jakec / dec 2020
Anyone can walk into a bank. Maybe if you do so with a clipboard and a hi-vis vest you could even get down to the vault. But to actually get inside it, you’re going to need to use the position you’ve already established to elevate your access. So far, our journey has taken us through a bunch of ways we can recon and gain access to a system. But once you have that access, what do you do? What type of authorisation do you actually have? And if it isn’t enough to be useful, how can you change that? Enter: privilege escalation, or privesc.
Broadly speaking, there are two categories of accounts, or levels of access: users and administrators. Users can probably access and modify certain files and folders, but Administrators are the only ones who can modify system settings as well as other user permissions.
Naturally, there are sub-groups of permissions as well depending on someone’s role. The artists at your studio might have control over the Media & Assets directories but not the Accounting drive; the accountants vice-versa. Horizontal privilege escalation is moving between roles of roughly similar level of access. Vertical privilege escalation is moving to a level above entirely, e.g. the IT support staff who manage the access of both artists and accountants.
It’s not just about what files you can see and move around though. When you open a program, it typically runs at the same level of access as your user. Sometimes, though, you might want a user with a lower level of access to run a specific program that requires a higher level of access. In Linux, this can be done with something called SUID. It’s basically a special permission that an admin can set on a program which will allow users to run it like that admin.
While this is handy, there are some programs that, when they have this kind of permission, can be abused to escalate our privileges more broadly. For example, say you’re a regular user and want to view secret_password_list.txt in the Locked Admin Folder. You can’t access the folder itself, but you find out that the Linux program responsible for copying files, cp, has the SUID permission set, so it will run as an admin. Instead of viewing the file as it is, you could run cp /Locked Admin Folder/secret_password_list.txt in a folder you have access to and it’d copy the previously inaccessible file somewhere you could view it.
(On Linux, you can view programs with the SUID permission by running
find / -perm -u=s -type f 2>/dev/null)
There’s a lot of other useful information about privilege escalation and enumeration in THM’s writeup that you should check out, but we’ve covered enough to answer the main question:
What are the contents of the file located at /root/flag.txt?
When we deploy the machine on THM and SSH into it with the username ‘cmnatic’ and password ‘aoc2020’ given by the instructions:
We can try running
cat /root/flag.txt to view the file. But it won’t work because the user we’re logged in as, cmnatic, doesn’t have the permissions to view that file. However, when we run
find / -perm -u=s -type f 2>/dev/null and look through the list of programs with the SUID permission, we can see bash is on the list. bash is a Unix shell, i.e. a program that runs other programs. So if bash will run as an admin, we should be able to run anything through bash as if we were an admin.
When we type
whoami to see which user we’re operating as, we get “cmnatic”. But when we run bash and try
whoami again, it tells us we’re now operating as root. And now that we can do anything, let’s try
cat /root/flag.txt again. Whadya know, we get our flag.