By now you've certainly heard about the "zero day" Adobe Flash player exploit. If not, you can read a bit about it here and here. What appears to be going on is similar to how other exploits and malware become quickly propagated across the web:

1. Set up a site that hosts some malware with a simple but effective password stealer hidden in a Flash file
2. Inject malicious code via SQL injection techniques into a web site that will load the Flash files from the host you set up in step 1. Web 2.0 sites with forums and user-generated content are great places to try.
3. Collect passwords/personal information/run a bot
4. Profit

Current suggestions on preventing this exploit from taking hold on your PC is to disable Flash, or at least run a plug-in like Flashblock or NoScript that lets you decide what Flash content/scripts to run and which to block. If you have a BIG-IP available, there are some other options for you that will allow your users to view other, non-malicious Flash and JavaScript-based content while blocking scripts attempting to exploit the vulnerability. An added side benefit of this capability is that you'll quickly discover if you've been infected, and can get on with removing the malicious code sooner rather than later.

If you're wondering why the SQL injection attacks have been so successful in the first place (experts estimate over 250,000 sites are currently infected), just take a look at a screen shot captured by Dancho Danchev that shows some of the JavaScript used to enable the zero day Adobe Flash attack.

(Click to view full size)

Because this is a new exploit, and because it uses a couple of different domains from which to load the infected SWF files, the "signature" of this exploit isn't going to be available to most desktop security scanners. This is one of the drawbacks of using purely signature-based security products - the signature of a newly discovered threat isn't going to be available until researchers nail it down and make it available to be downloaded. And that could take days. Days in which you, your site, and your users could be vulnerable.

In general, if the SQL injection attack failed, this scheme would likely fail to work in the first place. Attackers must somehow trick you into downloading or otherwise loading the code that will in the end infect users' browsers, and that means (a) getting you to visit their site or (b) hiding the code in a site you do visit often that thrives on user-generated content a.k.a. Web 2.0 sites. 

Now, standard SQL injection attacks are easy to spot and most developers have probably coded in a way that ensures such standard attacks aren't going to be possible. But attackers are always learning, evolving, and discovering ways to evade such protection. And lately they've figured out how to hide their attacks such that they can evade code-based protected as well as most web application firewalls. They're hiding in the all concealing torchlight (link goes to white paper on this technique).

Even if your developers are using secure coding techniques, it's possible that an attack such as this could be perpetrated against their application anyway, because of the vagaries of HTML and other loosely typed, loosely defined languages used to build web applications today.

So how do you stop it - and future attacks like this one? Consider a web application firewall that's capable of detecting these "hidden" attacks by taking into consideration all the possible warped combinations that can be used to hide SQL injection and XSS attacks inside requests. 

If you're running a BIG-IP LTM (Local Traffic Manager), you can likely prevent this attack from infecting users and discover if you've infected by using iRules to scan the payload for specific strings known to exist in the payload of the attack, such as the known domains and filenames of the flash files.

Imbibing: Water