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

The Hidden Backdoors to the City of Cron

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:


Read More

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

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

Get Your Bearing

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

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

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

Sucuri  Sizzle CSS Selector Engine Modified III

Read More

Blackhat SEO and ASP Sites

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

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

Today we found this nice BlackHat SEO attack:

Sucuri SiteCheck ASP Malware

Read More

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

vBulletin Conditional Malware – myFTP.biz Malicious iFrames

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

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

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

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

Screen Shot 2013-06-12 at 12.57.21 PM

This code translates into a hidden iframe:

Read More

Joomla Pharma Hack – Web Malware Removal

In my last SEO poisoning post I wrote about some really nasty conditional malware. In this one, we’re going to revert our attention to the more common variation of the attack, and look at the Joomla CMS.

Joomla Pharma Hack

This variation will be the Pharma hack. As of late, it seems to be going on a rampage on a number of CMS applications and many of its characteristics are similar. The objective appears to be clear though, find its way into Google’s search engine result pages (SERP).

While we can only speculate, the idea is simple – The SERPs are a cached product and as long as they keep the injections benign of malware they increase their odds of bypassing detection until someone spots it and reports.

Read More

SiteCheck – Got Blackhat SEO Spam Warning?

As of late it seems like we’re talking about a lot of SPAM related cases, this post will be no different.

Blackhat SEO

Before you start, let me preface this by saying that clearing a Blackhat SEO Spam injection is probably the biggest PITA (Google It) infection there is. They constantly evolve, making them difficult to detect and they employ both new and old techniques that, even after years, still prove to be annoying. This post will demonstrate one such case.

Read More

Sneaky vBulletin Script Injections

In the past few days/weeks we have been seeing some nasty vBulletin infections that are proving difficult to find. In this post we’ll describe it and what we have done to remove it.

We recently wrote about Conditional Malware, this is but another instance of that. In this instance, the conditions are set around specific referrers and user-agents.

When a user visits the forum via Google search engine result pages (SERP), they are greeted with this payload:

Read More