More Disclosure of Vulnerabilities in Attacker Tools

Two years ago I wrote Full Disclosure for Attacker Tools, where I wrote in part:

The idea of finding vulnerabilities in tools used by attackers is not new. It's part of the larger question of aggressive network self defense that I first discussed here in 2005 when reviewing a book of that title. (The topic stretches back to 2002 and before, before this blog was born.) If you follow my blog's offense label you'll see other posts, such as More Aggressive Network Self Defense that links to an article describing Joel Eriksson's vulnerability research into Bifrost and other remote access trojans.

What's a little more interesting now is seeing Laurent Oudot releasing 13 security advisories for attacker tools. Laurent writes:

For example, we gave (some of) our 0days against known tools like Sniper Backdoor, Eleonore Exploit Pack, Liberty Exploit Pack, Lucky Exploit Pack, Neon Exploit Pack, Yes Exploit Pack...

In the post I addressed some of the issues involved, but a recent development involving the popular Poison Ivy (PI) remote administration tool (RAT) brought the debate back to life.

Today I became aware of Gal Badishi's Monday post Own And You Shall Be Owned. In the post he writes:

We will now present a fully working exploit for all Windows platforms (i.e., bypassing DEP and ASLR), allowing a computer infected by Poison Ivy (or any computer, for that matter) to assume control of PI’s C&C server...

In light of this analysis, a Metasploit module without encryption is being prepared.

"C&C server" means "Command and Control server," or the system operated by an intruder to control the multitude of victim systems on which he installed PI.

On the surface it may seem cool that "good guys" can now attack "bad guy" infrastructure thanks to this research. However, I think it's important to weigh the pros and cons of this disclosure of vulnerabilities in attacker tools.

Reasons One Should Disclose Vulnerabilities in Attacker Tools

1. Intruders already know about the vulnerabilities anyway.
2. Good guys already know about the vulnerabilities anyway.
3. Publicizing, and especially weaponizing (via Metasploit), this vulnerability gives good guys a way to strike back at bad guy infrastructure.
4. "Information wants to be free." Trying to protect the info from disclosure is a losing game.
5. If good guys didn't know about the vulnerabilities, they now can put them to work attacking intruder infrastructure for "active defense" and "research" purposes.
6. There's no place to disclosure vulnerabilities in attacker tools "responsibly" anyway.

Reasons One Should Not Disclose Vulnerabilities in Attacker Tools

1. Not all intruders know about the vulnerabilities, or perhaps none do.
2. By publicizing the vulnerabilities, it tips the intruders to defend their infrastructure by patching.
3. Good guys who previously had access to the infrastructure lose access once the intruders upgrade their vulnerable software.
4. A researcher just saved intruders time and resources by providing free software security and quality assurance services.
5. Information doesn't have to leak. Many organizations keep secrets, even without the infrastructure of classified systems.
6. There are several private, vetted mailing lists that do a reasonably good job keeping information confidential, while providing benefit to defenders.

I tend to think it's a bad idea to publicize vulnerabilities in intruder tools for the reasons I listed, but I see the other side as well. My biggest concern is that researchers don't weigh these issues, or given them enough thought, prior to publishing their findings. What do you think?

Tweet