Som väl är bekant släpper mjukvarutillverkare uppdateringar (patchar) till sin programvara. Ibland är dessa uppgraderingar till för att förbättra applikationens funktioner, men oftast för att täppa igen säkerhetshål som har upptäckts. Dessa patchar är viktiga att lägga på; till exempel skriver Riksrevisionen i en utvärdering:
“Att kontinuerligt analysera och välja vad som bör installeras av de patchar som tillhandahålls av leverantörerna är en viktig del i att bibehålla säkerhetsnivån. Om denna del blir eftersatt så kommer det på sikt att öka sårbarheten för kända attacker och angreppssätt.”
På senare tid har den kritiska tidsfaktorn mellan att uppdateringen släpps och att sårbarheten den täpper till börjar utnyttjas av hackare minskat. Detta beror på i huvudsak två saker: den exakta orsaken till säkerhetshålen sprids (medvetet eller omedvetet) av de som råkat upptäcka dem samt att de som är ute för att skapa illvillig kod har blivit duktiga på så kallad ””reverse engineering””.
””Reverse engineering”” eller bakåtkompilering, som man i detta fall kan kalla det på svenska, innebär att den exekverbara programkoden de-kompileras och blir läsbar assemblerkod (föklaring av vad detta är finns sist i texten). Genom att jämföra den kodversion som fanns innan det att uppdateringen installerades och hur den ser ut efteråt går det att läsa ut exakt vilken typ av felrättning som genomfördes i den aktuella patchen. Genom att hitta denna exakta orsak går det relativt lätt att skriva ett program (t.ex. ett virus eller trojan) som använder sig av detta hål.
När väl ett program som utnyttjar säkerhetshålet är skrivet är det alltså bara en tidsfråga innan det börjar användas. Alla system som inte hunnits bli uppdaterade ännu är då sårbara. Tidsfristen innan en attack kan genomföras beror naturligtvis mycket på vilken typ av sårbarhet som lagats i uppdateringen och motivationen hos de som skapar koden. Enligt Sabre-Security hittade de den exakta kodsekvensen som uppdaterades av en Micrsoftuppdatering på 20 minuter och skrev en skadlig kod som kunde användas mot oskyddade systen på mindre än 10 timmar (källa: SecurityFocus.com, 2005-07-01).
Vad är det då den skadliga koden gör? Oftast handlar det säkerhetshålet om buffertöverskrivningar, det vill säga att ett program tar in ett argument vars storlek inte kontrolleras. Den buffert som är skapad att ta hand om argumentet (ett tal, en sträng eller någon annan typ av variabel) blir då full, samt att den efterföljande koden i minnearean blir överskriden. Genom att skriva över exekverbar kod med skräpdata av en viss längd kan man få programmet att hoppa till att utföra helt andra intruktioner än de avsedda. Detta kan helt enkelt krascha applikationen eller, ännu värre, öppna för att installera trojaner.
Vad är då risken med att installera en patch så snart den är tillgänglig? Det finns några saker som kan inträffa, varav jag nämner två aktuella exempel här:
Att så snabbt som möjligt installera de säkerhetsuppdateringar som släpps till operativsystem och program måste nog ändå anses som viktigt. Men – och det är ett stort ””””men”””” – det är några viktiga handgrepp som måste göras i samband med uppdateringen:
För att se vilka säkerhetspatchar som redan är installerade eller som behöver installeras, finns det för de vanligaste Microsoftprodukterna ett stödverktyg som heter Microsoft Base Security Analyser (MBSA). För andra system, t.ex. Linux finns ofta motsvarande uppdateringsapplikationer, så som YaST eller Up2date.
De-kompilering eller bakåtkompilering:
© 2005 Carl Ljungqvist, Certezza AB
Carl Ljungqvist
