Exorcising your digital demons

Most people are familiar with Shakespeare’s The Tragedy of Macbeth. Of particularly common usage is the famous line uttered repeatedly by Lady Macbeth, “Out, damn’d spot! Out, I say” as she tries to wash imaginary bloodstains from her hands, wracked with the guilt of the many murders of innocent men, women, and children she and her husband have committed.

It might be no surprise to find a similar situation in the datacenter, late at night. With the background of humming servers and cozily blinking lights shedding a soft glow upon the floor, you might hear some of your infosecurity staff roaming the racks and crying out “Out, damn’d bot! Out I say!” as they try to exorcise digital demons from their applications and infrastructure. 

Because once those bots get in, they tend to take up a permanent residence. Getting rid of them is harder than you’d think because like Lady Macbeth’s imaginary bloodstains, they just keep coming back – until you address the source.

One of the ways in which a bot can end up in your datacenter wreaking havoc and driving your infosec and ops teams insane is through web application vulnerabilities. These vulnerabilities in both the underlying language and server software as well as the web application itself, are generally exploited through XSS (Cross-site scripting). While we tend to associate XSS with attempts to corrupt a data source and subsequently use it as distribution channel for malware, a second use of XSS is to enable the means by which a bot can be loaded onto an internal resource. From there the bot can spread, perform DoS attacks on the local network, be used as a SPAM bot, or join in a larger bot network as part of a DDoS.

The uses of such deposited bots is myriad and always malevolent.

Getting rid of one is easy. It’s keeping it gone that’s the problem. If it entered via a web application it is imperative that the vulnerability be found and patched. And it can’t wait for days, because the bot that likely exploited that vulnerability and managed to deploy the bot inside your network is probably coming back. In a few hours. You can remove the one that’s there now, but unless the hole is closed, it’ll be back – sooner rather than later.

According to an ARS Technica report, you may already know this pain as “almost all Fortune 500 companies show Zeus botnet activity”:

Up to 88% of Fortune 500 companies may have been affected by the Zeus trojan, according to research by RSA's FraudAction Anti-Trojan division, part of EMC.

The trojan installs keystroke loggers to steal login credentials to banking, social networking, and e-mail accounts.

This is one of those cases in which when is more important than where the vulnerability is patched initially. Yes, you want to close the hole in the application, but the reality is that it takes far longer to accomplish that then it will take for attackers to redeposit their bot. According to WhiteHat Security’s Fall 2009 Website Security Statistics Report a website is 66 percent likely to be vulnerable to an XSS exploit, and it will take an average of 67 days for that vulnerability to be patched.

That’s 67 days in which the ops and infosec guys will be battling with the bot left behind – cleaning it up and waiting for it to show up again. Washing their hands, repeatedly, day and night, in the hopes that the stain will go away.

The best answer to keeping staff sane is to employ a security solution that’s just a bit more agile than the patching process. There are several options, after all, that can be implemented nearly immediately to plug the hole and prevent the re-infection of the datacenter while the development team is implementing a more permanent solution.

• Virtual patching provides a nearly automated means of plugging vulnerabilities by combining vulnerability assessment services with a web application firewall to virtually patch, in the network, a vulnerability while providing information necessary to development teams to resolve the issue permanently.
• Network-side scripting can provide the means by which a vulnerability can be almost immediately addressed manually. This option provides a platform on which vulnerabilities that may be newly discovered and have not yet been identified by vulnerability assessment solutions can be addressed.
• Web application firewall can be manually instructed to discover and implement policies to prevent exploitation of vulnerabilities. Such policies generally target specific pages and parameters and allow operations to target protection at specific points of potential exploitation.

All three options can be used together or individually. All three options can be used as permanent solutions or temporary stop-gap measures. All three options are just that, options, that make it possible to address vulnerabilities immediately rather than forcing the organization to continually battle the results of a discovered vulnerability until developers can address it themselves.

More important than how is when, and as important as when is that the organization have in place a strategy that includes a tactical solution for protection of exploited vulnerabilities between discovery and resolution. It’s not enough to have a strategy that says “we find vulnerability. we fix. ugh.” That’s a prehistoric attitude that is inflexible and inherently dangerous given the rapid evolution of botnets over the past decade and will definitely not be acceptable in the next one.

John Pescatore, vice president and distinguished analyst, speaking about the enterprise threat landscape Tuesday at the Gartner Security and

Risk Management Summit, said rapid changes are taking place in the way IT organizations deliver services, largely via virtualization and cloud computing , and the way businesses consume them, which create infrastructure breakage points ripe for exploit.

"Ninety percent of attacks are exploiting vulnerabilities we already knew about, by missing patches, deciding not to patch, or uses of technology in which we made the decision to deploy without putting security controls on it," Pescatore said. "Less than 1% are zero-day attacks; the other 99% are exploited configurations and unpatched machines that the simplest vulnerability scan would've found."

And since attackers have had so much success using bots to take advantage of these vulnerabilities, Pescatore said that trend is likely to continue through 2012, when the ongoing cat-and-mouse game between attackers and enterprise defenders leads to the next threat delivery breakthrough.

With IT and security resources always at a premium, Pescatore said enterprises must prioritize their defensive efforts simply by asking themselves what an attacker would want to get from them; in most cases it's personally identifiable information (PII) in the form of credit card and Social Security numbers, or sensitive intellectual property. [emphasis added]

Gartner: Enterprises must learn to detect botnet threats 

It’s going to get harder and harder to exorcise those digital demons. That means the best strategy is to be proactive; to ensure the proper protections are in place before you go live. To provide developers with the training and tools to ensure that known vulnerabilities are addressed, and that the infrastructure or application is sanitizing inbound data and scrubbing outbound data.

Protecting the organization is no longer about which group or which solution should or shouldn’t be responsible for web application security. When web application vulnerabilities took legs and began to be a problem for the entire datacenter and the business, it became more about enabling solutions and less about who or how or what.

Patch the vulnerability first, in whatever way can make that happen immediately. Then you can discuss and debate about what’s the proper long-term solution for your organization. After all, no one would suggest that the little Dutch boy who stuck his finger in the dike should stand there forever, holding back the flood of water. But no one would suggest he was wrong to do it, either.