The Hex Factor blog: Solutions: The Hex Factor v2010 (Level B300)

Good day my dearest readers!

Please find below a description of the B300 v2010 solution! If anything is not clear, please don't hesitate to drop a mail to erik.van.buggenhout@thehexfactor.org!

You can find a step-by-step guide below and there is also a full movie clip at the bottom of the page!

Enjoy!

--------------------------------------------------

So... The Royal Bank of Ireland has returned. Apparently, this year they have managed to increase the security posture of their web application... So let's have a look! First of all, we start by pushing all traffic through a web application proxy such as BurpSuite. This allows us to easily intercept and tamper any parameters and pages sent between my browser and the web app server.

When first having a look at the web application it does seem to have been improved: The vulnerabilities identified in 2009 seem to have been fixed and a WAF (or something alike) has been implemented that is denying requests containing XSS or SQL Injection payloads.

However, when further browsing the application, we can see that a PDF has been published under Publications. In this PDF (which does not contain any suspicious payloads :P), we can find some interesting metadata (author = i89054):

Now, let's have a look at what services are running on the WAF:

There seems to be an SSH service running on port 22... This looks interesting, no? Let's try a dictionary attack with the identified user account (i89054). We opted to use Hydra and used the wordlist included in John The Ripper:

We can use this password to access the proxy server with a limited privileges user account. After doing some analysis on the compromised host, we can find the /etc/apache2/httpd.conf file. This configuration file shows us the IP address of the internal web server:

Now let’s abuse our SSH configuration in order to tunnel HTTP traffic through the SSH session, over the reverse proxy to the web application (which is at 192.168.62.136). On Linux, this can be achieved by opening the SSH session as following:

ssh -L 8090:192.168.62.136:80 i89054@192.168.1.105

When we now browse to our local IP address on port 8090, our traffic is being tunnelled through the SSH session over the WAF (thus bypassing the ModSecurity) towards the internal web server port 80. This can be verified by again submitting some XSS payloads in user input parameters:

When we now abuse our found credentials (i89054 – letmein) on the application, we have some more functionalities that become visible. When doing some basic input validation checks on this one, we can easily identify a blind SQL injection vulnerability in the backup functionality:

We now gear up SQLNinja (sorry Windows h4x0rs, there's no SQLNinja release for Linux) in order to exploit the identified SQL Injection vulnerability. The following should be configured in the sqlninja.conf file to perform successful exploitation. Please remember, we're targetting our local machine and port (that are being forwarded through the SSH tunnel.

host = 127.0.0.1 //Configure your host
port = 8090 //Configure port
method = GET //Configure HTTP method
page = /admin/popup.php //Configure vulnerable page
stringstart = id=backup’; //Configure vulnerable parameter

Attention, seeing as we need to have admin privileges to access the page, we need to also input the “Cookie” sessionid in between the --headers_start-- and --headers_end -- lines:

Cookie: PHPSESSID=7f20q7qkg8pnkfue0c286n2a7

Please note that the cookie value is different for each session (thank god :p), so you’ll have to find out yours on your own. This can be easily achieved by analyzing the traffic in BurpSuite:

Now, let’s test our injection with SQLNinja:

Now we know SQLNinja is up and running, let's try to do some damage... One of the ideas would be to create a user account on the remote machine. This can be done by issuing a "blind OS" command:

So now we have added the user thf with password thf to the remote database server. It would be nice to have a more graphic control interface to pwn the box. Let's try our SSH tunneling trick again, but now let's try forwarding to port 3389 (remote desktop):

ssh -L 3390:192.168.62.136:3389 i89054@192.168.1.105

I'm forwarding my local traffic on 3390 to the database server port 3389. Let's try opening up our Remote Desktop and logging in with our thf-thf set of credentials:

Hmm, this doesn't seem to be working... While it does validate our credentials, we don't seem to have the necessary user rights to log on to the machine. Let's try adding ourselves to the Local Admin group, by abusing our SQL Injection one more time: