MD2: hash-collision scare of the day

Overshadowed by the far more serious X509 parsing vulnerabilities disclosed at BlackHat, one of the problems noted by Dan Kaminsky et al. was the existence of an MD2-signed root certificate.

On the surface it looks bad. If MD2 preimage collision is possible, an enterprising attacker could forge other certificates chaining up to this one, and “transfer” the signature from the root to the bogus certificate, complements of the MD2 collision. Root certificates are notoriously difficult to update– Verisign can not afford (for business reasons, even if it is the “right thing” for the Internet) to risk revoking all certificates chaining up to the root. Re-publishing the root signed with a better hash function is a noop: the existing signature will not be invalidated. Only option is to not trust any certificate signed with MD2 except for the roots.

But looked from another perspective, the MD2 problem is tempest in a teapot. Luckily no CA is using MD2 to issue new certificates. (At least as far as anyone can determine– CA incompetence is generally unbounded.) This is important because the MD5 forgery from last December depended on a bone-headed CA continuing to use MD5 to sign new certificate requests. That means a second preimage collision is necessary; simple birthday attacks will not work. Finding a second message that hashes to a given one is a much harder problem than finding two meaningful, but partially unconstrained messages that collide.

Eager to join in the fray against PKI, the researchers point to a recent result, An improved preimage attack on MD2, to argue that such a possibility is indeed around the corner. It turns out the feasibility of this attack and the 0wnership of MD2 was slightly exaggerated, to paraphrase Mark Twain. The paper in fact does quote 2**73 applications of MD2 hash function as the amount of time required to find a second pre-image. This is an order of magnitude above what any previous brute-force attack has succeeded in breaking but Moore’s law can fix that. What the paraphrase seems to have neglected is a far more severe resource constraint, stated bluntly in the original paper and mysteriously neglected in the Kaminsky et al summary: the attack also requires 2**73 bytes of space. Outside the NSA nobody likely has this type of storage lying around. None of the existing distributed cryptographic attacks have come anywhere near this limit– in fact most of them made virtually no demands on space from participants. To put this in context, if one hundred million people were participating, each would have to dedicate more than a thousand terabytes of disk space. Not happening. This does not even take into account the communication and network overhead now required between the different users each holding one fragment of this massive table as they need to query other fragments.

CP

New York Times badly confused on identity management

Goodbye Passwords is that rare misstep form the otherwise consistently solid Digital Domain section in the Sunday NYT: confused, misinformed and way off base. Among the several muddled arguments, four of them stand out:

1. Equating OpenID to passwords.

“OpenID offers, at best, a little convenience, and ignores the security vulnerability inherent in the process of typing a password into someone else’s Web site.”

Minor factual error: actually the password is not being typed into a random website. It is supposed to be provided only to the website where the identity was originally created, not the website where it is being used. But the general difficulty of determining whether one indeed starting at the authentic site instead of a fraudulent replace– especially when the user has been sent there by the “someone else’s Web site” in question leads to the standard critique of OpenID as increasing phishing risks.

Major factual error: OpenID is a federation standard, not a new user authentication approach. It does not mandate passwords or any other scheme for verifying identity. Open ID 2.0 specification is loud and clear on this point:

“Methods of identifying authorized end users and obtaining approval to return an OpenID Authentication assertion are beyond the scope of this specification.”

That means the identity provider can choose to use good old-fashioned passwords, smart-cards, biometrics or experimental approaches such as reading tea-leaves to authenticate the user; OpenID is silent on this. In fact one of the more hyped extensions to the protocol, added at the urging of MSFT which has been desperately trying to promote CardSpace, is a way for signaling to websites that the user authenticated with credentials resistant to phishing– Infocards in the original vision that carved out this niche case, but also more generally strong authentication mechanisms such as PKI capable smart-cards.

2. Narrow definition of single sign-on:

OpenID promotes “Single Sign-On”: with it, logging on to one OpenID Web site with one password will grant entrance during that session to all Web sites that accept OpenID credentials.

In the most general sense, single sign-on refers to one identity being valid for accessing multiple systems. This is in contrast to the current state of affairs on the web: most websites have their own notions of user identities, requiring users to create a new account. Each account is valid at exactly one website and not recognized anywhere else. Single sign-on (“federation” using the fashionable term) is about merging these disconnected islands of identity such that the scope of an identity can extend beyond that one site.

Quick peek at the Wikipedia entry would have hinted that SSO is not tied to passwords. So it comes as surprise that a Microsoft architect is quoted as criticizing SSO. Cardspace is an instance of single sign-on: the vision calls for one identity held by the user’s machine to be usable for logging into any number of websites. Inside the enterprise, Active Directory is single sign-on because it allows the same credentials to be used for accessing everything from logging into a workstation with the three-finger salute to accessing email or HR systems.

3. Misconception that “information card” is a generic term-of-art as it relates to identity management. Information card, or infocard to use the original name for the technology before it was rebranded into CardSpace, is a particular proposal that defines specific formats and protocols for identity management. Writing about “the information cards” makes about as much sense as writing about “the Facebooks” and “the Googles.” Each is a specific incarnation of a general concept: a social networking site, a search engine and an identity management protocol.

4. No hint of the history of strong authentication or alternatives. A reader may walk away from this article with the impression no realistic alternatives to passwords existed until Cardspace magically burst on the scene. Basic fact checking would have unearthed some not entirely obscure facts: there is a concept of digital certificates dating back to the 1970s, leveraging the same brew of “hard to break cryptography” whose virtues are extolled in the article. Since late 1990s, digital certificates have been standardized by X509, a stable and widely implemented supported format. It would be a small jump from there to realize that the SSL protocol universally used for securing communications online has provisions for users to verify their identity with digital certificates and that many large organizations, including the United States Department of Defense have been depending on this capability for years.

This is not to say that there are not good points in the article. OpenID is a major distraction and duplication of effort precisely because it is a mediocre reinvention of the wheel, ignoring all the investments made towards deploying PKI on the web compliments of SSL and muddying the waters one more time just when there was a fighting chance that the industry might converge on a standard (SAML, far from perfect as it may be) as the underlying format for identity assertions. But it is a non-sequitur to argue that OpenID is doomed because of its dependence on passwords and inherent problems with single sign-on.

cemp

BlackHat: making the news while reporting it

DefCon attendees always knew that using the wireless network at the conference is living on the dangerous side– even on the rare occasions a few packets managed to route their way across the congested airwaves with thousands competing for the scarce bandwidth. (This blogger has been depending on his Novatel CDMA modem compliments of Sprint to continue writing.) If there is a real-life incarnation of the proverbial “untrusted network” this is it, and The Wall of Sheep has been the favored tradition for publicly embarassing those using weak protocols that transmit credentials in the clear.

This year the tradition expanded to Blackhat, putting attendees– a much different crowd than DefCon, it goes without saying– on notice that their name could be next on the hall of shame.

Journalists had a better deal: they got their own wired, private network in the press room, free from the shenanigans of creative researchers.

It did not work out. As reported by CNet, French journalists decided to step up to plate and impress their colleagues with their “l33t credentials.” Exact details are unclear but it appears that they managed to take control over the router and capture traffic from other journalists. For anyone not using VPN, that included the stories their they were filing. So much for good sportmanship– why bother attending the conference sessions or interviewing speakers when you can “rephrase” your colleagues’ dispatches instead? The French crew were so proud of their achievements that they wanted to get the spoils displayed on the Wall of Sheep. Conference organizers were not impressed by what they viewed as illegal wiretapping and interception. Neither were fellow members of press, when they were briefed on the incident. The proto-hackers were booted off the conference, which was not enough to appease the irate journalists. The reaction reportedly included at least one person from ZDNet going through the roof.

cemp

From 0wning DNS to 0wning SSL (2/2)

But SSL does have an Achilees heel: its trust model is anchored on the digital certificate used by the web server: the only proof that the website you are communicating with Bank of America (as opposed to an impostor in Estonia) is the fact that they have a digital certificate issued by Verisign claiming that this website indeed is www.bankofamerica.com.

The fragility of this model has been pointed out before. Verisign is not the only recognized certification authority; out of the box Windows ships with close to 100 CAs, all of them equivalent for trust purposes. Any one of them incorrectly issuing the Bank of America certificate to somebody else is enough to ruin any guarantees provided by the cryptography– it does no good to secure your traffic, when the person at the end of that encrypted channel is the bad guy. (Perhaps the biggest CA goof was Verisign issuing Microsoft code-signing certificate to impostors in 2001. The implications were much worse than for SSL certificates, but revocation has addressed the fall-out for the most part.) While MITM attacks against SSL due to incompetent CA practices have always been possible, the challenge of playing that messenger in between so far made this a low-likelihood attack vector. Owning DNS changes that.

More importantly– and this is Kaminsky’s main point regarding SSL– the certification process itself uses DNS. According to this version of the story, when the proud new owner of the domain www.acme.net wants a digital certificate, the CA consults DNS records to verify ownership. They might even ask the user to insert some DNS records or add a particular page to the website, as additional proof. All of these checks are trivially subverted if DNS is corrupt because all of them will be routed to servers controlled by the attacker. This means that while the existing Bank Of America certificate is safe and sound, the enterprising criminal will:

1. Choose a moderaly incompetent CA
2. Subvert DNS to confuse name resolution for that CA
3. Pass the domain ownership checks made by the CA
4. Obtain a new valid certificate in the name of Bank of America
5. Subvert DNS resoution for an ISP
6. MITM all of the users at that ISP by using the perfectly valid certificate from step #4

That, at least is the picture painted in the presentation. The critical details are certification steps used– not just by Verisign, Geotrust and other major CAs but every single one of the dozens of certification authorities recognized by IE and Firefox. Extended validation does not help for two reasons: on the usability front, users pay no attention to all the fancy eye-candy browsers waste on displaying EV status, as demonstrated nicely by The emperor’s new security indicators.. On the the implementation level, the browser grants exactly same privilege to regular certificates; embedded content for example can still be subverted using a vanilla cert while keeping the main page over EV.

If this attack does indeed work– and it is impossible to determine without consulting the certification practices for CAs– it shows a circularity in the security model. SSL/TLS are designed to survive exactly the type of mayhem created by DNS hijacking. It does not matter whether traffic is routed to the right website or the wrong one. When the protocol is implemented correctly and the certificate checks out, the user is supposed to be guaranteed that they are dealing with the legitimate website. (That is not much of a guarantee: if the certificate has errors, the protocol will detect it but until recent web browsers used to respond by displaying a cryptic warning that users simply ignored. Even when the certificate is validated correctly, that only proves the identity is what is stated in the URL– which may not be at all the same one that is in the user’s mental picture, to the delight of phishing syndicates everywhere.) Weak certification practices destroy even this glimmer of hope by placing critical faith in DNS to bootstrap a protocol that was purportedly designed to survive complete breakdown of all naming and routing infrastructure.

cemp

From owning DNS to owning SSL (1/2)

Dan Kaminsky walked away with the Pwnie award for most overhyped bug and being a good sport, appeared in person with a brief acceptance speech. The BlackHat presentation did turn into an over-crowded spectacle as expected, there was nothing new to report. (Even though a section of the deck was prefaced with “Here is something that did not leak…”) The cat had been out of the bag, compliments of earlier speculation by Halvar Flake and a miscue by the folks at Matasano. And that’s just the public disclosure: the presentation itself credited several people who identified the same vulnerability within days independently but decided to remain quiet, in keeping with the unusual request.

The more interesting was the second piece of the talk: the question of “why”, why it is worth subverting DNS and what can be accomplished. Decidedly more speculative in nature, in this section Kaminsky argued that SSL,  most software updates and online identity management services are vulnerable. If these claims hold for real-world implementation, not simply the marginal ones written by careless developers, it would be more remarkable than the original discovery.

SSL and in general PKI were designed to be resilient against an untrusted network. The design of the protocols assumes the transport is completely unreliable. The metaphor this blogger uses to describe it in security orientation classes is two people, say Alice and Bob, trying to communicate but restricted exchanging post-it notes carried by a shady messenger. In this model it is clear the messenger may fail to deliver the note, and the two sides never manage to communicate. No surprise there. But more interestingly, our shady messenger can erase part of the mesage, add forged languge, for that matter replace the entire note by a new one fabricated out of thin air, change the order in which notes are delivered, even replay one person’s note back to him/her as if it originated from the other side. This bizarre threat model is intended to capture the man-in-the-middle (MITM) attack in the abstract, where a malicious adversary is capable of reading and modifying any message sent between two people.

Communication protocols including SSL/TLS are designed to be secure in this model, in the sense that the nefarious messenger can not read a private message intended for Alice, nor convince Alice that Bob sent a message he did not in fact originate. SSL/TLS protocol itself has lived up to this claim so far– there are no known, practical cryptographic attacks against the protocol itself (as opposed to specific implementations, which can have coding issues that are not intrinsic in the protocol)  The closest call was the Bleichenbacher attack against RSA padding first published in 1998 and later refined.

[continued]

cemp

One week to Pwnie Awards

Move over Antoinette Perry. There is a new award in town and it will take place at the Black Hat briefings next week in Las Vegas. Pwnie awards will honor (shame?) moments of brilliance and ineptitude in the security research community. Highlights from this year’s crop of nominations include:

• Kernel-mode remote code execution that works on XP, W2K3 and Vista. This after MSFT speculated that the bug would be very difficult to exploit in the real world.
• Adobe Flash null pointer dereference. What appeared to be an innocuous crash that became a cross-platform, cross-browser remote code execution vulnerability after ISS’s Mark Dowd decided to take a closer look. Once again complements of Flash, continuing to undo any improvements in Internet Explorer security by introducing its own mediocre platform on top of an already fragile HTML/Javascript alliance that years of vulnerability research was finally starting to stabilize. All flash, no subtance but millions of users can’t be wrong: the dancing hamsters are clearly worth the risk of getting 0wned.
• QuickTime– no vulnerability required, the nomination committee decided the entire application is one colossal mistake, mired in the 1990s quality control standards (“compiles without errors when most warnings are disabled”) and providing another example of insecure context switching.
• DNS rebinding attacks. Using the web browser to VPN into the internal network behind a firewall. Considering that Kaminsky presented on the topic at last year’s Black Hat, this one has outlived its shelf life.
• Safari carpet bombing. Note to Apple: forcing software on user machines is not a good strategy when you are awfully slow to fix publicly reported vulnerabilities.
• Debian/OpenSSL not-very-random number generator debacle; also nominated for most epic failure.
• Linus Torvalds for controversial views on vulnerability research and handling security bugs.
• Overhyped bugs: DNS poisoning and unauthenticated UPnP control over network devices.

cemp

Fuel pumps and the “Y2K8 crisis”: security feature gone awry

Crude oil at $100/barrel may have been the first psychological barrier for traders. Now long crossed and $150 looming on the horizon, it turns out there is an equivalent one for drivers: the $100 refueling at the friendly local gas station. New York Times reports in the article titled When a tank of gast costs $100 several large trucks and SUVs have enough capacity for hitting the three digits during a refueling stop.

But they often do not quite get there for two reasons. First one is the unwillingness to see the register ringing up that amount. The article cites owners who prefer to refuel long before they are running on fumes, to avoid seeing the full price– and possible wasting more fuel with more frequent visits to the gas station, as well as slightly higher  weight of the car on average from carrying more fuel.

The second one is a “security feature:” many pumps that accept credit cards will shut off at $75 to prevent overcharges as well as stolen cards from being used. It seems strange that a criminal in possession of someone else’s credit card would be going on a shopping spree for fuel. Electronics, jewelry and other high value goods that can pawned off appear as more likely candidates. (Never mind the cartoon strips– these measures have been in place since the times when fuel was relatively inexpensive.)

That’s not the worst limitation: in an echo of the Y2K crisis, it turns out that many older pumps are not capable of registering three digits at all. (No word on whether they simply roll back to $0.00 and start counting from there or getting stuck at $99.99.)

cemp

GMail starts enforcing DomainKeys for eBay and PayPal

In a sign that Domain Keys Identified Mail deployments have become reliable enough to depend on, Google has started to enforce DKIM signatures on eBay and PayPal.

Quick recap: DKIM is an anti-spam scheme intended to block forged of email messages and verify the sender by using digital signatures. The  short version is every large email service provider signs messages originating from their site and the recipients verify them. Strictly speaking this is purely an authentication technology, defined by an open IETF standard– nothing prevents spammers from also signing their message but there is an implicit assumption that somewhere a reputation system will spring into existence to allow vetting the verified identities and blacklisting the miscreants. Microsoft has backed a competing solution called SenderID.

Major challenge with deploying these solutions is dealing with the “gray area.” If a message is properly signed by eBay, it is clearly coming from eBay. (Leaving aside the fact that eBay may have been handing out email accounts to its own sellers and one or more of them are spammers.) That email can be safely accepted. If the message is signed but the signature does not validate, it can be rejected– although even then there are edge cases where innocuous message modifications can cause the signature to invalidate. By design cryptographic signatures are designed to be very brittle; any change to the message invalides them. Domain Keys had to work around this.  But what about unsigned messages? It could mean that eBay does not implement the DKIM standard at all. Or perhaps they have not gotten around to deploying DKIM on all the servers. A large service may have hundreds of server dedicated to handling outbound email and the conservative approach is doing a small-scale pilot project first. The final possibility is the message did not originate with eBay and is indeed a forgery, an attempt at phishing for example. It’s important to distinguish these cases because the accept/reject decision for the message will be different.

Strictly enforcing DK would mean that unsigned messages are rejected but that can not be done until there is good reason to believe that the service provider has committed to signing 100% of outbound traffic. In October 2007 eBay (and PayPal, which is owned by eBay) announced plans for adopting DKIM. But until both services could commit to signing all traffic, strict enforcement could mean legitimate messages getting dropped or sent to the junk folder and unhappy users.

cemp

Cherry-picking identity providers in the open eco-system

Recap from a story developing last week:

• MSFT announced that it was accepting OpenIDs for the new HealthVault service, a cloud-based solution for managing health records. But not just any OpenID: only accounts issued by Trustbearer and Verisign are accepted. Both companies have two-factor authentication with portable hardware tokens.
• The blog ConnectID objected to the restriction, claiming that it violates the spirit of “open” in OpenID. Why is the user not free to choose any identity he/she prefers to use?
• MSFT’s identity architect fired back, joined by another blogger, both arguing that cherry-picking identity providers is fair game.

Underlying this exchange is a misunderstanding: agreement on protocols is necessary but not sufficient for identity federation. Accepting an identity issued by another company is a risk management decision– or under a broader perspective, it is a business decision. The mere fact that the aspiring ID provider has successfully implemented some protocol, is compliant with this other standard or runs the most popular software package for authentication is not enough.

Authentication is a security-critical function. Getting it wrong leaves any resource protected by that system vulnerable. And if something does break, it will always be the service provider’s problem downstream, even they are provably not at fault. Suppose that HealthVault accepted identities from Keys-Are-Us, a hypothetical incompetent OpenID provider operating out of a basement. This is an external dependency; when Keys-Are-Us makes an assertion about the identity of the user, HealthVault will accept that assertion on face value and provide access to controlled resources such as health records. This is essentially betting on the ability of this shady outfit to properly run an identity management system. If Keys-Are-Us experiences a security breach, and the health records accessed by unauthorized persons as a result, MSFT is still on the hook. Yes, in principle it was not their fault: Keys-Are-Us made the error. But try getting that message across to the media and blogosphere pouncing on the incident as another indication of everything that is wrong with the Internet. More importantly, by agreeing to accept identities from Keys-Are-Us, HealthVault is implicated in the risk management decision.

Case in point, HealthVault accepts Windows Live ID, the identity management service operated by MSFT. (Full disclosure: this blogger worked on WLID security in a former life.) Because both of these organizations roll up to the same corporate entity, HealthVault designers have visibility into and more importantly, influence over the risks of accepting these identities. Similarly the Verisign and Trustbearer systems are known quantities, and their reliance on hardware tokens makes it possible to gauge the security assurance level in a way that is not possible for random OpenID provider.

cemp

LifeLock: the plot thickens

(Follow-up from earlier post)

The past few weeks had more developments on the story of LifeLock, the company that promises identity theft protection and challenges would-be criminals with the social security number of the CEO. New York Times published an article on May 24th covering this story. The overall tone of the article is fairly negative on the value proposition of this service:

“…a fraud alert is more like a burglar alarm. And if the alert repeatedly fires off false alarms, forcing creditors to constantly double-check the identities of LifeLock customers who have never been victims of fraud, it is possible that those credit issuers will pay less attention to them. Experian is so worried about this, along with other issues, that it has filed suit against LifeLock.”

Strangely the company has found a new ally in Bruce Schneier who came out swinging in defense of LifeLock.  BS portrays the issue purely as a conflict of business models between the triumvirate of credit reporting bureaus (Equifax, Experian and TransUnion) and Lifelock. Credit reporting agencies prefer that the process of completing a credit check and clearing an applicant is easy. Lifelock’s mission in life is to make that process as difficult as possible for the lender, in order to reduce the risk that the application was fraudulent.

“The reason lenders don’t routinely verify your identity before issuing you credit is that it takes time, costs money and is one more hurdle between you and another credit card. (Buy, buy, buy — it’s the American way.) So in the eyes of credit bureaus, LifeLock’s customers are inferior goods; selling their data isn’t as valuable. LifeLock also opts its customers out of pre-approved credit card offers, further making them less valuable in the eyes of credit bureaus.”

And later in the same approving vein: (links in the original)

“It’s pretty ironic of the credit bureaus to attack LifeLock on its marketing practices, since they know all about profiting from the fear of identity theft. Facta also forced the credit bureaus to give Americans a free credit report once a year upon request. Through deceptive marketing techniques, they’ve turned this requirement into a multimillion-dollar business.”

One point where everyone is in agreement is that the services are not worth it from a purely financial point of view. Most of the actions taken on behalf of subscribers by the commercial services can also be taken by individuals directly for free. Convenience is the main selling point. For example anyone can request to have an alert put on their credit file but these expire after 90 days.

The original Wired article covering allegations that the service does not work appears to have been removed. Not to worry: Kim Zetter (full disclosure– she is a friend) writing on the ThreatLevel blog has missile lock on the company. In a series of posts, she highlighted an original piece from the Phoenix New Times that surfaced questionable past connections of the co-founder. LifeLock announced in response that he was resigning from the company.

cemp