Dodge
Test your pivoting and network evasion skills.
This work by Manav G Krishna is licensed under CC BY-NC 4.0 
Machine IP: 10.10.3.234
Nmap Scan:
nmap -p- -A -v -oN dodge_thm -Pn 10.10.3.234
Nmap scan report for 10.10.3.234
Host is up (0.50s latency).
Not shown: 65532 filtered tcp ports (no-response)
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.2p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 3072 a0:ec:76:fa:35:6b:a3:76:c7:37:0a:83:3b:fa:e2:a7 (RSA)
| 256 48:aa:54:67:1c:48:19:5b:94:6d:ca:0a:dc:98:35:13 (ECDSA)
|_ 256 2e:7c:9e:71:dc:59:ef:bd:c8:e6:f0:02:59:87:35:fb (ED25519)
80/tcp open http Apache httpd 2.4.41
|_http-title: 403 Forbidden
|_http-server-header: Apache/2.4.41 (Ubuntu)
443/tcp open ssl/http Apache httpd 2.4.41
|_http-title: 400 Bad Request
| http-methods:
|_ Supported Methods: GET HEAD POST
| tls-alpn:
|_ http/1.1
| ssl-cert: Subject: commonName=dodge.thm/organizationName=Dodge Company, Inc./stateOrProvinceName=Tokyo/countryName=JP
| Subject Alternative Name: DNS:dodge.thm, DNS:www.dodge.thm, DNS:blog.dodge.thm, DNS:dev.dodge.thm, DNS:touch-me-not.dodge.thm, DNS:netops-dev.dodge.thm, DNS:ball.dodge.thm
| Issuer: commonName=dodge.thm/organizationName=Dodge Company, Inc./stateOrProvinceName=Tokyo/countryName=JP
| Public Key type: rsa
| Public Key bits: 4096
| Signature Algorithm: sha256WithRSAEncryption
| Not valid before: 2023-06-29T11:46:51
| Not valid after: 2123-06-05T11:46:51
| MD5: f130:c8c8:576c:7a0c:8adc:2b43:ea0a:4233
|_SHA-1: 8ed2:dbe0:71ed:cf13:c1a0:d02f:b68b:ec34:4ac4:a4aa
|_http-server-header: Apache/2.4.41 (Ubuntu)
|_ssl-date: TLS randomness does not represent time
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: specialized|storage-misc
Running (JUST GUESSING): Crestron 2-Series (86%), HP embedded (85%)
OS CPE: cpe:/o:crestron:2_series cpe:/h:hp:p2000_g3
Aggressive OS guesses: Crestron XPanel control system (86%), HP P2000 G3 NAS device (85%)
No exact OS matches for host (test conditions non-ideal).
Uptime guess: 3.200 days (since Sat Dec 30 08:09:27 2023)
Network Distance: 4 hops
TCP Sequence Prediction: Difficulty=251 (Good luck!)
IP ID Sequence Generation: All zeros
Service Info: Hosts: default, ip-10-10-3-234.eu-west-1.compute.internal; OS: Linux; CPE: cpe:/o:linux:linux_kernel
TRACEROUTE (using port 443/tcp)
HOP RTT ADDRESS
1 246.05 ms 10.4.0.1
2 ... 3
4 502.33 ms 10.10.3.234
We have port 22, 80 and 443 open. From the Subject Alternative Name field of the scan we notice that we have the main domain & it's subdomains.
An other way to find this out instead of us waiting for the scan to complete is by accessing the site over HTTPS to view the SSL Certificate:
SSL Certificate:
Main domain: dodge.thm
Subdomains: www.dodge.thm, blog.dodge.thm, dev.dodge.thm, touch-me-not.dodge.thm, netops-dev.dodge.thm, ball.dodge.thm
Out of these we could access only: www.dodge.thm, dev.dodge.thm & netops-dev.dodge.thm. The rest were Forbidden.
The www.dodge.thm did not contain any information in its source code, and there were no specific versions of technologies used on this site that could be vulnerable to something.
The dev.dodge.thm had the PHP Info Page.
The netops-dev.dpdge.thm was blank. But the HTTP title said: Firewall - Upload Logs. Upon checking the source code we find this:
Two javascript files: cf.js & firewall.js are being referenced in this HTML code.
The firewall.js sounds interesting. Checking this out revealed an endpoint named firewall10110.php:
Accessing this endpoint:
In here we have a UFW Firewall configuration info along with an option that lets us run UFW commands.
Explanation of this configuration:
Status: active: The firewall is currently active.
Logging: on (low): Logging is enabled at a low level, meaning events are being logged.
Default: deny (incoming), allow (outgoing), deny (routed):
Incoming connections are denied by default.
Outgoing connections are allowed by default.
Routed connections are denied by default.
New profiles: skip: New profiles are skipped, which could mean that when new network profiles are detected, they are not automatically configured, and you may need to set rules for them manually.
Rules:
Allow incoming connections on port 80 (HTTP).
Allow incoming connections on port 443 (HTTPS).
Allow incoming connections on port 22 (SSH).
Deny incoming connections on port 21 (FTP).
Deny incoming TCP connections on port 21.
Allow incoming IPv6 connections on ports 80, 443, and 22.
Deny incoming IPv6 connections on ports 21 and 21/tcp.Note: These rules explicitly allow incoming connections on these ports despite the default policy being to deny incoming connections.
Since we can run commands we can modify these existing rules according to our needs.
Finding some blogs on using UFW Firewall commands:
From our nmap scan we knew that we had ports 22, 80 & 443 open (due to the UFW rules) but not port 21 - FTP. We can modify this rule: 21 DENY IN Anywhere to allow incoming connections to the FTP port.
UFW Command: sudo ufw allow ftp
Upon running this command the rules got updated and now the Action is ALLOW IN for FTP :
Confirming that port 21 is open:
Now we can try to connect to the FTP server. The first thing we can try to do is an anonymous login, that is both the Name and the Password being anonymous.
Confirming the same through an Nmap Scan:
Connecting to the server:
Directory listing:
We have the contents of a users home directory. Now we can go ahead and get all the possible files from the server on our local machine using the get command.
The .ssh directory had these files:
Contents that were successfully transferred from the server: authorized_keys, id_rsa_backup
The public key (authorized_keys) belonged to a user named challenger:
We can now SSH in as challenger post changing the permission on the private key file (chmod 400 id_rsa_backup):
Currently we are in the home directory of challenger where we get the user flag.
Checking users that have a console:
There is a user named cobra . We can try to find ways to become this user.
First way: ( This was how I initially got to cobra)
Upon listing out active network connections (ss -tulpen/netstat -tulpn) on the machine we notice that there is something running on a couple of high ports on the localhost.
SSH Local Port Forwarding on port 10000:
Since we have the ssh utility on the box/machine we can also Remote Port Forward . But we'll be going ahead with Local Port Forwarding.
Command for Local Port Forwarding:
ssh -L 8989:127.0.0.1:10000 challenger@10.10.3.234 -i id_rsa_backupNow we can access the service running on the port 10000 on our localhost on port 8989
The site:
Since the site had Apache web server running we could check the VHOST configuration info (apache2ctl -S):
We notice the 10000 port on the localhost. This confirms we port forwarded to the correct port.
The login page:
Checking the source code of this login page revealed the creds:
After successfully logging in we land here:
The Dashboard:
We now have cobra's creds. It says it is for SSH.
Trying to SSH in wasn't working:
Now let's try to get in as cobra from the machine itself by using the su utility:
We got in!!
Second way: ( Easier way to get to cobra):
Navigate to the /var/www/notes/api directory and we find a base64 content in the posts.php file ( We find this file upon cat ing out the .bash_history file in the home directory of challenger. In Bash, your command history is stored in a file ( .bash_history ) in your home directory and in this case the command in the file was - cat posts.php. Running a simple find command on the posts.php will give us the path):
Decoding the same gives us the creds of cobra:
Privilege Escalation:
We can now check for cobra's sudo rights/privs:
The apt binary can be run as any user without us being prompted to enter a password. So we can run it with elevated privs to become root.
Searching in GTFOBins:
Command:
sudo apt update -o APT::Update::Pre-Invoke::=/bin/shNow we are root and can fetch the root flag from /root directory:
Room solved!!
Last updated