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...If you're not familiar with these sorts of tools, see an example described by Brian Krebs at
A Peek Inside the ‘Eleonore’ Browser Exploit Kit.
Why release these advisories?
It's time to have strike-back capabilities for real, and to have alternative and innovative solutions against those security issues.I agree with the concept, but not necessarily with releasing "advisories" for attacker tools. Laurent claims these are "0days". This would imply the developers of these attacker tools did not know about the vulnerabilities. By publishing advisories, attackers now know to fix them. Assuming "customers" heed the advisories and update their software, this process has now denied security researchers and others who conduct counter-intruder operations access to attacker sites. This is tactically counterproductive from a white hat point of view.
On the other hand, developers of these attacker tools might already know about the vulnerabilities, and might have already patched them. In this case, publishing advisories is more about creating some publicity for Laurent's new company and for his talk last week. (Did anyone see it?)
I like the idea of taking the fight to the enemy. Security researchers are already penetrating attacker systems to infiltrate botnet command and control servers and do other counter-intruder operations. These activities increase the black hat cost to conduct intrusions, and the more resources the attackers have to divert to defending their own infrastructure, the fewer resources they can direct at compromising victims.
However, disclosing details of vulnerabilities in attacker tools is likely to not work in the white hat's favor. White hats are bound by restrictions like laws and rules that black hats routinely break. Announcement of a vulnerability in the Eleonore exploit kit is not going to unleash a wave of activity against black hats like announcement of a vulnerability in Internet Explorer. It's likely that the few researchers and others wearing white hats will not learn much from a public announcement due to their independent research, while mass-targeting attackers (who historically are not great developers themselves) will disproportionately benefit from the disclosure.
What do you think? Should white hat researchers publish security advisories for black hat tools?
I saw that presentations from Sharkfest 2010 are now posted. This is the third year that CACE Technologies has organized this conference. I've had conflicts each of the last three years, but I think I need to reserve the dates for 2011 when they are available. In this post I wanted to mention a few slides that looked interesting.
Jasper Bongertz presented Wireshark vs the Cloud (.pdf) I reviewed this presentation to see if anyone is doing something novel regarding monitoring Cloud environments. In the slide at right you see his first option is to install a monitoring tool inside a VM. That's standard.
In the next slide you see his second option is to select a link upstream from the VM server and tap that line. That's standard too. I know of some cloud providers who use this strategy and then filter the results. You will likely need some robust equipment, depending on active the link is.
In the last slide you see that future options include ensuring that the virtual switch in the VM server provide instrumentation options. From my limited understanding this should be the case with expensive solutions like the Cisco Nexus 1000v, but I don't have any personal experience with that. Any comments from blog readers?
I also wanted to mention SPAN Out of the Box (.pdf) by John He of Dualcomm Technology. In his presentation he advocates replacing a tap with a switch used only for port mirroring, as shown in the slide at left. He's mainly trying to compete on price, since his "USB Powered 5-Port Gigabit Desktop Switch with Port-Mirroring & PoE Pass-Through" sells for $139.95 on his Web site. I'll ask Mr He if I could get a demo switch to see how well it works.
I noticed three interesting blog posts that address security instrumentation failures.
I've been interested in online packet tools for several years, dating back to my idea for OpenPacket.org, then continuing with Mu Dynamics' cool site Pcapr.net, which I profiled in Traffic Talk 10. 
I generated the picture at right by downloading a trace showing FTP traffic from pcapr.net, then uploading it to CloudShark. Apparently CloudShark renders the trace by invoking Tshark, then building the other Wireshark-like components separately. You can access the trace at this link. CloudShark says:
For comparison's sake, I took a screen capture of the same FTP pcap as rendered by Pcapr.net. Personally I think it's a great idea to use a front end that everyone should understand -- i.e., something that looks like Wireshark.
Please stop what you're doing and read Mike Cloppert's latest post Security Intelligence: Defining APT Campaigns. Besides very clearly and concisely explaining how to think about APT activity, Mike includes some original Tufte-esque figures to demonstrate APT attribution and moving up the kill chain.
