Website Malware: Mobile Redirect to BaDoink Porn App Evolving

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!

Website Security Analysis: A “simple” piece of 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


Read More

Case Study: Complexities of “simple” malware

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.

viaworm1

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.


Read More

WordPress Plugin Alert — LoginWall Imposter Exposed

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.

plugin

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:

An example of a malware payload
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.

Take Back Your Internet – Demand a Safer Web

Take back the internet
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.

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.

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

PHP Backdoors: Hidden With Clever Use of Extract Function

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:


Read More