News

Apocalypse How? Next-gen Viruses, Worms

• By Shawna McAlearney
• August 9, 2006

Recent worms and viruses targeting Web apps, like MySpace and Yamanner, didn’t have much impact, but may only be the tip of the iceberg. Researchers warn that the next iterations of these attacks—attacks that could, for example, be used to devastate the stock market—are imminent and could have catastrophic results.

"It used to be that attackers designed code to steal data from individuals—now they're designing worms and viruses to spread across Web sites to steal data in larger quantities," says Billy Hoffman, lead R&D engineer for SPI Dynamics. "The type of damage these things can do is growing and it's only a matter of time before we see attacks we currently consider to be worst-case scenario."

Though he labels recent Web malware payloads “silly,” Hoffman expects this to change—and soon. In a presentation at the Black Hat security conference, he outlined attack examples, including one that used Google to capitalize on multiple SQL injection vulnerabilities in different Web apps, and another he called “1929” in reference to the stock market crash.

In that attack, a virus uses cross-site scripting (XSS), JavaScript and AJAX to infect a major stock trading site and propagate. AJAX can then be used—by either the virus itself or a third party—to buy and sell stocks on behalf of any user who viewed the infected pages. It could also be used to randomly build stock symbols, modify price/earnings ratios and trade volume thresholds, and buy high and sell low.

“It would inflict damage to the stock market as thousands of users sell otherwise healthy stocks,” says Hoffman. “Eventually the stock trading site will find the virus, remove it and attempt to sort real trades from virus trades, but it does not really matter in the end—external brokers will have made trade decisions based on the effects of the virus’ trades and affected the entire stock market.”

“The 1929 scenario could happen using cross-site scripting and AJAX,” adds Hoffman.

Roger Thompson, CTO, Exploit Prevention Labs, believes the attack and its outcome are plausible. “I think it behooves us all to keep an open mind,” he says. “However, we're screwed if we get hit by a meteorite too, but no one builds meteor shelters.”

“Profit is the driver these days,” adds Thompson. “If someone can figure out how to make a buck out of it, it'll happen for sure.”

A big problem is that corporate-types don't or can't patch, says Thompson, who notes that a company he spoke to recently has 8,500 PCs and is still running Service Pack 1. “Unlike Joe Sixpack, they can't patch every month because they have too many home grown apps that they can't afford to break.”

So, if patching flaws isn’t the answer, what can be done to mitigate such a threat?

"One of the most important things developers can do is use a whitelist rather than a blacklist," says Hoffman.

Instead of using a blacklist to screen for specific items you know to cause problems, he recommends using a whitelist where you input only data you know is safe to help limit attacks as they continue to evolve.

And, according to Gartner Inc., more than 70 percent of attacks against a company’s Web site or Web app come at the app layer not the network or system layer.

SPI Dynamics recommends taking several important steps to write more secure Web apps:

• Fix vulnerabilities to stop initial injection and further propagation, as well as payload execution;
• Be aware that everything can be modified, including “hidden” HTML input tags, cookies, URL parameters, POST data and HTTP headers;
• Never use input you get from the client without sanitizing it
• Enforce data types and formatting, including length restrictions and escaping characters to avoid SQL injection and XSS attacks;
• PHP and ASP have built in functions that can help. A well-placed RegEx can stop most attacks;
• Input validators should be implemented on both sides of a Web application;
• Frontend code should properly represent backend code and backend code for an HTML FORM that uses POST should only read values that were posted;
• Applications should only provide enough functionality to work—for example, do not use scripting technologies if you have static content.

Most developers will care about preventing these attacks, says Hoffman, "those who don't will have facilitating identity theft and exposure of confidential data on their consciences."

Read what other experts had to say about Weakness in Web 2.0