Luka w Amazon Machine Image

Nowe zagrożenie w ekosystemie Amazon Web Services (AWS) ujawnia poważną lukę w bezpieczeństwie Amazon Machine Images (AMI), pozwalając cyberprzestępcom na publikowanie fałszywych obrazów maszyn wirtualnych.

Mechanizm Ataku

Problem, określany jako „whoAMI name confusion attack”, polega na tym, że atakujący mogą publikować złośliwe AMI pod nazwami przypominającymi te oficjalne. Użytkownicy AWS, którzy wyszukują obrazy bez weryfikacji właściciela, mogą przypadkowo wdrożyć nieautoryzowane i potencjalnie szkodliwe instancje w swojej infrastrukturze.

Amazon Machine Images są kluczowym elementem w uruchamianiu instancji EC2. Użytkownicy często polegają na wyszukiwaniu AMI poprzez API ec2:DescribeImages, jednak brak weryfikacji właściciela może skutkować pobraniem niezweryfikowanego obrazu. Atakujący wykorzystują popularne schematy nazw (np. ubuntu/images/hvm-ssd/ubuntu-focal-20.04-amd64-server-*), by ich AMI pojawiły się jako najnowsze w wynikach wyszukiwania.

Gdy użytkownik wdroży taki obraz, atakujący mogą uzyskać dostęp do systemu, eksfiltrować dane lub instalować złośliwe oprogramowanie.

Przykładowy Wektor Ataku

Nieprawidłowa konfiguracja, np. w Terraformie, może skutkować pobraniem niezaufanego AMI:

Brak określenia właściciela AMI sprawia, że Terraform może wybrać najnowszy obraz – w tym potencjalnie złośliwy.

Jak się zabezpieczyć?

1. Filtrowanie właścicieli – zawsze określaj zaufanych właścicieli AMI:
   bash

   KopiujEdytuj

   aws ec2 describe-images \ --filters "Name=name,Values=amzn2-ami-hvm-*-x86_64-gp2" \ --owners "137112412989"
2. Używanie „Allowed AMIs” – AWS wprowadził w grudniu 2024 funkcję pozwalającą na definiowanie listy zaufanych AMI.
3. Aktualizacja Terraform i narzędzi IaC – nowsze wersje ostrzegają przed użyciem most_recent=true bez określonego właściciela.
4. Audyt kodu – narzędzia jak Semgrep pomagają wykrywać ryzykowne konfiguracje.
5. Monitorowanie instancji – skanowanie obecnych maszyn pod kątem użycia niezaufanych AMI.

AWS uznało problem, jednak dotknięte były głównie środowiska testowe, a dane klientów nie zostały ujawnione. Mimo to organizacje powinny wdrożyć środki ochronne, aby zabezpieczyć swoje środowiska chmurowe.