Hakerzy wykorzystują luki w środowiskach kontenerowych

Z raportu Sysdig wiemy, że atakujący wykorzystał podatność w konteneryzowanym workload, a następnie użył jej do eskalacji uprawnień na konto AWS w celu kradzieży danych i poświadczeń.

Zaawansowany atak w chmurze wiązał się również z wdrożeniem oprogramowania do kopania kryptowalut, które było albo próbą generowania nielegalnych zysków, albo sztuczką mającą na celu odwrócenie uwagi obrońców i zbicie ich z tropu.

Początkowy wektor infekcji opierał się na wykorzystaniu podatnej na ataki usługi publicznej w samodzielnie zarządzanym klastrze Kubernetes, hostowanym na Amazon Web Services (AWS).

Po zdobyciu przyczółka uruchomiono koparkę kryptowalut XMRig i użyto skryptu bash w celu uzyskania poświadczeń, które można było wykorzystać do dalszego zagłębiania się w infrastrukturę chmury AWS i eksfiltracji wrażliwych danych.

Włamanie wyłączyło również dzienniki CloudTrail, aby zminimalizować ślady, uniemożliwiając firmie Sysdig dostęp do dodatkowych dowodów. W sumie umożliwiło to aktorowi dojście do ponad 1 TB danych, w tym skryptów klientów, narzędzi do rozwiązywania problemów i plików dziennika.

Atakujący próbowali również przełączyć się za pomocą pliku stanu Terraform na inne połączone konta AWS, aby rozszerzyć swój zasięg w całej organizacji. Okazało się to jednak nieskuteczne z powodu braku uprawnień.

Schemat ataku

Poniższa infografika przedstawia główne etapy łańcucha KillChain opisywanego ataku.

Krok 1: Atakujący uzyskał początkowy dostęp, wykorzystując usługę publiczną w samodzielnie zarządzanym klastrze Kubernetes, hostowanym w ramach konta w chmurze AWS.

Krok 2: Gdy haker zyskał dostęp, złośliwe oprogramowanie było w stanie wykonać dwie początkowe akcje podczas uruchomienia:

• wystartować koparkę kryptowalut w celu generowania zysku bądź odwrócenia uwagi,
• uzyskać dostęp do poświadczeń za pomocą tymczasowych poświadczeń pracownika w Instance Metadata Service (IMDS) v1, aby wyliczać i zbierać informacje w jego imieniu przy użyciu uprawnień roli klastra. Ze względu na nadane uprawnienia, atakujący był w stanie:
  • wylistować zasoby AWS,
  • znaleźć poświadczenia innych użytkowników zarządzania tożsamością i dostępem (IAM), zarówno ustawionych jako zmienne środowiskowe Lambda, jak i przekazanych w postaci zwykłego tekstu do zasobników Amazon Simple Storage Service (S3).

Krok 3: Atakujący użył poświadczeń znalezionych w poprzednim kroku, aby przeskoczyć lateralnie po sieci. Skontaktował się bezpośrednio z interfejsem API AWS i przystąpił do zbierania informacji i eksfiltracji danych. Na tym etapie cyberprzestępcy byli w stanie:

• wyłączyć dzienniki CloudTrail, aby uniknąć wykrycia,
• kraść zastrzeżone oprogramowanie,
• znaleźć poświadczenia użytkownika IAM powiązane z innym kontem AWS, wykrywając pliki stanu Terraform w zasobnikach S3.

Krok 4: Atakujący użył nowych danych uwierzytelniających, aby ponownie przejść w bok, powtarzając atak i cały łańcuch z innego znalezionego konta AWS. Na szczęście w tym przypadku nie był w stanie enumerować zasobów, ponieważ wszystkie żądania API AWS, których próbował, zakończyły się niepowodzeniem z powodu braku uprawnień.

Podsumowanie

Na opisywanym przykładzie widzimy, że nowe technologie nie mogą być uważane za  bezpieczne. Przy projektowaniu nowych rozwiązań bezpieczeństwo powinno być jednym z priorytetów, gdyż hakerzy zawsze znajdą możliwość wykorzystania słabości środowiska.