> For the complete documentation index, see [llms.txt](https://0xb0b.gitbook.io/writeups/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://0xb0b.gitbook.io/writeups/tryhackme/2023/valley.md).

# Valley

{% embed url="<https://tryhackme.com/room/valleype>" %}

## Recon

Enumerating the machine gives us three open Ports, 22 running SSH, 80 running a web server and the unusual port 37370 running ftp.

```
┌──(0xb0b㉿kali)-[~]
└─$ nmap -p- -v 10.10.112.128
Starting Nmap 7.93 ( https://nmap.org ) at 2023-05-26 14:10 EDT
Initiating Ping Scan at 14:10
Scanning 10.10.112.128 [2 ports]
Completed Ping Scan at 14:10, 0.05s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 14:10
Completed Parallel DNS resolution of 1 host. at 14:10, 0.02s elapsed
Initiating Connect Scan at 14:10
Scanning 10.10.112.128 [65535 ports]
Discovered open port 22/tcp on 10.10.112.128
Discovered open port 80/tcp on 10.10.112.128
Discovered open port 37370/tcp on 10.10.112.128
Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 30.59 second
```

<figure><img src="/files/wqkWbJCuacqPYyN7jpbL" alt=""><figcaption></figcaption></figure>

## Inspecting web server

On first look visiting the website doesn’t reveal anything interesting.

<figure><img src="/files/PKAXrMz8Femh3lsLISq6" alt=""><figcaption></figcaption></figure>

Running gobuster for some directory enumeration gives us an promising directory, `static`

```bash
┌──(0xb0b㉿kali)-[~]
└─$ gobuster dir -u http://10.10.112.128 -w /usr/share/wordlists/dirb/big.txt
===============================================================
Gobuster v3.5
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Url:                     http://10.10.112.128
[+] Method:                  GET
[+] Threads:                 10
[+] Wordlist:                /usr/share/wordlists/dirb/big.txt
[+] Negative Status codes:   404
[+] User Agent:              gobuster/3.5
[+] Timeout:                 10s
===============================================================
2023/05/26 14:12:29 Starting gobuster in directory enumeration mode
===============================================================
/.htaccess            (Status: 403) [Size: 278]
/.htpasswd            (Status: 403) [Size: 278]
/gallery              (Status: 301) [Size: 316] [--> http://10.10.112.128/gallery/]                                                                       
/pricing              (Status: 301) [Size: 316] [--> http://10.10.112.128/pricing/]                                                                       
/server-status        (Status: 403) [Size: 278]
/static               (Status: 301) [Size: 315] [--> http://10.10.112.128/static/]                                                                        
Progress: 20417 / 20470 (99.74%)
===============================================================
2023/05/26 14:14:28 Finished
===============================================================
```

but it's an empty directory with directory listing enabled.

<figure><img src="/files/e5uYtFx3CpqddT4Uy8H2" alt=""><figcaption></figcaption></figure>

Digging further into it with gobuster. Maybe it will reveal us some hidden files or directories.

```bash
┌──(0xb0b㉿kali)-[~/Documents/tryhackme/valley]
└─$ gobuster dir -u http://10.10.112.128/static -w /usr/share/wordlists/dirb/big.txt 
===============================================================
Gobuster v3.5
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Url:                     http://10.10.112.128/static
[+] Method:                  GET
[+] Threads:                 10
[+] Wordlist:                /usr/share/wordlists/dirb/big.txt
[+] Negative Status codes:   404
[+] User Agent:              gobuster/3.5
[+] Timeout:                 10s
===============================================================
2023/05/26 14:37:04 Starting gobuster in directory enumeration mode
===============================================================
/.htaccess            (Status: 403) [Size: 278]
/.htpasswd            (Status: 403) [Size: 278]
/00                   (Status: 200) [Size: 127]
/11                   (Status: 200) [Size: 627909]
/10                   (Status: 200) [Size: 2275927]
/1                    (Status: 200) [Size: 2473315]
/12                   (Status: 200) [Size: 2203486]
/18                   (Status: 200) [Size: 2036137]
/16                   (Status: 200) [Size: 2468462]
/17                   (Status: 200) [Size: 3551807]
/13                   (Status: 200) [Size: 3673497]
/15                   (Status: 200) [Size: 3477315]
/3                    (Status: 200) [Size: 421858]
/14                   (Status: 200) [Size: 3838999]
/5                    (Status: 200) [Size: 1426557]
/2                    (Status: 200) [Size: 3627113]
/4                    (Status: 200) [Size: 7389635]
/6                    (Status: 200) [Size: 2115495]
/9                    (Status: 200) [Size: 1190575]
/7                    (Status: 200) [Size: 5217844]
/8                    (Status: 200) [Size: 7919631]
```

Out of curiosity directly visiting `static/00` gives us the first hint. A directory which has to be removed. Maybe it’s still there.

<figure><img src="/files/H1GJ9gTNdd362ZEPq2v9" alt=""><figcaption></figcaption></figure>

Visiting `/dev/1243224123123` reveals a login page.

<figure><img src="/files/OSPJAxnoSL58E9qG2QER" alt=""><figcaption></figcaption></figure>

By inspecting the source we see an included javascrip `dev.js` which might contain the logic behind the login.

<figure><img src="/files/GsWhrAwg0Ej2g8pprAyH" alt=""><figcaption></figcaption></figure>

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.

<figure><img src="/files/g9AX0a2AvBmzU9JiGvlx" alt=""><figcaption></figcaption></figure>

Out of curiosity, entering the creds does trigger the redirection.

<figure><img src="/files/pnh4oGAslChJOW1tpwJM" alt=""><figcaption></figcaption></figure>

The note states not to reuse credentials. So, maybe `siemDev:california` is also used for the ftp service.

<figure><img src="/files/4MA7mt8dzKZxSQOATPtd" alt=""><figcaption></figcaption></figure>

## Inspecting ftp

The credentials `siemDev:california` are indeed valid. And inside the ftp are three pcapng files.

<figure><img src="/files/1pLczNIGassNy6bpzXHW" alt=""><figcaption></figcaption></figure>

Analyzing `siemFTP.pcapng` with wireshark does not reavel anything interesing. Neither does `siemHTTP1.pcapng`

<figure><img src="/files/8F6QRy67vstVzZ4wgsZb" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/Ycf9SG4Bh3hqrGmFbGza" alt=""><figcaption></figcaption></figure>

But extracting the HTTP Objects from siemHTTP2.pcapng gives credentials hidden in the 42byte size `index.html`

<figure><img src="/files/gU3cmonaPe7qJk5OuKfK" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/Lo9OVMPjf8Qt3cjbrPue" alt=""><figcaption></figcaption></figure>

`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.&#x20;

<figure><img src="/files/wW56ICkZua6gw1g3VRnz" alt=""><figcaption></figcaption></figure>

And those are indeed the creds for valleyDev. We are able to retrieve the users flag.

<figure><img src="/files/b2Ah3tnDcROuBE02dZpb" alt=""><figcaption></figcaption></figure>

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.

<figure><img src="/files/P2LOVnLM8OVr3ngaCEMq" alt=""><figcaption></figcaption></figure>

On enumerating the target, a cronjob catches the eye. But does not seem to be exploitable by `siemDev`.

<figure><img src="/files/ixAD1Gdd8dP3qimqkiMe" alt=""><figcaption></figcaption></figure>

Next, copy the `valleyAuthenticator` to the attacking machine to analyze it further.

<figure><img src="/files/Q9j5zZHgVPt1SaoIURKO" alt=""><figcaption></figcaption></figure>

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

<figure><img src="/files/VyavMW5Zhd8HiDePrcDG" alt=""><figcaption></figcaption></figure>

With `upx -d valleyAuthenticator` it is easily unpacked.

<figure><img src="/files/VGvK9tpltYdDBWlVlsIq" alt=""><figcaption></figcaption></figure>

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.

<figure><img src="/files/appvuSw8TdqAjgeKr52n" alt=""><figcaption></figcaption></figure>

Running strings and grep for the prompted user input we find two md5 hashes.

<figure><img src="/files/hu8iuwNS8xOYQPhF8NeK" alt=""><figcaption></figcaption></figure>

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`

<figure><img src="/files/KIZpYmfIvL5B6dU9nV79" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/TpxXxlkUYVW0voFQV0q0" alt=""><figcaption></figcaption></figure>

## 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`

<figure><img src="/files/4VrmZP1Yxs6IuMVwRjb8" alt=""><figcaption></figcaption></figure>

Looking for files owned by the group shows the file `base64.py`

<figure><img src="/files/WPankjXZf7RhnpRGUi0h" alt=""><figcaption></figcaption></figure>

Remembering there was a cronjob running the script `/photos/script/photosEncrypt.py`&#x20;

Maye the `base64.py` might be an entry point

<figure><img src="/files/gKQQhQqmqopGgE9cTGqt" alt=""><figcaption></figcaption></figure>

Inspecting `photosEncrypt.py` uncovers the use of `base64`.

<figure><img src="/files/uRXp6Nt5Xihvc3arwWaE" alt=""><figcaption></figcaption></figure>

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.

<figure><img src="/files/IKCKcIr10bMwflLC0cqt" alt=""><figcaption></figcaption></figure>

{% hint style="info" %}
<https://www.linuxfordevices.com/tutorials/shell-script/reverse-shell-in-python>
{% endhint %}

Running `pspy64` which was provided by the attack machine just to see when the cron job hits.

<figure><img src="/files/cWf5biaZ4syDBFS8P1s7" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/CkBSvECMHOe9AGDh6R9I" alt=""><figcaption></figcaption></figure>

As the cronjob hits, the reverse shell connects. We are root and are able to extract the root flag.

<figure><img src="/files/J1NxjtFeFc7HQBuA4syg" alt=""><figcaption></figcaption></figure>