Över 9 300 läckta AWS-nycklar fungerade fortfarande

En nyckel som förekommer i ett publikt arkiv är inte automatiskt ett aktivt hot. Risken blir akut när nyckeln inte har återkallats, fortfarande fungerar och dessutom har betydande behörigheter. I den här granskningen sammanföll de tre omständigheterna ofta.

Hundratals företagsnycklar gav full administratörskontroll

Av de aktiva nycklar som kopplades till företagskonton tillhörde 817 företag. Gruppen bestod av:

• 526 nycklar till AWS root-konton
• 242 nycklar för IAM-användare med AWS-policyn AdministratorAccess
• 768 nycklar totalt som gav full administrativ kontroll över ett företags AWS-konto

Root-behörighet är den högsta kontrollnivån för en AWS-kund. En IAM-identitet med AdministratorAccess kan i sin tur utföra åtgärder i AWS-tjänster med mycket omfattande rättigheter. En giltig nyckel på någon av dessa nivåer kan därför bana väg för kontoövertagande, obehörig åtkomst till data, skapande av egna resurser eller missbruk som snabbt driver upp molnräkningen.

Resultatet pekar därmed på ett problem med både behörigheter och livscykelhantering – inte bara på bristande ordning i källkoden. Att ta bort en nyckel ur en synlig fil skyddar inte kontot om någon redan har kopierat den. Nyckeln måste återkallas eller bytas ut.

Hugging Face var den största enskilda källan

Hugging Face stod för 8 482 exponeringar av AWS-uppgifter och var den största enskilda källan i rapporteringen. Truffle Security uppgav att 17,9 procent av dessa AWS-uppgifter var root-uppgifter.

Det ligger i linje med en bredare genomsökning av publika data på Hugging Face. Truffle Security uppgav att företaget analyserade 7,6 petabyte offentliga dataset och hittade aktiva autentiseringsuppgifter i tusentals dataset. Det visar hur hemligheter kan leva kvar utanför vanliga programvaruarkiv och följa med data som senare sprids offentligt.

För säkerhetsteam är slutsatsen tydlig: det räcker inte att söka igenom dagens källkod. Git-historik, byggartefakter, containeravbildningar, register, publicerade dataset och CI-utdata kan fortsätta att innehålla uppgifter efter att utvecklare tror att de har raderats.

Många nycklar var flera år gamla

Den rapporterade medianåldern för nycklarna var cirka 1 831 dagar, alltså ungefär fem år. Den äldsta nyckeln var 17,4 år gammal. Bara 13,7 procent av posterna hade en nyare kopplad nyckel, vilket tyder på att de flesta inte hade bytts ut genom en regelbunden rotationsprocess.

Långlivade åtkomstnycklar ger obehöriga mer tid att utnyttja dem och gör det svårare att fastställa vem som äger dem. De kan också överleva personalbyten, systemmigreringar, städning av kodarkiv och förändringar i driftansvar.

Ålder bör därför ses som en tydlig risksignal. En exponerad nyckel som är flera år gammal ska inte avfärdas som föråldrad. Den bör kontrolleras, återkallas och utredas – om inte ägaren kan visa att den inte längre är giltig.

Få konton hade budgetvarningar

Truffle Security kunde läsa kontoinformation för 2 754 konton, men bara 262 av dem hade aktiverade AWS-budgetvarningar.

Budgetvarningar ersätter varken återkallade nycklar eller övervakning av hot, men de kan ge en tidig signal om att exponerade uppgifter används för att skapa kostsamma resurser – exempelvis för kryptomining eller annan molnmissbruk. Utan en notifiering som når någon med mandat att agera kan ovanligt hög förbrukning fortsätta även efter att ett konto har komprometterats.

Aviseringar löser inte hela problemet

Rapporteringen beskriver skydd i AWS som kan upptäcka offentliggjorda åtkomstnycklar, meddela berörda kunder och införa begränsningar eller karantänåtgärder. Att så många av de testade nycklarna fortfarande fungerade tyder dock på att upptäckt eller avisering inte konsekvent ledde till snabb återkallelse och rotation hos kunderna.

Upptäckt är bara det första steget. En fullständig hantering måste identifiera ägaren, fastställa vad uppgiften kan nå, kontrollera om den har missbrukats och därefter göra nyckeln ogiltig. Truffle Security beskriver sin egen validering som skrivskyddad: företaget kontrollerade autentisering samt behörighets- och kontometadata, utan att ändra kundernas resurser. Denna beskrivning kommer från Truffle Security och är inte oberoende verifierad i alla delar av det tillgängliga källmaterialet.

Så bör organisationer agera efter en AWS-läcka

1. Återkalla eller byt nyckeln omedelbart

Radera eller inaktivera alla publikt exponerade uppgifter och skapa bara en ersättare om åtkomsten fortfarande behövs. Att ta bort hemligheten ur ett arkiv, radera filen eller skriva om Git-historiken gör inte kopior som redan har hämtats ogiltiga.

2. Ta bort root-åtkomstnycklar

AWS root-åtkomstnycklar ska inte användas för vanlig programmatisk åtkomst. Ta bort root-nycklar och flytta arbetslaster till kontrollerade identiteter med så begränsade rättigheter som möjligt.

3. Kontrollera behörighet och ägarskap

Fastställ vilket konto, vilken användare eller tjänst och vilka resurser nyckeln var kopplad till. Prioritera nycklar med root-behörighet, AdministratorAccess, bred dataåtkomst eller möjlighet att skapa infrastruktur.

4. Utred både före och efter återkallelsen

Gå igenom autentiseringsaktivitet, CloudTrail-loggar, ändringar i IAM, nyskapade resurser och fakturering efter tecken på missbruk. Att återkalla nyckeln stoppar fortsatt användning, men visar inte om den redan har utnyttjats.

5. Byt långlivade nycklar mot kortlivade identiteter

Använd om möjligt kortlivade IAM-roller och identiteter för arbetslaster i stället för permanenta åtkomstnycklar. Principen om minsta möjliga behörighet begränsar skadan om en uppgift ändå läcker.

6. Aktivera budgetvarningar och en tydlig larmkedja

Konfigurera varningar i AWS Budgets och övervakning av kostnadsavvikelser. Skicka aviseringarna till personer som snabbt kan vidta åtgärder. Ekonomisk övervakning är ett skyddsnät – inte en ersättning för hemlighetsskanning, nyckelrotation och regelbundna behörighetskontroller.

Den större säkerhetsläxan

Det viktigaste resultatet var inte bara antalet hemligheter. Det var kombinationen av offentlig exponering, fortsatt giltighet, höga behörigheter, mycket hög ålder och bristande övervakning. Publika datakällor kan bevara uppgifter långt efter att en organisation har glömt var de användes, medan en kopierad nyckel kan fortsätta fungera tills den uttryckligen återkallas.

För molnteam är den säkraste utgångspunkten därför enkel: behandla varje exponerad AWS-uppgift som komprometterad, kontrollera vad den kan nå, återkalla eller byt den omedelbart och ersätt långlivad åtkomst med kortlivade identiteter som har minsta möjliga behörighet.