Posts tagged: 'lizamoon'

The following posts are associated with the tag you have selected. You may subscribe to the RSS feed for this tag to receive future updates relevant to the topic(s) of your interest.

LizaMoon : Analysis of a Blended Attack

There is a great write up on the LizaMoon attack on the SpiderLabs® Anterior blog.  In this breakdown we’re shown multiple examples of the SQL injection payloads used by the attackers. What makes this particular attack interesting however are not the SQL payloads, but what the strings are being used to attack.

The first target of this blended attack are custom web applications. Ryan Barnett with SpiderLabs describes the challenges associated with mass attacking such a target below.

Historically, criminals had a tough time creating SQL Injection payloads that would mass exploit web applications. This was mainly due to websites running custom coded apps. No two sites were the same. This means that attackers didn’t have access to the target code so they were forced to conduct manual reconnaissance probes to enumerate database structures. This meant that if an attacker wanted to extract out customer credit card data from a back-end database, they would be forced to run reconnaissance probes in order to enumerate the database structure and naming conventions. This manual probing offered defenders time to identify and react to attacks before successful compromise of customer data.

So how did the Lizamoon attackers pull this off? The article appropriately sheds light on this key component of the attack but doesn’t elaborate in detail on the process. Without web server and/or database logs it’s difficult to know exactly what methods they employed.  While I have seen reports of the XSS code being mass inserted into all DB fields, it seems likely that this actually represents a case where the attack is malfunctioning.  Scanning the DB for common field names such as “title” may do the trick in some cases, but would not work all the time.

Regardless of how that first component of the attack is executed, it is clear that other parts of the attack are not as clever and are being misunderstood or simply not identified properly.   While multiple sources mark March 29th as the start of this attack, evidence paints a different picture. Take for example Later in the cycle of this attack, the IP resolved to hxxp: // and was one of the domains frequently seen being injected.  In the attack’s earlier stages however, at least as early as February 11th, this IP was reportedly seen attempting a SQL injection against various servers.

Accurate or not, there seems to be even less information on the payload and its delivery method.  Grouping all Rogue Security Applications into the same bucket might keep us from gathering a good understanding of the overall attack, but where are the Rogue Security Applications? I think it’s safe to say that the criminals were probably disappointed by falling so short of what this attack could have been. But, whether you give credit to security researchers for acting quickly to shut down domains or you simply consider it poor planning on the scammers’ part, we can expect to see better randomization and distribution of domain names the next time around.

An interesting byproduct of this attack is the number and variety of URLs pushing pay-per-click ads jumping on the LizaMoon media bandwagon.   Like this gem:misleading LizaMoon Ad

Crafty marketing or a simple case of web vigilantism in action?

Tags: , , ,

0 Comments | Security


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.

Tags: , , ,

0 Comments | Security