Ponad 300 tysięcy instancji Prometheus podatnych na ataki DDoS i RepoJacking

Ponadto zidentyfikowano ryzyko ataków DoS, wynikające z ujawnienia punktów końcowych debugowania pprof, które po wykorzystaniu mogą przeciążyć i spowodować awarię serwerów Prometheus, kontenerów Kubernetes i innych hostów.

Dalsze dochodzenie ujawniło ryzyko zdalnego wykonania kodu z powodu luki w zabezpieczeniach zwanej „RepoJacking”, w ramach której złośliwi eksporterzy mogą zostać wprowadzeni na ścieżkę ataku za pośrednictwem porzuconych lub przemianowanych repozytoriów GitHub.

Z przedstawionych danych wynika, że co najmniej 336 000 hostów udostępnia swoje serwery i eksportery Prometheus do Internetu – praktyka ta stwarza znaczne ryzyko dla bezpieczeństwa.

Czym jest ekosystem Prometeusz?

Prometheus to zestaw narzędzi do monitorowania i alarmowania typu open source, który stał się podstawą nowoczesnych strategii monitorowania. Jego bazowa architektura obejmuje regularne pobieranie metryk ze źródeł, przechowywanie ich lokalnie w szeregowej bazie danych i dostarczanie potężnego języka zapytań, PromQL, do analizy danych w czasie rzeczywistym. System jest modułowy, z komponentami takimi jak Alertmanager do obsługi alertów i Grafana do wizualizacji, co czyni go idealnym dla dynamicznych środowisk, jak na przykład Kubernetes.

Eksportery to komponenty instalowane w różnych systemach. Służą do zbierania metryk z monitorowanych punktów końcowych, umożliwiając Prometheusowi pobieranie i przechowywanie danych z systemów, aplikacji lub usług, które nie udostępniają natywnie metryk w formacie Prometheus.

Skala zagrożenia

Zgodnie z dokumentacją Prometheusa zakłada się, że niezaufani użytkownicy mogą przeglądać informacje o jego usłudze, w szczególności punkt końcowy HTTP Prometheusa, dzienniki i informacje debugowania. Chociaż ekosystem obsługuje uwierzytelnianie użytkowników, warto zadać sobie pytanie, czy administratorzy zawsze udostępniają serwer Prometheus lub jego eksportery w Internecie z wymaganych uwierzytelnieniem.

Wystarczy użyć Shodan, wyszukiwarki zaprojektowanej do identyfikowania urządzeń podłączonych do Internetu, by przeanalizować obecność publicznie dostępnych serwerów i eksporterów Prometheusa. Aqua Team ustaliło, że ponad 296 000 eksporterów skierowanych do Internetu i 40 000 serwerów Prometheusa (łącznie około 336 000 serwerów) było kilka dni temu narażonych na potencjalne ryzyko.

Jakie podatności wykryto?

Podczas analizy stwierdzono, że publiczny punkt końcowy „/metrics” może nie tylko ujawnić wewnętrzne endpointy API, ale także dane o subdomenach, rejestrach Docker i obrazach – wszystkie informacje cenne dla atakującego przeprowadzającego rozpoznanie i chcącego rozszerzyć swój zasięg w sieci.

To nie wszystko. Przeciwnik może wysłać wiele równoczesnych żądań do punktów końcowych, takich jak „/debug/pprof/heap” i uruchomić zadania profilowania sterty intensywnie wykorzystujące procesor i pamięć, które mogą przeciążyć serwery i spowodować ich awarię. Mamy więc przepis na gotowy atak Denial of Service.

Aqua zwróciła również uwagę na zagrożenie dla łańcucha dostaw, które dotyczy wykorzystania technik repojackingu. Atakujący może tutaj wykorzystać nazwę powiązaną z usuniętymi lub zmienionymi nazwami repozytoriów GitHub i dzięki temu wprowadzić złośliwych zewnętrznych eksporterów. Konkretnie odkryto, że osiem eksporterów wymienionych w oficjalnej dokumentacji Prometheusa jest podatnych na RepoJacking, co pozwala atakującemu na odtworzenie eksportera o tej samej nazwie i hostowanie złośliwej wersji.

Podsumowanie

W omówionym wyżej odkryciu pokazano podatności i wady w stosie Prometheus. Podkreślono ryzyko związane z udostępnianiem serwerów i eksporterów Prometheus w Internecie bez konieczności uwierzytelniania. Takie działanie ujawnia poufne informacje i może być wykorzystane do przeprowadzania ataków DoS lub nawet wykonywania dowolnego kodu za pośrednictwem skompromitowanych eksporterów.

Zalecamy organizacjom podjęcie następujących kroków w ramach ochrony:

• Uwierzytelnianie i autoryzacja: Serwery i eksportery Prometheus powinny być chronione odpowiednimi mechanizmami uwierzytelniania, co da pewność, że tylko autoryzowani użytkownicy mogą uzyskać dostęp do poufnych danych lub wewnętrznych elementów systemu.
• Ograniczenie zewnętrznego ryzyka: Prometheus powinien być wdrażany w sposób minimalizujący narażenie na publiczny Internet. W przypadkach, gdy konieczny jest dostęp zewnętrzny, należy używać bezpiecznych kanałów komunikacyjnych (np. VPN lub sieci prywatnych). Taka strategia znacznie ograniczy liczbę osób, które mogą uzyskać dostęp do usług.
• Monitorowanie i zabezpieczanie punktów końcowych „debug”: Punkt końcowy /debug/pprof, który może być wykorzystywany do ataków DoS, nie powinien być publicznie ujawniany. Dostęp do punktów końcowych debugowania i profilowania powinien być ograniczony wyłącznie do użytku wewnętrznego lub wyłączony w środowiskach produkcyjnych.
• Ograniczenie wyczerpania zasobów: Zdecydowanie zalecamy wprowadzenie zabezpieczeń ograniczających wyczerpanie zasobów, takich jak ograniczenia procesora i pamięci RAM, które mogą zapobiec atakowi DoS wysycającemu zasoby lub zminimalizować zdolność atakujących do jego przeprowadzenia.
• Weryfikacja linków open source : Aby zapobiec atakom na łańcuch dostaw, takim jak RepoJacking, upewnij się, że łącza, z których pobierasz projekt, są zweryfikowane i oryginalne.