Sophos Cloud Optix
The newly-published Sophos Security Threat Report 2013 reveals that web exploit kits like the notorious Blackhole exploit kit are responsible for the majority of web attacks today.
The development of such attack kits, which exploit vulnerabilities to silently infect web-browsing computers, has been interesting for computer security professionals to follow.
During the past year, my colleagues at SophosLabs and I have been following the development of the Blackhole exploit kit very closely:
- Technical paper: Learn about the Blackhole exploit kit
- New version of Blackhole exploit kit
- Blackhole exploit kit confusion. Custom builds or copycats?
- Technical paper: Journey inside the Blackhole exploit kit
One thing I have noticed is a certain lack of originality in the exploit usage of the Blackhole exploit kit.
The author of the Blackhole exploit kit seems to be more comfortable as a system integrator and web application developer than anything else, and is far from being a hardcore vulnerability researcher.
This is perhaps not a surprise. After all, segregation in the malware field leads to specialization, and it has become apparent that the exploit kits are not the place to look for originality.
This impression of mine is perfectly supported by research conducted by iSec Partners, as you can see in the following video:
The video provides a good insight into exploit kits, and is well worth a watch by anyone interested in the topic.
It turns out that the number of exploits which first appeared in the malicious exploit kits is zero.
Further than that, only publicly-disclosed exploits which are well documented end up being used in the exploit kits.
So where do these exploits come from?
iSec Partners took the vulnerabilities used by the top 15 exploit kits, and investigated the original source of the disclosure:
| Developed in APT | 3 |
| Developed by whitehats | 10 |
| Developed by malware authors | 0 |
In a few cases the exploit was taken from samples of earlier field attacks, but more often, the source was the result of research by whitehat security experts.
Some might argue that this is last year’s story, as nowadays the Blackhole exploit kit dominates.
Would using the Blackhole exploit kit as a point of reference change the above picture? I don’t believe so.
The same old exploits are used by the Blackhole exploit kit, with only a couple of new zero-day exploits added like CVE-2012-4681 or CVE-2012-1889.
However, although the vulnerabilities were classed as zero-day at the time of addition to the exploit kit, the exploit code itself was not developed by the kit’s author.
Instead, the code was taken from publicly available samples – most visibly in the case of CVE-2012-1889, where the code was blindly copy-pasted into the exploit kit code.
To be clear: I am not against vulnerability disclosure.
Responsible disclosure helps the overall state of security. But that does not have to mean that we have to make the life of malware authors – such as those who deploy the Blackhole exploit kit – this easy.
Lets make the bad guys work hard for their money.
I can only agree with the conclusion of the iSec’s presentation: force cybercriminals to take the more expensive route.
How much money would buying a vulnerability cost? A typical Java exploit found recently is expected to be worth a five-digit sum.
The Blackhole exploit kit’s author himself claimed that to use a vulnerability would cost him about $100.000 if he were to buy it.
How much money would the exploit kits’ manufacturers make? Clearly, not even close to this figure.
The last info I have was from a year ago, when Blackhole protection was restricted to be used on 28 servers. This was discussed in my technical paper, “Inside a Black Hole”.
The well-coordinated update scheme observed in the Blackhole-related malware flow suggests that only one code branch was used. I would estimate the number of Blackhole licenses sold to be the same amount.
Assuming the best, that they are all one-year-licenses, a yearly income amounting to a five figure sum could be estimated. Therefore even buying a single exploit would mean spending a significant amount of the venture’s yearly income.
Providing it for free, in the form of easy-to-implement proof of concept code, really means supporting the exploit kit authors.
I’d much prefer a world where people chose to support the International Red Cross or the WWF instead.
Burning phoenix image from Shutterstock.
how about a 7 day scheme where the developers are informed before the report is published, allowing the vulnerability to be patched if needed?
The problem is not how many days before the disclosure the report is published (looking at the exploit kits' stats, users are successfully infected with exploits that were patched weeks, months, years before).
The problem is the content of the disclosure. It should not make it too easy to use it in malware attacks.
Developers need to embrace the responsible disclosure of bugs and make more of an effort to patch. Too many times, they drag their feet.
That is true. A lot of frustration built up in the past because developers failed to respond properly and in time.
And that is also true that the bad publicity coming from ITW exploiting their vulnerabilities forced some vendors to act.
But I hope there is a less destructive way to reach that other than mass infections.
Hey, I'm Dan Guido and I performed the research you cited. The data I collected was from the top 15 exploit kits in-use at the time, not just Phoenix.
Thanks for the correction, I really meant to write that. I got focused on the Phoenix vulnerabilities, and failed to make it clear that your research had a broader scope.
Hey, thanks for the correction.
There are a few other pieces of information worth pointing out.
* My original analysis included the Blackhole exploit kit
* I performed this research at iSEC Partners, however, I now work for Trail of Bits, a firm that I co-founded.
* I performed similar analysis of mobile malware with a colleague of mine, Mike Arpaia, titled the Mobile Exploit Intelligence Project: http://www.trailofbits.com/research/#mobile-eip
Good luck with your new company. Keep on doing the research.
I would guess that you used the info from Blackhole 1.1.0 in your paper, I just followed up with the new exploit added to the 1.2.x versions.
Thing is Full disclosure is a important part of vulnerability research
Lets say i have to analyze a exploit ,but i never actually seen a working exploit code.So situation will be much worse
Other example to analyze a malware lets say a rootkit ,it will be much better if seen a poc of such thing .
Hope you are getting me…POC plays a important to made a security researcher
Also if something is public and still not patched then its vendor issue..why google chrome never get into issue like that ?
Full disclosure is an important part of current vulnerability research – on that I agree. It is not necessarily the only part, but important.
But I don't beleive that we have only the choices of not disclosing the information and diclosing it to the entire world. There has to be a stage in between so that vulnerability researchers can get the necessary information but we don't feed the same information to the malware authors.
Is a screwdriver responsible for a broken screw? No. Exploit kits are imho not the threat, but the tool used – looks like this is mixed up here.
The root cause for successful attacks are not exploit kits.
I don't think it is mixed up here. There is only one criminal act in this picture and that is of the malware distributors.
Is an open door a justification to go into a house and steal the money from there? No. Moreover, it is not even legal.
The root cause for the succesful attack are obviously the vulnerable system. but that does not give the right to the exploit kit authors and purchasers to abuse them.
Exploit kits are only the tool to compromise vulnerable systems and can be used to find weaknesses and to take counter measures to prevent exploitation. Therefore, it depends on the use of an exploit kit whether it’s a threat or not.
Are you not mixing up Metasploit with the exploit kits like Blackhole and Phoenix? I could not recall a case when Blackhole was used to improve the security of a site.
Yes I did. Sorry for the noise.
With the same concept malware analyst should stop writing detailed articles about malware analysis cause they are giving out techniques and ideas to malware authors
Deciding just how much to write about a specific piece of malware can be a tricky d issue.
But there's a big difference between describing a malware trick, even in some detail (e.g. "the code scans all virtual memory blocks using a regular expression to looking for credit card magstripe data"), and actually including a link to download a working malware sample, or compilable malware source code…