Säkerhetshål i Timthumb.php

Marcus Olsson,

I förrgår så fick vi ett stort problem med en sida som jag har jobbat på, flera användare rapporterade att de fick “virusvarningar” då de besökte webbplatsen.

Att en WordPress-sida blir hackad är kanske i sig självt inget nytt, men hur mycket jag än letade så hittade jag inga tecken på ett “vanligt” intrång.

Till slut så lyckades vi med att hitta en js-fil som inte hörde hemma på sidan, nämligen “wp-includes/js/l10n.js?ver=20101110”.

Efter lite sökande efter vad som kunde ha orsakat detta så hittade jag, till min fasa, att det var hos Timthumb.php som felet låg. Om du inte vet vad Timthumb är så är det ett enkelt skript som man kan använda för att skala om bilder till exakt de dimensionerna man vill ha – väldigt populärt att ha i olika WP-teman. Jag har även använt den på en rad andra sidor, därför blev jag inte särskilt glad när jag upptäckte var felet låg.

Säkerhetshålet bestod av att Timthumb tillät (Timthumb är numera uppdaterad) en att förstora om bilder från en extern källa, exempelvis från Flickr. Problemet var bara att Timthumb kollade efter om domännamnet som tilläts fanns i hela strängen. Så om man tillät bilder från flickr.com, så tillät man även bilder ifrån flickr.com.scamsite.org (påhittad domän).

Timthumb i sin tur exekverade filen som stoppades in i den, och man är illa ute.

Exakt vilka problem som uppstod verkar vara olika från sida till sida, i vårt fall var det inte mycket värre än att det skapades en iFrame på 1×1 pixlar som laddade om en banner i ett billigt försök att få pengar. Men jag visste att de hade haft åtkomst till mer eller mindre hela sidan, inklusive wp-config.php, där databasuppgifterna sparas. Inget bra alls.

Vidare så upptäcktes följande filer som inte hörde hemma på sidan: markt.php (som hade gömts i uploads/2010/12/) samt external_ef17f016621c086a8d2c5486eafa404c.php som hade lagt sig cache-mappen för Timthumb.

I filerna så fanns det en enorm sträng som var “base_64 encode:ad” – vilken skapade en massa “fulkod” när den väl blev decode:ad.

För att lösa det hela var i vårt fall inte jättesvårt, men ganska tidsödande och tråkigt. Då jag visste vilka filer som var utsatta så plockade jag bort dem – jag hade även en uppdatering utav WordPress som väntade (som tur var i det här fallet) och installerade dem. Kontrollerade noga att alla de gamla WP-filerna blev överskrivna med de nya, och därefter så var det byte utav FTP- och MySQL- lösenord som gällde. Även som extra försiktighetsåtgärd så fick alla medlemmarna på sidan byta lösenord. Även Timthumb uppdaterades till nyaste versionen som är helt omskriven från grunden – men är som tur är helt bakåtkompatibel, så man behöver inte skriva om någon kod i ens WP-tema.

Det finns människor som har råkat ut för betydligt mycket värre saker tack vare det här säkehetshålet, en enkel Google sökning på "timthumb vulnerability" visar en hel del exempel.

För att läsa mer om detta kan jag rekomendera den här bloggposten utav Mark Maunder (Länk död) – det är även han som påbörjade arbetet med att skriva om Timthumb från grunden.

Kort och gått, använder du Timthumb – uppdatera!