IT@TT - Online

The Strange Tale of the Attacks Against GRC.COM

Nothing more than the whim of a 13-year old hacker is required to knock any user, site, or server right off the Internet. I believe you will be as fascinated and concerned as we were by the findings of Steve Gibson's post-attack forensic analysis

On the evening of May 4th, 2001, GRC.COM suddenly dropped off the Internet. Within a minute of the start of the first attack it was clear that we were experiencing a "packet flooding" attack of some sort. A quick query of our Cisco router showed that both of our two T1 trunk interfaces to the Internet were receiving some sort of traffic at their maximum 1.54 megabit rate, while our outbound traffic had fallen to nearly zero, presumably because valid inbound traffic was no longer able to reach our server. We found ourselves in the situation that coined the term: Our site's users were being denied our services.

I had two priorities: I wanted to learn about the attack and I wanted to get us back online. I immediately reconfigured our network to capture the packet traffic in real time and began logging the attack. Dipping a thimble into the flood, I analyzed a tiny sample and saw that huge UDP packets — aimed at the bogus port "666" of grc.com — had been fragmented during their travel across the Internet, resulting in a blizzard of millions of 1500-byte IP packets. Mixed into this appeared to be ICMP debris from large-packet ping commands.

We were drowning in a flood of malicious traffic and valid traffic was unable to compete with the torrent. At our end of our T1 trunks, our local router and firewall had no trouble analyzing and discarding the nonsense, so none of our machines were adversely affected. But it was clear that this attack was not attempting to upset our machines, it was a simple brute force flood, intended to consume all of the bandwidth of our connection to the Internet . . . and at that it was succeeding all too well.

Gibson Research Corporation is connected to the Internet by a pair of T1 trunks. They provide a total of 3.08 megabits of bandwidth in each direction (1.54 megabits each), which is ample for our daily needs. But from there all of the traffic bound for us must be funnelled through our two T1 trunks. Therefore, in order for the congestion of our T1's to be relieved of the malicious traffic, the "bad packets" had to be filtered before they left Verio's router. In this way, the packet flood would be stopped at a high-bandwidth point — upstream of the T1 choke point — thus allowing the "good packets" to slip past the bad packets and cross our T1's in peace.

It took us a while due to a comedy of changed telephone area-codes, mistyped eMail addresses, slept-through pager beeps, the attack's Friday night timing, and Verio continually insisting that I be processed through the regular channels of "the system" (which I kept explaining did not seem to be working), seventeen hours passed before I was able to get a competent Verio engineer on the other end of the phone. But once I had a competent engineer on the phone, and armed with my analysis of the attack pattern. In two minutes we applied "brute force" filters to the Verio router, shutting down all UDP and ICMP traffic and GRC.COM instantly popped back onto the Internet.

That part was pretty cool. We were still very much under attack, but because the attack was prone to filtering (thank goodness) we were able to have Verio's router "weed out" the bad packets and return us to almost normal operation.

Fortunately — as we'll see below — the attacking machines were all security-compromised Windows-based PC's. In a fluke of laziness (or good judgement?) that has saved the Internet from untold levels of disaster, Microsoft's engineers never fully implemented the complete "Unix Sockets" specification in any of the previous version of Windows. (Windows 2000 has it.) As a consequence, Windows machines (compared to Unix machines) are blessedly limited in their ability to generate deliberately invalid Internet packets.

It is impossible for an application running under any version of Windows 3.x/95/98/ME or NT to "spoof" its source IP or generate malicious TCP packets such as SYN or ACK floods. As a result, Internet security experts know that non-spoofing Internet attacks are almost certainly being generated by Windows-based PC's. Forging the IP address of an attacking machine (spoofing) is such a trivial thing to do under any of the various UNIX-like operating systems, and it is so effective in hiding the attacking machines, that no hacker would pass up the opportunity if it were available.

It is incredibly fortuitous for the Internet that the massive population of Windows-based machines has never enjoyed this complete "Unix Sockets" support which is so prone to abuse. But the very bad news is this has horribly changed for the worse with the release of Windows 2000 and the pending release of Windows XP.

For no good reason whatsoever, Microsoft has equipped Windows 2000 and XP with the ability for any application to generate incredibly malicious Internet traffic, including spoofed source IP's and SYN-flooding full scale Denial of Service (DoS) attacks!

While I was conducting research into the hacker world following these DoS attacks, I encountered evidence — in attack-tool source code — that malicious hackers are already fully aware of the massive malicious power of the new versions of Windows and are waiting impatiently for the "home version" of Windows XP to arrive in the homes of millions of less clueful end users.

When those insecure and maliciously potent Windows XP machines are mated to high-bandwidth Internet connections, we are going to experience an escalation of Internet terrorism the likes of which has never been seen before.

If I fail in my mission to convince Microsoft to remove this from Windows XP, the historical problems with Internet attacks promise to pale in comparison to what will begin happening as Windows XP is deployed next year.

Thanks to the fact that the fleet of attacking machines were Windows PC's, they were unable to send TCP SYN packets to our port 80 (which would have crippled us completely), and were only able to flood us with UDP and ICMP packets (which we could temporarily ignore). Working with our ISP we were able to filter our receipt of the malicious packets before they were able to reach our T1 trunks. We were able to continue offering our TCP-based services (Web/FTP/News) even while under continuing attack. (to be continued next week)

Steve Gibson
[email protected]

Exclusive to it@tt. it@tt wishes to thank Steve Gibson of Gibson Research Corporation (http://grc.com), for allowing us to reproduce this original article. © 2001 Gibson Research Corporation. All Rights Reserved.

Top

Other Articles