podpisywanie kodu

Podpisywanie kodu (code signing) to opatrywanie programu, sterownika, aktualizacji albo paczki podpisem cyfrowym wydawcy. NIST opisuje dwie korzyści: integralność, która dowodzi, że kod nie został zmieniony, i uwierzytelnienie źródła, które wskazuje, kto go podpisał ^[1]. Podpis wyraża akceptację oprogramowania przez organizację, dlatego NIST zaleca przegląd kodu przed podpisaniem ^[1]; sam w sobie nie świadczy o braku błędów. Kradzież klucza do podpisywania pozwala napastnikom podpisywać złośliwe oprogramowanie tak, jakby pochodziło od zaufanej firmy.

Jak działa

Podpisywanie kodu opiera się na kryptografii asymetrycznej. NIST wyróżnia trzy role: dewelopera, który pisze i buduje kod, podpisującego, który zarządza kluczami, oraz weryfikatora, który sprawdza podpis ^[1]. Podpisujący generuje parę kluczy na odpowiednio chronionym urządzeniu, bo bezpieczeństwo całego procesu zależy od ochrony klucza prywatnego ^[1]. Klucz publiczny trafia zwykle do urzędu certyfikacji, który potwierdza tożsamość podpisującego i wydaje certyfikat; bez urzędu klucz publiczny trzeba dostarczyć zaufanym kanałem pozapasmowym ^[1].

Opcjonalnym elementem jest urząd znacznika czasu. Pozwala uznać podpis za ważny, jeśli klucz był ważny w chwili podpisania, nawet gdy później wygasł albo został przejęty ^[1]. Przepływ podpisanego kodu pokazuje schemat poniżej.

RYS. 1Podpisanie i weryfikacja kodu

Zagrożenia

NIST wymienia pięć głównych zagrożeń dla systemu podpisującego ^[1].

NIST zaznacza, że zagrożenie kradzieżą klucza pogłębiają ograniczone mechanizmy unieważniania w niektórych systemach ^[1]. Włamanie do potoku budowania, opisane w haśle atak na potok CI/CD, prowadzi do tego, że złośliwy kod dostaje prawdziwy podpis. Dlatego podpis jest tylko jednym z ogniw obrony przed atakiem na łańcuch dostaw.

W WordPressie

Od wersji 5.2, wydanej 7 maja 2019 roku, WordPress kryptograficznie podpisuje aktualizacje rdzenia kluczem przechowywanym offline ^[5]. Zespół rdzenia podał, że podpisy to Ed25519 obliczone ze skrótu SHA384 zawartości pliku ^[4], czyli podpisany wynik funkcji skrótu. Paragon Initiative Enterprises wyjaśnia cel zmiany: po zmianie napastnik, który chciałby zainfekować strony przez serwer aktualizacji, musiałby nie tylko włamać się na ten serwer, ale też wykraść klucz podpisujący zespołowi rdzenia ^[5].

Zakres był ograniczony. W chwili wydania wersji 5.2 podpisywane były tylko aktualizacje rdzenia, a motywy i wtyczki nie ^[5]. W pierwszym wydaniu WordPress domyślnie tylko ostrzegał przy nieważnym podpisie, zamiast przerywać aktualizację, żeby błąd nie zablokował prawowitych poprawek ^[5]. Wraz z tą wersją do rdzenia trafiła biblioteka sodium_compat ^[4].

W praktyce właściciel strony nie ma podpisu, który potwierdzałby pochodzenie wtyczki z nieoficjalnego źródła. Piracka wtyczka albo fałszywa wtyczka może mieć dowolną zawartość, dlatego znaczenie ma samo źródło pobrania.

Jak się bronić

Zalecenia NIST dla wydawców obejmują m.in. ^[1]:

• uwierzytelnianie i autoryzację osób, które mogą zlecać podpis, z rozważeniem zatwierdzania przez dwie osoby albo uwierzytelniania wieloskładnikowego;
• rozdzielenie roli administratora systemu podpisującego od roli zlecającego podpis;
• przechowywanie kluczy w miarę możliwości w HSM i odizolowanie systemu podpisującego od sieci produkcyjnej;
• osobny system i osobne klucze do podpisywania wersji deweloperskich;
• audyt użycia kluczy i ochronę logów przed nadpisaniem.

Wymóg sprzętowej ochrony klucza wprowadziło też CA/Browser Forum. Certum informuje, że głosowanie CSC-13, przyjęte 22 maja 2022 roku, nakazuje przechowywać klucze prywatne certyfikatów Code Signing na bezpiecznym urządzeniu kryptograficznym ^[6]. Alternatywą dla długowiecznych kluczy jest Sigstore: klient tworzy tymczasową parę kluczy, dostaje krótkotrwały certyfikat powiązany z tożsamością OIDC, a po podpisaniu klucz prywatny jest usuwany; zapis podpisu trafia do publicznego, niezmienialnego rejestru przejrzystości ^[7]. Po stronie weryfikatora NIST zaleca sprawdzanie certyfikatu, znacznika czasu i unieważnień ^[1]. Kotwice zaufania, czyli klucze główne, którymi weryfikator sprawdza certyfikaty, powinny zmieniać się tylko w ściśle określonym procesie aktualizacji ^[1]. Jeśli trzeba chronić się przed przywróceniem starej, podatnej wersji, numer wersji powinien być podpisany razem z pakietem, a aktualizacja powinna przejść tylko wtedy, gdy kod jest nowszy od zainstalowanego ^[1]. Projekt Sigstore działa pod egidą OpenSSF w Linux Foundation i jest bezpłatny dla wszystkich wydawców ^[7]. Utracony klucz należy unieważnić i zastąpić; zob. rotacja kluczy.

Historia i przykłady

ESET w lipcu 2018 roku opisał kampanię grupy BlackTech, która podpisywała złośliwe oprogramowanie Plead certyfikatami skradzionymi firmom D-Link i Changing Information Technology ^[2]. Plead był zdalnie sterowaną tylną furtką, a towarzyszący mu moduł wykradał hasła z przeglądarek Chrome, Internet Explorer i Firefox oraz z programu Outlook ^[2]. Podpis znanego producenta sprawiał, że pliki wyglądały na zaufane, choć ich treść pochodziła od napastników. D-Link unieważnił przejęty certyfikat 3 lipca 2018 roku ^[2]. Sekurak opisał sprawę jako kradzież certyfikatów zawierających klucze prywatne ^[3]. Według ESET certyfikat drugiej firmy unieważniono już 4 lipca 2017 roku, a grupa i tak nadal go używała ^[2]; pokazuje to, jak ważne jest sprawdzanie unieważnień przez weryfikatora.