UPDATE: The source repository for all this code is hosted here: https://github.com/antitree/bsidesroc2017ctf
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:
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 http://bsidesrocmbna5a6.onion:5000
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: 184.108.40.206 or some tor exit node * WebRTC: 10.17.5.5 or some internal IP * DNS: 220.127.116.11 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 (('18.104.22.168', 56373)): ('01_7f3e4e2d-e6a4-467e-9aca-6b979a16cc59', 'hax', 'antitree', 'com') (A) - Response: 22.214.171.124 Wrong fucking query type Request dropped from 126.96.36.199 for 01_7f3e4e2d-e6a4-467e-9aca-6b979a16cc59.hax.antitree.com. Existing record found for 7f3e4e2d-e6a4-467e-9aca-6b979a16cc59 Request (('188.8.131.52', 54130)): ('01_7f3e4e2d-e6a4-467e-9aca-6b979a16cc59', 'hax', 'antitree', 'com') (A) - Response: 184.108.40.206 Existing record found for 7f3e4e2d-e6a4-467e-9aca-6b979a16cc59 Request (('220.127.116.11', 49195)): ('01_7f3e4e2d-e6a4-467e-9aca-6b979a16cc59', 'hax', 'antitree', 'com') (A) - Response: 18.104.22.168 Adding new record for: 19c950ef-ef16-4ac0-ac53-87cf47d1a49f Request (('22.214.171.124', 51293)): ('02_19c950ef-ef16-4ac0-ac53-87cf47d1a49f', 'hax', 'antitree', 'com') (A) - Response: 126.96.36.199 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.
Here’s one of the ways to win:
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.