Dette indlæg er alene udtryk for skribentens egen holdning.

Vrede mænd

7. juli 2008 kl. 12:0030
Artiklen er ældre end 30 dage

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.

Artiklen fortsætter efter annoncen

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!

30 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
2
7. juli 2008 kl. 12:55

Hvis google's cache også skulle være blevet overskrevet med religiøst vrøvl, ville http://www.archive.org/ sandsynligvis have kunne hjælpe dig, idet de gemmer adskillige snapshots.

3
7. juli 2008 kl. 12:56

Fallesen er hurtigere på aftrækkeren... :-)

4
7. juli 2008 kl. 13:11

Meget af usikkerheden ligger vel i det aktive indhold af sådan en blog. Det er jo som sådan ikke Apache som bliver hacket. Kan man ikke simpelthen skrivebeskytte indholdet?

5
7. juli 2008 kl. 13:49

Jo det burde man da - ved kunne at give db konto'en til X app READ adgang - så skal der ihvertfald være en flaw i db serverens user control for at det går galt.

6
7. juli 2008 kl. 17:25

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.

26
8. juli 2008 kl. 10:47

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å :)

7
7. juli 2008 kl. 17:30

Jeg kan se at hele 2006 ser ud til at være i arkiverne, men serveren melder fejl når jeg tilgår den ... FAQ'en siger serveren er nede og kommer op igen indenfor et par uger :-s. Vi ser.

12
7. juli 2008 kl. 21:11

Jep og nu har jeg reddet stumperne frem til november 2006, så det er næsten det hele der er blevet fundet. Fantastisk :-)

8
7. juli 2008 kl. 19:05

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.

9
7. juli 2008 kl. 20:30

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.apdv.embed.doc/doc/c0005785.htm 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?

16
7. juli 2008 kl. 22:53

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.

18
7. juli 2008 kl. 23:56

@ 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

Det er direkte forkert! Har du overhovedet sat dig ind i, hvad det er? Overskriften til standarden: "XQuery 1.0: An XML Query Language" -> http://www.w3.org/TR/xquery/

11
7. juli 2008 kl. 20:40

Bortset herfra: Jacob, har du et godt forslag til et <em>generelt</em> 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å.

22
8. juli 2008 kl. 08:51

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.

27
8. juli 2008 kl. 10:54

Med andre ord: XQuery er endnu ikke særlig interessant.

Når den engang bliver det: Hvad er det omkring XQuery som gør den mindre usikker end SQL, når vi taler om queries baseret på eksternt tilførte parametre?

28
8. juli 2008 kl. 11:20

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

24
8. juli 2008 kl. 10:04

Qizx implementerer også candidate recommendation på update: http://www.xmlmind.com/qizx/changes.html. Om det så er værd at lave sin helt egen blog i xquery og introducere helt nye sikkerhedshuller fremfor at benytte wordpress, hvor huller bliver lappet af et stort community, er så en anden sag.

25
8. juli 2008 kl. 10:28

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.

19
8. juli 2008 kl. 01:34

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.

20
8. juli 2008 kl. 07:57

@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 <script> ewller <iframe> tags ? Og til sidst, hvilken version af mySQL kører/kørte du på ?

29
8. juli 2008 kl. 11:23

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 <script> 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.

30
8. juli 2008 kl. 13:24

Jeg har lige checket med "select version()" på min MySQL instans og den rapporterer "4.1.21-log", ikke "3.23.56".

21
8. juli 2008 kl. 08:00

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

13
7. juli 2008 kl. 21:31

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

17
7. juli 2008 kl. 23:00

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.

14
7. juli 2008 kl. 22:10

XML filer er vist ikke et reelt alternativ til RDMS

Hvorfor ikke? Det kommer da helt an på mængden af data.

15
7. juli 2008 kl. 22:29

Alternativt til XML filer kunne man jo benytte noget så eksotisk som en NXDB (Native XML Database). En gratis version kan findes her: http://www.xmlmind.com/qizx/free_engine.htmlDen har dog en begrænsning på 1 gigabyte, hvilket vel er nok til de fleste blogs.