News

New Exploits at Black Hat

Black Hat Technical Information Security Conference highlights JavaScript-based Web applications’ vulnerability to malware.

• By John K. Waters
• 09/15/2008

"Traditional desktop malware authors are starting to use popular, widely employed Web technologies like JavaScript to obfuscate or encrypt their payloads, sneak them past an enterprise's perimeter and deliver them to a victim's browser," Hoffman says. "We know attackers are moving in this direction, and we need to rethink how we're writing the tools to detect this malicious code."

During a presentation at the recent Black Hat Technical Information Security Conference entitled "Circumventing Automated JavaScript Analysis Tools," Hoffman demonstrated some of the techniques that attackers are using to exploit JavaScript to hide their malware from analysis.

One particularly vexing problem, Hoffman explains to RDN, is a fundamental difference between how a security sandbox works and how a browser works. JavaScript allows authors to define a block of code to act as an error handler. A browser will run the code and the error handler, but when a sandbox encounters syntax or runtime errors, it usually shuts down. Malware authors can create deliberate errors in their code to force the error handler to run; if it doesn't run, the malware knows it's in a sandbox.

"As long as the JavaScript code can tell whether it's inside a sandbox or a real browser," Hoffman says, "the sandboxes are going to be ineffective. We really need to improve the sandbox technology we're implementing so that it eliminates this discrepancy."

	"These attackers are sophisticated, and they're using frameworks like Mpack and IcePack to automatically do this encoding and obfuscating and pack their code into the JavaScript."
Billy Hoffman, Manager, Web Security Research Group, Hewlett-Packard Co.

JavaScript Worries
Hoffman, who manages Hewlett-Packard Co.'s Web Security Research Group, is well known in the hacker community for, among other things, uncovering a security flaw in the campus magnetic ID card system at Georgia Tech while he was a student there. He later created StripeSnoop, a suite of research tools designed to capture, modify, validate and analyze data from magstrip cards. Hoffman also worked as a security researcher for SPI Dynamics, which was acquired by HP last year.

Concerns about the impact of JavaScript on the security of Web applications are not new. In 2006, attackers began using JavaScript to exploit cross-site scripting (XSS) vulnerabilities in dynamic Web sites.

"JavaScript is just very hard to secure," says Dr. Brian Chess, chief scientist at Palo Alto, Calif.-based security vendor Fortify Software Inc., "and AJAX proponents are not acknowledging the problem."

In a recently published X-Force report ("2008 Mid-Year Trend Statistics"), the IBM Internet Security Systems research and development team reported on the "evolving story" of browser exploits via code obfuscation. Before 2006, the researchers found, obfuscated Web browser exploits barely registered on their radar. But by the second half of 2007, Web browser attack obfuscation was approaching 100 percent, thanks in no small part to the development of additional obfuscation techniques, such as the multiple layering of self-decoding routines Hoffman describes.

According to the report: "The additional obfuscation techniques included concatenating nearby strings, concatenating out-of-order strings from arrays, random variable names, function reassignment in JavaScript, JavaScript updating the DOM with malicious VBScript (and vice versa) and multi-partite attacks (code spread into multiple script files). Typically, the string obfuscation techniques would occur even after all general self-decoding stages, whether the final malicious script is in JavaScript or VBScript."

VBScript Threat
Attackers continue to find new and creative ways of exploiting this popular dynamic scripter, Hoffman says. "I'm not talking about a bunch of random guys in third-world countries hand-coding everything," he says. "These attackers are sophisticated, and they're using frameworks like Mpack and IcePack to automatically do this encoding and obfuscating and pack their code into the JavaScript."

Another emerging JavaScript exploit Hoffman discussed at the conference combines the popular scripter with VBScript to create malware that slips past the defenses of the Internet Explorer browser. VBScript is the client-side scripting language that was superseded by Windows PowerShell in 2007.

"It's packed in layers, like an onion," Hoffman explains. "The malware authors will push a piece of JavaScript to your browser, which writes out a piece of VBScript, which then writes out a piece of JavaScript, and that's what spits out the nasty malware."

Hoffman points out that security researchers currently have no tools to process one of those layers: the VBScript. One way to encourage the development of those tools, he says, is for Microsoft to release a formal grammar for VBScript.

"I encourage Microsoft to do this so that researchers can develop tools that understand and process the language," he says. "No one is using VBScript anymore, but it's a feature that's still turned on in the browser because it has to be [on] for legacy reasons, and attackers are leveraging that fact. There are a lot of smart people in the research community who will write the tools. We just need the documentation to be able to do it."

Microsoft says that VBScript will continue to be shipped with future releases of Windows, and that the company will continue to provide support for it because of the amount of code written in it.

Christopher Budd, security response communications lead for Microsoft, says that his company has heard Hoffman's recommendations, and is "evaluating possible documentation to build those tools."

"Microsoft takes seriously all discussions with and recommendations from reputable security researchers who share Microsoft's passion for protecting customers," Budd tells RDN in an e-mail.

Hoffman has added his voice to the growing chorus of security mavens putting the security onus on developers.

"Ultimately, it's the developer who has to fix this," he says. "The IT security guys are doing their job. They set up firewall rules, secure the perimeter and implement anti-spam and anti-virus protection, but they're just securing the infrastructure that's serving you an application."

Continues Hoffman: "If that application is broken, old or insecure in some way, there's no magical box that your IT guy can stick in your DMZ that protects you. And even if there were something like that, it would just be a chain-link fence around a fundamentally broken application."