Develop a hunger to accomplish your dreams!
Bitlab is a medium difficulty machine running Linux. It tests your knowledge in Git, basic privilege escalation or Reverse Engineering/Debugging techniques. This machine can have a relatively steep learning curve if you have no experience in software RE/Debug.
Be sure to checkout the Basic Setup section before you get started.
Like always, enumeration is our first port of call. Let’s take a look at the machine and see what we are dealing with.
Navigating to port
80 by going to
http://bitlab.htb we are greeted with a Gitlab login page:
If we click the
Explore link at the bottom of the page it brings us to another page that tells us that there are
No projects found:
Going through the links at the top menu
Snippets also have nothing to show. However, when we click on the
Help link we are presented with a directory that contains a
bookmarks.html file. This file is related to exporting bookmarks from browsers so this could potentially show us some juicy data.
Taking a look we find five pages bookmarked and one looks promising called
Having a look at this link it is
To see what the
password is we can simply
console.log() the variable like so:
As we can see we uncover the username:
clave and password:
Trying the password with the username
clave as well as
ssh unsurprisingly yields no results.
Logging in to Gitlab we are presented with two projects
Going to the
Administrator/Profile project the first thing I notice is
TODO: Connect with postgresql which could be useful information later on. There is also a link to a
profile box bootstrap snippet which is contained in the
index.php file of the project.
Taking a look at the
Administrator/Deployer project we see a link in
README.md to a Gitlab documentation page regarding
webhooks and a file called
index.php that looks like it is using webhooks to automatically update the local repository using
When an event occurs the
index.php file is run which in turn executes the
shell_exec() function which is used to execute the operating system commands
cd ../profile/; sudo git pull
Taking note of the command traversing to the
profile directory we can find this page at:
Looks like we have found the entry point for our
foothold and potentially even a leap straight to
sudo is being used.
All we need to do is update the
Profile repository, commit the changes, submit a merge request and then merge the changes. This should satisfy all conditions of the webhook event that
clave has setup and our changes to the repository should be pulled into the
profile directory on the system.
To gain a shell we will simply edit
index.php in the
Profile repository adding the line:
We then go through clicking the buttons
Submit merge request and then
attacker machine we setup our listener:
Once setup we execute the payload by navigating to:
We should receive a shell via
We can upgrade our shell if we wish.
First things first we should take a look at this
postgres mention we found in the
Profile repository readme file. Now we are logged in to GitLab let’s go back through the top links we went through earlier. We can see a bunch of stuff in the
Activity section that we have already seen. Moving along we go to the
Snippets link and find a submission called
Taking a look we see the code:
Let’s use this info from our newly obtained shell to grab data from the database using our own
PHP script. Hopefully we can find some juicy info.
Here we find that
/var/www/html/profile is owned by
root so let’s
cd /tmp and write our script there:
Then we can execute the file and see what we have got:
Looks like more credentials. At first I thought that the password was
base64 encoding as it decodes to the string
ssh-str0ng-p@ss. However, the password is just disguised as one potentially for a rabbithole affect. We can simply login with the password as is:
We take yet another
user.txt flag! Time for
clave’s home directory we find a file called
Let’s download it:
And then have a look at it with a
ollydbg and go to
File -> Open in the top menu navigating to
RemoteConnection.exe and selecting it.
Once loaded, depending on your layout, we should see the following:
If you are missing the
Executable modules and
References windows you can open them by going to
View in the top menu:
Check that the
CPU window is on module
If it isn’t double click
RemoteConnection.exe from the
Executable modules window.
CPU window right click and select
Search for -> All referenced text strings from the context menu:
We should see a list appear in the
References window showing a bunch of strings:
Here we can see an ASCII string which looks interesting:
This looked like it could potentially be a password but on checking this was not the case. Would have been too easy!
At a closer look we see
UNICODE "clave" which we know is a
username used on the system and then a mention of
UNICODE "C:\Program Files\PuTTY\putty.exe" which is an SSH client. Given the name of the file
RemoteConnection.exe we can safely assume that this program is meant to connect to
bitlab and most likely as
We look at the
Disassembly section related to
UNICODE "clave" and see
CMP which stands for
compare. We like comparisons as that’s usually where interesting things happen.
Let’s set a
breakpoint and see whats going on. While the string
UNICODE "clave" is selected press
F2. We will see the address
00401640 highlighted in red showing that we have created a
breakpoint for that location:
To run the
F9 which brings us to our
Looking under the
Registers section we uncover what we are looking for:
We can now log in to
root with the password
And there we have it… Another box rooted!!
If you take a look at the beginning of this writeup I stated “tests your knowledge in Git, basic privilege escalation or Reverse Engineering/Debugging techniques”. Maybe you noticed it? Or maybe not!
Remember back when we found the exploitable script that used
sudo git pull I also stated “potentially even a leap straight to root“?
I know, I know! I’m sorry! But in my defence I wanted you to go through the Debugging way first.
Rewinding back to when we gained our
foothold with the user
www-data and we went in to the
/tmp to write our PHP script we could of done something a whole lot simpler.
In researching exploits for
git pull I came across this post. I decided that
githooks was going to be my attack method.
With further research I found the hook post-merge which is invoked by
git-merge which happens when a
git pull is done on a local repository. This fits all our criteria.
Now the issue here is that we can’t just add a
hook to the
.git folder in the repository because:
- Gitlab doesn’t allow it.
/var/www/html/profileis owned by
To combat this we will just recreate the
profile repository so we do have ownership.
/tmp we will copy the
profile repository to this location and then traverse in to it:
We will then create our
And make the file executable:
Next we get our listener ready on the
Now all thats left to do is alter a file in the
profile repository on Gitlab.
From there we
commit the changes,
submit a merge request and
Once that is done we can
pull in the changes to our own repository:
We should then receive a connection at our
There we have it
www-data -> root.
The initial foothold once again shows how the misconfiguration of a website can cause a ripple all the way to a system breach. Once compromised the misconfiguration of tools like
sudo allow execution of a command that can cause privilege escalation to