Valley
Can you find your way into the Valley? - by valley
Recon
Enumerating the machine gives us three open Ports, 22 running SSH, 80 running a web server and the unusual port 37370 running ftp.
Inspecting web server
On first look visiting the website doesn’t reveal anything interesting.
Running gobuster for some directory enumeration gives us an promising directory, static
but it's an empty directory with directory listing enabled.
Digging further into it with gobuster. Maybe it will reveal us some hidden files or directories.
Out of curiosity directly visiting static/00 gives us the first hint. A directory which has to be removed. Maybe it’s still there.
Visiting /dev/1243224123123 reveals a login page.
By inspecting the source we see an included javascrip dev.js which might contain the logic behind the login.
Inspecting the script discloses a user and password siemDev:california
Which aren’t any relevant, because it directly redirects to /dev1243224123123/devNotes37370 entering the right credentials. The name of the note is referring to the ftp service running on the machine.
Out of curiosity, entering the creds does trigger the redirection.
The note states not to reuse credentials. So, maybe siemDev:california is also used for the ftp service.
Inspecting ftp
The credentials siemDev:california are indeed valid. And inside the ftp are three pcapng files.
Analyzing siemFTP.pcapng with wireshark does not reavel anything interesing. Neither does siemHTTP1.pcapng
But extracting the HTTP Objects from siemHTTP2.pcapng gives credentials hidden in the 42byte size index.html
valleyDev:ph0t0s1234
SSH into the machine and getting user flag
Those credentials are related to the valley website. Maybe it is possible to login with those through ssh.
And those are indeed the creds for valleyDev. We are able to retrieve the users flag.
It's possible to change user to siemDev by reusing its credentials, but there is nothing of interest. But there is a binary in the /home directory valleyAuthenticator which might contain some credentials.
On enumerating the target, a cronjob catches the eye. But does not seem to be exploitable by siemDev.
Next, copy the valleyAuthenticator to the attacking machine to analyze it further.
For a quick analysis, just use strings. But there is nothing to detect. Even in Ghidra it wasn’t analyzable by the pure eye.
Running strings on it (string valleyAuthenticator -n 10) reveals that is packed with UPX
With upx -d valleyAuthenticator it is easily unpacked.
Looking at the main function via ghidra importing the unpacked binary, we see it is prompting for a username and password. For some values, md5 sums are calculated. Maybe the inputs are calculated as hashes and compared with stored hashes.
Running strings and grep for the prompted user input we find two md5 hashes.
Cracking them with crackstation gives the credentials valley:liberty123
With hashcat it would be like this hashcat –m 0 hashes /usr/share/wordlists/rockyou.txt
Switch user and privilege escalation to root flag.
Using the credentials valley:liberty123 we are able to log in as user valley. Unfortunately, the user is not allowed to run anything with sudo, neither are any suid bits set which are of interest. Instead, there is the group valleyAdmin
Looking for files owned by the group shows the file base64.py
Remembering there was a cronjob running the script /photos/script/photosEncrypt.py
Maye the base64.py might be an entry point
Inspecting photosEncrypt.py uncovers the use of base64.
Next, start a listener on the attack machine nc -lnvp 4445
Start editing the base64.py owned by the group valleyAdmin and adding reverse shellcode to connect back to our machine. The cronjob is run by root, so the connection to the listener will be root.
Running pspy64 which was provided by the attack machine just to see when the cron job hits.
As the cronjob hits, the reverse shell connects. We are root and are able to extract the root flag.
Last updated
