Hackers have used a feature of the OpenPGP protocol that has been known for over ten years.
We tell you what the essence is and why they cannot close it.
/ Unsplash / Chunlea Ju
')
Network problems
In mid-June, unknown
persons attacked the SKS Keyserver network of cryptographic key servers built on the basis of the OpenPGP protocol. This is the IETF standard (
RFC 4880 ), which is used to encrypt email and other messages. The SKS network was created thirty years ago to distribute public certificates. Tools such as
GnuPG for encrypting data and creating electronic digital signatures are connected to it.
Hackers compromised the certificates of two GnuPG project maintainers - Robert Hansen and Daniel Gillmor. Downloading a corrupted certificate from the server causes GnuPG to crash - the system just freezes. There is reason to believe that attackers will not stop there, and the number of compromised certificates will only increase. Currently, the extent of the problem remains unknown.
Essence of the attack
Hackers exploited a vulnerability in the OpenPGP protocol. It has been known to the community for decades. Even on GitHub,
you can find the appropriate exploits. But so far no one has claimed responsibility to close the “hole” (we’ll talk more about the reasons below).
A couple of selections from our blog on Habré:
According to the OpenPGP specification, anyone can add digital signatures to certificates to confirm their ownership. Moreover, the maximum number of signatures is not regulated in any way. And here a problem arises - the SKS network allows you to place up to 150 thousand signatures for one certificate, but GnuPG does not support such a number. Thus, when loading a certificate, GnuPG (as, incidentally, other OpenPGP implementations) hangs.
One of the users
conducted an experiment - importing a certificate took him about 10 minutes. 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 <dkg@fifthhorseman.net>" 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 aggravated by the fact that key servers with OpenPGP do not delete certificate information. This is done so that you can trace the chain of all actions with certificates and prevent their substitution. Therefore, it is impossible to eliminate compromised elements.
In fact, the SKS network is a large “file server” on which anyone can write data. To illustrate the problem, last year a GitHub resident
created a file system that stores documents on a network of cryptographic key servers.
Why the vulnerability is not closed
There was no reason to close the vulnerability. Previously, it was not used to conduct hacker attacks. Although the IT community
has long asked SKS and OpenPGP developers to pay attention to the problem.
In fairness, it is worth noting that in June they still
launched the experimental
keys.openpgp.org key
server . It implements protection against these types of attacks. However, its database is populated from scratch, and the server itself is not part of SKS. Therefore, time will pass before it can be used.
/ Unsplash / Rubén Bagüés
As for the bug in the original system, a complicated synchronization mechanism prevents fixing it. The key server network was originally written as proof of concept to defend a doctoral dissertation by Yaron Minsky. Moreover, a rather specific OCaml language was chosen for work. According
to maintainer Robert Hansen, understanding the code is difficult, so only minor corrections are made to it. To modify the SKS architecture, you will have to rewrite it from scratch.
In any case, GnuPG does not believe that the network will ever be fixed. In a post on GitHub, the developers even wrote that they did 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 the further development of events.
A couple of materials from our corporate blog: