Bitlab was a fun little box that has us work through gitlab based exploitation. From erroneously stored user credentials, to uploading and merging our own files to the project, to finally exploiting hooks to execute our own code as root, this box was a good overview of various gitlab functionality. Marked as a medium box by hackthebox I feel this box had an appropriate difficulty score. If you were familiar with git workflows this should be on the easier side, however if you are stepping into this for the first time a bit of research would be required to understand what is happening.
Starting it off with our regular
Since there seems to be a Gitlab instance setup on port 80, let's open burp and see what we can find on the site.
Doing some initial poking around we end up at the help page, which upon close look has something quite interesting within it.
That last JS snippet seems like it's worth investigating. The full code ends up being:
If we strip down the hex values and convert them we can now see a user login/password combination -
clave / 11des0081x.
Using the credentials discovered above we are able to get into the console as
clave. A quick poke around and looks like he has a Developer role on the project Administrator / Profile. After examining the project a bit we realize that while we can't upload directly to the master branch our user
clave has merge rights. We could in theory create a separate branch, upload our php reverse shell script and the approve the merge request as
clave. Sure enough, this was quickly accomplished and we managed to get a reverse shell up and running.
Unfortunately www-data was not our true user in this case. With that said however we are able to escalate directly to root from www-data and retroactively get the user.txt flag.
As part of the initial enumeration once getting the www-data shell we notice an interesting sudo rule:
So we are able to run
git pull straight as root?! Now we're talking. Quickly looked at what git repos were hosted locally that we may not have seen previously from the web portal.
At this point I somewhat knew what needed to happen. I copied over an existing repo to a folder we had the ability to modify.
Since we are able to run
git pull as root, we can assume that any hooks triggered by the command would also be run as root. This githook reference documentation goes into details with the various hooks available. Since we are interested in
git pull hooks we quickly learn that while there isn't a direct pull hook, every pull will trigger a
post-merge - This hook is invoked by git-merge, which happens when a git pull is done on a local repository. ... The post-merge hook runs after a successful merge command. You can use it to restore data in the working tree that Git can’t track, such as permissions data. This hook can likewise validate the presence of files external to Git control that you may want copied in when the working tree changes.
Alright, so if we manage to control that hook with our own script, we should be able to run something directly as root. Let's see if we can call a reverse shell this way.
With a local listener ready, sure enough we get a hit! Gather the root.txt flag and retroactively the user.txt flag as well.
And just like that Bitlab is in the books. Thanks folks. Until next time.