Vrede mænd

Der dumpede en email ind i min mailbox for et par dage siden fra en af mine kolleger med den dramatiske titel "Vapor Trails - Hacked !". I mailen var en kort tekst, der fortalte at min gamle blog http://www.vaportrail.dk var blevet hacket af vrede mænd.

I mailen var også et screenshot af det ulykkelige site, hvor hver eneste af mine +50 blogentries var blevet overskrevet med teksten "Stop your fitna & propaganda against ISLAM. Why we are here? because, to show you, that TRUTH can not be ignore & ISLAM is the TRUTH". Jeg var blevet ramt af et "defacement" angreb.

Jeg loggede straks på sitets web baserede administrationsmodul og kunne konstatere at mit gamle password fint virkede, at alt så normalt ud bortset fra at hver evig eneste felt og titel i den tabel der indeholder blog-posts var blevet overskrevet.

Siden jeg begyndte at skrive på Version2 har jeg ikke brugt den gamle blog, men blot ladet den være. Sitet kører Wordpress og på det tidspunkt i en version fra december 2006, hvilket i Internettid betyder at den var tudsegammel. En hurtig søgning på "sql injection wordpress" afslørede da også at den slags problemer åbenbart til stadighed finder vej ind i produktet omend de bliver patchet løbende.

Efter en halv times arbejde havde jeg fået rådet bod på problemet, patchet Wordpress og genetableret databasen med den nyeste backup jeg havde til rådighed. Desværre var forsidens nyeste entry efterfølgende fra februar 2006, sidste gang jeg tog backup.

Nu var jeg pludselig en anelse svedt ved tanken om at 20 måneders skriblerier var tabt for altid og tog en tre-fire ture rundt i stuen i koncentriske cirkler før det pludselig slog mig: Google har en cache. Cachen udgør et snapshot. Cachen indeholder måske den gamle forside!

Og ganske rigtigt. Google havde været så elskværdige at gemme alle mine entries fra 2007 samt af uvisse årsager den fra april 2006, så nu er jeg nede på at mangle i omegnen af 7-8 indlæg. Hvis nogen mod forventning skulle ligge inde med dem er der en dusør ![Eksternt billede](http://www.version2.dk/uploads/smil3dbd4d6422f04.gif" alt=")

Der er i hvert fald et par moraler i denne anekdote fra det virkelige liv:

1) Der er vrede mænd derude, som åbenbart bruger tid på at finde sårbarheder i open source software. Truslen er reel.
2) Hvis du vil mindske risikoen for hacking, defacement etc. er det en god idé at holde dit website software opdateret med nye sikkerhedspatches - også selv om du ikke bruger det mere.
3) Skulle uheldet alligevel være ude er det rart at have en rimelig frisk backup af site software, databaser, etc.

Så kan jeg lære det!

Kommentarer (30)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#6 Kåre Kjelstrøm

Det er vist desværre ikke så simpelt.

Defacement angrebet sker imod en .php fil, der benyttes til at poste kommentarer af bloggens besøgende. En fejl i .php koden gør det muligt at skyde en svada SQL af, som eksekveres i kontekst af den ene DB bruger, som Wordpress er sat op med og som i sagens natur skal have skriveadgang.

Et fix kunne måske være at lave forskellige brugere med forskellige rettigheder, så kommentarsiden kun kunne tilgå kommentartabellen. Jeg valgte at opgradere softwaren i stedet.

  • 0
  • 0
#8 Jacob Christian Munch-Andersen

Så kan du måske lære at lade være med at bruge et API baseret på tekststrenge hvor kommandoer og data blandes vilkårligt.

Helt generelt må jeg sige at jeg har svært ved at forstå det smarte i SQL. Først spilder frontend koden tid på at klippe strenge sammen, så spilder netværket båndbredde på at sende disse strenge, og til sidst spilder databasekoden rigtigt meget tid på at parse strengene igen så de kan blive til noget ordentligt forståeligt maskinmad.

Midt i det hele kommer så muligheden for injections, netop fordi data skal flettes sammen med kode før det igen kan blive splittet op.

  • 0
  • 0
#9 Troels Arvin

Jacob,

Du kan sagtens optimere på den slags. Det kan fx ske ved at benytte statisk+indlejret SQL i stedet for "dynamisk SQL". Statisk SQL kan blive så statisk, at selv databasens access plan for pågældende query bliver for-beregnet - med den ulempe at den da skal refresh'es manuelt, hvis data-forholdene (kardinalitet, indeks-forhold, ...) ændrer sig meget. Statisk+indlejret SQL er dog ikke noget, man typisk støder på længere. Se fx http://publib.boulder.ibm.com/infocenter/db2luw/v9/topic/com.ibm.db2.udb... for mere om statis/dynamisk SQL.

En god mellemvej er at benytte parameteriserede, prepared queries. Flere DBMSer kan cache' access plans for den slags, og mange sikkerhedsfejl kan undgås. Fx kan en situation som http://xkcd.com/327/ undgås.

Mht. at bruge at domænespecifikt sprog til datahåndtering: Jeg synes, det giver god mening at have et sprog som er godt til netop dette. Den relativt begrænsede syntaks og SQL's fokus på det deklarative gør også, at "moden" mht. datahåndterings-programmering ikke skifter som vinden blæser - i modsætning til hvad man ser inden for bredere, imperative sprog (Cobol/PL1 -> C++/4GL -> Java/PHP -> C#/Python -> ?).

Bortset herfra: Jacob, har du et godt forslag til et generelt alternativ til at benytte SQL?

  • 0
  • 0
#11 Michael Rasmussen

Bortset herfra: Jacob, har du et godt forslag til et generelt alternativ til at benytte SQL?

Nu hedder jeg godt nok ikke jacob, men jeg har et muligt alternativ:-)

Om det er bedre end SQL, må beråde på kontekst.

Man kunne anvende XQuery mod XML.

Mængden af data vil nok være en afgørende faktor for valget, men hvor grænsen går, har jeg ingen bud på.

  • 0
  • 0
#13 Carsten Sonne

XML filer er vist ikke et reelt alternativ til RDMS. Jeg kan ikke rigtig se nogle reele alternativer. Hvis nogle har et seriøst bud, så kom endelig med det!

I øvrigt er det jo ikke SQL som sådan der er problemet ved SQL injection, men den måde SQL bliver brugt på. SQL injection problemer er et udtryk for manglende kodekvalitet, usikkert design eller at man ikke benytter sig af sikkerhedsforanstaltninger.

Mvh Carsten Sonne Larsen

  • 0
  • 0
#16 Jacob Christian Munch-Andersen

Statisk+indlejret SQL er sikkert ok rent hastighedsmæssigt, men som du selv siger er der ikke nogen der bruger det, fordi det ødelægger den ease of use som er primær drivkraft bag SQLs udbredelse.

Langt de fleste SQL databaser bruges udelukkende med helt simple quieries, indsæt et stykke data, eller pil et ud bestemt af en enkelt parameter. Det tager vel noget i retningen af 50 linjer kode at skrive et program med en fast databasestruktur som indekserer de parametre der bliver trukket data ud på, så har man en database der er lynende hurtig til netop den opgave. Vi kan så udvide tanken til at omfatte en variabel databasestruktur, men defineret kun med indekstal, ikke noget med at give tabeller og felter navne. I stedet kan man så sammensætte en liste som oversætter fra navne til tal, listen kan så bruges sammen med applikationer som er skrevet med disse navne, således kan man få menneskevenlige navne når man skriver applikationen som så forsvinder når programmet kompileres, præcis ligesom funktion- og variabelnavne.

Noget mere SQL lignende kan så bygges ovenpå for at varetage de enkelte tilfælde hvor simple quieries ikke er nok.

Jeg har ikke noget navn på en sådan applikation, for jeg har aldrig brugt databaser til noget, jeg har blot alt alt for mange gange konstateret at en web applikation er urimeligt sløv fordi den bruger alt for meget ukompileret kode.

@ Michael Rasmussen, XQuery er jo slet ikke designet til at blive brugt som databasesprog, det er bare et værktøj til at læse og skrive XML filer, så hellere SQL.

  • 0
  • 0
#17 Jacob Christian Munch-Andersen

I øvrigt er det jo ikke SQL som sådan der er problemet ved SQL injection, men den måde SQL bliver brugt på. SQL injection problemer er et udtryk for manglende kodekvalitet, usikkert design eller at man ikke benytter sig af sikkerhedsforanstaltninger.

Det er korrekt, problemet er bare at SQL i så høj grad lægger op til at en uerfaren bruger laver sikkerhedshuller, hvilket jeg mener er ret dårligt design.

  • 0
  • 0
#19 Kristian Thy

Michael R:

Man kunne anvende XQuery mod XML.

Har du set XQuerys join-syntax? Det bliver hurtigt så tungt at danse med at jeg slet ikke kan se det spille i virkeligheden. Derudover kommer så problemet med at skulle parse XML-filerne - hvis der er bare et par (hundrede) tusind records i en fil (tabel-analog) kender jeg ikke nogle værktøjer der kan gøre det hurtigere end en database.

Jacob CMA:

... problemet er bare at SQL i så høj grad lægger op til at en uerfaren bruger laver sikkerhedshuller ...

Sludder. Problemet ligger i applikationslaget der laver koden, "typisk" ved at konkatenere strenge til SQL-udtryk (en slags poor man's runtime code generation). SQL i sig selv har intet med det at gøre, det handler udelukkende om inputvalidering og idéelt set brug af parametriserede forespørgsler. Alt sammen noget der håndteres af applikationslaget, ikke databaselaget.

  • 0
  • 0
#20 Stig Johansen

@Kåre

Tror du ikke det nærmere var et remote execution exploit der var 'miseren', og ikke SQL injection?

Jeg er lidt i gang med en slags IDS systemer til webservere, og der kunne jeg godt tænke mig at spørge dig: Hvordan blev defacementet opdaget ? Hvor lang tid gik der fra defacement til opdagelsen ? Nu var det tilsyneladende et defacement, men var der også injected ewller

<

iframe> tags ? Og til sidst, hvilken version af mySQL kører/kørte du på ?

  • 0
  • 0
#22 Troels Arvin

Så vidt jeg kan se, er der ingen færdig XQuery standard som tillader opdateringer. Hvis det er korrekt forstået, giver det i mine ører højst mening at tale om XQuery som alternativ til SQL's SELECT. Og så er det vist lidt uinteressant.

  • 0
  • 0
#25 Uffe R. B. Andersen

Efter en halv times arbejde havde jeg fået rådet bod på problemet, patchet Wordpress

Hvilken fremgangsmåde har du brugt? Umiddelbart identificerer din WP sig stadig som 2.0.4 og nyeste (Legacy 2.0 Branch) er 2.0.11.

Til backup findes der flere wp-plugins, men de fleste er nok til nyere versioner end 2.0.x.

  • 0
  • 0
#26 Kristian Larsen

Jamen jeg forstår ikke helt - hvis al opsætning er lavet og hele wordpress systemet kører og det derefter i princippet skal være statisk, så er alternativet til en html eksport vel at låse databasen så der kun er read adgang fra wordpress.

Hvad er problemet i det? Dumme mig vil forstå :)

  • 0
  • 0
#28 Thomas Ammitzbøll-Bach

Nu må det jammer om SQL høre op! Det er ikke SQL, der er problemet, men manglende brug af prepare/execute.

Se eksemplet her for PHP: http://www.php.net/manual/en/mysqli-stmt.bind-param.php

Databaser er databaser, og det bliver ikke mere sikkert af, at man anvender XML, XQuery eller CSV for den sags skyld. Især hvis man stadig tekstsubstiturer data ind uden at vaske det først.

Thomas

  • 0
  • 0
#29 Kåre Kjelstrøm

Hej Stig,

Det er helt sikkert muligt - jeg har ikke fundet lige præcis den exploit jeg blev ramt af, men WP har haft problemer med både SQL injection og remote execution.

Hvordan blev defacementet opdaget ?

En af mine kolleger kiggede ved et tilfælde på sitet - jeg er der sjældent selv.

Hvor lang tid gik der fra defacement til opdagelsen ?

Max 3 dage, idet jeg faktisk netop havde været derinde. Men det er som sagt et rent tilfælde.

Nu var det tilsyneladende et defacement, men var der også injected ewller

<

iframe> tags ?

Delvist. Der var lidt javascript, som dirrigerede brugeren videre til et website dedikeret til Muhammad.

Og til sidst, hvilken version af mySQL kører/kørte du på ?

Sitet er hostet af Surftown, der pt kører i version 3.23.56

Var der også uploadet ekstra malware (.exe filer) ? Var der også lagt bagdøre ind (.php/.pl etc.) ?

Ikke så vidt jeg kan se.

  • 0
  • 0
Log ind eller Opret konto for at kommentere