We all have anti-virus software and naturally take precautions against viruses, but do we know what a virus actually is? It’s obviously a piece of software that does something nasty, but how does that nastiness manage to find its way onto our computer? The other day I was with Phil, Sarah and Peter (Bishop, not Spencer – we have way too many Petes in Integra!) discussing our latest joint project and the subject of SQL Injection came up. Now Peter is a pretty clever chap (he has a PhD and everything!) but this was was new to him. Don’t worry, it wasn’t new to me, but I thought it might be worth writing a blog article about. After all, Peter used to design turbine blades for Rolls Royce Jet (“Jet” starts with a capital letter to distinguish it from glider engines and other engines that work by magic, as opposed to “proper” engines which work by, umm, jet) engines. So if Peter doesn’t know this, maybe lots of other people don’t either.
Now Peter is a very clever chap and, in common with very many clever chaps, he thinks that everyone in the world is a jolly good egg. Not being a jet engine designer I know that the world is not exclusively populated by nice people (I have even met some of them). Let’s suppose that we have a web site with access controlled by a username and password. Obviously we must have a screen where we ask people to enter a username and password. Let’s say that a genuine user visits our web site and enters his username as “fred” and his password as “secret”. Not wishing to bore everyone with the details of SQL we might be tempted to execute a command in the database (i.e. SQL) to validate this username/password combination. The obvious choice is:
SELECT * FROM Users
WHERE UserName = ‘fred’ AND Password = ‘secret’
(forgetting for the time being that no good system designer would ever store a password in a database in plain-text)
Well, that looks harmless enough. If the database USER table has a record for UserName = ‘fred’ where the password is ‘secret’ then what we have here is a good egg logging on to our application.
Suppose for just a minute that the world isn’t populated exclusively by PLU (“People Like Us” – if you’re a child of the 60’s you may recall this Nancy Mitford TLA). What if the user typed in:
”rubbish’ OR 1=2
When our application sends this to the server it turns out to be:
SELECT * FROM Users
WHERE UserName = ‘fred’ AND Password = ‘rubbish’ OR 1=1
There is a very good chance that the password in the database for the user Fred won’t be ‘rubbish’, but if you have an understanding of Boolean logic you will realise that while Password = ‘rubbish’ is FALSE, 1 = 1 is TRUE. As the Boolean OR evaluates FALSE OR TRUE to be TRUE, the user has managed to gain access to our system.
So far so bad, but things can get worse, much worse, Let’s suppose we have a really bad egg visit our web site. Now e-Quip is an equipment management database and so a well-informed hacker might guess that there was a table in the database called EQUIPMENT, or maybe INVENTORY. If this hacker guessed that e-Quip was based on Microsoft SQL-Server, then in this particular database system it is possible to chain together multiple commands in a single SQL statement, using the “;” character to separate the commands. What would happen if the user typed a password of:
”rubbish’ OR 1=2;DELETE FROM Equipment;DELETE FROM Job
A curious, but disastrous password! I don’t think you need to be a rocket scientist (or even a jet-engine scientist like Peter) to work out that not only will this password give you access to the system, but it will also destroy the system. If there isn’t a table called Equipment but there is one called Inventory that’s no problem for the hacker. It’s pretty simple to try out millions of combinations of names just by writing a little bit of code.
This kind of attack is known as “SQL Injection” and fortunately, programmers are well aware of this vulnerability and guard against it (I won’t go into details as that would make life way too easy for the bad guys). I used SQL in that example because the SQL language it is sufficiently English-like for anyone to get a rough idea what is going on and allow you to get the idea that bad things happen when code and data get mixed up. Although there are lots of SQL injection attacks out there, the baddies are way cleverer than that (some may even be cleverer than Peter) and they can turn data into executable code in lots of very clever ways.
I suppose that technically speaking that’s not really a definition of a virus, it’s more like a description of how the bad guys can trick an innocent application into doing something that it was never intended to do. What makes it a virus is the ability to replicate itself in another computer. Once a bit of software is doing naughty things in your name it’s only a small step to emailing itself to everyone in your global Address Book. That’s when it becomes a virus.
In case you’re thinking “why would someone bother to do this to me?”, it’s not you personally, it’s everyone. There are bits of software running 24 hours a day trying every combination of IP addresses and sending thousands of combinations of attacks to them. Here’s an extract from the Windows Event Log on a computer running Microsoft SQL-Server Express. This database server comes with a built-in system administrator account called “SA”.
Login failed for user ‘sa’. Reason: An error occurred while evaluating the password. [CLIENT: xx.xx.xx.xx]
(I’ve blanked out the bad guy’s IP address in case they sue me, or send the boys with baseball bats round)
On the computer I looked at this is happening every 60 seconds, all day, every day. A piece of software sitting on a perfectly innocent computer (possibly yours) is sending out millions of SQL-Server attacks in the hope that someone didn’t disable the “SA” account when they installed SQL-Server Express. How does it know where SQL-Express is installed? It doesn’t matter – when you have enough computers around the world doing this 24/7 it’s easy enough to try every computer in the world.
Ok, that’s not a virus, that’s somebody exploiting a security flaw. But the software that is doing this almost certainly got onto someone’s computer as a result of a virus. So let’s be careful out there and be sure to keep our data separate from our executable code!