There has not been much buzz about the recent Beladen attack. Although some sources estimated 40,000 infected web sites, it was clearly not as prominent as the Gumblar. To my mind, it’s because of the elusive nature of the Beladen exploit. It is very difficult to detect. It works intermittently. Only a small percentage of site visitors are exposed to malicious content. Many security scanners just overlook it. Most likely the spread of this attack is underestimated.
In this post, I’ll list every fact I know about the Beladen exploit and hope you will add any missing information in the comments. This format proved to be very fruitful in my recent post about the Gumblar exploit where your 150+ comments made my article the most informative online resource about that attack that most other sites (including major media) referred to.
I hope the information you will find here can help site owners and hosting providers understand the nature of the exploit and get rid of it.
Let me start with admitting the fact that my knowledge about this exploit is still incomplete. However my own blog (before I moved it to a VPS) was affected by this exploit and I went to great lengths to identify the source of the problem. I inspected my whole site, worked with people from Google’s antimalware team, with my blog visitors who had seen antivirus alerts, with my hosting provider and now I have enough information to share with you.
(The main Unmask Parasites site is hosted by a different hosting provider and it has never had any security problems.)
The main thing you should know about this exploit is it’s a server-level exploit. All sites on exploited servers are affected. If you are on a shared hosting plan, there chances are you can’t resolve this issue without help of your hosting provider.
The exploit inserts the following code into random web server responses:
This code sets a cookie which expires in 1000 days (in my case it was sessionid=39128605A531) and loads external script from googleanalytlcs . net/ __utmj . js. Note, this domain doesn’t have anything to do with Google Analytics. It’s just trying to mimic it in hope to look trustworthy.
This script injects a hidden iframe with the following source: 46970e. beladen. net/e/ads.php?b=1010
The iframe tries to load malicious code from other beladen subdomains. “46970e . beladen . net“, “662577 . beladen . net”
Now you can see why Google’s diagnostic pages mention both beladen . net and googleanalytlcs . net for affected websites. My blog is no different.
Whenever I was contacted with such virus alerts by my blog readers (three times during May), I couldn’t reproduce the problem myself. Googler’s that checked my blog with their malware scanners told me, that the percentage of server responses with the malicious code was very small. This makes the detection very difficult. On the other hand, most blog visitors were never exposed to the threat.
When I tried to match my blog’s access logs with requests of visitors who had seen the AV alerts, I discovered that some entries were missing. I.e. every time someone loads a web page in a browser, the browser not only loads the HTML code of the web page, it also loads a bunch of auxiliary files (e.g. styles, images). The set of these auxiliary files is always the same for the same web pages. However, when visitors saw the AV warnings, the sets of requested files were always incomplete. Usually some small .gif file was missing.
The most probable reason is some process intercepts random Apache requests and replaces them with the malicious content. This way, those intercepted requests are not handled by your site and never make it into your site logs.
The above AVG alert screenshot can be used as a proof of this hypothesis. You might have noticed that the “suspicious” file in that alert was “favicon.ico“. It’s a small benign file used by browsers to display a small icon in the address bar next to web pages’ URLs. This file was not modified (actually none of my site files were modified. They are under version control and any changes can be easily detected). The only possibility this file can be considered as malicious, is some man-in-the-middle process intercepted the browser’s request for favicon.ico and responded with the malicious content.
To prove the server level of the exploit I checked the Google’s Safe Browsing status of all site that resided on the same server with my blog. Most of them had never been checked by Google’s malware scanners (the scanners are not as ubiquitous as the googlebot), some sites had been checked more than a month ago, and the only two sites marked as suspicious had the same “googleanalytlcs/beladen” pair on their diagnostic pages.
When I checked neighbors of other affected sites (I found them in the Google’s Webmaster Help forum) I saw the same picture. Other suspicious neighbor sites had the same beladen traces. The reason that only few sites are usually marked as suspicious is malware scanners rarely check smaller/new sites and even when they check affected sites, the problem is not always detected because of the elusive nature of the exploit.
Thanks Kaleh, one of the BadwareBusters.org forum moderator, who pointed me at the David Wenzel’s PDF describing an Apache attack. This document looked like the answer. It had a relevant keyword “beladen . net“, it described malicious processes that modified web server’s responses. It explained how one can detect the malicious processes, but… By the time I sent this document to my hosting provider (remember, I was on a shared hosting plan and was limited in thing I could do myself), the server had been rebooted and no traces of the malicious processes left.
However this was a temporary victory. A few days later my blog visitor reported an antivirus alert again. This time my hosting provider used David’s instructions but couldn’t detect any malicious processes. As a temporary solution, they scheduled Apache to regularly restart, as the PDF document suggested.
We had some doubts that the attack described by David Wenzel was relevant to our case since we couldn’t find neihter malicious processes nor backdoor scripts.
Nonetheless, I decided to move my blog to a VPS (virtual private server) to have more things under control. Ironically, when I logged into my account on the shared hosting to prepare files for the move, I decided to try the “ps -A | grep d” command for the last time, and, to my surprise, the malicious process described in the David’s document was there:
$ ps -A | grep d
16768 ? 00:00:01 dse84abzw1abzw1
And when I checked the same process with a slightly different format of the ps command, it looked indistinguishable from legitimate Apache processes:
$ ps -ef | grep 16768
nobody 16768 1 0 02:44 ? 00:00:01 /usr/local/apache/bin/httpd -k start -DSSL
I immediately contacted my hosting provider and reported the suspicious process. They followed instructions from the PDF file and in just a few minutes they were able to identify the compromised account (it was not mine). They killed the process and contacted the owner of the compromised account. Unfortunately, they couldn’t locate the backdoor scripts and any malicious binaries.
Anyway, the attack described by David Wenzel proved to be real. Be sure to read this document as it describes how the exploit works, how it can be detected and how it can be prevented. It’s a must read for web server administrators. For the rest of us I’ll strip excessive technical details and explain the attack here.
Instructions for hosting providers (if some of your clients say their sites are blacklisted by Google and their diagnostic pages mention beladen . net/googleanalytlcs . net )
When I started the investigation googleanalytlcs . net server was live and served the malicious content. At the same time, Beladen . net resolved to 127.0.0.1 (the address used for local computers), however subdomains of beladen . net had valid DNS records and pointed to valid remote IP addresses.
Update: Beladen seems to have changed its name and now operates from shkarkimi . net. On Safe Browsing diagnostic pages Google now mention malicious domains as:
1 domain(s) appear to be functioning as intermediaries for distributing malware to visitors of this site, including googleanalytlcs . net/.
When I try to ping shkarkimi and its subdomains they resolve to 127.0.0.1. Now both malicious domains and beladen subdomains don’t resolve any more. This attack have been shut down. But security issues revealed by this exploit are still open.
Backdoor scripts still reside on thousands of web servers and hackers can activate new attacks whenever they want. The security hole makes it possible to hijack Apache processes by some compromised limited user account. Unless it is patched, millions of web sites on shared hostings can be affected by hacker attacks even if just a single neighbor account is compromised. And when there are hundreds of sites hosted on a single server the chances that one of them can be compromised are very high. One bad apple spoils the whole bunch.
Do you have anything to add? Was your site affected by this exploit? Do you know what security vulnerability is exploited here? Is it a PHP vulnerability or an Apache vulnerability? Is there any patch? Any other security issues that cannot be controlled by site owners on shared hosting? Or maybe you have found some inaccuracy in my article? Please leave your comments below.