John Hammond | Sunday, January 27th, 2017
Tags: #Web
Unfortunately, Animesh, even after repetitive efforts, could not get the final invitation to his friend Saumya's birthday party. But Animesh did not stop here. He came to know from Anjali (who is attending Saumya's birthday party) that there is a wild card entry in the party, but the key required for that is not known by anyone except Saumya. Now interestingly Saumya had kept the details of people coming to the party in a database. Now Animesh tries his luck for the last time to get the 'wild card key' required for the birthday party. Can you help Animesh in his last attempt? It is known that Saumya usually checks the details of people coming to the party from: here
I really liked this challenge; it was some fun SQL injection and had an interesting trick with PHP.
When you get to the page linked to in the challenge prompt, it's just a simple text input field. Apparently this lets you query the database, and you can seemingly search for people who are "going to the party." Really, you'll only see some results with the Anjali person.
Once I had results and could see that I really was interacting with the database, I tried to play with some SQL injection.
I did the usual:
Anjali' OR '1'='1
... but that got no result. Desperate, I tried to again with double quotes:
Anjali" OR "1"="1
.... and we got it, that dumped everything.
There was nothing in that table that was particularly interesting, so I poked a bit more to see how I could craft my SQL injection. I started to see what kind of syntax was used for comments. I did more manual tests with this.
" OR "1"="1" --
... Nothing.
" OR "1"="1" #
Aha! That worked, that dropped everything again. Okay, good, enough reconnaissance to figure out the comment style # and now we can fill out our injection more and more. Next, I wanted to know the number fields that were being returned.
I did this with some classic UNION SELECT testing.
" UNION SELECT 1 #
...
" UNION SELECT 1, 2 #
...
" UNION SELECT 1, 2, 3, 4, 5 #
Eventually I found that 5 fields would return values. That makes sense, considering we got five values earlier when we got real information returned from the database.
Now we can start to leak some valuable things, since we can see the output of our queries.
A while back I put together my own personal "SQL injection cheatsheet", and I used that heavily to leak information out of this database.
After long enough time of testing, I found another database called credentials, that had fields like username, password, and linktourl.
I leaked those out like so:
" UNION SELECT (SELECT GROUP_CONCAT( password ) FROM credentials), 2, 3, 4, 5 #
_Note that I did not use quotes here! That is what gave me the success for this query. I was able to use quotes for all the previous queries. You can use that same kind of style for all the other queries (wrap other SELECT statements inside of parentheses).
Eventually, I got the following information: I had a root account with the password a64ff1355b8b40f76bc265659eaf680e, and a URL https://felicity.iiit.ac.in/contest/extra/phpmyadmin/.
This link was to a phpMyAdmin login portal. Assumingly, I could use this root user and his credentials to log in, but that apparently had no success.
After some tinkering, though, I noticed this error was different than the usual. Other errors (with accounts that didn't exist) would give a legitimate MySQL error and it would be displayed at both the top and bottom of the login form.
After some banging my head against the wall (for quite a long time) and searching for phpMyAdmin bypass vulnerabilities (for quite a long time) I realized that, yeah, the PHP was seemingly filtering out the root username. Even if the wrong password were supplied for that account, I would get the same Access Denied! error... like it was purposely finding the username and acting against it.
So, I tried to trick it. Since it is just PHP handling the log in, I tacked on a null-byte at the end of the username. That way, it would be entered as root%00 and PHP would really let it login as root.
The %00 is a URL-encoded null byte. It means nothing; but PHP will buy it.
I had to enter this with a proxy (you can't enter it just as text in the form entry field!) like TamperData.
Then, we got in.
After some hunting in the "Browse" tab and the useful_info database, you can find a get_flag option.
The flag was: 07f663cbd03849d23e177a9348058722