Key concepts in this chapter are:
Analyzing the arms race between hackers and security developers
Evaluating future trends
It’s a warm sunny afternoon in the seaside forest bordering a beach in beautiful Costa Rica. The year is 2020. A robot monkey descends from the branches of a tree and offers you a cool drink. You lie back in your hammock, stretching after a long pleasant snooze. You sip the delicious cool drink and send the robot monkey to find some snacks as you switch on a satellite-linked Tablet PC and begin connecting to the headquarters of your global empire. Twenty years ago, people laughed when you began selling miniature plastic dinosaurs from a van somewhere in western Washington, but who’s laughing now? Those little lizards made you rich. You press your thumb onto the touch screen, and there is a slight hiss of escaping gas as the computer samples your body’s DNA and uses your code of life as the unique key to encrypt a message into a beam of light that is sent off to a satellite. Within milliseconds, hackers in neighboring Nicaragua tap into your satellite link and attempt to hijack your connection by emulating your Internet address. They are using a new hacking technique discovered less than an hour ago, but the satellite has already been patched against the vulnerability and you don’t even notice the failed attack as you begin poring over the massive numbers of purchase orders for miniature plastic dinosaurs that have come from all civilized corners of the solar system.
Wake up, you’re daydreaming again! Perhaps this little story truly does describe your destiny, the shape of tomorrow’s robots, and the future of security. However, don’t get complacent yet—security faces a lot of challenges, and besides, you still have to sell all those plastic dinosaurs. Before looking at future trends, let’s start by looking at what is happening today: the arms race of hacking.
Security today is a vicious circle, a cyber arms race between good guys and bad guys. Developers add features to software, people find security vulnerabilities, and system administrators close the holes, hopefully before hackers exploit the vulnerabilities. Before long, developers release a new version of the product, and the cycle repeats.
On May 17, 2002, David Litchfield of NGSSoftware (which develops vulnerability assessment tools) reported to Microsoft a security vulnerability in Microsoft SQL Server 2000. The vulnerability was simple: if an intruder sent the right information on UDP port 1434 to a server running SQL Server, the intruder could cause a buffer overrun and execute his own code on the server. This vulnerability meant an intruder could take over any computer connected to the Internet, provided the computer was running SQL Server. Two months later, on July 24, Microsoft released Microsoft Security Bulletin MS02-039, "Buffer Overruns in SQL Server 2000 Resolution Service Could Enable Code Execution (Q323875)." This bulletin included a description and a patch for the problem. Although this patch was freely available, not everyone installed the patch. The patch was also included in SQL Server Service Pack 3 (SP3), which was released on January 17, 2003. Still, a week later, not everyone had applied the service pack.
At some time during 2002, hackers began developing the Slammer worm, which was designed to take advantage of the SQL Server buffer-overrun vulnerability. (For information on the Slammer virus, see http://securityresponse.symantec.com/avcenter/venc/data/w32.sqlexp.worm.html.) Those hackers counted on the assumption that not everyone would have installed the patch. The Slammer worm sends a short program—just 376 bytes—to UDP port 1434; if a vulnerable SQL server is listening, the SQL Server is infected. The infected SQL Server begins executing an endless loop that generates a random IP address and attempts to infect any computer on that IP address. If a vulnerable SQL server is found on the randomly generated IP address, it too is infected; otherwise, the worm tries another address, and another, and another. This attack results in a huge amount of Internet traffic and makes the infected computer so busy that it becomes unresponsive. Luckily the worm does no further damage—it doesn’t write anything to the hard disk, and rebooting the computer removes the virus until the machine becomes infected again.
The authors of the Slammer worm released it on Friday, January 24, 2003 at about 9:30 p.m. PST. The result was immediate and catastrophic.
The Slammer worm began infecting computers exponentially. The number of infected computers doubled every 8.5 seconds, infecting 90 percent of vulnerable computers within 10 minutes. By 10:00 p.m. PST, over 200,000 machines were infected with the virus, and the Internet crawled to a halt worldwide. The speed with which the worm spread earned Slammer the honor of being the world’s first Warhol virus. A Warhol virus is one capable of infecting every computer on the Internet within 15 minutes, named after the pop artist Andy Warhol, who predicted that in the future everyone will have 15 minutes of fame.
By some estimates, Slammer cost the world between US$950 million and US$1.2 billion in lost productivity. On Saturday, January 25, in the United States, 13,000 Bank of America ATMs refused to dispense cash. Continental Airlines delayed or canceled some flights due to problems with online ticketing and electronic check-in. The City of Seattle’s emergency 911 network stopped working. Microsoft customers couldn’t activate Windows XP, and gamers couldn’t connect to Microsoft Asheron’s Call 2 online gaming system. In South Korea, customers couldn’t connect to the country’s largest ISP, KT. In China, Internet access became almost frozen.
By Tuesday, January 28, things were getting back to normal, but people wanted answers. "Whose fault was it?" "How can we prevent this from happening again?" Both are hard questions to answer. Was it Microsoft’s fault for putting security vulnerabilities into software? Some people noted that Microsoft had released a patch and a subsequent service pack that would have fixed the vulnerability before Slammer hit, had people installed it. However, many administrators don’t install patches as a matter of policy for fear that the patch will interfere with their systems. Occasionally, security patches and service packs have been known to actually destabilize systems. For example, on February 10, 2003, only a few days after the Slammer virus, Microsoft had to revise security patch MS02-071 after it was found that the patch caused random crashes and system reboots on Windows NT 4.0 systems. Some patches also require a system reboot, taking the system offline. Many systems are not designed for such maintenance, and administrators avoid installing patches because they need to keep their systems continuously available.
To make matters more complicated, new security vulnerabilities are found practically daily. According to Symantec’s biannual "Incident Security Threat Report," the number of vulnerabilities found in 2002 rose 82 percent to 2,524, compared to 2001. (The Incident Security Threat Report is available from http://enterprisesecurity.symantec.com/Content.cfm?articleID=1964&EID=0.) At the same time, the number of new viruses discovered in 2002 rose to more than 7,000. It’s no wonder that many people consider that we are in the golden age of hacking. The only reason why Slammer didn’t cause more damage was because it was essentially harmless, causing no damage to machines or networks other than slowing things down.
Although Slammer was a Windows-based worm, security vulnerabilities, viruses, and successful exploitations span all operating systems and potentially every product. In a world where computers increasingly rely on networks, there is no safe operating system. The following are some examples of recent vulnerabilities:
In December 2002, CERT reported a vulnerability in the Sun Microsystems Sun Cobalt RaQ Server appliance. In February, Sun had released a patch called RaQ 4 SHP (Security Hardening Product). Ironically, this security patch, which protected against buffer overflows and port scanning attacks, also included a new security vulnerability whereby a remote user could gain control of the server with "superuser" privileges.
Linux and other UNIX-based operating systems also have their share of hackers. As an example, in November 2002, CERT reported a problem with Red Hat Linux 7.3 and 8.0. The Samba package that provides file and print services included a vulnerability whereby an encrypted password, when decrypted with the old hashed password, could cause a buffer overrun and potentially execute a hacker’s code.
Hackers even target the comparatively smaller world of Apple operating systems. In July 2002, CERT reported the Apple Mac OS X had a vulnerability in the Stuffit Expander utility included with the operating system. This vulnerability allowed an attacker to create Trojan horse zip files with executable code.
For examples of vulnerabilities across all platforms, see the CERT Web site http://www.cert.org. (The CERT Coordination Center is a reporting center for Internet security problems.)
Slammer was a nondirected, noncoordinated virus that did nothing other than try to infect other machines. But what would happen if terrorists wrote computer viruses that attacked government, military, or commercial targets? The result would be cyber-terrorism, and the mere mention of this term makes many people scared. In recent years, as systems across the world have become more and more interconnected, the fear of cyber-terrorism and cyber-attacks has grown. Many people fear that cyberterrorists anywhere in the world might hack into the computers at an electrical utility company and cause a nuclear reactor’s core to overheat, following which they might cause a dam to open its gates, flooding a city, and finish by causing two trains to collide head-on at high speed.
These kinds of doomsday scenarios fuel the imaginations of B-grade Hollywood scriptwriters and reporters from small-town TV news stations desperate for any story that can catapult them to the big time. The reality is that the controls for essential systems are usually not connected to the Internet. To drain the water from the core of a nuclear power plant, you need to be inside the plant’s control center. Similarly, the switch that causes the dam gates to open is not connected to the Internet—why would it be? (See Figure 16-1.) Likewise, train companies have set routes and safeguards to stop controllers from accidentally causing a head-on accident.
What is more realistic is an attack on the Internet itself, with the sole purpose of bringing down the entire Internet. How realistic is this? It almost happened in 2002.
To understand what happened, you have to know that at the core of the Internet are 13 domain-name system root servers that translate URLs into the numeric IP addresses computers use to communicate with other computers. Although domain-name servers and gateways cache many of these translations, if all 13 of the domain-name system root servers are down long enough, Internet traffic will grind to a halt. On Monday, October 21, 2002, hackers mounted a distributed denial of service attack targeting the name servers. The attack was in the form of a data flood, which sent an enormous number of Internet control message protocol (ICMP) packets to the 13 root servers. This attack brought down 7 of the 13 servers for several hours. Although no one knows who mounted the attack, most authorities discount terrorists. What is clear, though, is that future attacks might succeed where this attack failed.