by Rik Farrow
Just because the front door of your house is locked doesnât mean someone canât get in through the backdoor, a concept that extends to computers. Most backdoors installed on exploited systems simply listen at a TCP or UDP port. Attackers use backdoor shells to execute commands on compromised systems, usually as Local System or as root. But just about any properly configured firewall blocks this type of backdoor, as most administrators set up firewalls to block arbitrary incoming connections.
Trojans containing backdoors that make outgoing connections can pass right through most firewalls. Most organizations configure their firewalls focusing external threats, and miss these connections as they slip past their defenses. The most sophisticated backdoors disguise their traffic as ordinary Web browsing.
Careful firewall configuration can block many attack tools that rely on successful outgoing connections. But the sneakiest of backdoor tunnels may only be detected through the use of network traffic analysis.
Successful attacks, whether via exploits or viruses, are often used to install backdoors. The most commonly used ports (see Resources) are ones that any firewall that blocks incoming connections except to specific servers will stop. Many backdoors exist because there are plenty of home-user systems that arenât protected by firewalls, and are open to attacks and further exploitation. Post-exploit tools, such as SubSeven and BackOrifice, listen at well known ports, and there are security tools as well as scanners that search for these trojans.
A much more subtle threat is posed by backdoors that make outgoing connections, instead of waiting for an incoming one that can be blocked trivially. Some recent trojans and distributed denial of service (DDoS) agents connect to channels on IRC servers, and wait there for commands. For the attacker, this method has the advantage of making an outgoing connection for remote control, and providing a degree of anonymity. The attacker has only to connect to the same channel and issue commands to any participating agents. IRC relays are perhaps the most commonly installed tools after a successful attack on a UNIX system, which gives the attacker a convenient relay to further obscure his or her real location.
The LSD sendmail exploit (see âGetting the Most out of Firewalls,â www.spirit.com/Network/net0403.html ) used a different technique. The exploit fires off an outgoing connection to port 25/TCP, the same port that would normally be used by a mail server. This connection presents a shell prompt to the attacker who ran the exploit, assuming that the exploit succeeded. Using the mail server port makes this attack much more difficult to stop via outgoing rules on a firewall, as connections to this port are expected. A connection to an IRC server, on the other hand, might be blocked at a firewall, depending on the policy used to formulate the firewall rules.
Effectively configured firewalls include rules that block all outgoing connections except for those permitted by policy. These configurations will block connections made by Trojans or backdoors to all ports, except those specifically permitted by the policy. And just monitoring the firewall logs for connection attempts to blocked ports on the inside of the firewall can reveal much more than policy violators. Often, a failed attempt, especially one that gets repeated regularly, indicates a backdoored system attempting to connect out, over and over, without success. These attempts often occur at regular intervals, a hint that some form of automation is behind these events.
Firewalls rarely block all outgoing traffic. Ports must be left open for outgoing connections permitted by policy. Two of these services are particularly problematic: HTTP and SSH (Secure Shell).
Tools for tunneling arbitrary traffic over HTTP have existed since at least 1999. HTTPTunnel listens at a port on an internal system, converts all the packets it receives into an HTTP request, and sends it to a special external server that converts the request back into IP packets. While any TCP application protocol can be passed using HTTPTunnel, the same approach has also been used as a method for presenting a shell prompt to a remote attacker. Like HTTPTunnel, this tool sends a specially crafted HTTP request to a remote "server". This server sends a notification that the tunnel is ready, and if the attacker is present, he or she can send back a command to execute. The "server" packages this command up as a valid HTTP response, and the local portion of the tunnel unpacks the HTTP response. When the command is executed, the output of the command gets sent back as another HTTP request. If there is no command to execute, the fake server sends back a null command, and the tunnel exits. Tunnels like this one get restarted at regular intervals using commands like at or cron.
Because this HTTP tunnel reverses the normal client/server relationship, it produces some anomalous behavior that can be detected. In two papers presented at the 2000 USENIX Security symposium, Zhang and Paxton (see Resources) demonstrated methods for detecting backdoors and command relays (which they call stepping stones) using packet analysis. For command relays, their analysis tool examined the delays between packets, searching for matching delays in pairs of connections. These delays are found whenever a connection includes packets based on a human typing at a keyboard, and proved to be a strong indicator of a relay compared to other methods of packet analysis, including content analysis.
In an article that appeared in the December 2003 security edition of ;login:, (http://www.usenix.org/publications/login/2003-12/pdfs/mudge.pdf ), Peter Mudge (www.intrusic.com, previously a member of the L0pht) discusses metrics for packet analysis for uncovering HTTP tunnels, such as timing, data contents, and size of packets. For example, in an HTTP tunnel, packets sent from a client to a server are larger than response packets from the server to the client, because they contain the output of a command.
The SSH protocol also permits the tunneling of arbitrary protocols over arbitrary ports. As SSH also encrypts its tunnels, just examining packet contents does not reveal what is being tunneled-- all that can be detected is the fact that an encrypted tunnel exists. Packet analysis might be able to detect SSH tunnels being used by a remote attacker as a reverse shell.
While you can block outgoing SSH connections using the standard port (22/TCP) with your firewall, SSH can optionally connect to any port. And itâs unlikely that your organization blocks all access to the Web using HTTP's port 80/TCP. A new class of defensive tools that look for anomalous patterns in outgoing traffic will need to be developed to detect backdoors that use tunnels.
On the bright side, most of today's exploits exhibit the more typical behavior of simply listening to a local port--something easily blocked--or connecting to an IRC server--something that can also be trivially blocked if your security policy permits it. But tunneling using HTTP, SSH, or other permitted protocols looks like the method of choice for the subtle attacker.
A list of TCP and UDP ports that includes ports used by backdoors can be found
at:
www.commodon.com/threat/threat-ports.htm
A tool for tunneling arbitrary TCP protocols via HTTP (through
firewalls) can be seen at:
www.nocrew.org/software/httptunnel.html
You can find Zhang and Paxtonâs paper about detecting stepping stones (relays)by analyzing delays between packets in pairs of connections at: www.aciri.org/vern/papers/stepping/