Android en iOS apps kwetsbaar voor man-in-the-middle aanval op SSL

Eind juli ontdekte ik een kwetsbaarheid in de wijze waarop een aantal Android apps een SSL verbinding opzetten. Het beveiligingscertificaat werd niet (goed) geverifieerd, waardoor een man-in-the-middle aanval op SSL relatief makkelijk kan worden uitgevoerd. Benieuwd of ik nog meer kwetsbare apps kon ontdekken, nam ik een aantal steekproeven onder (voor mij) bekende Android en iOS apps en stopte ik met 9 apps van 8 leveranciers op de teller. Middels een responsible disclosure heb ik de desbetreffende leveranciers geïnformeerd en ze ruimschoots de gelegenheid gegeven om de kwetsbaarheden te verhelpen.

De weken na mijn oorspronkelijke ontdekking (eind juli) was een interessante periode. Niet alleen vanwege het contact dat ik had met de verschillende leveranciers, maar ook omdat gedurende deze periode bleek dat dit certificaat-lek enorm van omvang is. Zo werd op 18 augustus bekend dat Microsoft een dergelijke kwetsbaarheid in haar Outlook app had verholpen, nadat Securify deze op 27 maart had gemeld. Mijn vermoeden dat ik mogelijk op het topje van de ijsberg was gestuit, werd twee dagen later op 20 augustus bevestigd toen het Amerikaanse FireEye bekend maakte dat 448 van de 1000 (meest populaire en gratis) geteste Android apps het SSL certificaat niet verifiëren. En zo volgenden er nog meer berichten omtrent dit certificaat debacle.

Kwetsbare apps en één false positive

De onderstaande tabel verklapt bij welke apps ik succesvol een man-in-the-middle aanval op SSL heb kunnen uitvoeren. Twee leveranciers hebben expliciet verzocht om anoniem te blijven, en ik heb besloten hier gehoor aan te geven. D-Link Benelux gaf na initieel contact (begin augustus) aan de bevinding te escaleren naar het hoofdkantoor in Taiwan, beloofde vervolgens e.e.a. te fixen in de release van oktober, maar heeft daarna op geen enkel verzoek om een statusupdate gereageerd. Ik heb vlak voor publicatie van dit bericht (26-11-2014) de meest recente versies (iOS v3.4.0 en Android v3.4.2) nogmaals getest, en geconstateerd dat beide versies nog steeds kwetsbaar zijn.

Ook noemenswaardig is de bevinding inzake de app Mobile@Work van MobileIron. Deze app wordt gebruikt om een smartphone te koppelen aan het bedrijfsnetwerk voor bijvoorbeeld zakelijke e-mail. Het is eigenlijk een beveiligde container waarbinnen andere apps geïnstalleerd kunnen worden. Een van deze apps luistert naar de naam E-mail+ en wordt door MobileIron aangeboden om verbinding te maken met een Exchange server. Ondanks het feit dat het vervalste certificaat probleemloos werd geaccepteerd en daarmee de basic authentication base64 encoded string kon worden onderschept, bleek het niet te gaan om een kwetsbaarheid in de app. De boosdoener was een foutieve configuratie. De zogenaamde MobileIron server kent namelijk een optie “accept all SSL certificates” waarmee de clients worden geïnstrueerd elk willekeurig certificaat te accepteren. Het bestaan van deze configuratieoptie is me nooit helemaal duidelijk geworden, maar ik adviseer de beheerders van dergelijke omgevingen om hier een controle op uit te voeren. Blijkbaar kan dit onopgemerkt blijven gedurende het implementatietraject.

Met uitzondering van De Telegraaf en een van de anonieme apps, kan een aanvaller de gebruikersnaam en het wachtwoord als gevolg van de kwetsbaarheid relatief gemakkelijk onderscheppen. In een aantal gevallen kan hiermee toegang worden verkregen tot meer vertrouwelijke gegevens in de app. Ook kunnen de onderschepte gebruikersnaam en wachtwoord elders bruikbaar zijn als gevolg van hergebruik. Het daadwerkelijke risico is dus niet alleen afhankelijk van de gegevens die kunnen worden onderschept, maar bijvoorbeeld ook van gebruikersgewoonten in relatie tot Wi-Fi netwerken en wachtwoorden. Het niet verbinden met openbare Wi-Fi netwerken en het niet/beperkt hergebruiken van wachtwoorden kan een lager risico tot gevolg hebben.

Had relatief gemakkelijk voorkomen kunnen worden

Wat ik opvalland vind is dat bij slechts één leverancier deze kwetsbaarheid aanwezig was in zowel de Android app als de iOS app. Of anders gezegd: bij de meeste leveranciers is deze kwetsbaarheid in slechts één platform aanwezig. Mijn test is qua omvang te klein om hier meteen harde conclusies aan te verbinden, maar het zou me niet verbazen wanneer dit te maken heeft met het feit dat voor ieder platform veelal een apart (intern of extern) ontwikkelteam is aangesteld.

Ook al is het vrij logisch dat ontwikkelteams kwalitatief van elkaar verschillen, betreft het hier wel een fout die eigenlijk niet gemaakt had mogen worden. Het valideren van SSL certificaten is nou niet bepaald nieuw; dit is al jaren de best practice en iets wat ontwikkelaars dienen te weten. Zeker wanneer je bedenkt dat zowel Android en Apple deze fout bestempelen als “common mistake” in hun Developer Libraries. En mocht een ontwikkelaar op dit vlak dan toch een steek laten vallen, dan hoop je dat goede uniforme testprocedures een vangnet vormen waarmee deze kwetsbaarheid ontdekt had kunnen worden. Echter, gezien de omvang van deze kwetsbaarheid denk ik dat deze non-functional bij veel leveranciers überhaupt niet wordt (of hopelijk werd) getest.

Afbeelding van Hack-ed.com.