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.


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