Beveiligingsonderzoeker Martijn Brinkers is een ware plaaggeest voor Nederlandse internetproviders. De Izecom werknemer heeft de afgelopen jaren uitgebreid de webmail van verschillende aanbieders onderzocht, vaak met schokkende resultaten. Zo bleek eind vorig jaar dat de webmail van Chello, Orange, Planet Internet, Tiscali, Tele2 en 12Move niet goed beveiligd was, waardoor een aanvaller andermans e-mail kon lezen en e-mailinstellingen wijzigen. Bij Het Net en Xs4all werden ook problemen aangetroffen, daar kon via een geprepareerd mailtje tijdelijk op de webmail van een abonnee worden ingebroken.

Ondanks de belofte, is het zeer waarschijnlijk dat de meeste providers die Brinkers onderzocht hun webmail nog steeds niet op orde hebben. "Ik zou die dus ook niet gebruiken zonder extra beveiligingsmethoden. Bij een aantal van deze providers is het mogelijk dat er een kopie van alle binnenkomende email wordt doorgestuurd naar een extern email adres zonder dat je dat door hebt," zo laat de onderzoeker in een interview met Security.NL weten.

De beveiliging van de webmail van Nederlandse providers lijkt structureel "lek" te zijn. Je hebt in het verleden al meerdere keren aangetoond dat het mogelijk is om toegang tot iemand z'n account te krijgen. Gaat het hier om implementatiefouten of echte beveiligingslekken in de code?

Brinkers: Het gaat hier bijna uitsluitend om beveiligingslekken in de code. Eén uitzondering was een ISP die een eigen webmail systeem had ontwikkeld waarbij HTML attachments geopend werden in een ander subdomein. Doordat ‘cross domain scripting’ niet mogelijk is, had de eventuele scripting code in die attachment ook geen toegang tot het email domain. Echter waren ze vergeten Apache zo in te stellen dat deze niet zomaar willekeurige .php files kon uitvoeren. Het sturen van een php attachment was dus voldoende om willekeurige code op de webmail server te activeren.

Meestal zijn het echter implementatiefouten. De meest voorkomende fout die wordt gemaakt is dat het vaak mogelijk is om ‘externe’ javascript code uit te voeren in de context van webmail applicatie (de zgn. ‘cross site scripting exploit’ ook wel afgekort tot XSS). Indien het voor een ‘aanvaller’ mogelijk is om willekeurige javascript code te laten uitvoeren binnen het domein van de web applicatie heeft deze toegang tot nagenoeg alle resources (dus bijv. cookies en emails) en kan de webpagina naar believen worden aangepast en uitgelezen. Het is dan bijvoorbeeld mogelijk om de cookies door te sturen naar een externe server (waardoor je in veel gevallen kan ‘inbreken’ op de login sessie) of je kan emails uit de Inbox scannen op interessante gegevens en eventueel laten doorsturen naar een ander adres zonder dat de gebruiker dat door heeft. De impact van een XSS exploit (en dit gaat natuurlijk op voor elke type exploit) hangt sterk af van de rest van de applicatie. In veel gevallen zijn er andere implementatiefouten te vinden die op zichzelf staand niet te misbruiken zijn maar in combinatie met een XSS exploit wel. In veel van de door mij onderzochte webmail applicaties was (is?) het mogelijk om voorkeuren van gebruikers aan te passen zonder dat de gebruiker gevraagd wordt om zijn of haar wachtwoord. In zo’n geval kan je door gebruik te maken van een XSS exploit de gebruikersvoorkeuren aanpassen zonder dat de gebruiker dit door heeft. In veel gevallen was het dus mogelijk om bijvoorbeeld de email ‘forwarding’ aan te passen zodat er voor elk binnengekomen email een kopie naar een willekeurig email adres werd verstuurd. In een aantal gevallen was het mogelijk om het wachtwoord of het ‘password recovery’ adres van de gebruiker aan te passen.

Een ander veel voorkomend probleem is 'Cross Site Request Forgeries' (CSRF). Zonder voorzorgsmaatregelen is een web applicatie niet in staat onderscheid te maken tussen opdrachten afkomstig van de web applicatie zelf en opdrachten van een andere bron dan de web applicatie. In het geval van webmail kan dit bijvoorbeeld worden misbruikt door een IMG (een afbeelding) aan een email te ‘attachen’ met als bron niet een echte afbeelding maar een URL naar een web applicatie resource. Indien de gebruiker deze email opent zal de browser een aanvraag doen (een GET) naar deze resource. Zodoende kan bijvoorbeeld het wachtwoord van de gebruiker worden aangepast door de aanvaller zonder dat de gebruiker dit weet. In veel gevallen is het niet eens nodig om een CSRF attack via de website zelf uit te voeren. Een pagina op een ander domein kan ook POSTs en GETs uitvoeren naar een willekeurig ander domein. Je browser stuurt vrolijk de sessie cookies mee. Zolang een web applicatie geen onderscheid kan maken tussen echte en gefingeerde requests is een CSRF attack mogelijk.

Een beveiligingsprobleem is in feite een niet –lineair probleem. Een op zichzelf staand probleem hoeft niet ernstig te zijn. Twee niet ernstige problemen kunnen samen echter wel ernstig zijn.

Een aardig, hoewel behoorlijk technisch, voorbeeld hiervan is een combinatie van problemen die ik vond bij een webmail aanbieder. Het domein van deze webmail aanbieder was opgesplitst in een aantal subdomeinen. Het hoofd domein werd oa. gebruikt voor “sign-up”, “support” etc. Nadat een gebruiker was ingelogd werd deze doorgestuurd naar een speciaal subdomein voor de webmail. Aangezien bepaalde invoer niet goed werd gefilterd was het mogelijk om script te ‘injecteren’ op de hoofdpagina. Op zichzelf was dat niet onmiddellijk te misbruiken (afgezien dat je eventueel de login pagina kan ‘spoofen’) aangezien je browser ‘cross domain scripting’ niet toestaat. Je kon dus geen toegang krijgen tot het domein waar de mail op werd verwerkt. Het bleek echter ook mogelijk om script te ‘injecteren’ bij het email opstel scherm. Wanneer iemand een email wilde opstellen werden de eventueel aanwezige email adressen uit een GET parameter (genaamd ‘TO’) uitgelezen en ingevuld in het email opstel scherm (dit werd bijvoorbeeld gebruikt als een bestaande email uit de ‘drafts folder’ werd geopend). Deze ‘TO’ parameter werd echter niet goed gefilterd en het was dus mogelijk hier script code in te verwerken.

Dit script zou dan worden uitgevoerd in het webmail domain. Op zich was deze fout niet direct te misbruiken aangezien het niet mogelijk was om via een externe bron deze ‘TO’ parameter aan te passen. Het bleek echter dat de webmail was gemaakt met PHP waarbij gebruik werd gemaakt van de $_REQUEST superglobal. Het ‘handige’ hiervan is dat je niet expliciet hoeft op te geven of je een POST,GET of Cookie parameter wil hebben. Welke parameter je terug krijgt hangt af van de ‘variables_order’ setting. Standaard is dat zo ingesteld dat Cookies voor POST en GET parameters gaan. Door nu gebruik te maken van de XSS exploit op de hoofdpagina was het mogelijk om Cookies aan te passen op het webmail subdomein. Je kon dus een Cookie genereren genaamd ‘TO’ met als waarde een stukje script code. Indien de gebruiker vervolgens een email wilde opstellen werd er ineens gebruik gemaakt van deze Cookie in plaats van de GET parameter en werd dus het script uitgevoerd. Je zou kunnen zeggen dat het een slapende ‘XSS exploit’ is aangezien de ‘besmetting’ op een ander moment plaatsvindt dan het uitvoeren van de exploit code. Het enige dat nu nog nodig was, was de gebruiker zo ver krijgen dat hij of zij eenmalig op een link zou klikken die bijvoorbeeld via email werd verstuurd. Elke moment daarna zou de script exploit zijn werk doen als er een nieuwe email werd opgesteld. Zolang de cookies aanwezig waren (de cookies waren onbeperkt geldig) was de exploit aanwezig.

Hoe kom je trouwens achter de beveiligingsproblemen. Voer je een code audit uit, of loop je "toevallig" tegen bepaalde zaken aan die "misbruik" mogelijk maken en is het niet de taak van de ISP om de beveiliging van hun diensten te controleren?

Brinkers: Dat is eigenlijk ontstaan omdat ik zelf bezig was met de implementatie van een webmail applicatie en ondervond hoe lastig het was om te zorgen dat een webmail applicatie veilig was. Zodoende ben ik eens gaan kijken hoe ze voor bestaande webmail applicaties dat soort problemen hadden opgelost en kwam er al snel achter dat voor een groot deel van de webmail applicaties deze beveiligingsproblemen helemaal niet waren opgelost.
In feite is het de taak van elke ISP om duidelijk te maken welk niveau van service en veiligheid ze kunnen garanderen. Het lastige is alleen dat hier geen duidelijk toetsbare normen voor zijn. De ISP’s zullen claimen dat hun veiligheid goed op orde is maar zonder duidelijke normen zegt dat niet zo veel.

Hoe reageren providers als ze met een lek geconfronteerd worden?

Brinkers: De meeste providers reageerden heel slecht of niet. De grote uitzonderingen waren XS4ALL (die adequaat reageerde en samen met de ontwikkelaars van Squirrelmail op zoek gingen naar oplossingen van het probleem), Yahoo en Microsoft. Wat mij opviel was dat er vaak een totaal gebrek aan kennis was wat betreft het beveiligen van web applicaties en webmail in het bijzonder. Bij elke melding werd een voorbeeld ‘exploit’ meegestuurd om duidelijk te maken wat er mis was. De oplossing van de ISP was meestal het aanpassen van de webmail applicatie zodat deze specifieke ‘exploit’ niet meer mogelijk was. Ze loste echter het onderliggende probleem niet op en een simpele aanpassing van de ‘exploit’ was vaak voldoende om de door hun aangepaste beveiliging te omzeilen. Na weer een melding paste ze de beveiliging weer aan maar wederom niet afdoende. Dit herhaalde zich meestal een aantal keer.

Is het niet een optie dat ISP's en e-mailproviders beter hun servers beveiligen, bijvoorbeeld door continu een nieuwe cookie te versturen, het IP-adres aan de sessie mee te geven en die dan te controleren of geen Java / scripting toe te staan?

Brinkers: Het IP adres koppelen aan je sessie kan verhelpen dat een externe aanvaller je huidige web sessie kan overnemen als deze beschikt over de session cookies. Echter het overgrote deel van de problemen die ik heb gevonden waren ernstiger dan het kunnen ‘stelen’ van je cookies. Het koppelen van de IP aan een cookie zal voor deze problemen geen oplossing zijn. De meeste webmail applicaties doen hun best om het ‘injecteren’ van javascript tegen te gaan. Het lastige van een webmail applicatie is dat email vaak bestaat uit HTML dat vervolgens weer javascript kan bevatten. De meeste webmail applicaties filteren vervolgens deze HTML zodat alle 'gevaarlijke' code verwijderd wordt. Aangezien je op heel veel verschillende manieren javascript kan verwerken in HTML is het zeer lastig om al deze javascript te verwijderen uit de HTML. Internet Explorer bijvoorbeeld accepteert de meest uiteenlopende javascript code (ik heb in de loop van de tijd een uitgebreide lijst opgebouwd van exotische script injectie methoden). Het is daarom veel beter om te werken met een ‘whitelist’ ipv een 'blacklist'. Dat wil zeggen, accepteer alleen bekende en veilige HTML tags en gooi de rest weg. Een andere mogelijkheid is om gewoon HTML email niet te accepteren en alleen het tekstdeel te laten zien.

Als je de situatie van Nederlandse providers vergelijkt met die van andere webmailaanbieders zoals Gmail en Hotmail, is de situatie bij deze partijen dan beter?

Brinkers: Bij Gmail, Hotmail en Yahoo werkt het 'vele ogen' principe ondanks dat het niet open source is. Dat wil niet zeggen dat er zo nu en dan nog wel problemen worden gevonden bij een van deze partijen. Echter zullen dat niet de meest voor de hand liggende problemen zijn.

Is webmail sowieso niet inherent onveiliger dan een traditionele setup met een software client?

Brinkers: Ja en nee. Het is wel mogelijk om webmail zo te maken dat er geen implementatiefouten zijn. Stel dat er helemaal geen implementatiefouten zijn, maar je email staat wel op een server waar je geen zeggenschap over hebt dan zijn er nog andere problemen waar je rekening mee moet houden. Wie kan er bijvoorbeeld mee lezen? Waar staan de back-ups? Je moet je afvragen of het acceptabel is om bijvoorbeeld medische of beursgevoelige gegevens op een externe webmail server te plaatsen.

De beveiliging van Webmail, althans, de onveiligheid ervan, haalt altijd het nieuws. Toch lijkt het zowel providers als gebruikers niet te kunnen schelen, aangezien het percentage internetters dat webmail gebruikt alleen maar groeit. Vanwaar deze onverschilligheid?

Brinkers: Voor veel internetgebruikers is email toch een soort blackbox. Je verstuurt iets en ergens komt het aan. Wat er intussen gebeurt met deze email vind plaats buiten het zichtsveld van de gebruiker. Het is ook niet duidelijk hoe vaak het mis is gegaan met het lekken/onderscheppen van email. Iets dat bij email virussen vaak wat duidelijker meetbaar is. Veel gebruikers zijn er ook niet van op de hoogte dat de routering van email volledig valt en staat bij de betrouwbaarheid van de DNS infrastructuur. DNS is echter niet helemaal te vertrouwen. Email is dus vrij gevoelig voor een ‘man in the middle attack’. Deze kritiek is echter meer gericht op email in het algemeen dan specifiek op webmail.

Maakt het voor een provider nog uit welk pakket hij gebruikt om webmail aan te bieden, SquirrelMail, Horde, Outlook Web Acces etc. of is het allemaal "een pot nat" als het om veiligheid gaat.

Brinkers: Ik heb zowel bij Squirrelmail, Horde als bij Outlook Web Access script injectie problemen gevonden. Toch zijn dit over het algemeen veilige webmail applicaties aangezien ze veel worden toegepast en dus ook vaak worden onderzocht op problemen. Zelfbouw is niet aan te raden als je niet exact weet waar je mee bezig bent. ISP’s kunnen dan beter gebruik maken van bewezen oplossingen. Wat je ook nog wel eens ziet is dat er ‘in house’ aanpassingen worden gedaan op bestaande webmail applicaties zonder na te denken over de beveiligingsaspecten daarvan (bijvoorbeeld het kunnen aanpassen van je wachtwoord of email forwarding). Dat gaat dus nog al eens mis.

Als het gaat om contentfiltering geven bedrijven veel geld uit aan het beveiligen en monitoren van e-mailclients, maar webmail wordt hierbij vergeten. Hoe zouden bedrijven hiermee om moeten gaan, en moet webmail op de werkvloer verboden worden?

Brinkers: Er wordt enorm veel geld en resources besteed aan het buitenhouden van aanvallen. Ook worden er regelmatig audits uitgevoerd om het beveiligingsbeleid te toetsen. De focus ligt hierbij vaak volledig op de informatiestroom van buiten naar binnen toe. Email is echter twee richtingsverkeer. Om tot een goed beveiligingsbeleid te komen zal je dus ook je uitgaande email moeten betrekken in je beveiligingsplan. Een audit beperkt zich meestal tot je eigen infrastructuur. Dat kan dus betekenen dat je bepaalde informatie extra zal moeten beveiligen alvorens het te versturen. Je weet immers niet van te voren waar de email wordt opgeslagen en of gelezen.

Onlangs hadden we dit artikel met tips waarin mensen werd verteld hoe ze konden controleren of hun webmail gehackt was. Heb je misschien nog aanvullende tips of informatie?

Brinkers: Controleer of je email forwarding is aangepast. Het kan zijn dat er kopieën worden verstuurd zonder dat je erg in hebt. Ook kan het zijn dat je ‘secret question’ is aangepast zonder dat je er erg in hebt. Hoe je dat kan controleren is afhankelijk van de gebruikte webmail applicatie.

Verwacht je in de toekomst meer problemen met webmail, doordat er bijvoorbeeld van AJAX gebruik wordt gemaakt, waardoor aanvallers weer een nieuw aanvalsoppervlak hebben?

Brinkers: “Complexity is the enemy of security”. Dus ik denk dat de problemen voor webmail nog niet de wereld uit zijn. Het belangrijkste is dat je ontwikkelaars hebt die snappen wat er allemaal mis kan gaan en regelmatig security audits uitvoeren op hun eigen code en bereid zijn bij te blijven met de laatste ontwikkelingen op beveiligingsgebied.. De beste oplossing is dus de juiste mensen met de juiste scholing die ook de ruimte krijgen om zich verder te ontwikkelen.

Heb je zelf nog vertrouwen in webmail of zweer je toch bij mutt?

Brinkers: Ik maak zo nu en dan gebruik van webmail maar niet vaak (ik heb een Blackberry). De meeste email die ik verstuur is trouwens versleuteld dus alleen ik heb toegang tot de inhoud van deze emails.