Poświadczenia i konfiguracje Kubernetes kilku firm z Fortune 500 ujawnione w publicznych repozytoriach

Kubernetes Secrets – co to jest?

Na oficjalnej stronie Kubernetes, Kubernetes.io, znajduje się obszerna sekcja poświęcona konfiguracji Sekretów w Kubernetesie. Wyraźnie wspomniano, że „Kubernetes Secrets są domyślnie przechowywane w postaci niezaszyfrowanej w podstawowym magazynie danych serwera API”. Użytkownicy mogą utworzyć plik YAML dla wpisów tajnych przy użyciu kubectl lub ręcznie utworzyć plik i przesłać go do klastra.

Jak przedstawiono w tabeli poniżej, Kubernetes obsługuje osiem wbudowanych typów sekretów. Omawiane badania skupiały się głównie na dwóch typach: dockercfg i dockerconfigjson. Chociaż wszystkie typy sekretów z natury zawierają poufne informacje, potencjał ich wykorzystania jest różny. Sekrety takie jak basic-auth, tls i ssh-auth mogą odnosić się do usług zewnętrznych połączonych z klastrem. Jednak ich wykorzystanie wymaga odnalezienia adresu IP lub adresu URL powiązanego z klastrem, co może być trudne i wymagać większych zasobów. Service-account-token jest bardziej odpowiedni dla usług wewnętrznych i może być cennym zasobem dla ruchu post-exploit i lateral movement w sieci. Jednak jego wykorzystanie z zewnętrznego punktu widzenia jest trudniejsze. Jeśli chodzi o bootstrap.kubernetes.io/token, przeprowadzono szczegółowe dochodzenie, ale nie odkryto w badaniach niczego wartego uwagi. Wreszcie typ „Opaque” jest zbyt ogólny, aby wskazać szereg scenariuszy wyzysku, co czyni go potencjalnym przedmiotem przyszłych badań.

Jak już wcześniej wspomniano, badania z Aqua Nautilus ostatecznie skupiły się na tajemnicach typu dockercfg i dockerconfigjson, ponieważ są one specjalnie przeznaczone do przechowywania danych uwierzytelniających umożliwiających dostęp do rejestrów zewnętrznych.

Nieumyślne umieszczanie Sekretów na GitHubie

W badaniach wykorzystano interfejs API GitHub, stosując iteracje rekurencyjne, aby ominąć ograniczenia do 1000 wyników. Szukano różnych kluczy, stosując złożone wyrażenia regularne, aby zawęzić zakres do konkretnych wystąpień plików YAML zawierających dockercfg lub dockerconfigjson z sekretami zakodowanymi w formacie base64.

Odkryto setki przypadków w repozytoriach publicznych, co podkreśliło powagę problemu, dotykającego zarówno osoby prywatne, projekty open source, jak i duże organizacje. Nasuwa się pytanie: dlaczego ktoś miałby świadomie przesyłać te sekrety do GitHuba?

Istnieje kilka uzasadnionych powodów, takich jak przesyłanie plików Kubernetes YAML w celu kontroli wersji, udostępnianie szablonów lub przykładów oraz zarządzanie konfiguracjami publicznymi.

Zdarzały się też przypadki, że z powodu nieporozumienia lub błędu praktycy nieumyślnie przesłali sekrety do publicznie dostępnych repozytoriów GitHub. Biorąc pod uwagę znaczną liczbę zakodowanych sekretów w porównaniu z sekretami w postaci zwykłego tekstu, podejrzewamy, że niektórzy inżynierowie z powodu nieporozumień lub braku wiedzy omyłkowo przesyłają zakodowane sekrety, myśląc, że są bezpieczne lub trudne do odkodowania. Nie zdają sobie sprawy, że z punktu widzenia bezpieczeństwa kodowanie base64 jest równoznaczne ze zwykłym jawnym tekstem.

Zakres ujawnionych danych

Spośród wszystkich 438 rekordów, które potencjalnie zawierały ważne dane uwierzytelniające do rejestrów, 203 rekordy – około 46% – zawierały dane uwierzytelniające umożliwiające bezpośredni dostęp do odpowiednich rejestrów. 93 hasła zostały ustawione ręcznie przez pojedyncze osoby, w przeciwieństwie do 345, które zostały wygenerowane komputerowo.

Poniżej lista wyodrębnionych sekretów z podziałem na rejestry dostępowe, których dotyczą:

„W większości przypadków dane uwierzytelniające umożliwiały zarówno wykonanie poleceń typu pull, jak i push” – zauważyli badacze. „Co więcej, w większości tych rejestrów często odkrywaliśmy obrazy prywatnych kontenerów”.

Co więcej, prawie 50% z 93 haseł uznano za słabe. Obejmowało to między innymi hasła, test123456, Windows12, ChangeMe i dockerhub.

Widać, jak krytyczne jest stworzenie polityki dotyczącej haseł w organizacji dla środowisk Dockerowych.

Aqua stwierdziła, że znalazła również przypadki, w których organizacje nie usuwały tajemnic z plików przechowywanych w publicznych repozytoriach na GitHubie, co prowadziło do niezamierzonego ujawnienia danych.

Pozytywnym akcentem jest jednak to, że wszystkie dane uwierzytelniające powiązane z AWS i Google Container Registry (GCR) okazały się tymczasowe i wygasły, co uniemożliwia dostęp. W podobnym duchu GitHub Container Registry wymagał uwierzytelniania dwuskładnikowego (2FA) jako dodatkowej warstwy chroniącej przed nieautoryzowanym dostępem.

Według raportu Red Hat o stanie bezpieczeństwa Kubernetes opublikowanego na początku tego roku, luki w zabezpieczeniach i błędne konfiguracje okazały się głównymi problemami związanymi z bezpieczeństwem środowisk kontenerowych, przy czym 37% z łącznej liczby 600 respondentów zidentyfikowało przychody/stratę klientów w wyniku incydentu związanego z bezpieczeństwem kontenera i Kubernetes.