Reconnaissance and Initial Foothold
First up, like any good hacker movie (but real!), the video starts with some reconnaissance. The goal here is to figure out what services are running on the target machine. They use a classic tool for this: nmap.
nmap -sV -sC <target_IP>
nmap: The network mapper tool.-sV: This tellsnmapto try and determine the version of the services running on open ports.-sC: This runs defaultnmapscripts, which can often find some quick vulnerabilities or more information.<target_IP>: This is just a placeholder for the actual IP address of the Quaoar machine.
The nmap scan reveals a few interesting things:
- An FTP server (File Transfer Protocol) is open, and excitingly, it allows anonymous login. This is like finding an unlocked door!
- A web server is also running.
They dive into the FTP server first. Lo and behold, there are some files in there. One of them is a cred.txt file – promising! And another one is msg.txt which seems to hint at some credentials or usernames.
The cred.txt file actually contains a username (admin) and what looks like a hashed password. Hashed means it’s scrambled, not plaintext. They try to crack this hash using an online cracker, and bingo! They get the password.
With these credentials (admin and the cracked password), they try to log into the FTP server as admin (not anonymously anymore) but it doesn’t work. Hmm, okay, plan B. They then try these same credentials on the web server, specifically on a /admin.php page that was likely found during directory enumeration or hinted at. Success! They’re into some kind of admin panel.
Inside this admin panel, there’s an upload feature. This is a classic spot to try and get a reverse shell. A reverse shell is a way to get the target machine to connect back to the attacker’s machine, giving them command-line control. They upload a PHP reverse shell (a common script for web servers running PHP).
To catch the incoming connection from the reverse shell, they set up a listener on their own machine using netcat (often abbreviated as nc):
nc -lvnp <your_listening_port>
nc: Netcat, the “Swiss Army knife” for networking.-l: Listen mode.-v: Verbose (gives more output).-n: Numeric (don’t resolve hostnames).-p <your_listening_port>: The port number they’ll listen on (e.g., 4444).
Once the shell is uploaded and they access it through the web browser, their netcat listener springs to life, and they have a shell on the target machine as the www-data user (the user the webserver runs as).
User Pivoting and Privilege Escalation
Now they have a foothold, but www-data is a low-privilege user. The goal is to become a regular user, and then ultimately, the all-powerful “root” user.
- Finding User Credentials: They start poking around the file system. They find a
config.phpfile for the website, and inside, jackpot! There are database credentials for a user namedweb_user. - SSH Access: They try to use these
web_usercredentials to log in via SSH (Secure Shell, a way to get a much more stable and interactive shell).
ssh web_user@<target_IP>
And it works! They are now web_user. This is often called “user pivoting.” They check the /home/web_user directory and find the user.txt flag.
Looking for a Path to Root: Now, how to become root? They run a common enumeration script called linpeas.sh. This script checks for tons of potential misconfigurations and privilege escalation vectors on a Linux system. linpeas.sh highlights something interesting: a file called check_activity located in /usr/local/bin/ has the SUID bit set.
What’s the SUID bit? Normally, when you run a program, it runs with your permissions. If a program has the SUID bit set and is owned by root, when any user runs it, it runs with root’s permissions. This is powerful and often a source of vulnerabilities if not handled carefully.
Analyzing the SUID Binary: They examine the check_activity binary. It seems to be executing the service command in a way that might be exploitable. Specifically, it’s running something like service <something_related_to_user_input_or_environment> status.
Exploiting the SUID Binary: The trick here is that the service command might not be called with its full path (e.g., /usr/sbin/service). If it’s just called as service, the system looks for it in directories listed in the PATH environment variable. They can create their own malicious service script in a directory they control (like /tmp or the user’s home directory), put a command in it to spawn a root shell (e.g., /bin/bash), and then add that directory to the beginning of their PATH environment variable.
So, the steps are:
- Create a malicious
servicescript in/tmp/:
echo '/bin/bash' > /tmp/service
chmod +x /tmp/service
This script, when run, will just execute /bin/bash, giving a shell. Modify the PATH variable so /tmp/ is checked first:
export PATH=/tmp:$PATH
Run the SUID binary check_activity:
/usr/local/bin/check_activity
When check_activity (running as root) tries to execute service, it will now find and run the attacker’s malicious /tmp/service script as root. This pops a root shell!
And with that, they’re root. They can now navigate to /root/root.txt and grab the final flag.
So, in a nutshell, it was a journey from an anonymous FTP login to finding web credentials, uploading a reverse shell, finding more credentials to pivot users via SSH, and finally exploiting a SUID binary by manipulating the PATH variable to get that sweet, sweet root access. A classic example of how different vulnerabilities can be chained together!
