RSA Conference 2011: Ease of performing a drive-by download attack demonstrated

News by Dan Raywood

The ease by which a drive-by download (DBD) can be conducted and used has been demonstrated in a presentation at the RSA Conference in San Francisco.

The ease by which a drive-by download (DBD) can be conducted and used has been demonstrated in a presentation at the RSA Conference in San Francisco.

During the presentation, Lars Ewe, CTO of Cenzic, and Neil Daswani, CTO of Dasient, demonstrated a DBD and admitted that it was 'much easier than you would expect'.

Daswani said that a DBD was an indication of how bad things can get with vulnerabilities on a website, but Dasient is working with the security community to help bolt down websites.

During the demonstration, Daswani showed a basic web page with a web script alongside it that contained an Adobe Acrobat Reader. He said that with a PDF with malicious JavaScript in it, you can start to manipulate a visitor's computer without their permission.

He said: “On a financial services website, the malware will try to log the keystrokes. There were days when an attacker had to guess the user's credentials, now there is a new method of attack and you can infect a website with a bad page.”

Daswani pointed at browsers supporting third party applications and functionality and said that attackers do take advantage of flaws in these and in zero-day vulnerabilities.

He said: “With Web 2.0 you are bringing in content from other providers and you use a third party to manage your inventory. On one page there is so much content that we are seeing DBD issues and there are tens of thousands of websites using widgets.

“The attacker figures out the shell code, generates a zero-size iframe and a PDF that has JavaScript, and then does the fingerprinting. The attacker does not need to take advantage of Reader, as they know what version they are running and does a buffer overflow.”

He went on to explain that the new step is to clear the shell code to give access and control to the stack on the client, 'spray' the heap with assembly instructions and that makes a connection out. “That is then a downloader and its sole purpose is to download more malware and it depends on who is paying to control it,” he said.

In terms of how to protect against these type of attacks, Ewe encouraged proactive, regular scans, as you want to find root causes and flaws before anyone else.

He said: “If you find an issue what do you do? It is classic to fix the underlying code but that is a hard job for the largest organisations, so look to best practise to make sure it doesn't happen in the first place. You want to block, find it and then do it quickly, that is where the web application firewall comes in.

Daswani said: “The first reaction is to prevent what is going on, but also have defence-in-depth. If a widget gets compromised it is not your code and it is not your responsibility to fix it. The firewall sees the code at the server side. It is important to have detection and a containment practice in place and websites need to have malware monitoring.”

Ewe concluded by saying: “What can we do? Test your websites, prioritise vulnerabilities based on risk score, block and remediate.”


Find this article useful?

Get more great articles like this in your inbox every lunchtime

Video and interviews