Badacze bezpieczeństwa ujawnili lukę w Amazon Web Services (AWS) Cloud Development Kit (CDK), która mogła prowadzić do przejęcia konta użytkownika w określonych okolicznościach. Według raportu opublikowanego przez Aqua, w pewnych scenariuszach atakujący mógł uzyskać dostęp administracyjny do docelowego konta AWS, co mogło skutkować pełnym przejęciem konta.
Szczegóły ujawnienia i naprawa luki
Po odpowiedzialnym ujawnieniu luki 27 czerwca 2024 roku, zespół odpowiedzialny za projekt szybko podjął działania i zajął się problemem w wersji CDK 2.149.0, która została wydana w lipcu tego samego roku. AWS CDK to open-source’owe narzędzie programistyczne, które umożliwia definiowanie zasobów aplikacji w chmurze przy użyciu takich języków programowania jak Python, TypeScript czy JavaScript, a następnie wdrażanie ich przy wykorzystaniu CloudFormation.
Mechanizm ataku: wykorzystanie nazw zasobów
Problem związany był z mechanizmem tworzenia „shadow resources” (zasobów cieni) w AWS oraz z predefiniowanymi konwencjami nazewnictwa dla usług takich jak AWS Simple Storage Service (S3). Atakujący mogli wykorzystać te standardy do przeprowadzenia tzw. Bucket Monopoly attacks, co mogło skutkować uzyskaniem nieautoryzowanego dostępu do wrażliwych danych.
Proces przygotowania środowiska AWS do pracy z CDK, zwany bootstrappingiem, wiąże się z tworzeniem określonych zasobów, takich jak S3 bucket (magazyn danych), repozytorium Amazon Elastic Container Registry (Amazon ECR) oraz role AWS Identity and Access Management (IAM). Zasoby te są definiowane w szablonie AWS CloudFormation.
Predykcyjne nazwy zasobów jako klucz do ataku
Jednym z głównych problemów było niezmienne i przewidywalne nazewnictwo zasobów. Na przykład, domyślnie tworzony S3 bucket otrzymywał nazwę według wzorca: PLACEHOLDER3a085926a8d5335a. Wartość PLACEHOLDER8333f549ecbefa0f to często unikalna, dziewięcioznakowa wartość, która domyślnie wynosiła „hnb659fds”. W praktyce oznaczało to, że jeśli użytkownik nie dostosował tej wartości, nazwa bucketa stawała się łatwa do przewidzenia, co otwierało możliwość ataku.
Podobna sytuacja miała miejsce w przypadku ról IAM, których nazwy miały strukturę: cdk-{Qualifier}-{Description}-{Account-ID}-{Region}. Jeśli atakujący znał identyfikator konta AWS oraz region, mógł wykorzystać te informacje, aby przejąć nazwę bucketa, co prowadziło do ataku zwanego S3 Bucket Namesquatting (lub Bucket Sniping).
Potencjalne skutki ataku
Przejęcie bucketa mogło prowadzić do częściowego odmówienia dostępu (DoS), kiedy inny użytkownik próbowałby skonfigurować swoje środowisko AWS CDK z tym samym identyfikatorem konta i regionem. Znacznie poważniejszym zagrożeniem byłaby sytuacja, w której CDK ofiary miała uprawnienia do odczytu i zapisu danych do zhakowanego bucketa. W takim przypadku atakujący mógłby zmanipulować szablony CloudFormation i wykonać złośliwe działania na koncie AWS ofiary.
Na przykład, rola CloudFormationExecutionRole w AWS CDK posiada domyślnie uprawnienia administracyjne, co oznaczało, że szablony CloudFormation napisane przez ofiarę mogłyby być wdrażane we współpracy z kontem atakującego. W rezultacie atakujący mógłby tworzyć zasoby administracyjne na koncie ofiary.
Jak atak mógłby wyglądać w praktyce?
W hipotetycznym ataku, jeśli użytkownik zainicjował proces CDK bootstrap w przeszłości, a później usunął bucket S3 z powodu ograniczeń quota, atakujący mógłby wykorzystać tę sytuację do stworzenia bucketa o tej samej nazwie. CDK, zakładając, że bucket jest zaufany, mógłby próbować odczytać i zapisać szablony CloudFormation do zhakowanego bucketa, co potencjalnie mogłoby prowadzić do pełnego przejęcia konta.
Przebieg ataku wyglądałby następująco:
1. Atakujący przejmuje kontrolę nad bucketem o przewidywalnej nazwie i umożliwia publiczny dostęp.
2. Tworzy funkcję Lambda, która wstrzykuje złośliwy kod do przesyłanych plików szablonów CloudFormation.
3. Kiedy ofiara wdraża aplikację przy użyciu cdk deploy, proces przesyła szablon do fałszywego bucketa, jednocześnie implementując złośliwe zasoby, takie jak rola administratora, do konta AWS ofiary.
Środki zaradcze i rekomendacje
AWS potwierdziło, że około 1% użytkowników CDK było podatnych na ten wektor ataku. Aby temu zapobiec, AWS wdrożyło poprawki, które zapewniają, że zasoby będą przesyłane jedynie do bucketów wewnątrz konta użytkownika, co eliminuje ryzyko przesyłania danych do nieautoryzowanych bucketów. Ponadto, AWS zachęca użytkowników do stosowania unikatowych identyfikatorów dla kwalifikatorów zamiast domyślnej wartości „hnb659fds”.
Działania, które użytkownicy powinni podjąć, obejmują:
– Aktualizację CDK do najnowszej wersji i ponowne uruchomienie komendy bootstrap.
– Alternatywnie, mogą oni skonfigurować politykę IAM ograniczającą dostęp do roli FilePublishingRole w CDK.
– Dodatkowo, badacze zalecają, aby użytkownicy utrzymywali w tajemnicy identyfikatory kont AWS, definiowali precyzyjne polityki IAM oraz unikali nadawania przewidywalnych nazw bucketom S3. Zamiast tego, zalecane jest generowanie unikalnych hashy lub losowych identyfikatorów dla każdego regionu i konta, które będą włączane w nazwy bucketów.
Inne zagrożenia chmurowe
Warto dodać, że w podobnym okresie Symantec, należący do Broadcom, odkrył liczne aplikacje na Androida i iOS, które zawierały w swoim kodzie zaszyfrowane, ale łatwo dostępne dane uwierzytelniające dla usług chmurowych, w tym AWS i Microsoft Azure Blob Storage. Aplikacje te, takie jak Pic Stitch: Collage Maker czy Crumbl, narażały dane użytkowników na potencjalne wycieki i manipulacje.
Podsumowując, choć AWS wprowadziło już poprawki, użytkownicy muszą podjąć dodatkowe kroki, aby zapewnić bezpieczeństwo swoich kont i uniknąć przewidywalnych nazw zasobów, które mogłyby zostać wykorzystane przez atakujących.
