HackDay: Albania Walkthrough

HackDay: Albania

Thanks to R-73eN for the VM!

Using netdiscover, we identify the IP address assigned to the target system.

screenshot

We add a record to our /etc/hosts file for the target instead of having to remember the IP address.

screenshot-2

We then perform a full TCP port SYN scan on the target using Nmap, identifying open ports 22 and 8008.

screenshot-3

Again using Nmap, we dig in and perform service enumeration on the open TCP ports.

screenshot-4

We have SSH running on port 22, and an Apache web service running on port 8008. We also find the robots.txt file for the server thanks to the discovery NSE script http-robots.txt. Lets take a look at the web page before I turn my attention to the robots.txt entries.

screenshot-5

Thats right, this VM is from Albania. Gotcha. Google translate to the rescue. The pop-up translates to “Welcome: If I am, I know where to go;)”. I am guessing that means if you are like my man Elliot here, you know what the next hack move. Unfortunately, I am no Elliot.

We then take a look at the page source and find the following: ” “, which translates to “OK ok, but not here”.

I find it odd that the OK and UNE are capitalized, so I write it down in my notes. Back to that robots.txt file.

I use Burp Suite’s Intruder functionality to test the directories listed in the robots.txt file. First I proxy a GET request to the main page, and use it as the base for the Intruder attack positioning. I configure the position where the payload values will be added to be on the requested page “/”.

screenshot-6

On the payloads tab, we load the directories listed on the robots.txt file, turn off URL encoding of the payload, and leave the Payload Type as Simple List.

screenshot-7

We execute the attack, and observe the responses received from the target. The majority of responses have a returned Length of 440, but I find one directory returns a unique value of 283, /unisxcudkqjydw/. Looking at the response received, the page mentions another directory /vulnbank/. Also, I again note the capitalization of ‘IS’ in the message on the page.

screenshot-8

We also take a look at the page returned for all the other directory requests. The page contains an image of raptor with the following text: “A ESHTE KJO DIREKTORIA E DUHUR. APO PO HARXHOJ KOHEN KOT”, which translates to “Is this the proper directory, or are jerk”.

screenshot-9

Moving on, we check out the /vulnbank/ directory, which then lists another subdirectory /client/. Clicking on the /client/ directory, we are brought to the ‘Very Secure Bank’ web application.

screenshot-10

We again note the capitalization on the page, and in the page title, IN and SECURE respectively. So far, we have the following capitalized letters “OK UNE IS IN SECURE”. Ok, one is insecure???? Maybe.

Through testing the login form for the Very Secure Bank, I am able to generate the following MySQL error after placing a ‘ in the username field.

screenshot-11

Excellent, looks like some SQLi is in play here! I proxy another login attempt through Burp, and copy the request to file for use with sqlmap.

screenshot-12

We run sqlmap using the request file, set the DBMS to MySQL, and set the level and risk parameters to the max in order to perform a comprehensive scan. We also set the proxy to my local Burp Suite instance to capture all of sqlmap’s requests and the subsequent server responses.

Lucky for us, our scan is successful, and we find the login form is vulnerable to RLIKE boolean-based blind, and RLIKE time-based blind SQL injection vulnerabilities! Thank you again sqlmap.

screenshot-13

Highlighted in green above, we are notified by sqlmap that our scan has received a 302 redirect from the server. This is a good indication that we have successfully bypassed the authentication on the login page. We take a look at our Burp proxy, and find the request and payload sent to the target that generated the HTTP 302 response.

POST /unisxcudkqjydw/vulnbank/client/login.php HTTP/1.1
Content-Length: 64
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Host: hackday:8008
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
Connection: close
Cookie: PHPSESSID=s0ri4argqjtplmjsemmoh5rfn6
Referer: http://hackday:8008/unisxcudkqjydw/vulnbank/client/login.php
Content-Type: application/x-www-form-urlencoded

username=admin%27%20RLIKE%20SLEEP%285%29–%20MRve&password=admin

URL decoded: username=admin’ RLIKE SLEEP(5)– MRve&password=admin

We go back to the Very Secure Bank login page, enter the same payload into the Username field, select Log IN, and we are in! Now we have access the account of Charles D Hobson, who currently has 25000 euro. Nice!

screenshot-14

Getting back to our SQLi results, we cannot leverage our injection points to retrieve additional database information (appears it may only be good for authbypass). For example, we receive the following error when attempting to read all database names:

screenshot-15

Turning our attention back to the Very Secure Bank application, we find the ability to add Support tickets which also includes an upload component. The web form makes a POST request to ticket.php which includes data for the problem, description, and attached file.

We immediately turn our attention to finding flaws in the file upload functionality. In an attempt to upload the simple-php-backdoor php file included with Kali, we receive the following error message indicating there are restrictions on the file type thats allowed to be uploaded:

screenshot-16

Returning to the main page, it appears that the ticket was still created, however the attached PHP backdoor was stripped.

screenshot-17

Looking at the page source, associated files included with tickets are sourced from the following link: img src=’view_file.php?filename=simple-backdoor.php’. Further, we are able to generate a PHP include warning message when making a request to view_file.php with a page that does not exist.

screenshot-18

We also receive the following message when trying to include a page with a PHP extension:

screenshot-19

With this information, if we are able to bypass the filetype filter and upload our PHP shell to the server, we can leverage the include call on view_file.php to access the backdoor and get remote access.

Our backdoor for this attack will be the php-reverse-shell.php webshell included with Kali, which we modify by setting our IP address and a callback port of 443 (in case there is an outbound filter on the target).

We create a new ticket, attach our modified php reverse shell script, and catch the request in our Burp proxy.
Then, we modify the filename and Content-Type values within the form-data in an attempt to bypass the upload filter.

We make the following changes in the Burp Intercepter window:

Original Request:

screenshot-32

Modified Request:

screenshot-33

Success!!!! We receive the following message indicating the upload worked.

screenshot-21

Now to test the PHP reverse shell we use ncat to setup a listener on 443, and make a request to view_file.php for our backdoor file: http://hackday:8008/unisxcudkqjydw/vulnbank/client/view_file.php?filename=php-reverse-shell.jpg
It works, and we now have remote access to the hackday server!

screenshot-22

We use a technique I learned from g0tmi1k to improve our shell using python to spawn a bash instance. First we review the executable paths for python, and then run the following command:

screenshot-23

When testing the SQLi flaw on the Very Secure Bank login page, the MySQL error message received referenced the page config.php. After reviewing the file, we are able to find the database credentials for the root MySQL user.

$db_host = “127.0.0.1”;
$db_name = “bank_database”;
$db_user = “root”;
$db_password = “NuCiGoGo321”;

We use these credentials to access the MySQL instance on the server in search of more credentials. We find usernames and passwords for the Very Secure Bank application in the klienti table:

screenshot-24

Excellent.

Next, we leverage the tool LinEnum written by @rebootuser. This tool is a bash script that will gather a good amount of system information for us quickly, so we can parse the results and look for potential local privexec weaknesses. We scp the file from our attacking machine to the pwn’d hackday system and execute the script.

screenshot-25

Other than root, the only other local account on the machine is ‘taviso’.

screenshot-26

Attempts to SSH into hackday using the root and taviso accounts with the password ‘NuCiGoGo321’ that we found in config.php failed.

Looking further through the LinEnum results, we find the following regarding read/write permissions for sensitive files:

screenshot-27

It looks as if we have write permissions to the /etc/passwd file. Very interesting……. We confirm this by adding a test line to the file:

screenshot-28

Excellent!!!! We refresh our memory of the structure of the passwd file via some googling. Our attack will be to add a new user to the file with root level permissions, who’s password is included in passwd and is not on the shadow file. We accomplish this with the following command:

echo “badcypher:\$6\$NOPE\$NOTINCLUDED:0:0:root:/root:/bin/bash” >> /etc/passwd

screenshot-29

After adding the new line to the passwd file, we switch user to badcypher.

screenshot-30

Game over. We now have root access to the hackday machine. We output the flag.txt to cement our victory:

screenshot-31
One last final translation: Urime, Tani nis raportin! =’s Congratulations, Now begins the report!

….so true, so true.

Had alot of fun with this VM, thanks again to R-73eN, and of course to the dopest of dope VulnHub.