Atakujący coraz częściej celują w klastry Kubernetes

Jak pisze zespół Microsoft Threat Intelligence w swoim nowym raporcie, aktorzy zagrożeń coraz częściej atakują niezabezpieczone klastry Kubernetes. Celem ataku może być dalsza eskalacja w środowisku informatycznym organizacji, wdrożenie ransomware lub ciche wydobywanie kryptowalut. Dynamiczna i złożona natura środowisk kontenerowych stwarza poważne wyzwania dla zespołów ds. bezpieczeństwa w zakresie wykrywania anomalii lub identyfikowania źródła naruszeń.

Rosnące zagrożenia w środowiskach kontenerowych

Według danych Microsoftu w ciągu ostatniego roku 51% tożsamości Kubernetes pozostało całkowicie nieaktywnych, co stworzyło podatny wektor ataku dla złośliwych podmiotów. Ta podatność jest spotęgowana przez rosnącą adopcję kontenerów jako usługi, co skłoniło Microsoft do ciągłego monitorowania i aktualizowania ram bezpieczeństwa, takich jak Threat Matrix for Kubernetes i macierz ATT&CK for Containers opracowana z MITRE w 2021 r.

Zasoby kontenerowe (w tym klastry, węzły, rejestry i obrazy kontenerów) są narażone na kilka różnych typów ataków. Aby w pełni zabezpieczyć środowiska Kubernetes, organizacje muszą zabezpieczyć kontenery i kod w nich uruchomiony, zależności systemu i biblioteki, potoki ciągłej integracji i ciągłego dostarczania (CI/CD), środowisko wykonawcze i inne poboczne elementy.

Zagrożenia w środowiskach Kubernetes według Microsoft mogą pochodzić z sześciu głównych obszarów:

• Skompromitowane konta. W przypadkach, gdy klastry Kubernetes są wdrażane w chmurach publicznych, takich jak Azure Kubernetes Service (AKS) lub Google Kubernetes Engine (GKE), naruszone poświadczenia do administrowania chmurą mogą doprowadzić do przejęcia klastra.
• Podatne lub nieprawidłowo skonfigurowane obrazy. Obrazy, które nie są regularnie aktualizowane, mogą zawierać dziury, które zostaną wykorzystane w złośliwych atakach.
• Błędne konfiguracje środowiska. Atakujący z dostępem do interfejsu API Kubernetes poprzez odsłonięte interfejsy zarządzania lub brak odpowiednich kontroli uwierzytelniania/autoryzacji może całkowicie wyłączyć serwer, wdrożyć złośliwe kontenery lub przejąć cały klaster.
• Ataki na poziomie aplikacji. Aplikacje mogą zostać wykorzystane dzięki kilku typowych metod, jak wstrzykiwanie kodu SQL, wykonywanie skryptów między witrynami i zdalne dołączanie plików.
• Ataki na poziomie węzła. Atakujący mogą uzyskać początkowy dostęp za pośrednictwem węzłów, czyli komputerów, na których działają kontenery. Węzły mogą być wektorem ataku, jeżeli działają na podatnym kodzie czy oprogramowaniu, mają otwarte interfejsy zarządzania (np. SSH) lub uruchamiają polecenia z poziomu płaszczyzny sterowania w chmurze.
• Nieautoryzowany ruch. Niezabezpieczona sieć między różnymi kontenerami w klastrze oraz między podami a światem zewnętrznym może być narażona na złośliwą aktywność bezpośrednio z sieci.

Całość dobrze przedstawia poniższa ilustracja:

Źródło: microsoft.com/en-us/security/blog

Studium przypadku: AzureChecker i ataki passwords spraying

Konkretny przypadek śledzony przez Microsoft jako Storm-1977 pokazuje wyrafinowanie powyżej opisanych ataków, szczególnie w sektorze edukacji.

Atakujący wdrożyli tutaj AzureChecker.exe, narzędzie wiersza poleceń, które pomogło im w przeprowadzaniu ataków password spraying na tenanty chmurowe. Poprzez połączenie się ze złośliwą domeną sac-auth[.]nodefunction[.]vip narzędzie pobrało zaszyfrowane listy celów i użyło kombinacji poświadczeń z pliku wejściowego accounts.txt. W jednym zaobserwowanym naruszeniu wykorzystano konto Gościa do utworzenia grupy zasobów w ramach atakowanej subskrypcji platformy Azure, co spowodowało utworzenie ponad 200 kontenerów przeznaczonych do złośliwego wydobywania kryptowalut.

Incydent podkreśla poważne konsekwencje niezabezpieczonych tożsamości i błędnie skonfigurowanych środowisk, w których atakujący mogą dyskretnie wykorzystywać ogromne zasoby obliczeniowe do generowania zysku.

Podsumowanie

Aby przeciwdziałać takim zagrożeniom, Microsoft opowiada się za najlepszymi praktykami, jak sprawdzenie kodu przed wdrożeniem przy użyciu specjalistycznych narzędzi, wymuszanie niezmiennych kontenerów w celu zapobiegania poprawkom w czasie wykonywania oraz wykorzystywanie kontrolerów dostępu do blokowania niezaufanych lub wymagających dużych zasobów wdrożeń.

Podczas produkcyjnego działania kodu najważniejsze znaczenie ma stałe monitorowanie złośliwych wywołań API i nietypowych działań dzięki np. XDR-a dedykowanego do Kubernetes. Oczywiście zabezpieczanie kont użytkowników i uprawnień ma pierwszorzędne znaczenie, a zalecenia dotyczą silnych metod uwierzytelniania, jak MFA i ścisłych kontroli dostępu opartych na rolach (RBAC). Utwardzanie sieci jest równie ważne, a podstawowe strategie, na których powinno budować się bezpieczeństwo w sieci to m.in. ograniczanie dostępu do serwera API przez zapory, wdrażanie zasad sieciowych Kubernetes i korzystanie z dostępu Just-In-Time (JIT).

Wraz ze wzrostem adopcji kontenerów powyższe środki są niezbędne, aby uniemożliwić hakerom wykorzystywanie Kubernetesa do złośliwych celów, zapewniając organizacjom ochronę swoich zasobów cyfrowych przed zmieniającym się krajobrazem zagrożeń.