To solve this machine, we begin by enumerating exposed services – finding only ports
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
Like all machines, we begin by enumerating exposed services – finding only ports
$ 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)
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 –
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
auth.php is). Additionally, it says the host is
openkeys.htb, so we add that to our
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
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
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
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
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!