The recent compromise of Kaspersky’s (the Antivirus vendor) support database left the company with a bit of explaining to do. The hacker published a blog post on hackersblog detailing stunts with Kaspersky’s USA support website. Kaspersky also published their own account based on their log files and the hacker’s (nicknamed unu) blog post.

Summary of what happened

The following is a summary of what appears to have happened:

1. Unu scanned Kaspersky’s website using an automated tool, possibly Acunetix WVS (take a look at the screenshots)
2. The scanner identified SQL injection vulnerabilities on usa.kaspersky.com
3. The hacker manually verified the SQL injection vulnerability by injecting SQL statements that reveal the version of the database server (MySQL)
4. The vulnerable PHP code appeared to be using a high privileged SQL account and Unu then proceeded to list all tables that he/she had access to

So how bad was this security incident for Kaspersky? For one thing, it appears to have affected the organization’s reputation. Security companies tend to loose credibility when they too become victims of the sort of threats that they are trying to prevent. Luckily for Kaspersky, it seems that the hacker had good enough intentions and was only interested in fame. The screenshots indicated that by abusing this vulnerability, a real criminal could have stolen customer details, product activation codes, lists of bugs. Gunter Ollmann of IBM’s Internet Security Systems also mentioned that the attacker could have updated the database to direct the customers to malicious software rather than Kaspersky’s security software.

Was Acunetix WVS Free edition used?

There were claims that Acunetix the free edition was used as part of the attack. It is more likely that a pirated version of the full scanner was used since the free version does not support scanning for SQL injection vulnerabilities.

What could have prevented this attack?

It is always important to learn from such security incidents. I think the following would address similar issues with many websites that are publicly exposed to SQL injection attacks:

• When performing vulnerability assessment, do not stop at the main website (eg. www.company.com) but also test subdomains; usa.kaspersky.com was not the main site, yet it had access to sensitive or important information
• Kaspersky’s incident could have been greatly mitigated if the SQL account did not have access to so many tables; when developing web applications design them with proper access control in mind
• Many websites are under constant development and improvement and therefore it is useless to only check its security once; it makes sense to  scan web applications periodically to identify any flaws that are introduced with the constant application changes

Be Sociable, Share!

•