image

'Permissiemodel achilleshiel Android' (interview)

zaterdag 26 mei 2012, 23:30 door Redactie, 4 reacties

Bedrijven die hun werknemers een Android-telefoon laten gebruiken, kunnen er beter voor zorgen dat ze er twee hebben. Dat zegt Georgia Weidman van Bulb Security in een interview met Security.nl. Weidman sprak tijdens Hack in the Box Amsterdam over apps die het Android permissiemodel weten te omzeilen door permissies van andere apps te gebruiken..

Waarom heb je ervoor gekozen om je in Android te specialiseren?
Weidman: Android is het leukste en meest gebruiksvriendelijke platform voor gebruikers en zal hierdoor uiteindelijk het populairste platform worden. Hetzelfde geldt voor ontwikkelaars, het is het eenvoudigste platform om voor te ontwikkelen. Met name als je nog niet zoveel ervaring hebt. Het is eenvoudiger om Android op te pikken en leuke dingen te ontwikkelen dan bij de andere platformen. Het is echter ook het meest onveilige platform, wat altijd leuk voor beveiligingsonderzoekers is.

Wat maakt het zo onveilig?
Weidman: Het beveiligingsmodel van Android is gebaseerd op bewustzijn van de gebruiker. En we weten allemaal hoe dat werkt. Daarnaast kan iedereen zijn eigen Android maken, is het update-proces erg traag. Je ziet dat mensen lange tijd hun toestel niet kunnen patchen ook al is er een lek bekend. Als je dan niet kwetsbaar wilt zijn moet je een nieuwe telefoon kopen of stoppen met het surfen op internet en installeren van apps. Maar daar gebruiken we juist onze telefoon voor.

Wat is op dit moment het grootste probleem waar Android mee te maken heeft?
Weidman: Ik denk dat het permissiemodel fantastisch is, maar uiteindelijk ook de ondergang van Android kan worden. Kijk als eerste naar wat gebruikers allemaal accepteren. Dat is een hele lijst aan permissies. Neem bijvoorbeeld Facebook en Twitter, die hebben helemaal niet je GPS-locatie nodig of de mogelijkheid om sms-berichten te versturen. Als gebruiker moet je kritisch zijn over waar een app allemaal toegang toe heeft.

Maar gebruikers vragen zich dat helemaal niet af, ze willen gewoon de app.
Inderdaad, je hebt een 'ja' of 'nee' vraag. Als je nee zegt krijg je de app niet, dus staan gebruikers hier ook niet bij stil. In het geval van Angry Birds, waar gebruikers er wel stil bij stonden, werd een update teruggedraaid die het mogelijk zou maken om sms-berichten te versturen. Als gebruikers hier vaker over klagenm zou het kunnen veranderen, maar dat gebeurt helaas niet. Gebruikersbewustzijn is belangrijk, want mensen beschouwen het als een gewone telefoon en hebben geen weet van de mogelijke aanvallen.

Had Google voor een ander model moeten kiezen?
Weidman: Dat is een lastige vraag. Bij iOS heb je allerlei mogelijkheden niet. Je bent veiliger in Apple's afgesloten omgeving, maar niet helemaal veilig. Google doet tenminste geen beloftes om je te beschermen, terwijl Apple zegt dat je nooit ongesigneerde code zal uitvoeren en dat je nooit risico zal lopen, en we hebben in het verleden gezien dat dit niet waar is. Elke keer dat er een jailbreak verschijnt wordt er ongesigneerde code uitgevoerd.

Ik zou graag zien dat Google het permissiemodel verbetert, maar ik zou ook weer niet willen zien dat Android in iOS verandert. Dat zou treurig zijn.

Is het permissiemodel op zich een risico of de manier waarop ontwikkelaars hiermee omgaan?
Weidman: Ik laat tijdens mijn presentatie voorbeelden zien waar ontwikkelaars het permissiemodel verkeerd gebruiken waardoor gevaarlijke permissies voor andere apps toegankelijk zijn. In sommige gevallen met opzet, maar ook zonder er over na te denken. Het kan iedereen overkomen, aangezien het permissiemodel en het programmeren voor Android nog zo nieuw is.

Moet Google geen veilig programmeren voor Android promoten?
Weidman: Absoluut. Er is zelfs een Google pagina over het veilig ontwikkelen voor Android en bevat allerlei interessante informatie. Deze securitypagina wordt echter nergens vermeld. Je moet er dus zelf naar zoeken, anders ga je het niet vinden.

Kan Google controleren of apps permissies lekken?
Weidman: Het is mogelijk via dynamische analyse of volledige controle van de code, maar er zijn zoveel apps dat dit onhaalbaar is.

Zijn dit soort permissielekken eenvoudig te vinden?
Weidman: In de meeste gevallen wel. Je zoekt naar de mogelijkheid om zonder gebruikersinteractie toegang tot code te krijgen. Zodra een permissie is aangeroepen, kunnen andere apps het gebruiken, bijvoorbeeld het versturen van een sms.

Welk permissie wordt het vaakst gelekt?
Weidman: Privégegevens die gelekt worden kwam ik het vaakst tegen. De mogelijkheid om informatie te lezen waar je eigenlijk geen toegang toe zou moeten hebben. Identificatiegegevens van de telefoon, gebruikersnamen en wachtwoorden.

Wat kunnen eindgebruikers tegen permissielekken doen?
Weidman: Wees bewust van de permissies die je aan apps geeft. Ga er dus van uit dat als je een app een permissie geeft, alle apps die permissie hebben.

Zou er een instantie moeten komen die apps gaat controleren en certificeren, zodat je zeker weet dat je een betrouwbare app binnenhaalt?
Weidman: Dat zou fantastisch zijn, en ik denk dat veel van de grote app-ontwikkelaars dat graag zouden zien. Zo kunnen ze een keurmerk op hun app plakken. Dat geeft gebruikers meer zekerheid.

Wat zijn volgens jou de grootste gevaren voor de toekomst van het Android-platform?
Weidman: Zoals altijd met ontwikkeling, gaat bruikbaarheid voor security. Elke keer dat er een nieuwe versie uitkomt zijn er meer features toegevoegd, maar op securityvlak gebeurt er niet zo veel. Ik zou graag meer aandacht voor security zien.

Moeten gebruikers hun telefoon rooten of niet?
Weidman: Die van mijn zijn de ene keer geroot en dan weer niet, afhankelijk van de dag. Als je je telefoon root kunnen je apps in potentie nog veel meer permissies krijgen. Bekijk dus de code als je dat kan en wees bewust van de gevaren.

Wat zou je aan zakelijke Android-gebruikers adviseren?
Weidman: Gebruik twee telefoons, dat doe ik. Het is beangstigend als je nagaat wat er op deze toestellen wordt opgeslagen, wat waarschijnlijk in strijd met je arbeidscontract is. Documenten, contracten, rapporten en klantgegevens, het staat allemaal op je telefoon. Documenten zijn mogelijk wel tijdens het verkeer versleuteld, maar staan meestal onversleuteld op de telefoon. Wat een risico is als je toegang tot de telefoon hebt, wat bij apps het geval is.

Ik denk dat Bring Your Own Device (BYOD) nog niet volwassen genoeg is op het punt dat het voldoende veilig is. Gebruik dus twee telefoons, één voor de leuke dingen en hou de andere uit de buurt van de enge apps.

Reacties (4)
27-05-2012, 01:03 door Anoniem
Jeemig wat had die dame een slecht verhaal @HITB en wat presenteerde ze slecht.

Haar verhaal in een notendop: permissiemodel is niet goed want je kunt apparaten rooten door exploits te draaien, daarna is het permissiemodel niet meer effectief. Ahah... Iets met klok en klepel.

En als ze het een 'exploit' noemt als je een SMS kunt sturen nadat je SMS-permissies hebt geaccepteerd snapt ze het m.i. ook niet helemaal. Een van de slechtste praatjes van HITB waar veel mensen ook wegliepen.
27-05-2012, 09:38 door spatieman
een ap dat zowiezo vraagt om SMS te versturen al permanent weigeren !!
27-05-2012, 09:46 door P5ycH0
"Bij iOS heb je allerlei mogelijkheden niet. Je bent veiliger in Apple's afgesloten omgeving, maar niet helemaal veilig. Google doet tenminste geen beloftes om je te beschermen, terwijl Apple zegt dat je nooit ongesigneerde code zal uitvoeren en dat je nooit risico zal lopen, en we hebben in het verleden gezien dat dit niet waar is. Elke keer dat er een jailbreak verschijnt wordt er ongesigneerde code uitgevoerd."

Google beloofd wel degelijk je te beschermen. Anders zat er geen permissie systeem in.
Verder idd een gevalletje 'de bal is rond'. Natuurlijk kan er unsigned code gerunned worden als je jailbreaked of root.
04-06-2012, 15:30 door SecOff
Door Anoniem: Jeemig wat had die dame een slecht verhaal @HITB en wat presenteerde ze slecht.
Kwam wellicht ook doordat ze tijdens de presentatie een halve fles teqilla leegzoop. ;-)
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.