Certighost (CVE-2026-54121): urząd certyfikacji wierzył atakującemu na słowo

Na czym polegał błąd

AD CS wystawia certyfikaty, a certyfikat w domenie działa jak podpisany dowód tożsamości. Możesz go pokazać KDC przez PKINIT i dostać bilet Kerberosa jako ten, kto jest w nim wpisany.

Podczas przetwarzania wniosku CA potrafi dopytać inny kontroler domeny o obiekt w katalogu. Ta ścieżka nazywa się chase i sterują nią dwa atrybuty żądania. Atrybut cdc wskazuje host, z którym CA ma się połączyć. Atrybut rmd wskazuje obiekt, którego ma tam szukać. Obie wartości podaje ten, kto składa wniosek.

Przed lipcową łatką CA łączyło się z podanym adresem po SMB i LDAP, pytało o wskazany obiekt i na podstawie odpowiedzi budowało certyfikat. Nie sprawdzało wcześniej, czy po drugiej stronie faktycznie stoi kontroler domeny.

Reszta jest już mechaniczna. Atakujący stawia u siebie własne usługi LDAP i LSA, wskazuje je w cdc, w rmd podaje nazwę DNS prawdziwego kontrolera domeny i odsyła CA jego objectSid oraz dNSHostName. Uwierzytelnienie po drodze przechodzi, bo atakujący zakłada sobie konto komputera w ramach ms-DS-MachineAccountQuota, a jego podstawione usługi przekazują wyzwanie od CA do prawdziwego kontrolera domeny. Z punktu widzenia CA po drugiej stronie odpowiada poprawny principal domenowy, więc certyfikat zostaje wystawiony z tożsamością kontrolera domeny.

Dalej idzie prosto: PKINIT tym certyfikatem, bilet Kerberosa jako kontroler domeny, prawa replikacji, DCSync, sekret krbtgt. W praktyce znaczy to podwójny reset krbtgt, zespół reagowania w środku nocy i pytanie od zarządu, jak długo ten stan trwał. Odpowiedź na to pytanie zwykle nie istnieje, bo nikt nie zbierał logów, które by ją dały.

Lipcowa aktualizacja dokłada walidację. Zanim CA pójdzie za wartością cdc, sprawdza w katalogu, czy podana nazwa odpowiada obiektowi komputera z flagą SERVER_TRUST_ACCOUNT (8192), odrzuca literały adresów IP i znaki, którymi dałoby się zmanipulować filtr LDAP, a po rozwiązaniu obiektu porównuje jeszcze SID.

Nasze spostrzeżenia

To nie jest kolejne ESC. Ostatnie lata nauczyły nas patrzeć na AD CS przez numerki: ESC1, ESC4, ESC8 i tak dalej aż do kilkunastu. Wszystkie mają wspólną cechę. To błędy konfiguracji, więc naprawiasz je konfiguracją: szablonem, flagą, uprawnieniem, wyłączeniem web enrollment.

Tutaj nie było czego naprawić. Badacze pracowali na domyślnym szablonie Machine z domyślną listą dostępu i domyślnym limitem kont komputerów. To nie błąd konfiguracji. To błąd w kodzie certpdef.dll.

Konsekwencja jest niewygodna dla wszystkich, którzy robią audyty AD CS z listy kontrolnej. Taki audyt na tym środowisku powiedziałby „czysto”.

Łatka zainstalowana, ścieżka niekoniecznie zamknięta. W lipcowej wersji nowa walidacja siedzi za flagą serwisową (Feature_3185813818), a stara gałąź wciąż jest w kodzie i wykonuje się, gdy flaga nie jest aktywna.

Nie mam twardych danych o tym, w jakich środowiskach ta flaga jest domyślnie włączona i nie zamierzam zgadywać. Wniosek praktyczny jest prostszy: zweryfikuj to u siebie, na kopii własnej konfiguracji, zamiast odhaczać KB w raporcie z WSUS-a. Różnica między „aktualizacja zainstalowana” a „ścieżka faktycznie zamknięta” potrafi być całą treścią rozdziału w raporcie.

Serwer CA prawie nigdy nie jest w zakresie testu. Dostajemy sieć wewnętrzną i listę systemów krytycznych. Serwer z rolą CA jest na tej liście rzadko, bo nie przetwarza danych osobowych, nie ma ładnego interfejsu i nikt nie ma go w KPI. Zwykle stawiał go ktoś na jeden projekt, kilka lat temu i od tamtej pory maszyna po prostu jest.

Ta maszyna wystawia tożsamości dla całej domeny. Segmentacja, EDR wszędzie, MFA na VPN, kwartalne przeglądy uprawnień. I jedna usługa PKI, która pyta obcego hosta, kim jest kontroler domeny…

Jeśli serwer CA nie podlega u ciebie temu samemu reżimowi łatania i monitoringu co kontrolery domeny, masz w architekturze założenie o zaufaniu, którego nikt nigdy nie zapisał.

ms-DS-MachineAccountQuota znowu. Ten sam parametr wraca w kolejnych ścieżkach eskalacji od lat: RBCD, noPac, teraz Certighost. Domyślne 10 oznacza, że dowolny użytkownik domeny może założyć sobie ważnego principala.

Ustawienie limitu na zero nie naprawia Certighost, bo skrypt potrafi użyć istniejącego konta komputera. Zabiera za to atakującemu darmowy klocek, po który sięga w większości łańcuchów, jakie oglądamy na testach wewnętrznych. Dołączanie maszyn do domeny przenieś na delegowaną grupę, tak jak powinno być od początku.

Detekcja jest tania, tylko nikt jej nie zbiera. Serwer CA nawiązujący połączenie wychodzące na porty 389 i 445 w stronę hosta, który nie jest kontrolerem domeny, to anomalia widoczna w netflow albo na zaporze, jeśli ktokolwiek na to patrzy.

Do tego dochodzą zdarzenia, które i tak masz: 4741 dla utworzenia konta komputera przez konto użytkownika oraz 4886 i 4887 dla żądań i wystawionych certyfikatów na CA. Same w sobie nic nie znaczą. Zestawione w czasie układają się w jeden bardzo czytelny wzorzec.

Co zrobić w tym tygodniu

• Zainstaluj lipcowe aktualizacje na każdym serwerze z rolą CA, nie tylko na kontrolerach domeny.
• Jeśli łatka musi poczekać, badacze podają obejście: wyczyszczenie flagi chase poleceniem certutil -setreg policy\EditFlags -EDITF_ENABLECHASECLIENTDC i restart usługi CertSvc. Sprawdź wcześniej, czy nie korzystasz z rejestracji międzydomenowej, bo to właśnie tę funkcję wyłączasz.
• Przenieś serwer CA z kategorii „serwer aplikacyjny” do tej samej klasy co kontrolery domeny: ten sam cykl łatek, ten sam monitoring, ta sama lista dostępów administracyjnych.
• Ustaw ms-DS-MachineAccountQuota na zero i oddaj dołączanie maszyn delegowanej grupie.
• Włącz na CA logowanie żądań certyfikatów i wyślij te zdarzenia tam, gdzie ktoś naprawdę je ogląda.

Na koniec pytanie

Ciekawi mnie jedno. Ilu z was wiedziało, że chase w ogóle istnieje, zanim ten CVE się pojawił?

To przy okazji najlepszy argument za tym, żeby robić test wewnętrzny, a nie sam skan. Skaner sprawdzi wersję i pójdzie dalej. Człowiek zapyta, czy ścieżka faktycznie jest zamknięta w twojej konfiguracji.