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

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

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

Debian/OpenSSL vulnerability: subtle and fatal (1/2)

Most vulnerabilities in COTS software are quite blatant about their root causes and direct in their impact. A remote code execution vulnerability can be traced to a low level programming error and its immediate effect is likely an 0wned machine, or the next billion dollar self-propagating malware. Once in a while, a new extremely creative type of bug is introduced that defies this pattern. The flaw in the OpenSSL random number generator that affected Debian and Ubuntu is one of those rarities.

The short version: Debian developers attempted to fix a problem in OpenSSL that was flagged by static analysis software. (For other takes on the problem: my colleague Ben Laurie has taken the Debian maintainers to task and added some clarifications about the response, XKCD has neatly summed up the issue with a comic strip and Garntner argued that this incident is indicative of a deeper problems in open-source, just in time for a Coverity report that gave glowing reviews to open source projects for fixing issues identified by their technology.) It turned out the fix was much worse than the ailment

• Motivation: specific problem flagged by the automatic analysis of source code was an instance of using uninitialized memory– something that ought not occur in an ordinary application and is almost always a bug. But a library implementing cryptographic functionality has unusual requirements. In this case the OpenSSL designers were intentionally using uninitialized memory to seed the randomness pool. C/C++ language lawyers will jump up and down at this point screaming that use of uninitialized variables on the stack is undefined by the language. “Undefined” meaning that the compiler is free to optimize out the code, insert an easter egg, cause the application to crash if it reaches that instruction etc. Pragmatically speaking on most CPUs, operating systems and compilers that OpenSSL will likely reach, the memory ends up retaining the junk that was written last time, and this unpredictability is exactly what is required for randomness.
• Neglected wisdom: important point is that the bug was not causing OpenSSL to crash or misbehave. In the worst case, the memory region contained predictable data such as all zeroes, so there was no benefit in seeding a randomness pool with that. No problem because there were many other sources of randomness used. This is a good time to remember the classic engineering adage: “if it ain’t broke, don’t fix it.” Debian developers did “fix” it, but in doing so they removed the addition of all entropy to the pool, instead of simply removing the one instance that was questionable.
• Outcome: OpenSSL random number generator was completely broken. This is a major problem when dealing with cryptography. Everything depends on keeping secrets; encryption only works to protect data from people who do not have the decryption key. When keys are not just random patterns but generated according to a very predictable pattern, they are no longer a secret. The surprising part is that the code did not have a “vulnerability” in the classical sense: OpenSSL would not crash on malformed data because of this, it would not start running somebody else’s code or cause the machine to become the latest inductee into a botnet. A security researcher looking for yet another buffer overrun would be disappointed to realize that nothing of the sort was introduced as a result of the Debian update.

(continued)

cemp

CFP2008: Deep thoughts on deep packet inspection

DPI came up on the Friday morning discussion of network neutrality and when exactly an ISP has crossed the line. There is a material distinction between “content” and “meta-data” of communications. For example the rules around a pen register / trap-trace and different and more stringent than those governing a full wiretap. For IP communications, the parallel for phone number is the header of an IP packet, which might describe its destination, how much data it contains and perhaps hint at the protocol.  Looking past that into the payload of the packet is what can be termed “deep packet inspection.”

On the panel it was pointed out that DPI simply not commercially feasible until recently. The hardware required to look at every packet flying by a high-speed gigabit link is not exactly stocked at the local BestBuy. According to David Reed, initial demand was driven by intelligence applications. But Moore’s law does not discriminate between military and commercial use. As soon as the capability was within striking distance for large ISPs, people started looking for ways to capitalize on it: in other words, a solution in search of a problem. As with most of these contrived, artificially created uses of technology that start from the ISDN position (“innovations-subscribers-don’t-need”) the first attempt has proved less than brilliant.

The proposals from Charter and British-Telecom cross the line from dubious into no-doubt-about-it nefarious. This is the one scenario where less intrusive solutions are not possible because the business model favors collecting more data about customers. There is an interesting correlation between how far into the IP packet the ISP must look and the social acceptability of its objectives. Comcast can manage its scarce resources by simply counting bits– looking at the size of the IP packets sent, without regard for its destination or port. As it turned out their first crude, inept attempt did look at port numbers and single out BitTorrent. Luckily bandwidth is bandwidth and while the ISP has every right to create different pricing models that may require limiting resources consumed by the heaviest users, it has no business deciding which protocol the customer will use or what endpoints they choose to communicate with. Looking at the size of the IP packet and keeping tabs on usage is good enough for this purpose.

Looking at more data in the packet cranks up the intrusiveness level. Destination address will reveal the websites the customer is visiting. Advertising networks have traditionally relied on this information for targeting. This is the same data Charter and British-Telecom are going after. The final step will involve looking past the header and directly into the contents of the packet. Moore’s law is not on the side of privacy in this case. The CFP discussion and Peter Ohm’s ideas about the ECPA connection are very timely.

cemp