How to prevent the Mevade botnet from abusing the Tor network?

Question

If the botnet admin decides to transmit data, maybe he alone could bring down the whole Tor network. The NTor circuit-level handshake in Tor 0.2.4 solved some problems, but the botnet is still affecting the network.

Are there any bolder options taken into consideration or being developed to fight against this massive botnet?

Answer 1

Step one is to look at the short and medium term answers that I described in the blog post on the topic.

I've asked Nick Hopper, a professor from Minnesota who is taking his sabbatical to work on Tor research problems, to think about the problem more deeply and see if there are good longer-term answers. Below are some of the ideas I suggested that he/we should explore.

We're definitely going to need help from the broader communities (research, hacker, social connections, etc) since we have our hands full teaching journalists what's going on with the NSA thing, making Tor work well when it's not under this much attack, etc. Please help!

But first, I should point out that the below ideas are for solving the current situation, where an enormous botnet has done a pretty good job at moving in without destroying its host. If he wanted to set his five million bots to trying to DDoS the Tor network, e.g. wasting the bandwidth of the volunteer relay operators, then that's a much crummier arms race to play. Five million bots is a lot of malicious hosts.

That said, here are some ideas to spark more thought. I was imagining breaking the ideas into three categories:

1. stuff we should do short-term that isn't too difficult;

2. stuff that isn't too tricky or risky that we should do medium term if the troubles remain; and

3. stuff we should do long-term if '1' and '2' don't work.

I think we have some handle on '1' (e.g. the points in the blog post), so I'm most interested in people to explore categories 2 and 3.

• Drop all requests that use the v3 link handshake, since 0.2.4 speaks the v4 handshake. Or drop all TAP handshake requests. That means Tor 0.2.3.25 (our current stable) would stop functioning; probably best to get 0.2.4.x out as stable first.
• Rate limiting of circuit creation, limiting differently by handshake class (I think this one's a near-term promising one but only if the bots never upgrade).
• Users have to solve some sort of captcha before they can make many circuits. Messy for headless users, and also messes up hidden services, and how exactly would we do it anyway? It seems like a lot of users think this is a great idea, but zero people have made any viable suggestions on how to do it engineering-wise.
• Consensus parameters to ask clients to back off of various behaviors (but when it comes down to it, if the client has an application request, and we've told it to back off, what should it do?)
• Which of the incentives design papers are suited for this situation? See Building Incentives into Tor, Recruiting New Tor Relays with BRAIDS, LIRA: Lightweight Incentivized Routing for Anonymity, and the related work section in each.
• Can we separate the hidden services functionality from normal Tor relays, and have it be an add-on that people use Tor relays for without Tor supporting the design explicitly? Would that actually help anything?
• Getting a sample of the malware, and contacting AV vendors to get them to help wipe it from the world.
• Using our social networks to try to track down the botnet operators and work with them to help them understand the harm they are doing.
• In the more crazy front: guards do passive OS fingerprinting (or heck, active nmaps) of the clients and throttle circuit requests and/or bandwidth from Windows users. Or they try to detect the pattern of circuit-building or accesses that the bot generates -- for example, if it's programmed to hit its hidden service every 20 minutes, then we can look for that pattern and treat those clients specially.

This particular bot appears to just access a hidden service every so often. What would happen if they wanted to pass more traffic over the Tor network too? What are the right architecture / design changes for becoming robust to that attack, without impacting real users too much?

Also, it seems like the game theory changes dramatically if we assume the botnet operator will upgrade in response to our changes, or if we assume he won't. Maybe that's another way to categorize options. It also means that since the network is reasonably stable currently, and things could be a lot worse, then we should take our time and try to find some good long-term-viable solutions.

In summary, please help! I have better things to be doing than biting off this new research direction in parallel to all the others.

Answer 2

• One could advocate crowd-founding a "Tor botnet defense fund". Then pay the most skilled hackers to analyze the malware, find a vulnerability in the botnet, cooperate with authorities and take over the botnet and shut it down. De-anonymize the botnet owner as a bonus.
• The issue comes from a lower level. A level, The Tor Project isn't responsible for. One could attempt to solve the problem at that level. Advocating for free basic education in computer security, so at least people's computers stay clear from computer worms would be an option.
• When even more botnets start using Tor, it may happen that Internet Service Providers call their users and ask them, if they know that they are using Tor; and then they don't; tell them to clean their computers.

Answer 3

There isn't really a way to stop the botnet entirely. Due to the very nature of Tor making it hard to stop the internal traffic, or identify its source, there is very little that can be done without introducing larger protocol changes.

I'm unaware of any efforts to investigate such changes.