Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Underminr to technika nadużycia współdzielonej infrastruktury CDN, która pozwala ukrywać połączenia do złośliwych zasobów pod pozorem komunikacji z legalnymi i zaufanymi domenami. Problem wynika z rozbieżności między tym, co obserwują mechanizmy DNS i TLS, a tym, jak ruch jest faktycznie kierowany wewnątrz infrastruktury dostawcy usług brzegowych.
W praktyce oznacza to możliwość obchodzenia filtracji DNS, polityk egress oraz części mechanizmów detekcji opartych wyłącznie na analizie nazw domenowych. Dla zespołów bezpieczeństwa to sygnał, że sama reputacja domeny nie wystarcza już do oceny wiarygodności połączenia.
W skrócie
Underminr bywa opisywany jako wariant domain frontingu, ale działa inaczej niż klasyczne techniki ukrywania celu ruchu. Zamiast polegać wyłącznie na różnicach między SNI a nagłówkiem HTTP Host, wymusza połączenie z adresem IP innego tenant-a działającego na tym samym współdzielonym brzegu CDN.
W efekcie komunikacja może wyglądać jak dozwolony ruch do zaufanej domeny, choć rzeczywisty cel sesji jest zupełnie inny. Taka metoda może służyć do maskowania kanałów C2, tunelowania ruchu przez VPN lub proxy oraz obchodzenia ochrony typu Protective DNS.
- ukrywanie złośliwego ruchu za legalną domeną,
- omijanie filtrów DNS i polityk ruchu wychodzącego,
- utrudnianie detekcji opartej na pojedynczych artefaktach telemetrycznych,
- potencjalne zastosowanie w malware, skryptach i kampaniach socjotechnicznych.
Kontekst / historia
Mechanizm nawiązuje do wcześniejszych technik domain frontingu, które były szeroko wykorzystywane do ukrywania rzeczywistego miejsca docelowego ruchu HTTPS. Historycznie polegało to na użyciu legalnej domeny w polach widocznych podczas zestawiania sesji TLS, podczas gdy właściwy cel był przekazywany dopiero wewnątrz zaszyfrowanego kanału HTTP.
Wielu dużych dostawców chmury i CDN z czasem ograniczyło tę klasę nadużyć. Underminr pokazuje jednak, że mimo wdrożonych mitigacji nadal istnieją słabe punkty wynikające ze współdzielenia adresacji IP oraz logiki routingu pomiędzy wieloma tenantami na tej samej infrastrukturze brzegowej.
Z perspektywy obrońców to istotny wniosek: blokada klasycznego domain frontingu nie rozwiązuje całkowicie problemu nadużyć na styku warstwy aplikacyjnej, TLS i routingu sieciowego.
Analiza techniczna
Sedno problemu polega na niespójności korelacji pomiędzy kilkoma warstwami obserwacji ruchu: wynikiem zapytania DNS, adresem IP endpointu brzegowego, wartością SNI w TLS, nagłówkiem HTTP Host oraz wewnętrznym routowaniem tenantów w ramach CDN. Jeżeli systemy ochronne analizują te elementy oddzielnie, a nie jako spójny łańcuch decyzyjny, pojawia się luka umożliwiająca obejście polityk bezpieczeństwa.
W klasycznym scenariuszu ochronnym rozwiązania PDNS i filtry egress zakładają, że poprawna rezolucja DNS prowadzi do zaakceptowanej komunikacji. W przypadku Underminr host może wykonać pozornie prawidłowe zapytanie do dozwolonej domeny, lecz sesja końcowo zostanie obsłużona przez inny zasób działający na tej samej współdzielonej infrastrukturze brzegowej.
Opisane nadużycie koncentruje się głównie na połączeniach TCP przez port 443. Jeśli mechanizmy kontroli opierają się tylko na DNS albo wyłącznie na SNI, mogą nie wykryć, że rzeczywisty backend nie odpowiada zaakceptowanemu celowi polityki dostępowej.
Technika może zostać wdrożona zarówno w złośliwych aplikacjach, jak i prostych skryptach powłoki. Wskazuje się również możliwość jej użycia w kampaniach typu ClickFix, w których użytkownik lub administrator jest nakłaniany do wykonania komend uruchamiających złośliwy łańcuch komunikacji.
Konsekwencje / ryzyko
Najpoważniejszym skutkiem Underminr jest podważenie prostych modeli zaufania opartych na reputacji domeny lub samej obserwacji DNS. Dla zespołów SOC oznacza to ryzyko fałszywego poczucia bezpieczeństwa, ponieważ ruch może wyglądać na legalny, mimo że faktycznie wspiera komunikację z infrastrukturą przestępczą.
Praktyczne konsekwencje obejmują ukrywanie kanałów command-and-control, omijanie polityk ograniczających ruch wychodzący, tunelowanie sesji przez VPN lub proxy oraz utrudnianie analizy incydentów. Szczególnie narażone mogą być organizacje, które traktują Protective DNS jako główny mechanizm blokowania złośliwej komunikacji.
Ryzyko rośnie w środowiskach enterprise intensywnie korzystających z usług SaaS i CDN, gdzie współdzielona infrastruktura jest standardem. W takich architekturach odróżnienie legalnego ruchu od nadużycia wymaga głębszej inspekcji i dokładniejszej korelacji zdarzeń sieciowych.
Rekomendacje
Organizacje powinny odejść od modelu, w którym decyzja o dopuszczeniu ruchu opiera się wyłącznie na wyniku zapytania DNS lub reputacji domeny. Kluczowe jest połączenie danych z wielu warstw: DNS, adresu IP, SNI, certyfikatu TLS, nagłówków aplikacyjnych oraz informacji o faktycznie osiąganym backendzie.
- rozszerzyć monitoring ruchu wychodzącego o korelację DNS, TLS i logów proxy,
- wykrywać niespójności między dozwoloną domeną a adresem IP lub tenantem obsługującym żądanie,
- ograniczać bezpośredni ruch do współdzielonych CDN do ściśle uzasadnionych przypadków,
- wdrażać polityki egress oparte na aplikacjach i tożsamości procesu, a nie tylko na domenach,
- monitorować połączenia TCP/443 inicjowane przez nietypowe procesy, skrypty i narzędzia administracyjne,
- analizować użycie SNI w zestawieniu z pełnym kontekstem sesji TLS,
- wprowadzać detekcję anomalii tam, gdzie poprawne zapytanie DNS nie odpowiada rzeczywistej ścieżce komunikacji.
Dodatkowo warto przeprowadzić przegląd architektury zabezpieczeń w kontekście usług Protective DNS. Jeśli PDNS jest traktowany jako podstawowa bariera dla C2, powinien zostać uzupełniony o segmentację sieci, kontrolę proxy, inspekcję TLS oraz polityki Zero Trust. Zespoły blue team powinny także uwzględnić tę technikę w playbookach threat huntingu i ćwiczeniach adversary emulation.
Podsumowanie
Underminr pokazuje, że współdzielona infrastruktura CDN może zostać wykorzystana do ukrywania złośliwej komunikacji nawet tam, gdzie klasyczne domain fronting zostało częściowo ograniczone. Problem nie wynika wyłącznie z pojedynczego błędu, lecz z luki w korelacji danych pomiędzy DNS, TLS i routingiem wewnętrznym.
Dla obrońców najważniejszy wniosek jest prosty: zaufanie do domeny nie może być traktowane jako wystarczający dowód legalności połączenia. Skuteczna ochrona wymaga wielowarstwowej walidacji celu komunikacji oraz lepszej widoczności ruchu wychodzącego.
Źródła
- SecurityWeek – ‘Underminr’ Vulnerability Lets Attackers Hide Malicious Connections Behind Trusted Domains
https://www.securityweek.com/underminr-vulnerability-lets-attackers-hide-malicious-connections-behind-trusted-domains/ - Underminr – oficjalne informacje o technice i badaniach
https://underminr.ai/ - Wikipedia – Domain fronting
https://en.wikipedia.org/wiki/Domain_fronting