
Report on the Fifth Usenix UNIX Security Symposium
By Rik Farrow
The previous Usenix security symposium (Santa Clara,
California in 1993) was a little disappointing. Not that it was
bad, but rather that it fell short of the previous symposium,
with papers that announced SOCKS and other now familiar tools.
It was thought that by waiting longer than a year for the next
symposium, more exciting work would surface. And I believe it
did.
Not that the conference by itself provided all the excitement.
Just getting to Salt Lake City turned into an adventure, with
wind gusts rivaling the first hurricane of the year. Tractor
trailers were blown over along interstates leading west, and
flights bounced about waiting for the winds to subside enough for
safe landings.
This was the situation on Monday evening, June 5.
Unseasonably cool weather prevailed, and a few sunburned faces
could be seen at the conference--people who had visited the ski
resorts surrounding Salt Lake City, usually closed by May. Those
who didn't play that day attended the seminars on UNIX Security
(presented by Gene Spafford) and Internet Firewalls (Tina
Darmohray and Marcus Ranum).
There were several BOFs on Monday night, but I can report on
the one I attended. Trusted Information Systems has supplied a
freely available set of firewall proxies called The Firewall
Toolkit (ftp://ftp.tis.com/pub/firewalls/toolkit), and the
BOF was about the future of the toolkit. Fred Avolio--Product
Manager for TIS' commercial firewall--presided. Avolio provided
a history of the toolkit, and solicited suggestions for its
continued support. TIS walks a delicate balance, as its free
software competes with its commercial product. At the same time,
Avolio, and Marcus Ranum, asserted that they felt very strongly
about providing software with no security-related bugs.
Suggestions ranged from selling the toolkit, restricting its
uploading to registered users, to selling maintenance contracts.
Mike Pearlman, of Rice University, said he couldn't outright buy
the product, but could get the university to pay for
maintenance.
Keynote
Fred Avolio, as program chair, got to introduce his boss,
Steve Walker the founder of TIS. Walker explained how a
conference like this suited him, that he gave up wearing ties
when he started TIS in his recreation room. He also explained
how he wound up in security when he transferred from the NSA to
DARPA in 1974 (if you're from NSA, you must know about computer
security!)
Walker's subject was network security, and he followed a
tangled but interesting thread getting there. He pointed out
that governments came about partially as a means for mutual
protection--that people banded together could organize to defend
themselves (or attack other groups). And that the world of
networking is leaving governments behind. As an example, a man
traveling through Zaire found an Internet-connected site in the
backcountry, and proceeded to read his email and communicate with
his coworkers. It was easier for him to reach around the world
then to contact the capitol of Zaire.
``We want to talk to everyone, but we want protection from the
bad guys. Whenever there's a threat, from malicious hackers or
terrorists, we expect protection. The government argues that the
very tools that we want to use to protect ourselves from the bad
guys will be used against us. This is the dilemma. We want to
have protection, but this protection can be used against
us.''
This brings Walker to his main point, cryptography. He points
out the terrible contradiction now faced by US users and
companies: that they can get the same crypto products from
overseas that they are forbidden to export from the US. There are
two issues here, one, that encryption is considered munitions
(witness the Phil Zimmerman case), and that encryption can be
used by the bad guys. The government's solution to the second
problem was the Clipper Chip, something that appears to have
failed quite miserably. The biggest stumbling block around using
Clipper focused upon the plan that the Federal Government would
maintain keys to all encrypted data in a pair of escrow
accounts.
It is hard to imagine France, Israel, or Japan permitting the
US government to hold the keys to their secure transmissions.
Walker pointed out that the notion of key escrow is not all bad.
Any company which uses encryption would be wise to keep its own
escrow keys, in case an employee quits, goes on sabbatical, or
just plan forgets his or her key.
The scheme Walker described is called Commercial Software Key
Escrow. Each escrow-enabled application would register itself
with a data recovery center. Then the key used to encrypt data
would itself be encrypted and travel with the data. If the key
is lost later, a means to decrypt the key, and then use the key
to decrypt the data, is provided through the data recovery
center. The center does not store individual keys, but does
include a mechanism for recovering the key saved with each
file.
With this scheme, corporations have a method for recovering
data (as do individuals who have forgotten their keys). Law
enforcement can get a the keys by subpoenaing the data recovery
center, a public process. Only the national security people get
left out--they must publicly request keys, and cannot decrypt
data transmission without public notice.
TIS has applied for a patent for this idea, and hopefully,
their patent won't be as closely held as other cryptography
patents have been.
Tuesday Morning
Ira Walker, of SAIC (Science Applications Internation
Corporation), led off with an interesting presentation about
social engineering. He reported about several contracts SAIC had
to test security at remote sites. In each case, they had four
days to penetrate the site, but were only allowed to talk on the
telephone, not to directly exploit the remote systems.
Hackers are quite adept at this type of intelligence
gathering. Social engineering, a new name for con jobs, is an
ancient human skill, and Walker showed that even non-hackers,
without ever visiting the site, dumpster diving, or getting a job
as a janitor, could have tremendous success. Starting out by
using 800 numbers, the group from SAIC probed the target sites,
working their way up from mail rooms to board rooms. They
managed to have a corporate telephone directory overnighted to
them, which provided more data. In general, the target company's
employees' helpfulness worked against them. The SAIC group
acquired passwords, phone numbers for modems, and even had the
necessary software for using secure modems shipped to them
overnight.
Lessons learned included not providing internal identifiers,
like employee numbers, and identifying callers by calling them
back at their proper phone numbers. This was obviously a
chilling exposition for many of the attendees.
Laurent Joncheray, of Merit Network, Inc., described a simple
active attack on TCP next. A passive attack is sniffing
passwords. Active attacks consist of taking over an existing TCP
connection. Joncheray describes enough of the TCP protocol to
provide a foundation for active attacks, then discusses the two
scenarios he used. Both involve desynchronization, getting the
client and the server out of sync by changing the sequence number
at the start of a connection, or by sending null data to the
server later in the conversation. In the paper, he demonstrates
the insertion of commands into a telnet session after it has been
authenticated using S/Key, a one-time password scheme.
Alex Muffett, of Sun Microsystems in jolly olde England,
presented some ideas about how to go about hacking your own
network--especially when its a big one (30,000 hosts, 1,200
subnets), but with only six security people. Muffett said his
biggest problem was that most machines were used by "peasants"
(after introducing his talk using an analogy of a kingdom far,
far, away).
AutoHack is a set of shell scripts that Muffett has yet to get
permission to distribute. He wrote these scripts (and a little
Perl) because he was bored with manually scanning the systems.
Although some tools exist, some cost money, while others (like
SATAN) mainly look for trust relationships. He wanted something
that could easily produce reports that could be passed onto the
"peasants".
His solution is presented starting with a very simple shell
script that explores trust relationships using rsh
and various user accounts. He goes on to explain how it is
better to first "ping" hosts, so as to not waste time waiting for
unresponsive hosts. As he continued to elaborate, he got to his
BIG POINT: all you need is a framework to drive your probes.
The paper includes a flowchart describing the current anatomy
of AutoHack. Questions focused around trying to weasle some part
of the software (``Can I get the banter library?''), and
questions about how badly this beats up the network (``It does
some nice things,'' said Muffett).
Altogether, there were 21 papers presented (out of 43
submitted). This article is an excerpt from a much longer article
to appear in the August version of ;login: magazine,
a publication for Usenix members. You can get more information
about Usenix by sending e-mail to office@usenix.org, or
calling 510-528-8649. The complete proceedings can be purchased
for $35 (non-members), or accessed on-line
(http://www.usenix.org/publications/library/) by members.
|