New mass SQL injection attack making rounds

Again a mass SQL injection attack is making its rounds on the web – this one called jjghui referring to the website it redirects traffic to. As Armorize reported, this is yet another play on using SQL injection to inject malicious JavaScript in ASP.NET websites. So far, a Google search shows 180,000 pages have already been infiltrated by this attack. This attack seems to be targeting smaller sites that lack personnel with the skills and security awareness of larger and more well-known sites.

This attack methodology is the same type that has been used many times before on a massive scale. Legitimate websites are serving up malware as quick as McDonald’s serves up piping hot fries.

This attack does several things:

1. A link to malicious JavaScript code is injected into vulnerable ASP.NET sites that serves webpages that have html content stored in SQL Server backend databases

2. The infected pages execute malicious script code from jjghui.com which in turn poisons a user’s machine with malware and recruits it to a botnet.

3. Attackers can load any payload (ie. Trojan, keylogger, command and control server) onto any computers that surf that website:

A command and control server allows an attacker to execute shell commands on the infected computer. Basically executing any command or program, including access to the local network that the computer is part of. This could allow access to file servers, databases, etc. Amongst other things, attackers can steal usernames, password hashes, credit card numbers, delete and modify database information and of course, download any of the information accessed.

While in this case it appears that the SQLi vulnerabilities exploited are only used to inject malicious JavaScript to fool people into buying fake AV software, it also provides attackers with direct access to the database behind the website and all of that data stored there. Since all of these infected websites can easily be identified by doing a simple Google search, to an attacker, Google is becoming the Yellow Pages of vulnerable websites. Once these websites are searchable, not only can the attackers go back and further exploit these vulnerabilities, copycat attackers can also run a SQLi and compromise the database just as easy.

The jjghui mass SQL Injection attack also has many similarities to the LizaMoon attacks from last spring. For starters, by looking on the Whois entry, both LizaMoon.com and jjghui.com are owned by James Northone of Plainview, New York. Who is James Northone? No one knows, but the registration definitely links the two sites.

Here are some more similarities to the LizaMoon attacks:

• Infected sites are ASP.NET sites with SQL Server backends.
• A script link is injected into columns that build the page html.
• The injected link will call yet more Script code from a third party site.
• The third party code is obfuscated malicious JavaScript code.
• This code redirects yet to another site with a fake Antivirus scam. It is also exploiting known vulnerabilities in JavaScript and Flash.

Technical Details:
The injected script code looks as follows:

At the referenced location, obfuscated JavaScript code is hosted in form of char codes (letters represented as numbers) that get decoded on the fly into working and malicious JavaScript. The obfuscation of the code makes it harder for firewalls and AV software to detect the attack. This code leaves a cookie on the browser and then navigates to a malicious URL at strongdefenseiz.in.

Databases at risk
The reason this attack is so successful is because it automatically finds vulnerable ASP.NET websites with SQL Server backend databases that can be exploited with a simple SQL Injection attack. Some of these sites might have been scoped out in LizaMoon and previous attacks.

Data stored in the database can be compromised not only by the people behind “James Northone” but also by any copycat attackers that run a simple Google query to find the vulnerable websites. Once compromised, the attackers can potentially access any data on the database backing the website, especially if there is no proper separation of duties. For example, on a shopping website, customer data such as email addresses and credit card numbers might be at risk.

How can I ensure that my organization is protected?
There is no easy workaround for the database component of this threat besides fixing the SQLi vulnerabilities on the site and employing the best practices mentioned below. However, employing a database activity monitoring solution will help to address this issue.

This and most other SQL Injection attacks are a case study in poor coding and database configuration practices. When web applications are written correctly and their backend databases are managed against vulnerabilities, SQL injections are proactively prevented. I recommend that organizations take the following steps to protect their site visitors, web applications and database assets:

1. First and foremost, web applications should be reviewed to insure proper input validation on web forms and URL parameters. Database queries to the backend database, especially SELECT, INSERT and UPDATE queries should never be created by simply concatenating a SQL query string with input from web form fields. The input should be sanitized and then parameterized queries should be used to interact with the database.

Note: ASP.NET does this by default. A web developer actually has to bypass some of the features, or disable some default security configurations to make a site vulnerable.

2. Harden your database. Unpatched database vulnerabilities can be exploited by SQL Injection attacks. They can give an attacker elevated privileges and access to sensitive data. For example, unsecure configurations can allow an attacker to execute OS commands through xp_cmdshell, providing full access to database assets. A program of database vulnerability assessment and rights management should be considered a high priority.

3. Enforce proper separation of duties for the web app accounts used to connect to the backend database. Unauthenticated visitors should only have “read only’ access to the database backend, and only administrators or content managers should be given insert, or update privileges to the backend tables used to serve up pages. User rights management tools should be used to enforce minimal privileges.

4. Monitor your database traffic. A properly configured database activity monitoring solution will help detect malicious SQL code and the fine grained-audit trail created by a good database activity monitoring solution will also help greatly with forensic analysis needed to reconstruct events in the aftermath of an attack.

Each of these steps incorporated into a defense in depth strategy will protect your data assets and IT infrastructure from SQLi attacks.