marco
blog
Menu:
Peering through the iframe
June 22, 2011
We have recently presented our paper Peering through the iFrame at the INFOCOM mini-conference.
In this paper, we look in-depth into a drive-by-download campaign, the one used to spread the Mebroot malware. In a way, this paper is an ideal continuation of our earlier investigations of the Mebroot/Torpig botnet; more in general, however, it aims at providing a snapshot (as comprehensive as possible) of a modern drive-by-download campaign. Mebroot is not the most pervasive or widespread drive-by-download campaign (during our monitoring, it affected "only" several thousands domains), but it is long-lasting and quite successful, and therefore it makes for an interesting subject of study.
We started off our study with the goal of gaining a better understanding of all the parties involved in a drive-by-download campaign: the attackers (what is their modus operandi? what infrastructure do they rely on for running the campaign?); the legitimate web sites that get compromised to drive traffic to exploit sites (which sites are targeted? do they notice they have been compromised? how long does it take for them to cleanup?); and the final potential victims of the attacks (are they indeed vulnerable to the attacks? what is the actual infection rate?)
To answer these questions, we needed to get visibility into the
operations of the drive-by-download campaign, and, as in our previous
studies on Mebroot, we obtained it by infiltrating the Mebroot's
infrastructure. A little bit of background is necessary to understand
how this worked in practice.
As in other drive-by-download attacks, the Mebroot campaign compromises
legitimate web sites with code that redirects the visitors of these
sites to the campaign's exploit sites (where the actual exploits are
launched). In the Mebroot case, the injected code uses domain
generation algorithms (DGAs) to dynamically generate the name of the
exploit sites where victims are sent to (instead of having their names
statically hard-coded). In practice, every so often (from one day to a
few days), the DGAs generate a different domain name, thus they redirect
victims to a different exploit site.
This presumably is done to be more resilient to take-down attempts: in
the traditional model (hard-coded exploit sites), whenever the current
exploit site is blocked, the campaign is effectively disabled: all the
legitimate web sites that an attacker has compromised of suddenly become
useless, because they point to a disabled domain.
On the contrary, in the Mebroot case, the disruption caused by taking
down the current exploit sites is only temporary: as soon as the DGAs
generate a new exploit site, the campaign is active again and the sites
that were compromised in the past resume sending their victims to the
new exploit site.
However, DGAs also open a window of opportunity for defenders. In particular, we were able to register some of the domain names that were to be used in the campaign. As a consequence, for several days over a period of almost a year, our own servers were used in the campaign in place of the actual exploit sites. Of course, our servers simply monitored the traffic they received and performed several measurements of their visitors.
This monitoring gave us a lot of interesting information; for all the results, refer to the full paper. Here are two findings (on the final target of the attacks and on the compromised web sites) that I think are particularly interesting.
How vulnerable really are the users that are redirected to exploit sites? Quite a bit. During our study, we found that roughly between 60% and 80% of the visitors used at least one browser plugin that was known to be vulnerable. Between 30% and 40% of the users we observed was vulnerable to one of the exploits used in the Mebroot drive-by-download campaign. Clearly, these are very worrying statistics. To be precise, these are upper bounds on the actual infection rates: from our vantage point, we could not determine whether an exploit was successful—an attack could be blocked by a host-based defense mechanism, such as an anti-virus tool. In any case, the potential for infection (and the lack of updating and patching) is staggering.
Switching our attention to the compromised web sites that expose their users to exploits, do they realize that they have been compromised, and, if so, do they clean up and remediate the infection? Not really. Almost 20% of the compromised web sites remained infected during our entire monitoring period. Those that did clean up, did so very slowly: after 25 days only half of the sites had removed the malicious code.
For more results, stats, and graphs, check out the paper. Here is the abstract:
Drive-by-download attacks have become the method of choice for cyber-criminals to infect machines with malware. Previous research has focused on developing techniques to detect web sites involved in drive-by-download attacks, and on measuring their prevalence by crawling large portions of the Internet. In this paper, we take a different approach at analyzing and understanding drive-by-download attacks. Instead of horizontally searching the Internet for malicious pages, we examine in depth one drive-by-download {\em campaign}, that is, the coordinated efforts used to spread malware. In particular, we focus on the Mebroot campaign, which we periodically monitored and infiltrated over several months, by hijacking parts of its infrastructure and obtaining network traces at an exploit server.
By studying the Mebroot drive-by-download campaign from the inside, we could obtain an in-depth and comprehensive view into the entire life-cycle of this campaign and the involved parties. More precisely, we could study the security posture of the victims of drive-by attacks (e.g., by measuring the prevalence of vulnerable software components and the effectiveness of software updating mechanisms), the characteristics of legitimate web sites infected during the campaign (e.g., the infection duration), and the {\em modus operandi} of the miscreants controlling the campaign.
Fake AV, education, and conditioning
June 21, 2011
Some time ago, I've stumbled upon a web page launching a "Mozilla Security scan". The page would purportedly identify viruses and other malware on my machine. Unfortunately, there is no (legit) Mozilla Security Scanner, as this was yet another case of a fake AV attack.
A characteristic of the Mozilla Security attack is that it uses a slight variation on the classic fake AV playbook: in fact, to convince users to install malware on their machines or directly part with their money, it mimics a security mechanism implemented in a specific program (the alert page presented by Firefox when a user visits a blacklisted domain), rather than simulating a generic anti-virus tool.
These attacks are successful because they piggyback on the trust that users have learned to assign to these security mechanisms (anti-virus software, blacklist filters in browsers, etc.). Of course, this shows that attackers are quite creative in coming up with new attack techniques, especially social engineering schemes. However—and this is perhaps a more constructive observation—they also point out a weakness in how we (the security community in general) have been educating users on computer security. While we were aiming for "user education" (finally having regular users "get" security), it appears that we only managed to do "user conditioning": Security. Advice. Must. Be. Followed. The anti-virus (or a program that looks like it) tells me to pay for an upgrade: done. The malware filtering page in the browser suggests to download a binary: check. And so on.
So, how to improve?
Well, user conditioning and its risks have been pointed out before, together with loads of good suggestions on how to avoid it (most exhaustively by Peter Gutmann). My simple, bare-minimum suggestion is the fake-AV-check: when a new security mechanism or security advice is introduced, how likely is it that this very same mechanism or advice is going to be used in fake AV attacks in a few weeks time? Or, how difficult is it to turn this mechanism or advice on its head and make it into a tool in the hands of the attackers? If the answer is "easy", then let's just go back to the design board and start over.
Best scam message
June 16, 2011
This is by far one of the most entertaining spam messages I have received in a long time. It reads as the script of an old Hollywood action movies: soldier in Iraq recovers a large sum of money (10+M USD), opportunely concealed near one of Saddam's palaces; he hides it with the help of a sympathetic UN officer; needs us to exfiltrate the money.
Here is the original text:
First,let me introduce myself. I am Capt. Michael Scholl, assigned
to 2nd Battalion, 3rd Marine Regiment, 3rd Marine Division, western
Anbar Province in Iraq. I am desperately in need of your assistance and
I have summoned up courage to contact you. I am presently in Iraq and I
am seeking your assistance to evacuate the sum of $10,570,000 (Ten
million Five Hundred and Seventy Thousand USD) as far as I can be
assured that it will be safe in your care until I complete my service
here.
SOURCE OF MONEY: During a rescue operation, some amounts in various
currencies which was concealed in barrels with piles of weapons and
ammunition at a location near one of Saddam Hussein's old Presidential
Palaces was discovered and it was agreed by all party present that the
money Be shared amongst us. This might appear as an illegal thing to do
but I tell you what, no compensation can make up for the risks we have
taken with our lives in this hellhole. The above figure was given to me
as my share and to conceal this kind of money became a problem for me,
so with the help of a German contact working with the UN here (his
office enjoys some immunity) I was able to get the package out to a safe
location entirely out of trouble spot. He does not know the real
contents of the package as he believes that it belongs to an American
who died in an air raid and asked that the package be handed over
family. Your confidentiality about this will be highly appreciated.
For more details please contact me via my private box:
schollmc@9.cn
The follow up email is not nearly as interesting: in a long and winding way, it promises to split the money 70%-30% and asks urgently for information about us.
A search on Google reveals that the scam is quite long-lived (and, we should conclude, successful?): in fact, there are reports dating back to November 2009 and 2010.
Needless to say, stay away from schollmc@9.cn.
