RSS
 

Posts Tagged ‘säkerhetshål’

WordPress-sajter hackade med TimThumb

25 Aug

Den här månaden har verktyget TimThumb använts för att hacka ett stort antal WordPress-sajter. Timthumb används för att skala ner en bild den hämtat från valfri adress. Av säkerhetsskäl går det som standard endast att hämta filer från vissa domännamn, till exempel flickr.com och picasa.com.

Kontrollen av adressen som angetts gör via php-kommandot stristr som endast kontrollerar att en av de godkända domännamnen finns med någonstans i hostnamnet som angetts.

Det innebär att även adresser som http://flickr.com.firastbill.com/flickr.com/huy3.php godkändes, filen hämtades och sparades på WordPress-sajten. På den hackade WordPress-sajten har oftast två shellscript-filer lagts in, på wp-admin/upd.php och wp-content/upd.php. Passwordet som används verkar alltid vara en slumpad siffra upp till 100 och det är därför lätt att upptäcka passwordet utifrån md-hashen. I fallet nedan är passwordet 59.

Dessutom läggs php-kod in i wp-config.php och wp-settings.php. I wp-config läggs detta in:

I wp-settings.php läggs detta in:

Koden i wp-settings körs endast om Googlebot kommer på besök medan koden i wp-config.php används av hackern för att kontrollera sajten. Förutom att få direktaccess till WordPress-sajtens adminsida kan hackern även ladda hem och köra php-kod. Denna möjlighet har hackern använt på ett lite oväntat sätt. En rad ur accessloggen för en hackad sajt ser ut så här:

Superpuperdomain.com står under hackerns kontroll och ligger för tillfället nere så man kan inte se vad filen tim.txt. Däremot kan man se vad som skedde samtidigt. När scriptet från superpuperdomain.com kördes hämtades http://timthumb.googlecode.com/svn/trunk/timthumb.php som är senaste versionen av TimThumb.

Den nya TimThumb-filen har installerats och säkerhetshålet som gjorde att hackern först kom in är nu alltså åtgärdat. Antagligen görs det för att stoppa andra hackers från att komma in och försvåra upptäckt av sajter som hackats.

Sucuri.net listar över 150 olika WordPress-tema som innehåller en osäker version av Timthumb. De har då endast kontrollerat de tema som är fritt tillgängliga på WordPress.org.

Uppdatering 29 augusti: I fredags körde hackern ett script på http://91.196.216.20/16.txt (sparad kopia). Detta script söker genom kontot efter wp-settings.php och tar bort den skadliga koden som tidigare lagts in. Även http://91.196.216.20/19.txt (sparad kopia) har använts för att hämta hem ytterligare filer och lägga in krypterad javascriptkod i wp-includes/js/l10n.js och wp-includes/js/jquery/jquery.js.

 
 

Hoppsan, mysql.com hackat via sql-injection

02 Apr

Förra helgen hackades mysql.com, databasnamn, tabeller, användarnamn och krypterade lösenord postades till mailinglistan Full-Disclosure. Enligt posten var http://mysql.com/customers/view/index.html?id=1170 sårbar för blind sql injection.

Några av lösenorden har nu dekrypterats och som vanligt är det de lätta lösenorden som knäcks först.

Avsändare för mailet till Full-Disclosure var Jackh4xor men säkerhetshålet upptäcktes redan i januari av TinKode & Ne0h. I januari upptäckte TinKode även ett XSS-hål på mysql.com. I sambandet med intrånget förra helgen publicerades även information från databaser på sun.com. Även där skedde intrånget med hjälp av sql injection.

Jackh4xor @ w4ck1ng

 
 

Joomla 1.6 öppet för spamutskick

12 Jan

Joomla 1.6 släpptes som stabil version 10 januari och samma dag upptäcktes ett säkerhetshål som gör att scriptet kan användas för att skicka ut spam.

Den enda kontrollen som görs är att meddelandet måste börja med en adress som hör till Joomla-installationen, i detta fall http://localhost/index.php. Spammaren kan själv välja vad som ska stå efter den adressen och vad som ska stå som avsändaradress och avsändarnamn.

För att skicka spam går man in på en speciell adress, till exempel http://localhost/index.php?option=com_mailto&tmpl=component&template=beez_20&link=BASE64 där BASE64 är det meddelande man vill skicka base64-kodat, i exemplet ovan:

http://localhost/index.php
SPAM SPAM SPAM
http://spamdomain.com/
SPAM SPAM SPAM

som base64-kodas till:

aHR0cDovL2xvY2FsaG9zdC9pbmRleC5waHANClNQQU0gU1BBTSBTUEFNDQpodHRwOi8vc3BhbWRv
bWFpbi5jb20vDQpTUEFNIFNQQU0gU1BBTQ==

Man kommer då till ett formulär där man anger mottagaradress, avsändaradress, avsändarnamn och ämne. Säkerhetshålet finns även i 1.5.22.

 
 

IBMs utvecklarsajt hackad

11 Jan

IBMs utvecklarsajt på http://www.ibm.com/developerworks/linux/ hackades i lördags. Enligt texten som lades upp utfördes hacket för att varna IBM för att sajten har flera allvarliga säkerhetshål.

”Tidak ada seorangpun, hewan atau banci yang disakiti dalam hacking ini” är indonesiska och betyder ungefär ”Ingen som skadar djur eller är vekling i detta hack”.

På mailinglistan Full Disclosure meddelar Maciej Gojny på Ariko-Security att de kontaktade IBM för flera månader sedan angående säkerhetshål på sajten men inte togs på allvar. Enligt Computerworld gällde det ett antal IBM-sajter som var sårbara för bland annat cross-site scripting (XSS), directory traversal och frame injection.

 
 

Hackerattack mot Binero

05 Jan

IDG rapporterar idag att kunder hos Binero i mellandagarna blev hackade. Inga existerande filer ska ha ändrats, istället har nya html-filer lagts upp som bevis på att hacken genomförts. Binero skriver på sin egen blogg att problemet upptäcktes i mellandagarna.

Men Binero har haft problem under längre tid än så här. Deras egen blogg på blogg.binero.se hackades redan 2 december tillsammans med bland annat sitebuilder.binero.se, demobuilder.binero.se och support.binero.se. IP-nummer 195.74.38.18 som är en av de servrar där Bineros kunder blev också hackat 2 december och filer lades upp på över tusen olika konton.

 
 

Säkerhetshål i Phoenix Exploit Kit 2.3

04 Jan

Phoenix Exploit Kit är ett script som används för att enkelt smitta datorer med malware. Det består dels av filer som attackerar kända säkerhetshål i webbläsare, Adobe Flash och Adobe reader, dels av en kontrollpanel där man enkelt kan ladda upp den fil man vill ska installeras på attackerade datorer och se statistik över attacken.

Ironiskt nog innehåller denna kontrollpanel ett säkerhetshål som rapporterades 2 januari. Säkerhetshålet gör att man kan logga in utan att känna till lösenordet förutsatt att serverns har register_globals aktiverat. Php-koden som hanterar inloggningen ser ut så här:

I rad 9 och 10 kontrolleras dels om något är fel med lösenordet (pw), dels om något är fel med användarnamnet (login). Sistnämnda är intressant, då man på kontrollpanelens inloggningssida endast fyller i lösenord. För att inloggningen ska misslyckas måste både lösenord och användarnamn vara felaktigt.

Variabeln $ADMINLN som kontrolleras på rad 10 sätts aldrig. Det spelar ingen roll för funktionaliteten eftersom en misslyckad inloggning kräver att både lösenordet och användarnamnet är fel. Däremot kan man sätta $ADMINLN, enklast genom att ange det i adressfältet, förutsatt att register_globals är aktiverat. På rad  21 sätts sessioncookie med namnet ‘login’ oavsett om inloggningen lyckats eller inte, rad 22 gör att sidan laddas om och först då kontrolleras att inloggningen är korrekt, via rad 9 och 10.

Vi har alltså möjlighet att kontrollera värdena i både sessioncookien ‘login’ och variabeln $ADMINLN. Eftersom kontrollen på rad 9 och 10 godkänner inloggning om inte både lösenord och användarnamn är fel kan vi nu logga in utan att veta lösenordet, eftersom vi har full kontroll över användarnamnet.

Enklast är att visa med hjälp av ett php-script.

<?php
$ch = curl_init();

curl_setopt($ch, CURLOPT_COOKIEJAR, ”cookie.txt”);
curl_setopt($ch, CURLOPT_URL, ”http://example.org/phoenix/statistics.php”);
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS, ‘login=’);
curl_exec($ch);

curl_setopt($ch, CURLOPT_URL, ”http://example.org/phoenix/statistics.php?ADMINLN=da39a3ee5e6b4b0d3255bfef95601890afd80709”);
curl_setopt($ch, CURLOPT_POST, 0);
curl_exec($ch);

curl_close($ch);
?>

I den första curl-requesten postar vi ett formulär till inloggningssidan, i detta fall http://example.org/phoenix/statistics.php. Enda fältet i det postade formuläret är login som lämnas tomt. Sessioncookien ‘login’ kommer nu att sättas med värdet av sha1-hash av en tom sträng. I nästa curl-request hämtar vi sidan igen och denna gången kommer $ADMINLN att sättas via adressen. Den sätts till värdet av sha1-hash av en tom sträng. När inloggningen kontrolleras kommer vi att uppfylla både kravet att sessioncookien ‘login’ är satt och att den har samma värde som variabeln $ADMINLN. Php-scriptet kommer att returnera sen html-kod som visas efter en lyckad inloggning.

 

Säkerhetsuppdatering av WordPress

30 Dec

Igår släpptes WordPress 3.0.4, denna version benämns som en kritisk säkerhetsuppdatering. En exploit som utnyttjar säkerhetshålet publicerades 27 december och utnyttjar det faktum att postad HTML-kod inte hanteras rätt om den innehåller versaler.

Detta rättas i uppdateringen till genom att koden först omvandlas till gemener.