🌄Valley

License

The following post by anthonyjsaab is licensed under CC BY 4.0arrow-up-right

0 - Introduction

Link to room: https://tryhackme.com/room/valleypearrow-up-right

This writeup walks you through a room on TryHackMe created by tryhackme and valley

1 - Scanning

1a - Ports

1ai - Discovery

┌──(kali㉿kali)-[~]
└─$ sudo nmap -sS -p- 10.10.23.36
[sudo] password for kali: 
Starting Nmap 7.93 ( https://nmap.org ) at 2023-05-29 08:27 EEST
Nmap scan report for 10.10.23.36
Host is up (0.11s latency).
Not shown: 65532 closed tcp ports (reset)
PORT      STATE SERVICE
22/tcp    open  ssh
80/tcp    open  http
37370/tcp open  unknown

Nmap done: 1 IP address (1 host up) scanned in 577.97 seconds

1aii - Versioning

1aiii - Checking for vulnerabilities

1b - Directory busting

1c - What we know so far:

  • The target machine exposes 3 ports: 22 (ssh), 80 (http), 37370 (ftp)

  • The OS and applications of the target machine seem fairly up-to-date.

  • The CVEs returned are not very useful.

  • Directory busting might have returned interesting results worth inspecting.

2 - Manually exploring the webserver

So much data could be gathered by going through all of the directories and pages discovered by dirb. However, for the sake of keeping this writeup digestible, I will list the pages that would lead to gaining foothold:

2a - /static/00

0704aa221b76460db5fd306e76d411f5

2b - /dev1243224123123

532ab41448efcffd6fa897bbc3142d40

The first thing that comes to mind would be to bruteforce this login form. However, when opening the Network Inspector and attempting to login with dummy credentials, no packet is sent! However, something does happen when clicking on login.

2da8fde943cca89d81c87e93e05cf378

This points out to login logic being embedded in JS code on the client side. Going to the Debugger leads to this:

7259b6fdef919d29b203754b40b0daa1

The highlighted lines are VERY important, and we will see why:

2c - /dev1243224123123/devNotes37370.txt

538c511109168d515e35550c65cb16a6

2d - What we know so far

  • The team in charge of the target machine have a very bad security posture. They do claim to reuse credentials.

  • The username "siemDev" paired with the password "california" might come in handy later.

3 - FTP

Trying out the set of credentials collected previously would lead to this:

4 - Wireshark analysis

Analysing the Wireshark captures were very time consuming. It is not possible to list every finding here. The most import finding was in the siemHTTP2.pcapng file while inspecting unencrypted packets:

241680471-36355922-253e-40a1-9149-11d70946bdea

The credentials valleyDev:p********* will prove to be important later.

5 - SSH - Part One

Trying the collected credentials on SSH would lead to gaining foothold!:

We also reached the first flag:

6 - valleyDev's enumeration for privesc

6a - Essential outputs from LinEnum

6b - What we know so far:

  • SUID/SGID are not an option

  • A quick sudo -l leads to a dead end

  • A very interesting cronjob belonging to root is worth inspecting: python3 /photos/script/photosEncrypt.py. It runs every minute.

  • Two other standard users named "valley" and "siemDev" exist

7 - The Cronjob - Part One

When first discovering the cronjob, I thought I would be able to modify it or use it in a way similar to base64 and vi when they have the SUID bit set. However, inspecting the script would prove me wrong:

8 - Finding another path: Pivoting

Seeing that the python script was not of much help, it seemed as if the "valleyDev" user wouldn't be the launchpad to gaining root access. I started looking for other ways. That is when I did an important discovery:

8a - /home/valleyAuthenticator

Normally, we only find folders in /home. However, on this target machine, there was an executable with a very interesting filename:

8b - Investigating valleyAuthenticator

From the filename, I understood that this file was worth investigating. At first, I thought the executable might be communicating with an authentication server, and that I will need to bruteforce my way to reveal a secret. However, reviewing the LinEnum outputs made this scenario very unlikely. It now seemed that the secret could be embedded in the executable itself. A quick search on Google revealed that there was a tool that could be useful in this situation: strings.

8bi - strings - Part One

After downloading valleyAuthenticator to my Kali machine using SCP, I ran the strings command on it:

Going through the output revealed to be mostly gibberish. However, two snippets were interresting:

  • While searching for "user", I found this:

I felt that it was important, but I did not know how to proceed with it.

  • While simply scrolling, I noticed this:

This was VERY interesting. This executable was packed using UPX. A quick search on Google revealed that I could uncompress the executable: using:

8bii - strings - Part Two

Using strings on this bigger executable leads to much more output, but they are much more human-readable. Searching again for "user" led me to this:

When I saw this, I immediatly identified the two gibberish strings as potentially MD5 hashes. Putting them in CrackStation leads to:

241681215-e4b8aa69-43bf-4cae-a683-e1228be13ed0

Voila! We now have new credentials

9 - SSH - Part Two

Using the newly discovered credentials leads to:

10 - Enumerating (again)

Enumerating again did not lead to interesting results, at first. However, after countless unsuccessful attempts, an enumeration outputted something interesting:

By using the user "valley", I could possibly change the PyPI packages stored on the target machine!

Inspecting the folder left no doubt: I can execute a supply chain attack by modifying the base64 package used in the cronjob's script!

11 - The Cronjob - Part Two

With the help of revshells.com, I modified base64.py to include:

After a minute, we get a reverse shell and can finally access the root flag!:

Last updated