From: Bruce Schneier [mailto:[log in to unmask]]
Sent: Friday, March 16, 2001 5:10 AM
To: [log in to unmask]
Subject: CRYPTO-GRAM, March 15, 2001
CRYPTO-GRAM
March 15, 2001
by Bruce Schneier
Founder and CTO
Counterpane Internet Security, Inc.
[log in to unmask]
<http://www.counterpane.com>
A free monthly newsletter providing summaries, analyses, insights, and
commentaries on computer security and cryptography.
Back issues are available at
<http://www.counterpane.com/crypto-gram.html>. To subscribe or
unsubscribe, see below.
Copyright (c) 2001 by Counterpane Internet Security, Inc.
** *** ***** ******* *********** *************
In this issue:
The Security Patch Treadmill
Crypto-Gram Reprints
Insurance and the Future of Network Security
News
Counterpane Internet Security News
Harvard's "Uncrackable" Crypto
TCP/IP Initial Sequence Number Flaw
The Doghouse: iBallot.com
The "Death" of IDS?
802.11 Security
Comments from Readers
** *** ***** ******* *********** *************
The Security Patch Treadmill
"Well, in our country," said Alice, panting a little,
"you'd generally get somewhere else -- if you ran very
fast for a long time, as we've been doing."
"A slow sort of country!" said the Queen. "Now here,
you see, it takes all the running you can do, to keep
in the same place."
--Through the Looking Glass, by Lewis Carroll.
Last week, the FBI announced that over the past year, several groups of
Eastern European hackers had broken into at least 40 companies' websites,
stolen credit card numbers, and in some cases tried to extort money from
theeir victims. The network vulnerabilities exploited by these criminals
were known, and patches that closed them were available -- but none of the
companies had installed them. In January 2001, the Ramen worm targeted
known vulnerabilities in several versions of Red Hat Linux. None of the
thousands of infected systems had their patches up to date. In October
2000, Microsoft was molested by unknown hackers who wandered unchallenged
through their network, accessing intellectual property, for weeks or
months. According to reports, the attackers would not have been able to
break in if Microsoft patches had been up to date. The series of
high-profile credit card thefts in January 2000, including the CD Universe
incident, were also the result of uninstalled patches. A patch issued
eighteen months previously would have protected these companies.
What's going on here? Isn't anyone installing security patches
anymore? Doesn't anyone care?
What's going on is that there are just too damn many patches. It's simply
impossible to keep up. I get weekly summaries of new vulnerabilities and
patches. One alert service listed 19 new patches in a variety of products
in the first week of March 2001. That was an average week. Some of the
listings affected my network, and many of them did not. Microsoft Outlook
had over a dozen security patches in the year 2000. I don't know how the
average user can possibly install them all; he'd never get anything else
done.
Security professionals are quick to blame system administrators who don't
install every patch. "They should have updated their systems; it's their
own fault when they get hacked." This is beginning to feel a lot like
blaming the victim. "He should have known not to walk down that deserted
street; it's his own fault he was mugged." "She should never have dressed
that provocatively; it's her own fault she was attacked." Perhaps such
precautions should have been taken, but the real blame lies elsewhere.
Those who manage computer networks are people too, and people don't always
do the smartest thing. They know they're supposed to install all
patches. But sometimes they can't take critical systems
off-line. Sometimes they don't have the staffing available to patch every
system on their network. Sometimes applying a patch breaks something else
on their network. I think it's time the industry realized that expecting
the patch process to improve network security just doesn't work.
Security based on patches is inherently fragile. Any large network is
going to have hundreds of vulnerabilities. If there's a vulnerability in
your system, you can be attacked successfully and there's nothing you can
do about it. Even if you manage to install every patch you know about,
what about the vulnerabilities that haven't been patched yet? (That same
alert service listed 10 new vulnerabilities for which there is no
defense.) Or the vulnerabilities discovered but not reported yet? Or the
ones still undiscovered?
Good security is resilient. It's resilient to user errors. It's resilient
to network changes. And it's resilient to administrators not installing
every patch. For the past two years I have been championing monitoring as
a way to provide this resilient security. If there are enough motion
sensors, electric eyes, and pressure plates in your house, you'll catch the
burglar regardless of how he got in. If you are monitoring your network
carefully enough, you'll catch a hacker regardless of what vulnerability he
exploited to gain access. Monitoring makes a network less dependent on
keeping patches up to date; it's a process that provides security even in
the face of ever-present vulnerabilities, uninstalled patches, and
imperfect products.
In a perfect world, systems would rarely need security patches. The few
patches they did need would automatically download, be easy to install, and
always work. But we don't live in a perfect world. Network administrators
are busy people, and networks are constantly changing. Vigilant monitoring
does not "solve" computer security, but it is a much more realistic way of
providing resilient security.
The Ramen worm:
<http://www.zdnet.com/zdnn/stories/news/0,4586,2675147,00.html>
<http://www.newsfactor.com/perl/story/6798.html>
<http://www.securityfocus.com/archive/75/156624>
Security patches aren't being applied:
<http://www.zdnet.com/zdnn/stories/news/0,4586,2677878,00.html>
Best quote: "Failing to responsibly patch computers led to 99 percent of
the 5,823 Web site defacements last year, up 56 percent from the 3,746 Web
sites defaced in 1999, according to security group Attrition.org." I'm not
sure how they know, but is scary nonetheless.
The Eastern European credit card hackers:
<http://www.sans.org/newlook/alerts/NTE-bank.htm>
<http://www.nipc.gov/warnings/advisories/2001/01-003.htm>
<http://www.fbi.gov/pressrm/pressrel/pressrel01/nipc030801.htm>
<http://www.zdnet.co.uk/news/2001/9/ns-21473.html>
Many networks have not patched BIND after January's vulnerabilities were
patched:
<http://www.computerworld.com/cwi/stories/0,1199,NAV47_STO58302,00.html>
The Microsoft attack:
<http://www.counterpane.com/crypto-gram-0011.html#7>
Patch your apps:
<http://www.zdnet.com/zdhelp/stories/main/0,5594,2317459,00.html>
Author's note: Every time I write an essay that speaks favorably about
Counterpane, I get e-mails from people accusing me of advertising. I
disagree, and I'd like to explain. Much of my current thinking about
computer security stemmed from years of consulting. I watched as product
after product failed in the field, and I tried to figure out why. My
conclusions are largely chronicled in my book _Secrets and Lies_, and are
reflected in the business model of Counterpane Internet Security, Inc. I
don't extol the virtues of monitoring because that's what Counterpane does;
Counterpane provides Managed Security Monitoring because I believe it is
the future of security. I see monitoring as a way to achieve security in a
world where the products are hopelessly broken. Over the next several
months I will publish more essays on security, and monitoring is prominent
in many of them. I'm not shilling Counterpane; it's just where my thinking
is.
** *** ***** ******* *********** *************
Crypto-Gram Reprints
Software complexity and security:
<http://www.counterpane.com/crypto-gram-0003.html#SoftwareComplexityandSecur
ity>
Why the worst cryptography is in systems that pass initial cryptanalysis:
<http://www.counterpane.com/crypto-gram-9903.html#initial>
** *** ***** ******* *********** *************
Insurance and the Future of Network Security
Eventually, the insurance industry will subsume the computer security
industry. Not that insurance companies will start marketing security
products, but rather that the kind of firewall you use -- along with the
kind of authentication scheme you use, the kind of operating system you
use, and the kind of network monitoring scheme you use -- will be strongly
influenced by the constraints of insurance.
Consider security, and safety, in the real world. Businesses don't install
building alarms because it makes them feel safer; they do it because they
get a reduction in their insurance rates. Building-owners don't install
sprinkler systems out of affection for their tenants, but because building
codes and insurance policies demand it. Deciding what kind of theft and
fire prevention equipment to install are risk management decisions, and the
risk taker of last resort is the insurance industry.
This is sometimes hard for computer techies to understand, because the
security industry has trained them to expect technology to solve their
problems. Remember when all you needed was a firewall, and then you were
safe? Remember when it was an intrusion detection product? Or a PKI? I
think the current wisdom is that all you need is biometrics, or maybe smart
cards.
The real world doesn't work this way. Businesses achieve security through
insurance. They take the risks they are not willing to accept themselves,
bundle them up, and pay someone else to make them go away. If a warehouse
is insured properly, the owner really doesn't care if it burns down or
not. If he does care, he's underinsured. Similarly, if a network is
insured properly, the owner won't care whether it is hacked or not.
This is worth repeating: a properly insured network is immune to the
effects of hacking. Concerned about denial-of-service attacks? Get
bandwidth interruption insurance. Concerned about data corruption? Get
data integrity insurance. (I'm making these policy names up,
here.) Concerned about negative publicity due to a widely publicized
network attack? Get a rider on your good name insurance that covers that
sort of event. The insurance industry isn't offering all of these policies
yet, but it is coming.
When I talk about this future at conferences, a common objection I hear is
that premium calculation is impossible. Again, this is a technical
mentality talking. Sure, insurance companies like well-understood risk
profiles and carefully calculated premiums. But they also insure satellite
launches and the palate of wine critic Robert Parker. If an insurance
company can protect Tylenol against some lunatic putting a poisoned bottle
on a supermarket shelf, anti-hacking insurance will be a snap.
Imagine the future.... Every business has network security insurance, just
as every business has insurance against fire, theft, and any other
reasonable threat. To do otherwise would be to behave recklessly and be
open to lawsuits. Details of network security become check boxes when it
comes time to calculate the premium. Do you have a firewall? Which
brand? Your rate may be one price if you have this brand, and a different
price if you have another brand. Do you have a service monitoring your
network? If you do, your rate goes down this much.
This process changes everything. What will happen when the CFO looks at
his premium and realizes that it will go down 50% if he gets rid of all his
insecure Windows operating systems and replaces them with a secure version
of Linux? The choice of which operating system to use will no longer be
100% technical. Microsoft, and other companies with shoddy security, will
start losing sales because companies don't want to pay the insurance
premiums. In this vision of the future, how secure a product is becomes a
real, measurable, feature that companies are willing to pay for...because
it saves them money in the long run.
Other systems will be affected, too. Online merchants and brick-and-mortar
merchants will have different insurance premiums, because the risks are
different. Businesses can add authentication mechanisms -- public-key
certificates, biometrics, smart cards -- and either save or lose money
depending on their effectiveness. Computer security "snake-oil" peddlers
who make outlandish claims and sell ridiculous products will find no buyers
as long as the insurance industry doesn't recognize their value. In fact,
the whole point of buying a security product or hiring a security service
will not be based on threat avoidance; it will be based on risk management.
And it will be about time. Sooner or later, the insurance industry will
sell everyone anti-hacking policies. It will be unthinkable not to have
one. And then we'll start seeing good security rewarded in the marketplace.
A version of this essay originally appeared in Information Security
Magazine:
<http://www.infosecuritymag.com/articles/february01/columns_sos.shtml>
An article on hacking insurance:
<http://cgi.zdnet.com/slink?85060:8469234>
** *** ***** ******* *********** *************
News
The Anna Kournikova worm was written using a virus-writing kit. If this
doesn't get Microsoft's attention, I don't know what will. And to the rest
of you, just say no to Outlook.
<http://www.wired.com/news/technology/0,1282,41817,00.html>
Computer hackers could be prosecuted as terrorists under a new UK law: the
Terrorism Act 2000. The Act significantly widens the definition of
terrorism to include those actions that "seriously interfere with or
seriously disrupt an electronic system."
<http://www.zdnet.co.uk/news/2001/7/ns-21060.html>
The Terrorism Act:
<http://www.legislation.hmso.gov.uk/acts/acts2000/20000011.htm>
Australians (at least those surveyed by ZDNet) agree with this:
<http://cgi.zdnet.com/slink?84319:8469234>
What's wrong with copy protection, by John Gilmore:
<http://www.toad.com/gnu/whatswrong.html>
This article is about the Seti@home project: people fake results to improve
their standings in the program. The security moral is that the "attack
isn't worth the effort" justification often doesn't apply; people spend a
lot of effort attacking things that have no monetary value.
<http://www.wired.com/news/technology/0,1282,41838,00.html>
I've repeatedly said that the Internet is too complex to secure. This
article is about "Enterprise Application Portals," one of the next big
things. When you read this article, marvel at all the protocols and
buzzwords and applications that are working in concert. "Infrastructure
and access meet at the network edge, where organizations are increasingly
driven to deliver pervasive, personalized content and commerce. Outside
the network edge are billions of Internet devices. Inside the Network edge
is the enterprise's competitive machinery. Whatever organizations erect at
the network edge must be highly scalable, reliable, available, and secure
all the time." Yeah, right.
<http://www.eaijournal.com/EBusiness/EnterpriseApplicationPx.asp>
IBM has withdrawn CPRM...
<http://news.cnet.com/news/0-1006-201-4922288-0.html?tag=mn_hd>
...and replaced it with something almost identical:
<http://slashdot.org/yro/01/02/23/2134255.shtml>
A good analysis by John Gilmore:
<http://cryptome.org/cprm-smoke.htm>
Claude Shannon dies:
<http://www.cnn.com/2001/TECH/science/02/27/obit.shannon.ap/index.html>
Particularly amusing response to a Motion Picture Association threat letter
to a researcher who has various instantiations of DeCSS on his Web page:
<http://www.cs.cmu.edu/~dst/DeCSS/Gallery/mpaa-reply-feb2001.html>
The U.S. General Accounting Office (GAO) has released this large report on
making PKI work:
<http://www.gao.gov/new.items/d01277.pdf>
According to CNN, accused spy Robert Hanssen suspected that he was under
surveillance and send an encrypted message to his handlers: "The comment
came from a letter that FBI officials said was encrypted on a computer
diskette found in a package -- taped and wrapped in a black plastic trash
bag -- that Hanssen dropped underneath a foot bridge in a park in Northern
Virginia, immediately before his arrest. The FBI decrypted the letter and
described it in an affidavit filed in support of its search
warrant." Interesting. Hanssen wasn't stupid, and he probably was using a
good commercial encryption product. What exactly did the FBI do to decrypt
the letter?
<http://www.cnn.com/2001/US/02/27/fbi.spy/index.html>
The FBI's affidavit, fascinating reading as it is, does not seem to confirm
this news story:
<http://www.fas.org/irp/ops/ci/hanssen_affidavit.html>
"The Emperor's New Clothes: The Shocking Truth about Digital Signatures and
Internet Commerce." Worth reading.
<http://www.smu.edu/~jwinn/shocking-truth.htm>
A program called ShareSniffer automatically searches the Internet for
Windows machines with world-accessible hard drives or
directories. Certainly some people may want the world to access their hard
drives, but most systems found are probably misconfigured.
<http://www.securityfocus.com/news/159>
More about last fall's network break-in at Microsoft. Honestly, I can't
tell how much of this is accurate.
<http://seattletimes.nwsource.com/cgi-bin/WebObjects/SeattleTimes.woa/wa/got
oArticle?zsection_id=268448455&text_only=0&slug=hack23&document_id=134269414
>
NIST released an intrusion-detection primer for federal agencies. It is
useful reading for anyone interested.
<http://csrc.nist.gov/publications/drafts/idsdraft.pdf>
And NIST has also released the draft FIPS for AES. If you have any last
comments, this is the time to make them.
<http://csrc.nist.gov/encryption/aes/>
A deliberate backdoor in the Palm OS. It was put there to allow debugging
and testing, but the programmers neglected to remove
it. Oops.
<http://www.zdnet.com/eweek/stories/general/0,11011,2692289,00.html>
A steganographic file system for Linux:
<http://www.mcdonald.org.uk/StegFS/>
Lessons in bad user interface. Why not to include an override button on
your device.
<http://orlandosentinel.com/news/orl-nws-votebad04020401.story>
The practicalities, and ethics, of honeypots:
<http://www.wired.com/news/culture/0,1284,42233,00.html>
The future of digital music licensing schemes?
<http://www.ibiblio.org/Dave/Dr-Fun/df200103/df20010306.jpg>
The news is not that Amazon was hacked so badly, or that it went on for
four months. The news is that Amazon denied it for so long, and threatened
legal action against those that first talked about the hack.
<http://www.theregister.co.uk/content/8/17384.html>
<http://www.theregister.co.uk/content/8/17387.html>
It's too late; Microsoft fixed it. But just a few days ago there was one
more Q/A between the second and third question. It read: "Will the virus
impact my Macintosh if I am using a non-Microsoft e-mail program, such as
Eudora? If you are using a Macintosh e-mail program that is not from
Microsoft, we recommend checking with that particular company. But most
likely other e-mail programs like
Eudora are not designed to enable virus replication."
<http://www.microsoft.com/mac/products/office/2001/virus_alert.asp>
Most companies do not want to go public with security breaches:
<http://www2.cio.com/archive/030101/silence_content.html>
Twelve steps to security. A good article (that quotes me extensively):
<http://www.cio.com/archive/030101/keys.html>
** *** ***** ******* *********** *************
Counterpane Internet Security News
Counterpane is hiring again. Look at all the current job listings at
<http://www.counterpane.com/jobs.html>
Bruce Schneier is speaking at the RSA Security Conference, Monday 4/9, at
9:00 AM, in San Francisco.
<http://www.rsasecurity.com/conference/>
Schneier is speaking at two ISSA meetings, in Minneapolis on 3/20 at 1:30,
and in Boston on 3/22 at 2:30.
Minneapolis: <http://www.mn-issa.org/>
Boston: <http://www.issa-ne.org/>
Counterpane signs Keynote and Conxion:
<http://www.counterpane.com/pr-infra.html>
Counterpane and PricewaterhouseCoopers offer joint service:
<http://www.counterpane.com/pr-pwc.html>
Counterpane signs NetCertainty and OpenReach:
<http://www.counterpane.com/pr-ncor.html>
Schneier lectured in Digital Rights Management at the University of
Minnesota.
Slides:
<http://www.ima.umn.edu/talks/workshops/2-12-16.2001/schneier/DigitalRights.
pdf>
Audio:
<http://www.ima.umn.edu/recordings/Public_Lecture/2000-2001/feb_12_01/schnei
er.ram>
MP3:
<http://www.ima.umn.edu/recordings/Public_Lecture/2000-2001/feb_12_01/schnei
er-128.mp3>
Schneier has been interviewed (in Italian) here:
<http://www.cdt.ch/giornale/inserto/Internet_e_sicurezza/12022001133144.asp>
** *** ***** ******* *********** *************
Harvard's "Uncrackable" Crypto
Last month the New York Times reported a cryptography
breakthrough. Michael O. Rabin and Yan Zong Ding, both of Harvard,
proposed an information-theoretical secure cipher. (Yonatan Aumann was
also involved in the research.) The idea is that a satellite broadcasts a
continuous stream of random bits. The sender and receiver agree on several
random starting point in that stream, and use the streams as continuous
keys to XOR with the message. Since the eavesdropper doesn't know the
starting point, he can't decrypt the message. And since the stream is too
large to store in its entirety, the eavesdropper can't try different
starting points.
That's basically it. The crypto isn't worth writing about (although
there's some interesting mathematics), but the context is.
One, the popular press does not count as peer review. I have often watched
in amazement as the press grabs hold of some random piece of cryptography
and reports on it like it changes the world, only to ignore important
pieces of research. When you read about something like this in the popular
press, pay attention to the motivations of the researchers and the public
relations people who convinced the reporters to write about it. Academic
peer-review will happen in the upcoming years.
One of my biggest gripes with these sorts of press announcements is that
they ignore the research and the researchers that come before. The model
and approach are not new; Ueli Maurer proposed it ten years ago. (If you
want to look it up, the citation is: U. Maurer, "Conditionally-Perfect
Secrecy and a Provably-Secure Randomized Cipher," Journal of Cryptology,
vol. 5, no. 1, pp. 53-66, 1992. I discuss some of this work in _Applied
Cryptography_, p. 419.) Rabin and Ding are not to blame -- their academic
paper credits Maurer heavily, as well as other work that went before -- but
none of that came out in the press.
Two, while the paper's mathematical result is a new contribution to
cryptography, it's nowhere near strong enough to unleash the full potential
of the model. I think there are better techniques in Maurer's paper for
finding public randomness, such as using the face of the moon as a public
source of randomness (his paper also includes in its model a satellite
broadcasting random bits). And it's totally impractical. Maurer's paper
provides better methods for establishing a secret channel in the presence
of an eavesdropper. But because Harvard has a better public relations
machine, this result magically becomes news.
Three, this scheme will never be used. Launching satellites gets cheaper
all the time, but why would someone have them broadcast random numbers when
they could be doing something useful instead? Remember, strong encryption
is not our problem; we have secure algorithms. In fact, it's the one
security problem we have solved; solving it better just doesn't matter. I
often liken this to putting a huge stake in the ground and hoping the enemy
runs right into it. You can argue about whether the stake should be a mile
tall or two miles tall, but a smart attack is just going to dodge the
stake. I don't mean to trash the work; it is a contribution of theoretical
interest. It's just that it should not be mistaken for a practical scheme.
Oh, and by the way, an attacker can store the continuous random stream of
bits from the satellite. Just put another satellite in space somewhere,
and store the bits in a continuous transmission loop. The neat property of
this attack is that the capacity of this storage mechanism scales at
exactly the same rate as the data stream's rate does. There's no way to
defeat it by increasing data rate. Isn't satellite data storage science
fiction? Sure. But no more than the initial idea.
<http://www.nytimes.com/2001/02/20/science/20CODE.html>
<http://cryptome.org/key-poof.htm>
<http://slashdot.org/articles/01/02/20/136219.shtml>
Maurer's Research:
<http://www.inf.ethz.ch/department/TI/um/research/itc/>
A demo of one of Maurer's schemes, more practical than the Rabin scheme:
<http://www.inf.ethz.ch/department/TI/um/research/keydemo>
** *** ***** ******* *********** *************
TCP/IP Initial Sequence Number Flaw
Last week the security consulting company Guardent announced a new
vulnerability in TCP/IP. This vulnerability is supposed to allow hackers
to hijack TCP/IP connections and do all sorts of nasty things. They have
not published technical details, leading some people to accuse them of
making it up. There have also been accusations of plagiarism of a
15-year-old vulnerability. The reality is a bit more complicated.
The flaw centers around the ability of an attacker to predict TCP/IP
sequence numbers (called Initial Sequence Numbers, or ISNs), and to use
this as a lever to break into systems. Robert Tappan Morris (the son, not
the father; the one who wrote the 1988 Internet worm) first wrote about
this type of vulnerability in 1985. It became an occasional hacker tool
after that; Kevin Mitnick used a sequence number predictor to break into
Tsutumo Shimomura's computer at the San Diego Supercomputer Center around
1995. Steve Bellovin wrote a paper extending this attack in 1989, and it
started receiving some serious attention in the security
community. Bellovin also wrote RFC 1948, which recommends using a virtual
time base to randomize the ISNs and thwart this attack.
A number of vendors have opted not to use RFC 1948, because of the
(perceived) expense. Instead, they often used home grown methods to
randomize ISNs. Guardent's recent work is an extension of the work of
Morris and Bellovin. The researchers found new ways of getting information
about the sequence numbers, and showed that hosts that don't use RFC 1948
are still vulnerable.
There's no plagiarism. The (still unreleased) Guardent paper credits all
earlier work, even if the press release ignores it. There are new attacks,
and real academic scholarship. What we do have is an over-enthusiastic
public relations department touting yet another incremental improvement on
a well-known class of attack. Interesting, but not worth all the press ink
it got.
Guardent's announcement:
<http://www.guardent.com/pr2001-03-12-ips.html>
CERT advisory:
<http://www.kb.cert.org/vuls/id/498440>
Morris's original paper:
<ftp://ftp.research.att.com/dist/internet_security/117.ps.Z>
Bellovin's paper:
<http://www.research.att.com/~smb/papers/ipext.ps>
RFC 1948:
<http://www.ietf.org/rfc/rfc1948.txt>
** *** ***** ******* *********** *************
The Doghouse: iBallot.com
I'll just reprint this from their Web site: "iBallot.Com uses a number of
security and encryption features that, when combined, provide a very high
level of security throughout the entire voting process. The details of
this process are proprietary, for obvious reasons. It does not make a
great deal of sense to disclose how the iBallot.Com security system works
only to have a hacker come into the system, read about the system's
security, defeat the security and tamper with the voting process. For this
reason, iBallot.Com does not publish its security processes. However, with
the foregoing being said, the iBallot.Com system does employ encryption and
secure server technology to ensure that the entire voting process is fair,
accurate and not subject to tampering."
Encryption and secure server technology.... Boy, I certainly feel
better. Good thing they don't disclose their security; if they did some
hacker might read about it and break it. Who *are* these guys?
<http://www.iballot.com/faq2.cfm?docid=28>
** *** ***** ******* *********** *************
The "Death" of IDS?
Recently I've been seeing several articles foretelling the death of
Intrusion Detection Systems (IDS). Supposedly, changes in the way networks
work will make them an obsolete relic of simpler times. While I agree that
the challenges IDSs face are serious, and that they will always have
limitations, I am more optimistic about their future.
IDSs are the network equivalent of virus scanners. IDSs look at network
traffic, or processes running on hosts, for signs of attack. If they see
one, they sound an alarm. In _Secrets and Lies_, I spent several pages on
IDSs (pp. 194-197): how they work, how they fail, the problems of false
alarms. For here, suffice it to say that the two problems that IDSs have
are 1) failing to detect real attacks, and 2) failing to ignore false
alarms.
These two problems are nothing new, but several recent developments
threaten to undermine IDSs completely.
First is the rise of IPsec. IPsec is a security protocol that encrypts IP
traffic. An IDS can't detect what it can't understand, and is useless
against encrypted network traffic. (Similarly, an anti-virus program can't
find viruses in encrypted e-mail attachments.) As encryption becomes more
widespread on a network, an IDS becomes less useful.
Second is the emergence of Unicode. In the July 2000 Crypto-Gram, I talked
about security problems associated with Unicode. One problem is the
ability to disguise character strings in various ways. Since most IDS
systems look for character strings in packets indicating certain network
attacks, Unicode threatens to make this job insurmountable.
Third is the increased distribution of networks. Today's traffic is no
longer coming through one firewall, but rather via the firewall and
hundreds of different direct external links to customers, suppliers, joint
venture partners, outsourcing companies, IPsec gateways for telecommuters
and road warriors, etc. This makes it very hard to monitor the traffic.
And fourth is the sheer speed of networks. For an IDS to be effective, it
has to examine every packet. This slows down an Ethernet software switch
or router, but completely stalls a gigabit hardware device. Data
transmission rates are getting so fast that no IDS can possibly keep up.
Some security experts are predicting the death of IDSs, but I don't
agree. Even with all of this, an IDS is still the most effective tool for
detecting certain network attacks. But it is not a panacea. I think of
IDSs as network sensors, similar to a burglar alarm on a house. It won't
detect every attack against the house, it can be bypassed by a sufficiently
skilled burglar, but it is an effective security countermeasure.
And just as door and window alarms are more effective when combined with
motion sensors and electric eyes, IDSs are more effective when combined
with other network sensors. Tripwire, for example, is a network sensor
that alarms if critical files are modified. Honeypots include network
sensors that alarm if attacked.
The missing piece is a way to interpret and respond to these alarms. The
whole point of building Counterpane Internet Security was to deal with the
problem of these sensors going off. Someone has to watch these sensors
24/7. Someone has to correlate information from a variety of sensors, and
figure out what's a false alarm and what's real. Someone has to know how
to respond, and to coach the network administrator through the process. My
hope is that someone is Counterpane. I think Counterpane is the company
that finally makes IDSs look good.
"Imminent death of..." predictions come in a couple of forms. Most of them
are sales pitches, forecasting that somebody's product is going to kill off
the victim, one way or another. (Often, most sane people will define the
proposed killer as actually in the doomed class; most things that are
"going to replace firewalls" are thinly disguised firewalls, for
instance.) Those that aren't sales pitches are mostly just nabobs of
negativity, short-sighted people who like prophesying doom. (My favorite
one of these is the first line of John Varley's _Steel Beach_: "In five
years, the penis will be obsolete.")
Whole classes of products are hard to kill. They evolve in response for a
very long time. IDSs are already evolving. They're getting smarter,
faster, and more distributed. The people forecasting the death of IDSs are
looking at the pressures against them, but they aren't proposing the kind
of radical shift that would replace an IDS with something better. And
until that happens, IDSs are here to stay.
Good article on the realities of IDS:
<http://www.securitymanagement.com/library/000556.html>
Interesting (and good) review of IDS:
<http://securityportal.com/articles/idsintroduction20010226.html>
Problems with IDS:
<http://www.infoworld.com/articles/op/xml/00/12/11/001211opswatch.xml>
IDS and false positives:
<http://www.zdnet.com/eweek/stories/general/0,11011,2606343,00.html>
Unicode and IDS:
<http://www.securityfocus.com/focus/ids/articles/utf8.html>
Scholarly stuff:
<http://secinf.net/info/ids/idspaper/idspaper.html>
<http://www.all.net/journal/ntb/ids.html>
** *** ***** ******* *********** *************
802.11 Security
In February, researchers at (or formerly at) Berkeley published several
security vulnerabilities in the Wireless Equivalent Privacy (WEP) protocol,
part of the 802.11 wireless LAN standard. This is the standard used by
most wireless LANs, including Apple's AirPort. The job of the WEP is to
prevent unauthorized eavesdropping on the wireless network.
The result of the vulnerabilities is that eavesdropping is easy. The
details are not really worth describing; read the academic paper if you
want to know. They are all a result of sloppy cryptographic engineering,
and are easily fixable.
This "yet another vulnerability" story would normally not be worth writing
about, but the real morals are not obvious and were largely ignored by the
press. News stories were along the lines of: "There are problems with
802.11; they need to be fixed. We'll all be more secure once they're
fixed." I see a more general story: "There are problems in lots of
protocols, we find and fix them randomly, and this doesn't bode well for
the future of security." The 802.11 problems are just an example of this
trend.
Security flaws like this are unnervingly common. To quote from the paper:
"Design of secure protocols is difficult, and fraught with many
complications. It requires special expertise beyond that acquired in
engineering network protocols." This time 802.11 was broken, but you
should assume these sorts of problems occur in most other security
protocols. Simply because some marketing literature says things like "uses
128-bit RC4" doesn't mean that the product is secure. Odds are, it isn't.
As bad as the discovered flaws are, there are usually worse security
problems. WEP is nothing more than a password-access network. You type in
the password, and the base station lets you on. It's both authentication,
and the encryption key. Most implementations use 40-bit RC4 encryption
(completely insecure in today's environment), although some implementations
have an option for 104-bit RC4. All users share a single key, which is
stored in every computer on the 802.11 network. Hence the security does
not scale for large networks at all. And even worse, the key is chosen and
typed in by the network administrator, which means that the effective key
length is probably even smaller than 40 bits, regardless of how many bits
are in the encryption key.
Protocols designed in secret, or by closed committees, are the worst. The
802.11 process was technically open, but in practice it was closed. Anyone
could go to the committee meanings, if they wanted to pony up the airfare
and registration fee and spend their time trying to decipher the 802.11
jargon. However, you couldn't just grab the standard or read about the
cryptography on the net. There was no free, generally available, public
information.
Publishing the protocol allows for these flaws to be discovered, but
doesn't guarantee that they will be. The 802.11 protocol is an IEEE
standard, and has been public since at least 1999, although any researcher
wanting to read it has to pay the IEEE several hundreds of dollars for a
copy. The reason these flaws were not discovered earlier is not because
they're subtle -- they're not -- but because no one with sufficient
cryptographic skill had read them earlier.
Flaws in these protocols are discovered more or less at random. The only
reason a cryptanalysis of WEP was published is that one of the researchers
became annoyed at the University of California Berkeley. The University
was starting to deploy 802.11, but with some annoying usage
limitations. Coincidentally, an officemate had just bought a copy of the
standard for other purposes (nothing to do with security), so they took a
took at it. The timing just happened to work out right, and they had a few
hours to puzzle out the cryptography.
Discovering and fixing the flaws is not enough. There's no reason to
believe the WEP flaws will be fixed, or that the protocol will be secure
after they are fixed. The 802.11 committee has been downplaying the
vulnerabilities, but it's putting a working group together to investigate
them. The 802.11 standard governs hardware devices; upgrades are difficult
and must be backwards compatible. Undoubtedly other problems remain, and
any modification to the WEP will undoubtedly introduce new flaws. Unless
they find a competent cryptographer to do the work, and submit the results
to a rigorous peer review, the cycle will continue.
This trend is getting worse, not better. There are more and more protocols
being designed to offer more and more security features. Most of these
design processes are no more rigorous than the 802.11 process. Most of
these processes do not include cryptographic peer-review; some of them are
done completely in secret. (Some of the 802.11 people have said things
like "we're already open," "we don't need to fix our process," "we *did*
get peer review when we designed the standard, we asked the NSA whether it
was any good.") Many of these protocols are much more complex than
whatever they are replacing, making security flaws even more likely. If
these flaws are common now, they are going to be more common in the future.
The attacks:
<http://www.isaac.cs.berkeley.edu/isaac/wep-faq.html>
Response from the Chair of IEEE 802.11:
<http://slashdot.org/articles/01/02/15/1745204.shtml>
An example of 802.11 security marketing:
"Increased Security Through Wired Equivalent Privacy
Wired Equivalent Privacy (WEP), an optional RC4 encryption algorithm, helps
ensure the security of your data. Before data are transmitted, they are
streamed through an RC4 algorithm, an efficient encryption process designed
for LAN communications. Additionally, all RangeLAN802 devices are
authenticated through a challenge-and-response mechanism before being
allowed network access. Both wireless and wired LANs are thus fortified
against eavesdropping and unauthorized access by hackers or other nearby
802.11-compliant devices."
<http://www.airlinx.com/rangelan2pccard.htm>
** *** ***** ******* *********** *************
Comments from Readers
From: Rebecca Mercuri <[log in to unmask]>
Subject: Voting in Brazil
In your January Crypto-Gram you published a letter from Daniel Balparda de
Carvalho, a Brazilian who commented favorably on their electronic voting
system. The U.S. press touted the Brazilian equipment as something we
should be emulating. However, I have heard from numerous Brazilian
journalists and scientists who have noted difficulties with their
system. On my voting Web site <http://www.notablesoftware.com/evote.html>
I have linked an excellent discussion of this subject by Michael
Stanton. The translation "The Importance of Counting Votes" is available
there, as well as the URL to the Portuguese version as originally
published. I have also linked the Web site to the Brazilian Electronic
Voting Forum maintained by Amilcar Brunazo Filho
<http://www.votoseguro.org>, which is a key resource on the subject and
tells "the rest of the story" -- although it is helpful if you can read
Portuguese. I am concerned that the side of the Brazilian election that we
are being shown here
in the US is not fully reflective of the true nature of the matter, and
intend to continue to publicize other official reports as I receive them.
From: "Phillip Hallam-Baker" <[log in to unmask]>
Subject: Codesigning
The attacks against Authenticode you print in Crypto-Gram were considered
in the design. The purpose of Authenticode is to give at least the same
level of security as buying shrink wrap software from a store. Shrink wrap
software can be compromised, and indeed there are a small number of cases
of people selling CDs infected with viruses. Authenticode has already been
a great success; distributing code through the net could have been a
disaster on the scale of e-mail viruses.
A hacker could probably obtain a certificate if they were persistent
enough. But that certificate would be tied to the name of the shell
company they started for the purpose. They would not be able to get a
certificate with the name "Microsoft" or "Blizzard" or any company that was
well known.
If the hackers circulated the private key to any great extent, the
compromise would soon be known. The certificate would be revoked and would
not be accepted by the Authenticode signing service for future code signing
requests. Software that had already been signed would still pose a risk,
but this could be controlled through warnings in the press.
In the future it is likely that a higher level of security will be possible
in enterprise configurations. Ideally each software installation would be
referred to a central service for prior approval. This is not an
acceptable option for consumer use, of course -- at least not without a
ready means of bypassing it so that the consumer can write their own code.
There is still a risk from program bugs, of course. But the buffer overrun
problem cited should be considered a security weakness of C and C++. There
have been languages with robust bounds checking on arrays since the
1960s. Unfortunately, bounds checking has only recently arrived in the C
world in the Java and C# variants. But it is here now and programmers
won't have much excuse not to use it.
** *** ***** ******* *********** *************
CRYPTO-GRAM is a free monthly newsletter providing summaries, analyses,
insights, and commentaries on computer security and cryptography.
To subscribe, visit <http://www.counterpane.com/crypto-gram.html> or send a
blank message to [log in to unmask] To unsubscribe,
visit <http://www.counterpane.com/unsubform.html>. Back issues are
available on <http://www.counterpane.com>.
Please feel free to forward CRYPTO-GRAM to colleagues and friends who will
find it valuable. Permission is granted to reprint CRYPTO-GRAM, as long as
it is reprinted in its entirety.
CRYPTO-GRAM is written by Bruce Schneier. Schneier is founder and CTO of
Counterpane Internet Security Inc., the author of _Secrets and Lies_ and
_Applied Cryptography_, and an inventor of the Blowfish, Twofish, and
Yarrow algorithms. He served on the board of the International Association
for Cryptologic Research, EPIC, and VTW. He is a frequent writer and
lecturer on computer security and cryptography.
Counterpane Internet Security, Inc. is a venture-funded company bringing
innovative managed security solutions to the enterprise.
<http://www.counterpane.com/>
Copyright (c) 2001 by Counterpane Internet Security, Inc.
************************************************************************************
Distributed through Cyber-Society-Live [CSL]: CSL is a moderated discussion
list made up of people who are interested in the interdisciplinary academic
study of Cyber Society in all its manifestations.To join the list please visit:
http://www.jiscmail.ac.uk/lists/cyber-society-live.html
*************************************************************************************
|
