Challenge Premise

You have access under frank, but you want to be root! How can you escalate privileges? If you listen closely, maybe you can uncover something that might help!

Cryptic guidance, that tells you everything you need to know.

Listen… to what?

When the hint given is around listening, immediately my mind is going to go to netstat and ps or top to see what’s running on the machine. So I started by running ps -ef just to get an idea of all running processes. This was the result of the first command:

Not really much going on, the only ssh session was the one I initiated (frank@pts/0). If you’re curious how we can know that, you can just type who to confirm what terminal session you’re using:

frank@workstation:~$ who
frank    pts/0        2023-02-05 23:09 (10.13.8.205)

I wanted to get a live view of everything happening on the machine (in case there is some rogue/temporary process we can take advantage of) so I used top and sure enough, at one point a new SSHD process spawned and disappeared.

What is this rogue SSH process?

So what does this mean? My assumption is that for this challenge, there is a script that logs frank in, does some stuff and at some point he enters a credential that we’re going to need for privesc. One cool thing we can do is verify that there is in fact something logging frank in. To do that we can use the last frank command:

frank@workstation:/var/log$ last frank | head -n5
frank    pts/1        172.18.0.2       Sun Feb  5 23:30 - 23:30  (00:00)
frank    pts/1        172.18.0.2       Sun Feb  5 23:30 - 23:30  (00:00)
frank    pts/1        172.18.0.2       Sun Feb  5 23:30 - 23:30  (00:00)
frank    pts/1        172.18.0.2       Sun Feb  5 23:30 - 23:30  (00:00)
frank    pts/1        172.18.0.2       Sun Feb  5 23:30 - 23:30  (00:00)

This tells me I’m on the right track for a few reasons:

1. We know our session is under pts/0.
2. We know that our login occured remotely from our THM VPN address, for me

frank@workstation:/var/log$ last frank | grep 10.13
frank    pts/0        10.13.8.205      Sun Feb  5 23:09   still logged in

Time To (p)Spy

So I’ll be honest here, I tried used watching top and then using cat /proc/<newpid>/maps to dump the memory of the new processes that spawn in hopes of seeing what command was run. But I think because they are spawned in a separate session, I kept encountering a Permission denied. After some googling, I found this pretty sweet tool that can be used for unprivileged snooping on a Linux system. So I downloaded it to the VM I was working from and used SCP with the handy SSH key we were given to move it onto frank’s workstation.

Confirming our first theory

So in this screenshot, you can see that the sshd process that spawns and disappears lines up with another frank session being spawned.

But what we’re really interested in is what happened AFTER frank logged in. There are two really important bits of information here:

1. The PATH variable being loaded into the environment
2. This frank runs sudo cat /etc/shadow

Breaking it Down

So for those unfamiliar with sudo, it allows a user to run a command at an elevated privilege. Because /etc/shadow can only be read by the root user, or members of the root/shadow group, elevating our privilege is necessary to view the file’s contents (which is a list of all users, and the password hashes for those users that have passwords).

Sudo, itself, is a binary that runs on its own. So when you run sudo <cmd> you’re going to launch both sudo and then <cmd> under the context of that sudo permission. In Linux systems, when you enter a command on the CLI - the OS needs to know where that binary lives (if run via relative path). What I mean, is if we type cat on the CLI, what we’re actually doing is running /usr/bin/cat (this is a generally the path but obviously will vary). How does the OS know which binary to use? Simple, run which cat and you’ll get an output with the binary that will be executed. If you look at the screenshots above, you’ll see the actual order that is used to find the binary we want to run. Knowing that this other frank is going to run sudo at some point, we can actually intercept that program call with our own malicious script. To do that, we’ll need to modify frank’s .bashrc file to specify a path for our new bad bad program.

Modifying Environment Variables

Since we ARE frank, we can modify his .bashrc using your preferred text editor. Since this file is loaded every time a new bash shell session is initiated, we can actually export a new PATH variable that points to our malicious payload. All we need to do is add export PATH=/tmp:$PATH (or whatever path you choose) to the very top of our file. This is actually a common persistence mechanism used on compromised linux hosts.

Now when we list the PATH environment variables, we can see that the shell is going to look at /tmp first:

Crafting a binary to execute instead of the real sudo

We need to do a few steps here in order for this to work.

1. Create a file called sudo in /tmp
2. Write some code that intercepts the credential
3. Output the credential somewhere we can use.

Since we know our interactive terminal is actually running under /dev/pts/0 we can send the console output directly there. Here is an example of how to intercept sudo and print to our current terminal:

#!/bin/bash
read pass
echo $pass > /dev/pts/0

After we write this script and save it to /tmp/sudo, we need to chmod +x /tmp/sudo to make it executable and then we wait…

Elevating to root

Now with frank’s password, we can see if we can enter a root session via sudo su -. But remember, our malicious sudo broke the real sudo - so let’s remove our changes to .bashrc and resource it (source .bashrc).