Nearly 90 days into the Penetration Testing with Kali course and things are going swimmingly, however I needed a little break from the nightly course routine. Naturally, I pull up VulnHub, because nothing beats taking a break from popping boxes by... popping different boxes? Oh well. Last night I picked up SkyTower v1 and got straight to work.

A quick nmap scan showed me the following:

Nmap scan report for 192.168.1.143
Host is up (0.000034s latency).
Not shown: 65532 closed ports
PORT STATE SERVICE VERSION
22/tcp filtered ssh
80/tcp open http Apache httpd 2.2.22 ((Debian))
3128/tcp open http-proxy Squid http proxy 3.1.20

Squid was running and SSH was filtered, which looked pretty interesting. I'll get to that later. Hitting the system with a browser presents a basic PHP login form. Inspecting the page source tells me there shouldn't be many other surprises in store. Dirbusting also reveals nothing more than the login page, so that's good. My mind immediately went to SQLi. I fired up a console and got to work with cURL (Figure 1).

Running your bog standard SQLi login bypass strings didn't seem to work, and thankfully the developer who designed this login form left in the MySQL output for us :). After a few enumerations, it looked as though certain characters were being stripped out of the form input before it got to MySQL such as '=', '-', 'or', 'and' and a couple others. I spent some time doing my homework on partial SQLi filtering techniques and came up with the following string: ' oorr 1 > 0 #'. This was a pretty slick workaround for cases where the form inputs are filtering out 'or'. The middle 'or' is replaced, resulting our outer 'o' and 'r' characters coming together giving us what we needed (Figure 2).

Plugging this into the browser form returned a message from SkyTower (Figure 3).

SSH access, nice. There was a little snag though, as ssh seemed to be filtered. A quick login using John's credentials confirmed my suspicions, that must be what Squid was made available for. I dropped the victim's IP and proxy port (3128) into proxychains.conf and set out to try logging in again, this time with success! Well, sort of...

I (err... John) had to go through all this work only to be told that funds have been withdrawn? That seems like overkill. Something must be telling the terminal to exit out. I passed 'ls' to the victim via ssh and nothing suspicious came up so I had a look at .bashrc (Figure 5). Bingo.

After a quick and dirty replace command I'm in (Figure 6).

proxychains ssh john@192.168.1.143 "cat .bashrc | head -n -4 >bashrc.mod && mv bashrc.mod .bashrc"

At this point I spent probably too much time poking around the file system and seeing what kind of options I had. I looked for any funky root-owned binaries with the setuid bit set and nothing major popped out. I knew of the pt_chown vulnerability and did a fair amount of research into using that but I ended up not pursuing that attack vector. Having come up with not a whole lot, I remembered that there were user credentials once I bypassed the login form. Somewhere there were credentials being served up, so I looked to see if I had access to any of the web directories. As it would have it, my user had access to read files in /var/www.

In the web root, there was a config.php file which contained root login credentials to the MySQL database. My lucky day! I fired up mysql and was able to pull plaintext login credentials for the SkyTower database (Figure 7).

Following the same proxy ssh login pattern, I tried using the credentials. I wasn't able to log in to the system as william, but sara was a success. As with John's ssh login, Sara's ssh connection was immediately killed. Working my magic replacement, I had access to Sara's account. After a fair bit of time spent poking around and seeing what Sara had access to, I checked if Sara was allowed sudo access (Figure 8).

Sara had /bin/cat and /bin/ls sudo privileges to the /accounts path which looked promising, except that flag.txt was in /root. Well, thankfully the sysadmin didn't read up on how using wildcards in sudoer file paths is bad news! Rookie mistake buddy... I took advantage of the wildcard vulnerability to reach the flag (Figure 9)!

Overall, I'd say this system was pretty easily defeated with a little patience and research. I definitely learned a little bit more about SQLi attacks and ways to further circumvent partial SQLi filtering. I guess now I need to get back to the offsec labs! Thanks for reading!