Quantcast

Common Darknet Weaknesses 3: DNS Leaks and Application Level Problems

Adrian Crenshaw describes some common attacks deployable in the darknet usage scenario, such as DNS leaks, content grabbing, and application level issues.

Other common attacks

Other common attacks

Alright, some other common attacks: DNS leaks and various other protocols, and application level problems. An overview: does all the traffic go through the proxy? Okay, you’re using a darknet, everything is encrypted, and you’re using multiple hubs so no one really knows who’s talking to who. But what if you’re sending all of your through there, and the protocol is not quite right and it’s sending stuff outside the darknet? A common example is DNS leaks. Let’s say, you’re using Tor to visit SecManiac.com. So, I’m visiting SecManiac, and I think I’m secure, all my traffic to him is encrypted and it’s encrypted back, but I don’t want people to know that I’m visiting his site. Well, if there’s a DNS leak, they might know. I might be sending traffic through Tor, but if my machine is not configured right it could be asking the DNS server: “Hey, what’s the IP address of Dave’s box?” So, my ISP knows I’m visiting Dave’s site; they may not know what I’m looking at, but that’s still information. If you are visiting a Tor-hidden service or I2P eepSite – same thing: there will be some string of characters, .i2p or .onion, and if you’re not configured right, those hidden services will be recorded to a DNS server.

Potential darknet problems

Potential darknet problems

So, basically, you need to make sure that the darknet is configured (see left-hand image). We’re talking kind of dual purposes here. I’m talking, in some sense, about how to protect yourself when you’re using a darknet for anonymity, and how to catch someone who’s using it. It’s kind of an interplay, or game of chess. I’m sort of preaching the both sides here, and I think the topic is interesting.

A snooper can also use web bugs, depending on how you have your proxy set up. Let’s say, you have your browser set to send all HTTP traffic through Tor or I2P, but you forget about HTTPS, or possibly FTP. That would be an issue, because a person could use that to embed a link inside a web page and find out who you are. I have some examples of web bugs, but since a web bug can be something like an image you put on a web page, the IP and various other information is reported to the service hosting that web bug. You can use that kind of thing for tracing people down.

HTTPS is a good example, but there’s other application level stuff that can be a problem. JavaScript also is pretty hosed. I’d recommend watching Gregory Fleischer’s Defcon 17 talk, it basically makes you go: “Yeah, JavaScript is a bad idea from the very beginning,” as far as security is concerned, especially anonymity in this case.

DNS leaks principle

DNS leaks principle

Let’s talk about DNS leaks for a second (see right-hand image). Here we have a DNS query, let’s say that’s to some .onion address, or .i2p, or even secmaniac. Even though all my traffic going through the network might be encrypted, that doesn’t necessarily mean that this person – monitored DNS server – doesn’t know who I’m visiting. They might not know what I’m doing, but they know who I’m visiting – that can be bad enough.

Mitigations for DNS leaks

Mitigations for DNS leaks

A few ways of mitigating these kinds of problems (see left-hand image). In Tor and I2P, someone might want to put a sniffer and use libPcap filter like port 53 to find both TCP and UDP packets and see if any kind of traffic is leaving that shouldn’t. In theory, if Tor is configured right, or I2P is configured right, you’re not going to see that traffic, hopefully.

If you’re having some problems, one thing you might want to make sure, at least in Firefox, is to go in there and make sure this particular setting in ‘about:config’ is set to true so it knows to use DNS through the SOCKS connection, through the proxy. This gets a lot more complicated in other protocols, for example when you configure it in IRC client, make sure it does name resolution from IRC client to IRC client. Same thing with Secure Shell, but you’d better be damn sure you have that proxy setting configured correctly.

Don’t use a bunch of plugins…

Torbutton should help. When I use Tor or I2P, generally speaking, I use Tor browser button which has all settings already done for you to help with anonymity. Also, don’t use a bunch of plugins – that’s another big one. Other applications may vary of course. You may also want to try firewalling off port 53 and make sure it can’t go any place, and then the only way out of that particular box is the proxy.

Also, with Tor, one of the things you can do is you can actually set up a local DNS server on your box, and then, if you’re worried about DNS traffic going out, you can point your local machine’s DNS server to point to localhost, and it won’t talk to a Domain Name Server. So, that’s a nice and fairly secure option. And you can make that little setting by editing your torrc file and putting in those flags.

Grabbing content out

Grabbing content out

Alright, grabbing content outside of the darknet – this can also be an issue. In this illustration (see left-hand image), I have more of an I2P kind of style node diagram. Let’s say some traffic is being sent through. If someone doesn’t have this configured right, they could be getting HTTP traffic through on I2P, but you might get HTTPS through it. I2P does various modifications to the traffic to try to increase your anonymity, and you can’t really do that on HTTPS. There have been HTTPS out-proxies, but I’m not sure there’s any at this moment. Let’s say you’ve only configured an HTTP one. That traffic may be going through I2P and bounce around and come back to you, and they don’t know who you are. But that web page hosts a file, a web bug that is accessed via HTTPS – then it’s possible that when you request that you get your page back; you request the image, and then they have your real IP address.

A prevention trick

A prevention trick

To prevent that from happening, in I2P I used to go in and set the option: “Use this proxy server for all protocols” (see right-hand image). This particular setting isn’t necessarily going for all SSL traffic, as I recall. You can also set SSL proxy that should work. I don’t know if that particular I2P proxy is actually up and running at this point.

Careful with the cookies!

Careful with the cookies!

Okay, slightly related subject (see left-hand image). Let’s say you’re web surfing around and you visit some website and you’re like: “Hmm, I want to do something a little bit more suspicious.” You’re visiting public Internet first, then you decide to visit using Tor later on when you’re up to doing something you don’t want to be known. Well, if you’ve got a cookie while you’re on the public Internet, and if you’re using the same web browser when going the same place using Tor, you might notice you’ve got the exact same cookie again. Torbutton has various features along with Polipo, this little HTTP proxy that’s meant to filter various identity revealing information out of your HTTP traffic. It might be a concern though if you don’t have Tor configured properly. If you get a cookie off the public Internet, then if you use Tor and go to the same page – the same cookie gets sent.

Interacting with hidden server

Interacting with hidden server

You can as well make a hidden server contact you over the public Internet (see right-hand image). The last few examples I’ve given have been: you’re client and you’re contacting some Internet site. In this case, you might be trying to reveal the identity of some hidden server. This is a server inside I2P network that you don’t know its real IP address. You know its name but it’s bounced around in between hosts inside the network to be able to get to it. If you can contact it, let’s say with an exploit, for example you have a shell execution exploit or some bad web vulnerability on there – if you can tell it to pin you – well, game over, it may pin you from its real IP address. There’re mitigations for this though.
 

Read previous: Common Darknet Weaknesses 2: Tor and I2P

Read next: Common Darknet Weaknesses 4: Attack Mitigations

Like This Article? Let Others Know!
Related Articles:

Leave a comment:

Your email address will not be published. Required fields are marked *

Comment via Facebook: