Veelgebruikte Android-apps kunnen gegevens lekken door ssl-gaten

Enkele veelgebruikte Android-apps zijn vatbaar voor man-in-the-middle-aanvallen bij een ssl-verbinding. Dat concluderen Duitse onderzoekers uit eigen research. Bovendien blijken apps als Facebook en Gmail vatbaar voor aanvallen via geldige, maar verkeerde ssl-certificaten.

De onderzoekers noemen geen enkele app bij naam, maar de drie grootste apps met grote gaten in de beveiliging hebben tussen 30 en 150 miljoen gebruikers, zo vermelden de onderzoekers van de Leibniz Universiteit in Hannover in hun paper. De gevolgen kunnen verstrekkend zijn: via een man-in-the-middle-aanval kunnen gegevens als Facebook-logins, creditcardgegevens en het adresboek van de gebruiker worden onderschept.

De gaten zitten in de implementatie van ssl; zo checken sommige apps de ssl-certificaten niet, waardoor ook ssl-certificaten die door de onderzoekers zijn ondertekend geaccepteerd worden. Ssl-certificaten horen alleen vertrouwd te worden als ze door een Certifcate Authority ondertekend zijn.

Naast de gaten in de ssl-beveiliging bleken ook weinig apps 'ssl-pinning' te ondersteunen. Met ssl-pinning accepteert de app alleen een door de ontwikkelaar goedgekeurd certificaat voor ssl. Dat kan, omdat een app vaak maar met een of enkele beveiligde servers communiceert en bijvoorbeeld een Dropbox-app een geldig certificaat voor Gmail niet hoeft te accepteren.

Door het ontbreken van ssl-pinning blijven apps vatbaar als een man-in-the-middle-aanval uitgevoerd wordt met een geldig, maar verkeerd certificaat. Dit kleinere beveiligingsgat had onder meer geëxploiteerd kunnen worden na een hack als die bij bij certificaatautoriteit Diginotar vorig jaar.

Alleen Twitter heeft ssl-pinning, onder meer Facebook en alle apps van Google zoals Play Store en Gmail ondersteunen dat niet. Ook Dropbox, Foursquare en Hotmail hebben geen support voor ssl-pinning. Het beveiligingsgat is kleiner dan de andere, omdat bijvoorbeeld browsers ssl-pinning niet kunnen ondersteunen: de gebruiker moet daarop kunnen inloggen op veel verschillende diensten.

In totaal bleken van de 13.000 onderzochte apps ongeveer 1000 een ssl-beveiligingsgat te hebben. Daarvan hebben de onderzoekers er honderd handmatig verder onderzocht. Er komt volgens geruchten betere beveiliging in Android 4.2, al zullen de lekken in apps daarmee niet worden aangepakt. De onderzoekers hebben hun onderzoek gericht op Android, omdat het onderzoek daarop makkelijker gaat dan op bijvoorbeeld iOS of Windows Phone. Bovendien draaien de meeste smartphones momenteel op Googles mobiele platform.

Reacties (33)

En hoe zit dit bij de concurrenten dan? Windows phone en ios? is het makkelijk automatisch toe te voegen door Google of zijn het de ontwikkelaars die dit beter moeten doen?

En hoe zit dit bij de concurrenten dan? Windows phone en ios? is het makkelijk automatisch toe te voegen door Google of zijn het de ontwikkelaars die dit beter moeten doen?

ik zal eens kijken of ik 't op iOS kan reproduceren, ik vermoed eigelijk van wel. (zelfde dev team per slot van rekening voor de facebook en gmail apps)

Google moet het voor haar eigen apps (gmail, google play) toevoegen. Maar dat geld ook voor de individuele ontwikkelaars van Facebook, etc, etc.

Het zijn de ontwikkelaars die dit beter moeten doen. De makers van de diverse Apps zouden hun beveiliging beter op orde kunnen hebben. Google is daar ook één van overigens.

Het is geen fout van Android ansich, dus Google kan het niet achteraf automatisch toevoegen.

Ik vind de kop daarom niet correct en zelfs wat suggestief. Het is getest op Android, waarschijnlijk omdat de onderzoekers daar eenvoudig snel hun testtooltjes op konden laden. Maar als bijvoorbeeld een Dropbox problemen heeft op Android, dan zit er een redelijke kans in dat het probleem net zo groot is op iOS en WP.

Dit is niet Android specifiek. Check op IOS maar eens volgende apps:

Binck
ICS Cards
Paypal
E-Bay

Allemaal vatbaar voor mitm via ongeldige certificaten

Dit is niet eens zozeer een beveiligingslek. Het maakt de app net zo veilig als dat een browser een beveiligde verbinding opzet. Het had alleen makkelijker nog veiliger gekund (via dat ssl-pinning dus).

Klopt en daarom staat het ook niet bovenaan in het artikel

Het was ook niet bedoeld als enige kritiek op het artikel. Eerder voor de mensen die de stof minder begrijpen / het artikel maar half lezen.

(Edit: Dat ikzelf het artikel maar half lees, en dat er wel degelijk een probleem is met apps die de certificaten niet goed controleren daargelaten...)

[Reactie gewijzigd door Oerdond3r op 22 oktober 2012 14:39]

Je browser geeft dan een melding dat het certificaat niet bij de URL past of niet geldig is. De apps doen dit niet en gaan gewoon verder, DUS is de app minder veilig dan de browser

Fout: (Edit: Je hebt gelijk. Eigenlijk las ik het artikel niet goed waarin staat dat veel apps dit inderdaad niet doen) Net als bij het Diginotar incident kon men bij een man in the middle aanval certificaten voor elk URL vervalsen. De browser zag dan dat Diginotar deze uitgegeven had en gaf geen enkele melding.

SLL pinning is nog veiliger omdat de app dan maar één certificaat vertrouwd, en dat is die van zijn provider. Hier komt dan geen Certificate Authority aan te pas.

[Reactie gewijzigd door Oerdond3r op 22 oktober 2012 14:26]

De onderzoekers hebben hun onderzoek gericht op Android, omdat het onderzoek daarop makkelijker gaat dan op bijvoorbeeld iOS of Windows Phone.

Waarom zou dit makkelijker zijn?
Voor een man in the middle moet je alleen ergens tussen de verbinding zitten op het netwerk, dat heeft niks met het apparaat te maken, kan net zo goed een koelkast of magnetron zijn.

Ja maar om resultaten op het apparaat te zien of om dingen on the go aan te passen werkt android, met zijn openheid, waarschijnlijk toch iets beter

Waarom zou dit makkelijker zijn?

Volgens het artikel hebben de onderzoekers zich gericht op Andriod omdat er nog niet een dergelijk onderzoek is gedaan bij Andriod. Daartoe hebben ze Mallodriod App ontwikkeld die gebouwd is op Androguard.
Kortom mogelijkerwijs hebben praktische redenen een rol gespeeld bij de keuze voor OS-omgeving, maar dat is (volgens mij) niet expliciet gemaakt.

Kwa oplossingen stellen de auteurs dat er meerdere alternatieven zijn en dat alleen een stand-alone oplossing geen aanpassing van het OS vereist. Mallodriod App icm Androguard is een standalone oplossing.

Ik vraag mij dan toch altijd af waarom ze niet eerst even alle appmakers een mailtje sturen met desbetreffende info en dan nog een maandje wachten met publiceren. Nu lichten de goeden naar mijn idee onbedoeld de slechte in over nieuwe hackmethodes etc. Is zo'n onderzoek publiceren terwijl het nog mogelijk is om te gebruiken meer waard in wetenschappelijke zin?
Edit: De link naar de paper is trouwens dood.

[Reactie gewijzigd door BombaAriba op 22 oktober 2012 10:35]

Hoewel dat niet genoemd is, zal dat waarschijnlijk wel het geval zijn geweest. Echter, door het bericht te publiceren (en dus het nieuws te halen), bouw je druk op voor het bedrijf om het probleem op te lossen. Gebeurd wel vaker .

Hoewel dat niet genoemd is, zal dat waarschijnlijk wel het geval zijn geweest. Echter, door het bericht te publiceren (en dus het nieuws te halen), bouw je druk op voor het bedrijf om het probleem op te lossen. Gebeurd wel vaker .

vooral als het bedrijf in kwestie niet reageert, of beloftes maakt en vervolgens de deadlines niet nakomt. Beide situaties komen helaas maar al te vaak voor.

Zolang ze maar blijven toestaan om self-signed certificaten te blijven accepteren na een waarschuwing.

Idd. Ik vind

Ssl-certificaten horen alleen vertrouwd te worden als ze door een Certifcate Authority ondertekend zijn.

dan ook niet terecht. Je wilt natuurlijk niet voor elke ssl-verbinding een certificaat waarschuwing, dus daar zijn die authorities handig bij. Maar als je een self-signed cert gebruikt, zoals ik op mijn eigen (mail)server, dan wil ik zelf beslissen of ik dat certificaat vetrouw of niet. Dus niet standaard blokkeren omdat die self-signed is. Als ik maar weer een waarschuwing krijg als het certificaat is veranderd.

Dan compile je toch je eigen applicatie, zodat-ie jouw certificaat vertrouwt?

Whehe dit had ik zelf ook al geconcludeerd, zie de programmatjes dSploit en Faceniff hehe, kan je vanaf je android mitm attacks doen op andere androids, maar ook op iOS (vooral die Faceniff lijkt meer iOS te detecteren dan android, die dSploit kan meer maar is nog vroeg in development en vind vrij weinig)

[Reactie gewijzigd door 434365 op 22 oktober 2012 10:52]

Hoe werkt dat dan? In android kun je gebruik maken van de HttpsURLConnection die voor zover ik weet alles afhandeld. Maken die 1000 applicaties gewoon geen gebruik van HttpsURLConnection of is de fout juist dat zij er ook vanuit gaan dat die klasse alles veilig afhandelt.

Is het niet gewoon zo dat DNSSec bij de 'leverancier' (E.G. https facebook) dit meteen tackelt?
Of denk ik dan te makkelijk..

Lijkt me i.i.g. geen issue van Android itself. Ik ga ff Googlen op SSL pinning

EDIT: hier een duidelijk verhaal over SSL pinning:
http://blog.lumberlabs.co...rs-should-care-about.html

[Reactie gewijzigd door sjongenelen op 22 oktober 2012 12:05]

voor aanvallen via geldige, maar verkeerde ssl-certificaten

Mooie woordkeus. Als ze geldig zijn, kunnen ze toch verkeerd zijn.

Er komt volgens geruchten betere beveiliging in Android 4.2, al zullen de lekken in apps daarmee niet worden aangepakt.

De google apps wel toch, mag ik aannemen??

Het probleem hier is denk ik dat sommige app developers lui zijn en in plaats van een SSL certificaat goed te controleren, wel HttpsURLConnection gebruiken maar gewoon alle certificaten automatisch doorlaten omdat het te veel moeite kost om het wel goed te verifieeren.

Met een self-signed certificaat lijkt me trouwens niks mis in de context van een applicatie, omdat de applicatie de public key van de server ingebouwd kan hebben voor controle.

[Reactie gewijzigd door Overv op 22 oktober 2012 13:10]