Solving each and every fb-ctf challenge PART 1

Write-up of all the challenges which were in fb-ctf web category

Okay, before beginning, let me admit my fault, I totally forgot about fb-ctf after coming home on 26th May, and when I found the note, it was too late.

Still, I could’ve pulled out some challenges but unfortunately I had my GSoC internal submission on 2nd — 4th June.

Sad.

Yeah, so I completed it between 5th —8th June, but hey, I connected to the IRC chat (#fb-ctf) on 1st and occasionally read the chats, it was fun!

No, I found it funny as well :P

It was again a jeopardy styled CTF with dynamic scoring policy, meaning pts ‘automatically’ get adjusted according to “number of solves” parameter.

Some people said that it was harder than the common ones and I found this to be true.

Let the hacking begin

From The Social Network

Web :: product manager

Description

Description

Solution

We had the luxury of viewing the source-code for this challenge.

db.php

We can see the comments, and it hints about where the flag is. It means we somehow need to access the description value of the facebook element.

db.php

On further inspection of db.php , it seems SQL Injection isn’t an option due to correct preparation of the SQL statements.

Vulnerability

The check_name_secret checks that a product exists with the entered name and secret combination. However, the get_product function only returns an element from the database by using the name parameter!

This means we can add another element called facebook with a secret we know and get the program to return the first product found with the name facebook i.e. the one with the flag!

It throws an error that name already exists. Shit!

After 4–5 hours of searching, reading about MySQL, I got to know about SQL Truncation Attack (ref-1 | ref-2)

Actually, this is an issue with MySQL. MySQL doesn’t compare strings in binary mode. By default, more relaxed comparison rules are used.

Taking a quote from the documentation:

All MySQL collations are of type PADSPACE.

This means that all CHAR, VARCHAR, and TEXT

values in MySQL are compared without regard

to any trailing spaces.

This results in the MySQL statement treating "facebook " the same as "facebook"

Exploit!

The password is desc itself