# PoliCTF 2015: John the Referee

Wow, it’s been a long time since my last writeup, during this weekend me and my friends at the vulnhub-ctf team took part in the PoliCTF and here is my writeup about this nice web challenge, make sure to read all our writeups at our VulnHub-CTF Team Blog

John the referee was a 150 points web challenge with some crypto added to the recipe :)

The web application looked like a shop selling different types of tshirts and our objective was to discover an hidden item in the shop.

The search function looked interesting, because once a search string was submitted, the user was redirected to a search result page having an URL similar to the following:

http://referee.polictf.it/search-result/e25fc408c9ac78c3fb02ff08ece71f1b4182747916789ca739281400a7a33cca


Obviously trying to perform a basic SQL injection attack revealed that the input from the search form was sanitized.

But let’s get back to the search result page. From a first look the last part of the URL looked like an hash (a sha256), but messing around with the search form, and submitting longer search keywords, we could notice that the hexdecimal string was expanding by 32 characters (16 bytes) every 16 characters in the search string.

This suggested that instead of an hash, it was most likely a block cipher encoded text, and chances that it was containing our search string were quite high.

Also by searching the same string multiple time, the encrypted string in the URL was different every time, and this meant that an initialization vector was used.

Putting all the things togeder, from what we knew the URL hex encoded string was most likely an AES256 CBC encrypted version of our search keyword.

This meant that if we could manipulate the content of the encrypted text directly from the URL, we could probably bypass the sanitization and perform a SQL injection on the backend database.

There are two types of attacks that are especially effective against block ciphers encrypted data:

• bit flipping.

I spent quite a while attempting a padding oracle attack, but without any success, so i decided to try a bit flipping one.

A good search result page looked like the one from the above picture, this suggested that probably a union select injection would be effective

The only sanitized characters were \ ‘ “ and a few others, so i decided to submit the following search string from the search page

& union select 1,2,3,4 ;#--


and start messing with the search result ciphertext

Soon enaugh we had a working injection :)

From there on, i continued with some standard enumeration techniques to determine the database and the table name; fairly long and tedious part, i really wanted to prevent the usage of banned characters in the query, and therefore i couldn’t use any where clause.

Still at the end i figured out that the database name was johnthereferee and the table name was uniforms.

at that point running the following query returned the flag.