WhoAMI Attack: Vardų painiavos taktika, skirta AWS aplinkai

Grėsmė debesų saugai

Kibernetinio saugumo tyrėjai atskleidė pavadinimų painiavos techniką, pavadintą whoAMI ataka, kuri leidžia asmenims manipuliuoti „Amazon Web Services“ (AWS) aplinka skelbiant apgaulingus „Amazon Machine Images“ (AMI). Šis metodas gali leisti užpuolikams vykdyti kodą AWS paskyrose tam tikromis sąlygomis, todėl kyla susirūpinimas dėl netinkamų debesų saugos konfigūracijų.

Kaip veikia whoAMI Attack

Iš esmės whoAMI ataka yra tiekimo grandinės manipuliavimo forma, kai klaidinantis išteklius naudojamas pakeisti teisėtą. Ataka pasinaudoja tuo, kaip AMI – virtualių mašinų vaizdai, naudojami AWS Elastic Compute Cloud (EC2) egzemplioriams paleisti – išgaunami iš AWS bendruomenės AMI katalogo.

Išnaudojimas veikia, kai programinės įrangos scenarijai arba automatizavimo įrankiai ieško AMI pagal pavadinimą, bet nenurodo svarbių parametrų, tokių kaip savininkas arba savininko ID. Tokiais atvejais AWS API gali grąžinti kelis AMI su atitinkamais pavadinimais, įskaitant tuos, kuriuos įkėlė nežinomi subjektai. Jei paieškos logika sukonfigūruota pasirinkti naujausią vaizdą iš sąrašo, užpuolikas gali paskelbti apgaulingą AMI tuo pačiu pavadinimu, padidindamas tikimybę, kad jis bus pasirinktas vietoj patikimo.

Neteisingai sukonfigūruoto AMI pasirinkimo pasekmės

Kai užpuoliko AMI yra įdiegtas taikinio AWS aplinkoje, jis suteikia galimybę nuotoliniu būdu vykdyti kodą (RCE). Tai reiškia, kad užpuolęs asmuo gali gauti prieigą prie egzemplioriaus ir vykdyti tolesnę kenkėjišką veiklą, pavyzdžiui:

• Neteisėtos programinės įrangos diegimas
• Skelbtini duomenys
• Sistemos nustatymų keitimas
• Nuolatinės prieigos sukūrimas ilgalaikei kontrolei

Kadangi AWS aplinkos yra plačiai naudojamos programoms, duomenų bazėms ir įmonės infrastruktūrai priglobti, sėkmingas išnaudojimas gali turėti reikšmingų pasekmių įmonėms, kurios remiasi debesijos paslaugomis.

Lygiagrečios tiekimo grandinės pažeidžiamumas

WhoAMI ataka turi panašumų su priklausomybės painiavos metodais, pastebėtais kuriant programinę įrangą. Priklausomybės painiavos atakos metu užpuolikas paskelbia paketą tuo pačiu pavadinimu kaip ir vidinės programinės įrangos priklausomybės, apgaudinėdamas kūrimo sistemas atsisiųsti padirbtą paketą. Panašiai whoAMI atveju užpuolikas patikimą AMI pakeičia panašiu, leisdamas atlikti neteisėtus pakeitimus debesyje priglobtose sistemose.

Aptikimo ir reagavimo pastangos

Saugumo analitikai, tyrę problemą, nustatė, kad šis atakos modelis paveikė nedidelę AWS naudojančių organizacijų dalį. Apie problemą AWS buvo pranešta 2024 m. rugsėjo viduryje, o AWS ją išsprendė per kelias dienas. AWS pareiškė, kad jokie įrodymai rodo, kad ši technika buvo panaudota ne pagal įgaliotas saugumo tyrimų pastangas.

Reaguodama į atradimą, AWS pristatė naują saugos funkciją, vadinamą Allowed AMI. Šis nustatymas leidžia vartotojams apibrėžti, kuriuos AMI galima naudoti jų paskyrose, taip sumažinant riziką, kad netyčia bus pasirinktas nepatvirtintas vaizdas. Be to, infrastruktūros kaip kodo įrankiai, tokie kaip „Terraform“, pradėjo duoti įspėjimus, kai naudojamas parametras „most_recent = true“, nenurodant AMI savininko, o būsimose versijose planuojama taikyti griežtesnį patvirtinimą.

Debesų saugos praktikos stiprinimas

Siekdamos sumažinti tokios taktikos poveikį, AWS aplinką valdančios organizacijos turėtų peržiūrėti savo AMI paieškos procesus ir užtikrinti, kad visose paieškose būtų nurodytas savininko ID arba patvirtintas AMI sąrašas. Įtraukiama geriausia saugumo praktika, pvz.:

• AMI pasirinkimo griežtos prieigos kontrolės įgyvendinimas
• Reguliarus debesies konfigūracijų auditas
• Naudojant AWS saugos funkcijas, pvz., Leidžiamus AMI
• Stebėjimo sprendimų taikymas neįprastiems diegimams aptikti

Pašalinusios šias spragas, įmonės gali sumažinti tikimybę tapti painiavos grėsmių, pvz., whoAMI, aukomis ir padidinti bendrą debesimis pagrįstos infrastruktūros saugumą.