By Dan Goodin in San Francisco
16 Jan 2008
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.
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
randomness also prevents most antivirus programs from detecting the
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
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
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
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.
Subscribe to InfoSec News