As I progress through TJ Null’s OSCP PWK V3 list, I wanted to cover a particular machine that had a very unique privilege escalation vulnerability. The machine in question is SPX. I’ll skip over initial access for the sake of brevity and limiting spoilers. Speaking of spoilers, you’ve been warned!

Identifying the Vulnerability

Once I had my initial footfold into the machine, and gained access to a local user account, my immediate thought was:

what privileges do I have in this new user context?

After some manual enumeration, I eventually found the answer. A sudo command for the make binary:

Research

Anytime I come across a specific Unix binary with special permissions (sudo in this case), I always consult the GTFOBins GitHub Pages site.

Initially, it looked like I had an easy win here, but I do not have access to the -s and --eval flags shown in the example GTFOBins code snippet. The target’s whitelisted command from the sudo -l output was /usr/bin/make install -C /home/profiler/php-spx:

I’ll be honest, I was stumped on this problem for a good hour or so. I decided to thoroughly enumerate the rest of the system. I was convinced I missed something somewhere. Eventually, I realized the sudo permission for this user was the obvious privilege escalation vulnerability. It was my only access to command execution as root on the target.

Even More Research

Having used the make utility in the past, I knew it called on instructions specified in a Makefile. I searched for Makefile exploits/privilege escalation techniques. Googling this topic eventually led me to this Medium article, written by one Adam Bartlett. He explains that make can be used to execute bash commands when the target directory is specified using the -C flag.

The “make” command looks for a file called “Makefile”. If you’re looking for code execution, make sure you’re running “make” in the location where “Makefile” is executed, or specify the directory using the -C flag.

Here is the malicious syntax for bash execution provided in the article.

Crafting the Makefile

Now it’s time to match the example to the target system. I always like to start by making a backup of a file I’m modifying. It’s not a requirement by any means, but it’s a good habit to have.

profiler@spx:/var/www/html$ cd ~/php-spx/
profiler@spx:~/php-spx$ cp Makefile ./Makefile.bak

There’s many different bash techniques that can be used to spawn a root shell in this scenario. I chose to create a malicous copy of bash with an SUID bit. When a standard user executes this bash copy with a -p flag, it tells bash to not reset the effective user ID with my real user ID. In short, bash will run with the file owner’s permissions (root).

Escalating Privileges

With the malicious Makefile in place, it’s simply a matter of executing the allowed sudo command.

Now I’ll execute the new /tmp/evil bash binary, ensuring the -p flag is provided to spawn a root shell!

Lessons Learned

The very specific sudo command was a great starting point for securing the system, but the true vulnerability lies in the specified directory’s permissions, /home/profiler/php-spx. The standard user profiler had write access to the directory, and as a result, write access to the Makefile itself. If the directory prevented the profiler user from having write access, there would be no opportunity to escalate privileges.

This machine was an excellent reminder that the devil is always in the details, and file permissions matter!