According to an article in last Friday's Washington Post, Circuit City fixed a security hole in their web servers, which had allowed "bad guys" to infect computers of users of those servers. How can they do that? We're going to look at that today, and tomorrow we'll look at the related topic of "secure web sites".
First, let's look at what they have to do, before considering how:
- They find a vulnerability in the web-server computer.
- They take advantage of that to put their own software on the web server.
- Their software takes advantage of a (probably different) vulnerability in computers that visit the web site.
- They wait for a vulnerable computer to visit.
- They use the vulnerability to infect the visiting computer.
The first thing they need to do, then, is to crack the web-server computer. They can do that by exploiting a vulnerability in the web server, in the operating system, or in the security configuration (or possibly some combination). I don't know what they did in this case (and I doubt that Circuit city is saying), so let's just look at the possibilities. It's possible for the web server to have bugs that would allow someone who knows where to "poke" to access the administrative interface, which would then let them load their software into the server. In the past, this sort of thing has been done with "buffer overruns" (using, for instance, a very long web request to cause portions of the web-server program to be overwritten), and it's surprising how often such an easy-to-avoid problem arises in software. Alternatively, the attackers might have found a way to get access to a command shell with "root" authority, which enables them for pretty much anything, from loading software to stopping and restarting programs to changing the network routing for the computer. There have been many exposures to this in Unix systems over the years.
Or perhaps they just found a security problem in the computer's configuration. This could be an easily guessed password, a misconfigured firewall, a key file or directory with incorrect security permissions, or any number of other things. Periodic security audits on critical computer systems are important.
Passwords are among the weakest points of computer systems. In order to try to balance security with usability, we use short, easy-to-remember passwords. Unfortunately, those are also often easy to guess. Sometimes it's because the software has a default password and it wasn't changed when the software was installed. Sometimes it's just because of a poor choice of passwords. Many years ago, back when passwords were generally stored unencrypted, we did a password audit on a computer system that I worked on. When a user logged into that system, she entered her username, the system responded with the prompt "Enter password:", and she entered her chosen password. Can you guess what was, by far, the most commonly used password on that system?
OK, the attackers have loaded a program onto the web server. Now, a customer visits, and the program sends something to the customer's web browser that's designed to attack it. If the customer's computer isn't up to date with the latest "patches" (or if this is a new attack for which there isn't yet a patch), the attack might work, allowing the infected web server to put a program onto the customer's computer that will put it under the control of the attackers. The victim's computer is now part of the "zombie network".
 Yes, you got it: "password".
 History: these aren't actually patches, but are more properly just called "software updates". True "patches" were used in the old days, when we crafted computer software with stone knives and bearskins, when computer memory was scarce, and updates were difficult and time-consuming. We actually used to update small sections of computer programs by changing the binary codes directly, "patching" them in very much the same way as you might patch the torn knee on a pair of trousers.