Dark Side 105: Intro to Privilege Escalation

I’ve accomplished my first few privilege escalations!

If you’ve been reading my other Dark Side posts, you’ll know the next room on the list was tmux, a tutorial for learning the popular command-line tool, but I ran into some technical difficulties on that one…I couldn’t find the credentials to access the virtual machine in that room, so if anyone has done that room before, let me know!

Instead of getting stuck, I decided to just move on to the next room, Privesc, so let’s dive into it!

Horizontal vs. Vertical

Common Linux Privesc is a room that walks you through a few basic places to start when looking for privilege escalation opportunities. There are two main types of privilege escalation:

• Horizontal — compromise multiple users on a system with the goal of gathering varying permissions that can be used to perform an exploit; User1 → User2 → User3
• Vertical — compromise a user account with Administrator or root permissions

LinEnum

In this room I also learned about LinEnum, a bash script available on GitHub that scans a system and provides useful information from the target system, like the users and groups, sensitive file permissions, SUID files, and cron jobs. This script can save a pen tester so much time by providing a lot of useful information that takes much longer to gather manually.

Here’s an example of a part of the output when running this script. We can see that user7 is a member of root, and this is an account I used to access and write to the /etc/passwd file in a later exercise:

[-] Group memberships:

uid=0(root) gid=0(root) groups=0(root)

uid=1(daemon) gid=1(daemon) groups=1(daemon)

uid=2(bin) gid=2(bin) groups=2(bin)

uid=3(sys) gid=3(sys) groups=3(sys)

uid=1000(user1) gid=1000(user1) groups=1000(user1)

uid=1001(user2) gid=1001(user2) groups=1001(user2)

uid=1002(user3) gid=1002(user3) groups=1002(user3)

uid=1003(user4) gid=1003(user4) groups=1003(user4),0(root)

uid=1004(user5) gid=1004(user5) groups=1004(user5)

uid=1005(user6) gid=1005(user6) groups=1005(user6)

uid=1006(user7) gid=0(root) groups=0(root)

uid=1007(user8) gid=1007(user8) groups=1007(user8)

Exploit #1

After running the LinEnum script, I found that the /etc/passwd file mistakenly had write permissions for some users. One of the users with those permissions was user7, so I now knew I could create a new user, even better, a superuser!

With user7, I opened the passwd file using the nano editor and added a new line to the file:

new:$1$new$p7ptkEKU1HnaHpRtzNizS1:0:0:/root:/root:/bin/bash

• new — our new user’s username
• $1$new$p7ptkEKU1HnaHpRtzNizS1 — this is a password of 123, but in order for it to be compliant it had to be a hashed value. The tutorial walked me through how to do this via the following command: openssl passwd -1 -salt
• 0:0:/root:/root:/bin/bash — UserID:GroupID:UserID Info:Home Directory:Shell

After adding this entry, I was able to switch to that user and had gained superuser privileges:

Exploit #2

The second exploit involved creating my first payload using Metasploit. By reviewing the cron jobs output in the enumeration scan results, I found there was a job that ran every 5 minutes to execute a script on user4’s desktop.

Since this runs as root, all that’s required is to inject a malicious payload into it. On my attackbox (a host used to attack the target machine being exploited), I created a payload using msfvenom, which invokes the CLI of Metasploit.

The -p flag is used to create a payload, and cmd/unix/reverse_netcat tells Metasploit which type of payload we’re generating. lhost and lport are the parameters that tell the exploited host where to connect once the payload executes. In this case, I wanted my target host to connect to my attack box, 10.10.94.92, over port 8888.

Now that I had the malicious payload, I had to copy it into the script that ran as part of the cron job we’re exploiting.

Using user7, the one with root permissions, I was able to open the script and edit it:

And now…we wait.

After a few minutes, I saw the connection in my netcat listener! Boom, we have a shell as root.

Exploit #3

This last exploit leveraged an imitation executable, a file that imitates a common command but executes something different. User5 already had a script in his home directory that was executing the ls command:

To use this to our benefit, the next step was to create an imitation executable for ls in the /tmp directory and configure it to launch “/bin/bash”. With that new file, I then used chmod to make the file an executable.

The last step in this exploit was configuring the $PATH variable to point to /tmp instead of the user’s shell. By running export PATH=/tmp:$PATH, I effectively updated the $PATH variable to /tmp instead of the default: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games

Now, when we run ./script it runs “ls”, but we successfully imitated ls in the /tmp directory to execute “/bin/bash” instead, resulting in a root shell:

Practicing these simple exploits was fun and interesting, and also provided me with more real-world context of the previously learned basics, like permissions and cron jobs.

Fourth Impression: I’m getting the hang of it

This time around, I found that navigating Linux is becoming easier. I still find myself Googling certain commands or files, but overall I’m more comfortable using the CLI than I was when I started.

There are a few times where I accidentally open a file in edit mode and can’t figure out how to exit, so I frustratingly bang on CTRL+X, q, and type exit, to no avail. In those moments, I seriously wonder who decided to make so many different “quit” commands! After Googling “how to exit out of X in Linux”, I am usually reminded to try :q or q!

I wonder how long it’ll take me to start remembering that! But that aside, I really am getting the hang of it and it’s super rewarding.

22% Complete!

I am now 22% of the way through the Beginner learning path and I have to say, I’ve learned so much! Outside of the practice I’m getting, the rooms so far have done a great job of explaining each step. And I’ve found if the rooms don’t explain it, the write-ups do, or other references are provided for further reading.

One of the things that really bothers me, especially when learning via exercises like this, is when there are no explanations as to why you’re doing what you’re doing. One of my courses in my master’s program was like that. The professor outlined all the commands to run for a specific assignment, similar to the below, and there were no explanations for any of it:

1. Type Nano text1
2. Type “Hello World”
3. Save text1
4. Type chmod +x text1

The entire time I was doing that assignment I was like Why?? At the time, I had no understanding of what Nano was and no idea what chmod did, so running those commands meant nothing to me.

I came out of that exercise with no new knowledge, but at least I got an A, right?

I personally always have to understand what I’m doing, or I’ll become very frustrated. As mentioned in a previous post, I don’t enjoy when something doesn’t make sense to me, so I’ll always find a way to figure it out. But the learning goes much smoother when the explanation I need to grasp the concept is provided upfront.

Kudos to TryHackMe and the room developers for creating awesome rooms for beginners like me! It’s much appreciated.

Additionally, for anyone on the same adventure of learning Linux as me, here are some useful references I found and have bookmarked:

Happy Hacking!