Drive By Downloads
Drive-By Download Attacks are when an attacker can get a user to download software by simply visiting a website. The user only has to “drive-by” for the download to take place.
There are many channels for distributing drive-by downloads. Online advertising networks were once the most popular. An attacker would sneak a malicious ad into an ad network and it would be widely distributed by reputable, high-traffic sites. Starting around 2012, additional quality controls were put in place to make it more difficult. Sites which serve lower-quality ads with less quality control still exist. Often these begin with a pop-up window telling the user that a virus has been detected on their computer and offering to perform a free virus scan. Another popular way to bring in victims is to send out phishing emails with links to attacker-controlled websites.
The most dangerous type of distribution is from third-party websites which have been compromised by attackers and perform drive-by downloads on all of their visitors.
Drive-By Download Process
A user visits a compromised website. The website either sends a background request or performs a request redirect to an attacker-controlled website. This can be done quietly without alerting the user by using JavaScript and an HTML iframe. The request loads an “exploit kit” which probes the user for a large number of known vulnerabilities in their operating system, browser, or browser plug-ins. PDF readers, media players, and the browser’s own JavaScript and rendering engines are common targets. Historically, the Adobe Flash Player and the Java browser plug-in were the most heavily exploited targets, but both have since been retired: Flash reached end-of-life on December 31, 2020, and Oracle removed the Java browser plug-in starting with JDK 11 in 2018.
Once the exploit has been identified, it can use it to force the user’s browser to download a malware “payload”. The payload might display ads in the user’s browser, make their computer part of a botnet, log keystrokes or steal credentials, hijack banking sessions, install ransomware, or install a backdoor to allow the attacker future access.
Examples
“Mac Flashback”
Around the end of February and early March 2012, tens of thousands of WordPress blogs were compromised. How the blogs were compromised is unclear; Kaspersky’s analysis offers two unconfirmed theories: vulnerable WordPress versions or the ToolsPack plugin. Any user who visited an infected blog was redirected to an attacker-controlled website. The malicious site first attempted a drive-by download using exploits for Java vulnerabilities on Mac OS X. If the exploits failed, a Java applet posing as software signed by Apple asked the user to allow it to install (which delivered the same malware). The payload made the Mac part of a botnet and included a browser component that intercepted Google searches and substituted fake search results, giving the attackers a steady source of income. The attack infected an estimated 600,000 Macs.
NBC.com drive-by downloads
In February 2013, attackers compromised the NBC.com website and used an iframe to load the Redkit exploit kit, which served drive-by downloads of the Citadel Trojan, malware that steals personal and financial information. Security researchers analyzing the attack reported that the exploit kit was also installing the ZeroAccess malware, which modifies search results to generate pay-per-click ad revenue.
Drive-By Download Preventions
For users
The best defense against drive-by downloads is to turn on automatic software updates for the operating system, web browser, and all plugins. Attackers often use recently announced exploits and users who are slow to upgrade are vulnerable. In addition, it is prudent to remove any browser extensions you do not need, since each one expands the attack surface. Users can also install an extension such as NoScript which blocks JavaScript and other active content by default and selectively allows it on trusted sites. Some browsers will even warn users before they visit websites which are known to be compromised.
Users should not be logged into their computers as admins. This is an example of the Principle of Least Privilege—a user does not need admin permissions for most tasks. By not being an admin, it limits the read, write, and execute permissions which are available to malware and limits any damage to the user account only.
Because drive-by downloads put viruses and malware on a computer, an anti-virus program can help to detect and neutralize the threat if the download succeeds.
For site operators
Because compromised third-party websites are the most dangerous distribution channel, the people who run a site can also make it harder to turn their pages into a drive-by launch point. A Content Security Policy (CSP) is a response header in which a site tells the browser which sources its pages may load resources from. MDN’s CSP guide describes its primary use as controlling which resources, especially JavaScript, a document may load, so that a <script> injected by an attacker and pointing at an untrusted host is not loaded. The same applies to frames: the frame-src directive lists the valid sources for <frame> and <iframe> elements, falling back to child-src and then default-src when it is absent. An iframe pointing at an exploit-kit host that is not on the list, like the one injected into NBC.com, is blocked by the visitor’s browser instead of loading. For example:
Content-Security-Policy: default-src 'self'; script-src 'self'; frame-src 'none'
Under this policy, the page may load scripts and other resources only from its own origin and may not load any frames. Because the policy includes script-src, MDN notes that inline JavaScript will not run either unless the site explicitly allows it, for example with a nonce or a hash. See the Content Security Policy page for how to build a policy, including the nonce-based “strict CSP” that MDN recommends for scripts.
A CSP is a layer of defense in depth, not a replacement for keeping the site itself secure. MDN states that setting a CSP is not an alternative to sanitizing input, so a site should do both. A new policy can be tested first in report-only mode with the Content-Security-Policy-Report-Only header: it is not enforced, but violations are sent to the reporting endpoint the policy names.