skoordynowane ujawnianie podatności

Skoordynowane ujawnianie podatności (coordinated vulnerability disclosure, CVD) to proces, w którym osoba odkrywająca podatność najpierw przekazuje informację producentowi lub zaufanemu pośrednikowi, a szczegóły trafiają do publicznej wiadomości dopiero po przygotowaniu poprawki albo po upływie ustalonego terminu. CERT/CC definiuje CVD jako zbieranie informacji od znalazców podatności, koordynowanie ich wymiany między zainteresowanymi stronami i ujawnianie istnienia podatności oraz środków zaradczych, także publicznie ^[3]. Według CERT Polska proces ten został wprowadzony do europejskiego porządku prawnego zapisami dyrektywy NIS2 ^[1]. W starszych tekstach spotyka się określenie „responsible disclosure”.

Jak działa

Przewodnik CERT/CC dzieli proces na siedem faz: odkrycie, zgłoszenie, weryfikację, ustalenie priorytetu, naprawę, informację publiczną i wdrożenie ^[4]. Na etapie naprawy powstaje plan zaradczy, najlepiej poprawka oprogramowania, ale może to być też inny mechanizm ^[4]. Ostatnia faza to zastosowanie rozwiązania w działających systemach ^[4]. Schemat poniżej pokazuje kolejność faz.

RYS. 1Fazy skoordynowanego ujawniania podatności

Zasada, która odróżnia skoordynowane ujawnianie od publikacji natychmiastowej, to okres poufności. CERT Polska prosi zgłaszających, by nie publikowali informacji o podatności przed zakończeniem procesu jej obsługi, a osoby planujące wcześniejszą publikację o uprzedzenie o tym ^[2]. W tym czasie producent przygotowuje łatkę, a użytkownicy nie są jeszcze narażeni na ataki oparte na opublikowanym opisie.

Uczestnicy

CERT/CC wymienia role znalazcy, zgłaszającego, producenta i koordynatora ^[3]. Przewodnik opisuje też rolę wdrażającego, czyli tego, kto instaluje poprawkę w swoich systemach ^[4].

Koordynator jest potrzebny, gdy producent nie odpowiada, gdy podatność dotyczy wielu producentów albo gdy zgłaszający nie chce kontaktować się bezpośrednio. W Polsce funkcję tę pełnią zespoły CSIRT poziomu krajowego. CERT Polska zaleca, by zgłaszający najpierw kontaktował się z producentem lub właścicielem systemu, a jeśli to niemożliwe, przekazywał zgłoszenie właściwemu zespołowi CSIRT ^[2].

Każde zgłoszenie trafiające do CERT Polska jest analizowane, a analitycy w razie potrzeby proszą zgłaszającego o uzupełnienie informacji ^[2]. Pierwszeństwo mają zgłoszenia dotyczące wielu producentów lub podmiotów, które mogą mieć znaczny wpływ na bezpieczeństwo krajowe ^[2]. Odpowiada to fazom weryfikacji i ustalenia priorytetu w modelu CERT/CC, w których zgłoszenie jest sprawdzane pod kątem poprawności i porządkowane względem innych według pilności ^[4]. Koordynator może też wspierać wymianę informacji między zgłaszającym a producentem ^[2].

Terminy i publikacja

CERT Polska publikuje numery CVE po 90 dniach od przesłania producentowi szczegółów wykrytych słabości ^[2]. Publikacja może nastąpić wcześniej, jeśli producent wyda poprawkę albo nie podejmie współpracy ^{[1] [2]}. Numery CVE są przydzielane podatnościom w oprogramowaniu używanym w wielu systemach ^[2]; w praktyce nadaje je organizacja pełniąca rolę CNA. Po naprawie CERT Polska publikuje informację bez danych zgłaszającego, chyba że ten wyrazi zgodę ^[2].

Na poziomie Unii Europejskiej ENISA wspiera wyznaczonych koordynatorów CSIRT we współpracy, gdy podatność może mieć znaczący wpływ na podmioty w więcej niż jednym państwie członkowskim ^[5]. ENISA prowadzi też Europejską Bazę Podatności (EUVD), która gromadzi, uzupełnia i publikuje znane podatności ^[5].

Zgłaszającemu ułatwia pracę plik security.txt. RFC 9116 z kwietnia 2022 roku definiuje go jako maszynowo czytelny format opisu praktyk ujawniania podatności, umieszczany pod adresem /.well-known/security.txt ^[6]. Pola Contact i Expires są obowiązkowe; Policy może wskazywać politykę ujawniania, a Acknowledgments stronę z podziękowaniami dla badaczy ^[6].

W WordPressie

Projekt WordPress prowadzi osobne ścieżki dla rdzenia i dla wtyczek. Podatności w rdzeniu zgłasza się przez program WordPress na platformie HackerOne, a błędy w WordPress.com i wtyczkach Automattic przez program Automattic ^[7]. Podręcznik zastrzega, że szczegółów nie wolno przekazywać nikomu, dopóki poprawka nie zostanie oficjalnie wydana, i że nie wolno zgłaszać takich błędów publicznie na forach ani w Core Trac ^[7]. Projekt wypłaca nagrody za nowe, nieopublikowane podatności, czyli prowadzi program bug bounty; w okresie od pierwszej bety do ostatniej wersji RC nagrody są podwajane ^[7].

Podatności we wtyczkach z katalogu WordPress.org zgłasza się na adres plugins@wordpress.org, podając opis problemu i odnośnik do wtyczki ^[8]. Zespół wtyczek oczekuje, że zgłaszający najpierw spróbuje skontaktować się z autorem ^[8]. Większość zgłoszonych wtyczek jest zamykana dla nowych pobrań do czasu rozwiązania problemu ^[8]. Zespół prosi o niepublikowanie informacji, bo rozgłos zwiększa liczbę włamań i rzadko przyspiesza naprawę ^[8]. Nie pomaga natomiast w uzyskiwaniu numerów CVE ^[8].

Dla właściciela strony skutek jest praktyczny. Zamknięta w katalogu wtyczka może oznaczać niezałataną podatność we wtyczce, a wtyczka bez aktywnego autora staje się porzuconą wtyczką, dla której proces ujawniania nie kończy się poprawką.

Znaczenie

Skoordynowane ujawnianie skraca okres, w którym podatność jest znana atakującym, a nie ma na nią poprawki. Luka ujawniona bez poprawki staje się w praktyce zero-day, a luka ujawniona razem z poprawką jest podatnością znaną, którą trzeba jak najszybciej załatać; zob. n-day. Faza wdrożenia w modelu CERT/CC przypomina, że proces kończy się dopiero po zainstalowaniu poprawki w działających systemach ^[4]. Dlatego po publikacji komunikatu liczy się zarządzanie poprawkami po stronie administratorów.