Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , reacties: 69, views: 18.385 •
Submitter: SidewalkSuper

Een lek in de beveiliging van Android maakt het mogelijk maken om code in een app aan te passen, zonder dat de cryptografische handtekening wijzigt. De kwetsbaarheid werkt op bijna alle Androids, maar het risico lijkt beperkt.

Evil AndroidHet beveiligingslek werd gevonden door Bluebox, een startup die zich specialiseert in de beveiliging van mobiele apparaten. Bluebox paste code aan .apk-bestanden, zonder dat de cryptografische handtekening van de app veranderde. Daardoor lijkt het alsof de geïnfecteerde app niet gewijzigd is. De beveiligingsfout is sinds Android 1.6 aanwezig en volgens de hackers van toepassing op 99 procent van alle Android-apparaten.

Het grootste risico schuilt er volgens Bluebox in dat er ook apps geïnfecteerd kunnen worden die door de fabrikant van de telefoon geïnstalleerd zijn. Deze apps hebben meestal speciale machtigingen, waardoor het injecteren van eigen code in deze apps ervoor kan zorgen dat er volledige controle over het apparaat verkregen wordt. Opgeslagen data zoals smsjes, e-mail en documenten zouden uitgelezen kunnen worden, maar er is dan ook toegang tot wachtwoorden en de telefoon-functionaliteit.

Het risico van de bug lijkt evenwel klein. Gebruikers moeten de geïnfecteerde app echter wel zelf downloaden. Android-gebruikers die officiële apps uit de Play-store halen zullen daarom niet snel met het gat in de Android-beveiliging geconfronteerd worden. Downloads van apps van websites of alternatieve downloadwinkels kunnen echter wel risicovol zijn, maar op Android-telefoons kunnen die alleen geïnstalleerd worden als de gebruiker zelf aangeeft apps buiten de Play Store om te willen installeren.

De bug is door Bluebox in februari aan Google gemeld en volgens Engadget is de recentelijk uitgebrachte Samsung Galaxy S4 al immuun gemaakt voor de fout in de Android-beveiliging. Tijdens de hackersconferentie Black Hat, die eind juli plaatsvindt, zal Bluebox uit de doeken doen hoe de beveiliging precies omzeild kan worden; de details van het lek zijn op dit moment onbekend.

Reacties (69)

En toch vind ik (als fervent Android gebruiker) het jammer dat er geen mogelijkheid is voor Google om bepaalde bestanden, zoals een framework.apk o.i.d., te patchen via een OTA zodat dit soort dingen voor iedere Android telefoon die er maar is, gefixed worden. (a la Windows update). Dit soort dingen rechtvaardigt wel een 'Je telefoon moet even opnieuw opstarten' melding dunkt me...

En als die mogelijkheid wel bestaat... Is het zonde dat die niet gebruikt wordt.
Zoiets man Google wel, maar dat gaat via de Google Play Store services.
Nou... Ik heb Google Play Store nog nooit dingen zoals een framework.apk of core.jar of services.jar zien updaten (in de /system/framework/ map). Wel een paar .so's die in de Google Apps zitten, maar het Android systeem staat los van Google Play Framework. Er zijn zat Android devices zonder Google Apps package, en die hebben dat dus allemaal niet.

Iedere Android kan in principe wel van een OTA-update functie gebruik maken, en daarmee zouden essentiele systeembestanden moeten worden aangepast. Maar dat gebeurt dus niet...
Momenteel is dat waar Google mee bezig is. Alle systeem apps apart als APK's inpakken zodat zij zelf kunnen updaten en niet meer onafhankelijk zijn van third parties.

Een goed voorbeeld daarvan is het Android keyboard wat binnenkort als APK beschikbaar is.
Dat mag niet, rechten en regels enzo. Daarnaast is alles altijd heel open, ad-hoc, gedecentraliseerd en hackbaar, wat het hele OTA verhaal erg lastig maakt. En zelfs als het al zou lukken om dat de eerste set problemen te overkomen zonder dat het een bak geld kost die je nooit van je leven terugkrijgt, dan zit je nog met die gigantische versplintering.
Android loopt hier tegen het probleem aan dat elke fabrikant zijn systeem 'custom' maakt. Niet alleen wat betreft drivers, maar ook allerlei vaak diep geintegreerde eigen apps.

Je moet dus niet tegen Google klagen maar tegen de mobieltjes fabrikant. Het is toch godsgeklaagd dat bijv. een Samsung Ace nog steeds met Android 2.xx rond moet lopen?
Ik kan wel een reden bedenken waarom ze dat niet updaten/patchen. Elke klant met een 'risicotoestel' kun je weer een nieuw toestel verkopen :P Iets wat ik toch best wel een beetje schandalig vind. Beveiligingslekken die een groot risico vormen behoren gepatched te worden, ongeacht de versie van Android die op dat toestel draait. Je betaalt vaak meer voor een Android smartphone dan voor een licensie op Windows en dan is het nog maar de vraag of de Android die daarop draait ooit wel een update krijgt.
Ik heb heel erg het gevoel dat een gemiddelde gebruiker, zeker als deze stamt uit het Win 95 tijdperk, het 'even opnieuw opstarten' het liefst zo lang mogelijk uit stelt. Het lijkt mij beter om de telefoon na de update zichzelf gewoon te laten rebooten. Anders wacht je tot er 135 updates klaar staan.
Ik heb heel erg het gevoel dat een gemiddelde gebruiker, zeker als deze stamt uit het Win 95 tijdperk, het 'even opnieuw opstarten' het liefst zo lang mogelijk uit stelt. Het lijkt mij beter om de telefoon na de update zichzelf gewoon te laten rebooten. Anders wacht je tot er 135 updates klaar staan.
Mijn idee,
Sterker, het hele "uptime" verhaal heb ik nooit begrepen.
bij 24/24 kritieke service misschien, maar in 'thuis' situaties, ik kom soms verhalen tegen MET screenshots, over de trots dat hun modem / mailserver / telefoon al 100'en dagen niet meer is ge-reboot.

alsof het een prestatie op zich is.

Hier gaat alles regelmatig gewoon offline, dagelijks, zo niet één keer per week.
Zelfde reden ..... "omdat het kan !"

Mijn telefoon herstart ik gewoon, soms elke dag, soms om de paar dagen.
[...]

ik kom soms verhalen tegen MET screenshots, over de trots dat hun modem / mailserver / telefoon al 100'en dagen niet meer is ge-reboot.

alsof het een prestatie op zich is.
Als een systeem regelmatig gereboot móét worden bij normaal bedrijf, is het niet stabiel. Nou kun je zeggen dat dat geen bezwaar is als het een week ofzo up kan zijn, aangezien je het toch iedere dag reboot, maar niet stabiel blijft niet stabiel. Als hij na een week problemen krijgt bij normaal bedrijf, wie zegt dan hoelang hij het uithoud onder zware load?
Heel vreemde redenatie.
Ik weet niet hoor, maar Linux of MacOs hoef ik maar zelden opnieuw op te starten.
En nee, dat is niet omdat ik het uitstel.
Maar gewoon, omdat het niet nodig is.
En daarom zal de overgrote meerderheid van Android apparaten ws nooit een update voor dit lek krijgen.
Kom op, Chrome rendert HTML5 en CSS3 redelijk goed, dus en Google Search levert de beste resultaten (zegt niets over hoe de code-base in elkaar zit) ... kortom Android moet wel helemaal perfect zijn. Ja ik weet het, het zijn totaal ongerelateerde zaken ... maar zo wordt wel net even te vaak naar Google en hun producten gekeken.
Is iOS beter dan? Elke nieuwe versie wordt ook door gebruikmaking van weer een nieuw beveiligingslek gejailbreakt.

Met deze kwetsbaarheid van Android krijg je alleen maar te maken wanneer je je apps uit onbetrouwbare bron haalt. Ook de apps die je met een gejailbreakte iPhone uit Cydia haalt zijn potentieel onveilig.

Wanneer Google Android net goed genoeg zou maken om de advertentie-inkomsten binnen te halen, zou het niet goed genoeg zijn om veel gebruikers vast te houden. Een groot veiligheidslek is voor Google net zo funest als voor elk ander bedrijf.

Je doet hier alsof Google de enige is die gegevens gebruikt die het via het gebruik van telefoons binnenkrijgt. Apple en Microsoft verzamelen net zo veel gegevens over het gebruik van hun telefoons en proberen er op dezelfde manier geld mee te verdienen.
Verschil is wel dat je bij iOS je toestel moet jailbreaken om er een onveilig toestel van te maken. Bij Android koop je gewoon een onveilig toestel.

En wat gegevens verzamelen betreft is het wel de core business. De core business van Apple is hardware verkopen. Gegevens verzamelen is voor Apple dan ook totaal niet belangrijk.

Maar ja het is Android en dan kijkt men alles door de vingers natuurlijk. En wijst men direct alle kritiek op het platform van de tafel door nonsens en het gospel van Google te preken.
Mijn eerste punt is dat iOS ook onveilig is. Door de beveiligingslekken is het mogelijk een iPhone te jailbreaken. Een beveiligingslek dat het mogelijk maakt om vanaf een website je iPhone te jailbraeken kan door een ander website misbruikt worden om andere ongein op de iPhone uit te halen.

Mijn tweede punt is dat het beveiligingsprobleem in Android alleen speelt wanneer je apps buiten de Google Play Store of een andere officiële app-store om installeert. De meeste mensen komen hier dus nooit mee in aanraking. Alleen wanneer je bewust apps uit niet-officiële bronnen haalt is misbruik van dit beveiligingsprobleem mogelijk, net als wanneer je dat met een gejailbreakte iPhone doet. Jailbreaken is dan welliswaar iets ingrijpender dan een vinkje zetten in het instellingenmenu dat het voor Android-toestellen mogelijk maakt om apps buiten de Google Play Store om te installeren, maar het gaat te ver om daarmee de iPhone veilig en Android onveilig te noemen.

Verder zal ik nooit het gospel van Google preken. Ik vind hun verzameldrang erg verontrustend. Maar de verzameldrang van Apple en Microsoft is minstens net zo erg, dat het niet hun core-business is verandert daar niets aan. Doordat het niet hun core-business is kunnen zij zich zelfs grotere ‘missers’ veroorloven. Wanneer zij de ‘fout’ in gaan, kunnen zij zich verontschuldigen door te zeggen dat de fout er doorgeslopen was omdat er wat onduidelijkheid was over de regels, omdat het niet hun core-business is.
Google moet veiliger opereren juist omdat het hun core-business is. Juist zij moeten weten waarmee ze bezig zijn. Zij moeten ook dieper door het stof wanneer ze de fout in gaan, waar anderen kunnen volstaan met: “Sorry, volgende keer beter.”

Het beste wat je kunt doen is je diensten spreiden. B.v. Een Android telefoon met Google Play Store, maar de rest van de diensten van Google (incl. gMail) links laten liggen en Firefox op je PC met Bing ingesteld als zoekmachine en iTunes als muziekdienst. Dan heeft niemand een compleet profiel van je; Google niet, maar ook Apple en Microsoft niet.
Het probleem is dat framework.apk en de services.jar per bedrijf anders is. Bijvoorbeeld heeft samsung heeft in de nieuwere galaxy toetselen hierin de multi window dingen verwerkt.

Dus zou google alle versies moet hebben liggen en meerdere malen moeten aanpassen.
Ze kunnen toch ook een API maken waaraan alle aparte skins en versies van Android moeten gaan voldoen zodat deze bij een update niet breken?
Het ergste is dat Tweakers dit minimaliseert als zijne "beperkt risico". Terwijl ondertussen wel duidelijk is dat een heel groot deel van de Android gebruikers nooit een patch zullen ontvangen.
Het risico is beperkt omdat de meeste gebruikers apps alleen uit officiële kanalen zullen installeren. Als je alleen apps uit de Play Store haalt hoef je je niet echt veel zorgen te maken, daarom is het risico als 'beperkt' geclassificeerd.
Knap, want Bluebox heeft er pas gisteren een artikel over geschreven. Wellicht is er een andere vulnerability die eerder al bekend is geworden, die niet hetzelfde is als degene waar het artikel over spreekt.
Onzin, zie bijvoorbeeld hier. Bericht van meer dan een maand oud.

Als je even zelf het bericht van bluebox had gelezen zag je: "Details of Android security bug 8219321 were responsibly disclosed through Bluebox Security’s close relationship with Google in February 2013".

Ze hebben tot nu toe volgens mij nog niet verteld hoe deze aanval werkt, maar het kan dus best zijn dat DSTech er al eerder van gehoord heeft.

[Reactie gewijzigd door Manu_ op 4 juli 2013 09:41]

Als je even goed leest, staat daar alleen maar genoemd dat het over die specifieke bug gaat (op basis van het nummer), maar absoluut niet wát de vulnerability inhoudt. Zelfs niet een beetje. Als je verder gaat zoeken naar dat bug-nummer, vind je alleen aankondigingen als 'an exploit that runs across all Android devices' of 'The vulnerability involves discrepancies in how Android applications are cryptographically verified & installed'.

Overigens zeggen ze inderdaad dat ze de details in februari hebben vrijgegeven. Aan Google, ja, en aan niemand anders.
Vooruit, hier nog een link: klik. Van 30 mei, staat letterlijk "Forristal claims he can modify APKs without having to re-sign them". Het was dus echt al bekend.
/aluhoedje op

Het wijzigen van de .apk-bestanden is niks nieuws. Het grappige is dat een dergelijke proof of concept al in september 2012 aan me getoond is door een bekende developer (van een bepaald type standalone mediaplayer).

Sindsdien is deze developer ook al aangesproken door zowel Samsung als LG om bepaalde werkzaamheden voor ze te gaan doen op Android-niveau en dan met name in de hoek van beveiliging alsmede DRM-apps voor smart-TV's.

Al met al vind ik de kwetsbaarheid die nu gepubliceerd is best een sterk staaltje van achterstallig onderhoud; het is niet alsof .apk pas sinds een paar maanden bestaat of op een beperkt aantal devices te vinden is.
Een APKtje uit elkaar halen, wijzigen en overnieuw signen (dus met een andere key) is wel iets heel anders. De andere key geeft eigenlijk al aan; deze app is door iemand anders gemaakt.

Over het 'achterstallig onderhoud': ik weet natuurlijk niet hoe geavanceerd deze aanval is, maar het is toch niet heel raar dat aanvallen pas later gevonden worden? Daaruit kun je toch niet meteen afleiden dat Google laks is geweest? Misschien vergelijkbaar: X509 was ook al 20 jaar oud toen dit werd gedaan.
Je zou bijna denken dat de handtekening bijvoorbeeld de md5 of een andere soort hash op alle bestanden binnen een .apk-bestand zou checken, of gebeurt dit al?
Volgens mij zou je met md5 nog een collision kunnen veroorzaken waardoor andere code exact dezelfde hash oplevert. Misschien is SHA-1 wel een optie?
MD5-collision.... Theoretisch... JA het is mogelijk.
Maar SHA-1???? Dat is nog vele malen erger dan MD5.
Gebruik dan SHA-256 of 512
MD5 hash aanpassen zonder detectie?

2^127 mogelijkheden en dus héél lang zoeken ;)

http://www.mscs.dal.ca/~selinger/md5collision/
paar uurtjes dus :(

[Reactie gewijzigd door CetelBink op 4 juli 2013 11:28]

Dit is werkelijk totaal onbekend voor mij.
Volgens mij wordt SHA-1 superieur geacht aan MD5.
Heb je bronnen die het tegendeel onderbouwen?
http://www.schneier.com/b...5/02/cryptanalysis_o.html
Earlier this week, three Chinese cryptographers showed that SHA-1 is not collision-free. That is, they developed an algorithm for finding collisions faster than brute force.
Dat gebeurt in principe wel, en dat is waarschijnlijk ook hoe de .apk's worden geverifieerd; er wordt een hash getrokken van de inhoud van de .apk, en die wordt ondertekend met een privésleutel, waarna Android met het publieke deel van die sleutel diezelfde hash kan verifiëren.

Waarschijnlijk zit er een fout in de code die die hash berekent waardoor stukken van .apk's kunnen worden uitgesloten van het berekenen van die hash. Er is verder nog niet bekend hoe de vulnerability technisch in elkaar steekt.
Ik vind dat er wel erg gemakkelijk beweerd wordt dat dit maar een beperkt risico is.

Want volgens mij betekent dit dat kwaadwillenden ook apps in de Play Store kunnen gaan zetten die heimelijk de standaard beveiling van de toegang tot data omzeilt. Een app kan alleen toegang tot onschuldige gegevens vragen en dat melden, maar intussen stiekem álle gegevens van de gebruiker benaderen.
Dat gecombineerd met het feit dat vrijwel alle versies kwetsbaar zijn, én de zeer beperkte mate waarin de meeste Android telefoons worden geupdatet, ik vind dit om eerlijk te zijn wél een zeer ernstig lek.
Kwaadwillenden die het via de Google Play Store doen hebben de truuk niet nodig. Als het je lukt om een foute app in de Play Store te krijgen dan hoef je niets te omzeilen.
Ik weet niet precies hóe dat bij de Play Store werkt, maar is het niet zo dat een eenmaal door Google 'gesigneerde' app hiermee dus na het signeren te wijzigen is?
Nee het certificaat zorgt/waarborgt (normaal) dat alleen de rechtmatige eigenaar een nieuwe versie kan uploaden. Dat is eigenlijk de enige reden voor het certificaat, het staat compleet los van het rechtensysteem...
Apps worden niet door Google gesigned, maar door de developer (klik).

Een app wordt alleen geupdate als de update met dezelfde key gesigned is als de geinstalleerde versie. Door deze aanval lijkt het zo te zijn dat mensen dus nep updates maken die bij alle data van de app kunnen en alle permissies kunnen gebruiken.

@jalumsx: Dit is zeker een ernstig lek, dat probeer ik helemaal niet te ontkennen! luckyjan geeft ergens hieronder een prachtig voorbeeld van hoe het mis kan gaan.

[Reactie gewijzigd door Manu_ op 4 juli 2013 10:33]

Dus het opent de deur voor apps die zich nestelen tussen het proces van het downloaden van updates en het installeren ervan.

Er wordt een geldige update gedownload, een (desnoods via de Play Store verspreidde) geinfecteerde app onderschept de download, wijzigt de inhoud (infecteert met willekeurige malware) en het OS ziet een geldige sleutel en installeert de besmette update gewoon.

Dit is toch een ernstig lek, met een substantieel risico?
Dan nog, om een app op iemands telefoon te krijgen die deze bug kan misbruiken is niet eenvoudig, als je iemand iets dergelijks kan laten installeren dan ben je immers al binnen: dan heb je een bug als dit niet meer nodig.
@Manu_:

Dat is dus precies wat ik bedoelde inderdaad, ik denk dat we het eens zijn. :)

Ik vind dat het t.net artikel de ernst van deze kwetsbaarheid nogal bagatelliseert.
Want volgens mij betekent dit dat kwaadwillenden ook apps in de Play Store kunnen gaan zetten die heimelijk de standaard beveiling van de toegang tot data omzeilt.
Nee dat heb je fout, alle te gebruiken rechten moeten nog steeds gevraagd worden aan de gebruiker, dat heeft niks met het certificaat te maken. Het certificaat is enkel om de echtheid te garanderen, net zoals bij websites zo is...
Dat gecombineerd met het feit dat vrijwel alle versies kwetsbaar zijn, én de zeer beperkte mate waarin de meeste Android telefoons worden geupdatet, ik vind dit om eerlijk te zijn wél een zeer ernstig lek.
De telefoons hoeven ook geen update in de zin van een nieuwe Android versie, Google kan gewoon hun Play Service updaten, wat los staat van de Android versie...

Dus nee ik vind dat jij er wel erg makkelijk meer van maakt dan het is :) Neemt niet weg dat het wel een probleem is waar Google zeker wat aan moet doen uiteraard...
Is dat zo?

Volgens mij maakt dit lek het in ieder geval mogelijk om apps die alle rechten al hebben, via een 'update' te besmetten met malware. Het is toch niet zo dat een app die vanuit de store geupdatet wordt, elke keer opnieuw om de toegang tot die gegevens vraagt?

Je zou dus een app kunnen bouwen die zich voordoet als een spel of wat dan ook, maar dan heimelijk Play Store updates gaat onderscheppen en injecteren met malware, en het OS én de gebruiker merken daar niets van...
Dan nog, de gebruiker moet daarvoor eerst jou app buiten de playstore downloaden, redelijk wat rechten toekennen voordat een dergelijk app de mogelijkheid heeft om een dergelijke bug te misbruiken.
vinden de android virusscanners die ik heel af en toe eens installeer en laat lopen en deinstalleer deze kwaadaardige apk's ?
vinden de android virusscanners die ik heel af en toe eens installeer en laat lopen en deinstalleer deze kwaadaardige apk's ?
Tenzij ze zelf voorzien zijn van die code, en ondertussen al je 'schone' apps aanpassen
Het is toch niet ondenkbaar dat geïnfecteerde apps ook in de store komen, of vergis ik me? Dit moet zo snel mogelijk opgelost worden, maar dat zal wel niet gebeuren.
Wat ik mij afvraag is of de Play Store pakketten standaard via SSL binnenhengelt. Als dat zo is ben ik het met de schrijver van het artikel eens dat het risico minimaal is, aangezien je op die manier heel lastig geïnfecteerd kan worden zonder zelf pakketten te downloaden en te installeren.

Als de Play Store geen SSL gebruikt wordt het makkelijk om een ander pakket door te sturen. Bijvoorbeeld door een open WIFI op te zetten die een bepaalde applicatie gewijzigd doorstuurt.
Een boel Sommige mensen installeren APKs handmatig. Als er bijvoorbeeld een nieuwe play store versie is, dan duurt het vaak erg lang totdat je die update krijgt. Sites als AndroidPolice uploaden die APKs dan, en die kon je 'veilig' installeren omdat ze toch gesigned waren.

Verder komt dit een beetje over als onzin: "Installation of a Trojan application from the device manufacturer can grant the application full access to Android system and all applications (and their data) currently installed" (bluebox). Een telefoonfabrikant kan toch sowieso allerlei system apps installeren op je telefoon, daar is deze aanval toch niet voor nodig?

Edit: Jullie hebben gelijk, ik las het iets te letterlijk: met 'trojan application from the manufacturer' bedoelen ze natuurlijk iets dat zich voordoet als van de fabrikant.

[Reactie gewijzigd door Manu_ op 4 juli 2013 10:36]

het gaat er om dat een kwaadwillende nu een update voor een systeem applicatie kan uit brengen zoals een aangepaste touchwiz apk, die gewoon herkend wordt als een Samsung app maar wel even gegevens naar een derde partij verstuurd.
normaal zou alleen de fabrikant of Google een apk kunnen maken die een systeem applicatie vervangt, maar nu kan iedereen die de fout kent dit doen.
Een Trojan kan zich dus voordoen als een door de fabrikant ondertekende update of app...
'Een boel'? Ik denk dat het aandeel mensen dat zelf APK's installeert vrij minimaal is, gekeken naar het totale aantal Android-gebruikers. Het percentage mensen wat überhaupt weet wat een APK is, zal al zeer minimaal zijn.

En ik denk dat ze het hebben over een gecompromitteerde APK die zich voordoet als een applicatie van een telefoonfabrikant.
Mensen vergeten wat voor mogelijkheden dit biedt voor man-in-the-middle aanvallen, wanneer Android niet doorheeft dat de appliecatie die je download niet de applicatie is die hij zou moeten zijn.
Jammer dat Google niet de verantwoordelijkheid neemt om smartphones, die buitenGoogle Play apps geinstalleerd hebben, te beschermen. Blijkbaar kun je ze immuun maken, alhoewel ik niet weet hoe gemakkelijk dit gedaan kan worden.

Google kan het risico misschien als extra 'motivatie' zien voor gebruikers om binnen het eco-systeem te blijven. Het kan natuurlijk ook dat het simpelweg te moeilijk/onmogelijk is om het probleem via een update op te lossen.

Iemand een idee?


@Korben
Ah, verkeerd gelezen. Bedankt voor je reactie!
Betrap ik me toch op een vooroordeel tegenover Google :s

Gelukkig heb ik een andere ROM draaien
die beter update dan de fabrikant.

[Reactie gewijzigd door Mative op 4 juli 2013 11:21]

Het probleem gaat worden opgelost met een update. Het zal alleen waarschijnlijk een systeem-update worden, en Google heeft, met uitzondering van de Google Nexus-telefoons, geen invloed op wanneer een fabrikant zijn telefoons updatet.

Google neemt wel degelijk de verantwoordelijkheid om gebruikers te beschermen, voor zover mogelijk. Het probleem is alleen dat ze een fout hebben geïntroduceerd in het valideren van applicaties. Het is niet dat ze het niet willen.
Ik gebruik de app LBE security master
http://forum.xda-developers.com/showthread.php?t=1422479
Daarmee kan je per app instellen wat ie wel en niet kan.
Bijv. een of andere weer app die mijn contacten, imei nummer enz wil lezen kan ik dan beperken tot alleen internet verbinding.
Verder zit er een ad ware en virusscanner in (geen idee hoe effectief die is).
Zo heb ik bijna iedere app die ik gebruik op functionele rechten ingesteld. Mocht ik dus een "foute" app binnenkrijgen is het risico toch beperkt.
Nadeel is wel dat je telefoon geroot moet zijn om alle functionaliteit van LBE te gebruiken.
Haha, prachtig voorbeeld.

Jij download APKs van een site (zonder TLS). Elke nieuwe versie móet wel van de echte developer zijn, dat garandeerd die signature toch? Nu doet een aanvaller een MITM aanval en geeft jou een app met aangepaste code maar dezelfde signature. Jij installeert vrolijk deze app, en nu heeft de aanvaller root access op je telefoon.
De echte developer kent alleen Chinees :P Je moet natuurlijk wel zelf kijken of het enigsinds betrouwbaar is en in dit geval vertrouw in de vertaler meer dan menig app in de playstore :)

Op dit item kan niet meer gereageerd worden.