Wprowadzenie do problemu / definicja
Atak na łańcuch dostaw to scenariusz, w którym przestępcy kompromitują dostawcę technologii, partnera lub zaufaną integrację, aby pośrednio uzyskać dostęp do środowisk klientów. W tym przypadku celem była platforma big data Qubole oraz model dostępu oparty na rolach IAM w Amazon Web Services, co umożliwiło nieautoryzowany dostęp do zasobów wielu organizacji.
W skrócie
Z ujawnionych ustaleń wynika, że napastnicy wykorzystali skompromitowane poświadczenia IAM powiązane z kontem AWS związanym z Qubole. Dzięki temu mogli przejmować role międzykontowe skonfigurowane wcześniej przez klientów i uzyskiwać dostęp do ich środowisk chmurowych. Kampania objęła ponad tuzin organizacji, a działania atakujących obejmowały rozpoznanie, pobieranie sekretów, analizę konfiguracji oraz eksfiltrację danych z bucketów S3.
- Kompromitacja poświadczeń IAM dostawcy
- Wykorzystanie ról cross-account w AWS
- Dostęp do sekretów, konfiguracji i zmiennych środowiskowych
- Eksfiltracja danych z zasobów S3
- Ryzyko wynikające z nieusuniętych, historycznych integracji
Kontekst / historia
Integracje SaaS z chmurą publiczną często wymagają przyznania dostawcy określonych uprawnień w środowisku klienta. W AWS zazwyczaj realizuje się to za pomocą ról IAM typu cross-account, które pozwalają zewnętrznemu kontu przejąć zdefiniowaną rolę i wykonywać określone działania. Sam mechanizm jest powszechnie stosowany i może być bezpieczny, o ile organizacja konsekwentnie ogranicza zakres uprawnień oraz usuwa dostęp po zakończeniu współpracy.
W opisywanym incydencie problemem okazały się nie tylko przejęte poświadczenia dostawcy, ale również aktywne role pozostawione przez część klientów mimo zakończenia korzystania z usługi. Takie osierocone integracje tworzą długotrwałą powierzchnię ataku i pozwalają przestępcom wykorzystać zaufanie ustanowione wcześniej między klientem a dostawcą.
Analiza techniczna
Mechanizm ataku opierał się na wykorzystaniu przejętych poświadczeń IAM przypisanych do konta AWS dostawcy. Jeżeli klient utworzył wcześniej rolę umożliwiającą temu kontu operację AssumeRole, napastnik mógł przejąć tę rolę i uzyskać dostęp do zasobów ofiary w granicach nadanych uprawnień.
Według opisu kampanii działania atakujących obejmowały kilka etapów operacyjnych. Najpierw prowadzili enumerację zasobów, identyfikując dostępne konta, role, buckety, sekrety i konfiguracje. Następnie pobierali materiał uwierzytelniający z typowych lokalizacji w AWS, w tym sekrety, klucze oraz zmienne środowiskowe. Kolejnym krokiem była walidacja przejętych poświadczeń oraz testowanie ich przydatności do dalszego ruchu w środowisku. Ostatnim etapem była eksfiltracja danych z bucketów S3, w niektórych przypadkach na znaczną skalę.
Na uwagę zasługuje również sposób identyfikacji incydentu. Jednym z ważnych wskaźników kompromitacji miały być nazwy sesji ról zgodne z powtarzalnym schematem, sugerującym powiązanie z Qubole i opisem wykonywanych działań. To podkreśla znaczenie monitorowania logów CloudTrail, zdarzeń STS oraz analizy wzorców użycia operacji AssumeRole. Dodatkowym utrudnieniem była obserwacja ruchu pochodzącego nie z infrastruktury dostawcy, lecz z zewnętrznego serwera i sieci VPN.
Konsekwencje / ryzyko
Najpoważniejszym skutkiem tego typu incydentu jest utrata poufności danych przechowywanych w chmurze. Jeżeli role nadane integracji miały szeroki zakres odczytu, atakujący mogli uzyskać dostęp do danych biznesowych, artefaktów analitycznych, kopii zapasowych, konfiguracji aplikacyjnych oraz sekretów umożliwiających dalszą eskalację.
Ryzyko nie kończy się na jednorazowej eksfiltracji. Przejęte sekrety i klucze mogą zostać użyte do wtórnych włamań, ruchu bocznego między usługami, utrzymania dostępu lub obchodzenia segmentacji środowiska. Szczególnie niebezpieczne są przypadki, w których integracje dostawców posiadają nadmierne uprawnienia do wielu bucketów, menedżerów sekretów lub elementów konfiguracji całego konta.
Incydent podkreśla też problem osieroconych integracji. Nawet jeśli organizacja przestała korzystać z danej usługi, pozostawione role i relacje zaufania mogą nadal funkcjonować jako aktywny kanał wejścia do środowiska.
Rekomendacje
Organizacje korzystające z AWS i usług SaaS powinny potraktować ten incydent jako sygnał do przeglądu swoich integracji chmurowych oraz modeli zaufania. Kluczowe znaczenie mają zarówno działania prewencyjne, jak i zdolność do szybkiego odcięcia dostawcy od środowiska w razie podejrzenia nadużycia.
- Przeprowadzić pełny przegląd ról IAM typu cross-account i ustalić ich właścicieli biznesowych oraz technicznych
- Usuwać nieaktywne integracje natychmiast po zakończeniu współpracy z dostawcą
- Stosować zasadę najmniejszych uprawnień dla wszystkich ról przyznawanych partnerom zewnętrznym
- Monitorować operacje AssumeRole, aktywność STS oraz nietypowe wzorce nazw sesji w CloudTrail
- Wdrożyć detekcję nietypowych odczytów i masowych transferów danych z S3
- Rotować sekrety, klucze i tokeny po każdym incydencie lub podejrzeniu naruszenia
- Regularnie oceniać ryzyko dostawców i gotowość do szybkiego wyłączenia integracji
- Segmentować dane i ograniczać dostęp partnerów do konkretnych zasobów, prefiksów lub projektów
Podsumowanie
Atak związany z Qubole pokazuje, że bezpieczeństwo chmury zależy nie tylko od konfiguracji usług natywnych, ale również od pełnego cyklu życia integracji zewnętrznych. Kompromitacja dostawcy może przerodzić się w incydent obejmujący wiele organizacji, jeśli w środowiskach klientów pozostają aktywne i zbyt szeroko uprzywilejowane role cross-account. Najważniejsze działania obronne to inwentaryzacja relacji z dostawcami, usuwanie osieroconych uprawnień, ograniczanie zakresu dostępu oraz stałe monitorowanie użycia ról IAM i transferu danych.