Security Company Infiltrated

Recently I posted a couple of articles (Article 1 – Article 2) discussing security of websites. Of necessity those articles were relatively superficial and didn’t go into any technical depth about the ways that websites can be compromised.

A recent development, which I’ll get to shortly, has inspired me to briefly revisit the topic of website security, this time in relation to a specific type of website and type of vulnerability. But first a little background…

Many websites are supported by a database in which is stored pretty much any information relating to the functionality of the website that the programmer decides should be stored there. While simpler designs may just store something like member information — for example UserID, password, e-mail address, etc — more complex arrangements may even store the website’s design components (such as screen colors, page dimensions, number of columns, etc) in the database.

Obviously regardless of what sort of information is stored in the database, any destruction, corruption or malicious manipulation of the database will almost certainly have serious adverse repercussions for the functionality of the website itself.

Another consideration is that there are different brands of databases, and each has its own design requirements, peculiarities and potential vulnerabilities. Microsoft SQL Server is generally considered to be the industry Big Gun, but it is considerably outnumbered in instances of use by the open source product mySQL, by far the most popular database used on websites.

In order to extract specific information from a database it is necessary to execute a piece of code called a Query. Queries must be written in a standard format which complies with the syntax of the “standard” Structured Query Language (SQL). Don’t be thrown by that — it just means that there are strict rules governing how you can ask a database to return information; you must use the right words in the right order in the right way. This is the province of the programmer, and should be completely invisible to the website visitor, but it never hurts to understand a little of what goes on behind the scenes. So, a simple example of an SQL query might look like this:

“SELECT * FROM users WHERE name = ‘” + UserName + “‘;”

That will make more sense if we consider a hypothetical website where the visitor must login to get access to the site’s content.

When a visitor to our password-protected Website enters their UserName into a login form, the programming code behind the form would call something like that SQL query above in order to extract the records of the specified UserName from its table of registered users.

Now, one of the vulnerabilities that can be used to attack a database-supported website is called “SQL injection”. An example of attempting to use SQL injection against our hypothetical website would be to provide a UserName that is in fact a command or query that the Query Language would understand and act on.

Obviously it would be very undesirable to have a situation where a knowledgeable hacker could somehow “inject” into the UserName a standard SQL command to delete a table from the database, or to reveal the e-mail addresses of all the registered users.

You don’t need to know anything about programming or databases or query languages to appreciate that there absolutely must be provision in the design and coding to prevent that sort of thing from happening.

Some database systems have such a safeguard built in, an example being the Parameterized Statements feature of the open source H2 database system. However the enforcement of Parameterised Statements is not a feature of Microsoft SQL Server or mySQL. With those databases the onus is on the programmers and designers to anticipate possible SQL injection exploits and circumvent them with careful design and coding.

Now, with that little bit of background out of the way, let’s return to the “recent development” that instigated this article in the first place.

Kaspersky Labs is one of the largest security companies online, and develops various anti-virus and security suite products and services for home and business. Far from being a newcomer, the company has been an established player in the computer and online security niche for a dozen years now, and their products are well regarded.

But despite the security expertise and know-how that you would expect from such an entity, a hacker recently posted proof that he had infiltrated their online database using SQL injection as his method of entry.

Fortunately for Kaspersky and their many customers, this interloper was apparently a benign hacker who was only interested in exposing a security weakness. As far as anyone is aware he didn’t cause any damage or reveal any sensitive information — something that it is obvious from his expose’ he could have done quite easily.

The reason I put you through that background lesson is to reinforce a point I made in my earlier Website Security articles. Some people criticized those posts for not going into enough specific detail, and my response was that the range of potential exploits is just too great. What I want you to take away from the Kaspersky incursion is that there are certain measures that the average Webmaster can take and there are things he should keep an eye on. But unless he is himself an expert in all aspects of website design, programming and hosting, there are many aspects of website security for which you are compelled to rely on your Host. This is why it’s so important to do your research and due diligence before choosing a Host for your website.

It would be easy to sit back and point a derisive finger at Kaspersky and be aghast at how a security company could be so easily compromised. To a degree you would have every right to do so, because the Kaspersky Web developers certainly missed blocking a well-known type of exploit.

But while you’re scoffing, at least appreciate just how vast is the number of possible vulnerabilities and the many thousands of hackers who are constantly probing for a way to get in.

It doesn’t take a lot of expertise to put up your own Web form, whether it be for the purpose of logging-in or allowing a site visit to send you a message. Would it surprise you to know that, unless specific steps are taken to counter it, almost all Web forms are open to SQL injection or to similar exploits such as SMTP Header Injection (used against e-mail forms)?

If in doubt, talk to your Host.

The post by the hacker who cracked the Kaspersky website can be found here:
Kaspersky Website Hacked