3 January 2018
Bulletproof TLS Newsletter is a free periodic newsletter bringing you commentary and news surrounding SSL/TLS and Internet PKI, designed to keep you informed about the latest developments in this space. Maintained by Hanno Böck.
Various software vendors lately have been found to have shipped private keys for certificates within their software. This problematic practice can lead to security vulnerabilities and will inevitably lead to the revocation of certificates if the key is discovered. The latest examples of these cases include Blizzard’s battle.net, Origin from Electronic Arts, Microsoft Dynamics 365 for Operations, and mandatory communication software for lawyers from Germany called besonderes elektronisches Anwaltspostfach (beA).
A common use case for such certificates arises when software wants to run a local HTTPS server. This often is done to allow communication with a web page and local software.
Tavis Ormandy discovered that Blizzard’s battle.net software embedded a certificate for the localbattle.net domain, signed by GoDaddy. This domain points to the local IP 127.0.0.1. Because the software runs the HTTPS server locally, this automatically means the software must contain the private key. This situation therefore is considered a key compromise. According to the Baseline Requirements, a set of rules for certificate authorities, if a key compromise is reported to a certificate authority, the certificate must be revoked within 24 hours.
In addition to being a key compromise, such certificates also can allow attacks. An attacker in a man-in-the-middle position could change the DNS reply for localbattle.net and thus redirect to an attacker-controlled server. Because the attacker can extract the certificate and private key from the software, he can impersonate that server.
After the certificate was revoked, Blizzard changed battle.net to locally generate a certificate that gets imported into the system’s certificate store.
Because the private keys were randomly generated on each system, this is an acceptable solution if implemented properly. However, in a thread on Reddit many users wrongly interpreted the newly installed root certificate as a security risk.
Later, it was discovered that the Blizzard client had another valid certificate for localbattle.net embedded that was signed by Digicert. In some situations, this certificate was used even after the initial fix. This was another key compromise, so the certificate was revoked again.
Electronic Arts also used a publicly trusted certificate for its Origin software, for the clienttolocalhostonly.com domain. Now that this certificate has been revoked, the software uses HTTP connections instead of HTTPS.
In both cases, the software tried to create a local HTTPS server with a publicly trusted certificate. This is never acceptable. Recently, the W3C agreed to a possible solution: browsers can consider connections to the local IP 127.0.0.1 part of a secure context, even if they’re made via HTTP. This doesn’t create a security issue because connections to the local IP never go over any network. Firefox and Chrome already support this.
Independent of these events, Markus Drenger discovered a few days before Christmas that communications software provided by the German Federal Bar (Bundesrechtsanwaltskammer, BRAK) had a very similar problem. Besondere elektronisches Anwaltspostfach (beA), which translates to “special electronic lawyers postbox,” was developed by the company Atos. Its web interface communicated with the bealocalhost.de domain, pointing to 127.0.0.1. TeleSec issued a certificate for that domain.
What made this case particularly interesting is that, in theory, German lawyers must use the beA software starting January 1st; it’s shut down for now, however.
After the certificate was revoked, the German Federal Bar tried to provide a fast solution and created a self-signed root certificate for bealocalhost.de. The lawyers were asked to import this certificate into their local root certificate store.
This made matters much worse. Because this was a root certificate—with the private key being part of the software—it allowed anyone to issue certificates for arbitrary domains. An attacker thus could perform man-in-the-middle attacks against google.com or any other domain—and all German lawyers were asked to install that certificate.
After this problem was uncovered by the author of this newsletter on the German news site Golem.de, the German Federal Bar shut down the system. It’s been offline since then. It’s worth pointing out that the bundled certificate wasn’t the only security problem for beA: the software also has a broken end-to-end encryption, and the server is still vulnerable to the ROBOT attack.
Microsoft’s Dynamics 365 for Operations presents another slightly different case in which a private key for a publicly trusted certificate was compromised. Software developer Matthias Gliwka discovered that sandbox instances of Dynamics 365 used a wildcard certificate to deliver the web interface. Customers can use the rdesktop protocol to log into their instances, so Gliwka was able to extract the private key.
Over the course of several months, Microsoft ignored Gliwka’s reports. However, after the author of this newsletter learned about this case, both Mozilla and the responsible certificate authority, Digicert, were informed. Thereafter, Microsoft was forced to resolve the issue quickly. The certificate was revoked, and new instances of Dynamics 365 use individually created certificates for each instance.
We reported about similar cases of private keys in applications, affecting Spotify and Cisco, in our June Newsletter.
This subscription is just for the newsletter; we won't send you anything else.
Designed by Ivan Ristić, the author of SSL Labs, Bulletproof SSL and TLS, and Hardenize, our course covers everything you need to know to deploy secure servers and encrypted web applications.
Remote and trainer-led, with small classes and a choice of timezones.
Join over 1,500 students who have benefited from more than a decade of deep TLS and PKI expertise.