Stel je een potige portier voor op een exclusief feest. Wanneer iemand beweert gast te zijn, controleert de portier de uitnodiging en vergelijkt deze met de namen op de lijst. Als ze niet bij elkaar passen, komt de persoon niet door het fluwelen touw. Maar wat gebeurt er als de portier zijn werk niet doet? Zijn bedrog kan ertoe leiden dat mensen die aan het feest deelnemen hors d’oeuvres meenemen en waardevolle spullen stelen.
Natuurlijk is dit geen perfecte analogie, maar FTC-schikking waarbij kredietinformatiebedrijf Credit Karma en bioscoopkaartjessite Fandango de gevaren laten zien wanneer bedrijven de standaardinstellingen van het besturingssysteem negeren die zijn ontworpen om verbindingen te authenticeren en te beveiligen die worden gebruikt om gevoelige informatie te verzenden.
Zo werkt het zodra consumenten de app naar het apparaat downloaden. Denk aan Secure Sockets Layer (SSL), het industriestandaardprotocol voor het tot stand brengen van gecodeerde verbindingen, als poortwachter. Wanneer een online dienst verbinding wil maken met een applicatie, levert deze een SSL-certificaat om de identiteit ervan te garanderen. Zodra de applicatie het certificaat valideert, wordt de online dienst door het fluwelen touw toegelaten en wordt een gecodeerde verbinding met het apparaat tot stand gebracht, zodat consumenten informatie kunnen verzenden. Deze een-tweetje validatie via SSL-certificaten en encryptie 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 applicatie het SSL-certificaat niet controleert, kan een aanvaller een ongeldig certificaat gebruiken om actie te ondernemen en een verbinding tot stand te brengen om informatie te onderscheppen die tussen de applicatie en de online dienst wordt verzonden. Noch de persoon die de app gebruikte, noch de online dienst was op de hoogte van wat er gebeurde.
Het beveiligen van de overdracht van persoonlijke informatie tegen bedreigingen zoals man-in-the-middle-aanvallen is zo belangrijk dat iOS- en Android-besturingssystemen gebruiksvriendelijke application programming interfaces (API’s) bieden waarmee ontwikkelaars SSL kunnen implementeren. Standaard valideert deze API automatisch SSL-certificaten en weigert verbindingen als het certificaat ongeldig is.
Ontwikkelaarsdocumentatie voor de iOS- en Android-besturingssystemen gebruikt zeer krachtige taal om te waarschuwen voor het uitschakelen van dergelijke standaardvalidatie-instellingen. Volgens iOS-documentatie elimineert het niet valideren van een SSL-certificaat “elk voordeel dat u zou kunnen behalen door het gebruik van een beveiligde verbinding. De resulterende verbinding is niet veiliger dan het verzenden van verzoeken via niet-gecodeerde HTTP, omdat deze geen bescherming biedt tegen spoofing door vervalste servers.” De documentatie van Android neemt ook geen blad voor de mond: apps die SSL-certificaten niet valideren “versleutelen mogelijk ook de communicatie niet, omdat iedereen gebruikers op openbare Wi-Fi-hotspots zou kunnen aanvallen… (en) aanvallers zouden dan wachtwoorden en persoonlijke gegevens kunnen loggen.”
Volgens de FTC is Krediet Karma En Fandango negeer de waarschuwing ‘Ga daar niet heen’. Bij de ontwikkeling van zijn iOS-app, waarmee consumenten kredietscores kunnen krijgen en andere financiële gegevens kunnen controleren, stond Credit Karma dienstverleners toe code te gebruiken die de validatie van SSL-certificaten uitschakelt voor testdoeleinden. Maar de FTC zei dat Credit Karma zijn app op de markt heeft gebracht zonder de standaardinstellingen opnieuw in te schakelen. Tussen 18 juli 2012 en ongeveer 1 januari 2013 was de iOS-app van het bedrijf dus kwetsbaar voor man-in-the-middle-aanvallen, waarbij de burgerservicenummers, geboortedata en kredietrapportgegevens van gebruikers in gevaar kwamen.
Hoe kwam CreditKarma op de hoogte van dit probleem? Volgens de FTC niet via haar eigen interne inspecties en monitoring. De klacht beweert dat gebruikers contact hebben opgenomen met Credit Karma, dus hebben bedrijfstechnici de app in januari 2013 bijgewerkt om de standaardinstellingen te herstellen.
Maar dat is niet het einde van het Credit Karma-verhaal. Korte tijd later namen FTC-medewerkers 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 applicatie. Is het ingewikkeld, duur en tijdrovend? Nee. Volgens de FTC duurt het proces slechts een paar uur en kost het vrijwel niets. En raad eens wat er werd onthuld? In februari 2013 – na Credit Karma is op de hoogte gebracht van de iOS-kwetsbaarheid: het bedrijf lanceerde een Android-versie van zijn app met exact hetzelfde probleem. Uit de review kwam ook nog een ander beveiligingslek naar voren: de iOS-app sloeg authenticatietokens en toegangscodes op een onveilige manier op het apparaat op.
De rechtszaak van de FTC tegen Fandango beschuldigt het bedrijf van soortgelijke onregelmatigheden. Van maart 2009 tot maart 2013 slaagde de iOS-versie van de Fandango-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 verschillende audits uitgevoerd, ruim twee jaar nadat de app was uitgebracht. Dit beperkt echter de reikwijdte ervan en heeft alleen betrekking op bedreigingen die ontstaan wanneer een aanvaller fysieke toegang heeft tot een consumentenapparaat. Er wordt geen veilige gegevensoverdracht getest. Daarom heeft Fandango een kans gemist om de kwetsbaarheid te ontdekken die het had geïntroduceerd door de standaard te omzeilen.
De FTC zei dat Fandango dit probleem verergerde omdat het geen effectief kanaal had voor het publiek om veiligheidsproblemen te 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 negeert vervolgens de beveiligingswaarschuwing als ‘opgelost’.
Wanneer zal Fandango het probleem eindelijk oplossen? Volgens de klacht hoorde het bedrijf alleen iets van FTC-personeel. Pas toen voerde Fandango een eenvoudige test uit waaruit bleek dat de app het SSL-certificaat niet kon valideren. Fandango ontdekte ook dat de kwetsbaarheid een afzonderlijke applicatie voor bioscoopkaartjes trof die voor derden wordt gehost. Binnen drie weken bracht Fandango een update uit voor beide iOS-apps die de standaardinstellingen herstelden en daarmee het beveiligingslek dichtten.
De voorgestelde schikking met Credit Karma en Fandango vereist dat de bedrijven een alomvattend beveiligingsprogramma implementeren om de risico’s die gepaard gaan met het ontwikkelen en beheren 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 elke twee jaar een grondige beveiligingsaudit door een onafhankelijke professional vereisen. Natuurlijk zijn de voorwaarden van de overeenkomst alleen van toepassing op die bedrijven, maar slimme bedrijven zullen de voorgestelde volgorde willen lezen om te zien wat er van Credit Karma en Fandango wordt verlangd. U kunt vóór 28 april 2014 opmerkingen indienen over de voorgestelde schikking.
Wat kunnen bedrijven nog meer van deze cases leren?
1. Wees voorzichtig bij het wijzigen van de standaardbeveiligingsinstellingen. Als bedrijven aan hun lot waren overgelaten, zouden de beveiligingsnormen voor besturingssystemen de persoonlijke gegevens van consumenten hebben beschermd tegen man-in-the-middle-aanvallen. We zeggen natuurlijk niet dat het wijzigen van de standaardinstellingen altijd illegaal is. Er zijn zelfs verschillende manieren waarop u verder kunt gaan dan de standaard SSL-certificaatvalidatie door een sterkere authenticatiemethode te implementeren die bekend staat als ‘certificaat vastzetten’. Maar het veranderen van de standaardbeveiligingsinstellingen is een hersenoperatie bij de ontwikkeling van applicaties. 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.’ Gevolgen voor app-ontwikkelaars: Profiteer van de beschikbare gratis of goedkope methoden om de beveiliging van uw app te testen voor Je legt het in de handen van de consument.
3. Bedenk hoe mensen uw app zullen gebruiken. Er is een reden waarom SSL zo belangrijk is in mobiele omgevingen en waarom documentatie voor iOS- en Android-ontwikkelaars er veel waarde aan hecht: omdat mensen vaak mobiele apps gebruiken op onbeveiligde openbare Wi-Fi-netwerken. Net als schakers moeten ontwikkelaars verschillende zetten vooruit denken. Voordat u een app uitbrengt, moet u eerst nadenken over hoe mensen deze gaan gebruiken en hoe u deze gaat beveiligen, rekening houdend met praktische overwegingen.
4. U bent verantwoordelijk voor wat anderen in uw naam doen. Volgens de klacht stond Credit Karma dienstverleners toe het validatieproces van het SSL-certificaat uit te schakelen tijdens pre-releasetests, maar zorgde het er niet voor dat de beveiligingsinstellingen daarna werden hersteld. Eerste zorg: testen kan worden gedaan zonder de standaardinstelling uit te schakelen. Het is echter van cruciaal belang dat bedrijven ervoor zorgen dat alles weer in orde is voordat consumenten de app in handen krijgen.
5. Breng je oor naar de grond. Er is een actieve onderzoeksgemeenschap die informatie deelt over potentiële beveiligingsproblemen. Maar door op serieuze waarschuwingen te reageren met een standaard ‘bedwantsbrief’, miste Fandango een kans om het probleem op te lossen. Heb contact gehad met mensen met verstand van zaken de jouwe bedrijf onlangs over potentiële risico’s? En staat het bericht nog steeds in de e-mailbox zonder gelezen te worden?
6. Raadpleeg beschikbare bronnen. 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 applicatie dit goed controleert. Een eenvoudig digitaal certificaat van een gerenommeerde leverancier is goedkoop en helpt uw klanten ervoor te zorgen dat ze met uw server communiceren, en niet met die van iemand anders. Maar de normen veranderen, dus houd de nieuwste technologie in de gaten en zorg ervoor dat u de nieuwste en beste beveiligingsfuncties gebruikt.
Markeer de FTC Privacy- en beveiligingspagina en raadpleeg andere openbare bronnen voor gratis informatie over het ontwikkelen van veiligere applicaties.
