OpenKeyS is an OpenBSD box that features CVE 2019-19521 as an vulnerability that allows you to gain access to user and ultimately root.
Enumeration
We start off with an NMAP scan we can see that there are two open ports. 22 for SSH and 80 for OpenBSD httpd.
Nmap scan report for 10.10.10.199
Host is up (0.079s latency).
Not shown: 998 closed ports
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).
We decided to take a look at the web server first since we don’t have credentials and bruteforcing especially blind isn’t usually the path on HTB.
We open port 80 in a web browser and find by logging we will apparently be given ssh keys. That is very convenient.
However we don’t have credentials and as mentioned before, it is unlikely that we would need to bruteforce this. There is likely something else we can leverage.
We fire up ffuf and find a number of directories.
/'___\ /'___\ /'___\
/\ \__/ /\ \__/ __ __ /\ \__/
\ \ ,__\\ \ ,__\/\ \/\ \ \ \ ,__\
\ \ \_/ \ \ \_/\ \ \_\ \ \ \ \_/
\ \_\ \ \_\ \ \____/ \ \_\
\/_/ \/_/ \/___/ \/_/
v1.0.2
________________________________________________
:: Method : GET
:: URL : http://10.10.10.199/FUZZ/
:: Follow redirects : false
:: Calibration : false
:: Timeout : 10
:: Threads : 40
:: Matcher : Response status: 200,204,301,302,307,401,403
________________________________________________
images [Status: 200, Size: 589, Words: 160, Lines: 22]
css [Status: 200, Size: 697, Words: 215, Lines: 23]
includes [Status: 200, Size: 711, Words: 211, Lines: 23]
js [Status: 200, Size: 582, Words: 156, Lines: 22]
vendor [Status: 200, Size: 1522, Words: 635, Lines: 30]
fonts [Status: 200, Size: 1066, Words: 385, Lines: 26]
[Status: 200, Size: 96, Words: 13, Lines: 7]
At this point, I got stuck for longer than I care to admit. I felt like the next step had to be right in front of my face about to bite my noes off and I was right.
Eventually I checked out /includes We instantly found some lovely files. auth.php which we is blank if we attempt to read and auth.php.swp Which is not.
http://10.10.10.199/includes/auth.php.swp
b0VIM 8.1�-�^���jenniferopenkeys.htb/var/www/htdocs/includes/auth.php 3210#"! Utp=ad� � =����sWB@?" �������mgC� � � { a W J @ � � � � � � � v p n m U S 0 � � � J � � � � � � � � � � � ?>} session_start(); session_destroy(); session_unset();{function close_session()} $_SESSION["username"] = $_REQUEST['username']; $_SESSION["user_agent"] = $_SERVER['HTTP_USER_AGENT']; $_SESSION["remote_addr"] = $_SERVER['REMOTE_ADDR']; $_SESSION["last_activity"] = $_SERVER['REQUEST_TIME']; $_SESSION["login_time"] = $_SERVER['REQUEST_TIME']; $_SESSION["logged_in"] = True;{function init_session()} } return False; { else } } return True; $_SESSION['last_activity'] = $time; // Session is active, update last activity time and return True { else } return False; close_session(); { ($time - $_SESSION['last_activity']) > $session_timeout) if (isset($_SESSION['last_activity']) && $time = $_SERVER['REQUEST_TIME']; // Has the session expired? { if(isset($_SESSION["logged_in"])) // Is the user logged in? session_start(); // Start the session $session_timeout = 300; // Session timeout in seconds{function is_active_session()} return $retcode; system($cmd, $retcode); $cmd = escapeshellcmd("../auth_helpers/check_auth " . $username . " " . $password);{function authenticate($username, $password)
As you can see it isn’t very friendly to read but we do find some very useful info. We now have a username, jennifer. There is also a reverence to another file, ../auth_helpers/check_auth Point our browser at that page and we receive an elf exactable. Based of /includes/auth.php.swp it would see to be used to check the authentication for users logging in on the web page.
This is where we find a rabbit hole. We can spend a ton of time reverseing this binary but it isn’t going to gain us much. What we need can be found with a simple strings.
/usr/libexec/ld.so
OpenBSD
libc.so.95.1
_csu_finish
exit
_Jv_RegisterClasses
atexit
auth_userokay
_end
AWAVAUATSH
t-E1
t7E1
ASAWAVAT
A\A^A_A[]
ASAWAVP
A^A_A[]L3
Linker: LLD 8.0.1
.interp
.note.openbsd.ident
.dynsym
.gnu.hash
.hash
.dynstr
.rela.dyn
.rela.plt
.eh_frame_hdr
.eh_frame
...
Right at the top we find a reference to a specific version of libc. If we google along the lines of libc.so.95.1 exploit we find reference to CVE 2019-19521. An extremely crazy bug for openbsd that allows for authentication bypass. That sounds pretty useful doesn’t it?
https://n3x0.com/2019/12/05/severe-auth-bypass-and-priv-esc-vulnerabilities-disclosed-in-openbsd/
The above is a blog that discusses the vulnerability in more depth. Essentially, there is a flaw in how OpenBSD authentication works. When -schallenge is supplied for a username it is parsed as a command line option and further authentication is not requested.
Remember how an elf binary is responsible for authentication the website? That is probably vulnerable. We give it a enter -schallenge and passwd (or whatever else you want for a password) and then attempt to login…
And we end up at /sshkey.php! Oh rats. There is no ssh key for user -schallenge :P
User.txt
Fortunately for us there is more than one way to provide input to the web application. Checking back to /includes/auth.php.swp we find that there can be a username cookie set.
So we attempt to login again this time modifying our request with burp to include username=jennifer in the cookie field
We are then greeted with a beautiful sight, Jennifer’s Private ssh key.
We copy that over to a file on are machine. modify permissions so it will be accepted by ssh. chmod 600 jen_key and then attempt to ssh into the machine. Our key is accepted and we land in Jennifer’s home directory right next to the user flag.
Root
The fun part is that the same vulnerability that allowed us to login will also allow us to privilege escalate to root. We can’t just use su though it is vulnerable it causes a segfault so no dice.
Worth a shot though right?
This article goes through some more specific examples of the vulnerability. https://www.openwall.com/lists/oss-security/2019/12/04/5 One of which is a privilege escalation. I attempted to pull it of manually following the article but wasn’t sucessful. I was instead able to find a script on github that was based on the code and this one worked
https://github.com/bcoles/local-exploits/blob/master/CVE-2019-19520/openbsd-authroot
It take two steps. First we leverage xlock, a binary that locks the local display until a password is entered, to join the auth user group. From there the exploit creates and Skey which is used for onetime authentication. The way this interacts with su is different. Su can then be run using the skey for authentication and it does not call a segfault.
Change directory to root, snag the flag and we are done with this machine!
Wrap Up
This was a very fun box thanks to polarbearer & GibParadox for creating it. Also thanks to Pop_eax & Szymex73 for nudging me when I was blind.