2026-10-06 · BADANIA · Zespół Offensive Technology

Jak logi Certificate Transparency ujawniają wewnętrzne subdomeny

Czy Certificate Transparency ujawnia wewnętrzne nazwy hostów? Tak, rutynowo. Przeanalizowaliśmy publiczne logi CT dla 702 czołowych domen za pomocą crt.sh, tego samego darmowego narzędzia, z którego może skorzystać każdy, i odkryliśmy, że 65.5% ma zarejestrowaną przynajmniej jedną nazwę hosta wyglądającą na wewnętrzną: a dev., staging., vpn., admin., jira., lub vault.-podobną nazwę, która niemal na pewno była przeznaczona dla pracowników, a nie do publicznego internetu. Żaden host nie był skanowany, rozwiązywany w DNS ani sprawdzany bezpośrednio, aby uzyskać tę liczbę. CT to publiczny rejestr typu append-only każdego certyfikatu, jaki kiedykolwiek wystawiło publiczne CA, a dana nazwa musi otrzymać tylko jeden publicznie zaufany certyfikat, aby stać się trwałym, możliwym do przeszukania wpisem. To pierwszy krok atakującego przed jakimkolwiek skanowaniem, a większość organizacji oddaje swoją wewnętrzną konwencję nazewniczą za darmo.

Dlaczego publiczny log ujawnia prywatnie wyglądające nazwy

Certificate Transparency istnieje z ważnego powodu: uniemożliwia CA po cichu błędne wystawienie certyfikatu dla domeny, dla której nie powinno tego zrobić, ponieważ każdy wystawiony certyfikat staje się widoczny dla właściciela domeny i publiczności. Chrome i inne przeglądarki wymagają logowania w CT od publicznie zaufanych CA od 2018 roku na mocy RFC 6962. To bezsprzeczny zysk dla bezpieczeństwa całego ekosystemu. Efektem ubocznym jest to, że CT rejestruje również samą nazwę hosta, a nazwa hosta jest często najbardziej odkrywczą częścią wpisu.

Systemy wewnętrzne otrzymują publiczne certyfikaty z banalnego, prozaicznego powodu: nikt nie chce ostrzeżenia w przeglądarce, gdy pracownicy otwierają portal VPN lub wewnętrzną instancję Jira, nawet jeśli DNS dla tej nazwy rozwiązuje się tylko w sieci firmowej lub przez tunel VPN. Nazwa otrzymuje więc prawdziwy certyfikat od Let's Encrypt, DigiCert lub innego publicznego CA, dokładnie tak, jak publicznie dostępna strona. Certyfikat po cichu spełnia swoje zadanie. Efektem ubocznym jest to, że vpn.example.com lub staging-admin.example.com jest teraz trwale widoczna dla każdego, kto odpyta CT o example.com, za pomocą darmowego narzędzia takiego jak crt.sh, bez jakiejkolwiek interakcji z własną infrastrukturą example.com.

Dane: co rejestrują 702 czołowe domeny

Odpytaliśmy crt.sh o próbkę z listy najpopularniejszych domen Tranco (lista 94Y82), domena po domenie, z buforowaniem i opóźnieniami (backoff), aby nie przeciążać usługi, a następnie sklasyfikowaliśmy pierwszą etykietę DNS każdej zarejestrowanej nazwy według dziewięciu kategorii typowego nazewnictwa wewnętrznego: dostęp zdalny, uwierzytelnianie/tożsamość, środowiska nieprodukcyjne, devops/CI, komunikacja wewnętrzna, observability, administracja/zarządzanie, sekrety/infrastruktura oraz nazwy jawnie wewnętrzne. Spośród 1,000 odpytanych domen ukończono 702; 660 miało jakąkolwiek historię w CT. Wyniki dla poszczególnych domen były przechowywane wyłącznie w pamięci operacyjnej na czas analizy i nigdy nie zostały zapisane na dysku, więc nic tutaj nie wymienia konkretnej organizacji. Są to wartości procentowe dla próby, a nie lista.

Dominują nazwy środowisk nieprodukcyjnych: 58.8% domen zarejestrowało dev., staging., test. lub podobną nazwę. To najmniej zaskakujący wniosek i sam w sobie najmniej groźny, nazwanie środowiska stagingowego nie jest podatnością. Bardziej interesujące jest to, jak daleko sięgają niebezpieczne kategorie na tej liście. 20.4% zarejestrowało nazwę związaną z sekretami lub infrastrukturą taką jak vault., consul. lub k8s., a 21.8% zarejestrowało nazwę związaną ze zdalnym dostępem jak vpn. czy citrix. To kategorie, w których sama nazwa mówi atakującemu dokładnie, pod kątem jakiego znanego CVE warto sprawdzić dany produkt.

Poszczególne prefiksy pokazują to samo w większej szczegółowości. Oto dwanaście najczęstszych etykiet, które dopasowaliśmy, według udziału w próbie 702 domen:

Sam prefiks vpn. stanowi 12.8% całej próby, co oznacza, że w przybliżeniu jedna na osiem najbardziej obciążonych domen w internecie ogłosiła światu, poprzez publiczny log, którego nigdy nie musiała dotykać, że pod określoną nazwą uruchamia konkretny produkt do zdalnego dostępu. W połączeniu z fingerprintingiem wersji, który jest możliwy, gdy nazwa hosta się rozwiązuje, atakujący przechodzi od zerowej wiedzy do spriorytetyzowanej listy celów bez wysłania ani jednego pakietu w stronę celu.

Rzadko kończy się na jednej nazwie

Wyciek nie rozkłada się równomiernie po jednej nazwie na domenę. Spośród 460 domen, które ujawniły cokolwiek, 113 ujawniło nazwę z dokładnie jednej kategorii, ale pozostałe ujawniały nazwy z wielu kategorii jednocześnie: 65 domen pojawiło się w trzech kategoriach, 42 w sześciu, a 22 domeny ujawniły nazwy we wszystkich dziewięciu analizowanych przez nas kategoriach. Gdy organizacja ma nawyk wystawiania prawdziwych, publicznych certyfikatów dla wewnętrznych narzędzi, nawyk ten jest zwykle widoczny we wszystkich jej wewnętrznych narzędziach, a nie tylko w jednym. Dla atakującego domena, która ujawnia dane szeroko, jest znacznie cenniejsza niż taka, która ujawnia pojedynczą nazwę, ponieważ za pomocą jednego zapytania mapuje infrastrukturę deweloperską, uwierzytelniania i administracyjną.

Jak sprawdzić własną domenę

Zajmuje to mniej niż minutę i nie wymaga żadnego narzędzia poza przeglądarką lub curl, ponieważ odczytujesz ten sam publiczny rejestr, który sprawdziliśmy my.

• Odpytaj bezpośrednio crt.sh. Otwórz https://crt.sh/?q=%25.yourdomain.com&output=json i przejrzyj każdą zwróconą nazwę hosta. To wszystko, co CT kiedykolwiek zarejestrowało dla Twojej domeny, w tym nazwy wystawione lata temu dla serwerów, które mogą być dawno wyłączone z eksploatacji.
• Przefiltruj wyniki za pomocą grep pod kątem etykiet wyglądających na wewnętrzne. Szukaj w szczególności prefiksów z powyższej tabeli: dev, test, staging, admin, auth, vpn, internal, vault, jenkins, gitlab, grafana oraz ich bliskich wariantów. Wszystko, co pasuje, jest trwale publiczne, niezależnie od tego, czy obecnie rozwiązuje się w DNS.
• Traktuj każde dopasowanie jako już znane atakującemu. Nie można wstecznie usunąć certyfikatu z logu. Jedynym wyjściem jest założenie, że nazwa jest publiczna, upewnienie się, że stojąca za nią usługa nie polega na obscurity, oraz dbanie o jej aktualizacje i kontrolę dostępu tak, jak w przypadku zasobu wystawionego do internetu, ponieważ dla atakującego czytającego CT już nim jest.

Czego to nie dowodzi

Uczciwe ograniczenia, bo liczba bez zastrzeżeń to tylko marketing.

• Zarejestrowana nazwa nie jest dowodem na działającą, osiągalną lub podatną usługę. Dopasowywaliśmy jedynie tekst nazw hostów w CT, nic więcej. Nie rozwiązywaliśmy żadnej nazwy w DNS, nie łączyliśmy się z żadnym hostem ani nie sprawdzaliśmy, czy usługa za nim nadal istnieje. Część z tych nazw wskazuje na wycofaną infrastrukturę, a część nie wskazuje na nic.
• To próba 702 domen, a nie cały internet. Czołowe strony Tranco faworyzują duże, ugruntowane organizacje z infrastrukturą wystarczająco rozbudowaną, by w ogóle posiadać środowiska deweloperskie i stagingowe. Inna metodologia rankingu lub szersza próba zmieniłyby dokładne wartości procentowe.
• To migawka stanu z danego momentu. Liczby te opisują stan CT z momentu naszego odczytu 24 lipca 2026. Organizacje stale dodają i wycofują wewnętrzne nazwy hostów, więc dokładne wartości zmieniają się w czasie, nawet jeśli samo zachowanie pozostaje bez zmian.
• Dopasowywanie prefiksów jest heurystyczne, a nie bezwzględnie pewne. Etykieta taka jak admin to zazwyczaj wewnętrzny panel administracyjny, ale sporadycznie może być w pełni legalną nazwą produktu wystawionego publicznie. Zoptymalizowaliśmy listę kategorii pod kątem konwencjonalnego nazewnictwa, a nie idealnej precyzji, więc traktuj te wartości procentowe jako silny sygnał, a nie dokładny inwentarz.
• To mierzy ekspozycję nazwy, a nie podatność na wykorzystanie. Wiedza o tym, że vpn.example.com istnieje, to rekonesans, a nie kompromitacja. Daje to atakującemu spriorytetyzowaną, łatwo dostępną listę celów do sprawdzenia w kolejnym kroku.

Często zadawane pytania

Czy atakujący mogą używać logów Certificate Transparency do znajdowania subdomen?

Tak. Każdy certyfikat wystawiony przez publiczne CA jest rejestrowany zgodnie z RFC 6962, a każdy może przeszukiwać te logi za darmo za pośrednictwem crt.sh. W naszej próbie 702 domen 65.5% organizacji zarejestrowało w ten sposób przynajmniej jedną nazwę hosta wyglądającą na wewnętrzną, bez jakiejkolwiek interakcji z ich infrastrukturą.

Czy logi CT mogą ujawnić wewnętrzne nazwy hostów, które nigdy nie miały być publiczne?

Tak. Nazwa potrzebuje tylko jednego publicznie zaufanego certyfikatu, często wystawianego po to, by pracownicy nie widzieli ostrzeżenia w przeglądarce, aby stać się trwałym, publicznym wpisem. Serwer stojący za nią nie musi być osiągalny z internetu, aby sama nazwa wyciekła.

Jakie informacje są ujawniane w polu Subject Alternative Name certyfikatu?

Pole SAN wymienia każdą nazwę hosta objętą certyfikatem. Pojedynczy certyfikat typu multi-domain może ujawnić dziesiątki nazw naraz, a wszystkie stają się możliwe do wyszukania w CT w momencie wystawienia certyfikatu.

Jak wykrywać subdomeny za pomocą crt.sh?

Wyślij zapytanie do https://crt.sh/?q=%25.yourdomain.com&output=json. Zwraca każdy zarejestrowany certyfikat dla Twojej domeny i jej subdomen, w tym te wystawione dla serwerów, które mogą już nie istnieć. Jest to pasywne wyszukiwanie typu read-only w publicznym logu, dokładnie ta sama metoda, której użyliśmy tutaj.

Czy certyfikat wildcard zapobiega pojawianiu się subdomen w logach CT?

Certyfikat wildcard dla *.example.com rejestruje jedynie sam ciąg wildcard, ukrywając konkretną etykietę subdomeny. Jednak w momencie, gdy jedna usługa otrzyma własny certyfikat o unikalnej nazwie, ta nazwa zostaje zarejestrowana, nawet jeśli wszystko inne kryje się za certyfikatem wildcard.

Jak zapobiec wyciekowi wewnętrznych nazw hostów do Certificate Transparency?

Używaj prywatnego, wewnętrznego CA dla nazw, które nigdy nie powinny być publiczne, ponieważ tylko publiczne CA muszą rejestrować dane w CT. Preferuj certyfikaty wildcard zamiast unikalnie nazwanych certyfikatów końcowych (leaf), jeśli pozwala na to Twoja architektura, i traktuj wszystko, co już znajduje się w CT, jako trwale ujawnione.

Czy prywatne lub wewnętrzne urzędy certyfikacji są zwolnione z rejestrowania w Certificate Transparency?

Tak. Logowanie w CT jest wymagane od publicznie zaufanych CA, a nie od certyfikatów w ogóle. Certyfikat z Twojego własnego wewnętrznego CA, któremu ufają tylko Twoje zarządzane urządzenia, nigdy nie musi trafić do publicznego logu CT.

Powiązane artykuły

• Co atakujący naprawdę mogą zobaczyć na temat Twojej firmy? Szersza kwestia powierzchni ataku, na którą ten post odpowiada w jednym wycinku.
• Ile czasu zajmuje pojawienie się certyfikatu w CT? Ta sama kategoria narzędzi crt.sh, kwestia czasu zamiast kwestii nazewnictwa.
• Czy Certificate Transparency jest już post-quantum? Inna warstwa tego samego ekosystemu publicznych logów, warstwa podpisywania checkpointów zamiast zawartości certyfikatów.