OpenKeys HTB

Updated:November 3, 2021 pm

  • Openkeys was a medium level openbsd machine. At first we are presented with a web application which we bypass the login using a vulnerablity on how openbsd handles the authentication. After we get an ssh key which we use to ssh into the box. At the end we use 2 openbsd vulnerabilities to gain root access.


# Nmap 7.80 scan initiated Tue Sep 22 08:39:23 2020 as: nmap -sC -sV -oN openkeys
Nmap scan report for (
Host is up (0.093s latency).
Not shown: 998 closed ports
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 .
# Nmap done at Tue Sep 22 08:39:50 2020 -- 1 IP address (1 host up) scanned in 27.47 seconds

As Shown Nmap gives us the most common ports we see on hackthebox machines, 22(ssh) and 80(http).


Upong visiting this port I see a web page with a login form. Because I don’t have much info at the moment I won’t do any brute force against it. But I try the common ones like admin:admin, admin:password unfortunately none of these works.


My next step now is to do a directory brute forcing using ffuf.

ffuf -w /usr/share/wordlists/SecLists/Discovery/Web-Content/raft-medium-directories.txt -u

images                  [Status: 301, Size: 443, Words: 33, Lines: 18]
includes                [Status: 301, Size: 443, Words: 33, Lines: 18]
js                      [Status: 301, Size: 443, Words: 33, Lines: 18]
css                     [Status: 301, Size: 443, Words: 33, Lines: 18]

All the directies seem normal except the includes which has two files inside of it.


We can read only the second file because the first has .php extension and our browser does not show php code on the client side. On the other hand auth.php.swp is a vim swap file. We can download this file and open it with vim -r and see it’s content. We can see how the login works. By opening the file on the browser we get a hostname which we add to our /etc/hosts file.


By viewing the file on our browser we get a hostname so I add it to my /etc/hosts file. When I visit jenniferopenkeys.htb I get the same page as before and nothing more. But jennifer may be a potential username, so I write that down.

After searching for some time I found a cve here. The CVE is using -schallenge for username to force a passwd-style authentication, then the authentication is automatically successful and therefore bypassed.At the website I enter -schallenge as username and something random as a password.


Indeed we did login but we have an error. The error OpenSSH key not found for user -schallenge. All I had to do to bypass this error was to add another cookie username=jennifer, because the application did fetch the username from that cookie(You can see this on the swap file on vim). Now I have the private ssh key of user jennifer. It came with no password protection.

kali@kali:/tmp$ ssh -i ssh.priv jennifer@
Last login: Fri Dec 11 22:16:47 2020 from
OpenBSD 6.6 (GENERIC) #353: Sat Oct 12 10:45:56 MDT 2019

Welcome to OpenBSD: The proactively secure Unix-like operating system.

Please use the sendbug(1) utility to report bugs in the system.
Before reporting a bug, please try to reproduce it with the latest
version of the code.  With bug reports, please try to ensure that
enough information to reproduce the problem is enclosed, and if a
known fix for it exists, include that as well.

openkeys$ whoami


Given that from the previous CVE there were some other ones related to the same version of openbsd using on this machine I give them a try and they indeed did work.

This time it was 2 vulnerabilites. One is CVE-2019-19520: Local privilege escalation via xlock and the other one is CVE-2019-19522: Local privilege escalation via S/Key and YubiKey.


This exploits a vulnerabilty which adds my user on the auth group.


Since I belong to auth group I can take advantage and use this to become root by adding an S/Key entry (a file in /etc/skey) for the user “root”. By using this bash script: it automatically exploits those two vulnerabilties hence giving us root access.


You can read more about the vulnerablities from this post