Odzyskanie domeny: po przywróceniu DNS sprawdź certyfikaty

Odzyskanie przejętej domeny nie kończy się na przywróceniu DNS. Sprawdź nieoczekiwane certyfikaty w Certificate Transparency, poproś urząd certyfikacji, który je wystawił, o unieważnienie nieautoryzowanych certyfikatów, przywróć restrykcyjne zasady ich wystawiania i wyznacz osobę odpowiedzialną za dalszy monitoring. Działająca strona i awaryjna blokada w przeglądarce wyjaśniają tylko część sytuacji.

6 października Google poinformował o manipulacji autorytatywnym DNS w przestrzeniach nazw .gh, .sl i .as, po której wystawiono nieautoryzowane certyfikaty dla Google i innych organizacji. Firma podaje, że jej własne systemy nie zostały naruszone, i nie wskazuje powodów, by obwiniać urzędy certyfikacji. Chrome blokował certyfikaty za pomocą CRLSets, a Google równolegle uzgadniał ich unieważnienie z wystawcami. To relacja Google z incydentu, a nie pełne publiczne odtworzenie jego skutków. Raport Google o incydencie.

Co pozostaje do zrobienia po przywróceniu DNS?

Odzyskanie kontroli nad DNS nie unieważnia istniejącego certyfikatu. Certification Authority Authorization, czyli CAA, określa, które urzędy mogą wystawiać certyfikaty. Nie określa, jak klient sprawdza certyfikat już wystawiony. Zmiana tych zasad nie może wstecznie anulować wystawienia certyfikatu. RFC 8659.

Domena może wskazywać właściwy serwer, a strona przedstawiać swój zwykły certyfikat, gdy certyfikat wystawiony podczas nieautoryzowanej kontroli nadal nie został unieważniony. Sprawdź osobno kontrolę nad domeną i status certyfikatów.

Zacznij dokumentację odzyskiwania od tych pytań:

Ta sama różnica dotyczy zgłoszeń wycieku danych uwierzytelniających: zablokowanie przyszłego dostępu i ustalenie wcześniejszej aktywności to osobne decyzje.

Odzyskaj kontrolę i zachowaj dane z badanego okresu

Współpracuj z odpowiednim rejestratorem, rejestrem domen i dostawcami DNS, aby odzyskać kontrolę. Zachowaj dostępne zapisy zmian i ustal okres wymagający zbadania, zanim rutynowe porządki utrudnią odtworzenie kolejności zdarzeń.

Zapisz, która warstwa według twoich ustaleń została naruszona i który dostawca potwierdził odzyskanie kontroli. Przejęcie konta u rejestratora, zmiana rekordów autorytatywnych i incydent na poziomie rejestru mogą dotyczyć różnych organizacji. Raport Google opisuje manipulację autorytatywnym DNS w trzech przestrzeniach nazw. Relacja Google.

Dla każdej dotkniętej domeny zapisz oczekiwaną delegację, dostawcę DNS i zależne od niej usługi. Uwzględnij domeny regionalne, przekierowania i domeny zaparkowane. Domena bez aktywnej strony również może wymagać sprawdzenia certyfikatów. Google wyraźnie zaleca monitoring wszystkich posiadanych domen, w tym zaparkowanych i regionalnych, oraz ostrzega, że jego dochodzenie mogło pominąć część dotkniętych domen. Zalecenia Google dla właścicieli domen.

Uzasadnij granice badanego okresu. Jeśli znasz najwcześniejszą potwierdzoną nieautoryzowaną zmianę i czas przywrócenia kontroli potwierdzony przez dostawcę, zachowaj oba ustalenia. Jeśli zapisy są niepełne, wskaż, która granica pozostaje niepewna. Wygodnie dobrany okres wokół pierwszego alertu jest punktem wyjścia, a nie dowodem, że wcześniej nic się nie działo.

Znajdź nieoczekiwane certyfikaty w Certificate Transparency

Certificate Transparency, czyli CT, udostępnia certyfikaty i precertyfikaty w publicznych dziennikach, do których można tylko dopisywać nowe wpisy. Systemy monitorujące przeglądają dzienniki i mogą powiadamiać subskrybentów o znalezionych wpisach. CT dostarcza dowodów wystawienia certyfikatu do dalszego zbadania. Sam wpis nie dowodzi przechwycenia ruchu ani kradzieży danych. Jak działa CT.

Wyszukaj dotkniętą domenę w crt.sh, narzędziu do przeszukiwania CT wskazanym w instrukcji unieważniania Let’s Encrypt. Otwórz odpowiednie wyniki i porównaj nazwy objęte certyfikatem, wystawcę, daty ważności i znaczniki czasu w dziennikach z badanym okresem. Analizuj dane certyfikatu i dziennika łącznie. Nie traktuj początku ważności jako dokładnego czasu wystawienia.

Porównaj wyniki z dokumentacją wdrożeń i odnowień. Zapytaj osobę odpowiedzialną za usługę, czy każdy certyfikat pochodzi ze zwykłego odnowienia, CDN lub innego autoryzowanego wdrożenia. Pobierz niewyjaśnione certyfikaty, jeśli są dostępne, aby wystawca mógł zbadać ten sam plik.

Dla każdego niewyjaśnionego wyniku zachowaj krótki zapis dowodów:

• Nazwy domen objęte certyfikatem, w tym alternatywne nazwy podmiotu.
• Wystawcę, numer seryjny i odcisk certyfikatu.
• Daty ważności i odnośnik do odpowiedniego wpisu w dzienniku.
• Informację, czy obserwowany wpis dotyczy certyfikatu, czy precertyfikatu.
• Dokumentację wdrożeń lub odnowień wykorzystaną do porównania.
• Osobę, która sprawdziła wynik, i jej wniosek.

Nie utożsamiaj precertyfikatu z certyfikatem. Precertyfikat służy procesowi rejestrowania w CT i sam nie jest certyfikatem, którego serwer może używać. Wynik oznaczony jako precertyfikat powinien zachować to oznaczenie w wiadomości do wystawcy i w zgłoszeniu. Nie zamieniaj go w twierdzenie, że zaobserwowano serwer przedstawiający certyfikat. Opis precertyfikatów w CT.

Monitoring CT ma ograniczenia czasowe i nie obejmuje wszystkiego. Proces rejestrowania przewiduje maksymalne opóźnienie dodania wpisu do dziennika, a system monitorujący widzi tylko dzienniki, które sprawdza. Nie obiecuj natychmiastowego wykrycia i nie traktuj braku alertów jako pełnego dochodzenia. Projekt CT publikuje katalog systemów monitorujących, ale obecność w nim nie gwarantuje kompletności ani nie oznacza rekomendacji dopasowanej do twoich potrzeb.

Poproś wystawcę o unieważnienie certyfikatu

Zgłoś nieautoryzowane wystawienie certyfikatu do urzędu, który go wystawił, i postępuj zgodnie z jego udokumentowaną procedurą unieważnienia. Przywrócenie DNS, zastąpienie certyfikatu i awaryjna blokada w przeglądarce to osobne zdarzenia. Żadne z nich nie zastępuje odpowiedzi wystawcy.

Prześlij zebrane identyfikatory i dowody, wyjaśnij, dlaczego wystawienie było nieautoryzowane, i zachowaj wniosek oraz późniejsze odpowiedzi. Jeśli certyfikat obejmuje kilka nazw, zaznacz to na początku. Możesz potrzebować pomocy wystawcy. Nie zakładaj, że kontrola nad jedną domeną wystarczy do wybranej procedury.

Let’s Encrypt opisuje przydatny przykład: po odzyskaniu kontroli nad domeną właściciel może użyć innego uprawnionego konta, aby poprosić o unieważnienie, wykazując kontrolę nad wszystkimi identyfikatorami w certyfikacie. Posiadanie klucza prywatnego atakującego nie jest więc jedynym sposobem uzyskania uprawnienia. To procedura Let’s Encrypt. W swoim przypadku sprawdź instrukcje faktycznego wystawcy. Dokumentacja unieważniania w Let’s Encrypt.

Śledź każdy wniosek do uzyskania udokumentowanego wyniku. „Wysłano e-mail do CA” oznacza działanie oczekujące na odpowiedź. Odpowiedź wystawcy i dowody statusu certyfikatu pozwalają powiedzieć więcej. Zapisz, którego certyfikatu dotyczy wynik, aby odpowiedź o jednym numerze seryjnym nie zamknęła przypadkiem kilku niewyjaśnionych wpisów.

Co potwierdza blokada w Chrome?

CRLSets w Chrome umożliwiają awaryjne blokowanie certyfikatów i zawierają część unieważnień zebranych z list urzędów certyfikacji. Nie są pełną kopią wszystkich unieważnień. Google zastosował blokadę w Chrome i współpracę z CA jako osobne działania. Dokumentacja CRLSet w Chromium, reakcja Google na incydent.

Google ostrzega, że jego działania nie zapewniają niezawodnej ochrony użytkownikom innych przeglądarek. Jeśli sprawdzasz zachowanie przeglądarek lub klientów API, zapisz sprawdzone programy, wersje lub środowiska, czas i zaobserwowany wynik. Oddziel zakres tych sprawdzeń od odpowiedzi wystawcy dotyczącej unieważnienia.

Przywróć CAA bez zakłócania uprawnionych odnowień

CAA kontroluje wystawianie certyfikatów i wymaga przeglądu po odzyskaniu DNS. Nie może zapobiec nieautoryzowanemu wystawieniu, gdy atakujący kontroluje same zasady DNS, ani unieważnić istniejącego certyfikatu. Google zaleca przywrócenie restrykcyjnej polityki CAA z obsługiwanymi powiązaniami kont i metod walidacji. Ma to ograniczyć późniejsze wystawianie na podstawie wyników walidacji zapisanych w pamięci podręcznej. Zalecenia Google.

Zapisane wyniki walidacji mają znaczenie, ponieważ koniec nieautoryzowanej kontroli nad DNS nie musi oznaczać końca wszystkich możliwości wystawienia certyfikatów powstałych w tym okresie. Potraktuj przegląd jako zadanie konfiguracyjne zależne od dostawcy. Nie zakładaj, że ogólny rekord CAA usuwa tę lukę, bez sprawdzenia obsługi odpowiednich ograniczeń u wystawcy.

RFC 8657 definiuje dwa parametry: accounturi, który wiąże uprawnienie z URI konta, oraz validationmethods, który ogranicza metody walidacji dopuszczone przez dany rekord. Ich działanie zależy od jawnej obsługi przez wskazany urząd certyfikacji. Bezpodstawne założenie o obsłudze któregokolwiek parametru może sprawić, że planowane ograniczenie nie będzie egzekwowane. RFC 8657.

Przed zmianą rekordów produkcyjnych zidentyfikuj uprawnionych wystawców i konta używane do wystawiania w produkcji. Potwierdź dokładny URI konta u wystawcy lub w systemie zarządzającym certyfikatami. Adres e-mail używany do logowania przez człowieka nie zastępuje tego identyfikatora. Uwzględnij sposób odnowienia oraz ostatnie ręczne wystawienie, bo mogą odpowiadać za nie różne systemy.

Sprawdź całą politykę:

1. Potwierdź, że każdy wskazany wystawca obsługuje planowane powiązania.
2. Sprawdź URI konta produkcyjnego i dozwolone metody walidacji.
3. Osobno sprawdź uprawnienia do certyfikatów wildcard, jeśli mają zastosowanie.
4. Przeanalizuj aliasy, delegowane nazwy i politykę subdomen.
5. Sprawdź każdy rekord uprawnień pod kątem niezamierzonej alternatywnej autoryzacji.
6. Zweryfikuj, że uprawnione wystawianie i odnawianie nadal działa przy planowanych ograniczeniach.

Let’s Encrypt dokumentuje obsługę ograniczeń metod http-01, dns-01 i tls-alpn-01 oraz powiązań z kontami ACME. Sprawdza CAA przed każdym wystawieniem i wyjaśnia, że uprawnienia z wielu rekordów sumują się. Dokumentacja opisuje też nadpisywanie zasad w subdomenach i rozwiązywanie CNAME. Korzystaj z tych szczegółów, gdy wystawcą jest Let’s Encrypt, bez zakładania, że każdy urząd zachowuje się identycznie. Dokumentacja CAA w Let’s Encrypt.

Sumowanie uprawnień wymaga świadomego sprawdzenia. Ściśle ograniczony rekord może współistnieć z innym uprawnieniem, które pozwala wystawić certyfikat, którego wystawienie miało zostać zablokowane. Przeczytanie tylko nowego rekordu nie wystarcza. Sprawdź, jakie zasady faktycznie obowiązują dla nazw objętych certyfikatem, z uwzględnieniem odpowiednich delegacji i aliasów.

Zachowaj wynik testu działania razem ze zmianą konfiguracji. Zapisz, co udało się wystawić, przy użyciu którego konta i metody oraz jaki sposób odnowienia sprawdzono. Sprawdź odnowienie przed zaakceptowaniem zmiany, aby polityka nie blokowała następnego uprawnionego certyfikatu.

Wyznacz odpowiedzialność za monitoring wszystkich domen

Utrzymuj monitoring po doraźnym odzyskaniu kontroli. Wyznacz osobę, która potrafi zweryfikować alerty i skontaktować się z wystawcą. Google zaleca objęcie monitoringiem wszystkich posiadanych domen, ponieważ centralna reakcja może pominąć dotknięte nazwy. Zalecenie Google dotyczące monitoringu.

Zbuduj zakres monitoringu na podstawie spisu domen, a nie listy aktywnych stron. Uwzględnij marki regionalne, przekierowania, zaparkowane domeny i nazwy delegowane do innych zespołów. Dla każdej domeny zachowaj informację o oczekiwanym operatorze i uprawnionym sposobie wystawiania certyfikatów. Dzięki temu nowy alert da się wyjaśnić również pod nieobecność osoby, która obsługiwała pierwotny incydent.

Ustal, dokąd trafiają alerty i co dzieje się, gdy nikt nie odpowiada. W małym zespole jasno wskazana osoba odpowiedzialna i jej zastępca mogą być bardziej przydatni niż nieczytana wspólna skrzynka. Procedura powinna pozwalać zachować wpis, skontaktować się z osobą odpowiedzialną za usługę i zgłosić niewyjaśnione wystawienie bez wymyślania zasad w trakcie incydentu.

Monitoring nie daje uprawnienia do aktywnego testowania każdego adresu powiązanego z domeną. Jeśli dochodzenie rozszerza się o badanie usługi, sprawdź jej operatora i posiadane pozwolenie. Nasz przewodnik po zakresie skanowania bezpieczeństwa wyjaśnia, dlaczego samo powiązanie w DNS nie potwierdza uprawnienia.

Zachowaj dowody odzyskania kontroli przy zgłoszeniu

Zamykaj zgłoszenie na podstawie konkretnych wyników: przywrócenia kontroli, przeglądu dowodów dotyczących certyfikatów, udokumentowanych odpowiedzi wystawców, sprawdzenia polityki emisji i przypisania pozostałych prac. Obok wyników nazwij ograniczenia, aby kolejna osoba mogła ocenić decyzję bez powtarzania dochodzenia.

Przydatna notatka zamykająca może brzmieć: „Dostawca potwierdził odzyskanie kontroli nad tymi domenami. Porównaliśmy te wyniki CT z dokumentacją wdrożeń i zgłosiliśmy dwa niewyjaśnione wpisy ich wystawcom. Tutaj są odnośniki do odpowiedzi. Sprawdziliśmy wskazaną politykę CAA i sposób odnowienia. Testy przeglądarek i klientów API objęły te środowiska; osobny przegląd aktywności pozostaje przypisany do tej osoby”.

Zastąp każde ogólne określenie rzeczywistymi dowodami, uwzględniając oczekiwane odpowiedzi wystawców i luki w badanym okresie.

W Kit zgłoszenie bezpieczeństwa może zawierać wskazaną osobę odpowiedzialną, załączniki z dowodami, notatki wewnętrzne i odnośniki do zgłoszeń u dostawcy lub zadań naprawczych. Oś czasu łączy zmiany statusu, przypisania i korespondencję. W analizie po incydencie można zapisać przyczynę źródłową, działania naprawcze i wnioski, które trzeba jeszcze wyciągnąć. Powiąż techniczne prace nad odzyskaniem kontroli i ich wyniki z tym zgłoszeniem.

Zespół zyskuje w ten sposób miejsce do oceny przekazania sprawy i decyzji o zamknięciu. Sprawdź obsługę zgłoszeń Security w Kit i porównaj ją z obecnym procesem: czy kolejna osoba potrafi wskazać odpowiedzialnego, znaleźć dowody dotyczące certyfikatów i zobaczyć, które stwierdzenia o odzyskaniu kontroli nadal wymagają weryfikacji?