Buff was a... frustrating box. Not only were there mulitple attack vectors, but I discovered a new "rule" put in place by HTB to protect it's users. Though it took me a bit longer than I had hoped, persistence pays off, and I eventually got the root flag.
As usual, we start things off with a typical port scan. The results were... saddenning to say the least. Only 2 ports open, and only 1 of them is really all that responsive!? Damn... not off to a good start. Taking a look at the lone port, we see that it sia website of sorts.
Persuing the site revealed the framework, or Web APplication (WAP) in use. Fortunately, it has a vulnerability that gives a simple Remote Code Execution (RCE), getting us the user flag.
So far, so good... we seem to be off to a pretty good start. Using this basic RCE, we can download nc.exe and set ourselves up a proper reverse shell.
Now what...?
I had though up uploading linpeass or some other kind of scripted kernel vulnerability checker, but I try to save that as a bit of a last-ditch-effort. Besides, that's not (typically) quite how these challenges work on HTB. Instead, let's take a look around the filesystem and see what we've got. I'm sure there's all kinds of ways to do this, but myself, I just check out the user's home directory, and check each and evey folder (and sub-folder and file) therein.
There, in the Download folder, was our next hint: CloudMe. Searchsploit shows that it's had a few vulnerabilities over the years, and fortunately (for us), this one appears to be vulnerable to a buffer overflow allowing for yet another RCE. Since this one appears to run as a system service, this should get us to our root/Admin flag. The exploit suggested by searchsploit seems to be pretty straightforward and easy to use, so I dive right in.
Except, that it doesn't.
Maybe the service itself isn't running...? So I try the exploit and try to start the CloudMe application.
Nothing.
Maybe I didn't start the application properly...? So I try all kinds of way to start the application, start in the background, try to allow for a windowed application from the CLI...
Nothing.
Figuring I'm (hopefully) just missing simple, I review some of the finer details of the exploit, and see that we need access to localhost port 8888.
That'd explain why this wasn't working... (RTFM Jonny boy...)
Alright... so putty's "plink" tool should be able to accomplish this using just the CLI.
So, upload that and use it to redirect localhost port 8888 to our Kali/Attacker machine.
Except, that it doesn't connect.
It can't be a VPN connection, the reverse shell is still working and active. Nor can it be any other "general" connectivity issue.
It's got to be some kind of endpoint protection. Maybe it's already blocking plink.exe from running. So I try renaming it.
Nothing.
Maybe it's a bit smarter than that... So I try a few other ways to try to obfuscate the executable.
Still nothing.
Maybe... maybe it's even smarter than that...? Maybe plink ISN'T the tool to use...? There are all kinds of other tools that can accomplish a similar task, one being called chisel. But this requires a bit more... setup. And isn't included in Kali by default. I make a few (feeble, I will admit) attempts to get it to work, but... it's not part of Kali, and it is atypical to require non-Kali-included tools in HTB's challenges, so I didn't waste too much time trying to get this sorted out.
Chances are that I've probably overcomplicated the issue here now (I was).
Going back to the reverse shell, I start using the known-good nc.exe to try connecting on a variety of psudo-random-from-my-head ports. They all work. I try nc on port 22. This does NOT. Later on, I would be in contact with HTB support, where they confirmed that port 22 is now being blocked outbound to the "user's"/attacker machines. It was sorta-kinda-somewhat "announced", but I missed it, and could have saved myself a few hours.
So, upon discovering this, I end up falling down another rabbit hole trying to find a "quick and easy", simple way to redirect a port to port 22 for ssh/plink. After a couple more wasted hours, I end up figuring out that, really, the quickest and easiest way to do this is to just add the extra port to the sshd_config and restart the service. :S
Upon finally solving this, I run in to YET ANOTHER problem, being that there's some kind of encryption algorithm mismatch.
And there went a couple more hours down another rabbit hole trying to get my attacker SSH daemon to use older encryption options.
Nothing.
OMFGWTAF AAAARRRRGGGHHHH!!!!
My Google-fu suggests it may actually be as simple as using the latest version of plink. Getting it to the target machine did actually get it to work, so once again, overcomplicating the problem.
Ok... So now the port redirection is in place, we should be good to go on the exploit.
Yet again, it doesn't work.
Maybe... maybe it's... wracking my brain for somekind of idea on what's going on NOW, I mindlessly tap the up arrow key followed by Enter, trying again and againa and again. Looking back to the scrren, it worked!?
Et voila, there's the root/Admin flag!
Afterwards, discussing this behaviour with some associates fo mine, it comes to my attention that this is actually the, more-or-less, expected behavoiur for buffer overflows; it doesn't necessarily work each and every time. Usually, you need to try multiple times to get it to work. This would explain SO MANY "strange" behaviours I couldn't otherwise explain on other boxes and CTF challenges.
 HTB-Buff Report
|
|
HTB Buff |
|
 Monday, 05 October 2020 11:31  182.67 KB  422 |
Download |
My "Report Template" for CherryTree continues to evolve and, hopefully, improve. But since I'm just making this up as I go, I'm not sure if I'm "progressing" in the right direction. Maybe, I'm actually moving backwards. Someday, I'll get an actual job as an Ethical Hacker or Penetration Tester or Red Team or something similar, and maybe I'll find out then. But until then, I just make my own way.
As usual, let me know what you think in the comments!
