Initial Thoughts: LizaMoon Mass SQL Injection

While I will be posting a more in-depth analysis of the LizaMoon attack, here are a few early thoughts from Dave Pack while his blogger profile gets set up. Dave manages LogRhythm’s Knowledge Engineering department and has been working in information security and advanced data analysis for over ten years.

Various security organizations/bloggers are tracking a mass SQL Injection currently being called “LizaMoon” (one of the first websites identified). While we haven’t a chance to fully analyze the attack, based on information being aggregated by SANS and Stackoverflow, it looks like this is a combination SQL Injection/Stored XSS Attack, the final target being client-side end-users. It appears that the SQL Injection is taking advantage of a web application vulnerability. 

The injection itself is delivering a Stored XSS attack to the vulnerably web servers, consisting of a script (< / title> < script src = http : // >) that redirects unlucky Internet users to a different site hosting a file named ur.php. 

This php file is where the dirty work is actually done. It launches an exploit which installs fake AV software on the end-user’s machine. What’s really interesting is that the SQL injection is really just a means of delivering the much more dangerous Stored XSS to vulnerable web servers. Stored XSS are much scarier than a standard Reflected XSS because a user doesn’t have to be tricked into clicking a maliciously crafted URL. 

The XSS attack is simply sitting on the web server, waiting for any unlucky Internet user to browse to the compromised website. We’re attempting to get our hands on the ur.php code for further analysis of the client-side exploit, after which one of our analysts will be posting an update. 

In the meantime, here are some things both web administrators and end users can do to detect this attack and help protect against it. SQL Injection: 1. Implement standard protections, such as sanitizing all database inputs and using parameterized queries across the board, to limit what can get through. 2. Check if a web server is being targeted by most types of SQL injections. a. In particular, look at your access logs for “)-“ in the URL.

It is extremely rare for legitimate input to be commenting out the rest of a SQL statement. b.  Check for various encodings of the same string as well. LogRhythm provides an out-of-the-box AI Engine advanced correlation rule that looks for these strings in a URL and will alarm on any injection attempts. Stored XSS: 1. If the functionality is available in your infrastructure, block any attempts to access a website with “ur.php” in the URL. 2. Practice standard “safe browsing” techniques. Many browsers offer a plugin, such as NoScript which forces users to explicitly grant any script permission to run client-side. Use a plugin like this, or disable javascript all together if it’s not needed for business purposes.