Network Defense by Rik Farrow There are holes in your firewall, and there is little you can do about them This spring, the news was full of stories about Chinese espionage in the US nuclear research labs. Mention was made of files moved to a computer accessable from the Internet. The files had been on a computer connected to a classified network. The assumption was that once the files were on the Internet-connected system, thay were lost. The US government has a policy that classified information is never stored on Internet-connected systems. It is simply too dangerous. Not only is there a risk from hackers but there is also the risk that an insider will accidently or purposely transmit the data over the internet. Any connection with the internet has its hazards. Hackers have proven resourceful in sneaking their connections through firewalls. There are several well known tools, as well as techniques, for slipping past firewalls. In a few cases, you can do something about these leaks. But in most cases having an Internet connection makes it impossible to stop all clandestine activity. The Easy Way The easiest way is also the most common. The attacker will install some networking software on an internal system that communicates using a port address permitted by the firewall's configuration. A popular port to use is port 53 TCP, normally used by DNS. Many firewalls permit all traffic using port 53 by default because it makes configuration of the firewal simpler and reduces support calls. Other ports can be used as well--more on this later. Now, you might be wondering how the attacker has managed to install this software on a system behind the firewall in the first place. In some cases, the attacker has already success- fully broken in, so installing software is a conparatively trivial task. One tool even comes with suggestions for breaking in with a focus on attacking an external webserver as the first step. But the attacker does not necessarily need to break in. One popular technique is to e-mail the target a message saying this: run the enclosed program to see if Back Orifice has been installed. The attached program reports that Back Orifice has not been installed and then installs it without notifying the user. This is an old technique (about a year old). Another trick is to provide a free download of software that is adver- tised as useful for remote administration. If you visit the Web site for NetBus, NetBus is advertised as a remote administration tool, but functions equally well as a back door into the system, along with a network sniffer, eavesdropper, registry editor, file downloader, process killer, and remote system shutdown. Actually not bad as a remote administration tool, but not something you want in the hands of an attacker. There are other ways an attacker can use to get these programs installed on Windows machines. On Unix systems, the common approach is to gain root privileges on the target machine and install a rootkit. Rootkits have been around for over five years. The primary goal of the original rootkit's designer was to install a password sniffer. The secondary purpose was one of stealth. The rootkit included trojan horse programs that hide its presence and activity. The third goal of the rootkit is to install backdoors that make breaking back into this system trivial. Backdoors Rootkits have come a long way in five years. Newer versions include more trojan horses and more back doors. Backdoors include a replacement login program that provides root access whenever a magic password is used. The remote shell program (which should never be permitted through your firewall) also responds to the same magic password. The internet daemon, inetd, is also trojanned with a hidden service listening to the discard port or some high numbered TCP port. On both Windows and Unix systems another popular technique is to install a new service. On NT systems this involves editing the registry as well as installing the software. On Unix systems either system start up files or the inetd configurations files must be edited so that the new service will be started after rebooting. There are even sneakier ways for backdoors to operate. One tool currently making the rounds is based on a paper first published in Phrack Magazine, an online resource for hackers and phone freaks. The paper describes a tool named LOKI, named after an evil Norse god, and uses ICMP Echo Response packets to carry its payload. ICMP Echo Response packets are normally received by the ping program and many firewalls will permit responses to pass freely. After all, the response follows a legitimate request normally. But what LOKI does is to piggyback commands in the data portion of the response in one direction and send the results of the command back in another response packet. This is a little like a wolf in sheep's clothing. LOKI, and the related LOKI2 and pinsh, are rumoured to be widely used, as well as rarelt detected. The wise (and paranoid) firewall administrator blocks PING packets at the firewall. Use the Web A tool that appeared on a Dutch hacker site uses the Web to sneak though firewalls. Just about every firewall permits access to remote web servers. This tool emulates a Web browser sending requests to a remote Web server. Except that both the Web browser and server are different invocations of the same Perl script. The browser generates a phony request at a predetermind time, and the server notifies the hacker that a command maybe issued. If the hacker is ready, the command is sent as a phony Web response, executed by the fake browser and the results sent back as another phony request. This may continue for many commands or until a time out occurs. (see illustration). To a firewall this traffic looks like normal Web traffic. The script found on the Dutch site actually has a small flaw that would permit some firewalls to detect that something is amiss and block the phony response containing the command. But not all firewalls would succeed at this. Only strictly written application gateways would detect an error like this. Another tool was not created for hacking at all. During the first RSA DES Challenge, thousands of people worked on cracking a 56 bit key using a brute force approach. Each person's computer was assigned a small portion of the key space and tried each key in turn. The program used looked for a known string in the decrypted data, and would continue trying keys until successful or the portion of potential keys ran out. Either way, the program sent back an encoded message to a monitor system, which would send out another portion of the key space to try. The protocol used was based on UDP, a protocol most firewalls will not generally permit for good reasons (not session-oriented and very easy to spoof). Many possible participants in the DES Challenge were situated behind good firewalls, so the organizers wrote a Perl script that converted the UDP packets from participants into Web browser requests, and another script that took the Web requests and converted them back into the UDP packets that the monitor system expected. New sets of keys were sent back to the Perl script, converted to a syntactically-correct Web response, and sent back to the client Perl script. This script performed the final conversion into UDP packets for decryption engine running on the desktop. Although this system was not designed for evil-doing, it could easily be abused. Marcus Ranum designed what is probably the earliest example of code written to tunnel one protocol over another. He wrote software that captured UDP packets from a network, uuencoded the packet header and data, and sent the encoded message as email using UUCP. UUCP (UNIX-to-UNIX Copy Protocol) transmitted email, netnews, and files using dial-up modems and POTS (plain old telephone system), and was slow but reliable. The receiving end passed the email to another program that converted the encoded message back into a UDP packet. Ranum managed to support NFS (Network File System) using this technique--proof that just about any protocol can be used to transport another. Endless Tunnels Most firewalls pass all outgoing email without checking its contents. Even content checkers could be foiled by burying the encoded message within text, somewhat the way that steganography hides data in images. And firewalls permit most Web browser requests, checking only (in some cases) that the destination is not a proscribed site (pornographty, hate groups, gambling, etc.). If an attacker can install his or her tunnel on the inside, or you have a malicious insider, you have little hope of preventing leaks from the inside. Your firewall has huge easily exploitable holes in it, and there is little you can do about it. This is why information that can be considered life-threatening, such as a list of undercover agents, must never be kept on systems that are connected to the Internet. A hospital's administration would be wise to keep patient data off Internet- connected systems as well, the corporation keeping critical business plans inaccesible, the salesperson hiding the list of hot clients. Obviously, sensitive data is often exposed. The only example of handling sensituve data correctly that I am aware of is the US goverment's separation of classified networks from Internet- connected ones. I presume that other countries do this as well. The conveniences of networking and the Internet must be balanced against the risks. For most of us, this simply means being aware of the potential for leaks of data, and protocol tunnels that can be used by an attacker's backdoor. And for spys, the Internet will continue to be an incredible bonanza. Resources: http://www.fas.org/nuke/hew/Usa/Weapons/Allbombs.html Chinese claim that this site contains the information they are accused of stealing. http://www.netbus.com for Netbus information http://www.phrack.com/archive.html: Look at volume 49, article 6, for the orginal LOKI paper