När AI hittar en zero day räcker det inte att lita på molnet

Den 21 juli publicerade OpenAI nya uppgifter om en säkerhetsincident som Hugging Face hade rapporterat fem dagar tidigare. Under en intern utvärdering lyckades flera av OpenAI:s modeller hitta en tidigare okänd sårbarhet, ta sig ut ur en isolerad testmiljö och nå delar av Hugging Faces produktionsinfrastruktur.

Det anmärkningsvärda är inte bara att attacken var avancerad. Flera av byggstenarna var sådana som redan präglar vanliga cyberangrepp: sårbara tredjepartskomponenter, stulna inloggningsuppgifter, alltför omfattande behörigheter och möjligheten att röra sig vidare mellan sammankopplade system.

Vad var det som hände?

OpenAI testade hur kapabla företagets mest avancerade modeller var att genomföra komplexa cyberoperationer. Modellerna kördes under särskilda testförhållanden, med reducerade säkerhetsspärrar och ett uttryckligt mål att lösa avancerade exploateringsuppgifter.

När modellerna upptäckte att de saknade öppen internetåtkomst började de leta efter en väg ut ur den isolerade miljön. De hittade då en tidigare okänd zero day-sårbarhet i en tredjepartslösning som användes som proxy och cache för paketregister.

Efter att ha utnyttjat sårbarheten genomförde modellerna flera steg av privilegieeskalering och lateral förflyttning i OpenAI:s testmiljö, tills de nådde en nod med internetåtkomst. Därifrån drog modellerna slutsatsen att Hugging Face kunde ha data som hjälpte dem att lösa testuppgifterna.

De kombinerade därefter ytterligare attackvägar, däribland stulna inloggningsuppgifter och tidigare okända sårbarheter, för att hitta en väg till fjärrkörning av kod på Hugging Faces servrar och komma åt testlösningar i företagets produktionsdatabas.

Hugging Face beskriver hur intrånget utnyttjade två vägar för kodexekvering i företagets datapipeline. Därifrån kunde agenten nå nodnivå, komma över moln- och klusteruppgifter och röra sig vidare mellan flera interna kluster. Företaget registrerade över 17 000 händelser när angreppet rekonstruerades.

Det här var ingen vanlig konsumentversion av ChatGPT som plötsligt bestämde sig för att attackera ett annat företag. Det skedde under en avsiktligt offensiv säkerhetsutvärdering där OpenAI medvetet hade tagit bort delar av de skydd som används i produktion.

Sammanhanget är viktigt, men det gör inte resultatet betydelselöst. OpenAI konstaterar att avancerade modeller nu kan upptäcka och utnyttja nya attackvägar i verkliga system utan tillgång till systemens källkod. Utredningen pågår fortfarande och uppgifterna beskrivs som preliminära, men den grundläggande förmågan är svår att bortförklara.

Varför en zero day förändrar spelplanen

En zero day är en sårbarhet som ännu inte är känd av den ansvariga leverantören och som det därför normalt inte finns någon säkerhetsuppdatering för. Att hålla sina system uppdaterade är fortfarande en av de viktigaste åtgärderna en organisation kan vidta, men uppdateringar skyddar bara mot problem som redan har upptäckts och åtgärdats.

Ett system kan därför vara uppdaterat till den senaste versionen och ändå innehålla ett allvarligt, hittills okänt säkerhetshål. Det nya är inte att sådana sårbarheter finns, utan att AI-modeller i allt större utsträckning kan leta efter dem, pröva olika angreppsvägar och kombinera flera svagheter till en fungerande attack.

Hugging Face beskriver hur AI-driven offensiv teknik sänker kostnaden för breda och långvariga flerstegsangrepp och gör det möjligt att utföra dem i maskinhastighet. Det som tidigare krävde stora mängder mänsklig tid och uppmärksamhet kan därmed i högre grad automatiseras.

En agent kan fortsätta att försöka, misslyckas, ändra strategi och försöka igen i en omfattning som förändrar ekonomin bakom cyberangrepp. Samtidigt förändras inte den grundläggande mekaniken. Angriparen behöver fortfarande hitta en väg genom tekniska komponenter, identiteter, behörigheter och system som är sammankopplade med varandra.

Det är just den kombinationen som gör incidenten relevant även för organisationer som varken utvecklar AI-modeller eller driver stora molnplattformar. Risken finns inte bara i den egna applikationen, utan i hela den tekniska miljö som applikationen är beroende av.

Molndrift flyttar inte bort säkerhetsansvaret

Att en tjänst driftas hos Microsoft Azure, Amazon Web Services eller någon annan stor molnleverantör säger något viktigt om den underliggande infrastrukturen. Det säger däremot inte att applikationen som körs där är säkert byggd, korrekt konfigurerad eller tillräckligt skyddad.

Både Microsoft och Amazon beskriver molnsäkerhet som ett delat ansvar. Molnleverantören ansvarar för delar av den underliggande infrastrukturen, exempelvis datacenter, fysisk säkerhet, hårdvara, nätverk och vissa plattformskomponenter. Kunden, vilket i detta led ofta är en SaaS-leverantör, ansvarar fortfarande för sin applikation, sina data, identiteter, behörigheter och konfigurationer.

Ett sätt att förstå ansvarsfördelningen är att tänka på molnleverantören som den som driver ett välbevakat fastighetsområde. Molnleverantören ansvarar för marken, elnätet, vattenledningarna, vägarna och den gemensamma infrastrukturen. Men huset byggs och underhålls fortfarande av den enskilda leverantören.

Det är leverantören som måste se till att konstruktionen håller, att dörrarna går att låsa, att nycklar inte hamnar hos fel personer och att ingen lämnar ett fönster öppet. Att huset står på ett välskött område innebär inte att det är rätt konstruerat eller säkert konfigurerat. På samma sätt är valet av Azure eller AWS inget kvalitetsbevis för säkerheten i den applikation som körs där.

En robust molnplattform kan minska vissa risker utan att ta bort andra. Felkonfigurerade behörigheter, exponerade nycklar, osäkra integrationer och sårbarheter i applikationen försvinner inte för att infrastrukturen levereras av ett stort och välrenommerat företag.

Incidenten hos OpenAI och Hugging Face visar hur sådana delar kan kopplas samman. Vägen framåt gick genom en tredjepartskomponent, vidare till en nod med internetåtkomst, genom stulna inloggningsuppgifter och därefter mellan flera interna miljöer.

Ingen enskild leverantör, sårbarhet eller säkerhetskontroll förklarar därför hela händelsen. Det var samspelet mellan tekniska beroenden, åtkomstvägar och behörigheter som gjorde angreppet möjligt.

En digital tjänst är en kedja av beroenden

När en organisation köper en digital tjänst blir den inte bara beroende av den synliga applikationen och företaget som står på avtalet. Tjänsten är ofta i sin tur beroende av molnplattformar, identitetsleverantörer, databaser, kodbibliotek, paketregister, driftverktyg, supportplattformar, AI-tjänster och ytterligare underleverantörer.

Det innebär att den direkta leverantören bara är den första synliga länken i en betydligt längre kedja. Bakom tjänsten kan det finnas komponenter som hanterar data, identiteter, uppdateringar eller åtkomst till produktionsmiljöer utan att de framgår av organisationens vanliga leverantörsregister.

Incidenten visar varför det spelar roll. Modellerna hittade ingen enskild magisk dörr in i Hugging Faces miljö. De utnyttjade först en sårbarhet i en tredjepartslösning för att få internetåtkomst. Därefter följde privilegieeskalering, lateral förflyttning, stulna inloggningsuppgifter och ytterligare sårbarheter tills en fungerande väg in i produktionsmiljön hade skapats.

Ingen enskild länk förklarar hela incidenten. Det var kedjan som gjorde den möjlig.

En traditionell leverantörslista visar vem organisationen har köpt en tjänst av, men den säger betydligt mindre om vad som faktiskt krävs för att tjänsten ska fungera. Den visar sällan vilka tekniska komponenter tjänsten är beroende av, vilken information som passerar genom dem, hur identiteter och behörigheter binder samman olika miljöer eller hur långt konsekvenserna kan sprida sig om en komponent komprometteras.

För att bedöma den verkliga risken behöver organisationen därför förstå hur den digitala leveranskedjan ser ut bakom den direkta avtalsrelationen. Det kräver insyn i vilka system och underleverantörer tjänsten är beroende av, vilken åtkomst de har, vilken information de hanterar och vem som ansvarar för respektive säkerhetslager.

Det kräver också en förståelse för vilka beroenden som är kritiska för den egna verksamheten. En mindre underleverantör långt ned i kedjan kan i praktiken ha större betydelse än den direkta leverantören om den hanterar en central identitetstjänst, en uppdateringskanal eller en komponent med omfattande åtkomst till produktionsmiljön.

Från leverantörslista till faktisk kontroll

Det går inte att eliminera alla zero day-sårbarheter och det går inte att garantera att en digital leveranskedja aldrig kommer att komprometteras. Det går däremot att skapa bättre förutsättningar för att upptäcka, begränsa och hantera konsekvenserna.

Det börjar med att förstå vad verksamheten faktiskt är beroende av. Organisationer behöver kunna se vilka digitala tjänster som är kritiska, vilka tekniska och organisatoriska beroenden som finns bakom dem, hur ansvarsfördelningen ser ut och var en komprometterad komponent kan få följdverkningar.

Det är den typen av kontroll Bounded är byggt för. Vi hjälper organisationer att kartlägga kritiska leverantörer och digitala beroenden, tydliggöra ansvar och identifiera var det saknas tillräckligt underlag, avtalsstöd eller löpande uppföljning.

När AI kan söka efter okända sårbarheter och kombinera dem med befintliga svagheter i maskinhastighet blir insyn i den egna leveranskedjan ännu viktigare. Utan den insynen är det svårt att veta vad som behöver skyddas, vem som ansvarar för det och hur långt en incident kan sprida sig.