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:
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.
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 injected script code looks as follows:
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.