Death of the Net?

In a small-scale rerun of the infamous Internet Worm panic, the New York Times published a front page story on another Internet security crisis. The Sydney Morning Herald reprinted the story in its next edition.

The story contained the usual mixture of fact, fantasy and hype. Non-technical readers might be forgiven for assuming that the long-predicted "death of the net" was at hand. According to the report, most home computers were at (some unspecified) risk of attack.

Sticking to the facts, so far as they are known, the story is a lot less exciting. It certainly seems as if a few hackers (motivation uncertain) have penetrated some systems presumed to be safe in that they were "protected" by various firewalls. A second hack was then applied to some of the penetrated systems to allow authorised sessions in progress to be hijacked (via some kernel table patching).

To get really boring, it is necessary to point out that the method of attack has been documented since at least 1987 in work by Robert T. Morris (sr.) and Steve Bellovin (both at Bell Labs at the time). It is yet another manifestation of the hoary old problem of service authentication based on the requesting host's IP address alone. For an example, consider the contents of your system's /etc/hosts.equiv file.

The current hack is a refinement of the widely known source-routing hack, in which packets with a trusted source address are supplied with an optional "source route" which takes them to an untrusted spoofing host. By selecting your apparent source address appropriately, you can make the system under attack give you a login shell without asking you for a password.

The refinement is that by being able to predict in advance the contents of the necessary handshake packets, packets with bogus source addresses can be sent without the tell-tale source route option. The prediction is possible because packet sequence numbers are not randomised by the originating host.

So how should it be fixed. First and foremost, the net needs to move away from host address based authentication to something which uses some form of secure cryptography (say Kerberos with a public key extension). This will protect your hosts even if your firewall is breached.

Second, and more easily implemented, is to filter out incoming packets on untrusted network interfaces which should only have come from trusted networks or hosts. Unfortunately, it's only very recent revisions of most router software which support any kind of inbound filtering. The outbound filtering they do support is inadequate against this attack.

However, your Internet service provider can install outbound filtering for your link, though you may not want to fully trust this. A second router is another possible way to set up this kind of security. A firewall built around a UNIX host may need some extensive kernel modification to make it safe, unless it trusts nothing on the network, not even itself; this is hard. Remember that filtering rules based solely on the packet source address without knowledge of where the packet appeared (screend, SOCKS etc.) are not enough either.

Last of all, and least importantly, some improvment to the assignment of TCP sequence numbers to new connections to reduce guessability would be handy, though not enough in itself. Be cautious of vendors offering this as a "solution".

Once your system is penetrated, there is no way to prevent a hacker from hijacking any existing connections and using them to penetrate those systems as well. For Sun systems, the hijack is made easy by some useful (to legitimate administrators) but dangerous software available from UNIX source archives.

For further information on this, and many other security threats, browse the WWW and FTP archive at the Computer Emergency Response Team's site cert.org, or join the mailing list for CERT advisories. And above all, don't panic.