Answer: Backdoors are tools used by attackers to help them maintain access to the sites they compromise. The harder it is to find the backdoor, the better for the attackers, since it will likely remain undetected allowing them to reinfect or regain access to the site whenever they want.

This backdoor is a very good example of a sneaky one. No alpha numeric characters, no direct function calls or anything like that. So what is it doing? We asked one of our developers, Yorman Arias, to help decode it.

We often talk about websites being compromised and injected with malware that redirect users to exploit kits. We unfortunately don’t give you a complete picture of what the distribution payload is doing on your local machine very often. Today we’ll try to improve that analysis by giving you a more complete picture of the full life cycle of a specific distribution payload.

In this example, we’ll be showing you how an attacker is injecting a site with a dynamic iFrame generator, which then attempts to install a malicious payload on your machine. More importantly, we’ll show you what that file is doing locally.

We were actually very lucky in this instance. Instead of a banking trojan, we were able to get our hands on a payload that is designed to steal not only your Browser information, but your FTP credentials as well. This can then be used to compromise any website you own, completing the life cycle of the injection:

In this example we explained how it was a very simple approach to displaying the version of PHP on your server. There were a lot of questions following that saying, well what’s so harmful in that. Etc… With little help from us the attackers go on to show us what they can do.

Taking a Look at the Attacks

In this section I’ll show you three of the various attacks we’re seeing. In each you can see how they abuse the mfunc vulnerability, one in a more traditional approach of injecting a backdoor and other in a more creative way that allows them to abuse HTTP headers. In either case they all seem to be getting passed via comments, and we give an example of that below. This is obviously for educational purposes only.Read More

Drupal core’s Image module allows for the on-demand generation of image derivatives. This capability can be abused by requesting a large number of new derivatives which can fill up the server disk space, and which can cause a very high CPU load.

This vulnerability has been patched and it’s recommended that all Drupal sites upgrade to the latest version, 7.20.

I will say this about this announcement, I kind of wish other platforms would do something similar to disclose security issues to the public. Kudos Drupal security team for your approach to disclosure.

In case you don’t see it, a month and change ago it was at 0 detections of 46 and today it’s 20+ detections of 46. Nice!

That being said, what we found a month ago and what is being discussed today are two different things.

The Discussion

What is important to understand is the differentiating factor between what we found and what is being reported, is that in our case it was a full modification of SSHD. In this case, a module is being injected to modify the libraries used by SSHD.Read More

You are receiving this email because you have opened a ticket with our support staff in the last 6 months. cPanel, Inc. has discovered that one of the servers we utilize in the technical support department has been compromised. While we do not know if your machine is affected, you should change your root level password if you are not already using ssh keys. If you are using an unprivileged account with “sudo” or “su” for root logins, we recommend you change the account password. Even if you are using ssh keys we still recommend rotating keys on a regular basis.

As we do not know the exact nature of this compromise we are asking for customers to take immediate action on their own servers. cPanel’s security team is continuing to investigate the nature of this security issue.

–cPanel Security Team

The cPanel product is very popular and used by hosts like Bluehost, HostGator, InMotion and many others. They in turn service 100’s of thousands of website owners website owners. While the scale of the compromise is unknown, an attacker targeting an environment like this is surely interested in one thing – data.

Highly recommend that any hosting company that uses the cPanel product force a reset of all account credentials.

******Update: Feb 22, 2013 – 16:16 PST********************

Interestingly enough, one of our engineers was also notified by their host, WiredTree, of a possible correlation between the cPanel compromise and the recent rumblings about a root-level exploit in RedHat/CentOS servers. On February 18th, they sent out the following notice:

I am writing you tonight to inform you that we have disabled access to port 22 (default SSH port) on your server as temporary precautionary security measure. Our security team has good reason to believe there is a root-level exploit in the wild for RedHat/CentOS servers as compromises have been reported on WebHostingTalk, Reddit, as well as on our own network and at other providers we have talked to. There have been a number of similarities in the attacks and that is why we have decided it is best to block this port temporarily until the attack vector is determined.

Today, WiredTree, sent out the following email in response to our analysts inquiry for more information:

We recently emailed you to inform you that we temporarily disabled access to port 22 (default SSH port) on your server as a precautionary security measure. This block has now been lifted.

Our security team had been following some wide spread reports of root level compromises over the course of a couple of weeks. As time went on more and more were being reported, and we saw a handful on our network. One thing all of the servers compromised had in common was that SSHd was enabled with password authentication. We blocked SSHd temporarily as a precautionary measure, however we have since learned that SSHd was not the actual culprit.

We have been informed by cPanel that one of their servers in their Technical Support department was compromised and after further investigation, we have found that servers that were compromised had a cPanel ticket opened at one point where root level SSH access was given to cPanel Support so they could log in from their support offices. This extends back as far back to tickets being opened with cPanel support in October 2012.﻿

Can the two issues be related? Are any other hosts seeing similar issues and care to give more information? If this is in fact true then this is a pretty serious concern, not just for hosts, but website owners alike that depend on these products for their day to day administration and management.

When you’re remediating servers, one of the things you’re always looking for are any traces that show the attacker is trying to cover their tracks. In one such incident, right as we were responding to an attack, the attacker removed all the logs on the server, to include some of our tools designed to detect. We weren’t done configuring and almost missed it, but fortunately we were actively tailing all the logs and saw the attack. We obviously got the upper hand on the attack and won the battle, but it’s something everyone needs to be accounting for.

This is nothing new, any good attacker – good or bad – knows that an attack is comprised of four things:

Reconnaisance

Identify vector

Exploit vector

Cover tracks

As we continue to see a growing divide between enterprise level attackers and web attackers, the last step is often the one that is overlooked. Today however we came across a little gem on a clients site.

It appears the attacker decided on trying to gain access via a Remote File Inclusion (RFI) attack. Fortunately, they weren’t successful. But in the process they left a very small trail on the servers error logs, using that footprint, we were able to follow the rabbit home. Of the various things we found, there was one of particular interest to this post – a script designed to clean up the attackers tracks.

It’s always easy to say, “Hey, they do this folks, they cover their tracks!!” It’s something completely different to actually show you how they do it.Read More

This week, we detected unusual access patterns that led to us identifying unauthorized access attempts to Twitter user data. We discovered one live attack and were able to shut it down in process moments later. However, our investigation has thus far indicated that the attackers may have had access to limited user information – usernames, email addresses, session tokens and encrypted/salted versions of passwords – for approximately 250,000 users.

They go on to explain what they have done for those 250,000 accounts but not what they have done for all users. For that reason, we would encourage all Twitter users to follow the same precautionary steps they have done for those 250,000 users and change your own passwords as well. When wondering about passwords be sure to read our post on the password dilemma. Also don’t be fulled, if their environment is owned you can change it 150 times it won’t matter.

What you can do is start using password managers and unique passwords for each site. The last thing you want to do is use the password for your bank with your Twitter account. That’s just setting yourself up for a very bad day.

Good news though, this wasn’t the work of amateurs:

This attack was not the work of amateurs, and we do not believe it was an isolated incident. The attackers were extremely sophisticated, and we believe other companies and organizations have also been recently similarly attacked.