Over the past few months, a number of legitimate sites have become unfortunate hosts of malware, specifically in the form of Flash objects that purport to be part of a legitimate advertisement. This malware has been found on sites like Expedia.com, The Economist and MLB.com. One of my favorites is a pop-up box which claims a user's system is infected. If the user selects "OK" to allow the pop-up to "clean" their systems, they become victims. If they select "Cancel," their systems are still infected.
An odd detail about how this malware works is it does not activate with every click. Many of the malware samples that have been analyzed either trigger on X number of clicks, or function by a preset timer. This makes analysis difficult; it can be hard to recreate a specific attack. It's not only a challenge for the systems administrators of the sites that are inadvertently hosting the malware, but may also prove difficult for a team trying to replicate the conditions to perform a solid root-cause analysis of the infection, which is a key of any incident-response plan.
But can't sites simply scan the ads they host? Unfortunately, to scan ads successfully, websites need to be able to create a blacklist of known bad domains from which to block ads, but unfortunately this approach doesn't work. Even trying to see where the malicious advertisements are redirected can be difficult, since they may be redirecting to a number of "legitimate" sites like ad.doubleclick.net, which may then redirect to the malware content. Sometimes multiple ad redirects are used before malware is activated. There is a great video describing this type of malicious attack as it was discovered on MLB.com.
Preparing for Flash-based malware
Flash-based malware can be created using a number of tools that make the generation of Flash objects easier, allowing developers to tie two objects together, much like wrappers for executables. In other words, an attacker can take his malicious code and wrap it in a seemingly legitimate program, like a Flash video. When the user runs the Flash video, the malicious code will also be executed. If, for any reason, the malicious software needs to install something that requires permission of the user, it is not uncommon for a pop-up box requesting install permission to be used. As we now know, many users will install the application without a second thought, perhaps believing it is required to view the content.
So, what's the defense strategy for Flash-based malware? First, organizations need to understand that they are responsible for the content on their sites. It's a challenge because many organizations utilize a third party to provide advertisement content. Regardless, there needs to be an agreement between the owners of sites and the people who provide it. Make sure any agreement you make with third-party ad providers has procedures for how to notify them of potentially malicious content, and the timeframe in which they will remove it. The advertisement organization should be required to notify you as well if it discovers that malicious content has been served through its service to your site.
Enterprises must also understand how these objects work. Your incident-handling team must be familiar with how the malware operates and how to analyze it. Remember, simply relying on AV to find infections may not be adequate, and relying on Web filtering tools will not work because the malicious files are usually hosted on legitimate sites. A good tool to become familiar with is Flare, a decompiler of Flash SWFs. Because many byte-code languages can be decompiled, developers are able to see how they function. This tool is also useful for incident response teams that need to analyze how potentially malicious software affects systems.
Ollydbg, a Windows debugger, can also be attached to the Flash player. While programs like Flash and Java require software to function, the code is quite different than what a CPU and operating system expects to process properly. All of these byte-code-level languages need to be interpreted through intermediary software so they can be put into instructions that an OS and CPU can understand. Tools like Ollydbg attach to and monitor this lower-level software and allow for monitoring of the lower-level OS and CPU instructions. The Ollydbg approach is a challenge, however, because it is difficult to separate the instruction flow of the Flash program from the Flash object. The tool is critical, though; it may show data that Flare cannot.
Given that Flash-based malware represents a substantial threat, enterprises should ask their endpoint security vendors about the capabilities their tools have to monitor browser behavior. User education is important as well; many times the success of Flash malware depends on getting the user to click "OK" or "Cancel," when instead they should use the X in the upper right-hand corner to close the pop-up window.
Another approach that can be somewhat controversial is to run browser ad-blocking software, which will block many advertisements that show up on Web pages and greatly reduce the attack surface of an environment. In my opinion, if there's an opportunity to strip a possible attack vector away from the attackers, security pros should take it.
About the author:
John Strand currently is a Senior Security Researcher with his company Black Hills Information Security, and a consultant with Argotek, Inc for TS/SCI programs. He teaches the SANS 504 "Hacker Techniques, Exploits and Incident Handling," 517, "Cutting Edge Hacking Techniques," and 560 "Network Penetration Testing" classes as a Certified SANS Instructor. Strand also answers your questions on information security threats.
