Doctor was a fun box. Though I took a few days here and there to get it done, the bulk of my work was done in 3 or so hours, so it wasn't TOO difficult...
As usual, we start with a port scan, and see that 22, 80, and 8089 are open.
This is my 10th documented box on HackTheBox, and I think I've seen port 22 open on ALL of them. And I've never even had to bother with it. I'm starting to think that port 22 is, essentially, never an attack vector, despite how often and hard I've tried... but I digress...
This new page is a login and we still have nothing to work with :(
Except that here there's an option, "Need An Account? Sign Up Now". Doing so gives us an account that is good for 20 minutes. And while I would love to brag this was the only time I had to do this, I would also be liar... I think I had to do this 4-5 times all said-and-done.
So now that we have acces, what can we do? I launch autorecon on the new domain name, less so for the port scanning, but more for the autmoated gobuster (in hindsight, it'd probably be smarter for me to make note of the actual commands themselves...). Loading the base domain URL brings us to what appears to be some kind of messaging system. We can post some messages, but that appears to be all. My wappalyzer browser addon shows us a Flask web framework is use, among a few other details.
Going back to the gobuster, we also find there's an /archive page, which doesn't offer that much more insight, but my wappalyzer notes there's some web framworks in use, the same as the messaging system, leading me to believe they are connected. Taking a look at the page source showed some "hidden" details of the posts I had made in the messaging system. Taking a deeper look, the "Title" of the message is nestled between some "<item><title>" and "</title></item>" HTML tags. I don't know how/why, but that combination of the Flask framework and HTML tags triggered a memory, some kind of article or post or twitter or something about this combo and "SSTI". After much Google-fu, I stumbled across this site (https://portswigger.net/web-security/server-side-template-injection), further detailing a "Server Side Template Injection" (SSTI). Some quick verification quickly shows us this is indeed a valid attack vector. More Google-fu ("kali ssti reverse shell” to be exact) brought me to another page (https://medium.com/@jayaye15/jinja2-server-side-template-injection-ssti-9e209a6bbdf6) showing a possible exploit. In fact, the page is *SO* similar it makes me suspect that it may be an incognito writeup for this part of the box, but I digress again...
So using that exploit, we gain an initial foothold on the box... YAY!!!
But no user flag... :'(
And here I spent a good hour browsing the filesystem, reading all the files and scripts... There was some really compelling possibilities... I even found a password hash in a databse! I wasted over an hour trying to sort out what kind of password hash it was before giving up and moving on. I had looked through all the python files, and while I don't quite fully understand how the entire framework all fits together, I did note that the framework itself appears to include a pasword reset function. Taking a look through the log files (eventually) leads us to what appears to be a password reset, and maybe a plaintext password...? Using the reverse shell, we can su to the other user and get that user flag! Yeah!
So now for the root flag...
A quick perusal of the user's home directory doesn't offer anything insightful. So time to take a look at linpeas. Again, so much info... and most of it is useless... :'( I just need to sort through what is what. In the review, I stumbled across another reference to Splunk, in the form of a username and home directory on /opt/splunkforwarder. Some more Google-fu lead me to a potential exploit, and github repo with PoC code. Cloning the repo and running (and verifying first, of course) the code gets us root access, and the flag!
The quick and obvious lesson to learn here is the user input in the messaging system. Though Splunk is what gave us the root access, it would not have been possible without the user credentials we found in the apache logs. The solution here is to properly verify and sanitize the users' input. But this opens a whole other can of worms on the topic of for-profit companies and organizations using these kinds of open-source projects, and profiting from them, while never pushing these fixes back upstream to the original open source project, often run by a single person with zero budget. These for-profit organizations should take the time and effort to push these kinds of fixes upstream, whereby increasing security as a WHOLE, instead of just your interests. But alas, I digress yet again...
|Monday, 14 December 2020 16:02 0 156||Download|
I have written up another Report for this box too. I didn't make any changes to the report template, but I am considering including some kind of timestamps for relevant events, but I am unsure how/where... my concern is that if, for example, I started on a box, then didn't come back to it for a week or so, could lead later review to suggest that I took that long to progress to that next step/timestampped event. But then again, do I care? I haven't decided yet...
Let me know what you think!