SQL-Injection – "ASCII Encoded/Binary String Automated SQL Injection Attack"
What is SQL Injection?
SQL injection is a technique that exploits a security vulnerability occurring in the database layer of an application. The vulnerability is present when user input is either incorrectly filtered for string literal escape characters embedded in SQL statements or user input is not strongly typed and thereby unexpectedly executed. It is in fact an instance of a more general class of vulnerabilities that can occur whenever one programming or scripting language is embedded inside another.
Source : WikiPedia
Is your website hack proof or affected by SQL Injection? You might want to check your site now and make sure that your site is not affected by SQL Injection. Today itself, I just found out that my client website was hacked by this SQL-Injection with the script “ngg.js” which created much trouble. (as you could see from the image below with this “script src=http://www.keje.ru/ngg.js /script”)
There seems to be a new wave of sql injections ending with ngg.js, it’s a kind of script that will run maybe to harm your pc recently?
The following table lists the references to malicious scripts detected and reported to date:
Date Monitored | Script Reference
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.
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 24,200 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.
Analyzing the pattern above, it is quite obvious 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.
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:
<% Dim strQuery strQuery = Request.ServerVariables("QUERY_STRING") strQuery = Replace(URLDecode(strQuery), " ", "") If InStr(UCase$(strQuery),"EXEC(") > 0 OR Len(strQuery) > 500 Then
Or you may follow my own way to replace the single quote syntax which is the cause of the SQL-Injection by just calling this valid_sql function across all your program. You may save it into a file and then use include function to include the file which can be accessible by all the pages.
<% Function valid_sql(s) For i = 1 To Len(s) If Mid(s, i, 1) = "'" Then temp = temp + "'" End If temp = temp + Mid(s, i, 1) Next valid_sql=trim(temp) End Function %>
source : bloombit.com