October 2001
  

IP Address? It's A Virus Calling!

BY Tom Keating

Inspired, I wrote a "war dialer" program that dialed all the local phone numbers in the surrounding area in search of a modem signal. The program would start at a number; say 555-0000 and then increment by one to 555-0001, then 555-0002 and so forth in search of modems. It was a slow program, taking days to call all the local numbers. While I never actually broke into any government systems, hundreds of people must have thought they just received a hang-up prank call. My motives were harmless. I was just curious to explore unknown computer systems via my 1,200-baud modem.

DANGEROUS DIALER
The recent news about the Code Red worm and its ability to "dial" IP addresses, searching for vulnerable IISs made me think of this program. Essentially the Code Red worm calls an IP address, scans for the vulnerability, dumps its payload and then moves onto the next IP address. When an IIS becomes infected with the newer Code Red II worm, it will actually scan IP addresses in the same "local" subnet to more quickly scan and find more IISs. Matthew Broderick's character in War Games would have had a field day with such a tool, which can scan for thousands of computers much faster than either of our war dialer programs.

Many people have read about the Code Red worm in the news, but I doubt most realize the impact this worm has had or will have on the Internet. No doubt some hacker is going to improve upon the design of this worm and truly cause chaos on the Internet. The worm in its current form is insidious due to its self-replicating nature and its ability to hog bandwidth. Newer variants even leave a "back door" which a hacker can use to steal data.

Several experts warned that the Code Red worm would bring down the Internet. This didn't happen, but the impact of the Code Red worm should not be understated. Several ISPs, including AT&T, Qwest, Optimum Online, and others reported disruptions due to the Code Red worm. Reportedly, the Bank of America was forced to shut down its intranet routers for at least a day, leaving the entire bank without Internet service. Even government and military computers have not been immune from this worm. Although I'm sure none of the mission-critical machines are connected directly to the Internet, it still gives me the chills to think that someone could infiltrate our government and military computers utilizing worms.

PREVENTION
I believe that something needs to be done to help minimize these types of attacks. It would be a fruitless exercise to expect bug-free software, so there will always be vulnerabilities that hackers will exploit. However, I believe that the tools to detect Denial of Service (DoS) attacks and the ability to find out who the offending DoS IP addresses belong to is sorely lacking. It's true that a seasoned network engineer can discern an attacking IP address, then do a "whois" lookup to find out to whom it is registered. Unfortunately, this is a manual process and often times the IP address is registered to the ISP and not the actual user.

The Code Worm virus infected over 400,000 IIS servers. How can ISPs quickly inform 400,000 people that their IIS has been compromised and that it is flooding the Internet with packets in its attempt to find and attack other machines? The ISPs can't do it, so that leaves it up to each individual person to have the knowledge to detect and know that their system has either been compromised or is being attacked.

Unfortunately, not everyone who manages a Web server, IIS or otherwise, is experienced in networking. Their Web server could be "slow" due to DoS attacks and the IT department may have no idea what is going on. They may think it's the ISP's fault or that there is heavy traffic on the Web, and not consider that their Web server has been compromised. Unless they know about the "netstat" command, have a packet sniffer, or know how to read the log files, they often are flying blind.

Microsoft is partly to blame for this. They've made installing a Web server as simple as installing Windows NT or 2000 and then installing an IIS which comes included on the CD. Providing a turnkey Web server is great, but it can be dangerous in the hands of a novice. Microsoft needs to provide better tools with an IIS for novice Web server administrators to ensure proper security. Such tools can include a reporting utility showing "hack attempts by IP address," as well as a real-time alerting system if a DoS attack has occurred.

NO ONE IS IMMUNE
My own broadband cable provider was not immune from the Code Red worm. For over a week, the receive and transmit lights on my cable modem were on constantly. At first I thought someone was trying to attack my home network. But even with all of my PCs off, the cable modem has constant high activity. I received an e-mail from my broadband provider informing me that the Code Red worm was flooding the shared cable broadband network. In fact, at times it was so bad I could not access the Web at all.

The Internet has become a critical communications medium for all kinds of applications. E-commerce, VoIP, e-mail, Web sites, instant messaging, ASPs, and more depend on the Internet. It's a wonder how we ever lived without it. Unfortunately, the Internet is like the Wild, Wild West, providing an expanse which allows hackers to hide in complete anonymity. Hackers can cause damage and there isn't much we can do to prevent it from happening, or to even catch those who do it.

WHEN IP ADDRESSES ATTACK
I have a suggestion for Microsoft and other manufacturers of Web servers that might help lessen the impact that the next Code Red worm can have on the Internet. But before I get into that, let's look at how someone is notified that they are inadvertently DoS attacking someone else. As we all know, everyone who logs onto the Internet has an IP address. Let's assume PC-A with IP address 198.1.1.1 has been infected and is performing a DoS attack on PC-B having IP address 200.1.2.3. Fortunately, the Webmaster for PC-B has noticed the DoS attack and has found the IP address of the attacking PC (198.1.1.1). He then goes to www.internic.net/whois.html to look up who owns 198.1.1.1. The whois query returns with the name of the company, the person responsible, an e-mail address and a phone number. He calls the person, tells him that his PC is infected and together they're able to solve the problem.

But wait, now PC-B is being attacked by a new IP address -- 193.3.2.1. He does a whois lookup, but the IP address is registered to UUNET, a major ISP for thousands of customers. He calls UUNET tech support and explains that one of their customers is infected with a worm and is performing a DoS attack on his PC. He asks the UUNET technician for the phone number of the customer so he may get in touch with the customer immediately to resolve the problem. Due to privacy restrictions, UUNET doesn't give out customer information. Instead, UUNET offers to contact the customer instead. Yeah right! I'm sure they'll get right on it. If only the Webmaster could send a message to the IP address (193.3.2.1) informing the person on the other end that they are performing a DoS attack.

INSTANT MESSAGE TO THE RESCUE
A recent survey estimated that 80 percent of users are utilizing some form of instant messaging. With the push for standardized, interoperable instant messaging, it is conceivable that a person can IM someone regardless of the platform that he running, (i.e., Windows, Mac, Linux).

My idea is to IM by IP address and not by some authenticated user account. Essentially, you are bypassing the IM provider, which normally performs the IP address translation for you. In our scenario, the Webmaster could open his favorite IM client and then type in the IP address of the attacking PC (193.3.2.1) to let the other party know he is infected with something.

Of course, my idea has some dangers as well. Imagine when spammers learn that they can IM you by using an IP address. They can put my little war dialer to shame. Also, the leading IM providers (AOL, ICQ, Yahoo!, Microsoft) would probably not want you to bypass their networks to send text messages. But I think I have a solution for both of these problems.

Today when you IM someone, you need their screen name or e-mail address. When you open your IM client, you are authenticated and the IM provider has a record of your current IP address, which was logged when you first authenticated onto the IM service. When you try to IM someone by their screen name or e-mail address, the request is forwarded to your instant messaging provider, who translates the screen name or e-mail address to the IP address of the person you are trying to reach and then forward the instant message to that IP address. Since the IM client is listening on a specific port number for messages, it can receive and display the message.

Now for my solution to prevent IM spam. I would like my hypothetical IM client to support two modes. The first mode is the traditional mode that accepts incoming messages from those who send a message from an "authorized" IM provider to your screen name (not your IP address). For example, if someone is logged into AOL and they IM me by my screen name, then they have the capability to send entire text messages with no restrictions.

The second mode is more restricted. It allows someone to IM me by my IP address, but it only lets the person send a numeric code. The numeric code sent can be pre-defined by some Internet standards body to correspond to various viruses, worms, and other critical alerts. Therefore, "code 1" could correspond to the Code Red worm, "code 2" could correspond to the SirCam virus, and so on. By only allowing numeric codes to be instant messaged when "dialing" directly via IP address, the user is protected from any IM spam and be instantly informed when they have been infected by something. IM providers probably couldn't care less that these simple numeric code alerts are routed directly to the IP address of the IM client rather than routed through the IM provider's network first.

Additionally, these special codes can be programmed on the IM client to play a special sound (such as a siren) or flash the screen with various colors. Flashing the screen might be important since not all Web servers have sound cards or speakers installed. It might be a good way to grab the attention of the Web server administrator.

ONE STEP FURTHER
To protect against pranksters sending false alarms, my idea could be extended even further. A running counter could be displayed on the screen to indicate the number of incoming "coded" IMs by IP address. If a Web server receives dozens of "code 1" alerts, all from different IP addresses, then no doubt this is a legitimate alert. Also, perhaps there could be something equivalent to the MAPS (Mail Abuse Prevention System) blacklist that keeps track of the IP address of pranksters who send false alerts. Or perhaps only ISPs with predetermined IP addresses are allowed to send these special numeric code alerts to IM clients? If the ISPs add the capability to detect DoS attacks and the like, they can program an automatic way of notifying their customers simply by IMing the customer's IP address.

In fact, this could be a value-added service that ISPs could provide. Notifying customers that there has been a security breach in the customer's systems could certainly be a profitable, high-margin value-add. By utilizing ubiquitous instant messaging technology, my idea would not be that hard to implement.

Let's face it, most people don't update their virus software on a regular basis and even the most diligent IT manager can't keep up with Microsoft's daily security patches. Sorry Microsoft, you deserve that one. Once an instant messaging standard is ratified, this could provide a valuable tool in the fight against fast-spreading worms and viruses. The Internet has become a critical tool in our business and personal lives. There will always be those who will exploit the anonymity of the Internet for personal gain. Let's just hope that technology will keep the bad guys in check and help to tame the Wild, Wild Web.

[ Return To The October 2001 Table Of Contents ]