Real hackers go to Usenix

by Carole Fennelly

March 29, 2001 —

I don't attend very many conferences, mostly because I have to cover the expense myself. However, the 9th Annual Usenix Security Symposium held this past August in Denver looked too good to miss.

I wasn't disappointed. In fact, I wondered why I'd waited so long to attend a Usenix conference. It was probably because I felt that I could just read the research papers instead of actually attending, but that's like shunning a concert with backstage passes because you can buy a CD. There's so much more to the live conference than the purely technical presentations.

This article describes my view of the conference -- it's by no means a complete picture, as it's impossible for one person to attend every talk. For a complete review of the conference, I urge you to get the November 2000 issue of ;login magazine (a publication of Usenix and SAGE).

Keynote address

Dr. Blaine Burnham presented an interesting keynote address, "Design Principles of Simplicity." "Why do buffer overflow attacks still work?" he wondered. He went on to stress that security should not be an add-on. In some ways, Dr. Burnham was preaching to the choir. I know several managers and developers who refuse to accept that security needs to be designed into the architecture from the start.

As an example to illustrate his point, he referred to weeds indigenous to the American Southwest known as goatheads. These nasty little weeds produce spiked seeds that are the bane of bicyclists. Dr. Burnham pointed out that experienced cyclists quickly learned to take countermeasures to protect their tires. Why hasn't the software industry learned to take appropriate countermeasures that protect systems before they're flattened? he asked. Security must be designed into the system, not added on later. Intrusion-detection systems (IDSs) and patches are a last resort.

Tracks

The two major tracks for the Technical Sessions were invited talks and refereed papers.

"Computer System Security: Is There Really a Threat?" Dave Dittrich, University of Washington: http://www.usenix.org/publications/library/proceedings/sec2000/invitedtalks/dittrich_html/index.html

Dave Dittrich is sometimes referred to as "the DDoS guy" because of the expert analysis he provided during the infamous distributed denial-of-service attacks earlier this year. Dave's talk was perfectly timed after Dr. Burnham's keynote, as he continued to berate poor software quality that leads to security vulnerabilities. He noted that the attacker community communicates and works faster than the security industry. The security community (vendors especially) needs to work together faster, instead of posturing for commercial advantage.

Dave provided a timeline of the DDoS attacks that clearly demonstrated that there was plenty of warning about the threat of DDoS attacks in the open source community. Yet people were still unprepared to respond. Attacked sites focused on quick restoration of service, not forensics. Dave stressed the importance of preserving evidence for potential law enforcement use, and of understanding how the system was compromised.

Businesses must develop good incident response procedures and forensic skills, he pointed out. "The business community must acknowledge security as the cost of doing business, not just overhead," Dave emphasized. He recommended that every software organization have a chief hacking officer to test the quality of developers' code before it's released, especially for buffer overflow errors. Dave also recommended that more resources be directed towards system administration as well as system testing. He compared software architecture to building standards, and observed that anyone who constructs an unsafe building is held criminally liable for damage or injuries caused by buildings that don't meet these standards. Builders factor the cost of adhering to safety codes into their budget. Why isn't this done in the software industry?

After lunch, we decided to check out the exhibitor's floor. Brian Martin (a.k.a Jericho of Attrition.org) dragged me in so that he could pick up freebies from the vendors.

The products I describe here happen to be those that made me pause to get more information. I'm not endorsing any of them, nor am I panning those I don't mention.

Argus Systems Group

Representatives from Argus had contacted me after my article about chroot jails, telling me that using chroot isn't a good solution and that I should look at their product instead. Marketing people be warned: this type of obvious marketing ploy tends to prejudice me against a product. However, I saw a bunch of the Sun engineers talking to them and felt it was only fair to find out more about it. Trusted operating systems, such as the Network Pitbull by Argus, have a certain appeal for companies that don't have the expertise to properly secure a system. They also have a place in installations where a secure standard is desired that's maintained by a third-party company.

I'm still not convinced that using a trusted OS is worth the accompanying administrative headaches and added complexity. Very large installations usually have a pretty technical administrative staff that's perfectly capable of hardening systems to its own standards. I just can't see such staffers paying additional money to use a trusted OS.

Some of the issues that come to mind are: licensing problems, patch updates (there's some lag while the trusted OS vendor updates its OS), performance impact, application compatibility, and administrative overhead. I have not evaluated the Argus Pitbull -- these are just issues I would test for if I did.

A chat with the Sun engineers

While standing around the Argus booth, I got to chatting with Glenn Brunette, a network security architect for Sun Professional Services. I mentioned to Glenn that it would be nice if Sun gave an administrator the option to install a hardened system, instead of having everyone write and implement his or her own Solaris lockdown documents. Glenn explained that it would be difficult to arbitrarily decide on hardened features that would satisfy every installation. Also, what happens when patches are applied later?

Glenn went on to describe a toolkit that he, Alex Noordergraaf, and Keith Watson are developing for Sun's Blueprints Online program. The toolkit, called Jumpstart Architecture and Security Scripts (JASS), gives the administrators the power and flexibility to customize the hardening process to their company's standards. With some other toolkits, it's an all-or-nothing approach unless you want to get into the source code. With JASS, the same distribution (same finish scripts, different drivers) can be used for an entire network of systems. A sample hardening driver is shipped that adheres to the published Blueprint documents regarding hardening.

JASS is currently in revision 0.12, with a new version (0.2) of the toolkit due in early November that will include additional Solaris 8 hardening functionality. I plan to evaluate the toolkit in a future article, as maintaining a hardened system is one of the most critical elements of a secure installation. Those patches will get you every time!

Network Security Wizards

I first noticed Network Security Wizards (NSW) and its Dragon IDS because of the similarity in the company's name and motif to those of my own company, Wizard's Keys. This coincidence reminded me of when Rain Forest Puppy referred me to Ron Gula (NSW's CEO and founder) when I was looking at intrusion-detection systems. RFP was pretty impressed with the performance of the Dragon IDS and knew I was looking for a system to monitor Cisco PIX firewalls. As luck would have it, Ron was manning the NSW booth himself and was happy to answer my inquiries.

Ron explained: "Technically, the network IDS is the Dragon Sensor, and its basic claims to fame are operation at Gigabit Ethernet speeds without hardware acceleration and one of the deeper signature libraries available on the market. The product that analyzes PIX log files is called Dragon Squire. It currently can look at any ASCII log file or stream of SNMP traps. We currently offer log analysis for Cisco, Cisco PIX, ipfilter, ipchains, and ipfw. Checkpoint, Raptor, and Sidewinder log formats are also being produced. In addition to the firewall log files, Dragon Squire also monitors log files for Web, FTP, Sendmail, DNS, syslog, and many other applications. It also performs MD5 analysis of key system files. A version for NT will be available in Q4."

My list of products to evaluate is growing...

Cryptographic systems

Lew Koch, a columnist for whom I have great respect, told me to that I should be sure to attend Suelette Dreyfuss's (author of The Practical Use of Cryptography in Human Rights Groups) talk. This didn't look like it was going to be a very technical talk, and, consequentially, had very light attendance.

This was unfortunate, because Suelette described the most compelling motivation for developing advanced cryptographic systems: saving human lives. We've all heard of the horrible human rights abuses in Kosovo that led to the deployment of peacekeeping forces and the eventual overthrow of the Yugoslav government. But how did we learn about these brutalities?

Suelette described the activities of human rights workers who risk their lives gathering evidence of atrocities around the globe. These individuals store data from their interviews with local witnesses on laptops that they carry back to the United Nations and other global organizations. Naturally, if they're caught with this information by an oppressive government, the witnesses are summarily executed.

Suelette described the methods used for encrypting the data and stressed the need for computer literacy in human rights groups -- many of whom think locking a computer in an office will secure its data. She explained that simply encrypting data is not enough. Human rights workers caught with a laptop containing encrypted data may be tortured to reveal the keys or password. What's needed is a deniable cryptographic system, which a volunteer project called Rubberhose is developing. The Rubberhose system is designed to encrypt data in such a way that it's impossible to prove the existence of the data.

The script-kidiot hackivists should take a lesson from this and find a real cause that doesn't involve destruction of property. More information can be found at http://www.rubberhose.org.

Hallway conversations

It's always a pleasure to run into Steve Bellovin, whom I first met about 15 years ago at Bell Labs. I've always been impressed with how unimpressed Steve is with himself. Considering some of the prima donnas in this industry with far less technical knowledge, Steve could be justified in asserting some ego. Happily, he doesn't.

I asked Steve about a concern I had with sending encrypted data through a firewall. While encryption can be a very good thing, not knowing what that data stream will do at the receiving end can be very bad. Steve referred to a paper he had written on distributed firewalls, a must-read for anyone who relies on firewalls to provide security: http://www.research.att.com/~smb/papers/distfw.html

While fueling up on caffeine, I ran into Dave Dittrich. We discussed his talk and a recent article I wrote for Unix Insider on forensics. Dave had sent me mail pointing out the necessity for getting a complete backup of a system before any forensic work is started. I had neglected to mention that in my article, but Dave is absolutely right. In the situation I described, the system had been compromised so many times that it was difficult to isolate the various exploits that were installed. Also, there was no intention of prosecution. However, it's a step that should be taken, regardless of intentions.

While talking to Dave, Casper Dik (a demigod to Solaris security types) asked for a word with me about a Solaris lockdown document which he thought I had worked on; the paper had some factual errors. It was case of mistaken identity -- I had previously talked to him about writing such a document on Solaris 8 security, but had never gotten around to it. Casper referred me to the Sun Blueprints section and the JASS project, which I plan to review.

After awhile, Alec Muffett (author of Crack and another Sun demigod) joined the conversation, which became quite lively. In a discussion about the limitations of firewalls, Alec described his security model as "bags of onions, all strung together in racks." In other words, security must be hardened throughout the network, not just on perimeters.

I particularly enjoyed meeting and talking with Jody Patilla, one of the few people I had met who really had a grasp of how the corporate world works. This impromptu gathering of about a dozen people lasted for almost an hour before we realized there wasn't much time for lunch before Mudge's talk.

"Methods for Detecting Addressable Promiscuous Devices," Mudge, VP of research and development, @Stake: http://www.usenix.org/publications/library/proceedings/sec2000/invitedtalks/mudge_html

Mudge described local Ethernet segments as party lines on which anyone on the segment can eavesdrop. Even with encryption, someone monitoring the network could gather information on network topology and use. Mudge described the various methods that could be used to detect sniffers on a network, and the pros and cons of each. Clearly, this was the most popular talk of the conference. Mudge is arguably one of the brightest hackers on the planet and is extremely personable. He managed to make this very technical presentation both informative and entertaining.

We made up for harassing Mudge by buying him a beer at the bar after his talk.

http://www.wkeys.com/pics/usenix_pics/cf_mudge.jpg

http://www.wkeys.com/pics/usenix_pics/casper_mudge_bar.jpg

Wrap-up

The last security conference I attended was two years ago, and I found myself walking out of every talk in disgust at the self-promoting agenda of the speakers. Usenix was different. If there were any prima donnas present, I didn't run into them. In fact, I liked it so much that I plan to attend the LISA conference in New Orleans this December.

If you've never attended a Usenix conference, I strongly urge you to go to one. If you do attend, maybe I'll run into you there. Just don't tell me the Pink Panther Hotel joke...

Unix Insider