daily online news

The mystery over a cluster of poisoned websites distributing a toxic malware cocktail may be better understood but it's still not solved.

Five days ago, we wrote about the infection of several hundred websites that was unlike anything seasoned researchers had seen before. Mary Landesman, a cyber gumshoe who first brought it to public attention, asked for help from other security pros in figuring out how the unusual new technique worked. And help is what many of her peers have provided.

The sites host malicious javascript that is spontaneously created and randomly named only after a visitor hits the home page. That's unlike any other mass infection most researchers have seen before. Usually, infected sites merely host pointers to attacker-controlled servers, which in turn are used to host malware with static file names.

The innovative technique is much more than an academic curiosity. Because the rogue code does not exist on any server until an end user visits it, the javascript remains invisible to site administrators. The randomness also prevents most antivirus programs from detecting the javascript. Equally frustrating, it prevents researchers from running a simple web search that ferrets out every web address where the attack code is hosted.

From her perch at ScanSafe, a company that provides real-time intelligence to large businesses about malware-spreading sites, Landesman could see several hundred websites exhibiting the odd behavior. Based on intelligence from firms with sensors elsewhere on the net, it turns out that the number of infected sites is much bigger.

According to independent reports released earlier this week by SecureWorks and Finjan, 10,000 or more websites are similarly infected. As of Tuesday, almost all of these were still infected. They are churning out malware, which preys on at least nine different vulnerabilities in programs such as the QuickTime media player, Yahoo! Messenger and Windows operating systems to install a backdoor on end users' computers.
Alive and kicking

Attackers "want to have their malicious code live and kicking for a longer time so it will be much more difficult to identify that this website was compromised," says Yuval Ben-Itzhak, chief technology officer at Finjan, a security provider that's been monitoring the attacks since December. "The longer they will have the malicious code out there, the better the chances they'll infect people."

Once the malware successfully finds an unpatched vulnerability, it installs the Rbot Trojan, or one of its variants. Many antivirus programs still fail to detect the exploit.

The infection dates back at least to late November, according to this thread, which was dredged up by a Reg reader in response to our earlier story. The online discussion shows web administrators from many companies reporting infections that were using multiple exploits to attack end users, and documents their difficulty in disinfecting the systems.

Landesman also reports how hard it is to remove the attack code from tainted web systems. Over the weekend, she noticed two modules - one called mod_bwlimited and the other enable_dl - in the Apache webserver that were responsible for transmitting the randomized malware onto end users' machines. But when she disabled them, she was dismayed to find the changes reversed and that the machines had soon resumed their attacks.

Initially, ScanSafe and SecureWorks researchers suspected the attacks were the result of a web-side rootkit that creates and delivers the randomized files after a victim visits the site. After an earlier version of this story was published, however, Don Johnson of SecureWorks called to say he no longer believes that is the case.

Instead, he says, attackers have managed to install an Apache runtime patch onto the infected machines. The patch launches code into the Apache memory that monitor requests and transmits the randomly named payload into the response data. Apache modules generally have the ability to load or unload new modules without root access, and that seems to be the case here.

But so far no-one - not ScanSafe nor SecureWorks, Finjan or any other researcher we've contacted - knows for sure how these mostly mom-and-pop ecommerce sites are getting infected in the first place. The vulnerability is unlikely to reside in Apache, given the sheer number of variants that different infected machines are running.
Access all areas

Infected sites also use a wide number of different web hosts, making that an unlikely entry way for attackers. While Cpanel, a tool for remotely administering the site, appears to be modified by the infection, Landesman says her research suggests that is also not the way attackers gain access.

This is a problem, because if you don't know how thousands of of machines are being commandeered, you can't prevent tens of thousands more from suffering the same fate.

"Every time I think I have some common thread, I find some exception to the rule," says Don Jackson of SecureWorks. "How do we stop websites from experiencing this again? We really don't know what controls we need to put in place."

If Jackson's theory about the runtime patches proves correct, it's likely they were installed using compromised passwords for FTP servers or hosting applications connected to the infected web server. He posits a modified dictionary attack could have been the initial way in.

What's really needed now is for operators of websites that are infected to step forward and allow a trusted researcher to inspect the machine. (One webmaster from a site mentioned in Friday's article volunteered to help Landesman, but by then he had already wiped his system clean, removing crucial evidence in the process.)

If you've seen the behavior described above lurking on your site, please leave a comment below, or contact your reporter using this link. Similarly, if you're a researcher with insight into this program please do the same.

With a little more digging, we'll solve this mystery.