Crypto certificates impersonating Google and Yahoo pose threat to Windows users

Crypto certificates impersonating Google and Yahoo pose threat to Windows users:

Yet another reason why (a) the certificate authority system is broken; (b) Microsoft is stuck trying to fix problems that it (partially) brings upon itself; © Chrome is arguably the most secure – if not privacy protective – of the major Web browsers.


Banking Trojan Ships With Its Own Certificate

This is all kinds of badness, and speaks to malware vendors becoming increasingly sophisticated in how they are targeting low hanging fruit (i.e. random users). In essence, the attack involved getting a certificate issued and then using it to create valid digital signatures for .pdf invoice documents. Once individuals opened the invoices the malware associated with the .pdf would burrow into the OS and act as a key logger that targeted banking information.

Unfortunately, I’ve not yet seen a media article discuss the mediocre effectiveness of revoking the certificate used to sign the .pdf. The OCSP protocol is incredibly susceptible to being defeated, especially if malware already resides on the target’s computer or a point in between the target and the revocation server is controlled by the attacker (possible by setting a compromised computer to proxy traffic to a host controlled by the attacker). So, while while the cert has been revoked, this actions does not necessarily stop the malware from functioning, but just reduces the prospective attack surface. Moreover, if browser/operating system CA stores are not updated – again, possible if the attacker already controls the host – then the same attacker can convince the browser or OS to continue trusting an expired certificate.


Fallout from Comodo and DigiNotar Hacks Continues

The hacking of major certificate authorities, Comodo and DigiNotar, has been somewhat addressed by certificate blacklists and revocations. Despite these measures, however, the fallout of the hacks continues. As picked up by PC Magazine,

This week Kaspersky has discovered malicious droppers – programs that install malware – bearing stolen VeriSign certificates originally issued to a Swiss company called Conpavi AG.

One of the droppers carries a 32-bit driver containing a malicious DLL, which gets injected into your Internet browser process. A malicious 64-bit dropper injects the DLL directly.

From there, the DLL reroutes all your search queries in Google, Yahoo!, and Bing, to a pay-per-click search engine called Search 123. Search 123 makes money off people who search and click on their results.

As a colleague of mine commented, this is just another nail in X.509’s coffin. Let’s just hope that not too many innocents are buried along with it.


SSL Skeleton Keys

From the Ars lede:

Critics are calling for the ouster of Trustwave as a trusted issuer of secure sockets layer certificates after it admitted minting a credential it knew would be used by a customer to impersonate websites it didn’t own.

The so-called subordinate root certificate allowed the customer to issue SSL credentials that Internet Explorer and other major browsers would accept as valid for any server on the Internet. The unnamed buyer of this skeleton key used it to perform what amounted to man-in-the-middle attacks that monitored users of its internal network as they accessed SSL-encrypted websites and services. The data-loss-prevention system used a hardware security module to ensure the private key at the heart of the root certificate wasn’t accidentally leaked or retrieved by hackers.

It’s not new that these keys are issued – and, in fact, governments are strongly believed to compel such keys from authorities in their jurisdiction – but the significance of these keys cannot be overstated. SSL is intended to encourage trust: if you see that a site is using SSL then that site is supposed to be ‘safe’. This is the lesson that the Internet industry has been pounding into end-users/consumers for ages. eCommerce largely depends on consumers ‘getting’ this message.

The problem is that the lesson is increasingly untrue.

Given the sale of ‘skeleton key’ certs, the hacking of authorities to generate (illegitimate) certs for major websites (e.g.,,, etc), and widespread backend problems with SSL implementation, it is practically impossible to claim the SSL makes things ‘safe’. While SSL isn’t in the domain of security theatre, it can only be seen as marginally increasing protection instead of making individuals, and their online transactions, safe.

This is significant for the end-user/consumer, because they psychologically respond to the difference between ‘safe’ and ‘safer’. Ideally a next-generation, peer-reviewable and trust agile, system will be formally adopted by the major players in the near future. Only after the existing problems around SSL are worked out – through trust agility, certificate pinning, and so forth – will the user experience be moved back towards the ‘safe’ position in the ‘safe/unsafe’ continuum.


Chrome Kills CA Revocation Checks

From Ars:

“While the benefits of online revocation checking are hard to find, the costs are clear: online revocation checks are slow and compromise privacy,” Langley added. That’s because the checks add a median time of 300 milliseconds and a mean of almost 1 second to page loads, making many websites reluctant to use SSL. Marlinspike and others have also complained that the services allow certificate authorities to compile logs of user IP addresses and the sites they visit over time.

Chrome will instead rely on its automatic update mechanism to maintain a list of certificates that have been revoked for security reasons. Langley called on certificate authorities to provide a list of revoked certificates that Google bots can automatically fetch. The time frame for the Chrome changes to go into effect are “on the order of months,” a Google spokesman said.

The problems with CA revocation checks have been particularly prominent over the past 12 months, given the large number of serious CA breaches. While even the Google fetch mechanism isn’t ideal – really, we need to move to an agile trust framework combined (ideally) with browser pinning that can’t be compromised by corporate admins – it’s better. Still, there’s a long way to go until SSL and the CA system are reformed to the point of being actual ‘trusted’ facets of the Internet.


The most important detail to focus on, is (per comment 12 by Brian Trzupek above) that Trustwave knew when it issued the certificate that it would be used to sign certificates for websites not owned by Trustwave’s corporate customer.

That is, Trustwave sold a certificate knowing that it would be used to perform active man-in-the-middle interception of HTTPS traffic.

This is very very different than the usual argument that is used to justify “legitimate” intermediate certificates: the corporate customer wants to generate lots of certs for internal servers that it owns.

Regardless of the fact that Trustwave has since realized that this is not a good business practice to be engaged in, the damage is done.

With root certificate power comes great responsibility. Trustwave has abused this power and trust, and so the appropriate punishment here is death (of its root certificate).

~Christopher Soghoian, in comment about Trustwave

More Playbook UI Fail

This is (another) security freak-out from the PlayBook. Is it really the case that Quantcast isn’t properly registering their certificates? What does it mean for the end-user to deny verifying the certificate?

The information contained in this screenshot lacks actual actionable information for most end-users, and they’re instead given a choice between X and Y without having any clear understanding of what either X (Decline) or Y (Accept) entrails.

Another Playbook UI Fail

Over the past years, one of the things I’ve spent an inordinate amount of time researching and writing about has been security certificates and data transport security. This is just to say: I spend time in security and know more than a lot of non-technical people.

I have no clue what the fuck this message in the Kobo application for the BlackBerry PlayBook is doing here.

To be specific: I opened the app in a wifi-dead area that was dead in the middle of no where. There was no cell service. I checked with packet sniffing applications on my computer, there were no adhoc or other wireless networks. This kind of a warning indicates that some third-party was trying to intercept encrypted messaging traffic that was destined to Kobo’s servers but gives no indication of how or why this certificate problem was raised. In effect, it’s a warning “shit’s gone back, son!” without say “because X just happened!”

Security – on all devices – should be transparent to the user. The warning above (which I’ve seen in other PlayBook apps) is useless to the end-user because it gives no guidance as to what just happened, how to address it, or even how to learn more about the issue. While I commend RIM for making certificate errors so front and centre, presenting highly technical security information to the end-user is garbage unless you also inform them what the hell just happened.