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.
As we always do, let's kick off with an nmap scan of the host to see what we can find.
Alright 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
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.
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.
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.
Excellent! Alright now all we need is the password. Let's assume there is a password entry in the same user table.
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!
Once on the box I moved over a few enumeration scripts - namely
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
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!