Entries Tagged "disclosure"

Page 9 of 11

Forge Your Own Boarding Pass

Last week Christopher Soghoian created a Fake Boarding Pass Generator website, allowing anyone to create a fake Northwest Airlines boarding pass: any name, airport, date, flight. This action got him visited by the FBI, who later came back, smashed open his front door, and seized his computers and other belongings. It resulted in calls for his arrest—the most visible by Rep. Edward Markey (D-Massachusetts)—who has since recanted. And it’s gotten him more publicity than he ever dreamed of.

All for demonstrating a known and obvious vulnerability in airport security involving boarding passes and IDs.

This vulnerability is nothing new. There was an article on CSOonline from February 2006. There was an article on Slate from February 2005. Sen. Chuck Schumer spoke about it as well. I wrote about it in the August 2003 issue of Crypto-Gram. It’s possible I was the first person to publish it, but I certainly wasn’t the first person to think of it.

It’s kind of obvious, really. If you can make a fake boarding pass, you can get through airport security with it. Big deal; we know.

You can also use a fake boarding pass to fly on someone else’s ticket. The trick is to have two boarding passes: one legitimate, in the name the reservation is under, and another phony one that matches the name on your photo ID. Use the fake boarding pass in your name to get through airport security, and the real ticket in someone else’s name to board the plane.

This means that a terrorist on the no-fly list can get on a plane: He buys a ticket in someone else’s name, perhaps using a stolen credit card, and uses his own photo ID and a fake ticket to get through airport security. Since the ticket is in an innocent’s name, it won’t raise a flag on the no-fly list.

You can also use a fake boarding pass instead of your real one if you have the “SSSS” mark and want to avoid secondary screening, or if you don’t have a ticket but want to get into the gate area.

Historically, forging a boarding pass was difficult. It required special paper and equipment. But since Alaska Airlines started the trend in 1999, most airlines now allow you to print your boarding pass using your home computer and bring it with you to the airport. This program was temporarily suspended after 9/11, but was quickly brought back because of pressure from the airlines. People who print the boarding passes at home can go directly to airport security, and that means fewer airline agents are required.

Airline websites generate boarding passes as graphics files, which means anyone with a little bit of skill can modify them in a program like Photoshop. All Soghoian’s website did was automate the process with a single airline’s boarding passes.

Soghoian claims that he wanted to demonstrate the vulnerability. You could argue that he went about it in a stupid way, but I don’t think what he did is substantively worse than what I wrote in 2003. Or what Schumer described in 2005. Why is it that the person who demonstrates the vulnerability is vilified while the person who describes it is ignored? Or, even worse, the organization that causes it is ignored? Why are we shooting the messenger instead of discussing the problem?

As I wrote in 2005: “The vulnerability is obvious, but the general concepts are subtle. There are three things to authenticate: the identity of the traveler, the boarding pass and the computer record. Think of them as three points on the triangle. Under the current system, the boarding pass is compared to the traveler’s identity document, and then the boarding pass is compared with the computer record. But because the identity document is never compared with the computer record—the third leg of the triangle—it’s possible to create two different boarding passes and have no one notice. That’s why the attack works.”

The way to fix it is equally obvious: Verify the accuracy of the boarding passes at the security checkpoints. If passengers had to scan their boarding passes as they went through screening, the computer could verify that the boarding pass already matched to the photo ID also matched the data in the computer. Close the authentication triangle and the vulnerability disappears.

But before we start spending time and money and Transportation Security Administration agents, let’s be honest with ourselves: The photo ID requirement is no more than security theater. Its only security purpose is to check names against the no-fly list, which would still be a joke even if it weren’t so easy to circumvent. Identification is not a useful security measure here.

Interestingly enough, while the photo ID requirement is presented as an antiterrorism security measure, it is really an airline-business security measure. It was first implemented after the explosion of TWA Flight 800 over the Atlantic in 1996. The government originally thought a terrorist bomb was responsible, but the explosion was later shown to be an accident.

Unlike every other airplane security measure—including reinforcing cockpit doors, which could have prevented 9/11—the airlines didn’t resist this one, because it solved a business problem: the resale of non-refundable tickets. Before the photo ID requirement, these tickets were regularly advertised in classified pages: “Round trip, New York to Los Angeles, 11/21-30, male, $100.” Since the airlines never checked IDs, anyone of the correct gender could use the ticket. Airlines hated that, and tried repeatedly to shut that market down. In 1996, the airlines were finally able to solve that problem and blame it on the FAA and terrorism.

So business is why we have the photo ID requirement in the first place, and business is why it’s so easy to circumvent it. Instead of going after someone who demonstrates an obvious flaw that is already public, let’s focus on the organizations that are actually responsible for this security failure and have failed to do anything about it for all these years. Where’s the TSA’s response to all this?

The problem is real, and the Department of Homeland Security and TSA should either fix the security or scrap the system. What we’ve got now is the worst security system of all: one that annoys everyone who is innocent while failing to catch the guilty.

This essay—my 30th for Wired.com—appeared today.

EDITED TO ADD (11/4): More news and commentary.

EDITED TO ADD (1/10): Great essay by Matt Blaze.

Posted on November 2, 2006 at 6:21 AM • View Comments

Voting Software and Secrecy

Here’s a quote from an elections official in Los Angeles:

“The software developed for InkaVote is proprietary software. All the software developed by vendors is proprietary. I think it’s odd that some people don’t want it to be proprietary. If you give people the open source code, they would have the directions on how to hack into it. We think the proprietary nature of the software is good for security.”

It’s funny, really. What she should be saying is something like: “I think it’s odd that everyone who has any expertise in computer security doesn’t want the software to be proprietary. Speaking as someone who knows nothing about computer security, I think that secrecy is an asset.” That’s a more realistic quote.

As I’ve said many times, secrecy is not the same as security. And in many cases, secrecy hurts security.

Posted on October 2, 2006 at 7:10 AM • View Comments

Faux Disclosure

Good essay on “faux disclosure”: disclosing a vulnerability without really disclosing it.

You’ve probably heard of full disclosure, the security philosophy that calls for making public all details of vulnerabilities. It has been the subject of debates among
researchers, vendors, and security firms. But the story that grabbed most of the headlines at the Black Hat Briefings in Las Vegas last week was based on a different type of disclosure. For lack of a better name, I’ll call it faux disclosure. Here’s why.

Security researchers Dave Maynor of ISS and Johnny Cache—a.k.a. Jon Ellch—demonstrated an exploit that allowed them to install a rootkit on an Apple laptop in less than a minute. Well, sort of; they showed a video of it, and also noted that they’d used a third-party Wi-Fi card in the demo of the exploit, rather than the MacBook’s internal Wi-Fi card. But they said that the exploit would work whether the third-party card—which they declined to identify—was inserted
in a Mac, Windows, or Linux laptop.

[…]

How is that for murky and non-transparent? The whole world is at risk—if the exploit is real—whenever the unidentified card is used. But they won’t say which card, although many sources presume the card is based on the Atheros chipset, which Apple employs.

It gets worse. Brian Krebs of the Washington Post, who first reported on the exploit, updated his original story and has reported that Maynor said, “Apple had leaned on Maynor and Ellch pretty hard not to make this an issue about the Mac drivers—mainly because Apple had not fixed the problem yet.”

That’s part of what is meant by full disclosure these days—giving the vendor a chance fix the vulnerability before letting the whole world know about it. That way, the thinking goes, the only people who get hurt by it are the people who get exploited by it. But damage to the responsible vendor’s image is mitigated somewhat, and many in the security business seem to think that damage control is more important than anything that might happen to any of the vendor’s customers.

Big deal. Publicly traded corporations like Apple and Microsoft and all the rest have been known to ignore ethics, morality, any consideration of right or wrong, or anything at all that might divert them from their ultimate goal: to maximize profits. Because of this,
some corporations only speak the truth when it is in their best interest. Otherwise, they lie or maintain silence.

Full disclosure is the only thing that forces vendors to fix security problems. The further we move away from full disclosure, the less incentive vendors have to fix problems and the more at-risk we all are.

Posted on August 14, 2006 at 1:41 PM • View Comments

A Month of Browser Bugs

To kick off his new Browser Fun blog, H.D. Moore began with “A Month of Browser Bugs”:

This blog will serve as a dumping ground for browser-based security research and vulnerability disclosure. To kick off this blog, we are announcing the Month of Browser Bugs (MoBB), where we will publish a new browser hack, every day, for the entire month of July. The hacks we publish are carefully chosen to demonstrate a concept without disclosing a direct path to remote code execution. Enjoy!

Thirty-one days, and thirty-one hacks later, the blog lists exploits against all the major browsers:

  • Internet Explorer: 25
  • Mozilla: 2
  • Safari: 2
  • Opera: 1
  • Konqueror: 1

My guess is that he could have gone on for another month without any problem, and possibly could produce a new browser bug a day indefinitely.

The moral here isn’t that IE is less secure than the other browsers, although I certainly believe that. The moral is that coding standards are so bad that security flaws are this common.

Eric Rescorla argues that it’s a waste of time to find and fix new security holes, because so many of them still remain and the software’s security isn’t improved. I think he has a point. (Note: this is not to say that it’s a waste of time to fix the security holes found and publicly exploited by the bad guys. The question Eric tries to answer is whether or not it is worth it for the security community to find new security holes.)

Another commentary is here.

Posted on August 3, 2006 at 1:53 PM • View Comments

Dangers of Reporting a Computer Vulnerability

This essay makes the case that there no way to safely report a computer vulnerability.

The first reason is that whenever you do something “unnecessary,” such as reporting a vulnerability, police wonder why, and how you found out. Police also wonders if you found one vulnerability, could you have found more and not reported them? Who did you disclose that information to? Did you get into the web site, and do anything there that you shouldn’t have? It’s normal for the police to think that way. They have to. Unfortunately, it makes it very uninteresting to report any problems.

A typical difficulty encountered by vulnerability researchers is that administrators or programmers often deny that a problem is exploitable or is of any consequence, and request a proof. This got Eric McCarty in trouble—the proof is automatically a proof that you breached the law, and can be used to prosecute you! Thankfully, the administrators of the web site believed our report without trapping us by requesting a proof in the form of an exploit and fixed it in record time. We could have been in trouble if we had believed that a request for a proof was an authorization to perform penetration testing. I believe that I would have requested a signed authorization before doing it, but it is easy to imagine a well-meaning student being not as cautious (or I could have forgotten to request the written authorization, or they could have refused to provide it…). Because the vulnerability was fixed in record time, it also protected us from being accused of the subsequent break-in, which happened after the vulnerability was fixed, and therefore had to use some other means. If there had been an overlap in time, we could have become suspects.

Interesting essay, and interesting comments. And here’s an article on the essay.

Remember, full disclosure is the best tool we have to improve security. It’s an old argument, and I wrote about it way back in 2001. If people can’t report security vulnerabilities, then vendors won’t fix them.

EDITED TO ADD (5/26): Robert Lemos on “Ethics and the Eric McCarty Case.”

Posted on May 26, 2006 at 7:35 AM • View Comments

Major Vulnerability Found in Diebold Election Machines

This is a big deal:

Elections officials in several states are scrambling to understand and limit the risk from a “dangerous” security hole found in Diebold Election Systems Inc.’s ATM-like touch-screen voting machines.

The hole is considered more worrisome than most security problems discovered on modern voting machines, such as weak encryption, easily pickable locks and use of the same, weak password nationwide.

Armed with a little basic knowledge of Diebold voting systems and a standard component available at any computer store, someone with a minute or two of access to a Diebold touch screen could load virtually any software into the machine and disable it, redistribute votes or alter its performance in myriad ways.

“This one is worse than any of the others I’ve seen. It’s more fundamental,” said Douglas Jones, a University of Iowa computer scientist and veteran voting-system examiner for the state of Iowa.

“In the other ones, we’ve been arguing about the security of the locks on the front door,” Jones said. “Now we find that there’s no back door. This is the kind of thing where if the states don’t get out in front of the hackers, there’s a real threat.”

This newspaper is withholding some details of the vulnerability at the request of several elections officials and scientists, partly because exploiting it is so simple and the tools for doing so are widely available.

[…]

Scientists said Diebold appeared to have opened the hole by making it as easy as possible to upgrade the software inside its machines. The result, said Iowa’s Jones, is a violation of federal voting system rules.

“All of us who have heard the technical details of this are really shocked. It defies reason that anyone who works with security would tolerate this design,” he said.

The immediate solution to this problem isn’t a patch. What that article refers to is election officials ensuring that they are running the “trusted” build of the software done at the federal labs and stored at the NSRL, just in case someone installed something bad in the meantime.

This article compares the security of electronic voting machines with the security of electronic slot machines. (My essay on the security of elections and voting machines.)

EDITED TO ADD (5/11): The redacted report is available.

Posted on May 11, 2006 at 1:08 PM • View Comments

Identity-Theft Disclosure Laws

California was the first state to pass a law requiring companies that keep personal data to disclose when that data is lost or stolen. Since then, many states have followed suit. Now Congress is debating federal legislation that would do the same thing nationwide.

Except that it won’t do the same thing: The federal bill has become so watered down that it won’t be very effective. I would still be in favor of it—a poor federal law is better than none—if it didn’t also pre-empt more-effective state laws, which makes it a net loss.

Identity theft is the fastest-growing area of crime. It’s badly named—your identity is the one thing that cannot be stolen—and is better thought of as fraud by impersonation. A criminal collects enough personal information about you to be able to impersonate you to banks, credit card companies, brokerage houses, etc. Posing as you, he steals your money, or takes a destructive joyride on your good credit.

Many companies keep large databases of personal data that is useful to these fraudsters. But because the companies don’t shoulder the cost of the fraud, they’re not economically motivated to secure those databases very well. In fact, if your personal data is stolen from their databases, they would much rather not even tell you: Why deal with the bad publicity?

Disclosure laws force companies to make these security breaches public. This is a good idea for three reasons. One, it is good security practice to notify potential identity theft victims that their personal information has been lost or stolen. Two, statistics on actual data thefts are valuable for research purposes. And three, the potential cost of the notification and the associated bad publicity naturally leads companies to spend more money on protecting personal information—or to refrain from collecting it in the first place.

Think of it as public shaming. Companies will spend money to avoid the PR costs of this shaming, and security will improve. In economic terms, the law reduces the externalities and forces companies to deal with the true costs of these data breaches.

This public shaming needs the cooperation of the press and, unfortunately, there’s an attenuation effect going on. The first major breach after California passed its disclosure law—SB1386—was in February 2005, when ChoicePoint sold personal data on 145,000 people to criminals. The event was all over the news, and ChoicePoint was shamed into improving its security.

Then LexisNexis exposed personal data on 300,000 individuals. And Citigroup lost data on 3.9 million individuals. SB1386 worked; the only reason we knew about these security breaches was because of the law. But the breaches came in increasing numbers, and in larger quantities. After a while, it was no longer news. And when the press stopped reporting, the “cost” of these breaches to the companies declined.

Today, the only real cost that remains is the cost of notifying customers and issuing replacement cards. It costs banks about $10 to issue a new card, and that’s money they would much rather not have to spend. This is the agenda they brought to the federal bill, cleverly titled the Data Accountability and Trust Act, or DATA.

Lobbyists attacked the legislation in two ways. First, they went after the definition of personal information. Only the exposure of very specific information requires disclosure. For example, the theft of a database that contained people’s first initial, middle name, last name, Social Security number, bank account number, address, phone number, date of birth, mother’s maiden name and password would not have to be disclosed, because “personal information” is defined as “an individual’s first and last name in combination with …” certain other personal data.

Second, lobbyists went after the definition of “breach of security.” The latest version of the bill reads: “The term ‘breach of security’ means the unauthorized acquisition of data in electronic form containing personal information that establishes a reasonable basis to conclude that there is a significant risk of identity theft to the individuals to whom the personal information relates.”

Get that? If a company loses a backup tape containing millions of individuals’ personal information, it doesn’t have to disclose if it believes there is no “significant risk of identity theft.” If it leaves a database exposed, and has absolutely no audit logs of who accessed that database, it could claim it has no “reasonable basis” to conclude there is a significant risk. Actually, the company could point to a study that showed the probability of fraud to someone who has been the victim of this kind of data loss to be less than 1 in 1,000—which is not a “significant risk”—and then not disclose the data breach at all.

Even worse, this federal law pre-empts the 23 existing state laws—and others being considered—many of which contain stronger individual protections. So while DATA might look like a law protecting consumers nationwide, it is actually a law protecting companies with large databases from state laws protecting consumers.

So in its current form, this legislation would make things worse, not better.

Of course, things are in flux. They’re always in flux. The language of the bill has changed regularly over the past year, as various committees got their hands on it. There’s also another bill, HR3997, which is even worse. And even if something passes, it has to be reconciled with whatever the Senate passes, and then voted on again. So no one really knows what the final language will look like.

But the devil is in the details, and the only way to protect us from lobbyists tinkering with the details is to ensure that the federal bill does not pre-empt any state bills: that the federal law is a minimum, but that states can require more.

That said, disclosure is important, but it’s not going to solve identity theft. As I’ve written previously, the reason theft of personal information is so common is that the data is so valuable. The way to mitigate the risk of fraud due to impersonation is not to make personal information harder to steal, it’s to make it harder to use.

Disclosure laws only deal with the economic externality of data brokers protecting your personal information. What we really need are laws prohibiting credit card companies and other financial institutions from granting credit to someone using your name with only a minimum of authentication.

But until that happens, we can at least hope that Congress will refrain from passing bad bills that override good state laws—and helping criminals in the process.

This essay originally appeared on Wired.com.

EDITED TO ADD (4/20): Here’s a comparison of state disclosure laws.

Posted on April 20, 2006 at 8:11 AM • View Comments

Writing about IEDs

Really good article by a reporter who has been covering improvised explosive devices in Iraq:

Last summer, a U.S. Colonel in Baghdad told me that I was America’s enemy, or very close to it. For months, I had been covering the U.S. military’s efforts to deal with the threat of IEDs, improvised explosive devices. And my writing, he told me, was going too far—especially this January 2005 Wired News story, in which I described some of the Pentagon’s more exotic attempts to counter these bombs.

None of the material in the story—the stuff about microwave blasters or radio frequency jammers—was classified, he admitted. Most of it had been taken from open source materials. And many of the systems were years and years from being fielded. But by bundling it all together, I was doing a “world class job of doing the enemy’s research for him, for free.” So watch your step, he said, as I went back to my ride-alongs with the Baghdad Bomb Squad—the American soldiers defusing IEDs in the area.

Today, I hear that the President and the Pentagon’s higher-ups are trotting out the same argument. “News coverage of this topic has provided a rich source of information for the enemy, and we inadvertently contribute to our enemies’ collection efforts through our responses to media interest,” states a draft Defense Department memo, obtained by Inside Defense. “Individual pieces of information, though possibly insignificant taken alone, when aggregated provide robust information about our capabilities and weaknesses.”

In other words, Al Qaeda hasn’t discovered how to Google, yet. Don’t help ’em out.

Posted on March 20, 2006 at 11:53 AM • View Comments

Huge Vulnerability in GPG

GPG is an open-source version of the PGP e-mail encryption protocol. Recently, a very serious vulnerability was discovered in the software: given a signed e-mail message, you can modify the message—specifically, you can prepend or append arbitrary data—without disturbing the signature verification.

It appears this bug has existed for years without anybody finding it.

Moral: Open source does not necessarily mean “fewer bugs.” I wrote about this back in 1999.

UPDATED TO ADD (3/13): This bug is fixed in Version 1.4.2.2. Users should upgrade immediately.

Posted on March 13, 2006 at 6:33 AM • View Comments

Vulnerability Disclosure Survey

If you have a moment, take this survey.

This research project seeks to understand how secrecy and openness can be balanced in the analysis and alerting of security vulnerabilities to protect critical national infrastructures. To answer this question, this thesis will investigate:

  1. How vulnerabilities are analyzed, understood and managed throughout the vulnerability lifecycle process.
  2. The ways that the critical infrastructure security community interact to exchange security-related information and the outcome of such interactions to date.
  3. The nature of and influences upon collaboration and information-sharing within the critical infrastructure protection community, particularly those handling internet security concerns.
  4. The relationship between secrecy and openness in providing and exchanging security-related information.

This looks interesting.

Posted on January 25, 2006 at 8:24 AM • View Comments

1 … 7 8 9 10 11

Sidebar photo of Bruce Schneier by Joe MacInnis.