Door Herman Braam, 26 mei 2014
Afgelopen weekend keek ik met verbazing en toenemende ongerustheid naar een aflevering van Kassa op TV. Beveiligingsexperts vertelden daar over een nieuw lek in SSL waardoor internetbankieren via een Wifi Hotspot niet veilig zou zijn. Hoorde ik nou goed dat er met software op de Wifi router ingebroken kon worden op de beveiligde verbinding met mijn bank? Zelfs de inhoud van betalingen kon worden aangepast zonder dat ik dat als gebruiker zou merken.
Althans niet direct, pas wanneer je na een aantal dagen opnieuw op je rekening zou kijken werden de malafide afboekingen zichtbaar. Het advies om kabeltjes te gebruiken in plaats van Wifi om veilig te kunnen bankieren had iets weg van het afplakken van de PC-camera dat eerder dit jaar door justitie werd aangeraden. Afdoende, dat zeker, maar toch wel wat bizar.
Omdat ik zeker wilde weten waar ik me nu precies ongerust over moest maken en omdat eenvoudig inbreken op een SSL verbinding me niet waarschijnlijk leek, besloot ik dit wat verder uit te diepen.
Een oude bekende
Al snel bleek het bij deze aanval om een oude bekende te gaan die voor het eerst in 2009 onder de aandacht is gebracht. Deze aanvalstechniek staat bekend als SSL-stripping, waar je hier meer over kunt lezen. Met SSL stripping wordt niet op de SSL verbinding zelf ingebroken, maar wordt deze verbinding door iemand anders dan de gebruiker opgezet. Wanneer een SSL verbinding wordt opgezet tussen de browser van de gebruiker en de server van de bank, dan is het voor derden niet mogelijk de inhoud van die communicatie te onderscheppen. (Even los van speculaties over achterdeuren en supercomputers van de NSA).
Hoe werkt de aanval?
Het punt bij dit lek is dat gebruikers doorgaans helemaal niet vragen om een versleutelde verbinding, maar bijvoorbeeld bank.nl in de browser intypen. Dat vertaalt zich naar het niet versleutelde http://www.bank.nl. Omdat de bank graag veilig wil communiceren wordt het door de browser verzochte HTTP adres door de server beantwoord met het verzoek om in plaats daarvan naar https://www.bank.nl te gaan. En daar zit de crux. De Wifi router regelt het verkeer tussen de browser van de gebruiker en de server bij de bank. Het verzoek van de bank om naar de beveiligde verbinding te gaan kan door de router worden onderschept en komt dan nooit bij de browser aan. Omdat de gebruiker niet zelf om een versleutelde verbinding aan de bank vraagt, kan de software in de Wifi router dat nu in plaats van die gebruiker doen. De door de bank aangeboden SSL verbinding wordt dan opgezet tussen de Wifi router en de bank, terwijl de Wifi router via onbeveiligd HTTP blijft communiceren met de browser van de gebruiker. De browser heeft het verzoek van de bank om HTTPS te gebruiker immers nooit ontvangen. Een klassieke “man in the middle” aanval. Een techniek die in principe werkt voor alle websites die van SSL gebruik maken en dus niet alleen misbruikt kan worden bij internetbankieren.
Omdat de Wifi Router het eindpunt is van de HTTPS verbinding, kan alle van de bank verkregen informatie gewoon gelezen worden door de software op de router. Dat is geen lek, maar zoals het is bedoeld. SSL versleutelt informatie immers alleen tijdens transport en niet op het start- of eindpunt. Omdat de onbeveiligde HTTP communicatie tussen browser en Wifi router gewoon leesbaar is kan deze eenvoudig gemanipuleerd worden. De door de gebruiker ingevulde bankrekeningen bij een overboeking kunnen dan bijvoorbeeld worden vervangen met alle gevolgen van dien.
Ziet de gebruiker daar nou niks van?
Als de gebruiker goed op zou letten dan valt op dat er HTTP i.pv. HTTPS in de adresbalk van de browser staat. Daarnaast ontbreekt op de meeste moderne browsers het slotje. Bij sommige browsers (Internet Explorer en oudere versies van Firefox, Opera en Chrome) kan de website zelfs een plaatje voor het webadres plaatsen en kan dan bijvoorbeeld een slotje tonen om de gebruiker verder te misleiden. Aan de inhoud van de bankpagina’s valt verder niets te zien van het misbruik. De software in de Wifi router kan aangepaste rekeningnummers bijvoorbeeld terugzetten voordat de door de bank aangeboden pagina in de browser aan de gebruiker wordt getoond.
Wat doen de banken en browsers hier aan?
Toen deze aanvalstechniek in 2009 bekend werd was dat aanleiding om te werken aan verbeteringen die hebben geleid tot HSTS (HTTP Strict Transport Security). Behalve Internet Explorer ondersteunen de meeste moderne browsers dit al enige jaren. Via HSTS instrueren websites een bezoekende browser geen andere dan HTTPS beveiligde communicatie te accepteren. De browser zal dat gedurende langere tijd onthouden, zodat de onbeveiligde verbinding naar de bank website via de malafide Wifi router uit dit verhaal door de browser zal worden geweigerd. Achilleshiel hierbij is dat websites HSTS moeten ondersteunen én dat de browser deze instructie wel eerst moet ontvangen voordat een malafide router deze kan onderscheppen. Wie echter eenmaal via HTTPS met een bank site heeft gecommuniceerd die HSTS ondersteunt is daarna beschermd tegen de aanvallen van malafide Wifi routers. Banken lijken het gebruik van HSTS nu op grotere schaal te adopteren.
Het feit dat Internet Explorer HSTS nog niet ondersteunt is extra vervelend, omdat deze browser het ook mogelijk maakt voor websites om zelf een plaatje (bijvoorbeeld een slotje) in de adresbalk te plaatsen. Overigens heeft Microsoft wel aangekondigd HSTS in de toekomst te ondersteunen.
Wat kun je hier zelf aan doen?
Je kunt natuurlijk het gebruik van Wifi vermijden en terugkeren naar kabeltjes. Praktischer is om op te letten wat je doet als je een beveiligde website wilt bezoeken.
- Gebruik het volledige adres, zodat de browser direct een veilige verbinding op kan zetten. Dus: https://www.bank.nl in plaats van bank.nl
- Controleer of er in de adres balk van de browser daadwerkelijk HTTPS staat en niet HTTP nadat de website is geopend
Als je hier goed op let is ook Internet Explorer veilig te gebruiken, maar zonder HSTS ondersteuning loop je wel meer risico als je een keer wat minder scherp bent.
Conclusie
Voor mij was het geruststellend om te constateren dat het fundament onder SSL niet is aangetast en dat er geen sprake was van een lekkende SSL verbinding bij deze hack. Minder geruststellend is dat een probleem dat al in 2009 is gesignaleerd en waarvoor al enige jaren oplossingen voor handen zijn, in de praktijk nog nauwelijks blijkt te zijn opgepakt. Hoewel er dus feitelijk geen sprake is van een nieuw lek, zit de nieuwswaarde wat mij betreft vooral in het grote gat tussen theorie en praktijk. Bij mijn werkzaamheden als privacyspecialist merk ik dagelijks hoever theorie en praktijk uit elkaar liggen, blijkbaar is dat bij beveiligingsvraagstukken niet anders.
Over de auteur: Herman Braam is oprichter en eigenaar van Privyon.
Specialist in vraagstukken op het snijvlak van IT en privacy. Helpt organisaties te voldoen aan de privacywetgeving
Contact via hbraam@privyon.nl of LinkedIn.