antiTree | posts and projects
posted on May 03, 2017

UPDATE: The source repository for all this code is hosted here:

Check out the previous 1, 2, 3 and 4 for the other CTF challenges.

Rebound Attack

Rebound Attack

I admit this this was the most complex one which is why it was worth 500. The idea is I want you to exploit yourself in very specific ways. This is adapting a research project from years ago where I fingerprint people based on the DNS requets they make. Here’s how it works:

  • I run a web server and custom DNS server
  • When you visit my webserver, I generate a UUID
  • The web server redirects you to a remote host named
  • On that page is various attacks like java, flash, javascript, etc. that all make remote calls to that hostname
  • My DNS server responds to that UUID and logs the IP that it came from
  • If in any case, your system leaks DNS requests, my DNS server will find it

It’s a demo of a de-anonmizing attack on Tor users in the case they are leaking their DNS via a script or standard web browser and how the Tor Browser Bundle which prevents these attacks.

Here was the clue:

You're in it now, there's no turning back
Lets see if there's skill in that black back pack
This app attacks macs, windows or *nix
But it's been mod'd with a few special tricks
A troll in the app gives you challenges 3:
Web, DNS, and WebRTC
If I see RIT IPs in all three
You'll never be able to recover the key
DNS, just be honest, but for Web stay anon
WebRTC, that's tricky. You'd better use Chrome.
Still confused. Don't give up. You'll eventually get it.
If it helps, there's 3 things: Flask, DNS, and Redis


At this point I assume everyone was sick of my poems but there were some important clues here. What I wanted was for you to leak your true DNS server, hide your IP, and disclose your private IP.

So it should have looked like:

  • Web: or some tor exit node
  • WebRTC: or some internal IP
  • DNS: or some RIT IP


The web test was simple. If you visit the web page using Tor, then you would get an IP that wasn’t from RIT’s network starting with 129.21.


This required a lot of testing on RIT’s network. What the web site was doing was using WebRTC to find your private IP. Your IP behind a NAT. But the assumption was that you were actually behind a NAT during the game. That means that you’d have to be on the RIT-GUEST WiFi which was behind a NAT because the normal WiFi gave you a public IP and the WebRTC test wouldn’t find an IP that started with 10., 172.16., or 192.168. Also, the WebRTC app that I wrote only worked in Chrome so you’d have to somehow configure Chrome to use Tor.


As I explained above, my custom DNS server was logging requests made to it and storing it in a Redis database. The web server was reading the database and correlating the traffic between the web session and the DNS request. The prefix of 01 or 02 were reference to the test I was performing but you don’t need to worry about that.

Here are some logs from BSidesROC:

Request (('', 56373)): ('01_7f3e4e2d-e6a4-467e-9aca-6b979a16cc59', 'hax', 'antitree', 'com') (A) - Response:
Wrong fucking query type
Request dropped from for
Existing record found for 7f3e4e2d-e6a4-467e-9aca-6b979a16cc59
Request (('', 54130)): ('01_7f3e4e2d-e6a4-467e-9aca-6b979a16cc59', 'hax', 'antitree', 'com') (A) - Response:
Existing record found for 7f3e4e2d-e6a4-467e-9aca-6b979a16cc59
Request (('', 49195)): ('01_7f3e4e2d-e6a4-467e-9aca-6b979a16cc59', 'hax', 'antitree', 'com') (A) - Response:
Adding new record for: 19c950ef-ef16-4ac0-ac53-87cf47d1a49f
Request (('', 51293)): ('02_19c950ef-ef16-4ac0-ac53-87cf47d1a49f', 'hax', 'antitree', 'com') (A) - Response:
Wrong fucking query type

What you needed to do was, on purpose, leak your DNS information and incorrectly configure your proxy settings. When you configure things like wget or curl to use a SOCKS proxy, in some cases the web request will go over the proxy but the DNS request will go to your normal DNS server. That’s what I’m referring to when I talked about a DNS leak.

So you’d have to use one of these apps that don’t know how to resolve DNS correctly but then at the same time you couldn’t visit the onion service with that script because .onion domains need to be resolved by tor meaning that if your script could resolve .onion domains, then it wouldn’t leak your DNS requests.

Confused yet?

Putting it all together

Here’s one of the ways to win:

  • Use Chrome, specifically Chrome, to visit the .onion address provided in the hint and route everything over tor
  • Copy the host that it redirected you to:
  • Make a curl or wget reuquest to use a SOCKS4 proxy to that host

Using Chrome you’ll exploit the WebRTC test, you’ll also address the Web test, and then the curl request will give you the correct results.


I created a backdoor as well in case all of this wasn’t working out. If you were able to intercept the requests being made to the server, you would see that most of them were done by an API hosted at /api/v1. Those requests could be manipulated to put in any IP that you wanted. In otherwords, the client was always in control of the data that was saved in the database. If you were able to figure out what conditions I was expecting, you could just intercept the requests and modify them to be what you wanted them to be.

If you got it right, you’d see the answer in the debug section of the web page. No one got this of course. Ther answer is a play on the lead developer, Roger Dingledine.