Thursday, February 27, 2014

Codegate CTF 2014 - Weirdshark - Forensics 150 Write-up

Here is our file :

Upon trying to open with wireshark we got the error :
That was obvious.

Let's try opening with tcpdump to see what happens :

There is something wrong with the file.

Based on the error massage of wireshark we searched what EPB is.
It was the block that transmitted information lies in.According to wireshark's error we assumed there was something wrong with packet's epb headers but not the information itself.

To fix headers we used online pcap fixer : corrected the error that EPB data exceeds the packet length.

Opening the repaired file via wireshark caused another error:

It seems that fixer changed cap len to 64 but our packets' len is 62.So we filled the packets with 0s to achieve 64 bit packets.

Voila!We can read the packets with wireshark.

and here is the flag.

and here is the one of other files we extracted from pcap file.We think these guys are the builders of this challenge.

Tuesday, February 25, 2014

Codegate CTF 2014 - Web Proxy - Web 200 Write-up

In this challenge we were given a proxy and in the html source code
a commented line which states:
it was clear that we should get into that file when we tried to get it from outside
it gave an 403 forbidden error and when you try to get it from inside with exact link
it was giving Access Denied response. So we figure out that the proxy was
processing the url you requested and if it is containing one of the "php" or "//"
it was giving that Access Denied response so we requested the page with just
which should give the default index and it worked but the response wast trimmed
we could get just a few lines and we thought that there might be a vuln in
request that proxy making so i just put the and of the link a %0a which is \n
and ta-daa the headers were gone we got just the contents of the page something
went absolutely wrong. When i examined deeply i see that the proxy is working by
putting the url we requested directly into the request so:

GET "our_url" HTTP/1.1
Host: xxx
And other headers.

the get request was happening that way so i manipulated it by hand to use
Range header it allows us to seek to any wanted byte of the file so i gave an
url like

localhost/188f6594f694a3ca082f7530b5efc58dedf81b8d/admin/ HTTP/1.1%0d%0aHost:localhost%0d%0aRange:bytes=380-%0d%0a%0d%0a

and the output was checking if the host is "hackme" so i changed my host line
and rearrangen range field for new file to get the password like this:

localhost/188f6594f694a3ca082f7530b5efc58dedf81b8d/admin/ HTTP/1.1%0d%0aHost:hackme%0d%0aRange: bytes=70-%0d%0a%0d%0a

and ta-daa there is the password.

Codegate CTF 2014 - 120 Arrows - Web 500 Write-up

By seeing the code it was clear that we are going to make a blind sql injection attack.
The problem was the attack limit we only have 120 chance to get the password,
password was 30 characters long and it was containing all the lowercase letters
- which are 26. So in the worst case a linear attack should try 26*30 different
passwords which is far more than 120. Then the first thing coming into mind is to
try binary search on each character which should take 6 steps per character in
the worst case and in total 6*30=180 if we are lucky enough we can find the answer
in less than that so i give it a try and it worked. If i would be so unlucky
then i would convert each character to base 3 and look for each digit ,there can
be almost 3 digits to represnt 26 in base 3, so it would take 3*30=90 which would
be absolutely enough for the case. And there is our exploit:

Exploit - Web500