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 voorbij het fluwelen touw. Maar wat gebeurt er als de portier zijn werk niet doet? Door uw nalatigheid kan iemand het feest binnenkomen om de hapjes te verslinden en de waardevolle spullen te stelen.
Het is natuurlijk geen perfecte analogie, maar de FTC-schikkingen met kredietinformatiebureau Credit Karma en bioscoopkaartjessite Fandango demonstreren de gevaren wanneer bedrijven de standaardinstellingen negeren van besturingssystemen die zijn ontworpen om verbindingen te authenticeren en te beveiligen die worden gebruikt om gevoelige informatie te verzenden.
Zo werken de zaken nadat een consument een app op een apparaat heeft gedownload. Denk aan Secure Sockets Layer (SSL), het industriestandaardprotocol voor het tot stand brengen van gecodeerde verbindingen, als portier. 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 dubbele validatiecontrole via een SSL-certificaat en encryptie zorgt voor een veiligere manier om gevoelige gegevens te verzenden.
Maar het is bekend dat oplichters 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 verbinding tot stand te brengen en informatie te onderscheppen die tussen de app en de online dienst wordt verzonden. Noch de persoon die de app gebruikt, noch de online dienst heeft door wat er gebeurt.
Het beschermen 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 de standaardvalidatie-instellingen. Volgens iOS-documentatie elimineert het niet valideren van SSL-certificaten “elk voordeel dat je anders zou kunnen behalen 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.” Android-documentatie neemt ook geen blad voor de mond: een app die SSL-certificaten niet valideert “kan net zo goed de communicatie niet versleutelen, omdat iedereen gebruikers op een openbare Wi-Fi-hotspot kan aanvallen… (e) 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 volgen, 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 opnieuw in te schakelen. Daarom was de iOS-app van het bedrijf tussen 18 juli 2012 en ongeveer 1 januari 2013 kwetsbaar voor man-in-the-middle-aanvallen, waardoor de burgerservicenummers, geboortedata en kredietrapportgegevens van gebruikers in gevaar kwamen.
Hoe heeft CreditKarma van het probleem gehoord? 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 dit is niet het einde van het Credit Karma-verhaal. Korte tijd later namen medewerkers van de FTC contact op met Credit Karma over de kwestie. Pas daarna voerde het interne team van het bedrijf een veiligheidscontrole uit op beide versies van de app. Was het ingewikkeld, duur en tijdrovend? Nee. Volgens de FTC duurde het maar een paar uur en kostte het bijna niets. En raad eens wat hij 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 onveilige wijze 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 de Fandango-app er niet in om SSL-certificaten te valideren, waarbij de standaardbeveiligingsinstellingen van het systeem werden omzeild. Volgens de FTC heeft Fandango zijn 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 toen werd de reikwijdte beperkt tot alleen bedreigingen die ontstonden wanneer de aanvaller fysieke toegang had tot het apparaat van een consument. Er is geen veilige gegevensoverdracht getest. Daarom miste Fandango de kans om de kwetsbaarheid te detecteren die was geïntroduceerd door de standaardinstellingen te overschrijven.
De FTC zegt dat Fandango het probleem heeft verergerd door geen effectief kanaal te hebben waarlangs mensen veiligheidsproblemen kunnen melden. Volgens de klacht nam een onderzoeker in december 2012 contact op met het bedrijf via de enige beschikbare methode: een webformulier voor de klantenservice. Omdat het bericht van de onderzoeker de term ‘wachtwoord’ bevatte, behandelde het klantenservicesysteem van Fandango dit als een routinematig verzoek om het wachtwoord opnieuw in te stellen en reageerde met een standaardbericht. Het systeem heeft de beveiligingswaarschuwing vervolgens afgewezen als ‘opgelost’.
Wanneer heeft Fandango het probleem eindelijk opgelost? Volgens de klacht gebeurde dit alleen toen het bedrijf met FTC-personeel sprak. 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 afzonderlijke app voor bioscoopkaartjes trof die namens een derde partij werd gehost. Binnen drie weken bracht Fandango een update uit voor beide iOS-apps, waarbij de standaardinstellingen werden hersteld en daarmee het beveiligingslek werd gedicht.
De voorgestelde overeenkomsten met Credit Karma en Fandango vereisen dat de bedrijven uitgebreide beveiligingsprogramma’s opzetten om de risico’s die gepaard gaan met de ontwikkeling en exploitatie van nieuwe en bestaande producten aan te pakken en om de veiligheid, integriteit en vertrouwelijkheid van de informatie waarop de order betrekking heeft te beschermen. In overeenstemming met andere overeenkomsten zullen Credit Karma en Fandango de komende twintig jaar om de twee jaar uitgebreide beveiligingsaudits door een onafhankelijke professional vereisen. Natuurlijk zijn de voorwaarden van de overeenkomsten alleen van toepassing op die bedrijven, maar slimme bedrijven zullen de voorgestelde orders willen lezen om te zien wat er van Credit Karma en Fandango wordt verlangd. Commentaar op de voorgestelde overeenkomsten kan uiterlijk 28 april 2014 worden ingediend.
Wat kunnen bedrijven nog meer van deze cases leren?
1. Wees uiterst voorzichtig bij het wijzigen van de standaardbeveiligingsinstellingen. Als bedrijven voldoende met rust zouden worden gelaten, zouden de beveiligingsinstellingen van het besturingssysteem de persoonlijke gegevens van consumenten beschermen 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 het valideren van het standaard SSL-certificaat door een nog krachtigere authenticatiemethode te implementeren die bekend staat als ‘certificaatvergrendeling’. Maar het wijzigen van de standaardbeveiligingsinstellingen is een hersenoperatie bij het ontwikkelen van apps. Bedrijven moeten er absoluut zeker van zijn dat ze weten wat ze doen.
2. Test uw app zorgvuldig 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 veiligheid 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 documentatie voor iOS- en Android-ontwikkelaars zo belangrijk is: omdat mensen vaak mobiele apps gebruiken op onbeveiligde openbare Wi-Fi-netwerken. Net als schakers moeten ontwikkelaars van tevoren over enkele zetten nadenken. Voordat u een app uitbrengt, moet u bedenken hoe mensen deze waarschijnlijk zullen gebruiken en deze beschermen met deze praktijkoverwegingen in gedachten.
4. U bent verantwoordelijk voor wat anderen namens u doen. Volgens de klacht heeft Credit Karma een dienstverlener toestemming gegeven om het validatieproces van het SSL-certificaat uit te schakelen tijdens pre-releasetests, maar heeft het er niet voor gezorgd dat de beveiligingsinstellingen daarna opnieuw zijn ingesteld. De eerste zorg: de tests hadden 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 ontvangen.
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 klassieke ‘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 dat bericht blijft ongelezen in een e-mailinbox liggen?
6. Raadpleeg beschikbare bronnen. De FTC-brochure, Ontwikkelaars van mobiele apps: begin met beveiligingbiedt advies aan 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 correct controleert. Een eenvoudig digitaal certificaat van een vertrouwde provider is goedkoop en zorgt ervoor dat uw klanten met uw servers communiceren en niet met die van iemand anders. Maar de 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 Privacy- en beveiligingspagina en raadpleeg andere openbare bronnen voor gratis informatie over het ontwikkelen van veiligere apps.
