July 15, 2000
by Bruce Schneier
Founder and CTO
Counterpane Internet Security, Inc.
A free monthly newsletter providing summaries, analyses, insights, and commentaries on computer security and cryptography.
Back issues are available at http://www.schneier.com. To subscribe or unsubscribe, see below.
Copyright (c) 2000 by Counterpane Internet Security, Inc.
In this issue:
- Full Disclosure and the CIA
- Counterpane Internet Security News
- More Counterpane Internet Security News
- Even the President Can't Choose a Good Password
- The Doghouse: Intuit QuickBooks
- Full Disclosure and Lockmaking
- Crypto-Gram Reprints
- Security Risks of Unicode
- Comments from Readers
On its Web site, the New York Times published a previously classified 1954 CIA document about the overthrow of the Iranian government. I'm not sure how the New York Times got its hands on the document, but the newspaper decided to redact the names of Iranian citizens involved in the plot.
The document was a scanned PDF file. What the Times did was to create an overlay on the pages, and drew black boxes over the names they wanted to obscure. The result was a file that still had the original digital information, but contained extra commands to obscure that information. Predictably, someone reverse-engineered the original names (it was suprisingly easy) and posted the restored document. The Times panicked and removed the original document, but it's too late; copies are available on various sites worldwide.
Reactions to this have been bizarre, and almost uniformly missing the point. Here's one, by William Hugh Murray: "Protecting the identity of intelligence sources is one of the few legitimate reasons for government secrecy. A 'freedom of information activist' does not serve his own cause, much less our national interest, by such reckless behavior." Ignoring Murray's hubris in claiming to know someone's motivations more strongly than he, what does this case have to do with government secrecy? It was the New York Times that decided to redact the document, not the CIA. The people who gave us the Pentagon Papers decided, on their own, not to release information that the CIA released to them. This is very different than the government trying to keep secrets. The last time I checked, the Times is not part of the intelligence community.
John Young, the activist Murray slams, makes classic full-disclosure arguments. The information was been published by the New York Times. Even though it took some work to extract, people are extracting it. Given this truth, it is better to release the information so that everyone can have access to it -- not only those random few who reverse-engineered the PDF file. Young said "Those folks who are named have a stake in knowing about it."
The opposing side has an equally predictable reaction: The information should be kept secret. Just because the New York Times erred and made the information available to a few people doesn't mean that we should compound the error and make the information available to everyone.
It's a complicated question, made even more muddy by the New York Times's decision to redact the document. If the CIA gave the New York Times the document in unredacted form, why did the Times decide to limit the public's knowledge of this information?
To me, this is a classic example of the power of full disclosure. The information in question -- the names of the Iranian citizens -- has been released to the public. Initially, it was known by only those few who had the means to reverse-engineer the PDF file, and those who learned as the information spread. Left to its own devices, this information would spread slowly. Maybe someone who wants to do these people harm would learn about this information; he certainly already knows that this information exists. Maybe some of the people named would learn that they are named, and be able to take appropriate action. But this process is slow and haphazard.
Better is to release the information to everyone, quickly. This limits the damage that can be done. The people named are more likely to find out they are named, and they are more likely to find out about it quickly. Those who want to take advantage of the relative secrecy of the information cannot. Everyone knows, and this levels the playing field. It is the situation where only a few random people know, and others find out piecemeal, that is unstable and dangerous.
Counterpane is pleased to announce a new insurance tie-in with Lloyd's of London. This is an exclusive offering for Counterpane customers: if Counterpane monitors your network, then you can purchase this insurance. For the first time ever, organizations can buy insurance against hacking without a security audit and without regard to the particular security products they use. Organizations can also buy, for the first time ever, warranty coverage that protects their customers against loss of income and data.
Computer security has always been sold as "threat prevention." Encryption, firewalls, anti-virus, PKI...these are all technologies that prevent particular threats. Threat prevention is a cost, and if an organization doesn't understand the threats, then it might not be willing to pay for prevention. Real business security, on the other hand, is about risk management. Risk management is not a cost, it's a way to make money. If one organization can manage its risk better than another, then it will be more profitable. Smart companies embrace risk, look for more of it, and figure out how to do business in the face of it.
Looking at computer security as a risk management tool, there are many more options than threat prevention. There is detection and response: managing risk by finding attacks in process and stopping them. And there is insurance: packaging risk and selling it to someone else. These are the future of computer security, not prophylactic technologies that promise a magical security blanket.
From the beginning, I have maintained that Counterpane Internet Security will address the real problems in network security. I have never believed that simply installing products will ever protect you, and have focused on the process of security. One part of that process is Managed Security Monitoring, which is what Counterpane's business is. The other part is insurance. Now Counterpane customers, and only Counterpane customers, have access to both.
Summary of the offering:
Counterpane Internet Security Inc., Lloyd's of London, Frank Crystal & Co., and SafeOnline Ltd. have jointly developed a first-of-its-kind, comprehensive risk management insurance solution specifically targeted to meet the needs of today's e-businesses.
Up to $100 million in protection available.
Two products available:
1. Internet Asset and Income Protection Coverage provides insurance for Counterpane's Managed Security Monitoring customers who incur a loss of or damage to information assets resulting from a breach of security or technology failure. Also covers business interruption due to loss of use due to a breach.
2. Internet Asset and Income Protection Warranty Plan for ISPs/ASPs that utilize Counterpane's Managed Security Monitoring services; this is a turnkey, insurance-backed warranty plan to extend the Internet Asset and Income Protection to their customers.
These insurance products are sold through authorized insurance brokers.
White Paper describing the insurance offering and its context:
More information on Counterpane's Managed Security Monitoring service can be found at:
<http://www.counterpane.com/oursol.html> [link dead; please see the Counterpane home page] <http://www.counterpane.com/coverage.html> [link dead; please contact Counterpane for information on supported sensors]
Bruce Schneier will address the Digital Commerce Society of Boston on August 1.
At WebDefense, in Washington DC (Aug 9), Bruce Schneier will give a talk entitled "What Level of Security Can We Reasonably Expect?"
For the full Counterpane conference schedule, see:
Another interesting article on writing computer viruses:
Software (children's software, no less) that automatically spies on you:
The need for security. Good article.
Problems with public-key infrastructures. This article was written well before I started thinking about the problems:
Countries are conducting military reconnaissance on U.S. computer networks:
Provocative articles on the risks of the new digital signature law:
Interesting cryptography story. A political party in Mexico wants an encryption key broken, because it believes that the resulting plaintext will embarrass the ruling party.
Commentary on the hype surrounding computer-security press coverage.
I don't agree: I think that the current media hype will desensitize people to the real threats and the real risks.
NATO releases a virus. (There's enough odd in this story for me to doubt its veracity, but who knows.)
The motives and psychology of the black-hat community. Another good essay by Lance Spitzner.
<http://www.securityfocus.com/focus/ids/articles/kye/...> [link moved to http://www.securityfocus.com/infocus/1448]
Publius is a system for anonymous, censorship-resistant publishing on the Web.
They're looking for people willing to host a Publius server.
The Secret Service is developing a Electronic Crimes Special Agent
Program. Agents analyze new security products and alert vendors to weaknesses.
Failing dot-coms are selling private information:
More proof that they should never be allowed to collect it in the first place, and that posted privacy policies aren't worth the phosphors they're displayed on.
Special news report on Echelon:
The government of France is investigating:
Interesting article on the lack of security in Australian government Web sites:
And other articles on the same topic:
There were rumors of hackers disrupting the Space Shuttle a few years ago. Here is what seems to be a coherent story:
NASA denies it:
The question to ask is: why in the world are these critical systems attached to public networks in the first place?
Electronic Commerce: Who Carries the Risk of Fraud?
NIST has published an index of computer vulnerabilities. Called ICAT, it links users into a variety of publicly available vulnerability databases and patch sites. ICAT is not itself a vulnerability database, but instead a searchable index leading one to vulnerability resources and patch information. ICAT allows one to search at a fine granularity, a feature unavailable with most vulnerability databases, by characterizing each vulnerability by over 40 attributes (including software name and version number). ICAT indexes the information available in CERT advisories, ISS X-Force, Security Focus, NT Bugtraq, Bugtraq, and a variety of vendor security and patch bulletins. ICAT uses the CVE vulnerability naming standard.
The insecurity of wireless computing:
New technology for recovering erased data on electronic media:
Good editorial. The biggest problem in computer security is the user, not the computer.
Lots of "pay-to-surf" sites are springing up, paying users to look at web advertisements, along with a cottage industry of programs that help rogue surfers bypass the rules and get paid anyway.
Social Security numbers of the rich and famous:
Internet voting is unsafe (no surprise), says a new study.
Spam with huge media attachments. Anyone care to ponder the implications for virus writers?
"The Carnivore," from the FBI. An expert system that seaches through email.
The ACLU complains:
The Cyber Group Network Corp claims to have a technology that allows you to locate a stolen computer, remotely retrieve information from it, and the destroy it. Sounds a bit far fetched. But they take "security by obscurity to new heights: "According to Nish Kapoor, a spokesperson for The Cyber Group Network, the patent pending technology that makes all this possible is being manufactured and developed at a remote, top-secret location identified only as 'Area 74.'" Wow.
And even worse, software that allows companies to track down (and presumably prosecute) those who say unkind things about them on the Internet. What happened to free speech on the Internet?
According to a story regarding Clinton signing the e-signature bill with a smart card:
"With a magnetic card and his dog Buddy's name as a password, President Clinton e-signed a bill Friday that will make electronic signatures as real as those on paper."
Note his choice of password. It's five characters, all alphas, and probably all lower case. At least he doesn't keep it on a Post-it in his desk.
Intuit's QuickBooks is a finance manager for small companies. It has lots of great features and is one of the most popular financial packages available. Unfortunately, the security sucks.
The earliest versions of QuickBooks stored usernames and passwords in the clear. As the version number increased, so did the amount of obfuscation: first they XORed the data with a constant mask, then they added some byte rotations and more bit twiddling. The latest versions of QuickBooks use DES to encrypt blocks of data containing a username and the corresponding password. This could have made the system much harder to break, if only the decryption keys weren't stored in the file.
To verify that the user has the correct password, QuickBooks looks up the decryption key, decrypts the block, and compares the password the user typed in to the one it just decrypted. Nothing prevents an unauthorized program from performing the same steps and printing out all the usernames and passwords.
Thanks to Mike Stay for pointing this out.
"In respect to lock-making, there can scarcely be such a thing as dishonesty of intention: the inventor produces a lock which he honestly thinks will possess such and such qualities; and he declares his belief to the world. If others differ from him in opinion concerning those qualities, it is open to them to say so; and the discussion, truthfully conducted, must lead to public advantage: the discussion stimulates curiosity, and curiosity stimulates invention. Nothing but a partial and limited view of the question could lead to the opinion that harm can result: if there be harm, it will be much more than counterbalanced by good."
-- Charles Tomlinson's Rudimentary Treatise on the Construction of Locks, published around 1850.
Those of you who have subscribed recently might have missed these essays from back issues.
The Future of Crypto-Hacking:
Unicode is an international character set. Like ASCII, it provides a standard correspondence between the binary numbers that computers understand and the letters, digits, and punctuation that people understand. But unlike ASCII, it seeks to provide a code for every character in every language in the world. To do this requires more than 256 characters, the 8-bit ASCII character set; default Unicode uses 16-bit characters, and there are rules to extend even that.
I don't know if anyone has considered the security implications of this.
Remember all those input validation attacks that were based on replacing characters with alternate representations, or that explored alternative delimiters? For example, there was a hole in the IRIX Web server: if you could replace spaces with tabs you could fool the parser, and you could use hexadecimal escapes, strange quoting, and nulls to defeat input validation.
The Unicode specification includes all sorts of complicated new escape sequences. They have things called UTF-8 and UTF-16, which allow several possible representations of various character codes, several different places where control-characters pop through, a scheme for placing diacriticals and accents in separated characters (looking very much like an escape), and hundreds of brand new punctuation characters and otherwise nonalphabetic characters.
The philosophy behind the Unicode spec is to provide all possible useful characters for applications that are 8- or 16-bit clean. This is admirable, but it is nearly impossible to filter a Unicode character stream to decide what is "safe" in some application and what is not.
What happens when:
- We start attaching semantics to the new characters as delimiters, white space, etc? With thousands of characters and new characters being added all the time, it will be extremely difficult to categorize all the possible characters consistently, and where there is inconsistency, there tends to be security holes.
- Somebody uses "modifier" characters in an unexpected way?
- Somebody uses UTF-8 or UTF-16 to encode a conventional character in a novel way to bypass validation checks?
With the ASCII character set, we could carefully study a small selection of characters, categorize them clearly, and make relatively straightforward decisions about the nature of each character. And even here, there have been mistakes (forgetting about tabs, multicharacter control-sequence snafus, etc). Still, a careful designer can figure out a safe way to deal with any possible character that can come off an untrusted wire by elimination if necessary.
With Unicode, we probably won't be able to get a consistent definition of what to accept, what is a delimiter under what circumstance, or how to handle arbitrary streams safely. It's just a matter of time before simple validators pass data and upper layer software, trying to be helpful, attach magic-character semantics, and we have a brand-new variety of security holes.
Unicode is just too complex to ever be secure.
My thanks to Jeffrey Streifling, who provided much of the material for this article.
From: Bernard Peek <Bernardpostar.co.uk>
Subject: Remotely Disabling Software
In the UK there is legal protection against disabling software by remote commands. In general this is illegal without the users' prior consent. It could be permitted if the user agreed to a software license that contained appropriate clauses. As I understand it, in the absence of a prior agreement any supplier that disabled a program running on a machine in the UK would be committing an offence within UK jurisdiction. Whether they triggered the event from elsewhere is not a defence.
I believe that one software supplier embedded an undisclosed time-trap in their program which would disable it. The trap was sprung if the supplier failed to switch it off. They would only do that if the customer failed to pay the final invoice.
One invoice was disputed and the trap was sprung. The software supplier was successfully prosecuted and had to pay a fine and damages.
I note, with some interest, that some files have security certificates with expiry dates, and that some programs will not work with expired files. I trust that the suppliers of these files have mechanisms in place to replace all of them prior to their expiry date, or have the customer's signature on a software license that details the conditions under which the programs cease to work.
From: Matt Curtin <cmcurtininterhack.net>
Subject: Breaking DES Keys by Brute Force
In the June 15 issue of CRYPTO-GRAM, you discuss the (in)security of DES because of its relatively short key length.
> Concerns about its short key length have dogged the
> algorithm since the beginning, and in 1998 a brute- > force machine capable of breaking DES was built.
John Gilmore and company made an important advancement with Deep Crack in 1998, breaking DES keys very quickly. But the first break of a DES key was actually accomplished in 1997 in software by a team led by Rocke Verser. Justin Dolske and I wrote a paper describing the architecture of the system that was published in the May 1998 special issue of ;login.
This seems an important thing to mention not just because we can move the time that it took to break DES keys back another year, but because it has been demonstrated (twice -- another team did the same thing the following year) that the key length was so short that it could be broken in software using only random idle cycles from computers talking together over a simple protocol. Before this is dismissed as an impractical attack, consider that it's believed that recent distributed denial-of-service attacks have been perpetrated by attackers who take over others' machines without their knowledge and then coordinate these "zombie machines" to do their work. If attackers can do this for launching DoS attacks, it could be done to break keys. (Though because of the inefficiency of the attack, this won't be used for anyone but attackers with no money, I'd think...)
The technical article is online at <http://www.interhack.net/pubs/des-key-crack/> and a nontechnical article (originally written for the press) briefly describing cryptography, brute force attacks, and our project's success is at
From: Paul Bissex <pbe-scribe.com>
Subject: Re: Cryptogram 6/15, Williams/Agre
A quick note on J. Christopher Williams' response to Phil Agre. I believe Mr. Williams has a legitimate difference of opinion here, though I do not share his views. However, to say that "[Agre's] grasp of basic grammar is less than firm" is simply laughable, especially after one has struggled through a few dozen lines of Mr. Williams' stilted prose.
There are few people who write about technology with as much intelligence, erudition, and accuracy as Phil Agre. It is unfortunate that Mr. Williams felt the need to turn his nitpick into a personal attack.
From: "Jay R. Ashworth" <email@example.com>
Subject: Comments to Schneier on Agre
In comments published in the June Cryptogram, Mr. Williams, you take issue with the comments by Phil Agre pointed to by, I believe, the previous edition of the newsletter...
> "... This is by-design behavior, not a security > vulnerability."
> "More odd language. It's like saying, 'This is a rock,
> not something that can fall to the ground'. It's
> confusing to even think about it.
> The author may be a security or computer expert, but
> his grasp of basic grammar is less than firm. The more
> accurate grammar conversion would be "This is an
> object thrown to the ground, not a free-falling
> object." The statement in and of itself merely assists
> in defining what can be called "thrown" and what can
> be called "free-falling" campaign the author suggests.
> To me the author is seemingly engaging in the same
> "blame shifting tactic" that he accuses Microsoft of.
The way *I* see this is this: Agre feels, and I agree with him, that Microsoft, in its phrasing, is suggesting that since [the behavior in question] is by design, that it *cannot be* a security vulnerability; that is, that they are mutually exclusive.
If in fact this is the assertion that Microsoft is trying to cause people to infer, they are wrong. For evidence, we need merely look to one of the most famous security holes of all time: the sendmail DEBUG command.
Obviously this was placed in the software by design. Equally obviously, it was a security vulnerability. Therefore, it must be possible for an element of a program to be both of these things.
Therefore, Microsoft's explanation must be disingenuous, as they are trying to assert that these two descriptions of a part of a program cannot both simultaneously be true.
The problem isn't Phil doesn't understand the language, it's that Microsoft is playing fast and loose with it.
From: kragenpobox.com (Kragen Sitaker)
Subject: Risks of XML
> XML and how to secure it:
> <http://www.zdnet.co.uk/news/2000/20/ns-15500.html> [link moved to http://news.zdnet.co.uk/story/0,,s2079073,00.html]
This topic is sort of like "ASCII and how to secure it." This paragraph says it best:
> And that is the one big problem. The Internet is as
> insecure as ever, and ASCII will do nothing to improve
> it. In fact, the temptation to intercept and alter an
> ASCII document containing vital data en route from one
> banking application to another will lure many an
> Internet vandal.
Well, in the original, it said XML, not ASCII, but it makes just as much sense either way.
From: Darren Cervantes <firstname.lastname@example.org>
Subject: SOAP Security
Your newsletter was forwarded to me recently. I am interested in your opinion on SOAP security issues. Your recent article suggested that any SOAP command may be able to sneak through to your machine and do something malicious. You state: Firewalls have good reasons for blocking protocols like DCOM coming from untrusted sources. Protocols that sneak them through are not what's wanted.
In my understanding of the SOAP protocol, a few things have to happen in order for an RPC to "sneak" through:
1) An explicit SOAP server has to be set up
2) The SOAP server has to "translate" SOAP to enterprise services or RPCs
3) That server has to be configured to execute particular SOAP services (in other words if the service isn't defined, it isn't available through SOAP)
4) The server has an opportunity to recognize the SOAP service and refuse or block it if it is invalid
In addition, in the MS SOAP document, they state that both HTTP encryption (SSL) and HTTP authentication protocols can be used in conjunction with any end-point security (presumably authorization). This would help negate the "untrusted sources" factor.
Based on my understanding, you would have to set up a SOAP server and an explicit service to "erase harddrive." You would then have to allow your server to accept the request. In a sense, it seems that this same concern could be equally applied to many other technologies. If SOAP were to be implemented irresponsibly, it could certainly be insecure, but isn't it possible to implement it securely?
CRYPTO-GRAM is a free monthly newsletter providing summaries, analyses, insights, and commentaries on computer security and cryptography.
To subscribe, visit http://www.schneier.com/crypto-gram.html or send a blank message to email@example.com. To unsubscribe, visit http://www.schneier.com/crypto-gram-faq.html. Back issues are available at http://www.schneier.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 "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.