ADVARSEL: Alvorligt sikkerhedshul i Google Website Optimizer (GWO)!
Google har opdaget et alvorligt sikkerhedshul i Google Website Optimizer (også kaldet GWO) og er begyndt at sende emails ud til brugerne.
Hvis du har opsat tests med Google Website Optimizer før d. 3. december bør du enten starte forfra (surt show), eller på andre måder sikre dig at sikkerhedshullet ikke misbruges.
Min co-host på Strikepoint, David Naylor, modtog advarslen fra Google i dag og har skrevet om den på hans blog.
Det lyder som et alvorligt problem og det store spørgsmål er så hvor lang tid dette hul har eksisteret og været kent af hackere. Det vides ikke …
Hvis du opsætter nye tests skulle sikkerhedshullet, ifølge Google være lukket. Men hvis du har tests som er opsat før d. 3. december, så er du i fare for at sikkerhedshullet udnyttes.
Så det sikreste er, at stoppe alle Google Website Optimizer tests der er opsat før 3. december. Men det er naturligvis skide surt, hvis det er en test der har kørt længe for at samle nok data. Spørgsmålet er, om du tør løbe risikoen ved at lade dine gamle tests køre videre nu …
UPDATE
Jeg har nu også modtaget emailen med advarslen fra Google. I betragtning af hvor alvorligt det er, synes jeg måske godt de kunne have sendt disse advarsler ud lidt hurtigere … Nedenfor kan du se den fulde email, hvis du ikke har fået den selv:
——————————–
Kære bruger af Værktøj til webstedsoptimering
Vi skriver for at informere dig om et muligt sikkerhedsproblem i Værktøj til webstedsoptimering. Ved at udnytte en sårbarhed i kontrolscriptet til Værktøj til webstedsoptimering kan en angriber måske køre en ondsindet kode på dit websted ved hjælp af et XSS-angreb (Cross-Site Scripting). Dette angreb kan kun lade sig gøre, hvis et websted eller en browser allerede er blevet bragt i fare ved et separat angreb. Selvom den umiddelbare risiko for at blive udsat for dette angreb er lav, anbefaler vi, at du tager skridt til at beskytte dit websted.
Vi har rettet fejlen, og alle nye eksperimenter er derfor ikke i fare. Men de eksperimenter, du kører i øjeblikket, skal opdateres for at rette fejlen på dit websted. Hvis du derudover har scripts fra Værktøj til webstedsoptimering fra eksperimenter, der er stoppet eller sat på pause, fra før den 3. december 2010, skal du også fjerne eller opdatere denne kode.
Der er to metoder til at opdatere din kode. Du kan enten standse de nuværende eksperimenter, fjerne de gamle scripts og oprette et nyt eksperiment, eller du kan opdatere koden direkte på dit websted. Vi anbefaler stærkt, at du opretter et nyt eksperiment, da det er den enkleste metode.
Sådan opretter du et nyt eksperiment
- Stop alle eksperimenter i Værktøj til webstedsoptimering, der kører i øjeblikket
- Fjern alle scripts til Værktøj til webstedsoptimering fra dit websted
- Opret et nyt eksperiment, sådan som du plejer. Nye eksperimenter er ikke sårbare.
Direkte opdatering af kontrolscript til Værktøj til webstedsoptimering
- Find kontrolscriptet på dit websted. Det ser sådan her ud:
Kontrolscript til A/B-test
Kontrolscript til flerdimensional test
- Find følgende i kontrolscriptet:
return c.substring(... - Rediger den følgende linje som vist her:
FØR:return c.substring(i+n.length+1,j<0?c.length:j)
RETTET:return escape(c.substring(i+n.length+1,j<0?c.length:j))
Husk at inkludere den sidste, afsluttende parentes “)”
Rettet kontrolscript til A/B-test
Rettet kontrolscript til flerdimensional test
Bemærk, at linjen k=XXXXXXXXX i ovenstående eksempler på kontrolscripts er en pladsholder.
Dit eksperiment vil fortsætte som normalt, når du har foretaget denne opdatering. Der er ingen grund til at sætte eksperimentet på pause eller genstarte det.
Vi har i høj grad fokus på at sørge for, at Værktøj til webstedsoptimering er sikkert, og vi beklager dybt, at dette problem er opstået. Vi vil fortsat arbejde hårdt på at forhindre fremtidige sårbarheder i systemet.
Med venlig hilsen
Trevor
Google Værktøj til webstedsoptimering-teamet
Kim Biesbjerg skriver
Så galt er det nu ikke.
Google skriver i en mail hvordan der lukkes for hullet, uden at man skal stoppe sit ekseriment.
Det handler bare om, at opdatere javascript-koden man har lagt ind på sin side, da det er deri fejlen ligger.
Fra Googles email:
“There are two ways to update your code. You can either stop current experiments, remove the old scripts, and create a new experiment, or you can update the code on your site directly. We strongly recommend creating a new experiment as it is the simpler method.”
Mikkel deMib Svendsen skriver
Jeg synes nu det er temmelig galt. Som Google selv skriver “We strongly recommend creating a new experiment …” Det giver jeg dem ret i.
Problemet er så, at mange website ejere på hostede platforms ikke har mulighed for at rette i disse koder. Så må man bare håbe på at deres leverandører får det gjort hurtigt.
René Madsen skriver
Ja, der er tit mange åbninger til forskellige webservere og igennem forskellige utætte script.
I dette tilfælde med Google website optimizer ser ud til at kodningen i den oprindelige version behandler tekststrenge som karakterer og ikke som data, ved at indsætte escape foran i tekststrengen opfattes det som data, og forhindrer derved Cross-site scripting.
Mikkel deMib Svendsen skriver
Ja, det er en helt klassisk fejl og derfor særlig pinligt, at Google ikke har opdaget det før nu.
Det understreger blot, at man ikke skal stole på nogen som helst trediepart når man smider scripts på sit site. Skal man være sikker må man selv have sikerhedseksperter til at teste det hele. Ikke engang Google kan tilsyneladende levere sikre scripts. trist, men sandt.
René Madsen skriver
Fordi det er Google, der står bag er ikke altid ensbetydende med de har fuldstændigt tjek på programmering og opsætninger etc.
Jeg har siden engang i foråret, hvor jeg beskrev Google´s fejlagtige serveropsætning på deres danske webserver, set at de ikke helt er så professionelle som man går rundt og tror.
Det er muligt at indeksere et hvilket som helst domænenavn på google.dk, og trække indhold ud på dette domænenavn samt indeksere det på deres egen søgemaskine med deres eget indhold.
Jeg kontaktede dem og beskrev problemet, de takkede efterfølgende både på mail og telefonisk, men her 6 måneder efter er deres server stadig fyldt med fejl, det er oveni købet blevet værre.
Det virker tungt i systemet hos Google, det ville tage mig under fem minutter at lukke sikkerhedshullet, hvis de sendte en terminaladgang.
Mikkel deMib Svendsen skriver
Har du offentliggjort de omtalte server-fejl? Ellers gad jeg godt høre lidt flere detaljer om, hvad de går ud på. Send evt. til mig på mikkel@demib.com 🙂
René Madsen skriver
Hej Mikkel, jeg har skrevet om det første gang i marts og i sidste uge.
http://blog.onlinemarketing.dk/google-dk-og-deres-serveropsætning.html
http://blog.onlinemarketing.dk/google-dk-gaet-ned.html
Disse domæner tilgår Google server med en kodning 200, hvilket giver mulighed for indeksering på andet navn.
Jesper skriver
Ok jeg er nu blevet ramt af angrebet på http://www.sundhedslex.dk/
Er der nogen der hvad man gør?`
Vh. Jesper
Mikkel deMib Svendsen skriver
Ja, du skal have fat i en programmør, som har styr på det med sikkerhed og som kan gå ind og kigge nærmere på dit site.
Der er ingen standard-løsninger på den slags problemer.
I første omgang skal du have fjernet den skadelige kode der er lagt ind. Herefter skal du have beskyttet dig mod at det kan ske igen. begge dele kan en kvalificeret udvikler hjælpe dig med.
Jesper skriver
Hej Mikkel,
Tak for svar. Har fulgt dit råd og løst problemet 🙂
/JG
Morten skriver
@Jesper
Hvordan opdagede du, at du var blevet ramt? Og hvilken form for angreb var du udsat for?
Kunne være lidt interessant at høre, så vi andre ved, hvad vi skal holde øje med fremadrettet…
Mig skriver
Jeg er blevet hacket – ikke via dette eksempel – men vil høre om der er nogen som kender nogen – der er en haj til sikkerhed og wordpressblogs? Hvordan kan man sikre den bedre – og kan man finde nogle beviser på dem der hackede mig? (jeg er næsten sikker på hvem der har gjort det, men kan jo ikke bevise noget..) Takker 🙂