HTB - OpenKeyS

Overview

Short description to include any strange things to be dealt with

Useful Skills and Tools

Recover a file from a vim .swp file

  • vim -r file-to-recover.swp

Useful thing 2

  • description with generic example

Enumeration

Nmap scan

I started my enumeration with an nmap scan of 10.10.10.199. The options I regularly use are: -p-, which is a shortcut which tells nmap to scan all ports, -sC is the equivalent to --script=default and runs a collection of nmap enumeration scripts against the target, -sV does a service scan, and -oA <name> saves the output with a filename of <name>.

Only two ports open, 22 - SSH and 80 - HTTP

HTTP leads to login page

There wasn't anything to do with the login page so I ran gobuster on it, there was an /includes folder where I was able to download the files auth.php and auth.php.swp. Auth.php didn't have anything in it so I tried the .swp file instead.

Since I didn't know what it was, I opened the .swp file using vim and found a potential username jennifer, along with a file directory for auth.php and the hostname openkeys.htb. Doing a little bit of research showed me that a .swp file was a vim recovery file. I also found that I could get the file contents back using the directions from: https://superuser.com/questions/204209/how-can-i-recover-the-original-file-from-a-swp-file

Using the -r flag for vim I was able to recover the file /var/www/htdocs/includes/auth.php from the .swp file.

The authenticate() function stuck out to me since it pointed to a directory I hadn't found yet. escapeshellcmd? ../auth_helpers/check_auth

By navigating to the path http://10.10.10.199/../auth_helpers/check_auth I was able to download the check_auth program. [Ignore the fact that it looks like this is on the /includes page, when it loaded the file to download there was no HTML to display.]

googled /usr/libexec/ld.so - https://man.netbsd.org/libexec/ld.so.1

found exploit for this file on openbsd - https://www.exploit-db.com/exploits/47780

yields full root privileges.

Will have to remember this one when I gain access to the machine

OpenBSD, /usr/libexec/ld.so, libc.so.95.1 looked like places to start investigating

https://blog.firosolutions.com/exploits/cve-2019-19521-openbsd-libc-2019/

https://packetstormsecurity.com/files/155572/Qualys-Security-Advisory-OpenBSD-Authentication-Bypass-Privilege-Escalation.html

So the system seemed like it was vulnerable, but I was still not sure how to exploit this to gain access

Road to User

Finding user creds

CVE-2019-19521: Authentication bypass

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.

After logging in with the username and password -schallenge I got this page. sshkey.php sounded very interesting.

Since it did not like this username, I tried different methods of specifying another username. The only possibility I had at this time was jennifer (and this still felt like a stretch since I had only seen it in the header of that swap file...)

Putting the username in the cookie seemed like a good bet, and logging in with the bypass and doing this gave me a redirect on the login page

After getting a valid logged in PHP session ID, I tried multiple ways of specifying the only username I had found. I was able to give the name in the cookie on the sshkey.php page and get a response back!

The service gave me an SSH key for the user jennifer!

It was easier to copy the key from the web browser since it didn't have the extra formatting.

Always use protection when reusing other people's keys.

Instead of telling me failed password attempt, the machine taunted me, saying "And you call yourself a Rocket Scientist!".

User.txt

jennifer had the user.txt flag in the user's folder

Path to Power (Gaining Administrator Access)

Enumeration as `jennifer`

The file dead-letter contained a message that looked like a notification to the admin that someone (jennifer) had tried to use sudo and failed due to not being in the sudoers file.

In the /etc/sudoers file there was an interesting entry that let www run the skey_gen command as jennifer; too bad the wheel group was commented out...since this would have let me privesc

Getting a shell

Version is OpenBSD 6.6 x64

searching for root exploit for this led to https://github.com/bcoles/local-exploits/blob/master/CVE-2019-19520/openbsd-authroot

The exploit was a shell script that I wrote to a file. It didn't seem to need any configuring so I ran it to see what it would do.

How this exploit works:

The relevant lines are:

Can use BSD's skey to login.

https://man.openbsd.org/skey.1 S/Key is a procedure for using one-time passwords to authenticate access to computer systems. It uses 64 bits of information transformed by the MD5, RIPEMD-160, or SHA1 algorithms. The user supplies the 64 bits in the form of 6 English words that are generated by a secure computer. This implementation of S/Key is RFC 2289 compliant.

Before using skey the system needs to be initialized using skeyinit(1); this will establish a secret passphrase. After that, one-time passwords can be generated using skey, which will prompt for the secret passphrase. After a one-time password has been used to log in, it can no longer be used.

When skey is invoked as otp-method, skey will use method as the hash function where method is currently one of md5, rmd160, or sha1.

If you misspell your secret passphrase while running skey, you will get a list of one-time passwords that will not work, and no indication of the problem.

Password sequence numbers count backwards. You can enter the passwords using small letters, even though skey prints them capitalized.

After verifying the type of authentication, then deleting and recreating the skey auth key, the exploit su's to UID 0 (root) using skey as the authentication method.

Root.txt

I had to enter the password the system had given me EGG LARD GROW HOG DRAG LAIN. After that I was given a root shell.

There was no /etc/shadow file, and the passwords were not stored in /etc/passwd. I will need to look up where OpenBSD stores it's password hashes at some point...

Thanks to polarbearer & GibParadoxfor something interesting or useful about this machine.

If you like this content and would like to see more, please consider buying me a coffee!

PreviousHTB - SneakyMailerNextHTB - Jewel

Last updated

Was this helpful?