Högsprayning i informationssäkerhet är en attack som använder fel i arbetet med programmets minne . En hacker attackerar med högsprayning och tvingar en applikation att allokera minne för ett stort antal objekt som innehåller skadlig kod . Detta ökar framgångsfrekvensen för en exploatering som flyttar exekveringstråden till någon position i högen . Det är viktigt att förstå att utan en exploatering som gör att du kan ändra flödet av utförande, kommer högsprayning inte att orsaka någon skada. Attacken bygger på förutsägbarheten av platsen för högen i processens adressutrymme . Dessutom är allokering av minne på högen en deterministisk operation, vilket gör det möjligt att framgångsrikt tillämpa denna teknik. Högsprayning är särskilt effektivt i webbläsare , där en hackare kan allokera minne med hjälp av flera rader JavaScript på en webbsida . En viktig roll spelas av likheten mellan minnesallokering i olika operativsystem , vilket gör denna attack plattformsoberoende. Som ett resultat är det möjligt att infoga en viss sekvens av byte (till exempel en maskininstruktion) i en förutspådd adress i minnet av målprocessen [ 1] .
När en process skapas i operativsystemet tilldelas ett adressutrymme [2] [3] [4] för dess behov , vilket innehåller användardata, körbar kod och viss systeminformation som beror på det specifika operativsystemet. Användardata fördelas mellan högen och stacken beroende på hur minnet är allokerat för dem [5] . Till exempel lagrar stacksegmentet variabler med en automatisk allokeringsklass, samt information som sparas varje gång en funktion anropas, såsom returadressen. Högen är ett område med dynamiskt minne , det vill säga när minnet allokeras dynamiskt tilldelas utrymme på högen. Traditionellt växer hög och stack mot varandra [2] [3] [4] .
Högsprayning är inte en sårbarhet i sig . Den kan dock användas för att leverera skadlig kod till en processs körbara minnesområde . Denna teknik utnyttjar determinismen i systemets minnesallokeringsoperation . Detta innebär att en stor mängd minne ofta ligger på samma offset i processadressutrymmet . Denna teknik kan dock inte skapa ett brott i själva säkerhetssystemet. Därför kräver dess användning en sårbarhet som gör att du kan ändra ordningen för exekvering av kommandon (maskininstruktioner) [6] .
Det är svårt att använda denna teknik eftersom antalet faktorer som påverkar exekveringen av processen (ur en hackers synvinkel) är mycket stort. Men genom att använda högsprayning kan du utföra ett stort antal instruktioner, vilket delvis kompenserar för denna svårighet och gör att du kan öka sannolikheten för en lyckad spricka [7] .
Högsprayning kan implementeras för de flesta operativsystem och arkitekturer . Den största svårigheten är att hitta en sårbarhet som gör att du kan styra om flödet av exekvering . Dynamisk allokering av en stor mängd minne, som nämnts tidigare, är en operation som låter dig förutsäga läget för högen i minnet (vid tidpunkten för kartläggning av virtuellt minne till fysiskt minne ) [8] . Varje gång man utför samma sekvens av minnesåtkomster kommer högen med största sannolikhet att hamna på samma plats [6] [7] .
Men för att öka denna sannolikhet är det nödvändigt att storleken på en del av tilldelat minne är jämförbar med storleken på ett segment eller en sida , beroende på hur minnet är organiserat [7] .
Det största problemet med denna attack är att ändra flödet av avrättning . Utan förmågan att avlyssna avrättningen är denna typ av attack inte meningsfull. Vissa funktioner kan lagra returadressen på högen, i vilket fall en hackare kan försöka ändra dem. I det här fallet, när den återvänder från en sådan funktion, kommer den att flyttas till en minnesplats som är bekväm för en hackare , och som ett resultat kommer skadlig kod att börja exekvera . Alla funktioner som läser en adress på högen kan utnyttjas som en sårbarhet. En hackare kan ersätta denna adress med adressen till ett minne som han har ändrat. Detta kan leda till att körningstråden omdirigeras till skadlig kod. Detta är dock inte så lätt som det verkar [1] [8] .
Korrektheten av adressen (dess storlek, förskjutning i förhållande till början av sidan) som används för substitution beror mycket på arkitekturen. Därför används i praktiken block, huvudsakligen bestående av NOP: er, som lägger till den nödvändiga koden i slutet. Denna teknik låter dig inte oroa dig för noggrannheten i adressberäkningen och styra exekveringsflödet till en ungefärlig plats i adressutrymmet [1] .
Steg för att implementera högsprayning:
Denna typ av attack är mycket effektiv i webbläsare . De flesta webbläsare stöder skriptkörning . En hackare kan allokera det minne som krävs med några rader JavaScript eller ActionScript på en webbsida. En viktig roll spelas av likheten mellan minnesallokering i olika operativsystem , vilket gör denna attack plattformsoberoende. Dessutom kommer adresserna som du behöver hoppa till vara liknande [9] .
Högbesprutning användes första gången 2001 och blev utbredd sommaren 2005. Sedan dess har ett stort antal sårbarheter hittats i Internet Explorer [10] [11] . Bedrifterna var väldigt lika varandra. Varje sådan exploatering bestod av högsprayning, vars implementeringsmetod inte ändrades, och överföring av programräknaren till önskad plats i minnet . Därför erhölls en ny exploatering genom att ändra några rader HTML och byta till en ny sårbarhet [1] .
Det enklaste sättet att allokera utrymme i webbläsarens minne är att deklarera en strängvariabel och initiera den [1] .
Exempel på minnesallokering i JavaScript [9] :
var myvar = "CORELAN!" ; var myvar2 = new String ( "CORELAN!" ); var myvar3 = myvar + myvar2 ; var myvar4 = myvar3 . delsträng ( 0 , 8 );Det här är väldigt enkla exempel eftersom de markerade linjerna är små. En bit skalkod är mycket större, men ändå mindre än en hel sida minne .
Hypotetiskt är det möjligt att skriva den nödvändiga skalkoden många gånger i varje block vi allokerar, men då måste angriparen hålla reda på vilken specifik adress pekaren går till, eftersom den inte ska hamna mitt i den körbara koden . Vanligtvis agerar de annorlunda - de väljer bitar som innehåller många NOP: er, och i slutet föreskriver de nödvändiga kommandon. Då, på grund av det linjära arrangemanget av block i högen, är det lättare att observera linjäriteten i kodexekveringen och det finns ingen anledning att oroa sig för noggrannheten av att träffa början av en minnesbit [9] .
Med rätt storleksval bör de tilldelade minnesbitarna vara mycket nära storleken på heapelementet. Om det tilldelade minnet är mindre kommer det återstående utrymmet att vara ledigt. Minneshanteraren kommer i bästa fall att lämna systemskräp i detta "oallokerade utrymme", och i värsta fall lägga ett föremål av rätt storlek. I vilket fall som helst kommer detta att resultera i ett fel när du försöker exekvera denna minnesplats [1] [9] .
Således ser skriptet som används av angriparna ut så här [9] :
< html > < script > var shellcode = unescape ( '%u\4141%u\4141' ); // detta är CORELAN-etiketten var bigblock = unescape ( '%u\9090%u\9090' ); //90 är NOP-koden var headersize = 20 ; var slackspace = rubrikstorlek + skalkod . längd ; // initial storlek på vår bit: användbar kod + rubrikstorlek while ( bigblock . length < slackspace ) bigblock += bigblock ; //fyllning med NOPs var fillblock = bigblock . delsträng ( 0 , slackspace ); //användbar kodfyllning var block = bigblock . delsträng ( 0 , bigblock . length - slackspace ); //just NOPs while ( block . length + slackspace < 0x40000 ) block = block + block + fillblock ; //fyll till storleken på heapelementet - i det här fallet är det 0x40000 var memory = new Array (); for ( i = 0 ; i < 500 ; i ++ ){ memory [ i ] = block + skalkod } // välj flera sådana element. </ script > </ html >unescape()är en funktion som låter dig placera byten i exakt den ordning som anges i argumentet [1] .
VBScript används i Internet Explorer för att skapa strängar med string. Konceptuellt är det samma som JavaScript- implementeringen , bara funktionsnamnen ändras [6] .
I juli 2009 hittades exploateringar som gör det möjligt att använda ActionScript för att implementera heap-spraying i Adobe Flash [1] .
I september 2012 presenterades en ny implementering på EuSecWest 2012 [12] . Federico Muttis och Anibal Sacco har visat att mycket granulär högsprayning kan implementeras med HTML5 -teknik . De använde bitmappsgränssnittet på låg nivå som tillhandahålls av canvas API .
Det finns metoder som använder bildladdning. Bilden är sammansatt av NOP och fortsätt sedan som i tidigare fall [1] [9] .
Som med alla buffertspill finns det tre huvudförsvar. [1] Det är ofta lättare att förhindra en förändring i flödet av exekvering än den faktiska användningen av bufferten. Moderna operativsystem använder alla följande metoder:
Projekt relaterade till denna typ av attack: