Datadog Security Labs ujawniło niedawno nowy rodzaj ataku typu #supplychainattack ukierunkowany na Amazon Machine Images, znany jako whoAMI atak na pomyleniu nazw. Podatność ta podkreśla ryzyko błędnego wdrożenia niezweryfikowanych AMI w środowiskach AWS, potencjalnie umożliwiając atakującym wykonanie złośliwego kodu.
Atak opiera się na myleniu nazw, technice podobnej do ataku na pomyleniu nazw zależności, ale jej celem jest infrastruktura chmury, a nie pakiety oprogramowania. Zamiast wykorzystywać luki w bibliotekach innych firm, atakujący nakłaniają organizacje do korzystania ze złośliwych obrazów maszyn wirtualnych, publikując AMI o nazwach podobnych do legalnych.
Kluczowe ustalenia:
- Wiele organizacji wyszukuje AMI przy użyciu ogólnych wzorców nazw bez określania identyfikatora właściciela AMI.
- Atakujący mogą utworzyć złośliwy AMI o niemal identycznej nazwie, czyniąc go najnowszym wynikiem zapytania API ec2:DescribeImages AWS.
- Jeśli narzędzia IaaC organizacji lub automatyzacja AWS wybierze najnowszy AMI bez weryfikacji jego źródła, AMI atakującego zostanie wdrożone zamiast oficjalnego.
- Metoda ta pozwala atakującym uzyskać kontrolę nad instancjami EC2 w środowisku AWS organizacji.
Od tego czasu AWS załatał podatność na zagrożenia i wprowadził „Allowed AMIs”, funkcję, która pozwala klientom definiować zaufane źródła obrazów, aby zapobiec niezamierzonemu użyciu niezweryfikowanych AMI.
Organizacje powinny niezwłocznie przeanalizować swój proces wyboru AWS AMI i wdrożyć mechanizmy kontroli bezpieczeństwa, aby złagodzić ten wektor ataku. Datadog zaleca następujące najlepsze praktyki:
Zawsze określaj atrybut „owners” podczas wyszukiwania AMI.
Włączenie opcji „Allowed AMIs” w AWS, aby wymusić ograniczenia dotyczące tego, które AMI mogą być używane.
Korzystaj z narzędzi do automatycznego skanowania, aby identyfikować i oznaczać niezaufane AMI w swoim środowisku.
Zaktualizuj Terraform i inne skrypty IaC, aby zawierały jawne filtry właścicieli i unikały pobierania AMI wyłącznie na podstawie wzorców nazw.
Monitorowanie wywołań API AWS, zwłaszcza gdy są używane bez określania właścicieli lub filtrów aliasów właścicieli.
Używanie AWS CloudTrail do śledzenia nieoczekiwanego użycia AMI i wykrywania nieautoryzowanych wdrożeń obrazów.
Atak ten jest doskonałym przykładem ryzyka związanego z łańcuchem dostaw, które nie opiera się na lukach w bibliotekach lub kodzie stron trzecich. Zamiast tego wykorzystuje zaufanie i błędne konfiguracje w sposobie, w jaki organizacje wybierają komponenty infrastruktury chmurowej.
Jak zawsze, polecam również słuchanie podcastu Bezpieczny Kod, który często dostarcza świetnych spostrzeżeń na temat cyberbezpieczeństwa i najlepszych praktyk.
A Cloud Image Name Confusion Attack
Datadog Security Labs recently uncovered a new type of supplychainattack targeting Amazon Machine Images, known as the whoAMI #nameconfusionattack. This vulnerability highlights the
risk of unverified AMIs being mistakenly deployed within AWS environments, potentially allowing attackers to execute malicious code.
The attack is based on name confusion, a technique similar to #dependencyconfusionattacks but targeting cloud infrastructure instead of software packages. Instead of exploiting vulnerabilities in third-party libraries, attackers trick organizations into using malicious virtual machine images by publishing AMIs with similar names to legitimate ones.
Key findings:
- Many organizations search for AMIs using generic name patterns without specifying the AMI owner ID.
- Attackers can create a malicious AMI with a nearly identical name, making it the most recent result in AWS's ec2:DescribeImages API query.
- If an organization’s IaaC tooling or AWS automation selects the most recent AMI without verifying its source, the attacker’s AMI is deployed instead of the official one.
- This method allows attackers to gain control over EC2 instances inside an organization's AWS environment.
AWS has since patched the #vulnerability and introduced "Allowed AMIs", a feature that lets customers define trusted image sources to prevent unintentional use of unverified AMIs.
Organizations should immediately review their AWS AMI selection process and implement security controls to mitigate this attack vector. Datadog recommend the following best practices:
Always specify the "owners" attribute when searching for AMIs.
Enable "Allowed AMIs" in AWS to enforce restrictions on which AMIs can be used.
Use automated scanning tools to identify and flag untrusted AMIs in your environment.
Update Terraform and other IaC scripts to include explicit owner filters and avoid fetching AMIs based solely on name patterns.
Monitor AWS API calls, especially when used without specifying owners or owner-alias filters.
Use AWS CloudTrail to track unexpected AMI usage and detect unauthorized image deployments.
This attack is a perfect example of a supply chain risk that isn’t based on vulnerabilities in third-party libraries or code. Instead, it exploits trust and misconfigurations in how organizations select cloud infrastructure components.
As always, I also recommend listening to Bezpieczny Kod podcast, which often provides great insights into cybersecurity risks and best practices.
Autor: Sebastian Burgemejster
Comments