Metadane i SSRF

Każda chmurowa maszyna wirtualna może odpytać specjalny wewnętrzny endpoint, aby uzyskać informacje o sobie: Instance Metadata Service (IMDS). Co istotne, usługa może również udostępniać tymczasowe dane uwierzytelniające roli przypisanej do instancji.

• W AWS, GCP i Azure metadane są dostępne pod adresem 169.254.169.254
• Można uzyskać do nich dostęp wyłącznie z wnętrza instancji
• Lokalne procesy nie wymagają uwierzytelniania

To udogodnienie staje się narzędziem ataku w połączeniu z SSRF.

W starszej wersji IMDSv1 pojedyncze żądanie GET zwraca metadane, w tym dane uwierzytelniające roli. Token nie jest potrzebny.

Właśnie dlatego IMDSv1 jest niebezpieczne, gdy aplikacja jest podatna na SSRF.

Server-Side Request Forgery (SSRF) to podatność, w której atakujący nakłania serwer do wykonywania żądań HTTP w jego imieniu. Serwer staje się proxy umożliwiającym dostęp do miejsc, do których atakujący nie może dotrzeć bezpośrednio.

• Parametr URL pobierany przez serwer
• Webhook, generator PDF lub funkcja zmiany rozmiaru obrazu
• Dowolny element przyjmujący URL podany przez użytkownika

Klasycznym celem SSRF w chmurze jest endpoint metadanych.

To wyjątkowo groźne połączenie: aplikacja podatna na SSRF pozwala atakującemu skierować serwer do 169.254.169.254. Serwer pobiera dane uwierzytelniające IAM instancji i zwraca je.

Atakujący uzyskuje wtedy dane uwierzytelniające do chmury, co często stanowi początek przejęcia całego konta.

Odpowiedź metadanych zawiera klucz dostępu, klucz tajny i token sesji. Atakujący eksportuje je i natychmiast działa jako rola instancji.

Następnie analizuje uprawnienia i szuka sposobów ich eskalacji.

Firma AWS wprowadziła IMDSv2, aby ograniczyć skuteczność SSRF. Wymaga ona najpierw uzyskania tokenu sesji za pomocą żądania HTTP PUT, którego większość mechanizmów SSRF nie potrafi wykonać, ponieważ obsługują tylko GET.

Wymuszenie IMDSv2 i ustawienie niskiego limitu przeskoków znacznie ogranicza kradzież metadanych za pośrednictwem SSRF.

Pozostali dostawcy również udostępniają metadane, choć każdy z nich ma własne szczegóły działania. Obaj wymagają specjalnego nagłówka, co samo w sobie stanowi niewielkie zabezpieczenie przed SSRF.

• Azure wymaga nagłówka Metadata: true
• GCP wymaga nagłówka Metadata-Flavor: Google

Obrońcy często blokują adres 169.254.169.254. Atakujący omijają naiwne filtry za pomocą alternatywnych zapisów adresów IP i przekierowań.

• Dziesiętny zapis IP: 2852039166
• Ósemkowe i szesnastkowe zapisy tego samego adresu
• DNS rebinding do nazwy rozwiązującej się na adres IP metadanych
• Otwarte przekierowania kierujące żądanie do URL metadanych

Solidne zabezpieczenia muszą weryfikować rozpoznany adres IP, a nie surowy ciąg znaków.

Metadane są najważniejszym celem, ale SSRF umożliwia dostęp do większej liczby wewnętrznych zasobów:

• Wewnętrzne panele administracyjne i pulpity dostępne na localhost
• Wewnętrzne bazy danych i pamięci podręczne (Redis, Elasticsearch)
• Serwer API Kubernetes i endpointy kubelet
• Inne mikrousługi, które nie są wystawione na zewnątrz

SSRF skutecznie przebija granicę sieci z zaufanego punktu dostępu.

Przerwanie łańcucha SSRF prowadzącego do metadanych wymaga wielowarstwowej ochrony:

• Wymuszenie IMDSv2 i ustawienie limitu przeskoków metadanych na 1
• Weryfikowanie i umieszczanie na allowliście wychodzących URL-i w funkcjach pobierania
• Blokowanie żądań do zakresów adresów link-local i prywatnych po rozpoznaniu DNS
• Stosowanie zasady najmniejszych uprawnień wobec ról instancji, aby ograniczyć skutki kradzieży danych uwierzytelniających

Role z minimalnymi uprawnieniami sprawiają, że nawet skuteczna kradzież przynosi niewielkie korzyści.

Testy SSRF mogą z założenia docierać do poufnych systemów wewnętrznych. Należy zachować dyscyplinę:

• Potwierdzić, że docelowy host i konto w chmurze są objęte zakresem
• Nie wykonywać ruchu do systemów spoza zakresu zlecenia
• Przerwać testy i zgłosić wynik po potwierdzeniu dostępu do danych uwierzytelniających

Dostęp do metadanych ma duży wpływ na bezpieczeństwo, dlatego należy wykazać go ostrożnie i nie wykorzystywać bez ograniczeń skradzionych kluczy.

Poznali Państwo najistotniejszy łańcuch ataku charakterystyczny dla chmury.

• Usługa metadanych pod adresem 169.254.169.254 udostępnia dane uwierzytelniające roli instancji
• SSRF pozwala atakującemu nakłonić serwer do pobrania tego endpointu
• Skradzione tymczasowe dane uwierzytelniające umożliwiają przejęcie konta
• IMDSv2 blokuje większość ataków SSRF, wymagając tokenu uzyskiwanego za pomocą PUT
• Należy stosować allowlisty URL-i, weryfikację adresów IP i role z minimalnymi uprawnieniami

To kończy kurs Cloud Pentesting. Następny kurs: Bug Bounty Hunting.