Nov 7, 2016 - Hack The Vote 2016 : Sander's Fan Club

Author: dade

Publish Date: 2016-11-07

Category: Web Points: 100 Description:

Those deplorable Sanders supporters are still fighting. Shut the site down by finding where the idiot stored his credentials.


Visiting the site, we’re presented with a pretty basic bootstrap site praising Bernie Sanders. Reading the content in the jumbotron suggets that the credentials were left laying around somewhere, and that it only works in Firefox. I was stubborn and thought this might be a red herring so continued to work in Chrome.

I fired up Fiddler and noticed that on every request, flag2.jpg is being sent in the HTTP Link: header and that it’s set to rel=stylesheet. Unfortunately, however, I don’t see any CSS in the body of what Fiddler sees. Okay, let’s see what Firefox has to offer.

Visiting the page in Firefox, I can see that there are very clearly different styles being applied, so I open up the firefox inspector (right click -> Inspect Element) and start looking at the styles. Unfortunately I don’t see anything other than rules from bootstrap.min.css:5 so let’s head to the network tab and see what happens when I refresh.

I notice right away that there are two GET requests for flag2.jpg but one is only 2.18KB. Looking at the headers between these two requests, it seems that in the first request we have Accept: "text/css,*/*;q=0.1" whereas in the second request we only have Accept: "*/*". If we take a look at the response, we’ll in fact see that the first request has valid CSS rules whereas the second request doesn’t. At the bottom of these CSS rules we see:

 * How did I... Nevermind. I'm pretty sure my creds are in a text file


So when we tell the web server that we want flag2.jpg and that we except it to be text/css, it seems to behave differently than if we don’t expect it to be text/css. And we know that the creds are in a text file, so let’s tweak the Accept header and see what happens. This can be achieved easily by right clicking on the flag2.jpg request and choosing “Edit and resend”.

User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0
Accept: text/plain,*/*;q=0.1
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache

Why it was vulnerable

I’m leaving this section here, as if there is some lesson to be learned, but to be honest I’ve never seen this before and I highly doubt it would ever be found in the wild. In reality, it seems like it’s just abusing the RFC.


Password reminder: flag{I_am_very_bad_with_computers}
(Go tell chrome devs to support RFC 5988 
Firefox masterrace)

Aug 19, 2016 - Icectf 2016 : RSA?

Author: dade

Publish Date: 2016-08-19

Category: Cryptography Points: 50 Description:

John was messing with RSA again… he encrypted our flag! I have a strong feeling he had no idea what he was doing however, can you get the flag for us? flag.txt


The file we’re provided lists N, E, and C. The thing that stands out the most is that E is only 0x01. Low values of E are frowned upon, but this one takes it to a new level.


In RSA, when e is 0x01, we can simply convert the hex value we’re given for the ciphertext (c) to ascii and get the flag.



Jun 8, 2016 - backdoorctf16 : Busybee

Author: dade

Publish Date: 2016-06-08

Category: Forensics Points: 150 Description:

A deadly virus is killing bees in Busybee’s village Busybox, India. Unfortuantely, you have to go to the village to fight the infection. Get the flag virus out of the infected files.
Village address:
Created by: Ashish Chaudhary


Let’s unpack our infected.tar and take a look around

drwxr-xr-x  3 dade dade 4096 Jun  4 12:50 2b0fbc0e1ac044737fd881cff8164bb5a2c7bfbf90c40c87de3c3435f2c6a94e
drwxr-xr-x  4 dade dade 4096 Jun  4 12:53 983179bdb58ea980ec1fe7c45f63571d49b140bdd629f234be9c00a6edd8a4a7
drwxr-xr-x 10 dade dade 4096 Jun  4 12:51 d51a083a3b01fe8c58086903595b91fc975de59a9e9ececec755df384a181026
-rw-r--r--  1 dade dade 1344 Jun  3 09:13 eaa21323de5e2cce7078df3af4dd292181114dfc94be761b948657efbe3af26b.json
-rw-r--r--  1 dade dade  373 Dec 31  1969 manifest.json
-rw-r--r--  1 dade dade  106 Dec 31  1969 repositories

The json files don’t really have much interesting in them, looks primarily like data from building the problem. Lets dig in to 2b0fbc0e…

dade@gibson:~$ ls -la infected/2b0fbc0e1ac044737fd881cff8164bb5a2c7bfbf90c40c87de3c3435f2c6a94e
-rw-r--r-- 1 dade dade  464 Jun  3 09:13 json
-rw-r--r-- 1 dade dade 1024 Jun  3 09:13 layer.tar
-rw-r--r-- 1 dade dade    3 Jun  3 09:13 VERSION

file layer.tar says “data” and tar xvf layer.tar is unable to get anything. xxd layer.tar shows us that the data is all 0s. Nothing of interest in json or VERSION

Let’s move on to 983179bd…

-rw-r--r-- 1 dade dade     907 Jun  3 09:13 json
-rw-r--r-- 1 dade dade 1035776 Jun  3 09:13 layer.tar
-rw-r--r-- 1 dade dade       3 Jun  3 09:13 VERSION

json and VERSION are probably still not particularly helpful for us, but lets unpack this layer.tar

dade@gibson:~/infected/983179bdb58ea980ec1fe7c45f63571d49b140bdd629f234be9c00a6edd8a4a7$ tar xvf layer.tar 

.ash_history looks like a shell history file, let’s see if anything interesting is in there.

dade@gibson:~/infected/983179bdb58ea980ec1fe7c45f63571d49b140bdd629f234be9c00a6edd8a4a7$ cat root/.ash_history
not so easy bru - the infections is intense


Hmm. This tarball also had two binaries in it. Let’s see if there is a reason those binaries specifically were included by checking them out with strings. Given the premise of the challenge, that the flag had “infected” files by a “virus”, binaries are a common target to hide in.

dade@gibson:~/infected/983179bdb58ea980ec1fe7c45f63571d49b140bdd629f234be9c00a6edd8a4a7$ strings bin/sha1sum 

Well that was easy, the virus flag was in the infected binaries. Just sha256 that string and submit.


This challenge is hosted permanently at Backdoor, so go find the flag yourself!