msgbartop
Unmask Parasites - Check your web pages for hidden links, iframes, malicious scripts, unauthorized redirects and other signs of security problems.
msgbarbottom
Loading site search ...

Lorem Ipsum and Twitter Trends in Malware. Update.

   18 Feb 12   Filed in Website exploits

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:

<IfModule mod_php5.c>
php_value auto_append_file "google_verify.php"
</IfModule>

<IfModule mod_php4.c>
php_value auto_append_file "google_verify.php"
</IfModule>

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

  1. Scan your server for .html and .php files (usually ‘index‘, ‘default‘, ‘main‘) that contain the malicious code. Examples of the malicious code:
  2. Remove the the malicious code from your files.
  3. Scan server for google_verify.php files that contain the above malicious code. Delete them.
  4. 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.
  5. 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.

  1. 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.
  2. 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.
  3. 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.
  4. 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:

Reader's Comments (4)

  1. |

    Thank you for your interesting posts.

    Beside the aforementioned modifications of .html and .php files the attackers also placed a PHP-Webshell onto the server. Since we have had several affected client accounts, we could identify the following general scheme:

    -The Webshell was in all cases placed in the main directory of a website and named after the particular folder. For example: /home/www/htdocs/site5/site5.php

    -The our variant is 64,5 kb large and it has the md5sum cf0a09cdac130669a3e7d9045726647b.

    - A comment in the first line reads “Web Shell by oRb”

    -The shell is hidden for SearchEngine Bots:


    if(!empty($_SERVER['HTTP_USER_AGENT'])) {
    $userAgents = array("Google", "Slurp", "MSNBot", "ia_archiver", "Yandex", "Rambler");
    if(preg_match('/' . implode('|', $userAgents) . '/i', $_SERVER['HTTP_USER_AGENT'])) {
    header('HTTP/1.0 404 Not Found');
    exit;
    }
    }

    - It is secured by an hardcoded md5 hashed password

    if(!empty($auth_pass)) {
    if(isset($_POST['pass']) && (md5($_POST['pass']) == $auth_pass))
    WSOsetcookie(md5($_SERVER['HTTP_HOST']), $auth_pass);

    if (!isset($_COOKIE[md5($_SERVER['HTTP_HOST'])]) || ($_COOKIE[md5($_SERVER['HTTP_HOST'])] != $auth_pass))
    wsoLogin();
    }

    I hope, this will help other affected admins.
    Steven

    • |

      Thanks Steven,

      The same web shell with the same MD5 hash of a passwords was reported by foks. Actually, this “Web Shell by oRb” is one of the most prevalent web shells. Other attacks use different passwords and usually encrypt the web shell file.

      The naming convention of the web shell file that you noticed may really help some webmasters find the backdoors.

      It is important to find and remove all such shell, as they provide literally full access to your sites.

  2. |

    Hi, we got the same infection on June 12th, apparently from an Ukraine IP.

    All index, home files were infected (also a maintenance.htm file) and the same PHP Webshell with md5 cf0a09cdac130669a3e7d9045726647b was placed in the root with the same folder name (public_html.php).
    Same .htaccess infection and google_verify.php files.
    I’ve also found a pearl file named “hosting-dont-delete.pl”

    Thanks for this post guys!

  3. |

    In addition to this already good info. look for this in yours index.htm(l)and *.js files: document.write('.vb_style_forum {filter: alpha(opacity=0);opacity: 0.0;width: 200px;height: 150px;}');

    in general search for “.vb_style_forum” its a good indication that you’ve been hacked!

    Cheers, D.