Host Dockera z nieuwierzytelnionym API wystawionym do internetu nie udostępnia jedynie wygodnej funkcji zdalnego zarządzania. Udostępnia zdalną drogę do maszyny, na której działają kontenery. Opisana 30 września kampania CARBONATO wyraźnie pokazuje znaczenie tej różnicy: atakujący wykorzystują ujawnione zdalne interfejsy API Dockera do tworzenia uprzywilejowanych kontenerów, ustanawiania trwałego dostępu, kradzieży poświadczeń i wyszukiwania kolejnych hostów Dockera.

Ilustracja redakcyjna odsłoniętego hosta Docker, pokazująca ścieżkę dostępu z internetu do serwera i płaszczyzny sterowania kontenerami.

Incydent zasługuje na uwagę, ponieważ nie jest przede wszystkim historią o nowej luce w Dockerze. To historia interfejsu administracyjnego umieszczonego w niezaufanej sieci bez granicy uwierzytelniania. Złośliwe oprogramowanie zawiera nowoczesny ładunek, w tym przerobiony framework open source dla agentów AI, ale warunek umożliwiający atak jest starszy i prostszy: każdy, kto może dotrzeć do demona, może żądać operacji wykonywanych z uprawnieniami hosta.

Zespoły uruchamiające Dockera na serwerach chmurowych, maszynach kompilacyjnych, hostach deweloperskich, usługach utrzymywanych samodzielnie lub systemach brzegowych powinny potraktować sprawę jako ocenę ekspozycji i możliwego przejęcia. Należy zamknąć nieuwierzytelnioną ścieżkę, ustalić, czy host był wykorzystywany, obrócić wszystko, co mógł odczytać, a następnie przejrzeć systemy sąsiednie. Ponowna instalacja kontenera albo zmiana taga obrazu nie wystarczy, jeśli bazowy host lub jego poświadczenia mogą już znajdować się pod kontrolą innej osoby.

Co naprawdę wynika z raportów o CARBONATO

Komunikat Cyber Security Agency of Singapore opublikowany 30 września informuje, że badacze zidentyfikowali kampanię botnetową wymierzoną w hosty Dockera, których nieuwierzytelnione zdalne interfejsy API były wystawione do internetu, zwykle na porcie TCP 2375. W komunikacie opisano wykorzystanie legalnych funkcji Dockera do utworzenia uprzywilejowanego kontenera z dostępem do systemu plików, procesów i sieci hosta.

Ta sekwencja ma znaczenie. Atakujący nie musi wykorzystywać błędu bezpieczeństwa pamięci w Docker Engine, jeśli demon przyjmuje żądania administracyjne od niezaufanej strony. Żądanie normalne dla administratora — utworzenie kontenera, zamontowanie ścieżki, uruchomienie procesu albo podłączenie sieci — może stać się kontrolą nad hostem, gdy nadawca nie jest uwierzytelniony, a demon działa z wysokimi uprawnieniami.

Singapurski komunikat stwierdza, że kampania może ustanawiać trwały zdalny dostęp, wykradać poświadczenia i inne wrażliwe informacje oraz skanować połączone sieci w poszukiwaniu kolejnych ujawnionych hostów Dockera. Nie twierdzi jednak, że każdy wystawiony host został przejęty, ani nie przedstawia uniwersalnego wskaźnika, który samodzielnie potwierdziłby lub wykluczył incydent. Te ograniczenia są ważne. Komunikat jest powodem do zbadania ekspozycji i logów, a nie podstawą do uznania każdej instalacji Dockera za zainfekowaną.

Osobna notatka badawcza Cloud Security Alliance uzupełnia obraz ładunku. Opisuje CARBONATO jako samorozprzestrzeniający się botnet, który instaluje niezmodyfikowany framework open source dla agentów AI, Hermes Agent, a następnie zmienia jego konfigurację persony, aby framework realizował cele operatorów. Z notatki wynika, że zainfekowane hosty skanują sąsiednie zakresy sieci w poszukiwaniu kolejnych demonów Dockera.

Nietypowy jest wybór ładunku. Dla obrońców najważniejsza pozostaje jednak ścieżka dostępu. Obecność frameworka AI może przyciągać uwagę, ale atakujący nie potrzebuje agenta AI, aby zmienić ujawniony demon Dockera w poważny incydent. Ta sama ekspozycja administracyjna może służyć do kradzieży poświadczeń, kopania kryptowalut, działań destrukcyjnych, proxy, ruchu bocznego albo wdrożenia tradycyjnego backdoora.

Dlaczego port 2375 wymaga precyzyjnej reakcji

Dokumentacja Dockera rozróżnia zwykłe lokalne gniazdo od zdalnych połączeń sieciowych. Domyślnie Docker korzysta w systemach Linux i macOS z niesieciowego gniazda Unix. Zdalne zarządzanie może natomiast używać SSH albo gniazda TCP chronionego TLS-em i uwierzytelnianiem klienta.

Dokumentacja Dockera wskazuje również konwencjonalny podział portów: TCP 2375 jest zwykle używany dla niezabezpieczonego połączenia bez TLS, a TCP 2376 tradycyjnie kojarzy się z TLS-em. Sam numer nie jest dowodem przejęcia, a inny port nie czyni nieuwierzytelnionego API bezpiecznym. Port 2375 jest po prostu użytecznym sygnałem rozpoznawczym, ponieważ często wskazuje, że demon Dockera skonfigurowano do zwykłego zdalnego dostępu.

Kluczowe pytanie nie brzmi: „Czy port 2375 jest otwarty?” w oderwaniu od kontekstu. Należy ustalić:

  • Jaki proces nasłuchuje?
  • Czy nasłuch jest osiągalny z publicznego internetu, szerokiej sieci firmowej czy tylko z ograniczonego segmentu zarządzania?
  • Czy wymaga uwierzytelniania i odpowiednio autoryzuje klienta?
  • Jaki demon Dockera, konto, host i obciążenie znajdują się za tym interfejsem?
  • Czy logi pokazują żądania, których właściciel nie wykonywał?

Usługa dostępna z internetu może być niebezpieczna nawet wtedy, gdy nie jest osiągalna globalnie. Demon wystawiony do płaskiej sieci wewnętrznej może być dostępny dla przejętej stacji roboczej, urządzenia kontraktora, konta deweloperskiego albo innego obciążenia, które nigdy nie powinno mieć administracyjnej kontroli nad hostem. „Jest otwarty tylko wewnątrz VPC” to stwierdzenie o sieci, a nie model autoryzacji.

Sedno problemu: dostęp do Dockera oznacza dostęp do hosta

Kontenery zapewniają użyteczne granice izolacji, ale dostęp do demona Dockera jest uprawnieniem zarządczym. Docker ostrzega, że zmiana powiązania demona na gniazdo TCP albo przyznanie dostępu do gniazda Unix przez grupę docker może pozwolić użytkownikowi uzyskać dostęp do hosta na poziomie roota. Łatwo przeoczyć to ostrzeżenie podczas diagnozowania systemu kompilacji albo upraszczania zdalnego programowania.

Kontener utworzony z podwyższonymi uprawnieniami może widzieć zasoby hosta lub je modyfikować. Nawet bez odtwarzania sekwencji ataku wniosek obronny jest prosty: poświadczenia demona Dockera i dostęp do jego gniazda należy traktować jak poświadczenia roota. Należą do tej samej kategorii ryzyka co klucze administratora chmury, interfejsy zarządzania hipernadzorcą i dostęp do płaszczyzny sterowania Kubernetes.

Dlatego samo usunięcie podejrzanego kontenera jest słabym działaniem ograniczającym skutki. Jeśli atakujący uzyskał dostęp na poziomie demona, mógł odczytać zmienne środowiskowe, zamontować katalogi hosta, przejrzeć inne kontenery, skopiować pliki konfiguracyjne, zmodyfikować mechanizmy startowe, utworzyć dodatkowe konta albo zebrać poświadczenia z hosta. Widoczny kontener może być tylko jednym artefaktem szerszego przejęcia.

Ta sama zasada dotyczy runnerów CI. Runner kompilacyjny z dostępem do uprzywilejowanego gniazda Dockera może ujawnić kod źródłowy, materiały podpisujące, poświadczenia pakietów, tokeny chmurowe i uprawnienia wdrożeniowe. Laptop dewelopera z zamontowanym gniazdem Dockera może ujawnić lokalne pliki i środowisko hosta. Zdalne API dodane dla wygody może więc połączyć przepływ pracy kontenera z tożsamością i infrastrukturą znajdującą się wokół niego.

Co administratorzy powinni zrobić najpierw

Pierwsza reakcja powinna ograniczyć zasięg atakującego bez niszczenia dowodów.

1. Zidentyfikować każdy demon Dockera z ekspozycją sieciową

Zacznij od wiarygodnego inwentarza, a nie od pamięci zespołu. Przejrzyj grupy bezpieczeństwa w chmurze, zapory hostów, load balancery, trasy VPN, rekordy wykrywania usług, konfigurację hostów kontenerowych, pliki jednostek systemd, pliki konfiguracyjne demona, szablony orkiestracji oraz repozytoria infrastruktury jako kodu.

Szukaj nasłuchujących demonów Dockera na portach TCP 2375 i 2376, ale sprawdzaj również niestandardowe porty i powiązania, na przykład demona nasłuchującego na wszystkich interfejsach. Przejrzyj środowiska produkcyjne i nieprodukcyjne. Hosty deweloperskie bywają bardziej wystawione, słabiej monitorowane i połączone z sieciami zawierającymi cenne poświadczenia.

Wytyczne CISA dotyczące ograniczania ekspozycji internetowej zalecają budowanie widoczności zasobów dostępnych z internetu i ograniczanie niepotrzebnej ekspozycji. To samo podejście dotyczy ekspozycji wewnętrznej: ustal, co jest osiągalne, z jakiego miejsca i z jakiego powodu biznesowego. Zasobu nieobecnego w inwentarzu nie da się wiarygodnie załatać, monitorować ani zbadać.

Jeśli nieuwierzytelniony demon jest wystawiony, natychmiast ogranicz dostęp na poziomie sieci, zachowując logi i rejestry zmian. Doraźnym celem jest zatrzymanie nowych nieuwierzytelnionych połączeń. Nie zakładaj, że zmiana reguły zapory dowodzi czystości hosta; zmienia tylko to, kto może do niego dotrzeć.

2. Usunąć zwykły zdalny dostęp

Oficjalne wytyczne Dockera dotyczące ochrony gniazda demona zalecają użycie SSH albo TLS do zabezpieczenia zdalnego dostępu. SSH może być praktycznym wyborem dla pracy operatorów, ponieważ przekazuje żądania do zdalnego gniazda Unix, korzystając z istniejącego modelu uwierzytelniania i autoryzacji hosta.

Jeśli dostęp TCP jest rzeczywiście wymagany, użyj wzajemnie uwierzytelnianego TLS z kontrolowanym urzędem certyfikacji, chroń klucze prywatne, ogranicz sieci źródłowe i rejestruj aktywność administracyjną. Szyfrowana TLS-em usługa bez uwierzytelniania nadal jest problemem autoryzacji. Szyfrowanie chroni ruch przed obserwacją i modyfikacją; nie rozstrzyga, czy klient powinien móc tworzyć uprzywilejowane kontenery.

Preferuj prywatną ścieżkę zarządzania zamiast publicznego nasłuchu. Stosuj zasadę najmniejszych uprawnień wobec tożsamości administrujących demonem, oddziel zarządzanie przez ludzi od automatyzacji i unikaj przekazywania szeroko używalnego certyfikatu klienta zadaniom kompilacyjnym lub wielu zespołom. Certyfikat klienta dający nieograniczony dostęp do Dockera należy traktować jak poświadczenie roota hosta.

Nie rozwiązuj ekspozycji wyłącznie zmianą numeru portu. Grupy bezpieczeństwa, zapory hostów, routing, uwierzytelnianie i autoryzacja muszą wspólnie odpowiadać zamierzonej granicy zarządzania.

3. Zachować i przejrzeć dowody

W przypadku potencjalnie ujawnionego hosta zachowaj odpowiednie logi systemowe, zapory, chmury, Dockera, orkiestracji i tożsamości, zanim wykonasz rotację lub przebudowę. Ustal okres, w którym demon był osiągalny, i porównaj go z raportami o kampanii oraz własną telemetrią.

Przydatne pytania kontrolne obejmują:

  • Czy do punktów końcowych API Dockera kierowano nieoczekiwane żądania?
  • Czy kontenery tworzono, uruchamiano, zatrzymywano lub usuwano poza zwykłymi oknami wdrożeń?
  • Czy pojawił się nowy obraz, rejestr, sieć, wolumen albo sekret?
  • Czy ścieżki hosta były niespodziewanie montowane w kontenerach?
  • Czy kontener działał z podwyższonymi uprawnieniami, siecią hosta albo dostępem do wrażliwych katalogów?
  • Czy na hoście utworzono nowe procesy, użytkowników, zadania zaplanowane, usługi, klucze SSH albo wpisy startowe?
  • Czy host nawiązywał nietypowe połączenia wychodzące, szczególnie z infrastrukturą command and control albo nieznanymi rejestrami?
  • Czy inne hosty w tej samej sieci wykazywały wkrótce potem próby połączeń związanych z Dockerem?

Celem nie jest znalezienie jednej magicznej nazwy pliku. Atakujący mogą usuwać kontenery, zmieniać nazwy procesów, korzystać z legalnych narzędzi albo wdrażać inny ładunek. Koreluj aktywność API z uruchamianiem procesów, przepływami sieciowymi, dostępem do rejestrów, zdarzeniami audytu chmury i logami dostawcy tożsamości.

Jeśli host zawiera wrażliwe obciążenia albo logi nie pozwalają ustalić, co się wydarzyło, odizoluj go i postępuj zgodnie z procesem reagowania na incydenty w organizacji. Gdy integralność hosta budzi wątpliwości, odbuduj go z zaufanego obrazu. Odbudowa jest bardziej wiarygodna, gdy sprawdzono również poświadczenia, konfigurację i artefakty wdrożeniowe, zamiast bezkrytycznie kopiować je z potencjalnie przejętego systemu.

4. Obrócić ujawnione sekrety zgodnie z ich zakresem uprawnień

Załóż, że mogły zostać ujawnione sekrety dostępne dla demona Dockera, hosta, zamontowanych wolumenów, zmiennych środowiskowych, warstw obrazów lub działających procesów. Priorytety ustalaj według tego, co dane poświadczenie pozwala zrobić, a nie według miejsca jego przechowywania.

Może to obejmować klucze dostępu do chmury, tokeny CI, tokeny kontroli źródła, poświadczenia rejestrów, hasła do baz danych, klucze SSH, klucze podpisujące, sekrety webhooków, tokeny kont usług i poświadczenia wpisane w pliki wdrożeniowe. Odwołaj je lub obróć z zaufanej ścieżki administracyjnej. Sprawdź, czy po wydaniu nowych poświadczeń nie były one używane w nieoczekiwany sposób.

Rotacja bez odwołania jest niepełna, jeśli stare poświadczenie nadal działa. Rotacja bez przeglądu logów pomija możliwość, że atakujący już użył sekretu do uzyskania dostępu do innej usługi. Rotacja bez mapy zależności może zakłócić produkcję, dlatego trzeba ją skoordynować, ale niedogodność operacyjna nie jest powodem, by pozostawiać aktywne cenne poświadczenia po wiarygodnym ujawnieniu.

Przejrzyj także sekrety, które nie były bezpośrednio zapisane na hoście, lecz były osiągalne przez jego tożsamość. Przejęta rola instancji w chmurze, tożsamość obciążenia albo konto usługi CI może rozszerzyć incydent daleko poza jeden serwer Dockera.

Jak wygląda bezpieczna architektura

Dobrze zabezpieczona konfiguracja Dockera zwykle ma wąską ścieżkę administracyjną i jasno uzasadniony powód dla każdego wyjątku.

W przypadku administracji lokalnej zachowaj domyślne gniazdo Unix chronione kontrolą dostępu hosta i ogranicz członkostwo w grupie docker. Członkostwo nie jest niewinnym ułatwieniem; może zapewniać szeroką kontrolę nad demonem, a tym samym nad hostem.

Do administracji zdalnej używaj SSH albo wzajemnie uwierzytelnianego TLS, ogranicz adresy źródłowe i w razie potrzeby umieść usługę za siecią zarządzania lub VPN-em. Przechowuj logi poza hostem, aby atakujący nie mógł usunąć jedynej kopii. Monitoruj wydawanie certyfikatów, użycie kluczy i zmiany konfiguracji demona.

W CI unikaj przekazywania niezaufanemu zadaniu kompilacyjnemu uprzywilejowanego gniazda hosta. Rozważ tryby rootless, izolowane runnery, krótkotrwałe workery, oddzielne tożsamości do budowania i wdrażania oraz API o wąskim zakresie. Jeśli kompilacja rzeczywiście wymaga uprzywilejowanych operacji, traktuj runner jako wysokiego ryzyka system administracyjny i odpowiednio go izoluj.

W środowiskach chmurowych uwzględnij nasłuchujące demony Dockera w zarządzaniu powierzchnią ataku i wykrywaniu dryfu konfiguracji. Bezpieczny szablon może zostać później podważony przez skrypt startowy, konfigurację demona wbudowaną w obraz, polecenie diagnostyczne albo tymczasowy wyjątek w zaporze, który stanie się stały.

Deweloperom należy udokumentować zatwierdzony zdalny sposób pracy. Zespoły często tworzą niezabezpieczone nasłuchy, ponieważ bezpieczna ścieżka jest niejasna albo niewygodna. Obsługiwany kontekst SSH, zarządzane środowisko programistyczne lub dobrze zaprojektowana usługa kompilacyjna usuwa presję, by wystawiać demon bezpośrednio.

Jak odróżnić ekspozycję od potwierdzonego przejęcia

Publiczny albo szeroko dostępny wewnętrznie nasłuch Dockera jest poważnym ustaleniem, ale nie stanowi automatycznie dowodu, że atakujący go wykorzystał. W rejestrach incydentu zachowaj rozdział między trzema stanami:

  1. Potwierdzona ekspozycja: demon przyjmował lub mógł przyjmować połączenia z niezaufanej sieci.
  2. Zidentyfikowana podejrzana aktywność: logi albo telemetria hosta pokazują żądania, procesy, aktywność sieciową lub zmiany konfiguracji, których nie wyjaśnia autoryzowana praca.
  3. Potwierdzone przejęcie: śledczy mają wystarczające dowody, że nieuprawniona strona uzyskała kontrolę albo dostęp do danych.

To rozróżnienie pomaga podejmować decyzje. Potwierdzona ekspozycja powinna uruchomić natychmiastowe zamknięcie dostępu i analizę opartą na ryzyku. Zidentyfikowana podejrzana aktywność powinna uruchomić izolację i reagowanie na incydent. Potwierdzone przejęcie powinno prowadzić do pełnego ustalenia zakresu, odwołania poświadczeń, odzyskiwania, oceny obowiązku powiadomień i wyciągnięcia wniosków.

Pomaga to również uniknąć dwóch częstych błędów. Pierwszym jest samozadowolenie: „Nie znaleźliśmy złośliwego kontenera, więc ekspozycja była nieszkodliwa”. Drugim jest przesada: „Port 2375 był otwarty, więc całe środowisko na pewno zostało naruszone”. Dobre raportowanie bezpieczeństwa może być pilne, nie udając przy tym wiedzy większej niż ta, którą wspierają dowody.

Wątek AI jest drugorzędny, ale nadal użyteczny

Wykorzystanie frameworka agenta AI przez CARBONATO pokazuje, jak atakujący mogą pakować automatyzację, ale nie jest powodem, by traktować każdy komponent AI jako z natury złośliwy. Framework opisany przez Cloud Security Alliance jest oprogramowaniem open source i może mieć legalne zastosowania. Jego ponowne wykorzystanie w botnecie ilustruje znany wzorzec bezpieczeństwa: legalne oprogramowanie staje się częścią ataku, gdy przeciwnik kontroluje otaczające środowisko wykonawcze i konfigurację.

Obrońcy powinni więc dodać do dochodzenia zainstalowane oprogramowanie, pliki konfiguracyjne, zaplanowaną aktywność, miejsca docelowe połączeń wychodzących i dostępne poświadczenia. Szukanie wyłącznie nazwy produktu może pominąć zmodyfikowane wdrożenie albo zupełnie inny ładunek. Z drugiej strony zablokowanie nazwy legalnego frameworka bez usunięcia ekspozycji Dockera pozostawia otwartą pierwotną ścieżkę dostępu.

Szersza lekcja dotyczy granic automatyzacji. Framework AI działający na przejętym hoście może ułatwić elastyczne wykonywanie zadań, ale nie tworzy początkowych uprawnień. Uprawnienia pochodziły z demona Dockera. Silne uwierzytelnianie, segmentacja sieci, integralność hosta, higiena poświadczeń i użyteczne logi nadal pozostają kontrolami, które mają znaczenie.

Praktyczna lista kontrolna na najbliższy przegląd

Zespoły mogą przełożyć ten incydent na powtarzalny przegląd kontroli:

  • Zainwentaryzuj wszystkie demony Dockera i sieci, które mogą się z nimi łączyć.
  • Potwierdź, że żadne nieuwierzytelnione API Dockera nie jest wystawione do internetu ani niezaufanej sieci wewnętrznej.
  • Szukaj TCP 2375 i niestandardowych nasłuchów demona, a nie tylko oczekiwanych nazw usług.
  • Zastąp doraźną administrację TCP przez SSH albo prawidłowo skonfigurowany, wzajemnie uwierzytelniany TLS.
  • Ogranicz dostęp do gniazda Dockera i przejrzyj członkostwo w grupie docker.
  • Oddziel runnery CI od wrażliwych sieci produkcyjnych i poświadczeń.
  • Centralizuj logi Dockera, hosta, zapory, chmury, tożsamości i rejestrów.
  • Analizuj nieoczekiwane tworzenie kontenerów, ustawienia uprzywilejowane, montowania hosta, nowe obrazy i połączenia wychodzące.
  • Obróć poświadczenia, które mogły być odczytywalne z dotkniętych hostów lub obciążeń.
  • Odbuduj hosty, gdy ich integralności nie można ustalić z zaufanych nośników.
  • Dodaj ekspozycję demona i dryf konfiguracji do cyklicznych kontroli bezpieczeństwa.
  • Udokumentuj zatwierdzony sposób zdalnego zarządzania, aby inżynierowie nie tworzyli awaryjnych nasłuchów.

CARBONATO w odpowiednim momencie przypomina, że płaszczyzna sterowania platformą kontenerową sama jest zasobem krytycznym. Decydujące działanie obronne nie polega na spekulowaniu o nowatorstwie ładunku. Chodzi o sprawdzenie, kto może dotrzeć do demona, co demon może zrobić, co ostatnio zrobił i jakie tożsamości byłyby ujawnione, gdyby host został przejęty. Gdy te pytania stają się rutynowe, ryzykiem łatwiej zarządzać bez paniki i bez myślenia życzeniowego.

Źródła