Last week, a large scale SQL Injection attack dubbed LizaMoon, referencing one of the domain names used in the attack, surfaced. This attack targets websites by injecting code that redirects visitors to a rogue anti-virus (AV) site. While on the AV site, visitors are presented with fake antivirus screens and popups, they are prompted to download fake software that will run a scan of the computer and ask the user to pay for a license to remove the alleged found infection.
While this attack has garnered quite a bit of media attention as being the next big threat – its size and severity have already started to be downplayed by some experts. Initially, Websense declared that this attack has stretched to hundreds of thousands or even millions of websites. After conducting some research via Google, it did return millions of results. However, this number should be considered a very high ceiling since a site with many infected pages will result in multiple results in a Google search. My educated guess is this vulnerability puts possibly thousands of sites – or less, at risk.
Why A Web Vulnerability Puts Databases At Risk
The attack infects websites by injecting SQL code that is updating text columns in the back-end database, where content is used to build the pages displayed by the web server. This has largely affected installations of Microsoft SQL Server – which primarily focuses on ASP and ASP.NET sites. Other vendor databases are equally vulnerable to this type of attack, as well as other web-development frameworks.
While this attack targets the website, the database could become the ultimate payoff. The first step in protecting against this vulnerability is to harden websites. By setting up proper input validation on web forms and URL parameters, you can enable your site to reject injected SQL code like what is being used in this attack.
In addition, database queries to the back-end database, especially queries such as SELECT, INSERT and UPDATE, 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.
A good first step is to harden your database. Most SQL Injection attacks happen on the website, not the database, so why do I say to harden your database? It’s simple. Unpatched vulnerabilities on the database can be exploited in SQL Injection attacks, and can give the attacker amongst other things, escalated privileges and access to sensitive data. Insecure configurations can allow an attacker to, for example, execute OS commands through xp_cmdshell and there are many other issues that a savvy attacker can exploit. A securely configured and vulnerability-free database greatly reduces the bad things that can be done by an attacker and can increase your security posture. Deploying a program that includes database vulnerability assessment and rights management should be considered a high priority.
Next, enforce proper separation of duties for the web app accounts used to connect to the back-end database. Unauthenticated visitors should have ‘read only’ access to the database back-end, and only administrators or content managers should be given insert or update privileges to the back-end tables used to serve up pages. User rights management tools should be used to enforce minimal privileges.
Finally, monitor your database traffic. A properly configured database activity monitoring (DAM) solution will help detect malicious SQL code and the fine-grained audit trail created by a good DAM 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 these or any other SQL Injection attacks.
Largely Ineffective…This Time
TeamSHATTER has found the LizaMoon attack to be largely ineffective. Most of the domains that the attack is redirecting traffic to are non-functioning. Also, the way that the attack inserts a JavaScript snippet to redirect site visitors is not very effective. Most affected web pages analyzed by TeamSHATTER showed some raw html code with the redirect to the http://lizamoon.com/ur.php and similar malicious sites, displayed in text boxes. However, none was an actual link that could be clicked on.
Despite the limited impact of LizaMoon, we should not forget that the concepts it employs are easily applicable to other more serious attacks. More sophisticated, organized and well-funded criminals and state agencies are capable of inflicting devastating damages. The same kinds of attacks could be used to attack the website and host, the host’s OS, and other computers on the same network. They can be used to install Trojans, viruses and harvest data. By providing access to the databases, large-scale credit card thefts and breaches of other highly sensitive data are possible.
LizaMoon’s success is a case study in poor coding and database configuration practices. When web applications are written correctly and their back-end databases are managed against vulnerabilities, SQL Injections are proactively prevented.
Of course, what if this “attack” wasn’t the actual attack that it was portrayed to be, but rather the proof of concept that the attackers used to test the effectiveness of their delivery method? What appeared to be “sloppy” work may very well have yielded important information to show where the attack methods worked, and when they failed, to gain strong intelligence on the most effective way to deliver the payload. This time, the payload delivered was annoying fake AV, but next time it could be the Worm that takes over your network, or a Trojan that steals all of your data and sets you up for ransom payments, embarrassing exposure or worse.
Alex Rothacker is the director of security research at AppSec’s TeamSHATTER research team.
