Stel je een krachtige 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 overlijden zou een leider de partij kunnen betreden om de hors d’oeuvres aan te kleden en de waardevolle spullen te stelen.
Het is natuurlijk geen perfecte analogie, maar FTC-schikkingen met kredietrapportagebedrijf Credit Karma en bioscoopkaartjessite Fandango demonstreren de gevaren wanneer bedrijven de standaardinstellingen van het besturingssysteem omzeilen die zijn ontworpen om de verbindingen die worden gebruikt om gevoelige informatie over te dragen, te authenticeren en beveiligen.
Hier leest u hoe het werkt nadat een consument een app naar een apparaat heeft gedownload. Denk als portier aan Secure Sockets Layer (SSL), het industriestandaardprotocol voor het tot stand brengen van gecodeerde verbindingen. Wanneer een online dienst verbinding wil maken met een app, presenteert de dienst een SSL-certificaat om de identiteit ervan te garanderen. Wanneer de app het certificaat valideert, wordt de online dienst via het fluwelen touw geautoriseerd 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.
Het is echter 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 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 de persoon die de app gebruikt, noch de online dienst weet 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 tegen het uitschakelen van deze standaardvalidatie-instellingen. Volgens de iOS-documentatie elimineert het niet valideren van SSL-certificaten elk voordeel dat u anders zou hebben behaald door het gebruik van een beveiligde verbinding. De resulterende verbinding is niet veiliger dan het verzenden van het verzoek via niet-versleutelde HTTP, omdat deze geen bescherming biedt tegen spoofing door een nepserver. De 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 … (en) de aanvaller kan dan wachtwoorden en persoonlijke gegevens vastleggen.”
Volgens de FTC is Krediet Karma En Fandango negeerde deze waarschuwingen “Ga daar niet heen”. Terwijl Credit Karma zijn iOS-app aan het ontwikkelen was, waarmee consumenten hun kredietscores kunnen opvragen en andere financiële gegevens kunnen controleren, gaf Credit Karma een dienstverlener toestemming 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. Tussen 18 juli 2012 en ongeveer 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 heeft CreditKarma het probleem ontdekt? Volgens de FTC niet via haar eigen interne controles en monitoring. De klacht beweert dat een gebruiker contact heeft opgenomen met Credit Karma, wat ertoe heeft geleid dat 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 de kwestie. 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 maar 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 nog een ander beveiligingslek naar voren: de iOS-app bewaarde authenticatietokens en wachtwoorden op een onveilige manier op het toestel.
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, wat in strijd was met de beveiligingsnormen van het systeem. 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 enkele herzieningen laten uitvoeren, ruim twee jaar nadat de app was uitgebracht. Maar zelfs toen beperkte het de reikwijdte tot alleen bedreigingen die werden gemaakt toen 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 overschrijven.
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 voor 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 bericht. Het systeem deed de beveiligingswaarschuwing vervolgens af als “opgelost”.
Wanneer heeft Fandango het probleem eindelijk opgelost? Volgens de klacht gebeurde dat pas toen het bedrijf hoorde van FTC-functionarissen. Pas toen voerde Fandango de eenvoudige test uit waaruit bleek dat de app geen SSL-certificaten kon valideren. Fandango ontdekte ook dat de kwetsbaarheid een afzonderlijke app voor bioscoopkaartjes 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 implementeren 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. Op grond van andere schikkingen zullen Credit Karma en Fandango de komende twintig jaar elke twee jaar een veiligheidsaudit door een onafhankelijke professional eisen. 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. U kunt uiterlijk 28 april 2014 een reactie op de voorgestelde schikking indienen.
Wat kunnen bedrijven nog meer van deze cases leren?
1. Wees uiterst voorzichtig bij het wijzigen van beveiligingsnormen. Als de bedrijven goed genoeg met rust waren gelaten, zouden de beveiligingsnormen van de besturingssystemen de persoonlijke informatie 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 veranderen van de beveiligingsnormen is de hersenoperatie van app-ontwikkeling. Bedrijven moeten er absoluut 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 knippen.’ De implicatie 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 de iOS- en Android-ontwikkelaarsdocumentatie er zo veel aandacht aan besteedt: omdat mensen vaak mobiele apps gebruiken op onbeveiligde openbare Wi-Fi-netwerken. Net als schakers moeten ontwikkelaars een paar stappen vooruit denken. Voordat u een app uitbrengt, moet u bedenken hoe mensen deze waarschijnlijk zullen gebruiken en deze beveiligen 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 zij er niet voor gezorgd dat de beveiligingsinstellingen daarna werden hersteld. De eerste zorg: de test had kunnen worden uitgevoerd zonder de standaardinstellingen uit te schakelen. Maar toch is het uiterst belangrijk 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 een kans om de problemen op te lossen. Er is contact opgenomen met een deskundig persoon jouw heeft het bedrijf onlangs over een potentieel risico gesproken? En blijft dat bericht ongelezen wegkwijnen in een e-mailinbox?
6. Bekijk beschikbare bronnen. de FTC-brochure, Ontwikkelaars van mobiele apps: begin met beveiligingbiedt advies aan bedrijven over 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 gerenommeerde leverancier is goedkoop en helpt uw klanten ervoor te zorgen dat ze met uw servers communiceren en niet met die van iemand anders. Maar de normen veranderen, dus blijf op de hoogte van de huidige technologieën 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.
