Web-Centric Short-Term Incident Containment
Malicious IFRAMEs like the one below are being added to Web sites. These IFRAMEs like to malicious code hosting by a third party under the control of the intruder. When an innocent Web browser visits the compromised Web site, the browser is attacked by the contents of the IFRAME. This is not a new problem. I responded to an intrusion in 2003 that used the same technique. It's the reason why I discussed having the capability to use an extrusion method to modify traffic as it leaves a site. This is an example of Short Term Incident Containment. This technique does not remediate the compromised Web sites or Web servers. It does help clean malicious traffic before it reaches Web browsers. I suggest using Netsed or Snort in inline mode to replace the malicious IFRAME with something benign. It would be helpful to have this sort of capability widely deployed as an application-level incident response tool.
Note: I do not use Gentoo. However, Gentoo's package site nicely provides images for all the tools in their repository. When one is trying to write slides and add images that have some relationship with the material at hand, Gentoo's "package boxes" make nice additions.
As a preventative measure on the Web client side, Greg Castle's Whitetrash would help prevent the third-party content being loaded into the IFRAME.
On a somewhat related note, I am glad to see developments like that from Palo Alto Networks, described by Dark Reading. It's a firewall that makes blocking decisions based on application recognition, not port number. Parts of this functionality are available elsewhere, but eventually all network blocking and inspection products will make decisions using the same method.
Comments
but this stuff sounds like bluecoat. i'm confused. how is palo alto networks different? they provide malware signatures?
it's a good idea. but what about encrypted javascript? i know that jose nazario and others have done some research in this area - but i haven't seen enterprise-ready automation.
are we worried only about iframes and javascript? no. there's java, actionscript, and many other applications to worry about. i don't see how a firewall can stop these kinds of attacks with any hard metric on assurance.
can't users/malware circumvent these proxies as well? i know that ssh over ssl will work, as will ssl over ssl or anything else similar.
real covert channels are going to do "call home through call home" soon. imagine the threat of a botnet (or even browser-only botnets like attackapi) that uses command and control that is self-similar (1) to Windows Update, Mac OS X System Update, or yum traffic? gray-area already has http cookie covert channel proof-of-concept code.
firewall vendors are years behind, and i don't think that they will be able to catch up. i guess it's nice to see someone try, but hopefully the next firewall/ips/utm innovation will try even harder.
(1) http://en.wikipedia.org/wiki/Self-similar#Examples
While not offering an OpenBSD level of security, for a linux distro they offer decent security with their hardened kernel.
I prefer to spend my time doing something other than recompiling. :)