Laboratory was an Easy Linux box. It certainly drove me down many a rabbit-hole, chasing many red herrings, but ultimately, persistence paid off, and I got the box.
As usual, we start with a port scan and get little more than 22, 80, and 443. So right off the bat we know it'll be a web-based attack (at least for the initial foothold). Rather than just use ye olde nmap alone, I use a tool called AutoRecon (https://github.com/Tib3rius/AutoRecon) which performs a few other additional basic recon scans (like nikto, some port specific nap scans, gobuster, and a few others as well), just to make that initial recon that much more effective. Truth be told, I typically start the scan before going to bed, and whenever I get back to it, the scan is done, so I just need to review all the output files it generated, but I digress... The reason I mention this is because in addition to a basic all-ports scan, it will take the results and make port/protocol specific scans immediately afterwards. In the port 443 SSL scan, the certificate has an alternate name, git.laboratory.htb. So almost right away, I knew we had that subdomain. Taking a quick look over the main domain webpage doesn't give any real indicators, it appears to be a pretty "plain" webpage.
Loading the git subdomain page brings up, unsurprisingly, a GitLab login page. We don't have any credentials to attempt any logins, but there IS an option to register. Trying to register with a random dummy account gives a pretty telling error, so you know to adjust your email's domain name. Unsurprisingly, there's no actual email verification, so even though it's a fake account, you can still register AND log in. Taking a quick look around, it looks like there only the single project, and not a whole lot else. Searching searchsploit and metasploit doesn't give any exploits. Taking a deeper look through GitLab, we see that there's an issue, talking about a 418 error code. This led me down a rabbit for for 2 days, trying to get Laboratory to respond to any of the Coffee Pot protocols, trying a variety of different methods to generate/send the traffic. NOTHING worked. This was so out-of-the-ordinary that it just HAD to be a clue.
Eventually, I just had to accept the fact that this was probably just the machine creator trolling us. So I had to move on.
While researching some possibilities, I came across a HackerOne report, discussing a file read vulnerability, which could lead to a full RCE. So I went through the reproduction... created the 2 projects, creating an issue, then moving it between the projects. Then I would try to git clone or pull the file down, and nothing. So I tried it again, slightly differently. Nothing. And again. Nothing. What was I doing wrong? I re-read the report, re-created it. Nothing. I tried changing the number of directory "step ups" (I do not know if there's a "proper" term for it...), the number of "/../" in the file I want to read. STILL nothing.
Needless to say, my patience was beginning to wear thin...
Then, whilst randomly, idly clicking about in GitLab, I open one of the issues, and lo and behold, there's clickable link that loads the passwd file I was trying to read...!?
WTF!?
Here I was, trying various clones and pulls and numbers of "/../" directories in the file, and the whole time the file was in the issue, not the git project... Another day down another rabbit hole... So now I had the file read exploit, time to escalate that to the full RCE!
And here, I am sad to report, is where this path of efforts come to an end... I spent another 2 days trying to figure out how to get the RCE, all to no avail. Really, it was the gitlab-rails console command I couldn't ever sort out. I couldn't get it to install on my Kali machine, nor a "throwaway" VM... In fact, it was during these efforts that my Kali VM died. This is something I've run in to a great number of times, and the primary reason I don't use Kali as my daily driver... You get to installing all kinds of weird things, and weird inter-dependency issues with multiple versions of the same libraries, that eventually, you update something or install something (or seemingly simply reboot), and something breaks. I've spent many weeks trying to repair a broken install like this, only to have to admit failure and re-install anew. So without further ado, I download the latest Kali (2020.4), and (boot the live ISO and grab my notes) get a fresh Kali install.
Here's where I laugh.
Because this latest version of Kali has an updated version of metasploit, which DOES have a module for this GitLab vulnerability. So we simply point and run, and BOOM!, we've got a (rather limited) shell. After poking abouts for a bit, not getting much of anything, I recalled coming across a site with the process to reset users' passwords from the CLI. On a whim, I dig up that page and go through the process. And it works! Right away, I know I want to log in to GitLab and take a look for any for any Private repos. And sure enough there is. And, almost as expected, there's a private key there. This is a "classic" problem. So much so, that there are tools specific to Git(Lab/Hub/Etc...) to search all the repos for keys like this. It's such a problem that GitHub has launched a bug bounty, with this as a category on it's own.
Using this key, we are able to log in ot the machine and get the user flag! The very next thing I do is get linpeas on there and run it.
And then waste another couple of days, diving down countless rabbit holes, chasing wild geese and red herrings... But there's one binary that really sticks out. And I looked at it it, and then moved on to other possibilities, but my mind just kept coming back to this one. It was just a little bit TOO unique to NOT be some kind of clue or hint. PLUS it has the SUID bit set, so it just HAD to be something. So I start to run some basic binary analysis on it. Now I'm no reverse engineer by any stretch, but I've used things like strings and strace and ltrace, so I throw these at the binary. Lukily, they all existed on the machine. Strings didn't give me much, strace gave me a whole ton, but ltrace gave me the clue I needed. In the end, it was actually present in the strace output, but even looking at it afterwards, it still wasn't all that obvoius. The clue was the that the binary in question was making a system to call to another binary, but did not include the whole path. Instead, it was relyaing on the system $PATH variable to locate the other binary.
I'm pretty sure we can abuse that. So I create a dummy file, which is actually a script to start a reverse shell, and point the $PATH variable to that folder. Run the first binary, and sure enough, the script was called, the reverse shell worked, and we got root access!
As usual, I wrote up a little report, and made some small improvements to the report template.
