German lawyers are now required to install a crypto backdoor
Starting on 1.1.2018 all german lawyers are required to use the special electronic lawyer mailbox (beA) for communication with authorities and courts, which requires a system wide installation of a ROOT-CA(with a publicly known private-key).
Technical background for non-IT experts
Internet connections are mostly encrypted to protect sensitive data. To make sure the connection is not only encrypted, but you are also talking to the intended server, connections are signed. To do this, windows/mac comes with a list of signatures which are considered trustworthy (ROOT-CA). Websites who want to support trusted and encrypted connections are buying a custom signature (imagine a real signature like on a paper document) from the trustworthy ROOT-CA. When someone now tries to connect to such a website, it presents this custom made signature, the connecting system compares this signature to the known trusted signature(the ROOT-CA) (which came with windows/mac). If it is a match, the system knows it is talking to the correct website and not a man in the middle(1). Otherwise the connection is refused and a warning is shown.
beA requires the users to add a new ROOT-CA to their systems. The problem here is that the software contains the original signature of the ROOT-CA. With this original signature it is possible to create custom-signatures for any website (like google.com or others). Since the system now trusts all custom-signatures by this ROOT-CA, the whole trust/encryption infrastructure of the Internet is broken for everyone who has this ROOT-CA installed.
beA delivered a Certificate including the private key
This software requires communication with bealocalhost.de (which resolves to a server running on localhost). To enable TLS(https) for this connection the software brought its own Certificate signed by a regular Certificate Authority (TeleSec), but also included the private-key. Therefore TeleSec revoked this certificate in accordance with general CA regulations.
Fixing the issue by making it even worse
Up until then the compromised private Key could only be used to 1 connections in the context of the beA (which is already bad enough). But after the CA revoked the certificate, systems refused to establish a connection with the revoked certificate. To fix this issue the company behind beA (Atos IT Solutions and Services) released an update including instructions how to install a new ROOT-CA into the System. For the beA software running on localhost to present a valid certificate it again contained the private key. But this time it was the private key for the new ROOT-CA. With this private key it is now possible to issue valid certificates for ANY domain.
Consequences
Since the Systems now trust this new root-ca, it is possible to 1 every connection of such a system which has the mandatory beA software installed, instead of just connections related to beA.
Now what?
German lawyers are required to use this software. But as lawyers they are also trusted with very sensitive information. As an IT-security aware person i cannot see any acceptable solution to the current situation, besides NOT installing beA. But since important documents are sent via beA you cannot just not use the software. To revert back to the old situation, where only connections related to beA are compromised, you could have a computer just for beA and nothing else, so only data sent/received via beA would be compromised. I have no idea what the legal situation is in that case.
For now the beA servers are unavailable due to infrequent connection issues. The tutorial on how to install the new ROOT-CA is also unavailable, so is the new ROOT-CA itself. Shutting down the beA servers does NOT fix the issue. Only manually removing the new ROOT-CA from all systems does, but also prevents usage of beA.
How could this happen?
I have no idea how such a completely broken system could ever be released, especially if you consider the special confidentiality needs of lawyers. The only way i can describe it is as “A total FAIL. Happy Birthday!”. You are welcome to quote me on that.
Stay tuned for more information and more issues with beA as the original reporter of this vulnerability is giving a session during this years #34C4
Sources
Unfortunately most sources are in german Golem reported on the issue on 23.12.2017
Heise reported on the issue first on 22.12.2017
Markus Drenger originally found the issue
Matthias Bergt warnung vor dem beA Lawyer specialized in IT