Ataki i Obrona

1. Podstawy tożsamości AWS – konta, organizacje, użytkownicy, role i polityki oraz najlepsze praktyki.
2. Over‑Privilege – przyczyny nadawania nadmiernych uprawnień i jego konsekwencje.
3. Scenariusze eskalacji uprawnień – AttachUserPolicy, PassRole + RunInstances, PutKeyPolicy Overreach.
4. Najczęstsze luki bezpieczeństwa w chmurze – wycieki kluczy, publiczne zasoby, błędna konfiguracja
5. Persistence w AWS – techniki utrzymania dostępu, w tym ukryte backdoory w warstwach Lambda.
6. Strategie obrony i monitorowania – wzmacnianie kont, automatyczne skanowanie konfiguracji, ograniczanie zaufania zewnętrznego, testy bezpieczeństwa i monitorowanie działań w skali organizacji.

Twórz oddzielne konta dla różnych środowisk i celów. Na przykład utwórz osobne konto dla środowiska deweloperskiego (dev), testowego (staging), produkcyjnego (prod), logowania i bezpieczeństwa, aby ograniczyć skalę potencjalnych skutków incydentu.

AWS grupuje wiele kont pod pierwszym utworzonym kontem (zwykle nazywanym kontem zarządzającym, management account). Umożliwia stosowanie polityk jako mechanizmów kontrolnych, takich jak Service Control Policies (SCP), konsolidację rozliczeń oraz centralne włączanie usług, np. GuardDuty.

Jeśli atakujący przejmie konto zarządzające, może przejąć rolę OrganizationAccountAccessRole na każdym koncie podrzędnym — co oznacza natychmiastowe przejęcie całej infrastruktury. Dlatego zaleca się, aby pierwsze konto utworzone przez firmę służyło wyłącznie do zakładania kolejnych kont i konfigurowania polityk organizacji. Nie należy wykorzystywać go do uruchamiania infrastruktury ani przechowywania danych, aby ograniczyć ryzyko.

Użytkownik IAM reprezentuje osobę lub (rzadziej) aplikację, która potrzebuje stałych danych uwierzytelniających. Każdy użytkownik może mieć hasło do konsoli oraz maksymalnie dwie pary kluczy dostępowych. Hasła i klucze dostępowe należy co pewien czas rotować.

Twórz jak najmniej użytkowników (zamiast IAM używaj AWS Identity Center do ich tworzenia), wymuszaj stosowanie MFA, oznaczaj użytkowników tagami identyfikującymi właściciela oraz, jeśli to możliwe, nie zezwalaj na generowanie kluczy dostępowych dla użytkowników IAM.

• Ogranicz liczbę użytkowników IAM – każdy dodatkowy użytkownik to nowe stałe dane uwierzytelniające, które mogą wyciec lub zostać przejęte. Mniej kont oznacza mniejszą powierzchnię ataku.
• Używaj AWS Identity Center zamiast IAM – zapewnia centralne logowanie, łatwe wdrażanie polityk bezpieczeństwa, integrację z systemami tożsamości (np. Azure AD, Okta) i dostęp tymczasowy, eliminując ryzyko stałych kluczy.
• Wymuszaj MFA – dodatkowy czynnik uwierzytelniania chroni konto nawet w przypadku wycieku hasła.
• Taguj użytkowników – pozwala szybko zidentyfikować właściciela konta, ułatwia audyt i automatyczne raportowanie oraz umożliwia egzekwowanie polityk.
• Blokuj możliwość generowania kluczy dostępowych – klucze są trudniejsze do monitorowania niż logowania do konsoli, mogą trafić do kodu lub repozytoriów i pozostać tam latami, zwiększając ryzyko ataku.

Rola IAM nie posiada długoterminowych danych uwierzytelniających. Jest przyjmowana przez użytkowników, usługi AWS lub tożsamości zewnętrzne w celu uzyskania krótkotrwałych tokenów STS. Role są domyślnym sposobem nadawania obciążeniu lub osobie dostępu „just‑in‑time” (tylko na czas potrzebny do wykonania zadania) lub umożliwienia przechodzenia między kontami.

Stosuj role IAM z krótkotrwałymi poświadczeniami STS jako domyślny mechanizm nadawania dostępu między kontami AWS oraz do krytycznych zasobów. W przypadku procesów CI/CD skonfiguruj rolę międzykontową w środowisku docelowym (np. produkcyjnym), nadając jej wyłącznie minimalne uprawnienia wymagane do realizacji zadania. Pozwalaj potokom CI/CD na przyjęcie tej roli (assume role) tylko na czas wykonywania operacji, aby ograniczyć ryzyko nadużycia poświadczeń. Nie przechowuj stałych kluczy dostępowych w pipeline’ach, a dostęp wygaszaj automatycznie po zakończeniu wdrożenia.

Polityka to dokument w formacie JSON, który pozwala lub odmawia wykonywania określonych działań na wskazanych zasobach, opcjonalnie pod warunkiem spełnienia dodatkowych kryteriów (np. określony adres IP, wymuszenie MFA). Polityki mogą zawierać symbole wieloznaczne () dopasowujące wiele działań lub zasobów — na przykład "s3:Get" obejmuje wszystkie operacje odczytu obiektów w S3.

Polityki występują w trzech formach:

• AWS‑managed – utrzymywane przez AWS (często zbyt szerokie, np. AdministratorAccess).
• Customer‑managed – wielokrotnego użytku, tworzone przez użytkownika.
• Inline – osadzone bezpośrednio w użytkowniku, roli lub grupie (nie można ich ponownie wykorzystać dla innych tożsamości).

Zalecenia dotyczące bezpieczeństwa

• Stosuj zasadę najmniejszych uprawnień – nadaj użytkownikom, rolom i usługom tylko te uprawnienia, które są absolutnie niezbędne do wykonania ich zadań.
• Unikaj symboli wieloznacznych (*) – zastępuj je precyzyjnymi listami działań i zasobów, aby ograniczyć zakres dostępu.
• Preferuj polityki Customer‑managed – twórz i utrzymuj własne, dostosowane polityki zamiast polegać na szerokich politykach AWS‑managed.
• Ogranicz stosowanie polityk Inline – używaj ich tylko w wyjątkowych sytuacjach, ponieważ są trudne do zarządzania i audytu.
• Regularnie przeglądaj i aktualizuj polityki – usuwaj zbędne uprawnienia oraz weryfikuj, czy nadal odpowiadają aktualnym potrzebom organizacji.
• Oddziel konta zarządzające od produkcyjnych – konto zarządzające powinno służyć wyłącznie do tworzenia innych kont i konfiguracji organizacyjnej, bez uruchamiania na nim obciążeń.

Minimalne wymagane uprawnienie: iam:AttachUserPolicy
Cel: Nadanie sobie AdministratorAccess poprzez przypisanie zarządzanej polityki (managed policy) do własnego użytkownika IAM.

Przebieg ataku:

1. Odnalezienie swojego ARN użytkownika – polecenie aws iam get-user potwierdza tożsamość (principal), którą można modyfikować. Należy wskazać dokładnie ten principal, nad którym mamy kontrolę.
2. Przypisanie polityki administracyjnej – komenda aws iam attach-user-policy --user-name <name> --policy-arn arn:aws:iam::aws:policy/AdministratorAccess tworzy powiązanie polityki z tożsamością (policy/identity link). W efekcie w jednym wywołaniu API nadawane są wszystkie uprawnienia administracyjne.
3. Odświeżenie poświadczeń – ponowne uwierzytelnienie lub wygenerowanie nowych access keys powoduje, że AWS ponownie ocenia zestaw uprawnień. Od tego momentu atakujący ma nieograniczony dostęp do całego konta.

KMS Privesc - references

Minimalne wymagane uprawnienie: iam:PassRole ec2:RunInstances
Cel: Uruchomienie instancji EC2 (Amazon Elastic Compute Cloud — usługa w modelu on‑demand umożliwiająca uruchamianie i kontrolowanie wirtualnych serwerów podobnie jak maszyn wirtualnych (VM).), która dziedziczy uprzywilejowaną rolę, a następnie kradzież jej tymczasowych tokenów sesyjnych.

Przebieg ataku:

1. Enumeracja ról możliwych do przekazania (pass‑able roles) – polecenie: aws iam list-roles --query 'Roles[?AssumeRolePolicyDocument.Statement[?Principal.Service==\`ec2.amazonaws.com`]]' wyświetla role, których polityka zaufania (trust policy) zezwala na użycie przez EC2. Tylko takie role można przekazać podczas uruchamiania instancji.
2. Wybór roli o wysokich uprawnieniach – najlepiej takiej, która ma przypisany AdministratorAccess lub podobne prawa. Im potężniejsza rola, tym większy potencjalny zasięg szkód (blast radius).
3. Uruchomienie EC2 z przypisaną rolą – komenda: aws ec2 run-instances --iam-instance-profile Name=<roleName> ... przypisuje do instancji wskazany instance profile. Usługa Instance Metadata Service (IMDS) dostarczy STS credentials dla tej roli do maszyny wirtualnej.
4. Pozyskanie poświadczeń – wewnątrz maszyny uruchom: curl http://169.254.169.254/latest/meta-data/iam/security-credentials/<roleName> aby uzyskać poświadczenia w formacie JSON. Można je następnie wykorzystać na swojej stacji roboczej; działają one jak sts:AssumeRole bez wymogu MFA.

To bardzo powszechny schemat eskalacji uprawnień w środowiskach chmurowych, w którym atakujący korzysta z usługi chmurowej zdolnej do uruchomienia kodu kontrolowanego przez siebie, a następnie przypisuje do niej rolę z większymi uprawnieniami. Dzięki temu token używany w usłudze przejmuje uprawnienia roli, co skutkuje efektywną eskalacją dostępu.

EC2 Privesc - references

Klucze KMS — a także kilka innych usług AWS, takich jak S3, SQS, SNS, Lambda i Secrets Manager — obsługują polityki oparte na zasobach (resource‑based policies). Dokumenty te w formacie JSON są przypisane bezpośrednio do zasobu, a nie do tożsamości IAM, i są oceniane dodatkowo w stosunku do uprawnień IAM. Jeśli atakujący może zmodyfikować politykę zasobu, może całkowicie ominąć kontrolę IAM, nadając nowym principalom (lub wszystkim poprzez wildcard) dostęp, którego IAM normalnie by zabronił.

Minimalne wymagane uprawnienie: kms:ListKeys kms:PutKeyPolicy (kms:ListKeyPolicies kms:GetKeyPolicy) Cel: Przepisać politykę klucza KMS w taki sposób, aby sobie — lub każdemu — nadać pełną kontrolę kms:*, co umożliwia odszyfrowanie danych, tworzenie nieautoryzowanych grantów lub zablokowanie prawowitych właścicieli.

Przebieg ataku:

1. Enumeracja kluczy: aws kms list-keys --query 'Keys[*].KeyId' ujawnia identyfikatory wszystkich Customer Master Key (CMK). Wybierany jest zasób, który ma zostać przejęty.
2. Kopia zapasowa aktualnej polityki: aws kms get-key-policy --key-id <KeyId> --policy-name default (o ile dozwolone) zapisuje aktualny dokument JSON. Przydatne do późniejszego przywrócenia lub ostrożnych modyfikacji.
3. Stworzenie liberalnej polityki poprzez utworzenie pliku evil.json, który dodaje Twój principal z "Action": "kms:" dla danego klucza, lub ustawia "Principal": "" w celu pełnego przejęcia kontroli. Definiuje to eskalowane uprawnienia.
4. Wgranie nowej polityki: aws kms put-key-policy --key-id <KeyId> --policy-name default --policy file://evil.json nadpisuje istniejący dokument. Od tej chwili atakujący jest administratorem klucza.
5. Wykorzystanie dostępu – Można odszyfrować zaszyfrowane dane w AWS Secrets Manager, ponownie zaszyfrować dane kluczami, które kontroluje wyłącznie atakujący, lub tworzyć granty dla innych principalów atakujących. Takie działanie łamie gwarancje szyfrowania danych w spoczynku (data‑at‑rest) dla usług takich jak S3, RDS, EBS i inne.

KMS Privesc - references

Raport GitGuardian’s 2024 State of Secrets Sprawl wykrył 12,7 miliona nowych sekretów w publicznych commitach na GitHub — wiele z nich to klucze AWS (gitguardian.com). Niezależni badacze ustalili, że atakujący zaczynają wykorzystywać świeżo ujawnione klucze w ciągu kilku minut od ich wycieku (helpnetsecurity.com). Przykłady z rzeczywistości obejmują m.in. incydent w Uberze w 2022 roku, wywołany przez hard‑codowane dane administratora w skrypcie PowerShell (medium.com), oraz przypadkowe opublikowanie przez Toyotę długoterminowych access tokens w repozytorium GitHub przez pięć lat (blog.gitguardian.com).

Mitigacja:

• Włącz secret scanning w procesach CI.
• Regularnie rotuj klucze.
• Preferuj użycie ról zamiast długoterminowych kluczy.
• Blokuj publiczne artefakty CI zawierające pliki .aws/credentials.

Publiczne magazyny danych (S3 buckets, snapshoty EBS, instancje RDS) oraz nadmiernie liberalne reguły sieciowe (np. security groups z 0.0.0.0/0, NodePorts, publiczne load balancery) mają wspólny problem — zasoby są dostępne z internetu, mimo że nie powinny. Przykłady: naruszenie danych Capital One, które połączyło nadmiernie uprzywilejowaną rolę WAF z publicznym zasobnikiem S3 (darkreading.com); Pegasus Airlines ujawniły 6,5 TB danych lotniczych w publicznym S3 bucket (cshub.com); Accenture pozostawiło cztery publiczne zasobniki S3, ujawniając wewnętrzne dane uwierzytelniające (upguard.com). Podobne błędy konfiguracyjne występują również w bazach takich jak MongoDB, Redis czy Elasticsearch, które były wystawione na publiczne IP.

Mitigacja:

• Wymuszaj użycie prywatnych podsieci i VPC endpoints dla usług storage.
• Stosuj security group baselines blokujące 0.0.0.0/0, z wyjątkiem ruchu przez bastion lub WAF‑protected load balancer.
• Prowadź ciągłe skanowanie ekspozycji przy użyciu narzędzi takich jak ScoutSuite, Prowler czy CloudMapper.

Ścieżki zaufania pozwalające na dostęp z zewnętrznych kont AWS — a w najgorszym przypadku z całego internetu poprzez "Principal":"*" — stają się cichym „tylnym wejściem” do środowiska. Przykład: incydent w Twilio w 2022 roku rozpoczął się od ataku SMS phishing na pracowników, a następnie wykorzystania ról zaufanych do dostępu do danych klientów (wired.com). W testach red‑teamowych często wykrywa się zapomniane role vendorów lub stare integracje CI/CD, które umożliwiają atakującemu poruszanie się między środowiskami.

Mitigacja:

• Włącz IAM Access Analyzer, aby wykrywać niezamierzony publiczny lub międzykontowy dostęp.
• Dokonuj przeglądu trust policies co kwartał.
• Wymagaj stosowania ExternalId oraz warunku aws:PrincipalOrgID przy udostępnianiu ról dostawcom.

• Least privilege IAM – usuwaj nieużywane uprawnienia, opieraj dostęp na rolach, a nie użytkownikach, oraz wymuszaj MFA.
• Service Control Policies (SCPs) – twórz reguły blokujące (np. zabroń s3:PutBucketPolicy, które umożliwia publiczny dostęp do zasobnika S3).
• Bezpieczne ustawienia domyślne – wymuszaj szyfrowanie EBS domyślnie, wyłączaj publiczne AMI, wymagaj IMDSv2 na EC2.

• Skanowanie IaC – integruj narzędzia takie jak tfsec, cfn‑nag lub Checkov w CI, aby blokować buildy zawierające ryzykowne wzorce.
• Reguły AWS Config – wymagaj wersjonowania S3, szyfrowania RDS, braku otwartych Security Groups itp.
• Stack sets i baseline’y – wdrażaj wzorcowe (golden) VPC, chroń zasobniki S3 poprzez Block Public Access i wymuszaj obowiązkowe tagi.

• Bez wildcardów – unikaj "Principal":"*" w trust policies.
• ExternalId + aws:PrincipalOrgID – stosuj przy udostępnianiu ról dostawcom.
• Rotuj poświadczenia lub usuwaj ścieżki zaufania po zakończeniu umów.

• Automatyczne skanery – uruchamiaj Prowler, ScoutSuite lub AWS Trusted Advisor co tydzień.
• Okresowe pentesty i red teaming – symuluj działania przeciwnika, weryfikuj skuteczność alertów i mierz czas reakcji.
• Chaos engineering – stosuj „wyłączniki bezpieczeństwa” w sandboxach (np. usuń AdministratorAccess w środowisku dev), aby potwierdzić egzekwowanie zasady najmniejszych uprawnień.

• CloudTrail dla całej organizacji – logi wysyłaj do dedykowanego konta z włączonym S3 Bucket Logging i MFA delete.
• GuardDuty – wykrywaj anomalie i zagrożenia (np. koparki kryptowalut, adresy IP z list zagrożeń, eksfiltracja poświadczeń).
• Security Hub – agreguj wyniki z wielu źródeł i automatycznie reaguj poprzez EventBridge + Lambda (np. wyłącz klucze, które wyciekły do GitHub).
• CloudWatch i EventBridge – ustaw alerty na ryzykowne wywołania API: iam:CreateAccessKey, kms:PutKeyPolicy, lambda:PublishLayerVersion.
• Centralny SIEM – koreluj logi AWS z danymi z endpointów i systemów SaaS.