Amazon GuardDuty usprawnia wykrywanie eksfiltracji poświadczeń instancji EC2

Amazon GuardDuty to usługa wykrywania zagrożeń, która stale monitoruje złośliwą aktywność i nieautoryzowane zachowanie w celu ochrony kont AWS, obciążeń i danych przechowywanych w Amazon Simple Storage Service (Amazon S3).

Poinformowany o wielu publicznych i generowanych przez AWS źródłach danych i zasilany przez uczenie maszynowe, Amazon GuardDuty analizuje miliardy zdarzeń w poszukiwaniu trendów, wzorców i anomalii, które są rozpoznawalnymi znakami, że coś jest nie tak. Możesz go włączyć jednym kliknięciem i zobaczyć pierwsze wyniki w ciągu kilku minut.

Niedawno AWS dodał do GuardDuty możliwość wykrywania, kiedy poświadczenia instancji Amazon Elastic Compute Cloud (Amazon EC2) są używane z innego konta AWS. Poświadczenia instancji EC2 to tymczasowe poświadczenia udostępniane za pośrednictwem usługi metadanych EC2 wszystkim aplikacjom uruchomionym na instancji, gdy jest do niej przypisana rola AWS Identity and Access Management (IAM).

Jakie są zagrożenia?

Gdy Twoje workloady wdrożone w instancjach EC2 uzyskują dostęp do usług AWS, używają klucza dostępu, tajnego klucza dostępu i tokenu sesji. Bezpieczny mechanizm przekazywania poświadczeń klucza dostępu do obciążeń polega na zdefiniowaniu uprawnień wymaganych przez workload, utworzeniu jednej lub kilku polityk IAM z uprawnieniami, dołączeniu zasad do roli uprawnień IAM i wreszcie przypisaniu roli do instancji.

Każdy proces działający na instancji EC2 z dołączoną rolą może pobrać dane uwierzytelniające, wywołując usługę EC2 metadata service v2:

Poświadczenia te ograniczone są w czasie i zakresie. Są ważne maksymalnie przez sześć godzin. Ograniczają się one do zakresu uprawnień związanych z rolą IAM związaną z instancją EC2. Token uzyskany przez pierwsze polecenie jest ważny tylko w instancji, na której został wygenerowany.

Wszystkie pakiety AWS SDK są w stanie automatycznie pobierać i odnawiać takie dane uwierzytelniające. W Twojej aplikacji nie jest potrzebny dodatkowy kod.

Teraz wyobraź sobie, że Twoja aplikacja działająca na instancji EC2 jest zainfekowana, a złośliwy podmiot zdołał uzyskać dostęp do usługi metadanych instancji. Atakujący potrafi wyodrębnić dane uwierzytelniające. Te poświadczenia mają uprawnienia zdefiniowane w roli uprawnień IAM dołączonej do instancji. W zależności od aplikacji osoby atakujące mogą mieć możliwość eksfiltracji danych z S3 lub DynamoDB, uruchomienia lub terminacji instancji EC2, a nawet utworzenia nowych użytkowników lub ról uprawnień IAM.

Od czasu uruchomienia GuardDuty, usługa ta wykryła kiedy takie poświadczenia są używane z adresów IP spoza AWS. Sprytni napastnicy mogą zatem ukryć swoją aktywność za innym kontem AWS, aby działać poza zasięgiem GuardDuty. Od dzisiaj GuardDuty wykrywa również, kiedy poświadczenia są używane z innych kont AWS w sieci AWS.

Jakie alerty są generowane?

Istnieją uzasadnione powody, dla których źródłowy adres IP komunikujący się z interfejsami API usług AWS może być inny niż adres IP instancji EC2. Pomyśl o złożonych topologiach sieci, które kierują ruch do jednego lub wielu VPC; na przykład AWS AWS Transit Gateway lub AWS Direct Connect. Ponadto konfiguracje obejmujące wiele regionów lub niekorzystanie z AWS Organizations, sprawiają, że wykrycie czy konto AWS korzystające z poświadczeń należy do Ciebie, czy nie, nie jest proste. Duże firmy wdrożyły własne rozwiązanie do wykrywania takich zagrożeń bezpieczeństwa, ale tego typu rozwiązania nie są łatwe do zbudowania i utrzymania. Tylko kilka organizacji dysponuje zasobami wymaganymi do sprostania temu wyzwaniu. Kiedy to robią, odwracają uwagę inżynierów od podstawowej działalności. Dlatego AWS postanowił się tym zająć.

Od niedawna GuardDuty generuje alerty, gdy wykryje nadużycie poświadczeń instancji EC2. Gdy poświadczenia są używane z konta powiązanego, alert jest oznaczony jako o średniej wadze. W przeciwnym razie generowany jest alert o wysokim stopniu ważności. Konta powiązane to konta monitorowane przez to samo konto administratora GuardDuty, znane również jako konta członkowskie GuardDuty. Mogą być częścią Twojej organizacji lub nie.

W praktyce

Aby dowiedzieć się, jak to działa, przechwyćmy i wyeksportujmy zestaw poświadczeń EC2 z jednej z naszych instancji EC2. Używamy SSH do łączenia się z jedną z naszych instancji i używamy curl do pobierania poświadczeń, jak pokazano wcześniej:

Instancja ma rolę IAM z uprawnieniami umożliwiającymi odczytywanie bucketów S3 na tym koncie AWS. Kopiujemy i wklejamy poświadczenia. Następnie łączymy się z inną instancją EC2 działającą na innym koncie AWS, niezwiązanym z tym samym kontem administratora GuardDuty. Używamy SSH do łączenia się z tą drugą instancją, a następnie konfigurujemy AWS CLI za pomocą zhakowanych poświadczeń. Próbujemy uzyskać dostęp do prywatnego bucketu S3.

Niedługo potem używamy AWS Management Console, aby uzyskać dostęp do GuardDuty na koncie AWS, na którym „ukradliśmy” dane uwierzytelniające. Możemy sprawdzić, czy wygenerowano alert o wysokim stopniu ważności.

I co dalej?

Atakujący mogą wyodrębnić poświadczenia, gdy umożliwią zdalne wykonanie kodu (RCE), lokalny dostęp instancji lub wykorzystując luki na poziomie aplikacji, takie jak Server Side Request Forgery (SSRF) i iniekcja XML External Entity. Istnieje wiele metod ograniczania dostępu RCE lub dostępu lokalnego, w tym odbudowywanie instancji z zabezpieczonego i spatchowanego AMI w celu wyeliminowania dostępu zdalnego, rotacji poświadczeń dostępu i tak dalej. Gdy luka występuje na poziomie aplikacji, Ty lub dostawca aplikacji jesteście zobowiązani do załatania kodu aplikacji w celu wyeliminowania luki.

Gdy otrzymasz alert wskazujący na ryzyko złamania poświadczeń, pierwszą rzeczą do zrobienia jest zweryfikowanie identyfikatora konta. Czy to jedno z kont Twojej firmy, czy nie? Podczas analizy, jeśli pozwala na to uzasadnienie biznesowe, możesz usunąć zhakowane instancje lub zatrzymać aplikację. Uniemożliwia to osobie atakującej wyodrębnienie poświadczeń odnowionej instancji po wygaśnięciu. W razie wątpliwości skontaktuj się z zespołem AWS Trust & Safety, korzystając z formularza Report Amazon AWS abuse form lub pod adresem abuse@amazonaws.com. Podaj wszystkie niezbędne informacje, w tym podejrzany identyfikator konta AWS, dane logowania w postaci zwykłego tekstu itd., kiedy przesyłasz swoje żądanie.

Dostępność

Ta nowa funkcjonalność jest dostępna we wszystkich regionach AWS bez dodatkowych kosztów. Jest ona domyślnie włączona, gdy GuardDuty jest już włączony na Twoim koncie AWS.

W przeciwnym razie włącz GuardDuty i rozpocznij 30-dniowy okres próbny.

źródło:AWS