Cybersecurity-onderzoekers hebben een “end-to-end privilege-escalatieketen” aangetoond in Amazon Elastic Container Service (ECS) die door een aanvaller kan worden benut om laterale beweging, toegangsgevoelige gegevens uit te voeren en de controle over de cloudomgeving te grijpen.
De aanvalstechniek is codenaam ecscape door zoete beveiligingsonderzoeker Naor Haziz, die vandaag de bevindingen presenteerde op de Black Hat USA Security Conference die in Las Vegas wordt gehouden.
“We hebben een manier geïdentificeerd om een interne protocol zonder papieren ECS te misbruiken om AWS -referenties te pakken die behoren tot andere ECS -taken op dezelfde EC2 -instantie,” zei Haziz in een rapport gedeeld met het Hacker News. “Een kwaadaardige container met een lage uitgegeven IAM -rol (Identity and Access Management) kan de machtigingen verkrijgen van een hogere uitgegeven container die op dezelfde host draait.”
Amazon ECS is een volledig beheerde containerorkestratiedienst waarmee gebruikers applicaties kunnen implementeren, beheren en schalen, terwijl ze worden geïntegreerd met Amazon Web Services (AWS) om containerwerklast in de cloud uit te voeren.
De kwetsbaarheid die wordt geïdentificeerd door Sweet Security zorgt in wezen mogelijk voor escalatie van voorrechten door een lage bevoorrechte taak op een ECS-instantie toe te staan om de IAM-privileges van een hoger bevoorrechte container op dezelfde EC2-machine te kapen door zijn referenties te stelen.
Met andere woorden, een kwaadaardige app in een ECS -cluster kan de rol van een meer bevoorrechte taak op zich nemen. Dit wordt vergemakkelijkt door te profiteren van een metagegevenservice op 169.254.170 (.) 2 die de tijdelijke referenties blootlegt die verband houden met de IAM -rol van de taak.
Hoewel deze benadering ervoor zorgt dat elke taak inloggegevens krijgt voor zijn IAM -rol en dat ze tijdens runtime worden afgeleverd, kan een lek van de identiteit van de ECS -agent een aanvaller toestaan de agent voor te doen en referenties te verkrijgen voor elke taak op de host. De hele reeks is als volgt –
- Verkrijg de IAM -rolreferenties van de gastheer (rol van EC2 instantie) om de agent voor te doen
- Ontdek het eindpunt van het ECS -besturingsvlak waarmee de agent praat
- Verzamel de benodigde identificatiegegevens (clusternaam/arn, containerinstantie ARN, agentversie -informatie, docker -versie, ACS -protocolversie en sequentienummer) om te authenticeren als de agent die het taakmetadata -eindpunt en ECS introspectie API gebruikt
- Forge en ondertekent de Agent Communication Service (ACS) Websocket -aanvraag die zich voordoen als de agent met de parameter Sendcredentials ingesteld op “True”
- Oogst referenties voor alle uitvoerende taken in dat geval
“Het vervalste agent -kanaal blijft ook heimelijk,” zei Haziz. “Onze kwaadwillende sessie bootst het verwachte gedrag van de agent na – erkent berichten, verhoogde volgnummers, het verzenden van hartslag – dus niets lijkt mis.”
“Door zich voor te doen als de stroomopwaartse verbinding van de agent, stort ECSCAPE volledig in dat vertrouwensmodel in: een gecompromitteerde container kan de IAM -rolreferenties van elke andere taak passief verzamelen op dezelfde EC2 -instantie en onmiddellijk handelen met die privileges.”
Ecscape kan ernstige gevolgen hebben bij het uitvoeren van ECS-taken op gedeelde EC2-hosts, omdat het de deur opent naar cross-task privilege-escalatie, blootstelling van geheimen en exfiltratie van metadata.
Na verantwoorde openbaarmaking heeft Amazon de nadruk gelegd op de noodzaak voor klanten om sterkere isolatiemodellen aan te nemen waar van toepassing, en het in zijn documentatie duidelijk maken dat er geen taakisolatie is in EC2 en dat “containers mogelijk toegang hebben tot inloggegevens voor andere taken op dezelfde containerinstantie.”
Als mitigaties wordt geadviseerd om te voorkomen dat taken met een hoge voorgelicht zijn, naast niet-vertrouwde of low-privilege taken in hetzelfde geval, gebruik AWS Fargate voor echte isolatie, schakel of beperken de instantie metadata-service (IMDS) toegang voor taken. Toegang voor taken.
“De kernles is dat je elke container als potentieel compromisbaar moet behandelen en de explosie -straal rigoureus moet beperken,” zei Haziz. “AWS’s handige abstracties (taakrollen, metagegevenservice, enz.) Maken het leven gemakkelijker voor ontwikkelaars, maar wanneer meerdere taken met verschillende privilege -niveaus een onderliggende gastheer delen, is hun veiligheid slechts zo sterk als de mechanismen die ze isoleren – mechanismen die subtiele zwakheden kunnen hebben.”
De ontwikkeling komt in de nasleep van verschillende cloud -gerelateerde beveiligingszwaktes die de afgelopen weken zijn gemeld –
- Een raceconditie in de GitHub-integratie van Google Cloud Build die een aanvaller in staat had kunnen stellen om de onderhoudsreview te omzeilen en niet-beoordeelde code te bouwen nadat een opdracht “/gcbrun” is uitgegeven door de onderhoud
- Een externe code-uitvoeringskwetsbaarheid in Oracle Cloud Cloud Infrastructure (OCI) -code-editor die een aanvaller zou kunnen gebruiken om de cloud shell-omgeving van een slachtoffer te kapen en mogelijk draait in OCI-services door een slachtoffer te bedriegen, al ingelogd bij Oracle Cloud, om een kwaadaardige HTML-pagina te bezoeken die op een server wordt georganiseerd door middel van een divers van een station-aanval.
- Een aanvalstechniek genaamd I Spy die een Microsoft First-Party Application’s Service Principal (SP) in Entra ID exploiteert voor persistentie en escalatie van privileges via federale authenticatie
- A privilege escalation vulnerability in the Azure Machine Learning service that allows an attacker with only Storage Account access to modify invoker scripts stored in the AML storage account and execute arbitrary code within an AML pipeline, enabling them to extract secrets from Azure Key Vaults, escalate privileges, and gain broader access to cloud resources
- Een kwetsbaarheid van de reikwijdte in de Legacy AmazonguardDutyfulLaccess AWS beheerd beleid dat een volledige organisatorische overname van een gecompromitteerd lidaccount mogelijk zou kunnen maken door een willekeurige gedelegeerde beheerder te registreren
- Een aanvalstechniek die Azure-boog misbruikt voor escalatie van voorrechten door gebruik te maken
- Een geval van overbevorderde Azure-ingebouwde lezerrollen en een kwetsbaarheid in Azure API die door een aanvaller kan worden geketend om VPN-toetsen te lekken en vervolgens de sleutel te gebruiken om toegang te krijgen tot zowel interne cloudactiva als on-premises netwerken
- A supply chain compromise vulnerability in Google Gerrit called GerriScary that enabled unauthorized code submissions to at least 18 Google projects, including ChromiumOS (CVE-2025-1568, CVSS score: 8.8), Chromium, Dart, and Bazel, by exploiting misconfigurations in the default “addPatchSet” permission, the voting system’s label handling, and a race condition with bot Code-verzwakkingstijden tijdens het code-samenvoegproces
- Een Google Cloud -platform verkeerd configuratie die de subnetwerken blootstelde die worden gebruikt voor ledenuitwisselingen bij Internet Exchange Points (IXPS), waardoor aanvallers mogelijk de cloudinfrastructuur van Google kunnen misbruiken om ongeautoriseerde toegang te krijgen tot interne IXP LAN’s.
- Een uitbreiding van een Google Cloud Privilege Escalation -kwetsbaarheid genaamd verwarde factus die kan worden aangepast aan andere cloudplatforms zoals AWS en Azure met behulp van respectievelijk AWS Lambda- en Azure -functies
“De meest effectieve mitigatiestrategie om uw omgeving te beschermen tegen soortgelijke dreigingsacteur -gedrag is ervoor te zorgen dat alle SAS (Service Account) in uw cloudomgeving voldoet aan het principe van het minste privilege en dat er nog geen legacy cloud SA’s in gebruik zijn,” zei Talos. “Zorg ervoor dat alle cloudservices en afhankelijkheden up-to-date zijn met de nieuwste beveiligingspatches. Als Legacy SA’s aanwezig zijn, vervang ze dan door het minst-privilege SAS.”
