mboost-dp1
Sikkerhedshul hos dansk Internet service udbyder
Tidligere i dag opdagede jeg hul nummer to i deres system. Der er tale om et hul af samme type som det første, blot et andet sted i systemet.
Det nye hul er lidt nemmere at udnytte og giver langt mere adgang til systemet end det første. Jeg går ud fra at virksomheden allerede er klar over at problemet er mere alvorligt end først antaget. De burde i hvert fald være klare over det, da jeg opfordrede dem til at undersøge om de havde tilsvarende huller andre steder i deres system.
Alle de juridiske råd her i tråden vil jeg undlade at lytte på. Jeg har allerede spurgt min advokat til råds om den juridiske side. Derfor har jeg besluttet mig for at da jeg har orienteret dem om hullet og givet dem tid til at arbejde på det, og da jeg på nuværende tidspunkt kun har tænkt mig at offentliggøre råd til hvilke forholdsregler brugerne kan tage og ikke fortælle nærmere om hvordan man kan misbruge systemet, kan jeg føle mig ret sikker på at være på den rette side af loven.
Her er en SHA1 hash af exploitkode til det andet hul jeg fandt f3c08613c3ab42486b518a9421752c8b967fb08e. Og her er en SHA1 hash af de forholdsregler jeg har tænkt mig at offentliggøre på mandag 7c5fcf7dc777c638a3f43ba7bed7c5c67ebf7924.
Før i tiden skrev jeg indlæg på Computerworlds debatforum. De sendte emails når der var kommet svar på ens indlæg. Det blev sendt som HTML kode, som nogle email klienter kunne fortolke, men ikke alle. Jeg måtte derfor selv markere URLen og kopiere den over i min browser. Engang kom jeg til at markere lidt for langt og fik " tegnet efter URLen med, og fandt derved et SQL injektion hul.
Det nye hul er lidt nemmere at udnytte og giver langt mere adgang til systemet end det første. Jeg går ud fra at virksomheden allerede er klar over at problemet er mere alvorligt end først antaget. De burde i hvert fald være klare over det, da jeg opfordrede dem til at undersøge om de havde tilsvarende huller andre steder i deres system.
Alle de juridiske råd her i tråden vil jeg undlade at lytte på. Jeg har allerede spurgt min advokat til råds om den juridiske side. Derfor har jeg besluttet mig for at da jeg har orienteret dem om hullet og givet dem tid til at arbejde på det, og da jeg på nuværende tidspunkt kun har tænkt mig at offentliggøre råd til hvilke forholdsregler brugerne kan tage og ikke fortælle nærmere om hvordan man kan misbruge systemet, kan jeg føle mig ret sikker på at være på den rette side af loven.
Her er en SHA1 hash af exploitkode til det andet hul jeg fandt f3c08613c3ab42486b518a9421752c8b967fb08e. Og her er en SHA1 hash af de forholdsregler jeg har tænkt mig at offentliggøre på mandag 7c5fcf7dc777c638a3f43ba7bed7c5c67ebf7924.
Jeg har fundet flere huller på den måde eller ting der lå tæt op ad det.Magten (79) skrev:Jeg skrev den direkte url men ramte et forkert tal, og fandt derfor hullet.
Før i tiden skrev jeg indlæg på Computerworlds debatforum. De sendte emails når der var kommet svar på ens indlæg. Det blev sendt som HTML kode, som nogle email klienter kunne fortolke, men ikke alle. Jeg måtte derfor selv markere URLen og kopiere den over i min browser. Engang kom jeg til at markere lidt for langt og fik " tegnet efter URLen med, og fandt derved et SQL injektion hul.
Ronson (103) skrev:Jeg elsker sikkerhed!
http://www.snackskompagniet.dk/crispo.htm
http://www.solvanggruppe.dk/
Er jeg dum hvis jeg ikke kan se pointen? :S
Jeg kan se det morsomme i den første. Men hvad med den anden?Spiderboy (105) skrev:Tjek kilden.
Tænker du på http://scifi.pages.at/hackits (som desværre ikke mere er der)?Alrekr (106) skrev:Minder mig om udfordringerne på en hack-hjemmeside
kasperd (107) skrev:Tænker du på http://scifi.pages.at/hackits (som desværre ikke mere er der)?Alrekr (106) skrev:Minder mig om udfordringerne på en hack-hjemmeside
Nej. Den sluttede på .nl, så vidt jeg husker.
Edit: Jeg kan huske at den et par gange stillede videre til Disney hvis man ikke knækkede 'koden'.
kasperd (107) skrev:Jeg kan se det morsomme i den første. Men hvad med den anden?
Hos mig popper der en dialogboks op (i Firefox) med passwordet præudfyldt. Jeg har dog ikke forsøgt at logge ind.
Alrekr (110) skrev:Der sker ikke noget har jeg hørt. Desuden står der, meget fint, at logind ikke virker - jeg går ud fra at det er rigtigt.
Dunno. Jeg formoder bare at det er det, Ronson hentydede til.
Jeg kiggede først siden på min telefon og troede at det var en http authentication. Efterfølgende kiggede jeg sourcen på forsiden i en mere normal browser uden at klikke på linket.Zhadow (109) skrev:Hos mig popper der en dialogboks op (i Firefox) med passwordet præudfyldt.
At du også så det forudfyldte password i Firefox fik det til at gå op for mig at det ikke var en http auhtentication, da jeg har set hvordan de ser ud i Firefox.
Jeg kiggede så på sourcen til den pågældende side og kunne se at det er ikke korrekt at den forudfylder requesten med password. Den forudfylder requesten med tre stjerner. Den request der kommer op er ikke en password box, den erstatter ikke de tegn der indtastes med stjerner, den viser faktisk passwordet efterhånden som det tastes. De tre stjerner du ser i boxen er virkeligt fordi den forudfylder med tre stjerner. Passwordet er dog ikke tre stjerner.
Sourcen er sjov. Man ser både:
- Hvordan ophavsmanden har ladet være med at skrive passwordet i klartekst men i stedet skrevet et stykke kode der skal afvikles for at generere passwordet.
- Hvor langt passwordet er.
- Hvordan der promptes for password.
- Hvilken side der sendes videre til ved rigtigt password.
kasperd (112) skrev:Jeg kiggede først siden på min telefon og troede at det var en http authentication. Efterfølgende kiggede jeg sourcen på forsiden i en mere normal browser uden at klikke på linket.
At du også så det forudfyldte password i Firefox fik det til at gå op for mig at det ikke var en http auhtentication, da jeg har set hvordan de ser ud i Firefox.
Jeg kiggede så på sourcen til den pågældende side og kunne se at det er ikke korrekt at den forudfylder requesten med password. Den forudfylder requesten med tre stjerner. Den request der kommer op er ikke en password box, den erstatter ikke de tegn der indtastes med stjerner, den viser faktisk passwordet efterhånden som det tastes. De tre stjerner du ser i boxen er virkeligt fordi den forudfylder med tre stjerner. Passwordet er dog ikke tre stjerner.
http://troll.me/images/jackie-chan/jackie-chan.jpg
Nu er der begyndt at ske fremskridt. Således er de alvorligste huller blevet lukket. Der er stadig et par småting rundt omkring som ikke er helt perfekt. De sagde dog at de stadigvæk arbejder på det.
Men som det ser ud nu er de problemer jeg kan få øje på nu blot nogen der kan kategoriseres som irriterende og ikke decideret kompromitterende.
Om de ændringer der blev rullet ud i dag har noget at gøre med den email jeg sendte dem i går kan jeg ikke sige med sikkerhed.
Dermed er de forholdsregler jeg havde tænkt mig at publicere på mandag ikke længere relevante. Og nu er det nok egentlig rimeligt at de får lov til at bruge lidt tid på at finpudse detaljerne.
Men som det ser ud nu er de problemer jeg kan få øje på nu blot nogen der kan kategoriseres som irriterende og ikke decideret kompromitterende.
Om de ændringer der blev rullet ud i dag har noget at gøre med den email jeg sendte dem i går kan jeg ikke sige med sikkerhed.
Dermed er de forholdsregler jeg havde tænkt mig at publicere på mandag ikke længere relevante. Og nu er det nok egentlig rimeligt at de får lov til at bruge lidt tid på at finpudse detaljerne.
#119
Jeg venter også med at læse Xbox sæson 3, til den er afsluttet.
Jeg venter også med at læse Xbox sæson 3, til den er afsluttet.
Jeg kiggede lige gennem deres sider og kiggede på de $Id: tags som versionsstyringen har sat i deres websider. Jeg ville vide om de stadig arbejdede på det. Den ældste dato jeg fandt var 2002-08-01 og den nyeste var 2011-09-29.
Den sidste mail udveksling med dem fandt sted den 23. Og der var også en del $Id: tags fra den dag.
Det vil sige enten har de rettet de værste fejl og derefter ikke prioriteret det særlig højt at gå alle siderne igennem for at se om de havde overset noget.
Eller også tror de at det er færdige, men har overset en enkelt mindre vigtig detalje og har samtidig glemt at sende mig en email for at fortælle at de er færdige.
Jeg må hellere sende dem en email og spørge om de stadig arbejder på det, eller om det ene link er en forglemmelse.
Den sidste mail udveksling med dem fandt sted den 23. Og der var også en del $Id: tags fra den dag.
Det vil sige enten har de rettet de værste fejl og derefter ikke prioriteret det særlig højt at gå alle siderne igennem for at se om de havde overset noget.
Eller også tror de at det er færdige, men har overset en enkelt mindre vigtig detalje og har samtidig glemt at sende mig en email for at fortælle at de er færdige.
Jeg må hellere sende dem en email og spørge om de stadig arbejder på det, eller om det ene link er en forglemmelse.
De fejl jeg omtalte lå i et webbaseret værktøj til at opdatere DNS zoner hos en dansk udbyder af DNS hosting. Denne udbyder hoster også andet end DNS, men jeg har ikke personlige erfaringer med deres andre services.
Jeg har netop set denne artikel som ser på nogle eksempler af misbrug af DNS https://isc.sans.edu/diary/What+s+In+A+Name+/11770
Artiklen nævner ingen danske domæner. Hvis de spammere som artiklen omhandler havde kendt til et af de sikkerhedshuller jeg fandt, så ville der nok have været danske domæner på listen i den artikel.
Det skal lige siges at selvom der er tale om en dansk DNS hosting udbyder, så er deres service ikke begrænset til .dk domæner. De tilbyder registrering og hosting af domæner under mange andre TLDer.
Det første hul jeg fandt kunne misbruges til at oprette nye DNS records. Det kunne ikke umiddelbart bruges til at ændre eller slette eksisterende records.
Det andet hul jeg fandt kunne misbruges til at opnå fuld kontrol over en zone. Fuld kontrol betyder i den her sammenhæng at man havde mulighed for at aflæse den retmæssige ejers login og password. Der var også mulighed for at oprette et separat login og password med adgang til samme zone. Og hvis man ville kunne man lukke den retmæssige ejer ude ved at slette/ændre den retmæssige ejers password.
Ovennævnte huller er lukket. Der er en enkelt detalje tilbage, nemlig at mens man er logget ind og er ved at ændre sin zone kan et angreb potentielt betyde at man mister alle de ændringer man ikke har gemt endnu.
Hvis hullet allerede er blevet udnyttet til at opnå kontrol over zoner kan uvedkommende altså stadig have kontrol selvom hullet nu er lukket. Det man kan gøre som bruger i den situation er at logge ind og ændre alle sine passwords.
Jeg har netop set denne artikel som ser på nogle eksempler af misbrug af DNS https://isc.sans.edu/diary/What+s+In+A+Name+/11770
Artiklen nævner ingen danske domæner. Hvis de spammere som artiklen omhandler havde kendt til et af de sikkerhedshuller jeg fandt, så ville der nok have været danske domæner på listen i den artikel.
Det skal lige siges at selvom der er tale om en dansk DNS hosting udbyder, så er deres service ikke begrænset til .dk domæner. De tilbyder registrering og hosting af domæner under mange andre TLDer.
Det første hul jeg fandt kunne misbruges til at oprette nye DNS records. Det kunne ikke umiddelbart bruges til at ændre eller slette eksisterende records.
Det andet hul jeg fandt kunne misbruges til at opnå fuld kontrol over en zone. Fuld kontrol betyder i den her sammenhæng at man havde mulighed for at aflæse den retmæssige ejers login og password. Der var også mulighed for at oprette et separat login og password med adgang til samme zone. Og hvis man ville kunne man lukke den retmæssige ejer ude ved at slette/ændre den retmæssige ejers password.
Ovennævnte huller er lukket. Der er en enkelt detalje tilbage, nemlig at mens man er logget ind og er ved at ændre sin zone kan et angreb potentielt betyde at man mister alle de ændringer man ikke har gemt endnu.
Hvis hullet allerede er blevet udnyttet til at opnå kontrol over zoner kan uvedkommende altså stadig have kontrol selvom hullet nu er lukket. Det man kan gøre som bruger i den situation er at logge ind og ændre alle sine passwords.
kasperd (123) skrev:De fejl jeg omtalte lå i et webbaseret værktøj til at opdatere DNS zoner hos en dansk udbyder af DNS hosting. Denne udbyder hoster også andet end DNS, men jeg har ikke personlige erfaringer med deres andre services.
Jeg har netop set denne artikel som ser på nogle eksempler af misbrug af DNS https://isc.sans.edu/diary/What+s+In+A+Name+/11770
Artiklen nævner ingen danske domæner. Hvis de spammere som artiklen omhandler havde kendt til et af de sikkerhedshuller jeg fandt, så ville der nok have været danske domæner på listen i den artikel.
Det skal lige siges at selvom der er tale om en dansk DNS hosting udbyder, så er deres service ikke begrænset til .dk domæner. De tilbyder registrering og hosting af domæner under mange andre TLDer.
Det første hul jeg fandt kunne misbruges til at oprette nye DNS records. Det kunne ikke umiddelbart bruges til at ændre eller slette eksisterende records.
Det andet hul jeg fandt kunne misbruges til at opnå fuld kontrol over en zone. Fuld kontrol betyder i den her sammenhæng at man havde mulighed for at aflæse den retmæssige ejers login og password. Der var også mulighed for at oprette et separat login og password med adgang til samme zone. Og hvis man ville kunne man lukke den retmæssige ejer ude ved at slette/ændre den retmæssige ejers password.
Ovennævnte huller er lukket. Der er en enkelt detalje tilbage, nemlig at mens man er logget ind og er ved at ændre sin zone kan et angreb potentielt betyde at man mister alle de ændringer man ikke har gemt endnu.
Hvis hullet allerede er blevet udnyttet til at opnå kontrol over zoner kan uvedkommende altså stadig have kontrol selvom hullet nu er lukket. Det man kan gøre som bruger i den situation er at logge ind og ændre alle sine passwords.
Hvis de ikke har tænkt sig at svare tilbage på din henvendelse, kunne de fandme godt sende en præmie som tak.
snesman (124) skrev:kasperd (123) skrev:De fejl jeg omtalte lå i et webbaseret værktøj til at opdatere DNS zoner hos en dansk udbyder af DNS hosting. Denne udbyder hoster også andet end DNS, men jeg har ikke personlige erfaringer med deres andre services.
Jeg har netop set denne artikel som ser på nogle eksempler af misbrug af DNS https://isc.sans.edu/diary/What+s+In+A+Name+/11770
Artiklen nævner ingen danske domæner. Hvis de spammere som artiklen omhandler havde kendt til et af de sikkerhedshuller jeg fandt, så ville der nok have været danske domæner på listen i den artikel.
Det skal lige siges at selvom der er tale om en dansk DNS hosting udbyder, så er deres service ikke begrænset til .dk domæner. De tilbyder registrering og hosting af domæner under mange andre TLDer.
Det første hul jeg fandt kunne misbruges til at oprette nye DNS records. Det kunne ikke umiddelbart bruges til at ændre eller slette eksisterende records.
Det andet hul jeg fandt kunne misbruges til at opnå fuld kontrol over en zone. Fuld kontrol betyder i den her sammenhæng at man havde mulighed for at aflæse den retmæssige ejers login og password. Der var også mulighed for at oprette et separat login og password med adgang til samme zone. Og hvis man ville kunne man lukke den retmæssige ejer ude ved at slette/ændre den retmæssige ejers password.
Ovennævnte huller er lukket. Der er en enkelt detalje tilbage, nemlig at mens man er logget ind og er ved at ændre sin zone kan et angreb potentielt betyde at man mister alle de ændringer man ikke har gemt endnu.
Hvis hullet allerede er blevet udnyttet til at opnå kontrol over zoner kan uvedkommende altså stadig have kontrol selvom hullet nu er lukket. Det man kan gøre som bruger i den situation er at logge ind og ændre alle sine passwords.
Hvis de ikke har tænkt sig at svare tilbage på din henvendelse, kunne de fandme godt sende en præmie som tak.
Eller løn.
Status er på nuværende tidspunkt som følger:
- Jeg har udbyderens ord for at de kritiske sikkerhedshuller er lukket.
- De sikkerhedshuller, jeg havde kendskab til kunne misbruges til at opnå kontrol over andres login eller zoner, er lukket.
- Det er to måneder siden de blev gjort opmærksom på det første hul.
- Jeg har ingen mulighed for at vide om hullet er blevet udnyttet af andre som har opdaget det uafhængigt af mig. Jeg ved ikke om udbyderen har logfiler til at kunne undersøge dette.
- Hvis man som kunde hos denne udbyder er bekymret for om man er blevet angrebet er det bedste man kan gøre at logge ind på udbyderens system og ændre sine passwords. Hvis man har været så uforsigtig at anvende samme passwords andre steder skal de også ændres der.
Baseret på ovenstående tænker jeg at jeg måske bør fortælle hvilken udbyder der er tale om.
- Jeg har udbyderens ord for at de kritiske sikkerhedshuller er lukket.
- De sikkerhedshuller, jeg havde kendskab til kunne misbruges til at opnå kontrol over andres login eller zoner, er lukket.
- Det er to måneder siden de blev gjort opmærksom på det første hul.
- Jeg har ingen mulighed for at vide om hullet er blevet udnyttet af andre som har opdaget det uafhængigt af mig. Jeg ved ikke om udbyderen har logfiler til at kunne undersøge dette.
- Hvis man som kunde hos denne udbyder er bekymret for om man er blevet angrebet er det bedste man kan gøre at logge ind på udbyderens system og ændre sine passwords. Hvis man har været så uforsigtig at anvende samme passwords andre steder skal de også ændres der.
Baseret på ovenstående tænker jeg at jeg måske bør fortælle hvilken udbyder der er tale om.
apkat (128) skrev:fjols (127) skrev:Det synes jeg da du bør.
Hvis hullerne er lukkede så skader det vel ingen. Desuden virker det til at de har handlet professionelt i sagen.
Tjae, de har endnu ikke sendt ham et års forbrug af rødvin?
Jeg kan også.
Med det navn de har valgt til deres virksomhed, så bør de håndtere sådan en sag professionelt.fjols (127) skrev:Desuden virker det til at de har handlet professionelt i sagen.
Med mit forbrug af rødvin ville det være for billigt sluppet.Daniel-Dane (131) skrev:et års forbrug af rødvin?
Det sårbare system var https://selfcare.pil.dk/
Der er et demologin man kan bruge for at se hvordan DNS opsætningen fungerer. Demologin giver ikke adgang til brugeradministrationen. Men der er alligevel ikke voldsomt meget funktionalitet at se derinde.
Hvis man kigger på sourcen til websiderne kan man selv verificere de opdateringsdatoer jeg nævnte tidligere i tråden.
Jeg vil ikke på nuværende tidspunkt fortælle i detaljer omkring sikkerhedshullets karrakter, det kommer sikkert på et senere tidspunkt.
På http://pil.dk/dk/pildk/kunder.html kan man se en liste over nogen af deres kunder, men det fremgår ikke hvilke af disse kunder der anvender selfcare systemet.
Jeg har ingen grund til at tro at hullet er blevet udnyttet, men jeg formoder at hullet har eksisteret i flere år. Hvis man har domæne eller mail hostet på dette system og er bekymret for om man er blevet udsat for misbrug, vil jeg opfordre til at man logger ind og går ind i brugeropsætningen og ændrer alle passwords. Dernæst kan man gennemgå de andre funktioner og undersøge om opsætningerne er som de bør være.
Da man ikke med demobrugeren kan se hvordan deres brugeropsætning fungerer vil jeg kort skitsere den. Man kan oprette, modificere og slette brugere med adgang til sine egne domæner. Opsætningen af en bruger har tekstfelter til email og password. Derudover er der tre checkbokse til at vælge hvilke områder denne bruger har adgang til, de tre områder er brugeropsætnigen, mailopsætningen og DNS zoneopsætningen.
Omstændighederne omkring dette hul har fået mig til at oprette to separate logins til mit eget brug. Det ene login har kun adgang til brugeradministrationen, det andet login har kun adgang til DNS administrationen.
Det er DNS administrationen jeg oftest anvender, og skulle min adgang til DNS administrationen blive kompromitteret kan jeg efterfølgende anvende brugeradministrationen til at ændre passwordet. Denne opdeling giver så vidt jeg kan vurdere bedre sikkerhed end ved at anvende et login til det hele, også i tilfælde hvor begge logins anvendes af samme person.
Her er en anden nyhed som er en lille smule relateret. http://newz.dk/venstre-folk-hacket
Hvis det hul jeg kendte havde været kendt af flere, så kunne sådan et angreb i stedet for at gå ud over enkeltstående medlemmer af Venstre være gået ud over venstre.dk. Jeg formoder at det hul jeg kendte kunne være udnyttet til at deface venstre.dk.
Og jeg opdagede hullet og gjorde udbyderen opmærksom på det før valgkampen startede. Både jeg og udbyderen var klar over at hullet eksisterede gennem hele valgkampen.
At venstre.dk var blandt de udsatte sites opdagede jeg dog først efter valgkampen. Det var først en måned efter jeg opdagede hullet at jeg begyndte at undersøge hvilke sites der var berørt og tænkte at venstre.dk var et markant nok site til at det sikkert kunne skabe nogle overskrifter, hvis det kom frem at venstre.dk stod frit åbent for overtagelse gennem hele valgkampen.
Dog lykkedes det at få hullet lukket uden at det var nødvendigt at gå til pressen og fortælle hvordan man kunne deface venstre.dk.
Hvis det hul jeg kendte havde været kendt af flere, så kunne sådan et angreb i stedet for at gå ud over enkeltstående medlemmer af Venstre være gået ud over venstre.dk. Jeg formoder at det hul jeg kendte kunne være udnyttet til at deface venstre.dk.
Og jeg opdagede hullet og gjorde udbyderen opmærksom på det før valgkampen startede. Både jeg og udbyderen var klar over at hullet eksisterede gennem hele valgkampen.
At venstre.dk var blandt de udsatte sites opdagede jeg dog først efter valgkampen. Det var først en måned efter jeg opdagede hullet at jeg begyndte at undersøge hvilke sites der var berørt og tænkte at venstre.dk var et markant nok site til at det sikkert kunne skabe nogle overskrifter, hvis det kom frem at venstre.dk stod frit åbent for overtagelse gennem hele valgkampen.
Dog lykkedes det at få hullet lukket uden at det var nødvendigt at gå til pressen og fortælle hvordan man kunne deface venstre.dk.
Jeg synes lige jeg ville offentliggøre indholdet af de forholdsregler jeg ville have offentliggjort for længe siden, hvis ikke der var sket noget med hensyn til udbedring af hullet. Jeg har også linket til en tekstfil i tilfælde nogen måtte ønske at sammenligne med #101
Hvis man tilgår sites der behandler kritiske data er det værd at bruge forholdsregler som ovenstående, også selvom man ikke har kendskab til huller. Den lille smule ekstra besvær er en acceptabel pris for at være på den sikre side.
F.eks. åbner jeg personligt aldrig newz.dk og min netbank i samme browser.
Ovenstående forholdsregler er selvfølgelig ikke så relevante for selfcare.pil.dk mere, da de kritiske huller jeg nævnte tidligere er lukket. Men forholdsreglerne er alligevel værd at kende til da samme forholdsregler kan beskytte såfremt man skulle anvende andre websites med lignende huller.http://kasperd.net/7c5fcf7dc777c638a3f43ba7bed7c5c67ebf7924.txt skrev:Der er fundet et sikkerhedshul i selfcare.pil.dk
Indtil hullet er blevet lukket kan man som bruger tage følgende forholdsregler for at undgå misbrug.
Når du logger på selfcare.pil.dk så gør det på følgende måde:
1. Afslut browseren
2. Start browseren
3. Åbn https://selfcare.pil.dk/login.pl og ingen andre sider i samme browser session.
4. Log in
5. Foretag de ønskede ændringer
6. Log ud
7. Afslut browseren igen
Åbn under ingen omstændigheder andre websites samtidigt med at du er logget på selfcare.pil.dk. Derudover er det en god idé at åbne brugeradministrationen og skifte passwords på alle brugere.
Hvis man tilgår sites der behandler kritiske data er det værd at bruge forholdsregler som ovenstående, også selvom man ikke har kendskab til huller. Den lille smule ekstra besvær er en acceptabel pris for at være på den sikre side.
F.eks. åbner jeg personligt aldrig newz.dk og min netbank i samme browser.
kasperd (144) skrev:Nej, du skal forære den til en fattig studerende med evnerne til at installere et nyt operativsystem ovenpå det du havde på den.apkat (143) skrev:Skal jeg også smide computeren ud bagefter?
Jeg tager gerne imod :D
For at se et sted hvor koden er blevet ændret kan man først logge på selfcare.pil.dk (demobrugeren kan også bruges til det, så alle kan være med her). Dernæst vælg "Vedligehold DNS zoner", vælg en zone, vælg "Tilføj record". Kig derefter på html sourcen.
Der er en html form med et input felt der ser således ud: <input type="hidden" name="secret" value="INUuqWkeGevw2SxTBainGlU0udlEhwTL" />
Værdien er forskellig hver gang. Dette felt blev indført 23. september. Før det var der intet uforudsigeligt i denne form, hvilket gjorde den sårbar overfor XSRF angreb. Hvis man var logget på selfcare.pil.dk og havde været inde i en zone kunne en vilkårlig webside man besøgte sende en request til selfcare.pil.dk og derved oprette en ny DNS record.
Faktisk var der heller ingen check på referer og metoden, så en GET request kunne også anvendes. Det betød at enkelt img tag var alt hvad der krævedes for at oprette en record.
Her er beskrivelsen jeg oprindeligt sendte til pil (inklusiv link til tekstfil for dem der måtte ønske at sammenligne med #1). Selve exploitkoden ser jeg ingen grund til at offentliggøre endnu.
Der er en html form med et input felt der ser således ud: <input type="hidden" name="secret" value="INUuqWkeGevw2SxTBainGlU0udlEhwTL" />
Værdien er forskellig hver gang. Dette felt blev indført 23. september. Før det var der intet uforudsigeligt i denne form, hvilket gjorde den sårbar overfor XSRF angreb. Hvis man var logget på selfcare.pil.dk og havde været inde i en zone kunne en vilkårlig webside man besøgte sende en request til selfcare.pil.dk og derved oprette en ny DNS record.
Faktisk var der heller ingen check på referer og metoden, så en GET request kunne også anvendes. Det betød at enkelt img tag var alt hvad der krævedes for at oprette en record.
Her er beskrivelsen jeg oprindeligt sendte til pil (inklusiv link til tekstfil for dem der måtte ønske at sammenligne med #1). Selve exploitkoden ser jeg ingen grund til at offentliggøre endnu.
http://kasperd.net/725d9367218768406d82abd91ba50eb3ec15e7d1.txt skrev:Jeg har fundet et sikkerhedshul i
https://selfcare.pil.dk/zones/edit_record.pl
Når man er logget ind kan et vilkårligt website man besøger
tilføje records til den sidste zone man har haft åben.
1. Log in på https://selfcare.pil.dk/
2. Gå til DNS zoner og vælg en zone.
3. Åben http://kasperd.net/~kasperd/pil-selfcare-xsrf.html
Der vil derefter findes en ny TXT record i den zone man
havde åben.
kasperd (146) skrev:Faktisk var der heller ingen check på referer og metoden, så en GET request kunne også anvendes. Det betød at enkelt img tag var alt hvad der krævedes for at oprette en record.
anses check på refer ikke som ligegyldig bullshit, er da uendelig nemt at fake? (medmindre man så laver noget unikt id i den.)
Det er nemt at fake for den der bruger browseren- ikke for en tilfældig hjemmeside....
Og det er derfor det kan bruges imod xss
Og det er derfor det kan bruges imod xss
Nej, ikke i det her tilfælde. Hvis der et referer felt kan det være en nogenlunde effektiv beskyttelse imod XSRF.apkat (147) skrev:anses check på refer ikke som ligegyldig bullshit, er da uendelig nemt at fake?
Der er dog et par problemer med det. Nogle klienter sender ikke en referer. Så hvis du bruger referer til at beskytte imod XSRF er du enten nødt til at udelukke alle klienter der ikke sender en referer, eller du reducerer sikkerheden for klienter der ikke sender referer.
Men det bliver værre endnu. For hvis en request går fra en https side til en http side, så sendes der normalt ikke en referer, selv hvis klienten ellers ville. Det vil sige et angreb kan forholdsvis nemt forhindre klienten i at sende referer. Så hvis du tillader klienter uden referer kan du også reducere sikkerheden for de klienter der sender en referer header.
Desuden kan det være det site der skal beskyttes imod XSRF har sider der kan bruges til at redirecte til siden man vil angribe. Dermed bliver referer checks sværere at gøre sikre da man ikke nødvendigvis kan stole på alt på sit eget site.
Et skjult felt med en hemmelig værdi i hver form på sitet er en mere effektiv foranstaltning. Jeg har ikke kendskab til nogen metoder man kan anvende til at gennemføre et XSRF angreb i det tilfælde.
Nu kan jeg vist godt offentliggøre den oprindelige exploitkode, om ikke andet for at man kan se hvor lidt der egentlig skulle til.
Ovenstående exploitkode er 231 bytes. Exploitet af det endnu værre hul der blev nævnt i #101 er kun 158 bytes.
Jeg har netop checket igen at denne exploitkode ikke virker. Det er ca. tre måneder siden hullet blev lukket, og exploitkoden kan forhåbentligt tjene som advarsel til andre der laver webapplikationer.http://kasperd.net/~kasperd/pil-selfcare-xsrf.html skrev:<img src="https://selfcare.pil.dk/zones/edit_record.pl?id=&record=xsrf-attack&ttl=&type=TXT&priority=&value=Pil%20selfcare%20er%20saarbar%20overfor%20XSRF%20angreb.&submit=OK"><img src="https://selfcare.pil.dk/zones/save_zone.pl">
Ovenstående exploitkode er 231 bytes. Exploitet af det endnu værre hul der blev nævnt i #101 er kun 158 bytes.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Tagwall
Gå til bund