Dodge
Test your pivoting and network evasion skills. - by 1337rce and l000g1c
Last updated
Test your pivoting and network evasion skills. - by 1337rce and l000g1c
Last updated
The following post by 0xb0b is licensed under CC BY 4.0
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.
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.
The following subdomains were detected:
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.
The page on netops-dev.dodge.thm seems empty at first glance ...
... 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.
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.
Here we see a script that fetches firewall10110.php. Let's take a look at the page, maybe we have access to it.
We have a page in front of us to customize UFW firewall rules.
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.
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.
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.
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.
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.
We have a user challenger.
And the Backup actually contains the SSH key. Nice. We apply the correct permissions via chmod 600 id_rsa_backup.
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.
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.
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.
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.
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.
Using SCP, we get this binary onto the machine quickly.
Now I've copied a cool trick from Tokugero. See:
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:
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:
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.
By inspecting the source of login.php, we spot some stored credentials in the comments.
Reusing those credentials ...
... We are able to log in.
Jumping to the Dashboard, we get the SSH credentials of cobra.
Skip this part if you want to.
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.
In /var/www/notes/api something encoded in base64 was then revealed.
This quickly decodes via the use of CyberChef and we get the credentials of user cobra. That was the first way, it was done.
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.
This can easily be exploited via sudo apt update -o APT::Update::Pre-Invoke::=/bin/sh to spawn a shell as root.
From there we head to /root and find the final flag.
