November 24, 2024

Posts Comments

MySpace Photos Leaked; Payback for Not Fixing Flaw?

January 28, 2008 by

Last week an anonymous person published a file containing half a million images, many of which had been gathered from private profiles on MySpace. This may be the most serious privacy breach yet at MySpace. Kevin Poulsen’s story at Wired News implies that the leak may have been deliberate payback for MySpace failing to fix the vulnerability that allowed the leaks.

“I think the greatest motivator was simply to prove that it could be done,” file creator “DMaul” says in an e-mail interview. “I made it public that I was saving these images. However, I am certain there are mischievous individuals using these hacks for nefarious purposes.”

The MySpace hole surfaced last fall, and it was quickly seized upon by the self-described pedophiles and ordinary voyeurs who used it, among other things, to target 14- and 15-year-old users who’d caught their eye online. A YouTube video showed how to use the bug to retrieve private profile photos. The bug also spawned a number of ad-supported sites that made it easy to retrieve photos. One such site reported more than 77,000 queries before MySpace closed the hole last Friday following Wired News’ report.

…

MySpace plugged a a href=”http://grownupgeek.blogspot.com/2006/08/myspace-closes-giant-security-hole.html”>similar security hole in August 2006 when it made the front page of Digg, four months after it surfaced.

The implication here, not quite stated, is that DMaul was trying to draw attention to the flaw in order to force MySpace to fix it. If this is what it took to get MySpace to fix the flaw, this story reflects very badly on MySpace.

Anyone who has discovered security flaws in commercial products knows that companies react to flaws in two distinct ways. Smart companies react constructively: they’re not happy about the flaws or the subsequent PR fallout, but they acknowledge the truth and work in their customers’ interest to fix problems promptly. Other companies deny problems and delay addressing them, treating security flaws solely as PR problems rather than real risks.

Smart companies have learned that a constructive response minimizes the long-run PR damage and, not coincidentally, protects customers. But some companies seem to lock themselves into the deny-delay strategy.

Now suppose you know that a company’s product has a flaw that is endangering its customers, and the company is denying and delaying. There is something you can do that will force them to fix the problem – you can arrange an attention-grabbing demonstration that will show customers (and the press) that the risk is real. All you have to do is exploit the flaw yourself, get a bunch of private data, and release it. Which is pretty much what DMaul did.

To be clear, I’m not endorsing this course of action. I’m just pointing out why someone might find it attractive despite the obvious ethical objections.

The really interesting aspect of Poulsen’s article is that he doesn’t quite connect the dots and say that DMaul meant to punish MySpace. But Poulsen is savvy enough that he probably wouldn’t have missed the implication either, and he could have written the article to avoid it had he wanted to. Maybe I’m reading too much into the article, but I can’t help suspecting that DMaul was trying to punish MySpace for its lax security.

Filed Under: Uncategorized Tagged With: , ,

New $2B Dutch Transport Card is Insecure

January 21, 2008 by

The new Dutch transit card system, on which $2 billion has been spent, was recently shown by researchers to be insecure. Three attacks have been announced by separate research groups. Let’s look at what went wrong and why.

The system, known as OV-chipkaart, uses contactless smart cards, a technology that allows small digital cards to communicate by radio over short distances (i.e. centimeters or inches) with reader devices. Riders would carry either a disposable paper card or a more permanent plastic card. Riders would “charge up” a card by making a payment, and the card would keep track of the remaining balance. The card would be swiped past the turnstile on entry and exit from the transport system, where a reader device would authenticate the card and cause the card to deduct the proper fare for each ride.

The disposable and plastic cards use different technologies. The disposable card, called Mifare Ultralight, is small, light, and inexpensive. The reusable plastic card, Mifare Classic, uses more sophisticated technologies.

The first attack, published in July 2007, came from Pieter Sieckerman and Maurits van der Schee of the University of Amsterdam, who found vulnerabilities in the Ultralight system. Their main attacks manipulated Ultralight cards, for example by “rewinding” a card to a previous state so it could be re-used. These attacks looked fixable by changing the system’s software, and Sieckerman and van der Schee described the necessary fixes. But it was also evident that a cleverly constructed counterfeit Ultralight card would be able to defeat the system in a manner that would be very difficult to defense.

The fundamental security problem with the disposable Ultralight card is that it doesn’t use cryptography, so the card cannot keep any secrets from an attacker. An attacker who can read a card (e.g., by using standard equipment to emulate a card reader) can know exactly what information is stored on the card, and therefore can make another device that will behave identically to the card. Except, of course, that the attacker’s device can always return itself to the “fully funded” state. Roel Verdult of Raboud University implemented this “cloning” attack and demonstrated it on Dutch television, leading to the recent uproar.

The plastic Mifare Classic card does use cryptography: legitimate cards contain secret keys that they use to authenticate themselves to readers. So attackers cannot straightforwardly clone a card. Mifare Classic was designed to use a secret encryption algorithm.

Karsten Nohl, “Starbug,” and Henryk Plötz announced an attack that involved opening up a Mifare Classic card and capturing a high-resolution image of the circuitry, which they then used to reverse-engineer the cryptographic algorithm. They didn’t publish the algorithm, but their work shows that a real attacker could get the algorithm too.

Unmasking of the algorithm should have been no problem, had the system been engineered well. Kerckhoffs’s Principle, one of the bedrock maxims of cryptography, says that security should never rely on keeping an algorithm secret. It’s okay to have a secret key, if the key is randomly chosen and can be changed when needed, but you should never bank on an algorithm remaining secret.

Unfortunately the designers of Mifare Classic did not follow this principle. Instead, they chose to combine a secret algorithm with a relatively short 48-bit key. This is a problem because once you know the algorithm it’s possible for an attacker to search the entire 48-bit key space, and therefore to forge cards, in a matter or days or weeks. With 48 key bits, there are only about 280 trillion possible keys, which sounds like a lot to the person on the street but isn’t much of a barrier to today’s computers.

Now the Dutch authorities have a mess on their hands. About $2 billion have been invested in this project, but serious fraud seems likely if it is deployed as designed. This kind of disaster would have been less likely had the design process been more open. Secrecy was not only an engineering mistake (violating Kerckhoffs’s Principle) but also a policy mistake, as it allowed the project to get so far along before independent analysts had a chance to critique it. A more open process, like the one the U.S. government used in choosing the Advanced Encryption Standard (AES) would have been safer. Governments seem to have a hard time understanding that openness can make you more secure.

Filed Under: Uncategorized Tagged With:

Second Life Welcomes Bank Regulators

January 11, 2008 by

Linden Lab, the company that runs the popular virtual world Second Life, announced Tuesday that all in-world “banks” must now be registered with real-world banking regulators:

As of January 22, 2008, it will be prohibited to offer interest or any direct return on an investment (whether in L$ or other currency) from any object, such as an ATM, located in Second Life, without proof of an applicable government registration statement or financial institution charter. We’re implementing this policy after reviewing Resident complaints, banking activities, and the law, and we’re doing it to protect our Residents and the integrity of our economy.

This is a significant step. Thus far Second Life, like other virtual worlds, has tried to avoid entanglement with heavyweight real-world regulatory agencies. Now they are welcoming banking regulation. The reason is simple: unregulated “banks” were out of control.

Since the collapse of Ginko Financial in August 2007, Linden Lab has received complaints about several in-world “banks” defaulting on their promises. These banks often promise unusually high rates of L$ return, reaching 20, 40, or even 60 percent annualized.

Usually, we don’t step in the middle of Resident-to-Resident conduct – letting Residents decide how to act, live, or play in Second Life.

But these “banks” have brought unique and substantial risks to Second Life, and we feel it’s our duty to step in. Offering unsustainably high interest rates, they are in most cases doomed to collapse – leaving upset “depositors” with nothing to show for their investments. As these activities grow, they become more likely to lead to destabilization of the virtual economy. At least as important, the legal and regulatory framework of these non-chartered, unregistered banks is unclear, i.e., what their duties are when they offer “interest” or “investments.”

This was inevitable, given the ever-growing connections between the virtual economy of Second Life and the real-world economy. In-world Linden Dollars are exchangeable for real-world dollars, so financial crime in Second Life can make you rich in the real world. Linden doesn’t have the processes in place to license “banks” or investigate problems. Nor does it have the enforcement muscle to put bad guys in jail.

Expect this trend to continue. As virtual world “games” are played for higher and higher stakes, the regulatory power of national governments will look more and more necessary.

Filed Under: Uncategorized Tagged With: , ,

Latest voting system analysis from California

December 3, 2007 by

This summer, the California Secretary of State commissioned a first-ever “Top to Bottom Review” of all the electronic voting systems used in the state. In August, the results of the first round of review were published, finding significant security vulnerabilities and a variety of other problems with the three vendors reviewed at the time. (See the Freedom to Tinker coverage for additional details.) The ES&S InkaVote Plus system, used in Los Angeles County, wasn’t included in this particular review. (The InkaVote is apparently unrelated to the ES&S iVotronic systems used elsewhere in the U.S.) The reports on InkaVote are now public.

(Disclosure: I was a co-author of the Hart InterCivic source code report, released by the California Secretary of State in August. I was uninvolved in the current round of investigation and have no inside information about this work.)

First, it’s worth a moment to describe what InkaVote is actually all about.  It’s essentially a precinct-based optical-scan paper ballot system, with a template-like device, comparable to the Votomatic punch-card systems.  As such, even if the tabulation computers are completely compromised, the paper ballots remain behind with the potential for being retabulated, whether mechanically or by hand.

The InkaVote reports represent work done by a commercial firm, atsec, whose primary business is performing security evaluation against a variety of standards, such as FIPS-140 or the ISO Common Criteria. The InkaVote reports are quite short (or, at least the public reports are short). In effect, we only get to see the high-level bullet-points rather than detailed explanations of what they found. Furthermore, their analysis was apparently compressed to an impossible two week period, meaning there are likely to be additional issues that exist but were not discovered by virtue of the lack of time. Despite this, we still get a strong sense of how vulnerable these systems are.

From the source code report:

The documentation provided by the vendor does not contain any test procedure description; rather, it provides only a very abstract description of areas to be tested. The document mentions test cases and test tools, but these have not been submitted as part of the TDP and could not be considered for this review. The provided documentation does not show evidence of “conducting of tests at every level of the software structure”. The TDP and source code did not contain unit tests, or any evidence that the modules were developed in such a way that program components were tested in isolation. The vendor documentation contains a description of cryptographic algorithms that is inconsistent with standard practices and represented a serious vulnerability. No vulnerability assessment was made as part of the documentation review because the attack approach could not be identified based on the documentation alone. (The source review identified additional specific vulnerabilities related to encryption).

This is consistent, for better or for worse, with what we’ve seen from the other vendors.  Given that, security vulnerabilities are practically a given. So, what kinds of vulnerabilities were found?

In the area of cryptography and key management, multiple potential and actual vulnerabilities were identified, including inappropriate use of symmetric cryptography for authenticity checking (A.8), use of a very weak homebrewed cipher for the master key algorithm (A.7), and key generation with artificially low entropy which facilitates brute force attacks (A.6). In addition, the code and comments indicated that a hash (checksum) method that is suitable only for detecting accidental corruption is used inappropriately with the claimed intent of detecting malicious tampering. The Red Team has demonstrated that due to the flawed encryption mechanisms a fake election definition CD can be produced that appears genuine, see Red Team report, section A.15.

106 instances were identified of SQL statements embedded in the code with no evidence of sanitation of the data before it is added to the SQL statement. It is considered a bad practice to build the SQL statements at runtime; the preferred method is to use predefined SQL statements using bound variables. A specific potential vulnerability was found and documented in A.10, SQL Injection.

Ahh, lovely (or, I should say, oy gevaldik). Curiously, the InkaVote tabulation application appears to have been written in Java – a good thing, because it eliminates the possibility of buffer overflows. Nonetheless, writing this software in a “safe” language is insufficient to yield a secure system.

The reviewer noted the following items as impediments to an effective security analysis of the system:

  • Lack of design documentation at appropriate levels of detail.
  • Design does not use privilege separation, so all code in the entire application is potentially security critical.
  • Unhelpful or misleading comments in the code.
  • Potentially complex data flow due to exception handling.
  • Subjectively, large amount of source code compared to the functionality implemented.

The code constructs used were generally straightforward and easy to follow on a local level. However, the lack of design documentation made it difficult to globally analyze the system.

It’s clear that none of the voting system vendors that have been reviewed so far have had the engineering mandate (or the engineering talent) to build secure software systems that are suitably designed to resist threats that are reasonable to expect in an election setting. Instead, these vendors have produced systems that are “good enough” to sell, relying on external tamper-resistance mechanisms and human procedures. The Red Team report offers some insight into the value of these kinds of mitigations:

In the physical security testing, the wire and tamper proof paper seals were easily removed without damage to the seals using simple household chemicals and tools and could be replaced without detection (Ref item A.1 in the Summary Table). The tamper proof paper seals were designed to show evidence of removal and did so if simply peeled off but simple household solvents could be used to remove the seal unharmed to be replaced later with no evidence that it had been removed. Once the seals are bypassed, simple tools or easy modifications to simple tools could be used to access the computer and its components (Ref A.2 in summary). The key lock for the Transfer Device was unlocked using a common office item without the special ‘key’ and the seal removed. The USB port may then be used to attach a USB memory device which can be used in as part of other attacks to gain control of the system. The keyboard connector for the Audio Ballot unit was used to attach a standard keyboard which was then used to get access to the operating system (Ref A.10 in Summary) without reopening the computer.

The seal used to secure the PBC head to the ballot box provided some protection but the InkaVote Plus Manual (UDEL) provides instructions for installing the seal that, if followed, will allow the seal to be opened without breaking it (Ref A.3 in the Summary Table). However, even if the seals are attached correctly, there was enough play and movement in the housing that it was possible to lift the PBC head unit out of the way and insert or remove ballots (removal was more difficult but possible). [Note that best practices in the polling place which were not considered in the security test include steps that significantly reduce the risk of this attack succeeding but this weakness still needs to be rectified.]

I’ll leave it as an exercise to the reader to determine what the “household solvents” or “common office item” must be.

Filed Under: Other Topics, Privacy & Security Tagged With: ,

Further adventures in personal credit

November 20, 2007 by

In our last installment, I described how one of the mortgage vendors who I was considering for the loan for my new home failed to trigger the credit alerting mechanism (Debix) to which I was signed up. Since then, I’ve learned several interesting facts. First, the way that Debix operates is that they insert a line into your credit reports which says, in effect, “you, the reader of this line, are required to call this 1-800 telephone number, prior to granting credit based on what you see in this report.” That 800-number finds its way to Debix, where a robot answers the phone and asks the human who called it for their name/organization, and the purpose of the request. Then, the Debix robot calls up their customer and asks permission to authorize the request, playing back the recordings made earlier.

The only thing that makes this “mandatory” is a recent law (sorry, I don’t have the citation handy) which specifies how lenders and such are required to act when they see one of these alerts in a credit report. The mechanism, aside from legal requirements, is otherwise used at the discretion of a human loan officer. This leads me to wonder whether or not the mechanism works when there isn’t a human loan officer involved. I may just need to head over to some big box store and purchase myself something with an in-store instant-approval credit card, just to see what happens. (With my new house will inevitably come a number of non-trivial expenses, and oh what great savings I can get with those insta-credit cards!)

So does the mechanism work? Yesterday morning, as I was getting into the car to go to work, my cell phone rang with an 800-number as the caller-ID. “Hello?” It was the Debix robot, asking for my approval. Debix played a recording of an apparently puzzled loan officer who identified herself as being from the bank that, indeed, I’m using for my loan. Well that’s good. Could the loan officer have been lying? Unlikely. An identity thief isn’t really the one who gets to see the 800-number. It’s the loan officer of the bank that the identity thief is trying to defraud who then makes the call. That means our prospective thief would need to guess the proper bank to use that would fool me into giving my okay. Given the number of choices, the odds of the thief nailing it on the first try are pretty low. (Unless our prospective thief is clever enough to have identified a bank that’s too lazy to follow the proper procedure and call the 800-number; more on this below).

A side-effect of my last post was that it got noticed by some people inside Debix and I ended up spending some quality time with one of their people on the telephone.  They were quite interested in my experiences.  They also told me, assuming everything is working right, that there will be some additional authentication hoops that the lender is (legally) mandated to jump through between now and when they actually write out the big check. Our closing date is next week, Friday, so I should have one more post when it’s all over to describe how all of that worked in the end.

Further reading: The New York Times recently had an article (“In ID Theft, Some Victims See an Opportunity“, November 16, 2007) discussing Debix and several other companies competing in the same market. Here’s an interesting quote:

Among its peers, LifeLock has attracted the most attention — much of it negative. In radio and television ads, Todd Davis, chief executive of LifeLock, gives out his Social Security number to demonstrate his faith in the service. As a result, he has been hit with repeated identity theft attacks, including one successful effort this summer in which a check-cashing firm gave out a $500 loan to a Texas fraudster without ever checking Mr. Davis’s credit report.

Sure enough, if you go to LifeLock’s home page, you see Mr. Davis’s social security number, right up front. And, unsurprisingly, he fell victim because, indeed, fraudsters identified a loan organization that didn’t follow the (legally) mandated protocol.

How do we solve the problem? Legally mandated protocols need to become technically mandatory protocols. The sort of credit alerts placed by Debix, LifeLock, and others need to be more than just a line in the consumer’s credit file. Instead, the big-3 credit bureaus need to be (legally) required not to divulge anything beyond the credit-protection vendor’s 800-number without the explicit (technical) permission of the vendor (on behalf of the user). Doing this properly would require the credit bureaus to standardize and implement a suitable Internet-based API with all the right sorts of crypto authentication and so forth – nothing technically difficult about that. Legally, I’d imagine they’d put up more of a fight, since they may not like these startups getting in the way of their business.

The place where the technical difficulty would ramp up is that the instant-credit-offering big-box stores would want to automate their side of the phone robot conversation. That would then require all these little startups to standardize their own APIs, which seems difficult when they’re all still busily inventing their own business models.

(Sidebar: I set up this Debix thing months ago. Then I get a phone call, out of the blue, that asked me to remember my PIN. Momentary panic: what PIN did I use? Same as the four-digit one I use for my bank ATM? Same as the six-digit one I uses for my investment broker? Same as the four-digit one used by my preferred airline’s frequent flyer web site which I can’t seem to change? Anyway, I guessed right. I’d love to know how many people forget.)

Filed Under: Uncategorized Tagged With: ,