Prometheus – setki tysięcy niezabezpieczonych serwerów dostępne dla każdego
Prometheus to otwartoźródłowe narzędzie służące głównie do monitorowania systemów IT i alertowania o zagrożeniach. Stosowane jest szczególnie w środowiskach chmurowych oraz kontenerowych, współpracuje z tzw. eksporterami, które zbierają dane z różnych komponentów systemowych a następnie przesyłają je do serwera Prometheusa. Okazuje się, że do bardzo wielu serwerów może się dostać każdy.
Według analizy przeprowadzonej przez firmę AquaSec (https://www.aquasec.com/blog/300000-prometheus-servers-and-exporters-exposed-to-dos-attacks/) serwery Prometheus są wystawiane do internetu bez żadnych zabezpieczeń! Problem wynika z domyślnych ustawień, nie wymagających uwierzytelniania i pozwalającyh na otwarty dostęp do danych monitorujących. Może prowadzić to do kradzieży informacji, ataków DDoS, czy eskalacji zagrożeń. O jakim poziomie zagrożenia mówimy? O przeszło 300 tysiącach urządzeń!
Łatwy cel dla przestępców
Prometheus to standard monitorowania systemów chmurowych, jak Kubernetes czy Docker. Okazuje się jednak, że administratorzy zbyt często pozostawiają instancje Prometheusa z domyślnymi ustawieniami, co sprawia, że serwer otwarty jest na połączenia z dowolnych adresów IP, stając się łatwym celem dla wielu cyberprzestępców.
Podążając za raportem Aqua Nautilius zweryfikowaliśmy sieć w poszukiwaniu serwerów Prometheus. Okazało się, że wiele z wystawionych serwerów:
- nie posiada skonfigurowanego uwierzytelniania
- nie jest chronionych przez firewalla
- obsługuje dane wrażliwe, tj. statystyki CPU, RAM, ruchu sieciowego oraz informacje o procesach, które mogą zostać użyte do dalszej eksploracji sieci oraz planowania ataków
Jakie zagrożenia idą za taką dziurawą polityką bezpieczeństwa? Publicznie dostępne serwery Prometheus w Internecie narażają wiele organizacji na potencjalne ataki. Wśród nich np. ataki DDoS,gdy dostępne serwery Prometheus (szczególnie te z dużą ilością danych) mogą zostać zalane ogromną liczbą zapytań. To prowadzi do wyczerpania zasobów na atakowanym serwerze oraz braku możliwości jego monitorowania. Kolejne ryzyko to kradzież danych, gdy atakujący mogą uzyskać dostęp do szczegółowych statystyk infrastruktury, jak m.in.:
- informacje na temat użycia CPU, pamięci i dysku
- dane o procesach systemowych oraz ich zasobach
- informacje o uruchomionych aplikacjach (co może wskazać potencjalne słabe punkty systemu)
Znajomość takich danych może ułatwić przestępcom zaplanowanie bardziej zaawansowanych ataków, jak instalacja malware, przejęcie systemu lub zakłócenie działania krytycznych procesów. Kolejnym krokiem może być kradzież danych, a będące jej efektem rysy na reputacji firmy to skutki wyjątkowo trudne to usunięcia.
Jak wygląda atak na podatny serwer Prometheus?
Prometheus oferuje REST API, które pozwala m.in. na pobieranie metryk za pomocą zapytań typu GET, wykonując złożone zapytanie za pomocą języka zapytań PromQL (Prometheus Query Language) oraz zarządzanie danymi monitoringu.
Jeśli serwer Prometheus jest dostępny publicznie bez zabezpieczeń, każdy użytkownik znający adres IP serwera może wykonywać dowolne zapytania do API.
Atak DDoS polega na zalewaniu serwera dużą liczbą żądań, które wymagają intensywnego przetwarzania. W przypadku Prometheus, szczególnie podatne są zapytania PromQL, które angażują duże ilości zasobów, takich jak pamięć operacyjna i procesor.
Pierwszym krokiem ataku jest identyfikacja celu. Atakujący skanują sieć, aby znaleźć publicznie dostępne serwery Prometheus. Narzędzia takie jak Shodan czy Censys mogą szybko wykryć serwery na domyślnych portach (w przypadku tego narzędzia – 9090).
Potem następuje generowanie zapytań. Przestępcy używają botnetów (sieci zainfekowanych urządzeń) lub dedykowanych skryptów do generowania masowych zapytań do serwera. Popularne narzędzia do przeprowadzania ataków DDoS takie jak np LOIC (Low Orbit Ion Cannon) lub HOIC (High Orbit Ion Cannon) mogą być skonfigurowane do wysyłania żądań HTTP do API Prometheus.
W tym celu można też wykorzystać PromQL, tworząc zapytania do danych monitorowania. Przykładowo:
rate(http_requests_total[5m])
Powyższe zapytanie oblicza średnią liczbę żądań HTTP w ciągu ostatnich 5 minut.
Zaawansowane zapytania mogą jednak wymagać analizy ogromnych ilości danych, szczególnie jeśli serwer Prometheus obsługuje setki eksporterów i zbiera tysiące metryk. Można np. celowo generować zapytania PromQL, przeszukujące duże zakresy czasowe lub agregujące dane z wielu źródeł, np.:
sum(rate(cpu_usage_seconds_total[30d]))
W powyższym przypadku mamy już do czynienia z zapytaniem, wymagającym analizy 30 dni danych historycznych, co może łatwo przeciążyć atakowany serwer. Serwer Prometheus zużywa nadmierne zasoby (CPU i RAM), próbując obsłużyć zapytania. Jeśli liczba ich jest wystarczająco duża, wtedy serwer może stać się niedostępny dla innych użytkowników lub całkowicie się zawiesić.
Jak wykorzystać PromQL w atakach?
- stosować w zapytaniach funkcje agregujące, takie jak sum, avg, czy count; wymagają one dużej mocy obliczeniowej, zwłaszcza gdy dane są zbierane z wielu eksporterów
- używać rozszerzonych zakresów czasowych; im dłuższy zakres czasowy w zapytaniu, tym więcej danych musi przetworzyć Prometheus
Oto przykładowe zapytanie obejmujące dane z zakresu 1 roku:
rate(http_requests_total[1y])
Filtrowanie oraz grupowanie, dodanie etykiet i filtrów do zapytań zwiększa ich złożoność,
sum by (instance) (rate(network_bytes_sent[1h]))
Takie zapytania wymagają grupowania danych według poszczególnych instancji, co dodatkowo obciąża atakowany serwer.
Jak wykorzystać atak na eksportery?
Eksportery to komponenty, które przesyłają dane do serwera Prometheus. Atakujący mogą także wysyłać masowe zapytania bezpośrednio do eksporterów, co powoduje przeciążenie również ich zasobów bądź fałszować dane, które eksporter przesyła do Prometheus, co może prowadzić do błędnej analizy monitorowanych systemów.
Potencjalne scenariusze wykorzystania
Atakujący może użyć serwerów Prometheus jako narzędzia do mapowania danej infrastruktury IT. Analizując metryki może zidentyfikować najbardziej podatnych na kolejne ataki elementy systemu.
Wspominane już ataki DDoS spowodują przeciążenie serwera, w wyniku czego Prometheus przestaje działać. To uniemożliwia monitorowanie systemu, a w krytycznych sytuacjach, takich jak awarie, brak monitoringu może prowadzić do katastrofalnych skutków.
Przeciążenie infrastruktury. Atak na serwer monitorowania może wpłynąć na inne komponenty infrastruktury, np. eksportery, które zaczynają wysyłać nadmierną liczbę żądań.
Jak wyglądają przykładowe żądania API i ich wykorzystanie:
Pobieranie wszystkich dostępnych metryk. Żądanie:
GET /api/v1/label/__name__/values
zwraca listę wszystkich metryk dostępnych na serwerze Prometheus. Każda z nich jest związana z konkretnym eksporterem lub aplikacją, co pozwala atakującemu określić, jakie usługi i systemy są monitorowane.
Przykładowa odpowiedź od serwera:
[
"node_cpu_seconds_total",
"http_requests_total",
"go_gc_duration_seconds",
"mysql_connections",
"disk_usage_bytes"
]
Na podstawie nazw metryk haker może zidentyfikować:
- monitorowane aplikacje, np. MySQL, PostgreSQL, Redis
- systemy operacyjne, dzięki metrykom eksportera Node (np. node_cpu_seconds_total)
- działające aplikacje w kontenerach, np. docker_container_memory_usage_bytes
Pobieranie szczegółowych danych metryki. Żądanie:
GET /api/v1/query?query=node_cpu_seconds_total
pobiera dane dotyczące konkretnej metryki w czasie rzeczywistym.
Przykładowa odpowiedź od serwera:
{
"status": "success",
"data": {
"resultType": "vector",
"result": [
{
"metric": {
"instance": "192.168.1.10:9100",
"job": "node-exporter"
},
"value": [1689682373.123, "0.12345"]
}
]
}
}
Zastosowanie przez atakującego:
- zidentyfikowanie adresu IP (192.168.1.10) i portu eksportera (9100)
- mapowanie monitorowanych hostów i ich szczegółowych danych wydajnościowych
Pobieranie listy monitorowanych endpointów. Żądanie:
GET /api/v1/targets
zwraca listę wszystkich endpointów monitorowanych przez serwer Prometheus. Daje szczegółowe informacje o stanie każdej instancji.
Przykładowa odpowiedź od serwera:
{
"activeTargets": [
{
"discoveredLabels": {
"__address__": "192.168.1.20:8080",
"job": "web-server"
},
"health": "up",
"lastScrape": "2024-12-17T12:00:00Z"
},
{
"discoveredLabels": {
"__address__": "192.168.1.30:6379",
"job": "redis"
},
"health": "up",
"lastScrape": "2024-12-17T12:00:10Z"
}
]
}
Zastosowanie przez atakującego:
- zidentyfikowanie adresów IP oraz portów serwisów w sieci wewnętrznej
- rozpoznanie rodzaju aplikacji, np. Redis (6379), serwer WWW (8080)
- określenie, które usługi są aktywne (health: „up”)
Pobieranie informacji o konfiguracji serwera. Żądanie:
GET /api/v1/status/config
zwraca konfigurację serwera Prometheus, w tym szczegóły dotyczące źródeł danych (eksporterów) i reguł monitorowania.
Przykładowa odpowiedź od serwera:
global:
scrape_interval: 15s
scrape_configs:
- job_name: "web-server"
static_configs:
- targets: ["192.168.1.20:8080"]
- job_name: "redis"
static_configs:
- targets: ["192.168.1.30:6379"]
Zastosowanie przez atakującego:
- odczytanie szczegółowej konfiguracji infrastruktury monitorowanej
- ustalanie priorytetowych celów dla dalszych ataków (np. na Redis lub serwery WWW)
Wydobycie danych historycznych. Żądanie:
GET /api/v1/query_range?query=node_cpu_seconds_total&start=1689682373&end=1689682973&step=60
pobiera dane historyczne dla określonej metryki w danym zakresie czasu.
Przykładowa odpowiedź od serwera:
{
"status": "success",
"data": {
"resultType": "matrix",
"result": [
{
"metric": {
"instance": "192.168.1.10:9100",
"job": "node-exporter"
},
"values": [
[1689682373, "0.12345"],
[1689682433, "0.23456"]
]
}
]
}
}
Zastosowanie przez atakującego
- analiza obciążenia systemu w określonych godzinach, co pozwala zidentyfikować „słabe punkty” w wydajności infrastruktury
Jak można wykorzystać pozyskane dzięki podatności dane?
Mapowanie infrastruktury sieciowej. Na podstawie adresów IP i portów uzyskanych z API można zbudować dokładną mapę sieci, w tym lokalizację kluczowych usług, takich jak bazy danych czy serwery WWW.
Przygotowanie ataków ukierunkowanych. Znając szczegóły monitorowanych systemów, atakujący jest w stanie:
- wykonywać ataki brute-force na znane usługi (np. SSH, Redis)
- próbować exploitować znane podatności w monitorowanych aplikacjach
- zidentyfikować systemy bez aktualizacji lub z przestarzałym oprogramowaniem
Ponieważ domyślne ustawienia Prometheusa zakładają brak uwierzytelniania, jego interfejs API pozostaje nadal otwarty. Brak odpowiedniej konfiguracji stanowi duże zagrożenie, a publiczne wystawienie serwera na świat jest niczym pozostawienie kluczy w drzwiach mieszkania. To proszenie się o problem. Dla każdego kto korzysta z narzędzia takiego jak Prometheus, choć niezwykle przydatnego, niezbędne jest jego staranne skonfigurowanie oraz regularne monitorowanie.
Jakie konsekwencje mogą stać za źle zabezpieczonym Serwerem Prometheus?
- każdy kto uzyska dostęp do adresu serwera po URL może zdalnie w pełni wykonywać zapytania do bazy danych
- eksportery przesyłają dane bez szyfrowania (HTTP zamiast HTTPS), co może doprowadzić do przechwycenia całości ich w ruchu sieciowego
- eksportery Prometheus (np. Node Exporter czy cAdvisor) również mogą być wystawione na świat, ponieważ każdy eksporter generuje szczegółowe dane o monitorowanym systemie, co stanowi kolejne źródło informacji dla potencjalnych atakujących
Jak zminimalizować potencjalnie problemy oraz zagrożenia?
- wdroż firewall, który pomoże ograniczyć dostęp sieciowy do serwera tylko dla wskazanych adresów IP
- utrzymuj aplikację Prometheus tylko w sieci wewnętrznej, zablokowanej przed dostępem z zewnątrz
- wprowadź uwierzytelnianie przez odpowiednią konfigurację serwera z obsługą TLS (HTTPS) oraz autoryzacją za pomocą certyfikatów
- wdroż proxy z funkcją uwierzytelniania (np. Nginx lub Traefik)
- włącz szyfrowaną komunikację z użyciem protokołu HTTPS dla wszystkich połączeń
- jeśli eksportery znajdują się w innych sieciach, użyj szyfrowanych kanałów komunikacji, np. VPN
- aktualizuj regularnie aplikację Prometheus i eksportery, dzięki czemu usuniesz znane podatności
- monitoruj dostęp, co umożliwi rejestrowanie wszystkich połączeń do serwera Prometheus poprzez używanie systemów wykrywania intruzów (IDS) oraz do identyfikacji podejrzanych aktywności
Uwaga! Podane w tekście kody zostały stworzone na potrzeby zilustrowania potencjalnych ryzyk, związanych z możliwościami wykorzystania podatności. Nie rób tego w domu 😉
Iwo Graj