Introduction
AI was an interesting machine recently retired by HTB. The initial portions were more frustrating than complicated and reminded me of the daily struggle of dealing with various home assistants. Once a foothold was established privesc to root involved abusing a java debugging process running on localhost. As usual this was another HTB machine that gave me an opportunity to work with technology that I had not touched before and I overall enjoyed the journey.
Initial Recon
As we always do, let's kick off with an nmap scan of the host to see what we can find.
root@kali:~/Desktop/HTB/AI# nmap -sV -sV -p- 10.10.10.163
Starting Nmap 7.70 ( https://nmap.org ) at 2019-11-13 21:19 EST
Nmap scan report for 10.10.10.163
Host is up (0.029s latency).
Not shown: 65533 closed ports
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
80/tcp open http Apache httpd 2.4.29 ((Ubuntu))
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernelAlright not all that much. There does seem to be an Apache instance running on port 80, so let's take a look at what is running on there.
The most interesting page so far is the db.php page.
For a little bit of further recon I also ran a quick scan of the site to see if we could get any extra hits. Sure enough we got some interesting results.
root@kali:~/Desktop/HTB/AI# dirb http://10.10.10.163 /usr/share/dirb/wordlists/common.txt -X .php
-----------------
DIRB v2.22
By The Dark Raver
-----------------
START_TIME: Wed Nov 13 21:46:17 2019
URL_BASE: http://10.10.10.163/
WORDLIST_FILES: /usr/share/dirb/wordlists/common.txt
EXTENSIONS_LIST: (.php) | (.php) [NUM = 1]
-----------------
GENERATED WORDS: 4612
---- Scanning URL: http://10.10.10.163/ ----
+ http://10.10.10.163/about.php (CODE:200|SIZE:37503)
+ http://10.10.10.163/contact.php (CODE:200|SIZE:37371)
+ http://10.10.10.163/db.php (CODE:200|SIZE:0)
+ http://10.10.10.163/index.php (CODE:200|SIZE:37347)
+ http://10.10.10.163/intelligence.php (CODE:200|SIZE:38674)
-----------------
END_TIME: Wed Nov 13 21:48:22 2019
DOWNLOADED: 4612 - FOUND: 5
Very interesting. Looks like it is giving us a general syntax for a voice-to-text usage. Let's try and leverage a local utility, flite. I assumed at this point that we would need to leverage voice-to-text to perform some form of SQL injection. Let's see if we can get any useful output.
User exploitation
Funny enough I accidentally stumbled on to an error message based on one of my initial attempts.
Ok so we know it is running MySQL under the hood. Unfortunately I was having quite a bit of issues with getting the proper text to be understood properly. It was only once I came across this Microsoft article that I had the proper tips to get the text translated correctly. Funny enough "username" was not being translated properly so I had to take artistic liberties on the spelling and it finally worked.
root@kali:~/Desktop/HTB/AI# echo "open single quote union select Yusername from users Comment Database" > test6.txt
root@kali:~/Desktop/HTB/AI# flite -voice rms -f test6.txt -o test6.wav
Excellent! Alright now all we need is the password. Let's assume there is a password entry in the same user table.
root@kali:~/Desktop/HTB/AI# echo "Open single quote; union select; password FROM users Comment Database" > test7.txt
root@kali:~/Desktop/HTB/AI# flite -voice rms -f test7.txt -o test7.wav
Bam! Alright we should have a proper set of credentials now - alexa / H,Sq9t6}a<)?q93_. Let's try getting on to the host.
And just like that user is owned. On to root!
Root exploitation
Once on the box I moved over a few enumeration scripts - namely lse and pspy. After some poking around I found an interesting process running on the host.
Based on the jdpa mention I was able to deduce it was related to Java Platform Debugger Architecture. Following the process calls and we can see that it is running on port 8000 and is related to JDWP. A quick search later and we have more details on the process running from the Oracle JPDA documentation.
-agentlib:jdwp=transport=dt_socket, server=y,address=localhost:8000, timeout=5000
Listen for a socket connection on port 8000 on the loopback address only. Terminate if the debugger does not attach within 5 seconds. Suspend this VM before main class loads (suspend=y by default). Once the debugger application connects, it can send a JDWP command to resume the VM.
Based on the documentation and the process output the only difference is that our host does not have suspend set suspend=n.
Alright now that we have a better understanding of what is happening how will that help us? A quick look around for any low hanging fruit and we find an existing exploit.
I got the code over to the host and kicked it off. I'm not entirely sure _why_ I decided to go straight for the flag instead of initiating a root shell, however that decision ended up requiring triggering the exploit twice with different payloads due to an entitlements oversight of copying the flag. Hindsight is always 20/20 they say.
Well that's annoying... let's change those entitlements.
And just like that AI is in the books. Thanks folks, until next time!