- Date: January 17, 2008
- Author: Don Jackson
SecureWorks, one of the leading Security-as-a-Service (SaaS) providers in the market, and Senior Security Researcher Don Jackson have discovered a protection for the mass attack being launched against Linux/Apache servers. Previously, researchers had estimated that the attack only affected several hundred websites, however, SecureWorks discovered on Tuesday of this week that it has actually infected approximately 10,000 websites. The compromised websites, in turn, can infect website visitors. If infected, the malicious code can steal bank usernames and passwords, SSNs, credit card numbers, online payment accounts, basically any information a computer user puts into their web browser. The malicious code can also own the victim's computer.
The 10,000 infected website estimate has been derived from the number of alerts SecureWorks analysts have seen on the countermeasures the company put in place to protect its clients from the malware. Most of the sites cited in previous articles are still infected and serving up malicious code. Most of the top antivirus vendors are now detecting the malware being used in these attacks.
Not only are there U.K. and Indian websites infected but many other English speaking sites are infected as well.
SecureWorks already had countermeasures in place for its clients to protect against the attack and has notified research partners, anti-virus vendors and law enforcement officials of their new research.
Vulnerable Applications to the WebServer Attacks
The infected webservers serving the malicious JavaScript are not just taking advantage of QuickTime exploits, but a bunch of others, including:
- MDAC (Using XMLHTTP and ADODBStream)
- Slide (Heapspray)
- VML (KeyFrame)
- QuickTime (RTSP directly and through a .MOV file, in case the victim unregistered the RTSP URL handler as described in the workaround)
- SuperBuddy (AOL, LinkSBIcons)
- AudioFile (NCTsoft)
- GOM (GomManager openURL)
- WebFolderView (SetSlice)
- Yahoo! Messenger (GetFile)
Components of the Webserver Attacks
These exploits attempt to install a copy of Rbot and some other malware of the attacker's choice. These are typically large files (144k - 433k) and are "packed" in a way that avoids alerts for suspicious use of packers, tools used to compress and scramble code in executable files. These use the PE_Patch packer and UPX algorithms, but not other UPX signatures that might cause an alert. It is designed to look as close to a well-formed PE file as it can get. Code is arranged in a fashion typical of the Sdbot/Rbot kits. It's not just compressed but padded in a way that it scores below thresholds on most Shannon entropy tests and other heuristics which look for known PE header abnormalities like 0 CRC values or UPX segment names, and yet it's jumbled well enough to hide most obvious strings or known code blocks (like the Agent downloader feature) that match byte pattern signatures, even for packer stubs.
The EXE name is different each time too. It is being hosted on the infected Webservers in the root directory with names like "grhdbkcq" or "zmulpqbk". The EXE is added by the exploit code as the local filename. Infected machines will have files like "C:\mosvs8.exe" or "C:\win7265.exe" (the digits are random).
The way the JavaScript randomizes its filename and the way the executables are renamed is all made possible by a "webserver hijacker" kit, basically a Linux Trojan that infects Apache, handles requests and writes the data out to the HTTP response. Neither the JavaScript file nor the Rbot executable is actually a file located on the server (they are virtual, created by the so-called webserver hijacker.
This type of malicious code has been used in the past to redirect people from compromised sites to porn sites if -- and only if -- coming from a search engine result, for example. Type the URL into the address bar, or visit through a link on a news site, and the regular page loads. This new code would be a step up in sophistication from that simple hack.
How is the Malicious Code Infecting the WebSites?
Traffic loads and evasion techniques make it hard to pin down the exact moment the webserver becomes infected. We have evidence that compromised FTP and CPanel credentials are being used in these attacks.
Website administrators have been removing and cleaning their Webserver files, and even reinstalling their OS just to find out their website is again serving malicious "virtual" JavaScript files and Rbot executables just hours later.
Some fear that they can't see the files (xybjq.js, etc.) because they are infected with a rootkit. This is on the right track. It's not an LKM (Loadable Kernel Module) rootkit. Some web hosting administrators actually reloaded using a monolithic kernel (no LKM support) and still got hacked again.
Some suggested a rootkit like SucKIT, which is loaded through /dev/kmem instead of as a module. However, that was ruled out when one admin applied the GRSecurity kernel patch (which inhibits writing to /dev/kmem) to his monolithic kernel, and was subsequently compromised.
This is actually just an Apache runtime patch. It works by injecting code into the Apache processes. Basically, the attacker installs code that modifies Apache memory to monitor requests and inject the script tag, script contents, or the Rbot executable, depending on the request into the response data.
If the code infects the current running Apache process, Apache can spawn new (uninfected) processes to handle more requests. To account for that, the code redirects the system call for all running Apache processes using RPI (Runtime Process Infection), a technique described in a popular hacking e-zine. It employs shared objects or ".so" files -- which Apache can load, if written to the spec, as a module -- and the ptrace() function.
Actually, the techniques used will not work if Apache is started as root. If Apache is started as root, when it performs the standard startup setuid() call, the old and new uid won't match and the kernel clears the dumpable flag in the process structure. But this flag is required by ptrace() which is key to infection. This is one of those rare times that doing things as root affords protection. However, this is an exception to best practices, and we advise sticking to best practices.
In order for the infection to work, dynamic module loading must be enabled, which is the default.
How to Protect Against the Website Attack?
Protection for Organization's Websites: In order for an organization to protect their website from this attack they need to disable dynamic loading in their Apache module configurations.
Protection for Website visitors: This is designed to attack Windows PCs. Website visitors can avoid infection by the malware this attack distributes by making sure all anti-virus signatures are up to date and that all vulnerable software is patched. No previously unknown or 0-day vulnerabilities are used in this attack.
Who is Behind the Attacks?
Investigators have so far not been able to identify the individual or group behind these attacks. The attacks do not match any typical attack patterns from any of the well-known Russian or Chinese groups. Some signs point to it being Western European or even North American in origin. An analysis of the malware's command and control might be useful in proving any theories about origins. An investigation is ongoing.. However, whoever is behind the attacks, the underground hacking community is praising their recent success as seen on various underground forums.