Windigo Linux Analysis – Ebury and Cdorked

Our friends over at ESET released a very detailed document about the Windigo Operation. The Windigo Operation has been responsible for the compromise of thousands of Linux servers over the years. When you hear terms like Ebury, CDorked, Calfbot and others, they are all related to each other.

Over the last few years, our team has been handling and fixing compromised servers and we can attest to how complex the clean up for this infection can be. We’ve seen that the servers we’ve fixed have been misused for distribution of malware, SPAM and, in some cases, to steal credit cards on compromised web servers used for e-commerce.

Windigo Timeline

The timeline released by ESET matches what we have been seeing and it goes back to 2011 when Linux/eBury was first seen. It goes through many evolutions, including our joint analysis of CDORKED on 2013 and the SSH backdoors:

Windigo Timeline

Windigo IOC’s

If you run a Linux server and you are worried it might be infected, they provide a few techniques (indicators of compromise) to check if the server is hacked.

1- For Linux/Ebury. Run the ssh -g command. If it returns an error about missing argument, you know you are compromised.

2- For Linux/CDorked. Run curl to favicon.iso and see if you get redirected to Google.com. If you do, you know you are compromised.

These apply to the latest versions of the malware. Old versions have different indicators and we explain them on our previous blog posts. Note that with the release of this document, the malware authors will likely change operations and the behavior of the code. So do not expect it to last long.

We recommend reading the whole PDF here:

http://www.welivesecurity.com/wp-content/uploads/2014/03/operation_windigo.pdf

If you need help cleaning up a compromised Linux server, let us know.

Darkleech + Bitly.com = Insightful Statistics

This post is about how hackers abuse popular web services, and how this helps security researchers obtain interesting statistics about malware attacks.

We, at Sucuri, work with infected websites every day. While we see some particular infections on one site or on multiple sites, we can’t accurately tell how many more sites out there are infected, and how many people were exposed to that malware. All we can do is estimate.

Most estimations are based on data that can’t provide the whole picture such as number of detections in our SiteCheck scanner, number of cleanup requests, number of posts about a particular problem in webmaster forums. This only helps to tell whether it’s something “major” or “minor”.

Like any other firm out there, sometimes we can make some good educated estimates. For example, we can target specific Google searches that reveal the number of sites that contain some text, or URL specific to a particular attack. Another example is if an attack uses one specific URL (or a few well known URLs), then Google Safe Browsing reports also help estimate number of infected sites. These Google-based approaches are more precise, but they don’t work for most attacks that frequently change domains and have no artifacts that can be found in search results.

If security researchers are quite lucky, they might find an attacker’s unprotected (or poorly protected) Control Panel that contains all the statistics about infected site, clicks, exploits, etc.

This post will be about a different and quite unusual way of obtaining data about activity of a server-level attack that is known for being hard to detect and track.


Read More

Ubuntu Forums Hacked

Ubuntu’s official forum web site (ubuntuforums.org) was hacked, defaced and all user names and
passwords stolen. The forum was very popular with over 1.8 million registered users. The site is now disabled with this warning:

What we know:

-Unfortunately the attackers have gotten every user’s local username, password, and email address from the Ubuntu Forums database.

-The passwords are not stored in plain text. However, if you were using the same password as your Ubuntu Forums one on another service (such as email), you are strongly encouraged to change the password on the other service ASAP.

The site was running vBulletin and according to some sources, it was outdated and didn’t have the admin panel protected. During the time it was defaced, it was redirecting to “ubuntuforums.org/signaturepics/Sput.html”, which had this image:

Ubuntu forums hacked

Size of the attack and consequences

The Ubuntu forum was very large with over 1,800,000 registered members. Even though the passwords were not stored in plain text, they should be considered compromised and known by the attackers. And since the site used vBulletin, it is likely that they were just hashed with md5, which makes the job a lot easier to the attackers.

If you have an account there and you use the same password some where else, please
change the password asap.

From a Site Compromise to Full Root Access – Bad Server Management – Part III

When an attacker manages to compromise and get access to a website, they won’t stop there. They will aim to gain full root (admin) access to the entire server. If there are more websites hosted on the server being attacked, It is likely they will attempt to compromise every single one of them.

How can an attacker escalate their privileges? How can they go from FTP-only access to getting root on the server? In this series of articles we will show some techniques that attackers are using to go from confined FTP/web access, to full root level access on a server.

In the previous articles of this series, we talked about symlinking to root and using local exploits to increase their privileges. However, attackers often don’t need this level of work when the server is not well managed and/or properly secured. They can leverage a quick path to root (admin) with little trouble.


Read More

SSH Brute Force – The 10 Year Old Attack That Still Persists

One of the first server-level compromises I had to deal with in my life was around 12 ago, and it was caused by a SSH brute force attack. A co-worker set up a test server and chose a very weak root password for it. A few days later, the box was owned running IRC bots and trying to compromise the rest of the network.

That was just the first of many server-level compromises caused by SSH brute force attacks that I would end up responding to, and even after more than 10 years, quite a few of the server remediations that we do here at Sucuri are actually caused by the same thing.

Read More

New Apache Module Injection

For the last few months we have been talking about the Darkleech Apache Module injection that is being used to insert malicious iframes into every site hosted on a compromised Linux server.

However, this past week we detected a new type of Apache module injection that is more subtle and increasingly difficult to detect. We don’t know if it is a new and improved version of Darkleech or a completely different tool written by a different group. Our team is still working on the binary and trying to scope the reach of this infection, so we will only post our preliminary analysis here.

Identifying the injection

The first sign of this injection can be identified remotely by an iframe injection like this one:

<iframe src=httpx://ajaxfamilies[.]org/go[.]php?sid=3 width=1 ..

That gets randomly prepended at the top of the pages loaded from the compromised server. That injection is conditional, so depending on the browser, referrer or IP address it may not show up. Google also says that 500+ sites have been distributing malware through this domain (ajaxfamilies.org):

Has this site acted as an intermediary resulting in further distribution of malware? Over the past 90 days, ajaxfamilies.org appeared to function as an intermediary for the infection of 562 site(s) including ajbridalwear.co.uk/, global-lcs.com/, trattamento-acque.net/.

Note that the domain ajaxfamilies.org might not be the only one being used (and it might change or rotate soon). However, from the servers we were able to gain access to, it was the main domain being used.

Apache Module injection

The injection is being done in the same way was before, by modifying one of the httpd configuration files (either conf/httpd.conf or conf.d/*.conf) and inserting a new module to be loaded:

LoadModule suphp5_module modules/mod_suphp5.so

Note that mod_suphp5 is a false module and not the popular mod_suphp one. We have also seeing it injected by overwriting the default mod_version.so with a fake one:

LoadModule version_module modules/mod_version.so

Those new modules are very small in size and have 0 detection rate by common anti virus software, according to virus total.

This is their identifier (size and md5 checksum):

$ ls -la *.so
-rwxr-xr-x 1 dcid dcid 15472 19 Jun 14:03 mod_suphp5.so
-rw-r–r– 1 dcid dcid 15472 17 Jun 18:53 mod_version.so
$ md5 *.so
MD5 (mod_suphp5.so) = 0a64f8d809d0a73d1b0b4139126e8f94
MD5 (mod_version.so) = 71e800af61521ff4390bf9845befa33a

It uses Apache’s portable memory pool to store the list of IP addresses that visited the site before and to decide when to inject the malware. It also has a backdoor part of it, allowing the remote attacker to run any command as the user Apache.

This module has some unique signatures that you can use to search for it. At this point we recommend looking for AWAVAUATUS1 on the modules directory:

$ grep -r AWAVAUATUS1 /etc/httpd/modules
Binary file /etc/httpd/modules/mod_version.so matches

You can also search for execl or getppid on the module directory and see if any suspicious file comes up. On the default Apache/PHP install, only libphp5 would have a call for execl or getppid on it.

If you suspect a site might be compromised, our sitecheck scanner should be able to identify this type of injection.

What’s next?

It seems the switch from site-level injections to server-level injections is really here to stay. If you don’t know how an attacker with just basic FTP or restricted access can get root, take a look at this series of posts we are doing:

We will also provide more information as we learn more about it.

From a Site Compromise to Full Root Access – Local Root Exploits – Part II

When an attacker manages to compromise and get access to a website, they won’t likely stop there, they will aim to gain full root (admin) access to the entire server. If there are more websites hosted on the server being attacked, It is likely they will attempt to compromise every single one of them.

How can an attacker escalate their privileges? How can they go from FTP-only access to getting root on the server? In this series of articles we will show some techniques that attackers are using to go from confined FTP/web access, to full root level access on a server.


Read More