Deweloperzy repozytorium pakietów Python PyPI (Python Package Index) ogłosili wprowadzenie wsparcia dla mechanizmu cyfrowej atestacji w celu weryfikacji autentyczności publikowanych pakietów, który zastępuje weryfikację za pomocą podpisów PGP. Kluczową różnicą w atestacji jest to, że publikacja pakietu jest zatwierdzana nie przez dewelopera, lecz przez osobę trzecią (katalog pakietów) po potwierdzeniu wiarygodności publikacji przez zewnętrznego dostawcę OpenID Connect (na przykład po weryfikacji, że publikowany pakiet jest zgodny z powiązanym repozytorium na GitHubie lub GitLabie).
System atestacji eliminuje wady charakterystyczne dla mechanizmu weryfikacji podpisów PGP, który został wcześniej uznany w PyPI za przestarzały. Decyzja ta została podjęta z powodu problemów z weryfikacją przynależności deweloperów otwartych kluczy PGP, które były używane do weryfikacji podpisów cyfrowych — z 1069 kluczy PGP użytych od 2020 roku do tworzenia podpisów w PyPI, 29% otwartych kluczy nie było dostępnych w dużych publicznych serwerach bazach danych, a 35% kluczy okazało się niemożliwe do potwierdzenia podczas audytu. Potwierdzone 36% kluczy PGP obejmowało jedynie 0,3% wszystkich podpisanych plików.
W nowym systemie podpisy używane do atestacji pakietów są tworzone z wykorzystaniem krótkotrwałych kluczy efemerycznych, generowanych na podstawie uprawnień potwierdzonych przez dostawców OpenID Connect. W momencie generowania kluczy potrzebnych do stworzenia podpisu cyfrowego, deweloper identyfikuje się za pośrednictwem dostawcy OpenID, który potwierdza jego związek z głównym projektem. Infrastruktura cyfrowej atestacji została zbudowana przy użyciu systemu Sigstore i narzędzi in-toto Attestation Framework.
Zaletą certyfikacji jest brak związku z stałymi kluczami PGP — utrata lub kompromitacja klucza prywatnego niszczy zaufanie do podpisów stworzonych na jego podstawie, podczas gdy w przypadku certyfikacji podpis jest tworzony w połączeniu z tokenem, który potwierdza uprawnienia w momencie publikacji paczki oraz połączenie paczki z głównym repozytorium kodu. Na przykład przy publikacji paczki przygotowanej za pomocą GitHub Action, certyfikacja określa weryfikowalne i potwierdzone połączenie między plikiem publikowanym w PyPI, repozytorium, procesem workflow i hashem commit-u, na podstawie którego stworzono paczkę.
Aby śledzić autentyczność kluczy i wykrywać możliwe kompromitacje, używany jest publiczny zcentralizowany log, na którym opiera się tworzenie paczek projektów i samego PyPI, zapewniający integralność i ochronę przed wprowadzaniem danych wstecznie, w którym zastosowano strukturę "drzewa Merkle" (Merkle Tree, każda gałąź weryfikuje wszystkie niższe gałęzie i węzły dzięki drzewiastego haszowaniu).
Dodatkowo można zauważyć wykrycie w katalogu PyPI złośliwej paczki "fabrice", która maskowała się jako popularna biblioteka "fabric" poprzez typosquatting (nadawanie podobnych nazw, różniących się pojedynczymi znakami, na przykład exampl zamiast example, djangoo zamiast django, pyhton zamiast python itd.), która została pobrana 201 milionów razy (7 milionów pobrań w zeszłym miesiącu). Złośliwa paczka pozostawała niezauważona od 2021 roku i od tego czasu była pobierana ponad 37 tysięcy razy.
Paczka "fabrice" powtarzała podstawową funkcjonalność oryginalnej biblioteki i dodatkowo zawierała kod do wykrywania i wysyłania na zewnętrzne hosty kluczy dostępu do AWS (Amazon Web Services), instalacji backdoora oraz wykonywania określonych skryptów. Aktywacja złośliwych komponentów miała miejsce w systemach Linux i Windows. W systemie Linux pliki związane z złośliwą aktywnością były ładowane do katalogu ~/local/bin/vscode.
Źródło: opennet.ru
