WHITEPAPER: Firesheep en sidejacking Whitepaper Firesheep en sidejacking
Firesheep en sidejacking Inhoud Inleiding............................................................... 3 Het probleem van onbeveiligde Wi-Fi..................................... 3 Zelfbescherming....................................................... 4 De oplossing: TLS/SSL voor de gehele site................................ 5 Kosten en baten van TLS/SSL............................................ 5 Conclusie.............................................................. 6 2
Inleiding De recente release van Firesheep, de tool voor aanvallen op draadloze netwerken, heeft zowel gebruikers als aanvallers meer bewust gemaakt van de inherente onveiligheid van HTTP-verbindingen die niet beschermd zijn. Gebruikers op onbeveiligde netwerken die via gewone HTTP-verbindingen met websites verbinding maken, stellen hun verbindingen met die sites bloot aan de mogelijkheid van open toezicht en gegevensinbreuken. Firesheep stelt een aanvaller die met het lokale netwerk verbonden is, in staat om de websessies van andere gebruikers op het desbetreffende netwerk te volgen. De aanvaller kan de sessies van andere gebruikers vervolgens ook besturen door handelingen te verrichten in hun gebruikerscontext. Firesheep is specifiek gericht op open draadloze netwerken, maar het probleem komt ook voor op conventionele bekabelde ethernet-netwerken. Dit is allemaal niet nieuw. Deze problemen waren al jaren algemeen bekend, in ieder geval in de beveiligingssector. Firesheep heeft ook andere gebruikers kwetsbaar gemaakt en heeft ertoe geleid dat verregaande identiteitsdiefstal zelfs voor onervaren hackers binnen handbereik ligt. Zoals deskundigen in reactie op Firesheep hebben aangegeven, is de beste oplossing voor het probleem het gebruik van TLS/SSL voor alle verbindingen met websites, waaronder de beginpagina. Veel beheerders van grote sites zijn terughoudend geweest in het gebruik van TLS/SSL, misschien vanwege de grotere behoefte aan verwerkingscapaciteit die dat met zich meebrengt, maar dergelijke zuinigheid valt steeds moeilijker te verdedigen met het oog op het bedreigingsniveau en de werkelijke kosten. Het probleem van onbeveiligde Wi-Fi Draadloze 802.11-netwerken hebben al van oudsher te kampen met beveiligingsproblemen. Het eerste beveiligingsmechanisme, WEP ofwel Wired Equivalent Privacy, bleek funeste tekortkomingen te bevatten 1. Een WEP-installatie kan gemakkelijk worden gehackt met tools zoals AirSnort en Aircrack. Terwijl de overstap op WEP garant staat voor effectieve beveiliging, zijn open Wi-Fi-hotspots met WPA2 (Wi-Fi Protected Access versie 2) nog altijd zeer geliefd voor openbare toegang tot gebruiksvriendelijke verbindingsmogelijkheden; deze hotspots zijn afhankelijk van toegangscontrole door middel van bepaalde vormen van proxyverificatie, waarbij de router van de lokale hotspot verificatie op basis van HTTP biedt. Mogelijk worden de gegevens tussen de router en de rest van internet versleuteld (waarschijnlijk echter niet), maar het lokale netwerk in en rond het café is niet versleuteld en ligt nog altijd open. Daardoor is ook het verkeer van de clientcomputers naar internet daar niet versleuteld. Gebruikers kunnen zich op zo'n netwerk alleen volledig beschermen door gebruik te maken van een Virtual Private Network. Het meeste verkeer op openbare draadloze netwerken (en ook veel privénetwerken) is gebaseerd op HTTP, oorspronkelijk het toepassingsprotocol van het web, maar vaak gebruikt voor meerdere toepassingen. Tenzij voor de lokale toepassingen en de servertoepassingen een bepaald protocol voor privéversleuteling is geïmplementeerd, is het HTTP-verkeer niet versleuteld. 1 NScott Fluhrer, Itsik Mantin en Adi Shamir, Weakness in the Key Scheduling Algorithm of RC4, The Fluhrer, (FMS Attack), 2001, http://www.drizzle.com/~aboba/ieee/rc4_ksaproc.pdf 3
Alle verkeer is op het lokale netwerk als platte tekst beschikbaar en iedereen op hetzelfde netwerk kan het lezen. Het probleem wordt vergroot door veel voorkomende praktijken van websites met cookies. HTTP is staat- en sessieloos, hetgeen betekent dat afzonderlijke HTTP-opdrachten onafhankelijk zijn en niet door de server zelf worden verbonden. Gebruikers en hun sessiegegevens, zoals het document dat ze bekijken en wat ze ermee doen, moeten worden bijgehouden met toepassingen op de server. De standaardmanier om dergelijke zaken bij te houden is om cookies te gebruiken, dus gegevens die lokaal op de clientcomputer worden opgeslagen en aan een bepaalde server of een bepaald domein worden gekoppeld. De server verzendt deze cookies naar de client en de cookies worden ongewijzigd door de client naar de server teruggestuurd. De cookies kunnen gevoelige persoonlijke gegevens of andere identiteitsgegevens bevatten die door de server kunnen worden gebruikt om de client te identificeren. Cookies die specifiek worden gebruikt om gebruikerssessies bij te houden, noemen we sessiecookies. Cookies kunnen worden verzonden met een markering die aangeeft dat ze beveiligd zijn, zodat de browser ze alleen via een HTTPS-sessie (TLS/SSL) verzendt. Het is gebruikelijk om het aanmeldingsproces voor websites te versleutelen, maar niet om de markering voor de beveiliging van sessiecookies te gebruiken. Een aanvaller die een open netwerk in de gaten houdt, kan niet alleen de gegevens zien die tussen de server en de client worden verzonden, maar ook de gegevens in de onbeveiligde cookies. De cookiegegevens kunnen vervolgens worden gebruikt om de gebruiker te imiteren met een aanvalstechniek die 'sidejacking' wordt genoemd, een vorm van sessiekaping. Dit is de werkwijze van Firesheep. Firesheep is een uitbreiding voor de webbrowser Firefox, ontwikkeld door Eric Butler, die in oktober 2010 werd vrijgegeven tijdens ToorCon 12, een hackerscongres in San Diego. Firesheep gebruikt een 'pakketsnuffelaar' om onbeveiligde cookies te onderscheppen. Daarmee worden de namen van gebruikers op het lokale netwerk getoond alsmede de services waarmee ze verbonden zijn. De aanvaller kan met behulp van de gebruikersgegevens van het slachtoffer verbinding maken met deze services door op de naam te dubbelklikken. Zelfbescherming Een intelligente, vindingrijke en gemotiveerde gebruiker kan zichzelf tegen dergelijke bedreigingen beschermen. Sinds de onthulling van Firesheep zijn er talloze technische opties op de markt gebracht die geen van alle toegankelijk zijn voor gemiddelde gebruikers en geen van alle standaard goede bescherming bieden. Eén daarvan was een invoegtoepassing voor Firefox van de Electronic Frontier Foundation, HTTPS Everywhere 2. Met dit programma worden HTTP-aanvragen van de browser omgezet in HTTPS-aanvragen. Dit werkt alleen met sites die over SSL beschikken, maar standaard gebruikmaken van HTTP. Zoals op de pagina van HTTPS Everywhere zelf wordt aangegeven, gaat dit gepaard met bepaalde problemen. Zo werkt het alleen met specifieke browsers, kan het verbindingen met sommige draadloze netwerken blokkeren en kunnen gebruikers de toegang tot sommige services van Google kwijtraken. Maar zelfs als een gebruiker met deze configuratie tevreden is, is het nog mogelijk dat de site met JavaScript cookies via HTTP in platte tekst verzendt. 2 Electronic Frontier Foundation: Defending Your Rights in the Digital World, HTTPS Everywhere, https://www.eff.org/https-everywhere 4
Voor wat open draadloze netwerken betreft, zou het veel veiliger zijn om simpelweg WPA2 met een gedeeld wachtwoord te implementeren en een bericht weer te geven met de tekst 'Het wachtwoord luidt xxxxxxx' of om de netwerknaam te veranderen in 'ww café luidt xxxxxxx'. Zo kan iedereen op het netwerk komen, net als bij een open netwerk, maar met WPA2 wordt de gebruiker ook geïsoleerd, zodat er geen pakketsnuffelaar kan worden toegepast. Helaas zullen beheerders van draadloze hotspots dit niet klakkeloos voor websites regelen. Een andere oplossing is een Virtual Private Network, dat een versleutelde tunnel tussen het clientsysteem en een host op internet vormt dat als proxy voor alle communicatie van de client dient. Maar geen van deze oplossingen is perfect, omdat ze afhankelijk zijn van gebruikers die proactieve maatregelen moeten nemen om zichzelf te beschermen. De oplossing: TLS/SSL voor de gehele site Sites waarvoor TLS/SSL wordt gebruikt, zijn immuun voor sidejacking. TLS/SSL is in feite zelfs de enige goede oplossing voor het probleem. Eric Butler zelf formuleert het aldus: De enige effectieve oplossing voor dit probleem is volledige versleuteling tussen eindpunten, op het web bekend als HTTPS of SSL. 3 Volledig gebruik van TLS/SSL impliceert volledig gebruik van de markering voor beveiliging van cookies. Daarmee zullen alle aanvallen met pakketsnuffelaars op sites die op deze wijze worden beschermd, mislukken. Voor sites waarop altijd TLS/SSL wordt toegepast om gebruikers te beschermen, moet ook een vertrouwde certificeringsinstelling worden ingeschakeld. Volledige HTTPS-verificatie bij een vertrouwde certificeringsinstelling is de enige manier waarop gebruikers zeker weten met wie ze te maken hebben. Kosten en baten van TLS/SSL Expertise en softwareondersteuning op het gebied van TLS/SSL zijn alomtegenwoordig, dus kosten vormen de enige reden om niet HTTPS voor alle verbindingen met een website te gebruiken. Wat zijn de kosten? Grosso modo zijn er twee kostenposten. Dat zijn ten eerste de kosten van de certificaten zelf. Hoewel deze niet nul zijn, zijn deze kosten ten minste vast en voorspelbaar. Het echte struikelblok voor de meeste bedrijven zijn de extra hardwarekosten. Het gebruik van TLS/SSL betekent dat alle verkeer aan het ene uiteinde wordt versleuteld en aan het andere uiteinde wordt ontsleuteld. Daarvoor is extra computergebruik vereist dat anders niet nodig zou zijn. Op een grote site zou dit de indruk kunnen wekken dat dit tot substantiële hardwarekosten leidt. Maar dat hoeft niet zo te zijn. Neem Google, dat voor de uitermate populaire Gmail-service aan het begin van 2010 volledig op HTTPS is overgestapt. Adam Langley, een softwareengineer bij Google die bezig is met OpenSSL, NSS en Google Chrome, zegt daarover: In januari van dit jaar (2010) is Gmail voor alle toepassingen overgestapt op HTTPS. Dit was eerder als optie geïntroduceerd, maar nu gebruiken al onze gebruikers HTTPS om hun e-mails tussen hun browsers en Google te allen tijde te beveiligen. Daartoe hoefden wij geen 3 Eric Butler, Firesheep, {codebutler}, 24 oktober 2010, http://codebutler.com/firesheep 5
extra computers of speciale hardware te implementeren. Op de front-end computers zijn SSL/TLS-accounts verantwoordelijk voor minder dan 1% van de CPU-belasting, minder dan 10KB geheugen per verbinding en minder dan 2% van de netwerkbelasting. Veel mensen denken dat SSL veel CPU-tijd in beslag neemt en we hopen dat de bovenstaande cijfers (voor het eerst openbaar) zullen helpen om deze misvatting uit de weg te ruimen. 4 Eigenlijk is dit niet zo verrassend, want historische ontwikkelingen in CPU-prestaties hebben de prestatiebehoefte van SSL-webservers in de kaart gespeeld. De wet van Moore leidt niet alleen tot steeds betere ruwe prestaties, maar heeft ook tot meerdere CPU-kernen op elke CPU en grote cachegeheugens geleid. CPU's met meerdere kernen leiden bij toepassingen niet altijd tot betere prestaties, maar wel bij SSL-webservers, omdat elke verbinding naar één kern kan worden geleid. Een webserver zonder SSL, die in feite als een eenvoudige bestandsserver fungeert, belast de CPU mogelijk helemaal niet zoveel. Het resultaat is dat het toevoegen van SSL mogelijk weinig gevolgen zal hebben voor de algemene systeemprestaties. Dit zou een verklaring kunnen zijn voor de resultaten van Google. Zoals Langley benadrukt: SSL/TLS voor computers is niet meer duur. Hij bespreekt ook andere maatregelen die gebruikers kunnen nemen om de netwerkprestaties van een site te optimaliseren. Certificaatbeheer kan grote gevolgen hebben. Onjuiste configuratie kan tot tragere prestaties leiden. Als een site, zoals Google, bereid is om de webserver of OpenSSL zelf te optimaliseren, kunnen de netwerkprestaties sterk worden verbeterd. Bovendien biedt dit het voordeel dat alle communicatie tegen bepaalde soorten aanvallen wordt beschermd. Zodoende worden de site en haar gebruikers actief beschermd tegen beschamende en schadelijke incidenten en wordt iedereen duidelijk gemaakt dat de beveiliging serieus wordt genomen. Conclusie Het is voor openbare websites belangrijk om gebruikers functies voor de beveiligingsconfiguratie te bieden waarmee ze de toegankelijkheid van hun persoonlijke gegevens kunnen beheren, maar dit is allemaal voor niets als iemand aan de tafel ernaast de account volledig kan kapen. Beveiliging op internet begint tegenwoordig met een beveiligde privéverbinding die beschermd is tegen spionage. Beveiligingsexperts hebben ervaren dat er bij websites niet van kan worden uitgegaan dat gebruikers zichzelf beschermen. Als de infrastructuur en serviceproviders over systeemoplossingen voor beveiligingsproblemen beschikken, zijn schaalvoordelen van groot belang. Zo wordt uw gehele website met TLS/SSL niet alleen tegen vele aanvallen beschermd, maar kunnen uw gebruikers ook met een gerust hart op die beveiliging vertrouwen. 4 Adam Langley, Nagendra Modadugu en Wan-Teh Chang, Overclocking SSL, Imperial Violet, 25 juni 2010, http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html 6
Meer informatie Bezoek onze website www.symantec.co.uk/ssl-certificates/ssev Bel het volgende telefoonnummer om een productspecialist te spreken 0800 56 29 24 of +41 22 54 50 288 Over Symantec Symantec is wereldwijd leider in oplossingen voor beveiliging, opslag en systeembeheer waarmee consumenten en bedrijven hun door informatie aangestuurde omgeving kunnen beveiligen en beheren. Onze software en services bieden een completere en efficiëntere bescherming tegen meer risico's op meer punten, waardoor informatie met vertrouwen kan worden gebruikt en opgeslagen. Symantec BV Orteliuslaan 850 3528 BB UTRECHT Nederland www.symantec.com 2012 Symantec Corporation. Alle rechten voorbehouden. Symantec, het Symantec-logo, het vinkje, Norton Secured en het Norton Secured-logo zijn handelsmerken of gedeponeerde handelsmerken van Symantec Corporation of haar dochterondernemingen in de Verenigde Staten en andere landen. VeriSign en andere verwante merknamen zijn handelsmerken of gedeponeerde handelsmerken van VeriSign, Inc. of haar dochterondernemingen in de Verenigde Staten en andere landen, en zijn in licentie gegeven aan Symantec Corporation. Andere namen zijn mogelijk handelsmerken van de respectieve eigenaren.