Hakerzy wykorzystali funkcję protokołu OpenPGP znaną od ponad dziesięciu lat.
Mówimy Ci, o co chodzi i dlaczego nie mogą tego zamknąć.
/Unsplash/
Problemy z siecią
W połowie czerwca nie wiadomo do sieci serwerów kluczy kryptograficznych , zbudowany na protokole OpenPGP. Jest to standard IETF (), który służy do szyfrowania wiadomości e-mail i innych. Sieć SKS powstała trzydzieści lat temu w celu dystrybucji certyfikatów publicznych. Zawiera narzędzia takie jak do szyfrowania danych i składania elektronicznych podpisów cyfrowych.
Hakerzy złamali certyfikaty dwóch opiekunów projektu GnuPG, Roberta Hansena i Daniela Gillmora. Ładowanie uszkodzonego certyfikatu z serwera powoduje awarię GnuPG — system po prostu zawiesza się. Istnieją powody, aby sądzić, że napastnicy na tym nie poprzestaną, a liczba zhakowanych certyfikatów tylko wzrośnie. Na chwilę obecną skala problemu pozostaje nieznana.
Istota ataku
Hakerzy wykorzystali lukę w protokole OpenPGP. Jest znana społeczeństwu od kilkudziesięciu lat. Nawet na GitHubie odpowiednie exploity. Ale jak dotąd nikt nie wziął odpowiedzialności za zamknięcie „dziury” (o przyczynach porozmawiamy później).
Kilka pozycji z naszego bloga na temat Habré:
Zgodnie ze specyfikacją OpenPGP każdy może dodawać podpisy cyfrowe do certyfikatów w celu weryfikacji ich właściciela. Co więcej, maksymalna liczba podpisów nie jest w żaden sposób uregulowana. I tu pojawia się problem – sieć SKS pozwala na złożenie aż 150 tysięcy podpisów na jednym certyfikacie, ale GnuPG nie obsługuje takiej liczby. Dlatego podczas ładowania certyfikatu GnuPG (jak również inne implementacje OpenPGP) zawiesza się.
Jeden z użytkowników — import certyfikatu zajął mu około 10 minut. Certyfikat miał ponad 54 tysiące podpisów, a jego waga wynosiła 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
Co gorsza, serwery kluczy OpenPGP nie usuwają informacji o certyfikatach. Odbywa się to po to, aby można było prześledzić łańcuch wszystkich działań z certyfikatami i zapobiec ich podmianie. Dlatego niemożliwe jest wyeliminowanie uszkodzonych elementów.
Zasadniczo sieć SKS to duży „serwer plików”, na którym każdy może zapisywać dane. Aby zobrazować problem, zeszłoroczny rezydent GitHuba , który przechowuje dokumenty w sieci serwerów kluczy kryptograficznych.
Dlaczego luka nie została zamknięta?
Nie było powodu, aby zamknąć lukę. Wcześniej nie był używany do ataków hakerskich. Chociaż społeczność IT Programiści SKS i OpenPGP powinni zwrócić uwagę na problem.
Dla uczciwości warto zauważyć, że w czerwcu nadal eksperymentalny serwer kluczy . Zapewnia ochronę przed tego typu atakami. Jednak jego baza danych jest zapełniana od podstaw, a sam serwer nie jest częścią SKS. Dlatego też upłynie trochę czasu, zanim będzie można z niego skorzystać.
/Unsplash/
Jeśli chodzi o błąd w oryginalnym systemie, skomplikowany mechanizm synchronizacji uniemożliwia jego naprawienie. Sieć serwerów kluczowych została pierwotnie napisana jako dowód koncepcji na potrzeby pracy doktorskiej Yarona Minsky'ego. Ponadto do pracy wybrano dość specyficzny język OCaml. Przez opiekun Robert Hansen, kod jest trudny do zrozumienia, dlatego wprowadzane są w nim jedynie drobne poprawki. Aby zmodyfikować architekturę SKS, trzeba będzie ją napisać od nowa.
W każdym razie GnuPG nie wierzy, że sieć zostanie kiedykolwiek naprawiona. W poście na GitHubie programiści napisali nawet, że nie zalecają pracy z SKS Keyserver. Właściwie jest to jeden z głównych powodów, dla których zainicjowano przejście na nową usługę klucze.openpgp.org. Możemy jedynie obserwować dalszy rozwój wydarzeń.
Kilka materiałów z naszego firmowego bloga:
Źródło: www.habr.com