När det kommer till mobil säkerhet, varnas användare rutinmässigt för att vara mycket försiktiga och undvika misstänkta länkar, e-postmeddelanden och bilagor. Men tillväxten av klickfria attacker går förbi dessa mjuka försvar.
Google genomförde nyligen en sådan attack, som visade sig ha drabbat en iPhone. “Vi bedömer att detta är en av de mest tekniskt sofistikerade bedrifterna vi någonsin har sett, vilket ytterligare visar att (en leverantörs) kapacitet ger konkurrens till dem som tidigare ansågs vara tillgängliga endast för en handfull nationalstater.” sa Googles meddelande.
Den läskigaste delen av Googles rapport, och det finns många skrämmande delar, är att den bryter mot en av de oskrivna reglerna för säkerhetsvarningar, nämligen att det inte är optimalt att rapportera detaljerna om en attack som det inte finns något försvar mot. Jag håller med Google här om att detaljerna måste diskuteras så att gemenskapen kan komma med ett försvar snabbare.
“Det har dokumenterats att NSO erbjuder sina kunder no-click-exploateringsteknik, där även tekniskt kunniga mål som kanske inte klickar på en nätfiske-länk är helt omedvetna om att de blir attackerade. I scenariot med nollklick krävs ingen användarinteraktion. Det vill säga att angriparen inte behöver skicka nätfiskemeddelanden. Exploateringen fungerar helt enkelt tyst i bakgrunden. Förutom att inte använda en enhet, finns det inget sätt att förhindra exploatering via en exploatering utan klick. Det är ett vapen som det inte finns något försvar mot.”
Med den tröstande tanken, låt oss gå in i detaljerna.
Grafen som egentligen inte är en graf
Företaget bakom programvaran som används i dessa attacker, NSO, ska enligt uppgift använda ett falskt GIF-trick för att attackera en sårbarhet i CoreGraphics PDF-parser. Filerna har filtillägget .gif, men är inte GIF-bildfiler. Namnet är endast utformat för att hindra en användare från att oroa sig.
“ImageIO-biblioteket används för att gissa rätt format på källfilen och analysera den, utan att fullständigt ignorera filtillägget. Genom att använda detta falska gif-trick är över 20 bildkodekar plötsligt en del av iMessages klickfria attackyta, inklusive några mycket obskyra och komplexa format, som på distans exponerar förmodligen hundratusentals rader kod.”
Som Google noterade är dessa attacker svåra att motverka. Att blockera alla GIF-bilder kommer sannolikt inte att vara effektivt. För det första är dessa filer faktiskt inte GIF-filer. Det enklaste tillvägagångssättet är att blockera vad som helst med en GIF-tillägg, men skurkarna kommer helt enkelt att byta till en annan ofarligt klingande tillägg.
(Obs: Googles rapport säger att Apple har försökt negera GIF-attacken genom patchar som släpptes 2021. “Apple informerar oss om att de har begränsat de tillgängliga ImageIO-formaten som kan nås från IMTranscoderAgent från och med iOS 14.8 .1 (26 oktober, 2021) och helt tog bort IMTranscoderAgent GIF-kodsökvägen från och med iOS 15.0 (20 september 2021), och GIF-avkodning gjordes helt inom BlastDoor.”
Kompressionstekniken
Detta är en vanlig legitim taktik för att minska filstorleken genom att ersätta några upprepade tecken. Detta kommer in i ogräset lite: “Detta ger den aktuella landningssidan JBIG2Bitmap ett okänt, men mycket stort, värde för h. Eftersom det h-värdet används för gränskontroll och är tänkt att återspegla den tilldelade storleken på sidans stödbuffert, har detta effekten av att “avbinda” ritytan. Detta innebär att efterföljande JBIG2-segmentkommandon kan läsa och skriva till minnet utanför de ursprungliga gränserna för sidbackingbufferten.”
Resultatet?
“Genom att rendera 4-byte bitmappar till de korrekta arbetsytans koordinater kan de skriva till alla fält på JBIG2Bitmap-sidan, och genom att noggrant välja nya värden för w, h och linje kan de skriva med godtyckliga förskjutningar från stödbufferten på sidan JBIG2Bitmap. Vid denna tidpunkt skulle det också vara möjligt att skriva till godtyckliga absoluta minnesadresser om du kände till deras förskjutningar från sidans stödbuffert. Men hur beräknar man dessa ersättningar? Hittills har denna exploatering fortskridit på ett mycket liknande sätt som ett kanoniskt skriptspråksexploat som i Javascript kan sluta med ett obegränsat ArrayBuffer-objekt med minnesåtkomst. Men i de fallen har angriparen förmågan att köra godtyckligt Javascript, vilket uppenbarligen kan användas för att beräkna offset och utföra godtyckliga beräkningar. Hur gör man det i en bildanalysator för en gång? I praktiken betyder detta att det är möjligt att tillämpa de logiska operatorerna AND, OR, XOR och XNOR mellan minnesregioner med godtyckliga förskjutningar av JBIG2Bitmap-backingbufferten för den aktuella sidan. Och eftersom det har varit obegränsat… är det möjligt att utföra dessa logiska operationer i minnet med godtyckliga off-limits offset.”
Detta är ett kodningsproblem som gör att angripare kan smyga in och exekvera obehörig kod. Denna information är kritisk eftersom den tillåter kodare att undvika detta hål då och då och ger programvaran något konkret att hitta och blockera.
Attacker utanför räckvidden
En annan poäng från Google: “JBIG2 har inte skriptfunktioner, men i kombination med en sårbarhet har den förmågan att emulera godtyckliga logiska grindkretsar som arbetar i godtyckligt minne. Så varför inte använda det för att bygga din datorarkitektur och skriva det? Det är precis vad denna exploatering gör. Genom att använda mer än 70 000 segmentkommandon som definierar logiska bitoperationer, definierar de en liten datorarkitektur med funktioner som register och en komplett 64-bitars adderare och komparator, som de använder för att söka i minnet och utföra aritmetiska operationer. . Det är inte lika snabbt som Javascript, men det är i grunden beräkningsmässigt likvärdigt. Startoperationerna för escape-exploatet för sandlådan skrivs för att köras i den här logiska kretsen och allt körs i den här konstiga emulerade miljön skapad från ett enda dekompressionspass genom en JBIG2-sekvens.”
Google har helt rätt när det hävdar att dessa saker närmar sig nationalstatlig nivå av ondska. Men åtminstone dessa detaljer kommer att hjälpa CIO:er och CISO:er att börja manövrera runt det.
