---------- Forwarded Message ----------
Subject: CRYPTO-GRAM, November 15, 2005
Date: Tuesday November 15 2005 02:21
From: Bruce Schneier <schneier@COUNTERPANE.COM>
To: CRYPTO-GRAM-LIST@LISTSERV.MODWEST.COM
CRYPTO-GRAM
November 15, 2005
by Bruce Schneier
Founder and CTO
Counterpane Internet Security, Inc.
schneier@counterpane.com
<http://www.schneier.com>
<http://www.counterpane.com>
A free monthly newsletter providing summaries, analyses, insights, and
commentaries on security: computer and otherwise.
For back issues, or to subscribe, visit
<http://www.schneier.com/crypto-gram.html>.
You can read this issue on the web at
<http://www.schneier.com/crypto-gram-0511.html>. These same essays
appear in the "Schneier on Security" blog:
<http://www.schneier.com/blog>. An RSS feed is available.
** *** ***** ******* *********** *************
In this issue:
The Security of RFID Passports
Liabilities and Software Vulnerabilities
Crypto-Gram Reprints
Preventing Identity Theft: The Living and the Dead
Banks and Two-Factor Authentication
News
Sony Secretly Installs Rootkit on Computers
DMCA Review
Counterpane News
Taser Cam
A "Typical" Terrorist
The Zotob Worm
** *** ***** ******* *********** *************
The Security of RFID Passports
In 2004, when the U.S. State Department first started talking about
embedding RFID chips in passports, the outcry from privacy advocates
was huge. When the State Department issued its draft regulation in
February, it got 2,335 comments, 98.5% negative. In response, the final
State Department regulations, issued last month, contain two features
that attempt to address security and privacy concerns. But one serious
problem remains.
Before I describe the problem, some context on the surrounding
controversy may be helpful. RFID chips are passive, and broadcast
information to any reader that queries the chip. So critics, myself
included, were worried that the new passports would reveal your
identity without your consent or even your knowledge. Thieves could
collect the personal data of people as they walk down a street,
criminals could scan passports looking for Westerners to kidnap or rob
and terrorists could rig bombs to explode only when four Americans are
nearby. The police could use the chips to conduct surveillance on an
individual; stores could use the technology to identify customers
without their knowledge.
RFID privacy problems are larger than passports and identity cards. The
RFID industry envisions these chips embedded everywhere: in the items
we buy, for example. But even a chip that only contains a unique serial
number could be used for surveillance. And it's easy to link the serial
number with an identity -- when you buy the item using a credit card,
for example -- and from then on it can identify you. Data brokers like
ChoicePoint will certainly maintain databases of RFID numbers and
associated people; they'd do a disservice to their stockholders if they
didn't.
The State Department downplayed these risks by insisting that the RFID
chips only work at short distances. In fact, last month's publication
claims: "The proximity chip technology utilized in the electronic
passport is designed to be read with chip readers at ports of entry
only when the document is placed within inches of such readers." The
issue is that they're confusing three things: the designed range at
which the chip is specified to be read, the maximum range at which the
chip could be read, and the eavesdropping range or the maximum range
the chip could be read with specialized equipment. The first is indeed
inches, but the second was demonstrated earlier this year to be 69
feet. The third is significantly longer.
And remember, technology always gets better -- it never gets worse.
It's simply folly to believe that these ranges won't get longer over time.
To its credit, the State Department listened to the criticism. As a
result, RFID passports will now include a thin radio shield in their
covers, protecting the chips when the passports are closed. Although
some have derided this as a tinfoil hat for passports, the fact is the
measure will prevent the documents from being snooped when closed.
However, anyone who travels knows that passports are used for more than
border crossings. You often have to show your passport at hotels and
airports, and while changing money. More and more it's an identity
card; new Italian regulations require foreigners to show their
passports when using an Internet cafe.
Because of this, the State Department added a second, and
more-important, feature: access control. The data on the chip will be
encrypted, and the key is printed on the passport. A customs officer
swipes the passport through an optical reader to get the key, and then
the RFID reader uses the key to communicate with the RFID chip.
This means that the passport holder can control who gets access to the
information on the chip, and someone cannot skim information from the
passport without first opening it up and reading the information
inside. This also means that a third party can't eavesdrop on the
communication between the card and the reader, because it's encrypted.
By any measure, these features are exemplary, and should serve as a
role model for any RFID identity-document applications. Unfortunately,
there's still a problem.
RFID chips, including the ones specified for U.S. passports, can still
be uniquely identified by their radio behavior. Specifically, these
chips have a unique identification number used for collision avoidance.
It's how the chips avoid communications problems if you put a bagful of
them next to a reader. This is something buried deep within the chip,
and has nothing to do with the data or application on the chip.
Chip manufacturers don't like to talk about collision IDs or how they
work, but researchers have shown how to uniquely identify RFID chips by
querying them and watching how they behave. And since these queries
access a lower level of the chip than the passport application, an
access-control mechanism doesn't help.
To fix this, the State Department needs to require that the chips used
in passports implement a collision-avoidance system not based on unique
serial numbers. The RFID spec -- ISO 14443A is its name -- allows for a
random system, but I don't believe any manufacturer implements it this
way.
Adding chips to passports can inarguably be good for security. Initial
chips will only contain the information printed on the passport, but
this system has always envisioned adding digital biometrics like
photographs or even fingerprints, which will make passports harder to
forge, and stolen passports harder to use.
But the State Department's contention that they need an RFID chip, that
smartcard-like contact chips won't work, is much less convincing. Even
with all this security, RFID should be the design choice of last resort.
The State Department has done a great job addressing specific security
and privacy concerns, but its lack of technical skills is hurting it.
The collision-avoidance ID issue is just one example of where,
apparently, the State Department didn't have enough of the expertise it
needed to do this right.
Of course it can fix the problem, but the real issue is how many other
problems like this are lurking in the details of its design? We don't
know, and I doubt the State Department knows, either. The only way to
vet its design, and to convince us that RFID is necessary, would be to
open it up to public scrutiny.
The State Department's plan to issue RFID passports by October 2006 is
both precipitous and risky. It made a mistake designing this behind
closed doors. There needs to be some pretty serious quality assurance
and testing before deploying this system, and this includes careful
security evaluations by independent security experts. Right now the
State Department has no intention of doing that; it's already committed
to a scheme before knowing if it even works or if it protects privacy.
Government announcement:
<http://edocket.access.gpo.gov/2005/05-21284.htm>
RFID privacy problems:
<http://www.epic.org/privacy/rfid/>
<http://rfidkills.com/>
My previous writings on RFID passports:
<http://www.schneier.com/essay-060.html>
<http://www.schneier.com/blog/archives/2005/04/rfid_passport_s.html>
<http://www.schneier.com/blog/archives/2005/08/rfid_passport_s_1.html>
This essay previously appeared on Wired.com:
<http://www.wired.com/news/privacy/0,1848,69453,00.html>
** *** ***** ******* *********** *************
Liabilities and Software Vulnerabilities
At a security conference last month, Howard Schmidt, the former White
House cybersecurity adviser, took the bold step of arguing that
software developers should be held personally accountable for the
security of the code they write.
He's on the right track, but he's made a dangerous mistake. It's the
software manufacturers that should be held liable, not the individual
programmers. Getting this one right will result in more-secure software
for everyone; getting it wrong will simply result in a lot of messy
lawsuits.
To understand the difference, it's necessary to understand the basic
economic incentives of companies, and how businesses are affected by
liabilities. In a capitalist society, businesses are profit-making
ventures, and they make decisions based on both short- and long-term
profitability. They try to balance the costs of more-secure software --
extra developers, fewer features, longer time to market -- against the
costs of insecure software: expense to patch, occasional bad press,
potential loss of sales.
The result is what you see all around you: lousy software. Companies
find that it's cheaper to weather the occasional press storm, spend
money on PR campaigns touting good security, and fix public problems
after the fact than to design security right from the beginning.
The problem with this analysis is that most of the costs of insecure
software fall on the users. In economics, this is known as an
externality: an effect of a decision not borne by the decision maker.
Normally, you would expect users to respond by favoring secure products
over insecure products -- after all, they're making their own buying
decisions based on the same capitalist model. But that's not generally
possible. In some cases, software monopolies limit the available
product choice; in other cases, the "lock-in effect" created by
proprietary file formats or existing infrastructure or compatibility
requirements makes it harder to switch; and in still other cases, none
of the competing companies have made security a differentiating
characteristic. In all cases, it's hard for an average buyer to
distinguish a truly secure product from an insecure product with a
"boy, are we secure" marketing campaign.
The end result is that insecure software is common. But because users,
not software manufacturers, pay the price, nothing improves. Making
software manufacturers liable fixes this externality.
Watch the mechanism work. If end users can sue software manufacturers
for product defects, then the cost of those defects to the software
manufacturers rises. Manufacturers are now paying the true economic
cost for poor software, and not just a piece of it. So when they're
balancing the cost of making their software secure versus the cost of
leaving their software insecure, there are more costs on the latter
side. This will provide an incentive for them to make their software
more secure.
To be sure, making software more secure will cost money, and
manufacturers will have to pass those costs on to users in the form of
higher prices. But users are already paying extra costs for insecure
software: costs of third-party security products, costs of consultants
and security-services companies, direct and indirect costs of losses.
Making software manufacturers liable moves those costs around, and as a
byproduct causes the quality of software to improve.
This is why Schmidt's idea won't work. He wants individual software
developers to be liable, and not the corporations. This will certainly
give pissed-off users someone to sue, but it won't reduce the
externality and it won't result in more-secure software.
Computer security isn't a technological problem -- it's an economic
problem. Socialists might imagine that companies will improve software
security out of the goodness of their hearts, but capitalists know that
it needs to be in companies' economic best interest. We'll have fewer
vulnerabilities when the entities that have the capability to reduce
those vulnerabilities have the economic incentive to do so. And this is
why solutions like liability and regulation work.
Schmidt's comments:
<http://news.zdnet.co.uk/software/developer/0,39020387,39228663,00.htm>
SlashDot thread on Schmidt's concerns:
<http://developers.slashdot.org/article.pl?sid=05/10/12/1335215&tid=172&
tid=8> or <http://tinyurl.com/dvpd7>
Dan Farber has a good commentary on my essay.
<http://blogs.zdnet.com/BTL/?p=2046>
This essay originally appeared on Wired.com:
<http://www.wired.com/news/privacy/0,1848,69247,00.html>
There has been some confusion about this in the comments -- both in
Wired and on my blog -- that somehow this means that software vendors
will be expected to achieve perfection and that they will be 100%
liable for anything short of that. Clearly that's ridiculous, and
that's not the way liabilities work. But equally ridiculous is the
notion that software vendors should be 0% liable for
defects. Somewhere in the middle there is a reasonable amount of
liability, and that's what I want the courts to figure out.
Howard Schmidt writes: "It is unfortunate that my comments were
reported inaccurately; at least Dan Farber has been trying to correct
the inaccurate reports with his blog. I do not support PERSONAL
LIABILITY for the developers NOR do I support liability against
vendors. Vendors are nothing more then people (employees included) and
anything against them hurts the very people who need to be given better
tools, training and support."
Howard wrote this essay on the topic, to explain what he really
thinks. He is against software liabilities.
<http://news.com.com/Give+developers+secure-coding+ammo/2010-1002_3-5929
364.html> or <http://tinyurl.com/dmlgh>
But the first sentence of his last paragraph nicely sums up what's
wrong with this argument: "In the end, what security requires is the
same attention any business goal needs." If security is to be a
business goal, then it needs to make business sense. Right now, it
makes more business sense not to produce secure software products than
it does to produce secure software products. Any solution needs to
address that fundamental market failure, instead of simply wishing it
were true.
** *** ***** ******* *********** *************
Crypto-Gram Reprints
Crypto-Gram is currently in its seventh year of publication. Back
issues cover a variety of security-related topics, and can all be found
on <http://www.schneier.com/crypto-gram.html>. These are a selection
of articles that appeared in this calendar month in other years.
Why Election Technology is Hard:
<http://www.schneier.com/crypto-gram-0411.html#1>
Electronic Voting Machines:
<http://www.schneier.com/crypto-gram-0411.html#2>
The Security of Checks and Balances
<http://www.schneier.com/crypto-gram-0411.html#10>
Security Information Management Systems (SIMS):
<http://www.schneier.com/crypto-gram-0411.html#12>
Technology and Counterterrorism:
<http://www.schneier.com/crypto-gram-0411.html#13>
Airplane Hackers:
<http://www.schneier.com/crypto-gram-0311.html#1>
The Trojan Defense
<http://www.schneier.com/crypto-gram-0311.html#8>
Full Disclosure:
<http://www.schneier.com/crypto-gram-0111.html#1>
Why Digital Signatures are Not Signatures
<http://www.schneier.com/crypto-gram-0011.html#1>
Programming Satan's Computer: Why Computers Are Insecure
<http://www.schneier.com/crypto-gram-9911.html#WhyComputersareInsecure>
or <http://tinyurl.com/7ldrl>
Elliptic Curve Public-Key Cryptography
<http://www.schneier.com/crypto-gram-9911.html#EllipticCurvePublic-KeyCr
yptography> or <http://tinyurl.com/a2low>
The Future of Fraud: Three reasons why electronic commerce is different
<http://www.schneier.com/crypto-gram-9811.html#commerce>
Software Copy Protection: Why copy protection does not work
<http://www.schneier.com/crypto-gram-9811.html#copy>
** *** ***** ******* *********** *************
Preventing Identity Theft: The Living and the Dead
A company called Metacharge has rolled out an e-commerce security
service in the United Kingdom. For about $2 per name, website
operators can verify their customers against the UK Electoral Roll, the
British Telecom directory, and a mortality database.
That's not cheap, and the company is mainly targeting customers in
high-risk industries, such as online gaming. But the economics behind
this system are interesting to examine. They illustrate externalities
associated with fraud and identity theft, and why leaving matters to
the companies won't fix the problem.
The mortality database is interesting. According to Metacharge, "the
fastest growing form of identity theft is not phishing; it is taking
the identities of dead people and using them to get credit."
For a website, the economics are straightforward. It costs $2 to
verify that a customer is alive. If the probability the customer is
actually dead (and therefore fraudulent) times the average losses due
to this dead customer is more than $2, this service makes sense. If it
is less, then the service doesn't. For example, if dead customers are
one in ten thousand, and they cost $15,000 each, then the service is
not worth it. If they cost $25,000 each, or if they occur twice as
often, then it is worth it.
Imagine now that there is a similar service that identifies identity
fraud among living people. The same economic analysis would also
hold. But in this case, there's an externality: there is an additional
cost of fraud borne by the victim and not by the website. So if fraud
using the identity of living customers occurs at a rate of one in ten
thousand, and each one costs $15,000 to the website and another $10,000
to the victim, the website will conclude that the service is not
worthwhile, even though paying for it is cheaper overall. This is why
legislation is needed: to raise the cost of fraud to the websites.
There's another economic trade-off. Websites have two basic
opportunities to verify customers using services such as these. The
first is when they sign up the customer, and the second is after some
kind of non-payment. Most of the damages to the customer occur after
the non-payment is referred to a credit bureau, so it would make sense
to perform some extra identification checks at that point. It would
certainly be cheaper to the website, as far fewer checks would be paid
for. But because this second opportunity comes after the website has
suffered its losses, it has no real incentive to take advantage of
it. Again, economics drives security.
<http://www.theregister.co.uk/2005/10/21/outlaw_gambling/>
** *** ***** ******* *********** *************
Banks and Two-Factor Authentication
I've repeatedly said that two-factor authentication won't stop
phishing, because the attackers will simply modify their techniques to
get around it. Here's an example where that has happened:
"Scandinavian bank Nordea was forced to shut down part of its Web
banking service for 12 hours last week following a phishing attack that
specifically targeted its paper-based one-time password security system.
"According to press reports, the scam targeted customers that access
the Nordea Sweden Web banking site using a paper-based single-use
password security system.
"A blog posting by Finnish security firm F-Secure says recipients of
the spam e-mail were directed to bogus Web sites but were also asked to
enter their account details along with the next password on their list
of one-time passwords issued to them by the bank on a 'scratch sheet.'"
>From F-Secure's blog:
"The fake mails were explaining that Nordea is introducing new security
measures, which can be accessed at www.nordea-se.com or
www.nordea-bank.net (fake sites hosted in South Korea).
"The fake sites looked fairly real. They were asking the user for his
personal number, access code and the next available scratch code.
Regardless of what you entered, the site would complain about the
scratch code and asked you to try the next one. In reality the bad boys
were trying to collect several scratch codes for their own use."
Two-factor authentication won't stop identity theft, because identity
theft is not an authentication problem. It's a transaction-security
problem. I've written about that already. Solutions need to address
the transactions directly, and my guess is that they'll be a
combination of things. Some transactions will become more
cumbersome. It will definitely be more cumbersome to get a new credit
card. Back-end systems will be put in place to identify fraudulent
transaction patterns. Look at credit card security; that's where
you're going to find ideas for solutions to this problem.
Unfortunately, until financial institutions are liable for all the
losses associated with identity theft, and not just their direct
losses, we're not going to see a lot of these solutions. I've written
about this before as well.
We got them for credit cards because Congress mandated that the banks
were liable for all but the first $50 of fraudulent transactions.
News story:
<http://www.finextra.com/fullstory.asp?id=14384>
<http://www.theregister.co.uk/2005/10/12/outlaw_phishing/>
F-Secure's blog:
<http://www.f-secure.com/weblog/archives/archive-102005.html>
Here's a related story. The Bank of New Zealand suspended Internet
banking because of phishing concerns. Now there's a company that is
taking the threat seriously.
<http://www.stuff.co.nz/stuff/0,2106,3450674a13,00.html>
Meanwhile, the government is mandating two-factor authentication for
U.S. banks:
<http://banktech.com/news/showArticle.jhtml?articleID=173401089>
<http://www.ffiec.gov/press/pr101205.htm>
** *** ***** ******* *********** *************
News
Here's a phishing scam using SMS messages and a telephone call.
<http://www.chinadaily.com.cn/english/doc/2005-10/12/content_484196.htm>
or <http://tinyurl.com/bvz3q>
Passport required to use the Internet in Italy. Why? Terrorism, of course.
<http://www.csmonitor.com/2005/1004/p07s01-woeu.html>
Many color laser printers embed secret information in every page they
print, basically to identify you by. Here, the EFF has cracked the
code of the Xerox DocuColor series of printers.
<http://www.eff.org/Privacy/printers/docucolor/>
<http://news.com.com/2300-1029_3-5901948-1.html>
<http://www.washingtonpost.com/wp-dyn/content/article/2005/10/18/AR20051
01801663.html>
The UK has used terrorism laws to stifle free speech:
<http://www.schneier.com/blog/archives/2005/10/terrorism_laws.html>
Now it's using them to keep pedestrians off bicycle paths:
<http://women.timesonline.co.uk/article/0,,17909-1829289,00.html>
And to prevent people from taking pictures of motorways:
<http://www.dailyecho.co.uk/hampshire/southampton/news/SOTON_NEWS_NEWS0.
html>
I get that terrorism is the threat of the moment, and that all sorts of
government actions are being justified with terrorism. But this is
ridiculous.
The police are asking for access to private webcams.
<http://www.pe.com/localnews/corona/stories/PE_News_Local_C_cwatch05.13a
cfd04.html> or <http://tinyurl.com/c5rrz>
How soon before there's a law requiring these webcams to be built with
a police backdoor?
This is just a lovely essay. Very subtle.
<http://www.theregister.co.uk/2005/04/27/security_for_the_paranoid/>
A weird and amusing tour of U.S. government security awareness posters.
<http://www.defensetech.org/archives/001862.html>
"Study Reveals Pittsburgh Unprepared for Full-Scale Zombie Attack"
<http://www.theonion.com/content/node/41676>
An absolutely amazing story about phantom ATM withdrawals and British
banking from the early 90s. (The story is from the early 1990s; it has
just become public.) Read how a very brittle security system, coupled
with banks using the legal system to avoid fixing the problem, resulted
in lots of innocent people losing money to phantom withdrawals. Read
how lucky everyone was that the catastrophic security problem was never
discovered by criminals. It's an amazing story.
<http://www.theregister.co.uk/2005/10/21/phantoms_and_rogues/>
See also Ross Anderson's page on phantom withdrawals:
<http://www.cl.cam.ac.uk/~mkb23/phantom>
Oh, and Alistair Kelman assures me that he did not charge 1,750 pounds
per hour, only 450 pounds per hour.
This is an interesting (six-month-old) story about a supermarket
loyalty program. Person 1 loses a valuable watch in a
supermarket. Person 2 finds it and, instead of returning it as
required by law, keeps it. Two years later, he brings it in for
repair. The repairman checks the serial number against a lost/stolen
database. Person 2 doesn't admit he found the watch, but instead
claims that he bought it in some sort of used watch store. The police
check the loyalty-program records from the supermarket and find that
Person 2 was in the supermarket within hours of when Person 1 said he
lost the watch.
<http://www.timesonline.co.uk/article/0,,2-1459390,00.html>
FBI abuses of the USA Patriot Act:
<http://www.schneier.com/blog/archives/2005/10/fbi_abuses_of_t_1.html>
One of the sillier movie-plot threats I've seen recently: terrorists
playing bingo in Kentucky.
<http://www.wkyt.com/Global/story.asp?S=4019597>
Interesting commentary on digital identification cards.
<http://www.chi-publishing.com/?staticID=0>
Movie-plot threats aren't limited to terrorism. Bird flu is the
current movie-plot threat in the medical world. People are convinced
that they have the disease when they don't.
<http://www.nytimes.com/2005/10/25/health/psychology/25essa.html>
New technology allows eavesdropping through walls.
<http://www.newscientist.com.nyud.net:8090/article.ns?id=dn8208>
Missouri wants to track people's movements through their cell phones.
<http://www.thenewspaper.com/news/06/696.asp>
There's a new Australian anti-terrorism law in the works. It includes
such things as 14-day secret detention without arrest by security
services, shoot-to-kill "on suspicion" powers for police, and
imprisonment and fines for revealing an individual has been the subject
of an investigation. The news reports are pretty bad.
<http://www.theage.com.au/news/opinion/antiterrorism-laws-threaten-media
-freedom/2005/10/24/1130006058337.html> or <http://tinyurl.com/brtou>
<http://www.abc.net.au/news/newsitems/200510/s1489719.htm>
This draft legislation was not supposed to be public yet, but the Chief
Minister of the ACT posted it on his website in defiance of a federal
government request not to do so.
<http://chiefminister.act.gov.au/media.asp?media=692§ion=24&title=Me
dia%20Release&id=24> or <http://tinyurl.com/74tf2>
<http://www.chiefminister.act.gov.au/docs/B05PG201_v281.pdf>
Here's a security threat I'll bet you never even considered before --
convicted felons with large dogs: "The Contra Costa County board of
supervisors [in California] unanimously supported on Tuesday
prohibiting convicted felons from owning any dog that is aggressive or
weighs more than 20 pounds, making it all but certain the proposal will
become law when it formally comes before the board for approval Nov.
15." These are not felons in jail. These are felons who have been
released from jail after serving their time. They're allowed to
re-enter society, but letting them own a large dog would be just too
much of a risk to the community?
<http://www.sfgate.com/cgi-bin/article.cgi?f=/c/a/2005/10/26/BAGGAFE5251
.DTL&hw=contra+costa+felons+dogs&sn=001&sc=1000> or
<http://tinyurl.com/92fxn>
Judges have blocked police from using cell phones as tracking devices.
Good news for once.
<http://www.wired.com/news/technology/0,1282,69390,00.html>
NIST hosted a cryptographic hash workshop to talk about what to do in
the wake of the recent cryptanalytic attacks on SHA-1. Lots of
interesting discussion; no conclusions except that more research and
discussion is required. I liveblogged the event.
<http://www.schneier.com/blog/archives/2005/10/nist_hash_works_1.html>
<http://www.schneier.com/blog/archives/2005/10/nist_hash_works_2.html>
<http://www.schneier.com/blog/archives/2005/10/nist_hash_works_3.html>
<http://www.schneier.com/blog/archives/2005/11/nist_hash_works.html>
<http://www.schneier.com/blog/archives/2005/11/nist_hash_works_4.html>
The story about secret NSA patents is wrong:
<http://www.newscientist.com/article.ns?id=dn8223>
<http://blog.wired.com/elsewhere/index.blog?entry_id=1264879>
Authenticating people by their typing patterns:
<http://pc50461.uni-regensburg.de/ibi/de/leistungen/research/projekte/ri
sk/psylock_english> or <http://tinyurl.com/axnqu>
I've often said that security discussions are rarely about
security. Here's a story that illustrates that. A New Jersey mother
doesn't like her child's school bus stopping at McDonald's on Friday
mornings. Apparently unable to come up with a cogent argument against
these stops (which seems odd to me, honestly, as I can think of
several), she invokes movie-plot security threats: "Tyler wants the
stops to, well, stop before a student is hit by someone speeding into
the drive-thru or before a robbery occurs and her son and other
students are inside."
<http://www.nj.com/news/bridgeton/index.ssf?/base/news-0/113014689811964
0.xml&coll=10> or <http://tinyurl.com/dqj8v>
Here's an interesting paper on Oracle's password hashing algorithm.
<http://www.sans.org/info/911/>
This fascinating research paper discusses the vulnerabilities of the
U.S. Navy Fleet Broadcast System in the 1980s. If you remember, John
Walker and cohorts handed the Soviets the secrets that allowed them to
eavesdrop on this system.
<http://www.fas.org/irp/eprint/heath.pdf>
MIT is setting up a 24/7 wireless tracking network:
<http://news.yahoo.com/s/ap/20051103/ap_on_hi_te/wireless_campus>
WiFi is certainly a good technology for this sort of massive
surveillance. It's an open and well-standardized technology that
allows anyone to go into the surveillance business. Bluetooth is a
similar technology: open and easy to use. Cell phone technologies, on
the other hand, are closed and proprietary. RFID might be the
preferred surveillance technology of the future, depending on how open
and standardized it becomes.
I think this instantaneous data grabbing system is a harbinger of the
future.
<http://www.cioinsight.com/article2/0,1397,1878051,00.asp>
Microsoft calls for a national privacy law. No, really. Microsoft is
doing better about privacy recently. Certainly the devil is in the
details, but this is a good start.
<http://www.schneier.com/blog/archives/2005/11/microsoft_calls.html>
Really good blog posting on national security letters, increasingly
used by the FBI to collect personal information without any judicial
oversight.
<http://talkleft.com/new_archives/013011.html>
And an excellent news article:
<http://www.washingtonpost.com/wp-dyn/content/article/2005/11/05/AR20051
10501366.html> or <http://tinyurl.com/7tgmv>
The ACLU has been actively litigating the legality of the National
Security Letters.
<http://www.aclu.org/NationalSecurity/NationalSecurity.cfm?ID=19345>
Now this is a surprise. Richard Clarke advised New York City to
perform those pointless subway searches. Reading the New York Times
article, it seems that his goal wasn't to deter terrorism but simply to
move it from the New York City subways to another target -- perhaps the
Boston subways.
<http://www.nytimes.com/2005/11/07/nyregion/07search.html>
A team at the German Federal Agency for Information Technology Security
has factored a 193-digit number. (Note that this is not a record; in
May a 200-digit number was factored But there's a cash prize
associated with this one.)
<http://mathworld.wolfram.com/news/2005-11-08/rsa-640/>
Sniffing passwords is both easy and fun:
<http://www.infoworld.com/article/05/11/04/45OPsecadvise_1.html>
I am interested in analyzing that password database. What percentage
of those passwords are English words? What percentage are in the
common password dictionaries? What percentage use mixed case, or
numbers, or punctuation? What's the frequency distribution of
different password lengths? Real password data is hard to come
by. There's an interesting research paper in that data.
Military use for silly string: to find trip wires.
<http://www.cockeyed.com/citizen/silly/silly.html>
My comments on a Business Week article on fraudulent stock transactions
over the Internet:
<http://www.schneier.com/blog/archives/2005/11/fraudulent_stoc.html>
<http://www.businessweek.com/technology/content/nov2005/tc20051103_56515
0.htm> or <http://tinyurl.com/bq92y>
Here's an Illinois bill that could make it illegal to own magnetic
strip readers:
<http://www.ilga.gov/legislation/billstatus.asp?DocNum=1565&GAID=8&GA=94
&DocTypeID=HB&LegID=16639&SessionID=50> or <http://tinyurl.com/d6j5e>
The Sky Posse is an organization, not affiliated with anyone official,
of people who vow to fight back in the event of an airplane
hijacking. Members wear cool-looking pins, made to resemble a Western
sheriff's badge, with the slogan "Ready to Roll." Kind of silly, but
probably harmless.
<http://www.skyposse.com/>
On the security of tin foil hats:
<http://people.csail.mit.edu/rahimi/helmet/>
And a rebuttal:
<http://zapatopi.net/blog/?post=200511112730.afdb_effectiveness>
A report that the CIA slipped software bugs to the Soviets in the 1980s:
<http://www.msnbc.msn.com/id/4394002>
Hans Bethe was one of the first nuclear scientists, a member of the
Manhattan Project, and a political activist. In a recent article about
him, there's a great quote: "Sometimes insistence on 100% security
actually impairs our security, while the bold decision -- though at the
time it seems to involve some risk -- will give us more security in the
long run."
<http://www.physicstoday.org/vol-58/iss-10/p52.html>
Metadata in Microsoft Office:
<http://www.schneier.com/blog/archives/2005/11/metadata_in_ms.html>
There's a new report from Sandia National Laboratories (written with
Lawrence Berkeley National Laboratory) titled "Guidelines to Improve
Airport Preparedness Against Chemical and Biological Terrorism." It's
classified, but there's an unclassified version available.
<http://www.sandia.gov/news-center/news-releases/2005/def-nonprolif-sec/
proact-guidelines.html>
<http://www.sandia.gov/news-center/news-releases/2005/images/unlsand-200
5-3237.pdf>
The NSA has a site for kids. Crypto Cat, Decipher Dog, and friends.
<http://www.nsa.gov/kids/>
** *** ***** ******* *********** *************
Sony Secretly Installs Rootkit on Computers
Mark Russinovich <a
href="http://www.sysinternals.com/blog/2005/10/sony-rootkits-and-digital
-rights.html">discovered</a> a rootkit on his system. After much
analysis, he discovered that the rootkit was installed as a part of the
DRM software linked with a CD he bought. The package cannot be
uninstalled. Even worse, the package actively cloaks itself from
process listings and the file system. So he posted about it on his
blog, and ended up creating a firestorm, and a soap opera.
Lots of news and links are on my blog posts:
<http://www.schneier.com/blog/archives/2005/11/sony_secretly_i_1.html>
<http://www.schneier.com/blog/archives/2005/11/more_on_sonys_d.html>
Russinovich's blog postings:
<http://www.sysinternals.com/blog/2005/10/sony-rootkits-and-digital-righ
ts.html> or <http://tinyurl.com/auyjl>
<http://www.sysinternals.com/blog/2005/11/sony-you-dont-reeeeaaaally-wan
t-to_09.html> or <http://tinyurl.com/bpr64>
Removing the rootkit kills Windows:
<http://www.theregister.co.uk/2005/11/01/sony_rootkit_drm/>
Washington Post news story:
<http://www.washingtonpost.com/wp-dyn/content/article/2005/11/02/AR20051
10202362.html> or <http://tinyurl.com/8htcf>
Sony lies about their rootkit: "This Service Pack removes the cloaking
technology component that has been recently discussed in a number of
articles published regarding the XCP Technology used on SONY BMG
content protected CDs. This component is not malicious and does not
compromise security. However to alleviate any concerns that users may
have about the program posing potential security vulnerabilities, this
update has been released to enable users to remove this component from
their computers." But their update does not remove the rootkit, it
just gets rid of the sys cloaking.
<http://cp.sonybmg.com/xcp/english/updates.html>
Ed Felton's comments:
<http://www.freedom-to-tinker.com/?p=921>
<http://www.freedom-to-tinker.com/?p=923>
<http://www.freedom-to-tinker.com/?p=924>
And you can use the rootkit to avoid World of Warcraft spyware.
<http://www.securityfocus.com/brief/34>
F-Secure makes a good point about how this sort of thing can seriously
affect the reliability of Windows:
<http://www.f-secure.com/weblog/#00000696>
Declan McCullagh has a good essay on the topic. There will be lawsuits.
<http://news.com.com/Why+they+say+spyware+is+good+for+you/2010-1071_3-59
34150.html> or <http://tinyurl.com/dmwpt>
Here's one:
<http://business.bostonherald.com/technologyNews/view.bg?articleid=11162
2> or <http://tinyurl.com/8s6gv>
The Italian police are getting involved.
<http://www.computerworld.com/securitytopics/security/story/0,10801,1060
64,00.html?source=NLT_PM&nid=106064> or <http://tinyurl.com/crgfj>
Here's a Trojan that uses Sony's rootkit to hide.
<http://www.theregister.co.uk/2005/11/10/sony_drm_trojan/>
Sony has temporarily halted production of CDs protected with this
technology.
<http://www.securityfocus.com/brief/45>
<http://www.cnn.com/2005/SHOWBIZ/Music/11/11/sony.copyprotection.ap/inde
x.html> or <http://tinyurl.com/a5gag>
Microsoft will update its security tools to detect and remove the
rootkit. That makes a lot of sense. If Windows crashes because of
this -- and others of this ilk -- Microsoft will be blamed.
<http://news.com.com/Microsoft+will+wipe+Sonys+rootkit/2100-1002_3-59490
41.html> or <http://tinyurl.com/bmw8g>
** *** ***** ******* *********** *************
DMCA Review
The Copyright Office of the U.S. Library of Congress is conducting its
required regular review of the anti-circumvention provisions of the
Digital Millennium Copyright Act. Comments can be submitted over the
Internet, and are due December 1st.
<http://www.copyright.gov/fedreg/2005/70fr57526.html>
Comment form:
<http://www.copyright.gov/1201/comment_forms>
Good information on the DMCA:
<http://www.eff.org/IP/DMCA/>
<http://www.epic.org/privacy/drm/>
<http://www.anti-dmca.org/>
** *** ***** ******* *********** *************
Counterpane News
Schneier is delivering the keynote at the InfoSecurity Conference in
New York on December 8th.
<http://www.infosecurityevent.com>
My password utility, Password Safe, in the news.
<http://www.washingtonpost.com/wp-dyn/content/article/2005/10/15/AR20051
01500178.html> or <http://tinyurl.com/a2afk>
Password Safe:
<http://www.schneier.com/passsafe.html>
Counterpane has published an analysis of the attack trends we see in
the course of security monitoring. We're watching something like 500
networks in 35 different countries, so it's pretty interesting.
<http://www.counterpane.com/pr-20051115.html>
<http://www.counterpane.com/cgi-bin/attack-trends2.cgi>
** *** ***** ******* *********** *************
Taser Cam
The manufacturer of Tasers, Taser International, Inc., is selling a
Taser Cam. The device mounts on the Taser and records -- both audio
and video -- whenever the weapon is turned on, regardless of whether
the weapon is fired.
It's the same idea as having cameras record all police interrogations,
or record all police-car stops. It helps protect the populace against
police abuse, and helps protect the police of accusations of abuse.
This is where cameras do good: when they lessen a power
imbalance. Imagine if they were continuously recording the actions of
elected officials -- when they were acting in their official capacity,
that is.
Of course, cameras are only as useful as their data. If critical
recordings are "lost," then there's no accountability. The system is
pretty kludgy, and the recording has to be downloaded to a computer
using a USB cable.
How soon before the cameras simply upload their recordings, in real
time, to some trusted vault somewhere?
<http://www.local6.com/news/5263731/detail.html>
<http://www.cnn.com/2005/EDUCATION/11/08/taser.cam.ap/index.html>
** *** ***** ******* *********** *************
A "Typical" Terrorist
A simply horrible lead sentence in a Manila Times story: "If you see a
man aged 17 to 35, wearing a ball cap, carrying a backpack, clutching a
cellular phone and acting uneasily, chances are he is a terrorist."
Let's see: Approximately 4.5 million people use the New York City
subway every day. Assume that the above profile fits 1% of them. Does
that mean that there are 25,000 terrorists riding the New York City
subways every single day? Seems unlikely.
The rest of the article gets better, but still....
<http://www.manilatimes.net/national/2005/oct/08/yehey/top_stories/20051
008top4.html> or <http://tinyurl.com/d9vqz>
** *** ***** ******* *********** *************
The Zotob Worm
If you'll forgive the possible comparison to hurricanes, Internet
epidemics are much like severe weather: they happen randomly, they
affect some segments of the population more than others, and your
previous preparation determines how effective your defense is.
Zotob was the first major worm outbreak since MyDoom in January 2004.
It happened quickly -- less than five days after Microsoft published a
critical security bulletin (its 39th of the year). Zotob's effects
varied greatly from organization to organization: some networks were
brought to their knees, while others didn't even notice.
The worm started spreading on Sunday, 14 August. Honestly, it wasn't
much of a big deal, but it got a lot of play in the press because it
hit several major news outlets, most notably CNN. If a news
organization is personally affected by something, it's much more likely
to report extensively on it. But my company, Counterpane Internet
Security, monitors more than 500 networks worldwide, and we didn't
think it was worth all the press coverage.
By the 17th, there were at least a dozen other worms that exploited the
same vulnerability, both Zotob variants and others that were completely
different. Most of them tried to recruit computers for bot networks,
and some of the different variants warred against each other --
stealing "owned" computers back and forth. If your network was
infected, it was a mess.
Two weeks later, the 18-year-old who wrote the original Zotob worm was
arrested, along with the 21-year-old who paid him to write it. It seems
likely the person who funded the worm's creation was not a hacker, but
rather a criminal looking to profit.
The nature of worms has changed in the past few years. Previously,
hackers looking for prestige or just wanting to cause damage were
responsible for most worms. Today, they're increasingly written or
commissioned by criminals. By taking over computers, worms can send
spam, launch denial-of-service extortion attacks, or search for
credit-card numbers and other personal information.
What could you have done beforehand to protect yourself against Zotob
and its kin? "Install the patch" is the obvious answer, but it's not
really a satisfactory one. There are simply too many patches. Although
a single computer user can easily set up patches to automatically
download and install -- at least Microsoft Windows system patches --
large corporate networks can't. Far too often, patches cause other
things to break.
It would be great to know which patches are actually important and
which ones just sound important. Before that weekend in August, the
patch that would have protected against Zotob was just another patch;
by Monday morning, it was the most important thing a sysadmin could do
to secure the network.
Microsoft had six new patches available on 9 August, three designated
as critical (including the one that Zotob used), one important, and two
moderate. Could you have guessed beforehand which one would have
actually been critical? With the next patch release, will you know
which ones you can put off and for which ones you need to drop
everything, test, and install across your network?
Given that it's impossible to know what's coming beforehand, how you
respond to an actual worm largely determines your defense's
effectiveness. You might need to respond quickly, and you most
certainly need to respond accurately. Because it's impossible to know
beforehand what the necessary response should be, you need a process
for that response. Employees come and go, so the only thing that
ensures a continuity of effective security is a process. You need
accurate and timely information to fuel this process. And finally, you
need experts to decipher the information, determine what to do, and
implement a solution.
The Zotob storm was both typical and unique. It started soon after the
vulnerability was published, but I don't think that made a difference.
Even worms that use six-month-old vulnerabilities find huge swaths of
the Internet unpatched. It was a surprise, but they all are.
This essay will appear in the November/December 2005 issue of IEEE
Security & Privacy.
** *** ***** ******* *********** *************
CRYPTO-GRAM is a free monthly newsletter providing summaries, analyses,
insights, and commentaries on security: computer and otherwise. You
can subscribe, unsubscribe, or change your address on the Web at
<http://www.schneier.com/crypto-gram.html>. Back issues are also
available at that URL.
Comments on CRYPTO-GRAM should be sent to
schneier@counterpane.com. Permission to print comments is assumed
unless otherwise stated. Comments may be edited for length and clarity.
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 the author of
the best sellers "Beyond Fear," "Secrets and Lies," and "Applied
Cryptography," and an inventor of the Blowfish and Twofish
algorithms. He is founder and CTO of Counterpane Internet Security
Inc., and is a member of the Advisory Board of the Electronic Privacy
Information Center (EPIC). He is a frequent writer and lecturer on
security topics. See <http://www.schneier.com>.
Counterpane is the world's leading protector of networked information -
the inventor of outsourced security monitoring and the foremost
authority on effective mitigation of emerging IT threats. Counterpane
protects networks for Fortune 1000 companies and governments
world-wide. See <http://www.counterpane.com>.
Crypto-Gram is a personal newsletter. Opinions expressed are not
necessarily those of Counterpane Internet Security, Inc.
Copyright (c) 2005 by Bruce Schneier.
-------------------------------------------------------
-- Joey Kelly < Minister of the Gospel | Linux Consultant > http://joeykelly.net "I may have invented it, but Bill made it famous." --- David Bradley, the IBM employee that invented CTRL-ALT-DEL
___________________
Nolug mailing list
nolug@nolug.org
This archive was generated by hypermail 2.2.0 : 12/19/08 EST