Tangled in the Threads

Jon Udell, October 13, 1999

Beyond the Firewall: Full-Spectrum Security

Firewalls are frighteningly easy to bypass, and they create a false sense of confidence.

I've just returned from The Internet Security Conference, where I participated in a panel discussion on the deployment (or rather, non-deployment) of PKI-based technologies. But I'll confess I had to drag myself away from another session to attend mine. In the next room, a couple of white-hat hackers, Eric Shultze and George Kurtz, were giving an all-day seminar called "Extreme Hacking: The Art of Attack and Penetration." (Kurtz is coauthor of a new book, Hacking Exposed: Network Security Secrets and Solutions, will undoubtedly become a must read for network administrators).

It was a brilliant demonstration. The substrate involved about a half-dozen machines: a firewalled internal network, a DMZ with NT and Solaris Web servers, a router, and outside the router two attack machines, one Linux and one NT.

A lot of the tools and techniques I've seen or read about before, but it was awesome to watch the whole process. First the router was probed to check its filtering rules. One open port allowed a buffer overflow exploit against the ToolTalk service on the Solaris box. Bingo! Root access, in the form of an xterm shipped back to the attacking Linux box. The router was blocking port 139, the usual avenue for NT exploits, but at this point that was irrelevant. With a beachhead on the Solaris, the NT servers in the DMZ could now be attacked directly.

In fact, even without that beachhead, one of those servers was directly vulnerable from the outside, via port 80, to another buffer-overflow exploit (the ".htr" exploit). Using it, the attacker sent NT an executable payload that:

What? An NT root shell? So much for the argument that NT's lame built-in remote-access is a security virtue. All the existing NT remote access tools -- remote.exe, VNC, you name it -- double as hacking tools. But it turns out to be easy -- and elegant! -- to pipe CMD.EXE's output to netcat and materialize an NT root shell anywhere.

The other NT box wasn't vulnerable to the ".htr" exploit, but was vulnerable to the "MDAC" exploit which uses an RDS (remote data services) request to remotely run VBA's shell() command. What command? A batch file that ran tftp to fetch a hacking kit including netcat, which was again used to "shovel back" an NT root shell -- this time through a two-hop redirection via the hacked Solaris box -- to the attacker.

With the DMZ fully compromised, attention turned to the firewalled internal network. How to get around the firewall? The juiciest targets are dual-homed machines -- that is, boxes with two NICs connected both to the DMZ and the internal net. In theory there should be none; in practice, users (well, power users and developers) frequently do this so they can get their work done more quickly. How to find the dual-homed machines? An NT resource kit tool, getmac, aimed at everything in the DMZ, showed that one of the Web servers was dual-homed.

Note that getmac's targets didn't need to be compromised. The amount of information that NT will divulge without any privilege or authentication is truly impressive. Another favorite trick was the "null session command" which looks like this: 

net use \\10.1.1.200\ipc$ "" /user:""

This request says, in effect, "connect me as nobody with no authentication." But it does make a connection! And on pre-SP5 NT boxes without the RestrictAnonymous regkey, SomarSoft's DumpACL will gladly list users, last login times, password expiration policies, and more.

The Firewall Fallacy

Some might argue that the demo was concocted. Why didn't the router filter more ports? Why weren't the latest security patches applied to Solaris and NT? Why weren't NT's networking services unbound from the NBT protocol (NetBIOS-over-TCP/IP) on the external NIC? In fact, as we know but hate to think about, the scenario was all too real.

The grim fact is that you can do almost everything right, and still screw up horribly. A single dual-homed box in the DMZ, with a single exploitable security hole, gives an attacker the keys to your kingdom: the internal network. And if the DMZ was easy pickings, just imagine what happens when these jackals have free run there. Well, of course, that's the scenario we simply refuse to imagine. We support the fallacy that we're safe behind the firewall because it's simply too painful to imagine otherwise.

Pretend your firewall didn't exist. What would that mean? Suddenly security would no longer be a matter of marshalling all your defenses at the front gate. The battle would shift to each and every network-connected computer in the organization. You'd have to think about full-spectrum security: encryption of files on hard disks, encryption of LAN traffic, strong authentication everywhere.

Do we really want to go there? No. Should we? Probably. It's overwhelming to contemplate, I know. But we need to solve this problem anyway, because the Internet/intranet boundary is really just a fiction. In a typical working day, as much communication flows across the firewall as flows behind it. The same end-to-end encryption that could protect that external communication could also protect the internal communication. And should.

VPN experiences

Whew! It's too hard to think about that whole problem. But maybe the early experiences with VPN technologies are a step in the right direction. Recently I asked, in the networking newsgroup, for reports on VPN deployments.

Peter Hess:

I have been using MS PPTP on an NT laptop into an NT LAN at work. The setup was basically a no-brainer on both ends and worked right on the first try. Of course, I had the O'Reilly "Virtual Private Networks" book to scare the system into operation and help me avoid the pitfalls.

Connectivity to protected resources is fairly good, although there are some strange quirks with NETBIOS name resolution. In Server Manager, I can see every machine by name as expected. But certain of them, I cannot access by name, only by IP address. This only happens over the VPN, not when I am directly connected. I don't know if WINS is messed up; I haven't had time to look in more detail since I can get to the machines by IP.

Approaching the problem from a Linux perspective, Alan Shutko came up with a PPP-over-SSH solution:

Normally, ssh will allow you to forward certain local ports out over the ssh connection, and vice versa. That's how I was getting my news. That works on a per-port basis, so it's pretty much a per-app basis, since you have to reconfigure the apps to hit the localhost at some port.

However, it turns out you can also run ppp over an ssh. I just set that up (using a script snarfed from the ssh faq). Then I have another network interface, just like a normal PPP connection, and I can set up routes to anything I would like to get to. I just set up routes to my news server, my mail server, a POP server... whee! And everything just plain works.

Randy Switt:

I'm currently evaluating some nice pieces of equipment from Sonic Systems (SonicWall Pro) that supplies VPN among other things like a firewall, DMZ zone, NAT, DHCP server, etc. So far it looks like a nice way to hook up two remote LANs securely over the internet. It CAN be configured to allow individual users (by username and password) into the LAN from remote locations using supplied VPN client software (windows version only unfortunately). Its extremely easy to set up via a browser interface and is made to be rack mounted.

VPNs everywhere?

It's early days yet for VPNs, and to the extent people are deploying them, the focus is on protecting traffic on the known-to-be-insecure public Internet, not the presumably-secure intranet. I'm suggesting, though, that experience gained with the current generation of VPN technologies, and the emerging generation of IPSEC solutions, will be more valuable than we think. Our internal networks are vulnerable to a degree that it is paralyzing to contemplate, which is why we don't think about it much. In the long run, we need full-spectrum security that applies to every hard disk and Ethernet segment as well as to the Internet router and firewall.

Jon Udell (http://udell.roninhouse.com/) was BYTE Magazine's executive editor for new media, the architect of the original www.byte.com, and author of BYTE's Web Project column. He's now an independent Web/Internet consultant, and is the author of Practical Internet Groupware, forthcoming from O'Reilly and Associates.

Creative Commons License
This work is licensed under a Creative Commons License.