Jump Ahead: Enum – User – Root – Resources
TL;DR;
To solve this machine, we begin by enumerating exposed services – finding only ports 22 and 80 open. Enumerating the webserver, we find a vim swap file for the webserver login – disclosing a username and binary location. Analyzing the binary, we learn it uses a vulnerable OpenBSD authentication library function. Using the login form to exploit the binary, we are able to bypass the authentication, and get access to jennifer‘s SSH private key. Using the private key to log into the SSH server, we now have access to read user.txt. Exploiting a vulnerability within the xlock program allows us to privesc to the auth group, where we are then able to exploit S/Key authentication to gain a root shell – getting access to root.txt.
Enumeration
Like all machines, we begin by enumerating exposed services – finding only ports 80 and 22 open.
$ nmap -Pn -p- 10.10.10.199
$ nmap -A -oA nmap-quickTCP-scripts -p 80,22 10.10.10.199
# Nmap 7.80 scan initiated Mon Jul 27 10:06:35 2020 as: nmap -A -oA nmap-quickTCP-scripts -p 80,22 10.10.10.199
Nmap scan report for 10.10.10.199
Host is up (0.21s latency).
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.1 (protocol 2.0)
| ssh-hostkey:
| 3072 5e:ff:81:e9:1f:9b:f8:9a:25:df:5d:82:1a:dd:7a:81 (RSA)
| 256 64:7a:5a:52:85:c5:6d:d5:4a:6b:a7:1a:9a:8a:b9:bb (ECDSA)
|_ 256 12:35:4b:6e:23:09:dc:ea:00:8c:72:20:c7:50:32:f3 (ED25519)
80/tcp open http OpenBSD httpd
|_http-title: Site doesn't have a title (text/html).
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Mon Jul 27 10:06:52 2020 -- 1 IP address (1 host up) scanned in 16.94 seconds
Next, we use gobuster to enumerate the webserver for directories and files.
$ gobuster dir -u $RHOST -w /opt/wordlists/seclists/Discovery/Web-Content/raft-medium-directories.txt -o scans/web/gobuster-80-rmd-exts.txt -x txt,php
/js (Status: 301)
/images (Status: 301)
/includes (Status: 301)
/css (Status: 301)
/index.html (Status: 200)
/index.php (Status: 200)
/fonts (Status: 301)
/vendor (Status: 301)
Getting User
Going to the index page of the webserver, we are presented with a login form. Since we do not have a username or password, we avoid trying to bruteforce our way in.
Instead, we try taking a look at the directories we’ve found from our initial webserver enumeration. Looking in the /includes directory, we find 2 files – auth.php and auth.php.swp.
We download the files for further examination. Since the webserver is configured to process php, the auth.php file doesn’t return any data that we are able to see. By running file against the auth.php.swp file, we learn that it’s a vim swap file, owned by user jennifer, and it’s path on the file system is /var/www/htdocs/includes (where auth.php is). Additionally, it says the host is openkeys.htb, so we add that to our /etc/hosts file.
Using vim to take a look at the swap file, we see that authentication is being done by a binary located at ../auth_helpers/check_auth. Next, we go to http://openkeys.htb/auth_helpers/check_auth to download the binary for further analysis. Running strings against the binary, we see something called “auth_userokay”.
Googling “openbsd auth_userokay”, we learn that it is a part of the BSD authentication system. Googling “openbsd authentication bypass”, we eventually find a whitepaper from Qualys that outlines a few vulnerabilities. Namely, CVE-2019-19521 basically says we can bypass authentication by supplying -schallenge as our username. Before we can attempt any type of exploit, we need to confirm how the username and password are being passed to the binary; as the login form is being processed by index.php and the authentication is within auth.php. Looking back at the swap file, we see that the username is begin accepted from the php $_REQUEST array, which means it can be set from GET or POST requests, as well as cookies.
When we try a dummy login to check how auth.php might be called, we see that a POST request forwards you to auth.php (can be confirmed via browser developer tools, or BurpSuite). Since GET and POST parameters do not naturally persist between page redirects, for ease of exploitability, we will opt to set the real username via a cookie. Since the form data only seems to be used for the authentication check, we will perform the exploit by setting the username to -schallenge.
By doing this, we successfully bypass the authentication, and are presented with jennifer‘s SSH private key. Next, we save it, and set the appropriate permissions on it. Having done so, we are able to SSH into the machine as jennifer and read user.txt.
Getting Root
Referring back to the whitepaper used to bypass the web authentication, we see another vulnerability for xlock – CVE-2019-19520. Checking the remote system, we see that it is installed.
Following the instruction, we exploit it to gain access to the auth group.
Continuing to follow the whitepaper, we learn that CVE-2019-19522 allows us to use our privilege of being in the auth group to get root privileges. Exploiting this, we obtain a root shell – reading root.txt.
Thank you for taking the time to read my write-up. I am interested in other ways this machine has been solved. Feel free to reach out to me and we can discuss it. Thanks!