kim tiedemann bloghoved

Hvordan jeg på to aftener “hackede” to store offentlige sites

Det kræver ikke den store indsats at finde sikkerhedshuller – også på store offentlige sites, desværre. Jeg besluttede mig for at kigge nogle større sites igennem for sikkerhedshuller og de to første jeg tog fat i, havde sikkerhedshuller som kunne udnyttes af hackere. Jeg er ikke hacker, så jeg besluttede mig for at kontakte personer hos de to sites og lade dem fikse det. Derfor vil jeg også beskrive sikkerhedshullerne mere generelt uden at afsløre hvilke sites der er tale om.

Http/https mixed mode problemer

Det første site jeg kastede mig over fungerer både på http og https. Deres tanke er (tror jeg) at når man ikke er logget ind, så browser man på http sitet, mens i det øjeblik man er logget på, så skiftes til https. Et sådant site er oplagt at undersøge, for her er der flere muligheder for en angriber.

Så jeg starter med at logge ind og se om login formular hentes over en sikker forbindelse (https). En login formular skal altid loades over https og det er vigtigt at hele siden loades over https. Hvis siden loades over http, så kan en Man-In-The-Middle ændre i serverens response og dermed ændre hvor formularens indhold sendes hen eller injecte JavaScript på login siden, der sender brugernavn og adgangskode til en anden server.

I det her tilfælde loades login formularen over https og det er ikke muligt at angribe.

Efter login kommer man tilbage til sitet, denne gang på https og oppe i hjørnet på sitet kan jeg se, at jeg er logget ind. Men hvad hvis jeg ændrer protokol i adresselinjen tilbage til http? Her burde jeg ikke længere være logget ind. Desværre har det her site et sikkerhedsproblem og jeg er stadig logget ind på sitet. Det kan kun ske på en måde: Sitets authentication cookie sendes med henover den usikre http forbindelse, hvilket betyder at cookien ikke er Secure.

Illustration: Privatfoto

Her kan man tænke: Det er jo en aktiv handling fra brugerens side at skifte protokol. Problemet er bare at det kan ske ved at brugeren tidligere har bookmarket et usikkert link eller at jeg som hacker sender en mail med et usikkert link. Hvis brugeren allerede er logget ind (fx på en anden tab i browseren) så vil cookien blive lækket over http og dermed kan hackeren få fat i authentication cookie og bruge den over mod sitet og derfor være logget ind som brugeren.

På dette site var det dog ikke svært at få brugeren tilbage på http efter login. Flere links på sitet (specielt forsiden) pegede eksplicit på http:// og dermed ville brugeren ved at bruge sitet ganske naturligt hoppe tilbage til en usikker forbindelse.

Løsningen benytter hvad man må formode er sessionscookien (JSESSIONID er et typisk navn på en Java applikationsservers sessionscookie) som authentication cookie og det er formentligt årsagen til, at den ikke er secure. Den kan ikke være Secure, når nu sitet kører på både http og https. Sessions- og authentication cookie bør ikke være den samme cookie i det her tilfælde.

Heldigvis er cookien Http only og dermed ikke tilgængelig fra JavaScript. Dette er en rigtig god ting, da sitet jo også kunne være sårbart overfor Cross site scripting (XSS).

Hvordan kommer manden i midten?

Der findes devices som fx Pineapple Wifi, som kan udgive sig for at være et vilkårligt access point og dermed få uvidende ofre til at forbinde deres computer eller mobile devices til access pointet.

Pineapple Wifi benytter sig af at wifi protokollen sender prober ud der spørger efter Access points, som allerede er kendt. Så har du engang forbundet til et hotels åbne wifi, så vil din computer fremover spørge om dette access point er tilgængeligt derude. Pineapple Wifi kigger på disse prober og ændrer SSID til at matche med forespørgslen. Herefter kan hackeren se alle netværkspakker der sendes mellem din computer og netværket. Det eneste der nu skal gøres er, at tage authentication cookie indholdet, vedhæfte den i requests over mod sitet og dermed være logget ind som den uvidende bruger.

Hvordan kan man sikre sig?

Det bedste råd er at benytte https konsekvent i stedet for at skifte. Dette gør sig specielt gældende hvis sitet primært er henvendt autoriserede brugere.

Et andet råd er at authentication cookien skal være secure og også http only. Det sikrer at den aldrig sendes over en usikker forbindelse samt at den ikke kan tilgås fra JavaScript.

Et tredje råd er at benytte Http Strict Transport Security response headeren fra serveren. Det gør at browseren herefter sikrer, at sitet kun hentes igennem en sikker forbindelse fremover (indtil tidsfristen sat i headeren udløber). Dette er dog ikke understøttet i alle browsere endnu, men det sikrer i hvertfald Chrome og Firefox brugere.

Det andet offentlige site er sårbar overfor et Cross site scripting angreb – dette indlæg må dog vente et par dage…

Kommentarer (11)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Kim Bjørn Tiedemann

Nej, jeg deltager ikke i høringen. jeg tror det bliver svært at rumme både brugervenlighed for Hr. og Fru Hansen samtidigt med at vi får den bedste sikkerhedsmæssige løsning. Det er altid et kompromis mellem bekvemmelighed og sikkerhed, og jeg er bange for at bekvemmeligheden bliver vægtet højest.

Jeg kan godt lide ideerne i WAYF, som sikrer flere IdP'er samtidigt med at de sikrer en anonym identitet overfor tjenesteudbyderne.

Finn Aarup Nielsen

Klienten kan sikre sig med "HTTPS Everywhere" fra EFF https://www.eff.org/https-everywhere. Den virker som plugin til flere browsere, herunder min Ubuntu Firefox.
Jeg har haft den installeret siden jeg blev opmærksom på Firesheep.

Der er problemer med Wikipedia. Har man konto og logget ind ryger ens sessionssmåkage (og evt login) frem og tilbage. Søger man på Google vil link til Wikipedia være ukrypterede HTTP og det vil således være ikke sjældent at man kommer via HTTP. Med HTTPS Everywhere er et GET til Wikipedia via Google HTTP-link et HTTPS GET.

Jeg har dog oplevet at "HTTPS Everywhere" kan give funktionsproblemer for websites med mixed content (muligvis gjorde det sig gældende for http://www.dtu.dk på en måde jeg ikke fuldt forstod). Det er dog muligt at slå HTTPS Everywhere fra baseret på website.

Burde HTTPS Everywhere-funktionalitet være indbygget i webbrowsere?

Thue Kristensen

Så jeg starter med at logge ind og se om login formular hentes over en sikker forbindelse (https). En login formular skal altid loades over https og det er vigtigt at hele siden loades over https. Hvis siden loades over http, så kan en Man-In-The-Middle ændre i serverens response og dermed ændre hvor formularens indhold sendes hen eller injecte JavaScript på login siden, der sender brugernavn og adgangskode til en anden server.

I det her tilfælde loades login formularen over https og det er ikke muligt at angribe.

Hvis du har MitM til at kunne læse cookies eller passwords sendt over http, så har du vel som regel også mulighed for at køre sslstrip, som dynamisk oversætter https til http. Så https uden Http Strict Transport Security eller certificate pinning er meningsløst, med mindre dine brugere er kloge nok til manuelt selv at checke for https.

Så https i sig selv er faktisk overraskende sikkerhedsmæssigt meningsløst for almindelige dødelige brugere (=stort set alle andre end mig :) ), modsat hvad du giver indtryk af.

Da Moxie Marlinspike testede sslstrip mod gmail-brugere havde han en 100% successrate: http://www.thoughtcrime.org/software/sslstrip/

Kim Bjørn Tiedemann

SSL er i den grad ikke meningsløst, men man skal være varsom hvis man kører mixed mode med både http og https. Derfor er mit råd også at lade være med det.

Hvis dit site ikke svarer på http, så har sslstrip ingen effekt andet end at producere links, som serveren ikke svarer på. Fx svarer gmail ikke længere på http forespørgsler og derudover har de sikret sitet ved at sætte Http Strict Transport Security headeren (faktisk er det kodet ind i Chrome at gmail altid skal hentes over https http://dev.chromium.org/sts).

Hvis din authentication cookie er secure, så vil den aldrig sendes over http og kan dermed aldrig læses af en Man In The Middle.

Claus Lensbøl

Fx svarer gmail ikke længere på http forespørgsler og derudover har de sikret sitet ved at sætte Http Strict Transport Security headeren (faktisk er det kodet ind i Chrome at gmail altid skal hentes over https

At sige at de ikke svarer på http er vel lidt en simplificering. De svarer ikke med en HTTP 2xx, men med en 302 moved. Det samme med mail.google.com.

telnet mail.google.com 80  
Trying 74.125.232.118...  
Connected to googlemail.l.google.com.  
Escape character is '^]'.  
GET /  
HTTP/1.0 302 Found  
Location: http://www.google.dk/?gws_rd=cr&ei=SRKsU86mA8bMygOV74DoAg  
Cache-Control: private  
Content-Type: text/html; charset=UTF-8  
Set-Cookie: PREF=ID=b56811a41b4fb3df:FF=0:TM=1403785801:LM=1403785801:S=X8pGeIMuTcy6C6lV; expires=Sat, 25-Jun-2016 12:30:01 GMT; path=/; domain=.google.com  
Set-Cookie: NID=67=ZIRKTBJPZrpyCRa9XaR8Gqkay6DfqFxnvq6LLisqhX1CoTqC8-MfhtOav8gcfiJuLvAbVEUlV7lKBYK26j5gYlgex2MCf_VbE33Yk3BpJgrEMG_Na4kuWJ23C88PEsdc; expires=Fri, 26-Dec-2014 12:30:01 GMT; path=/; domain=.google.com; HttpOnly  
P3P: CP="This is not a P3P policy! See http://www.google.com/support/accounts/bin/answer.py?hl=en&answer=151657 for more info."  
Date: Thu, 26 Jun 2014 12:30:01 GMT  
Server: gws  
Content-Length: 258  
X-XSS-Protection: 1; mode=block  
X-Frame-Options: SAMEORIGIN  
Alternate-Protocol: 80:quic  
   
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">  
<TITLE>302 Moved</TITLE></HEAD><BODY>  
<H1>302 Moved</H1>  
The document has moved  
<A HREF="http://www.google.dk/?gws_rd=cr&amp;ei=SRKsU86mA8bMygOV74DoAg">here</A>.  
</BODY></HTML>

Sorry hvis det går under flue knepperi, men den eneste måde man kan gøre det sikkert på er vel ved at lave en løsning som ikke "bare" er "vores egen browser snakker kun med os selv over https".

Kim Bjørn Tiedemann

Det er rigtigt - den allerførste gang du besøger sitet inden sitet har sat Http Strict Transport Security headeren, har du en mulighed for at redigere brugerens request over på dit eget site.

Men i det request er der altså ingen auth cookie med og derfor er man på en ren phishing expedition, hvor man skal lave en gmail klon for at snyde adgangskoden ud af folk. Men det gør ikke SSL meningsløst.

Hvis du bruger Chrome er det hardcodet ind i browseren, at den kun skal bruge https mod gmail og derfor vil man aldrig have det initielle http request og det er endnu et sikkerhedslag, som er værd at tage med.

Debatten bliver lidt afsporet for det oprindelige problem var:

  1. Sitet brugte mixed mode
  2. Sitet eksponerede auth cookien over http forbindelsen
Martin Westergaard Lassen

Sorry hvis det går under flue knepperi, men den eneste måde man kan gøre det sikkert på er vel ved at lave en løsning som ikke "bare" er "vores egen browser snakker kun med os selv over https".

Både Chrome, Firefox og formentlig IE accepterer bug reports med samme behandling af dit site, samt et hardcoded check af dit certifikat. Helt flueknepperi er det ikke ;)

Log ind eller Opret konto for at kommentere