We hackten onze klant en dit is wat we ervan leerden

Het doelwit van onze hack

De insteek van de workshop was om echt praktisch en kritisch te kijken naar werk dat juist heel typerend werk voor ons is. We kozen daarom voor een mobiele app die we op dit moment aan het ontwikkelen zijn voor een van onze klanten. Het is een app waarbij gebruikers zich kunnen registreren en enigszins gevoelige, persoonlijke informatie kunnen inzien. Aangezien de app nog in ontwikkeling is en nog niet aan het publiek bekend gemaakt is, kunnen we helaas niet vertellen om welke klant het gaat.

De app is ontwikkeld in React Native waarbij de gegevens middels een API via een centrale backend worden ontsloten. Gebruikers identificeren zich met een combinatie van e-mailadres en wachtwoord, geven enkele persoonsgegevens op, en krijgen inzicht in gegevens die verwerkt worden door de opdrachtgever.

De backend waar de app mee communiceert is eveneens door ons ontwikkeld. Het systeem is ontwikkeld in Laravel en staat als centraal punt direct in verbinding met meerdere andere backend-systemen. Denk aan ERP-software, marketing-systemen en overige externe databases. De authenticatie-laag in de API bepaalt tot welke data een gebruiker toegang heeft.

Mogelijke beveiligingsproblemen bij online applicaties

De architectuur van online applicaties volgen vrijwel altijd standaard vormen en vertonen daarom vrijwel altijd overeenkomsten met elkaar. Dit betekent dat mogelijke veiligheidsproblemen veel gelijkenissen hebben. Om die reden bestaat de OWASP top 10, een lijst van de meest voorkomende problemen rondom online applicaties. 

Bovenaan de top 10 staat ‘Injection’; een methode waarmee een aanvaller specifieke data verstuurt naar de server om daarmee acties uit te kunnen voeren die normaliter niet uitgevoerd zouden mogen worden. Injection zou aan bod komen maar omdat deze methode vrij technisch is en we ook onze niet-techneuten wilden laten participeren, zouden we hier minder aandacht aan gaan besteden.

Op plek 2 staat ‘broken authentication’; een methode waarbij een aanval gericht is op het achterhalen van informatie waarmee de gebruiker zich kan voordoen als iemand anders, of simpelweg data kan achterhalen waar de gebruiker normaliter geen toegang toe zou moeten hebben. Het staat vrij dichtbij nummer 5, ‘broken access control’, een onderdeel waar we tijdens de workshop zeker naar zouden kijken.

Nummer 3 van de lijst is ‘sensitive data exposure’; een methode om gegevens van andere gebruikers te achterhalen, met name persoonsgegevens. Sinds de komst van AVG is dit iets dat gelukkig veel meer aandacht heeft gekregen en dat ook van ons zou krijgen in de workshop.

Tijdens de workshop richtten we ons op de communicatie tussen applicatie en backend, voor ons het meest interessante deel met het hoogste risico. ‘Hacken’ is alleen een nogal breed begrip en de materie kan heel technisch zijn. Omdat we iedereen wilden laten participeren en het bewustzijn over security niet alleen bij onze techneuten wilden laten groeien, begonnen we de workshop daarom met een korte introductie van hacken en presenteerden we de casus van de workshop.

Dit onderscheppen tussen backend en app wordt ook wel een ‘man-in-the-middle’ methode genoemd: de aanvaller gaat als ‘tussenpersoon’ tussen de twee apparaten zitten en kan het inkomende en uitgaande verkeer, aan beide kanten, onderscheppen, inzien en aanpassen. Het is geen eenvoudig uit te voeren methode maar wederom niet onmogelijk.

Het voornaamste probleem voor de hacker is dat het verkeer tussen onze app en backend uiteraard beveiligd is met TLS-certificaten. Dat wil zeggen dat alle dataverkeer versleuteld is en daarmee zelfs voor de tussenpersoon niet is in te zien. Wat de tussenpersoon zal moeten doen is een eigen TLS-certificaat zien te krijgen op de telefoon van de persoon die hij aanvalt. Als hij daarin slaagt dan de aangevallen persoon de klos. De tussenpersoon kan immers alle data inzien en alle verzoeken ‘namens’ die gebruiker indienen. Hiermee kan de tussenpersoon zich dus voordoen als de gebruiker zelf. Het grote gevaar is dat de tussenpersoon deze informatie kan gebruiken om zich als ieder ander persoon voor te doen en zo bijvoorbeeld de gegevens van álle personen kan achterhalen.

Onze bevindingen

Tijdens de workshop zijn de aanwezigen ingedeeld in kleine teams, en ging ieder team los van elkaar proberen beveiligingsproblemen te achterhalen, ieder met hun eigen methoden, om ze aan het einde van de workshop te presenteren. Dit waren samengevat onze bevindingen.

Meerdere teams begonnen simpelweg met het proberen in te loggen onder andermans account door e-mailadres en wachtwoord combinaties uit te proberen. Al snel bleek natuurlijk dat dit praktisch niet haalbaar was om handmatig te doen. De eerstvolgende stap was om dit via een script te doen met een aantal test-wachtwoorden. Ook hiervoor geldt dat je onmogelijk alle wachtwoorden kunt proberen; de uitgekookte developer pakte er een lijst met veelgebruikte wachtwoorden bij. Binnen korte tijd waren er van meerdere accounts de wachtwoorden achterhaald en konden mensen inloggen.

Een dergelijke aanval valt prima te beveiligen. Allereerst wil je ervoor zorgen dat mensen goede wachtwoorden gebruiken. Dit doe je door bij het registratie-scherm een check op het wachtwoord te doen, bijvoorbeeld op lengte en veelvoud van verschillende karakters. Een mooie dienst hiervoor is de API van Have I been Pwned die een check doet op een wachtwoord op basis van bekende datalekken. Voor de workshop hebben we ervoor gezorgd dat er een aantal accounts met deze veelgebruikte wachtwoorden beveiligd waren.

Ten tweede beveilig je normaliter de API endpoints met een ‘rate limiter’. Dit zorgt ervoor dat je een maximum aantal aanroepen van de API endpoints kunt doen, bijvoorbeeld 1 per seconde. Hiermee zorg je ervoor dat het raden van wachtwoorden ondoenlijk lang zal duren. Deze optie stond voor de test uitgeschakeld maar staat normaliter gewoon aan.

De meest complexe en daarmee de meest interessante bevinding van de avond was een zogeheten Timing Attack. Oorspronkelijk komt deze aanval uit de hoek van de cryptografie waar een versleuteling omzeild kan worden door het uitproberen van verschillende sleutels heel precies te timen. Dit type aanval is mogelijk als het falen van een (deel van een) sleutel sneller bepaald wordt dan het succesvol toepassen. Door als aanvaller de tijd te meten van beide scenario’s kan deze veel sneller de juiste sleutel achterhalen.

Deze methode is ook goed van toepassing op online applicaties. Neem bijvoorbeeld het volgende stukje code:

 function sendForgotPasswordEmail(email_address) {
  user = UserService::findByEmail(email_address);
  if (!user) {
    return true;
  }

  EmailService::sendForgotPasswordEmail(email_address);
  return true;
} 

Dit is een versimpeld stukje code van een functie die een wachtwoord-vergeten-e-mail stuurt als een gebruiker bekend is in het systeem. De programmeur van dit stukje code was slim genoeg om ook in het geval van falen (gebruiker is niet bekend in het systeem) een succesvolle status te geven, zodat een aanvaller niet direct kan achterhalen of een gebruiker in de database aanwezig is, wat een datalek zou geven.

Dit stukje code bestaat uit twee delen: 1. controleren of de gebruiker bestaat, en 2. een email versturen naar deze gebruiker. Een email versturen kost echter tijd: een server moet verbinding maken met een e-mailserver of een process inschieten bij een wachtrij. Als een gebruiker echter niet bestaat dan wordt dit nooit uitgevoerd en zal het proces sneller klaar zijn. Door met een bekend en onbekend mailadres het verschil in tijd precies te meten kan de aanvaller hiermee bepalen of een gebruiker al dan niet in het systeem aanwezig is. Deze methode is succesvol ingezet door één van de teams tijdens de workshop.

Conclusie

Ondanks de relatief korte tijd die we hadden voor deze workshop hebben we een aantal interessante bevindingen verzameld. Ze gaven ons meer inzicht in de veiligheid van al onze applicaties en de maatregelen die we moeten nemen om dit te verbeteren. Daarbij was het ook mooi om te zien hoe ook mensen zonder enige ervaring in beveiliging met eigen inzichten kwamen en actief konden participeren in de workshop. Het is dus absoluut iets dat we vaker zullen doen.

Meer weten?

Je kan de slides van de presentatie van onze Hackathon hier vinden: https://bit.ly/2K9Qwms. Wil je graag eens doorpraten over security met een van onze specialisten?