OpenBSD Local Privesc and httpd authentication bypass

Insecure cookies and out-of-date operating systems make for a scary combination when it comes to preventing your site from data breaches and takeovers. In this POC report, we will prove a vulnerability that exists in the OpenBSD kernel version 6.6 for httpd services. The following exploits were found in CVE-2019-19520 and CVE-2019-19521.

HackTheBox OpenKeyS

OpenKeys is an intentionally-vulnerable server created by HackTheBox users polarbearer and GibParadox. In this report, we will expose this server for its out of date operating system and insecure cookie usage. Most users have stated that CVE vulnerabilities makeup the majority of its exploitation characteristics matrix with a close attention to enumeration. And with this information in front of us now, we will begin the attack.

Enumeration

Because we are aiming to breach OpenKeyS' security, we will first scan for any open ports on 10.10.10.199: the target's IP address. By doing this, we are attempting to devise any attack vectors for exploitation. Let's run a quick port scan using the following nmap command:

The following information about 10.10.10.199 is returned:

	Host is up (0.093s latency).
	Not shown: 664 filtered ports, 334 closed ports
	Some closed ports may be reported as filtered due to --defeat-rst-ratelimit
	PORT   STATE SERVICE
	22/tcp open  ssh
	80/tcp open  http

We likely will not have any luck trying to brute force port 22 at the moment, so we will move on to the more inviting option of the two: port 80. Enumeration on port 80 will begin with navigating to the IP address in a web browser. Since the server is open on port 80, we will automatically reach the website's landing page.

Our only visible components on this page are some typical login fields. My first speculation was potentially using the Forgot? button to find usernames or email addresses, but it is currently not functional. After trying a few common admin credentials, I started up BurpSuite to begin prodding further at the login fields.

Now with Burpsuite running and a proxy setup for Burp to intercept Firefox's browsing activity, we will try logging in with a set of common credentials again in order to get a better idea of what is happening behind the scenes. Here is the intercepted header picked up by Burp:

Nothing is out of the ordinary here in terms of security flaws, but this may be useful information to have on-hand later on.

Security Flaw #1 - Accessible Directories

Further prodding with the login field does not lead to anything new. It would be best to continue enumeration in another section of the server. Passive directory tracing from Burp reveals the following directories in use, but a peak inside each directory for interesting content does not reveal anything new either. In order to go deeper to find potential vulnerabilities, we can execute the following nmap command for finding vulns in basic ports:

This returns crucial information for exploitation:

	Nmap scan report for 10.10.10.199
	Host is up (0.089s latency).

	PORT   STATE SERVICE VERSION
	22/tcp open  ssh     OpenSSH 8.1 (protocol 2.0)
	|_clamav-exec: ERROR: Script execution failed (use -d to debug)
	| vulners:
	|   cpe:/a:openbsd:openssh:8.1:
	|     	CVE-2020-15778	6.8	https://vulners.com/cve/CVE-2020-15778
	|_    	CVE-2020-14145	4.3	https://vulners.com/cve/CVE-2020-14145
	80/tcp open  http    OpenBSD httpd
	|_clamav-exec: ERROR: Script execution failed (use -d to debug)
	|_http-csrf: Couldn't find any CSRF vulnerabilities.
	|_http-dombased-xss: Couldn't find any DOM based XSS.
	| http-enum:
	|   /css/: Potentially interesting folder w/ directory listing
	|   /images/: Potentially interesting folder w/ directory listing
	|   /includes/: Potentially interesting folder w/ directory listing
	|   /js/: Potentially interesting folder w/ directory listing
	|_  /vendor/: Potentially interesting folder w/ directory listing
	|_http-stored-xss: Couldn't find any stored XSS vulnerabilities.
	|_http-vuln-cve2017-1001000: ERROR: Script execution failed (use -d to debug)

The CVEs that are listed in association with SSH aren't able to help us at the moment, but we do have a new directory in our knowledge base that was not spotted during the passive directory scan: /includes.

We can navigate to the /includes folder on the server by going to 10.10.10.199/includes. The path brings us to this file tree page:

Files with these names make it obvious that the /includes folder should not publicly accessible to anyone directory-busting the site.

• Auth.php is not an accessible file.
• Auth.php.swp is readable. Below is a printout of the file.

An interesting bit in this php file is within the first couple of strings: jenniferopenkeys.htb. There are a few possibilities for what this could mean. We could either have another hidden directory on our hands or a user to authenticate with. In both ways, we will be entering the foothold phase of the attack

The Foothold

No other hidden directory synonymous to jennifer was located, so it is clear that jennifer is most likely a user that has an account with the system. Further enumeration of the OpenBSD httpd service on port 80 reveals a few security vulnerabilities found from this Openwall case study. The study has found that there exists an authentication bypass vulnerability found in OpenBSD that can be exploited by using -schallenge as the account's username. A more in-depth description of the hole is elaborated below in a statement from Qualys Security Advisory:

This is the first piece of the puzzle: if an attacker specifies a
username of the form "-option", they can influence the behavior of the
authentication program in unexpected ways.
From the manual page of login_passwd:
------------------------------------------------------------------------------
     login_passwd [-s service] [-v wheel=yes|no] [-v lastchance=yes|no] user
                  [class]
     ...
     The service argument specifies which protocol to use with the invoking
     program.  The allowed protocols are login, challenge, and response.  (The
     challenge protocol is silently ignored but will report success as passwd-
     style authentication is not challenge-response based).
------------------------------------------------------------------------------
	This is the second piece of the puzzle: if an attacker specifies the
username "-schallenge" (or "-schallenge:passwd" to force a passwd-style
authentication), then the authentication is automatically successful and
therefore bypassed.

Our current port scan of the server did not reveal to us any operating system version number, so we will see if it is vulnerable to this exploit to gain a better understanding of the current version.

Back at the login screen, let's use -schallenge as the account username and pass for the password. This time, we get a new login error:

This is good and bad news. We have gained account access to a user named -schallenge, but as expected, this user does not exist on the system. However, we can try changing the user we login as with the same authenticated credentials through a cookie interception.

In our web browser, let's go back to the login page with the fields already filled out with -schallenge : pass. In Burp, we will prepare to intercept the cookie being sent to the site.

With Burp running and ready to intercept the transmission, login with the server. The following is what Burp catches:

Before forwarding the packet, modify line number 13 to include ; username=jennifer at the end of the line. The semicolon will escape the PHPSESSID cookie and provide a username to authenticate as. After our modification, it should be

Now forward the packet. We have successfully authenticated as user jennifer and obtained access to her private ssh key

User Access

After obtaining user jennifer's private key, write the key contents into a file named private_key.txt from BEGIN OPENSSH PRIVATE KEY to END OPENSSH PRIVATE KEY inclusive. Move this file into the /root/.ssh directory and change its permissions so that it is only accessible by a root user.

SSH into the user shell using

The private key was used as an ID and we have successfully gained user access into the OpenBSD system.

Privilege Escalation

The next step in this exploit path is to enumerate for attack vectors in gaining administrative access. Let's run a few commands to determine some more information about our remote system.

• We are logged in as a user named jennifer.
• We have a fourth attribute to our ID under the group, wheel.
• Our operating system is running on OpenBSD 6.6 64-bit.

A quick Google search reveals that there are a few ways to achieve local privilege escalation on our remote kernel version. One in particular occurs due to a failed check in xlock and currently has a github proof of concept shell script at this page.

On the remote server, navigate to jennifer's home directory and copy the github POC script into an sh file. Make it executable using chmod, then run the script.

Turns out we have run into a speed bump due to a directory write error. It appears that the script is attempting to create a file in the /tmp directory but is being prevented by the OS. Let's see if changing our current directory works when running the script. This time, we will move the POC script into /tmp and run it with the same commands.

While the script is running, we arrive at a prompt that asks for password, and from the password that we were given two lines above the prompt, we enter it as-is.

OpenBSD 6.6 has been successfully rooted.

Takeaways

Public knowledge of exploits like these typically arise right before an OS's team release a crucial security patch. It is our responsibility as administrators and users alike to ensure our systems are always up to date to curtail any form of exploitation.