In the past, when we tend to look at security vulnerabilities and attacks, we tend to think of a single attack, with generally one vector of entry.  In actuality, most attacks are layered, using multiple avenues, or a round-a-bout path to fulfill whatever nefarious goal in mind. LizaMoon is a prime example of this type of attack. The ultimate goal of which is to steal the personal or financial information of the victim.  To get this information, a type of malware is installed on the end user’s computer called “Scare ware”. This name is indicative of its attempt to scare people into paying to remove a false positive virus infection on a computer, all the while pretending to be legitimate software.  At the same time, credit card and other personal information is collected, almost willingly, from the user.

Sadly, this is nothing new.  The issue for the bad guy begins with loading malware on an end user’s computer. Putting up just a phony website doesn’t always cut it. Search engines and modern browsers keep track of malware infected sites, so just getting the traffic volume is a difficult task.  So an option would be to find a vulnerable trusted website, which you could inject code into.  If an attacker can inject a cross site script/XSS to make an end user’s browser point to, and download the malware, then they are one step closer to their goal. Since the website is trusted by the user, and with some creative malware coding, you can easily fool a typical end user.  Multiply this with thousands of trusted websites and you have the Lizamoon attack.

So to recap, for the attacker, the goal is to find legitimate websites with SQL vulnerabilities. Once found, the attacker then performs an SQL injection of code to execute a cross site script. At this point, the infected website’s users unknowingly download the malware.  Consider the three key steps to end up at the final goal of getting a victim’s personal and credit card information.

1-     SQL Injection

2-     XSS/Cross Site Scripting

3-     Malware installation

At each of these steps, there are preventative measures that can be taken to reduce vulnerability.  We will now discuss, on a very high level, preventative measures one can be taken to prevent these vulnerabilities. Depending on your Database type in question (MS SQL, mySQL, etc…), or what language or combination of language the target site is written in, there may be very specific things that can be done. The goal here is to consider some things when developing and planning a site and/or database implementation.  Also on the client side there are some tried and true best practices to keep the end user safer from infection.

SQL Injection

There are some steps to avoiding SQL injection.

Data Validation: Check all data for proper length, format etc… A field expecting a last name more than likely will not have something like the example below in a field.

‘; DROP TABLE haxor;CREATE TABLE haxor(line varchar(255) null);

INSERT INTO haxor EXEC master..xp_cmdshell ‘dir /s c:\’;–

In a blatant case like the above example, just filtering input would make this type of attack unusable.  Last names don’t have characters like ; / : \ _.

Least Privilege accounts: Obviously an Administrator account is not necessary to call data up to display.  Use accounts with the most minimal account privileges required to make the website or web application function properly. Restrict table access and function access to only the essential.

Consult documentation from you SQL solution for more flavor specific guides and best practices.

Cross Site Scripting/ XSS

When discussing Cross Site Scripting/XSS, there are two levels where we can stop this; the actual code, or on the client side where the code is executed (I.E. a web browser).  We will discuss some developer best practices here, and discuss what we can do in the client side in the next section.

According to The Open Web Application Security Project or OWASP here are some steps you can take to prevent XSS.  Much more detail can be reviewed by your developers by reviewing this link or going to Http://  Also, look to the documentation for your coding language of choice for very specific language options to prevent XSS.

- Never insert untrusted Data Except in Allowed Locations. untrusted data should never go in Scripts, Comments, Attribute names or in tag names

- HTML escape before inserting untrusted Data into HTML Element Content

- Attribute escape before Inserting untrusted Data into HTML Common Attributes

- JavaScript escape before inserting untrusted Data into HTML JavaScript Data Values

- CSS Escape before inserting untrusted Data into HTML Style Property Values

- URL escape before inserting untrusted Data into HTML URL Parameter Values

- Use an HTML policy engine to validate or clean user-driven HTML in an outbound way

Client Side prevention:

So let’s say you go to a site with a compromised DB and you are about to be sent to another website to download a client.  Here are just some of the things to prevent such an attack:

Keep browsers, plug-in and O.S. updated:  Sure it’s simple, but it really works.  Also consider applications like Adobe Flash and Reader, Java clients can also be exploited by code injected on a website.

Restrict admin privileges:  Nothing new here, if you can’t install anything, you definitely won’t install anything bad.

Browser plug-ins: If you are a Firefox user a plug-in called No Script will prevent any and all XSS and so many other exploits will prove unsuccessful to the attacker.  Chrome users have a similar option with Not Scripts.

Antivirus/Anti malware: Again nothing new. Keep updated anti-virus/malware software on all workstations.

End user education: Especially in larger organization, some basic policy and procedure overview with some simple common sense computer training goes a long way.

In the future, these multi-tiered attacks incidents are expected to rise.  When we think of security, we will have to think in a three dimensional way, as to how we protect our infrastructure.  It’s not just a single point of failure, but modern Internet usage truly becomes a chain with multiple points of failure. The good news is that at every step of the game we can be proactive to avoid these attacks.  It really does take an ounce of prevention to avoid a pound of cure.




Tags: , , , ,