Unu hits Kaspersky a second time with SQL Injection disclosure

by Steve Ragan - Dec 10 2009, 22:30

Unu, who has gained a good deal of attention lately, is known for his vulnerability disclosures that center on SQL Injection. In his latest adventures, he returns to a vendor he has targeted in the past, security software specialist Kaspersky.

In February, Unu went public on HackersBlog and disclosed the SQL Injection flaws he had discovered on Kaspersky’s USA portal. The flaws, which led to complete access to users, activation codes, lists of bugs, admins, shopping, etc., were quickly patched, and Kaspersky was quick to point out that, “despite their attempts, the hackers were unable to gain access to restricted information stored on the website. Claims by the hackers responsible for the attack that they had managed to gain access to user data are untrue.”

In response to those claims, we interviewed Unu shortly after Kaspersky issued them.

“First of all, it starts from a negative premise. It was not about any kind of attack. [This was not] my intention. I am not a thief. I'm just a guy who likes to do security testing, penetration. It’s like any other hobby,” Unu wrote in the e-mail.

“I do not break, I do not delete, I do not change, and I NEVER save anything. In the data that I can access in this way, I just show that it is possible, that the site is vulnerable. That is all. The same thing happened [in the] Kaspersky case. It was about a banal parameter that was not good or not [sanitized enough].”

Now, Unu has disclosed SQL Injection problems in two other Kaspersky portals, which were being hosted by channel partners in Malaysia and in Singapore. According to what was discovered, Unu commented that the vulnerability affected all databases in Southeast Asia. However, Unu told The Tech Herald that the flaws have been patched.

Yet, while the vulnerabilities were fixed, the point is the same. The SQL Injection only worked because user input was not checked. In detailing what he discovered on the two Kaspersky portals, Unu noted that several of the administrator passwords, while encrypted, were weak, and in several cases identical. (In one example he listed an administrator with a password of abc123.)

There was other information discovered, including personal information and accounts using the wildcard token (%), as well as license information, shop details, and access to both the Malaysia and Singapore databases on a single server.

“[These] vulnerabilities exist when [Web developers, site administrators, etc.] put [vulnerable] code on site. So if I could have access the database, somebody else could do that too, maybe somebody who has more knowledge about SQL Injection than me, and that person still will be able to do it if I or somebody else wouldn’t announce the problem,” Unu told us in February when asked about the reasoning for what he does.

“...maybe that person could have bad intentions or take advantage of it. What mind many people is that we make it public, these vulnerabilities, and not keep it low, send a mail to the admin in secret. Of course we choose this way because we want that the firms put a bigger accent on the security. At least in this way something is moving, they make a report, analysis, they have to check again, etc," he added.

“If we just send an email, without making it public they would fix only that parameter that we announced and it is possible to be others too. (I’m talking in general and not about a certain site.) So for what I do, I do not consider myself a malefactor, I'm not a criminal, I [am] not a burglar.”

Around the Web