News

New Exploits at Black Hat

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

There are days when JavaScript seems like a gift to malware authors, says security guru Billy Hoffman, and it's fast becoming a gift that keeps on giving.

"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."

Billy Hoffman, Manager, Web Security Research Group, Hewlett-Packard Co. "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."

Microsoft Lays out Security MAPP


Microsoft showed up at this year's Black Hat Technical Information Security Conference for only the third time in the show's history to announce an expansion of its Trustworthy Computing initiative that will provide partners with early access to security information.

Over the last few years, Microsoft's security group has worked to establish a fast, efficient and predictable communications process around reported exploits. Unfortunately, malicious hackers are quick to target flaws addressed by new security updates from Microsoft, sometimes within hours of the release.

"Look at what happens right after a patch is announced," says Gary McGraw, author of "Software Security: Building Security In" (Addison-Wesley, 2006). "Almost immediately, the bad guys start targeting the unpatched versions of the software that are still out there. It's like a big, red sign over the hole."

To thwart these opportunistic malefactors, Microsoft is launching a new initiative, called the Microsoft Active Protections Program (MAPP), which gives security software providers an advanced look at vulnerabilities Microsoft plans to address in its monthly security updates.

According to Steve Adegbite, senior security program manager in the Microsoft Security Response Center, MAPP will allow vetted security software providers early access to the technical details of the vulnerabilities the company is dealing with in its monthly security updates. In a post at his ecostrat blog (http://blogs.technet.com/ecostrat) at the time of the announcement, Adegbite wrote, "Basically, in doing this, we're betting that cutting out the time to reverse engineer our security updates will give valuable time back to the defenders to focus on protection enhancement and faster delivery."

At the same time, Microsoft unveiled its new Exploitability Index. The index should help partners gauge how likely a reported vulnerability in a security patch is to draw attacks.

Back in 2001, Microsoft chairman Bill Gates penned his famous "Trustworthy Computing" memo, and started the ball rolling on significant changes in his company's development processes. Since then, Microsoft's Trustworthy Computing initiative has produced quantifiable improvements internally, says Gartner Inc. analyst Neil MacDonald.

"You can point to real data that show a release-over-release reduction in the number of critical vulnerabilities in the company's products," MacDonald says. "No one writes perfect code, but is Microsoft producing better code now than they did four or five years ago? Absolutely."
-- J.K.W.

About the Author

John K. Waters is the editor in chief of a number of Converge360.com sites, with a focus on high-end development, AI and future tech. He's been writing about cutting-edge technologies and culture of Silicon Valley for more than two decades, and he's written more than a dozen books. He also co-scripted the documentary film Silicon Valley: A 100 Year Renaissance, which aired on PBS.  He can be reached at [email protected].

comments powered by Disqus

Featured

Subscribe on YouTube