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 49,065 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.

The third T-SQL variant varies as follows:

While the previous T-SQL script was "blindly" appending the malicious script references to the current value of any given column entry, this T-SQL script first verifies that the current entry has not been contaminated by prior attacks, preventing excessive repetition of the same malicious script reference. Additionally, the T-SQL script terminates enclosing <title> HTML tag in order to ensure immediate download and execution of the maliciously injected Javascript code. This approach specifically targets web pages that dynamically populate their title tag from the database. Finally, the T-SQL terminates the injection with a comment declaration "<!--", intentionally trying to hide or prevent the rendering of the HTML content to follow.

The following table lists the references to malicious scripts detected and reported to date:

Most Recent Date Monitored

Script Reference

Analyzing the pattern above, it is quite obvious that this attack is carefully crafted and fully managed. New malware domains are introduced daily, while others are excluded, probably based on declining success metrics as anti-virus and related software and hardware vendors are updating their databases and blacklisting newly detected domains.

This T-SQL script—carried by a single malicious request to a website that is vulnerable to SQL Injection—results in content contamination of the entire site with Persistent/Type 2 Cross-Site Scripting (XSS) exploit. The injected Javascript dynamically writes an invisible IFRAME HTML tag to the involuntarily hosting page, pointing to the actual web page that contains different malicious content in an effort to exploit current software configuration vulnerabilities of the end-user’s machine (and to further empower the botnet). Ironically, the botnet masters explicitly express cyber-crime sympathy or sort of patriotism by excluding all end-users with the following language preferences set in their browser—Russian (RU), Chinese (ZH-CN, ZH-TW, ZH), Korean (KO), Hindi (HI), Thai (TH), and Vietnamese (VI)—as the ngg.js script suggests. (Note that there is also another similar variant of this JS file—fgg.js—prefixed with some of the malware domains listed above.)

The end result (for the infected system) is a malware executable with the file name msscntr32.exe, that is installed as a system service with the name "Microsoft Security Center Extension."

Solutions: How To Immune Your Web Application and Database From Such Automated SQL Injection Attacks

Our attack sample indicates that the botnet zombies cover the entire globe and therefore, an IP-based filtering solution that excludes certain regions will not suffice by itself. Still in the networking-layer, an Intrusion Prevention System (IPS), be it hardware or software based, can make access control decisions based on sensed content and drop the malicious request and other potential malicious activity before it is passed to the web server. A software-based IPS can, for example (but not limited to), provide protection via integration with the IIS platform as an ISAPI filter.

If the web application being attacked is templated, or the underlying web technology is configurable and/or extensible and allows participation in the page processing, it is possible to detect the injected malicious T-SQL script during early stages of the page processing and force an exception at that point. Because such a solution is centralized, it is manageable and will prevent the malicious T-SQL from being propagated to an ad-hoc SQL query down the queue of the page request processing. This effectively stops this attack vector "at the gate." The following ASP 3.0/VB and ASP.NET/C# code snippets demonstrate this (imperfect) Quick & Dirty approach:

You can then utilize the error handling mechanism of each technology to further process the thrown exception. The second code snippet demonstrates the detection of additional most common T-SQL keywords.

This SQL injection sanitation technique can also be implemented using an ASP.NET HTTP Handler (IHttpHandler) that is "plugged-in" to the site's page processing queue by modifying the site's configuration file alone (web.config). Additionally, form variables (HTTP POST) and other types of input (i.e., cookies) can furthermore be scanned and validated against similar injection attempts.

Although the solutions listed above do have the capability to block and mitigate this type of attack, they do not aim to solve the root cause of the problem, but to provide you with a way to shield your website almost instantly. Yet, penetration testing and code base auditing are inevitable and necessary steps to diminish the effectiveness of SQL injection attacks. Microsoft Source Code Analyzer for SQL Injection (MSCASI) is a static code analysis tool for finding SQL Injection vulnerabilities in ASP code. (This tool requires access to the ASP code base and can help identify code paths that are vulnerable to SQL Injection.) Another useful tool that can aid in identifying vulnerabilities is the Scrawlr. The Scrawlr was developed by HP Web Security Research Group in coordination with Microsoft Security Response Center (MSRC). Scrawlr will crawl a website while simultaneously analyzing the parameters of each individual web page for SQL Injection vulnerabilities.

Generally speaking, it is best to pursue a multi-layered security approach. Therefore, shielding the underlying database itself is also an essential measure to be taken, regardless of the current security level of the web application. Configuring a low-privileged database security context (for the web application accessing the database), and URL filtering (as a fallback) with the help of FOR UPDATE T-SQL triggers (or CLR DML triggers) are two ways in which a database can be immunized from malicious content.

Michael Zino is the CEO of Bloombit Software Inc.

Tags:  SQL Injection  Security  Virus  Denial of Service  DDoS  ASProx 

Lucas Tolliver on June 13, 2008 1:59 PM

Thank you for providing such valuable information. A client may have been compromised via this particular attack vector. With your information, we were able to identify the specifics of the attack, so thanks.

Greg Martin on June 23, 2008 10:04 AM

Wonderful analysis work, just so you know these attacks are originating from a botnet called ASProx and it is still on a rampage, I have current knowledge that this botnet exceeds 6,000 zombies.

I suspect that the javascript injection is related to click-fraud.

© 2010 Bloombit Software Inc. All rights reserved.

19934 73A Ave., Langley, BC V2Y 3J3, Canada Phone: (604) 710-9459 · Email:

Disclaimer: Some of the trademarks mentioned herein are the property of their respective owners.