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
- Intruders already know about the vulnerabilities anyway.
- Good guys already know about the vulnerabilities anyway.
- Publicizing, and especially weaponizing (via Metasploit), this vulnerability gives good guys a way to strike back at bad guy infrastructure.
- "Information wants to be free." Trying to protect the info from disclosure is a losing game.
- 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.
- There's no place to disclosure vulnerabilities in attacker tools "responsibly" anyway.
- Not all intruders know about the vulnerabilities, or perhaps none do.
- By publicizing the vulnerabilities, it tips the intruders to defend their infrastructure by patching.
- Good guys who previously had access to the infrastructure lose access once the intruders upgrade their vulnerable software.
- A researcher just saved intruders time and resources by providing free software security and quality assurance services.
- Information doesn't have to leak. Many organizations keep secrets, even without the infrastructure of classified systems.
- There are several private, vetted mailing lists that do a reasonably good job keeping information confidential, while providing benefit to defenders.
Comments
I'm not going to address the general question, but rather the specific case of Poison Ivy (PI). As I said, PI's latest version dates back to late 2008 (meaning there's no public update). Additionally, the vulnerability was already discussed in 2010.
The sort of people who are likely to just take a public 4 years old Trojan package and use it blindly, are mostly not going to know (or care enough) about a vulnerability in the C&C server. Moreover, a lot of the defenders themselves don't seem to care enough, don't have the time to research the matter, or just don't believe it's possible (and I've had discussions with some of them).
All in all, I don't think it's such a big deal in this case. And yes, I thought about the issue before publishing. Rest assured there are many things I don't publish simply because I think about the consequences.
Be it as it may, I'm glad my humble post was enough to inspire you to write yours. :) Thank you for the fruitful discussion.
Cheers,
Gal
As I mentioned over on Twitter, another possible argument for disclosure is that disclosing could push attackers into making unplanned changes to their code or infrastructure. Though that can seem bad from an investigative point of view, it could cause the adversary to make mistakes that might not have otherwise been made. It could also contribute to resource depletion/exhaustion. At a minimum, it raises the cost in time and resources for the adversary to stay in the game. Right now, that cost is heavily lopsided against the defenders, so one could argue that any steps that contribute to exhausting the adversary's resources are potentially beneficial.
Having said that, it's important to note that attackers/criminals are not fundamentally unlike any other people. Some of them will improve their game and some won't, depending on some combination of their motivations, skills, and resources. Whether or not any given threat will escalate upon release of such information is unpredictable unless you already know something about the specific threat.
I haven't made up my mind about where I stand on the issue of openly sharing this kind of intelligence, whether it be vulnerability information or indicators of compromise. However, I do see that not releasing this kind of information (or selectively releasing) effectively creates two tiers of defenders. Those in the know who can, therefore, better defend themselves and those out of the loop who must cull together what intelligence they can on their own and pray they aren't missing too much.