The hackers used a feature of the OpenPGP protocol that has been known for over a decade.
We tell you what the essence is and why they cannot close it.
/Unsplash/
Network problems
In the middle of June, unknown to a network of cryptographic key servers built on top of the OpenPGP protocol. This is an IETF standard), which is used to encrypt email and other communications. The SKS network was created thirty years ago to distribute public certificates. It includes tools such as for data encryption and creation of electronic digital signatures.
Hackers compromised the certificates of two GnuPG project maintainers, Robert Hansen and Daniel Gillmor. Downloading a broken certificate from the server crashes GnuPG - the system just freezes. There is reason to believe that the attackers will not stop there, and the number of compromised certificates will only increase. The extent of the problem remains unknown at this time.
The essence of the attack
Hackers exploited a vulnerability in the OpenPGP protocol. It has been known to the community for decades. Even on GitHub related exploits. But so far no one has taken responsibility for closing the "hole" (we'll talk about the reasons in more detail later).
A couple of selections from our blog on Habré:
According to the OpenPGP specification, anyone can digitally sign certificates to verify their owner. Moreover, the maximum number of signatures is not regulated in any way. And here the problem arises - the SKS network allows you to place up to 150 thousand signatures on one certificate, but GnuPG does not support such a number. Thus, when loading a certificate, GnuPG (as well as other implementations of OpenPGP) hangs.
One of the users — it took him about 10 minutes to import the certificate. The certificate had more than 54 thousand signatures, and its weight was 17 MB:
$ gpg --homedir=$PWD --recv C4BC2DDB38CCE96485EBE9C2F20691179038E5C6
gpg: key F20691179038E5C6: 4 duplicate signatures removed
gpg: key F20691179038E5C6: 54614 signatures not checked due to missing keys
gpg: key F20691179038E5C6: 4 signatures reordered
gpg: key F20691179038E5C6: public key "Daniel Kahn Gillmor <[email protected]>" imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg: imported: 1
$ ls -lh pubring.gpg
-rw-r--r-- 1 filippo staff 17M 2 Jul 16:30 pubring.gpg
The situation is exacerbated by the fact that OpenPGP keyservers do not remove information about certificates. This is done so that you can trace the chain of all actions with certificates and exclude their substitution. Therefore, it is impossible to eliminate compromised elements.
In essence, the SKS network is a large "file server" to which anyone can write data. To illustrate the problem, last year a GitHub resident , which stores documents in a network of cryptographic key servers.
Why the vulnerability was not closed
There was no reason to close the vulnerability. Previously, it was not used for hacker attacks. While the IT community SKS and OpenPGP developers to pay attention to the problem.
In fairness, it should be noted that in June they still experimental keyserver . It implements protection against these types of attacks. However, its database is filled from scratch, and the server itself is not part of SKS. Therefore, it will take time before it can be used.
/Unsplash/
As for the bug in the original system, a complex synchronization mechanism prevents it from being fixed. The keyserver network was originally written as proof of concept for a doctoral dissertation by Yaron Minsky. Moreover, a rather specific OCaml language was chosen for work. By maintainer Robert Hansen, the code is difficult to understand, so only minor corrections are made to it. To modify the SKS architecture, it would have to be rewritten from scratch.
In any case, GnuPG doesn't believe the network will ever be fixed. In a post on GitHub, the developers even wrote that they do not recommend working with SKS Keyserver. Actually, this is one of the main reasons why they initiated the transition to the new keys.openpgp.org service. We can only observe further developments.
A couple of materials from our corporate blog:
Source: habr.com