Stel je een potige portier voor op een exclusief feest. Wanneer iemand beweert een gast te zijn, controleert de portier de uitnodiging en vergelijkt deze met de namen op de lijst. Als het niet bij elkaar past, komt de persoon niet door het fluwelen touw. Maar wat gebeurt er als de portier zijn werk niet doet? Door zijn fout zou een beller in het gezelschap de hors d’oeuvres kunnen vergaren en de waardevolle spullen kunnen stelen.
Het is natuurlijk geen perfecte analogie, maar de FTC-schikkingen met kredietinformatiebedrijf Credit Karma en bioscoopkaartjessite Fandango demonstreren de gevaren wanneer bedrijven de standaardinstellingen van besturingssystemen omzeilen die zijn ontworpen om de verbindingen die worden gebruikt om gevoelige informatie te verzenden, te authenticeren en beveiligen.
Zo werken de zaken nadat een consument een app op een apparaat heeft gedownload. Denk als portier aan Secure Sockets Layer (SSL), het industriestandaardprotocol om gecodeerde verbindingen tot stand te brengen. Wanneer een online dienst verbinding wil maken met een app, presenteert de dienst een SSL-certificaat om de identiteit ervan te garanderen. Zodra de app het certificaat valideert, wordt de online dienst door het fluwelen touw toegelaten en wordt een gecodeerde verbinding met het apparaat tot stand gebracht, zodat de consument informatie kan verzenden. Deze een-tweetje validatie via een SSL-certificaat en codering creëert een veiligere manier voor mensen om gevoelige gegevens te verzenden.
Maar het is bekend dat fraudeurs spoofingtechnieken gebruiken om zogenaamde man-in-the-middle-aanvallen uit te voeren. Als de app het SSL-certificaat niet controleert, kan een aanvaller een ongeldig certificaat gebruiken om een voet tussen de deur te krijgen en een verbinding tot stand te brengen om informatie te onderscheppen die tussen de app en de online dienst wordt verzonden. Noch degene die de app gebruikt, noch de online dienst heeft door wat er aan de hand is.
Het beveiligen van de overdracht van persoonlijke informatie tegen bedreigingen zoals man-in-the-middle-aanvallen is zo belangrijk dat de iOS- en Android-besturingssystemen ontwikkelaars voorzien van eenvoudig te gebruiken application programming interfaces (API’s) om SSL te implementeren. Standaard valideren deze API’s SSL-certificaten automatisch en weigeren ze de verbinding als het certificaat ongeldig is.
De ontwikkelaarsdocumentatie voor zowel het iOS- als het Android-besturingssysteem gebruikt bijzonder krachtige taal om te waarschuwen voor het uitschakelen van deze standaardvalidatie-instellingen. Volgens de iOS-documentatie elimineert het niet valideren van SSL-certificaten “elk voordeel dat je anders zou hebben gehad door het gebruik van een beveiligde verbinding. De resulterende verbinding is niet veiliger dan het verzenden van het verzoek via niet-gecodeerde HTTP, omdat het geen bescherming biedt tegen spoofing door een nep-server.” De Android-documentatie neemt ook geen blad voor de mond: een app die SSL-certificaten niet valideert “kan net zo goed de communicatie niet coderen, omdat iedereen gebruikers op een openbare Wi-Fi-hotspot kan aanvallen… (en) de aanvaller kan dan wachtwoorden en persoonlijke gegevens vastleggen.”
Volgens de FTC is Krediet Karma En Fandango negeerde de waarschuwingen ‘Ga daar niet heen’. Tijdens de ontwikkeling van zijn iOS-app, waarmee consumenten hun kredietscores kunnen opvragen en andere financiële gegevens kunnen controleren, heeft Credit Karma een dienstverlener toestemming gegeven om code te gebruiken die de validatie van SSL-certificaten uitschakelde voor testdoeleinden. Maar de FTC zegt dat Credit Karma de app op de markt heeft gebracht zonder de standaardinstellingen weer in te schakelen. Dus tussen 18 juli 2012 en rond 1 januari 2013 was de iOS-app van het bedrijf kwetsbaar voor man-in-the-middle-aanvallen, waardoor de burgerservicenummers, geboortedata en kredietrapportgegevens van gebruikers in gevaar kwamen.
Hoe kwam CreditKarma op de hoogte van het probleem? Volgens de FTC niet via haar eigen interne controles en monitoring. De klacht beweert dat een gebruiker contact heeft opgenomen met Credit Karma, waardoor de technici van het bedrijf de app in januari 2013 hebben bijgewerkt om de standaardinstellingen te herstellen.
Maar dat is niet het einde van het Credit Karma-verhaal. Korte tijd later namen medewerkers van de FTC contact op met Credit Karma over het probleem. Pas daarna voerde het interne team van het bedrijf een beveiligingsbeoordeling uit op beide versies van de app. Was het ingewikkeld, duur en tijdrovend? Nee. Volgens de FTC duurde het slechts een paar uur en kostte het vrijwel niets. En raad eens wat het onthulde? In februari 2013 – na Credit Karma was op de hoogte gebracht van de iOS-kwetsbaarheid: het bedrijf lanceerde de Android-versie van zijn app met exact hetzelfde probleem. Uit de review kwam ook een ander beveiligingsprobleem naar voren: de iOS-app bewaarde authenticatietokens en toegangscodes op een onveilige manier op het apparaat.
De rechtszaak van de FTC tegen Fandango beschuldigt het bedrijf van soortgelijke fouten. Van maart 2009 tot maart 2013 slaagde de iOS-versie van Fandango’s app er niet in om SSL-certificaten te valideren, waardoor de standaardbeveiligingsinstellingen van het systeem werden overschreven. Volgens de FTC heeft Fandango de app niet vóór de release getest om er zeker van te zijn dat deze SSL-certificaten valideerde en de persoonlijke gegevens van consumenten veilig verzond, inclusief creditcardnummers, vervaldata en beveiligingscodes. Ja, Fandango heeft in 2011 een aantal audits laten uitvoeren, ruim twee jaar nadat de app was uitgebracht. Maar zelfs dan beperkte het de reikwijdte tot alleen bedreigingen die ontstonden wanneer de aanvaller fysieke toegang had tot het apparaat van een consument. Er is niet getest op veilige gegevensoverdracht. Fandango miste dus een kans om de kwetsbaarheid te ontdekken die het had geïntroduceerd door de standaardinstellingen te omzeilen.
De FTC zegt dat Fandango het probleem heeft verergerd door geen effectief kanaal te hebben waar mensen beveiligingsproblemen kunnen melden. Volgens de klacht nam een onderzoeker in december 2012 contact op met het bedrijf via de enige beschikbare methode: een webformulier van de klantenservice. Omdat het bericht van de onderzoeker de term ‘wachtwoord’ bevatte, behandelde het klantenservicesysteem van Fandango het als een routinematig verzoek om het wachtwoord opnieuw in te stellen en reageerde met een ingeblikt bericht. Het systeem deed de beveiligingswaarschuwing vervolgens af als ‘opgelost’.
Wanneer heeft Fandango het probleem eindelijk opgelost? Volgens de klacht gebeurde dit pas toen het bedrijf iets hoorde van FTC-personeel. Pas toen voerde Fandango de eenvoudige test uit waaruit bleek dat de app er niet in slaagde SSL-certificaten te valideren. Fandango ontdekte ook dat de kwetsbaarheid een aparte bioscoopkaartje-app trof die voor een derde partij werd gehost. Binnen drie weken bracht Fandango een update uit voor beide iOS-apps die de standaardinstellingen herstelden en daarmee het beveiligingslek dichtten.
De voorgestelde schikkingen met Credit Karma en Fandango vereisen dat de bedrijven uitgebreide beveiligingsprogramma’s opzetten om de risico’s in verband met de ontwikkeling en het beheer van nieuwe en bestaande producten aan te pakken en om de veiligheid, integriteit en vertrouwelijkheid van de informatie waarop het bevel betrekking heeft te beschermen. In overeenstemming met andere schikkingen zullen Credit Karma en Fandango de komende twintig jaar om de twee jaar een grondige veiligheidsaudit van een onafhankelijke professional nodig hebben. Natuurlijk gelden de voorwaarden van de overeenkomsten alleen voor die bedrijven, maar slimme bedrijven zullen de voorgestelde orders willen lezen om te zien wat er van Credit Karma en Fandango wordt verlangd. U kunt vóór 28 april 2014 een opmerking indienen over de voorgestelde schikking.
Wat kunnen bedrijven nog meer van deze cases leren?
1. Wees uiterst voorzichtig bij het wijzigen van de standaardbeveiligingsinstellingen. Als de bedrijven goed genoeg met rust waren gebleven, zouden de standaardbeveiligingsproblemen van de besturingssystemen de persoonlijke gegevens van consumenten hebben beschermd tegen man-in-the-middle-aanvallen. We zeggen natuurlijk niet dat het altijd illegaal is om een standaardinstelling te wijzigen. Er zijn zelfs manieren waarop u verder kunt gaan dan de standaard SSL-certificaatvalidatie door een nog sterkere authenticatiemethode te implementeren die bekend staat als ‘certificaat vastzetten’. Maar het wijzigen van de standaardbeveiligingsinstellingen is de hersenoperatie van app-ontwikkeling. Bedrijven moeten er zeker van zijn dat ze weten wat ze doen.
2. Test uw app grondig voordat u deze uitbrengt. Timmerlieden hebben een oud gezegde: ‘Twee keer meten, één keer zagen.’ Het gevolg voor app-ontwikkelaars: profiteer van direct beschikbare gratis of goedkope methoden om de beveiliging van uw apps te testen voor je legt ze in de handen van de consument.
3. Bedenk hoe mensen uw apps zullen gebruiken. Er is een reden waarom SSL zo belangrijk is in de mobiele omgeving en waarom de iOS- en Android-ontwikkelaarsdocumentatie er zoveel aandacht aan besteedt: omdat mensen vaak mobiele apps gebruiken op onbeveiligde openbare Wi-Fi-netwerken. Net als schakers moeten ontwikkelaars een paar zetten vooruit denken. Voordat u een app uitbrengt, moet u bedenken hoe mensen deze waarschijnlijk zullen gebruiken en deze beveiligen met die praktijkoverwegingen in gedachten.
4. U bent verantwoordelijk voor wat anderen namens u doen. Volgens de klacht heeft Credit Karma een serviceprovider toestemming gegeven om het validatieproces van het SSL-certificaat uit te schakelen tijdens pre-releasetests, maar heeft er niet voor gezorgd dat de beveiligingsinstellingen daarna zijn hersteld. De eerste zorg: het testen had kunnen worden uitgevoerd zonder de standaardinstellingen uit te schakelen. Maar toch is het van cruciaal belang dat bedrijven ervoor zorgen dat alles weer in orde is voordat consumenten de app krijgen.
5. Houd je oor op de grond. Er is een actieve onderzoeksgemeenschap die informatie deelt over potentiële beveiligingsproblemen. Maar door op een serieuze waarschuwing te reageren met een standaard ‘bedwantsbrief’, miste Fandango de kans om de problemen op te lossen. Er is contact opgenomen met een deskundig persoon jouw bedrijf onlangs over een potentieel risico? En blijft dat bericht ongelezen in een e-mailbox liggen?
6. Raadpleeg beschikbare bronnen. De FTC-brochure, Ontwikkelaars van mobiele apps: begin met beveiligingbiedt advies voor bedrijven over de bescherming tegen dit soort kwetsbaarheden:
Om gebruikers te beschermen, implementeren ontwikkelaars vaak SSL/TLS in de vorm van HTTPS. Overweeg het gebruik van HTTPS of een andere industriestandaardmethode. Het is niet nodig om het wiel opnieuw uit te vinden. Als u HTTPS gebruikt, gebruik dan een digitaal certificaat en zorg ervoor dat uw app dit goed controleert. Een eenvoudig digitaal certificaat van een gerenommeerde leverancier is goedkoop en helpt uw klanten ervoor te zorgen dat ze met uw servers communiceren, en niet die van iemand anders. Maar normen veranderen, dus houd de huidige technologieën in de gaten en zorg ervoor dat u de nieuwste en beste beveiligingsfuncties gebruikt.
Maak een bladwijzer van de FTC’s Privacy- en beveiligingspagina en raadpleeg andere openbare bronnen voor gratis informatie over het ontwikkelen van veiligere apps.
