Oudere Android-versies zijn vatbaar voor ernstige privacybug

De stock-browser van Android-versies tot en met 4.3 is kwetsbaar door een ernstige bug waarbij websites de content en cookies van andere webpagina's via javascript kunnen uitlezen. De Chrome-browser en de stock-browser in Android 4.4 zijn niet kwetsbaar.

De kwetsbaarheid werd eerder deze maand gevonden door beveiligingsonderzoeker Rafay Baloch. Normaliter horen websites alleen bewerkingen te kunnen uitvoeren op hun eigen domein of subdomein; de zogenoemde same origin policy voorkomt bijvoorbeeld dat websites cookies van andere domeinen kunnen uitlezen.

In de stock-browser van Android 4.3 en eerder blijkt de same origin policy echter niet te worden nageleefd wanneer een unicode-karakter voor de javascript-code wordt geplaatst, waardoor iedere website de gegevens van een andere website kan uitlezen. Zo kan de inhoud van de website worden uitgelezen, wat gevoelig is in het geval van bijvoorbeeld webmaildiensten. Ook kunnen sessiecookies worden gekaapt, waardoor een aanvaller in sommige gevallen de sessie kan overnemen.

Android 4.4, de nieuwste stabiele Android-versie, is niet kwetsbaar, en hetzelfde geldt voor de Chrome-browser, die standaard wordt meegeleverd. Bovendien levert Google met Nexus-toestellen niet meer de stock-browser mee. Veel Android-gebruikers draaien echter oude Android-versies: slechts 24,5 procent van de Android-gebruikers beschikt over versie 4.4, blijkt uit cijfers van Google zelf.

Veel oudere telefoons worden niet meer ondersteund door de fabrikant en ontvangen geen software-updates meer, waardoor ze dus mogelijk altijd kwetsbaar zullen blijven voor de privacybug. Het risico dat de bug misbruikt gaat worden, is groot: er is inmiddels een module vrijgegeven voor hackframework Metasploit, waardoor het eenvoudig is om een aanval op te zetten.

Reacties (211)

[Kiswum]

Low-budget oplossing:
Je hoeft niet direct een nieuwere telefoon te kopen of 1 aan te schaffen met een goede ROM support. Je hoeft tevens je telefoon niet direct te rooten om deze weer te kunnen voorzien van een nieuwere Android versie.
Heb je veel sites die je hebt opgeslagen als bookmarks, sla deze dan op voordat je het onderstaande uitvoert.

Stap 1, download een andere browser via de playstore (bijvoorbeeld Google Chrome).
Stap 2, ga naar de instellingen van je telefoon, kies daar voor apps/applicaties, tabblad alle applicaties.
Stap 3, zoek naar de app "browser" (dat is een blauw icoontje).
Stap 4, sluit de app af via Force Close/Beëindigen, app Disablen/Uitschakelen en kies ervoor om de cache + data te wissen.
Stap 5, check of de browser app van je bureaublad/app menu is verwijderd.
Stap 6, ga nu verder met surfen i.c.m. een andere browser.

Je kunt nu weer rustig ademhalen

[Jeroenneman]

Helaas gaan de meeste mensen hier weer gelijk helemaal over de rooie mbt het update beleid van Android.

Nou, daarvoor hebben we marktkeuze:

1. Blijf je telefoon gebruiken met een andere browser.
2. Koop een Nexus of Motorola telefoon.
3. Koop lekker een iPhone of Windows Phone toestel.

[Verwijderd]

Wat maakt een nexus of Motorola nou uit? Nexus geeft 18 maanden en moterola zal ook niet veel meer zijn..

Door de zinsopbouw blijk je een bekoorlijke affectie tegen apple en windows te hebben wat nou net wel de enige twee platformen zijn die wel regelmatig updaten en serieus zijn met je privé gegevens.

[Kiswum]

Dat ze meer dan 1 jaar lang updates geven is (helaas), langer dan veel andere fabrikanten bij 80% van hun toestellen. Je kunt ook kiezen voor bijvoorbeeld Xiaomi, daarbij krijg je na 2 jaar nog steeds support. Dat heb ik niet veel vaker bij Android telefoons gezien. Hun eerste telefoon heeft 3 jaar lang officiële software support gehad van deze fabrikant.

Windows Phone, het is nog even afwachten hoe goed die support zal zijn, bij mijn WP 7.5 telefoon uit 2012 is het gestopt bij WP 7.8, dat kwam neer op nog geen 1 jaar support. Hoe de support vanaf WP 8.0 telefoons zal zijn weet ik niet, dat OS is nog geen 2 jaar op de markt, de tijd zal uitwijzen hoe lang deze gebruikers kunnen blijven updaten.

Bij IOS is de support erg lang en dat is volgens mij zo'n 3 jaar als ik het goed heb. Veel gehoorde problemen zijn echter dat de tablets/smartphones dan echter zo traag zijn geworden, waardoor het geen interessante upgrades zij geweest.

Support Blackberry? Geen idee hoe goed/slecht dat is.

[ronaldmathies]

Sorrie, ik kan niet voor mijzelf accepteren dat een keuze vrijheid voldoende is om te zeggen dat een update beleid slecht mag zijn.

[Jeroenneman]

Tja.

Ik kan ook klagen dat Tele2 zonder reden mijn abonnement verlengd, zonder me dit netjes te melden.

Ik vind het ook vervelend dat de Z3 Compact geen AMOLED scherm krijgt.

Ik vind het jammer dat mijn S2 niet meer de nieuwste Android versie krijgt.

Maar helpt het om te gaan janken op een tech site? Of zal ik toch maar met mijn portemonnee en verstand gaan stemmen?

Blijkbaar vinden genoeg mensen het geen probleem, kijkende naar het marktaandeel van Android. Ik ook niet. Die S2 heeft het 3 jaar prima gedaan, en het is tijd voor iets nieuws.

[catfish]

denk jij nu echt dat het OS zelf foutloos is en dat de bugs enkel in de browser zitten?
dat lijkt mij heel naïef

[johnkeates]

De vraag is dan nog: wat is de impact? Naast de vraag hoeveel gebruikers met vatbare apparaten zitten is er natuurlijk ook nog de vraag wie er daadwerkelijk vatbaar is door gebruik te maken van de ingebouwde browser en naar een site te navigeren met een exploit die daadwerkelijk de cookies wil uitlezen.

Edit: en dan bedoel ik niet dat het allemaal wel meevalt, want het valt helemaal niet mee, maar je kan je met dit soort zaken best afvragen hoe dit in de praktijk iets gaat veroorzaken. Stel dat een gebruiker met een ongepatcht apparaat rondloopt, dan is dat waarschijnlijk geen poweruser / tweaker gezien die groep vaak richting de custom ROMs gaat of nieuwe hardware koopt. Mensen die met oude hardware blijven zitten zullen dan misschien (als het echt oude hardware is met oude software) ook minder gebruik maken van alle functies van hun apparaat en daarmee minder data hebben waar misbruik van kan worden gemaakt.

Edit2: ik bedoel dus niet of het op grote schaal te misbruiken is, maar of het misbruiken wel wat op gaat leveren. Ergens inbreken waar niks te halen heeft, heeft weinig zin.

Edit3: Voor mensen die niet duidelijk zien dat het hier om een SOP bug gaat waarbij cookies een minimale rol spelen: cookies spelen dus een minimale rol. XSS krijgt met deze bug een aanzienlijk eenvoudigere vector, gratis en voor niets, waarmee je overal code kan injecteren waar je maar wil. Dus ook code om inputs ui te lezen en via een XHR naar een server te sturen. Dus als je er puur vannuit een beveiligingsperspectief naar kijkt is de aanval niet heel veel anders dan een gemiddelde XSS die je al sinds het bestaan van javascript kan uitvoeren. Kijk even op https://www.owasp.org/ind...ilter_Evasion_Cheat_Sheet hoe je dat bijv. zonder SOP bug doet, en hoe je eigen browser daar tegen kan. Cookies zijn hier je minste probleem. Maar het is wel interessant om te onderzoeken wat voor bruikbare data er in cookies staat (en dan bedoel ik niet sessies of ID's) gezien je die nu vrij onschuldig mee kan nemen zonder meteen compleet in te breken.

[Reactie gewijzigd door johnkeates op 24 juli 2024 09:49]

[johnbetonschaar]

Stel dat een gebruiker met een ongepatcht apparaat rondloopt, dan is dat waarschijnlijk geen poweruser / tweaker gezien die groep vaak richting de custom ROMs gaat of nieuwe hardware koopt. Mensen die met oude hardware blijven zitten zullen dan misschien (als het echt oude hardware is met oude software) ook minder gebruik maken van alle functies van hun apparaat en daarmee minder data hebben waar misbruik van kan worden gemaakt.

Denk je nu serieus dat al die goedkope Android toestellen die de afgelopen jaren zijn verkocht en al lang niet meer gesupport worden, alleen maar worden gebruikt door oude oma'tjes die er alleen mee bellen? Het enige wat je hoeft te doen om vatbaar te zijn voor deze exploit is a) een Android telefoon die geen 4.4 draait, en b) de stock browser gebruiken. En dan denk jij dat er maar weinig mensen vatbaar zijn, omdat iedereen met een kwetsbaar toestel vast wel een poweruser is en dus zelf even een custom ROM of een andere browser installeert, of zijn telefoon gewoon helemaal niet gebruikt om af en toe een website te openen? Echt een niet te volgen redenering dit, hoe kom je er op vraag ik me dan af?

Edit2: ik bedoel dus niet of het op grote schaal te misbruiken is, maar of het misbruiken wel wat op gaat leveren. Ergens inbreken waar niks te halen heeft, heeft weinig zin.

Je zou eens moeten weten hoeveel mensen gewoon voor elke internet dienst hetzelfde wachtwoord gebruiken omdat ze het anders niet kunnen onthouden. Als die een keer inloggen op de website van de voetbalpoule of op het Viva forum (om maar iets te noemen) en je weet het wachtwoord te ontfutselen via wat slimme Javascript dan zijn zulke personen al kwetsbaar voor veel groter leed. Je hoeft 'de kraak' natuurlijk niet via de browser van de telefoon zelf uit te voeren, als je de sleutel hebt ben je al binnen...

[Reactie gewijzigd door johnbetonschaar op 24 juli 2024 09:49]

[RebelwaClue]

De exploit kan geen wachtwoord onthutselen. Het kan alleen sessiegegevens uitlezen en overnemen die openstaat. Maar niet de wachtwoorden uitlezen. Natuurlijk nog een kwalijke zaak. Stel je hebt webmail open in een andere venster, kan de exploit mails lezen en versturen van de andere sessie. Maar geen wachtwoorden lezen. Als je dus ook verder geen sessies open hebt staan, kan het zelfs niks.
Neemt niet weg dat het een bug is die wel degelijk aangepakt moet worden en ben er bang voor dat dit niet 123 zal gebeuren. Als het uberhaupt al gebeurt.

[johnbetonschaar]

De exploit kan geen wachtwoord onthutselen. Het kan alleen sessiegegevens uitlezen en overnemen die openstaat.

Wellicht niet direct, maar wat ik hierboven ook al schreef, van een exploit die het mogelijk maakt om gegevens uit een andere tab, venster of iframe uit te lezen naar een gespoofde website die de gebruiker zijn wachtwoord laat intiepen, is geen grote stap natuurlijk.

[RebelwaClue]

Klopt, een wachtwoord veld kan wel uitgelezen worden en het is ook zeker geen misselijke bug. Vooral voor mensen onder Android 4.0 (boven 4.0 kan je uitwijken naar Chrome). Vraag me ook af hoeveel merken de AOSP browser gebruiken in hun phones.

[johnbetonschaar]

Vraag ik me af waarom? Welk punt probeer je te maken? Je schrijft eerst een hele alinea vol waarin je je afvraagt wat de impact van zo'n kwetsbaarheid is, maar iedereen die er 2 minuten over nadenkt kan zelf wel beoordelen dat als je een toestel waar geen 4.4 of een andere browser op draait, dus gewoon een ontzettend makkelijk doelwit bent. Dat is een hele grote groep mensen. Je veronderstelling dat er 'niks te halen valt' bij mensen met kwetsbare toestellen is niet onderbouwd, en voor mij niet te volgen.

[johnkeates]

Eh. Nee dus. Dat is niet wat er staat en ook niet wat ik bedoel. Ik zie ook niet hoe iemand je daar een +3 voor kan geven.

Ik zeg letterlijk dat een kwetsbaar toestel een kwetsbaar toestel is, maar dat de impact een beetje vaag lijkt te zijn en er noch in de bron noch in het artikel ook maar een regel duidelijkheid probeert te scheppen in dit geheel. Er staat ook een paar keer heel duidelijk het woord 'vraag' in mijn post. Drie keer om precies te zijn. Helemaal bovenin zelfs.

Er zijn totaal geen gegevens bekend over de daadwerkelijke real-world implicatie van een exploit als deze, en het is ook niet te vergelijken met bijv. de firefox extensie die automatisch sessies kan stelen of de wifi-pineapple. Ook javascript injecties via nieuwsnetwerken hebben er helemaal niks mee te maken.

[johnbetonschaar]

Wat ik bedoel te zeggen is dat je geen uber hacker hoeft te zijn om vrij vlot zelf te kunnen verzinnen dat je via dit soort exploits op allerlei manieren misbruik kan maken van kwetsbare toestellen. Als het mogelijk is om sessie cookies en data van websites die open staan uit te lezen is het natuurlijk een kleine stap naar wat slimme Javascript die via social engineering de gebruiker misleidt om zijn wachtwoord in te tiepen in een tab waar jouw exploit code draait, bijvoorbeeld gelanceerd door een banner ad of wat dan ook. Zet een server op die een 1-op-1 kopie van een website in een andere tab opent gebruik makend van de gegevens die je via de exploit kunt uitlezen, en presenteer de login pagina, en dan trap zelfs jij er misschien wel in. Bij slecht beveiligde websites die gebruik maken van session cookies kan ik me ook nog wel wat leuke exploits voorstellen, als jouw javascript met de server kan communiceren alsof je de ingelogde gebruiker bent dan opent dat een wereld van mogelijkheden om websites te spoofen. Als ik als simpele ziel al dat soort scenarios kan verzinnen dan weet een creatieve hacker vast nog vele andere manieren om hier misbruik van te maken.

[johnkeates]

Al mijn posts tot zo ver bij dit artikel gingen van een volledige breach uit, dat je dus op een device alle cookies gelezen en gedownload hebt...

Het punt was nergens of de exploit wel of niet gebruikt kan worden, natuurlijk kan die gebruikt worden. Het ging mij om de feitelijke impact. Ja, je kan dan lekker op iemand's accounts inloggen, maar dan? Gaat iemand een botnet gebruiken om aan de lopende band iedereen te frapen? Je facturen downloaden van een webshop waar je een autologin of sessie cookie van open had staan? Alles met 2-factor auth werkt al niet meer bij inloggen, en alle sessies die UA-gebonden, IP-gebonden, een erg korte timeout hebben of verlopen zodra de browser het tabje dicht heeft zijn ook nutteloos.

Dus nogmaals: wat zou de daadwerkelijke impact zijn? Een scriptkiddie die onder je naam op nu.nl reacties gaat plaatsen? Email inloggen gaat niet werken, dat is allemaal strikt gebonden. Dus daar heb je niks aan. Op z'n best dus de twee meestgebruikte autologin en sessie cookie types: voor webshops en voor reacties/forums. En qua privacy tracking, dat je een gebruiker kan profilen en tsja, dat is het dan wel zo'n beetje.

[Aial0n]

Het aantal gebruikers met vatbare apparaten is natuurlijk groot. Het betreft hier android. De vraag is vooral of ze deze exploit zelf ontdekt hebben, in dat geval staat er waarschijnlijk al wel een beveiligingsupdate klaar. Als iemand anders dit heeft ontdekt dan zou het misbruikt kunnen zijn.

Wat ik ook interessant zou vinden is hoeveel informatie ze denken te kunnen achterhalen. Ik werk niet in de ICT en heb alleen marginaal programmeerervaring, maar ik denk dat er (meestal) weinig interessante dingen staan in cookies. Cookies zijn toch voornamelijk voor sites om terugkerende bezoekers te tracken?

[mad_max234]

Leuk zo'n update alleen als 99% van oude telefoon nooit geen update meer krijgen hebben we er nog niks aan! Grootste fout die google heeft gemaakt, updates overlaten aan fabrikanten.

[RebelwaClue]

Al vraag ik me af wat concreet de impact is. Google Chrome is heeft tussen de 500.000.000 en en 1 miljard installaties. Veel mensen kiezen er toch voor om die te installeren dus.

[Verwijderd]

Die installatie betreffen vooral veel desktop installaties.
Voor veel android mobieltje is Chrome toch niet beschikbaar en gebruikt men gewoon de Android browser.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 09:49]

[RebelwaClue]

Ik denk niet dat de playstore desktop installaties aangeeft
Maar idd, chrome is alleen voor 4.0 en hoger en best wel een kwalijke zaak. Overigens kan je testen op de browser op je telefoon vatbaar is via de website ejj.io/SOP.php als je op test drukt en een alert ziet, ben je de pisang.

[De Ingenieur]

Hear hear! Zit hier met een LG optimus black, waarvan gezegd wordt dat de update naar Android 4 vorig jaar is uitgekomen maar welke ik niet kan installeren. Ik zit momenteel op (jawel) 2.2.2. Dit jaar gaat er wel een nieuwe telefoon komen.

[Vizzie]

Wees dan zo slim een Nexus te kiezen als je verknocht bent aan Android Kies anders een telefoon waarbij het OS onafhankelijk van de telefoonbouwer geupdate kan worden.

[Aaargh!]

Nexus toestellen krijgen ook maar 18 maanden updates. Dus als je het toestel onmiddellijk bij release koopt heb je maar anderhalf jaar updates. Lekker als je er een 2 jarig contract bij hebt. Koop je 't toestel een paar maand later zit je gewoon een jaar lang met een onveilig toestel.

Vergelijk dat met Apple die gewoon 4 jaar lang updates blijft leveren. Tegen de tijd dat de 18 maanden support voor de Nexus is afgelopen heeft een Apple toestel nog 30 maanden support over.

[Reactie gewijzigd door Aaargh! op 24 juli 2024 09:49]

[calvinturbo]

Nee, dat klopt niet. Nexus toestellen krijgen minimaal 18 maanden updates. De oude Galaxy Nexus kreeg geen updates door z'n processor.

[Aaargh!]

Niet minimaal, gewoon 18 maanden. Zie hier

[Reactie gewijzigd door Aaargh! op 24 juli 2024 09:49]

[calvinturbo]

Devices may not receive the latest version of Android if they fall outside of the update window, traditionally around 18 months after a device release.

May not betekent niet dat het altijd 18 maanden is, daarna garanderen ze het alleen niet meer.

[Aaargh!]

In praktijk betekend het gewoon geen updates meer. Let maar op, de Nexus 4 (bijna 2 jaar oud) gaat geen update krijgen naar Android L. De preview-images van Android L zijn ook alleen voor de Nexus 5 en 7 beschikbaar.

[calvinturbo]

Het klopt dat de preview-images alleen daarvoor beschikbaar zijn maarrrrr
nieuws: Broncode wijst erop dat Nexus 4 en 7 uit 2012 Android L-update krijgen

[Vizzie]

Mee eens, ik blijf waarschijnlijk ook gewoon bij Apple als ik weer aan een nieuwe telefoon toe ben.

Maar bij de Nexus toestellen heb je tenminste die garantie van 18 maanden. Volgens mij is het bij alle andere Android toestellen een kwestie van geluk of pech. Dus als ik de overstap zou maken (of al op Android zou zitten en er niet vanaf zou willen) zou ik voor een Nexus gaan.

[Verwijderd]

Ach, de Nexus 7 LTE heeft nog steeds geen 4.4.4, en draait dus 4.4.3 met OpenSSL vulnerability er nog gewoon in...

https://developers.google.com/android/nexus/images#razorg
http://aosp.changelog.to/aosp-KTU84M-KTU84P.html

[Thommity]

Ja, wat ben ik blij met mijn Galaxy Nexus, geen 4.4 update.

[Verwijderd]

Ik heb een lenovo tablet met oorspronkelijk 4.2.2 waarvoor ik een update kreeg naar 4.4.2, en het apparaat werd voor 60% onbruikbaar voor mij. Geen of nauwelijks nog bestandsbeheer, en kan niets meer downloaden, dan heb je dus wat! Nee, dan liever een mogelijk hackeble ding erin en bruikbaar. Gelukkig wil Lenovo hem voor mij terugzettenńnaar4.2.2, dan kan ik tenminse wat met m' n tablet.
Veiligheid is leuk, maar moet niet gaan overheersen (zie windows vsta). Als je veiligheid als belangrijkste ziet, moet je GEEN smartfone of tablet gebruiken.

[Verwijderd]

Blame Texas Instruments for that.

[oef!]

Das helaas de schuld van Texas instruments. http://www.engadget.com/2...ogle-galaxy-nexus-kitkat/

Maar het blijft natuurlijk gewoon prut.

[MsG]

Het is natuurlijk geen oplossing voor de brakke update-methode van Google, maar hier zijn tientallen custom roms, die je toestel vaak nog een tweede leven geven: http://forum.xda-developers.com/optimus-black/development

[divvid]

precies, ik heb eindelijk een Cyanogenmod 11 rom op m'n oude HTC explorer weten te zetten. Supersnel t.o.v. A2.2.1 maar toch... browser werkt niet goed, andere dingen als microfoon haperen, gapps deed het ook niet echt lekker...niet echt een oplossing dus. Daarnaast, zelfs als behoorlijk doorgewinterde tweaker kostte het me een hele dag neuzen in obscure fora om het aan de praat te krijgen, en dan nog niet eens de laatste versie, want die deed het niet.

Als je niet een gewilde phone hebt is C11 ook niet echt een optie, laat staan voor jan met de pet met een Argos van de Aldi en nul verstand van zaken.

[SV_25]

Je hebt gelijk. Ik had dan ook gehoopt dat ze dit probleem wel zouden inzien met hun L release, maar daar zit niks van in. Zeer spijtig want er is niets dat dit technisch tegenhoud. (Iets als een update voor google play services in combinatie met het xposed-framework implementatie?)
Ik hoop dan maar dat meerdere smartphone fabrikanten het 'One' concept volgen waarbij het google zelf is die de software maakt. Spijtig genoeg is het een serie die niet snel in het Westen zal verschijnen (en voor ons relatief slechte specs hebben).
On topic: wie gebruikt er eigenlijk die stock browser nog?

[Verwijderd]

Grootste fout die google heeft gemaakt

Het eeuwige probleem.

Aan de ene kant van de brug staat een kudde te roepen dat Google er met de Play-services en G-Apps voor heeft gezorgd dat Android niet meer open is en dat er veel meer in de AOSP versie moet zitten.

Aan de andere kant van de brug staat een groep te roepen dat Google niet genoeg regie houdt en dat teveel wordt overgelaten aan de fabrikanten die AOSP apps aanbieden.

Er is kennelijk geen perfect antwoord, anders dan dat fabrikanten hun verantwoordelijkheid moeten nemen. Wat ik eerlijk gezegd betwijfel of dat gaat gebeuren. Een paar misschien, maar de meesten zullen het zien als vervangingsstimulans.

[johnkeates]

Cookies bevatten meestal geen boeiende dingen. Op z'n best kan je er sessies uit hijacken en gebruikers profielen op basis van hun ID's. De data zelf is niks waard, het zijn eigenlijk altijd referenties.

[-weenie-]

In een cookie kan wel automatische login gegevens staan... Dus dan hoef je niet eens een sessie te hijacken... dan kan je gewoon een sessie opstarten.

[vide]

Als je gebruikersnaam en wachtwoord in een cookie steekt, dan ben je wel heel slecht bezig. Maar het zal ongetwijfeld gebeuren

Maar een ingevulde gebruikersnaam of wachtwoord komt normaal gezien van je webbrowser (inloggegevens bijhouden optie).

[-weenie-]

Ik doel meer op de optie van veel websites met : "Hou me voor altijd ingelogd" Dat wordt dan veelal in een cookie geslingerd (een hash/random-unieke waarde die verwijst naar een user-id in de database) of whatever. Dan heb je geen wachtwoord en username nodig.

Tenzij dat cookie dan weer aan meer info is gekoppeld, zoals ip van herkomst, browser/os etc. De implementatie is niet overal even uitgebreid als bij T.net :-)

[Armin]

Het is vaak een (AES 128) encrypted token. Probleem is echter als ik die data as-is kan lezen, ik die soms kan gebruiken om mij te authenticeren zonder de token zelf te hoeven decrypten.

En IP/browser/etc beveiliging helpt in dit geval niet, want het is mijn Android telefoon die het verzoek uitvoert. Immers wat kan gebeuren is het volgende:

- jij bezoekt site X
- die haalt jouw cookie voor site Y op uit je database
- javascript van site X uitgevoerd door jouw browser logt in op site Y

Site Y ziet geen verschil tussen een gewone login en deze login. Het is namelijk jouw telefoon die het verzoek uitvoert.

GMail werk bijvoorbeeld zo. Denk dus aan het mogelijk versturen van spam indien je je niet handmatig uitgelogd had (iets wat Google explicieit ontmoedigd).


Daarnaast zijn er legio sites die veel brakkere security hebben met unencrypted passwords, gebruikersnaam gewoon opslaan, etc. Dan ga je gewoon helemaal nat, en hoeven ze de data enkel naar de 'thuisbasis' te sturen.

Plus zoals ik hoger schreef, gewoon lekker dataminen. Cookies bevatten soms een schat aan persoonlijke informatie. Iedere ramdom site kan al die data nu dus lezen.

[RebelwaClue]

Als je in een cookie de login gegevens hebt staan, dan kan je je beter zorgen maken over de websites die je komt. Een login cookie zou geen unencrypted wachtwoord mogen staan.

[Patriot]

Als je in een cookie de login gegevens hebt staan, dan kan je je beter zorgen maken over de websites die je komt. Een login cookie zou geen unencrypted wachtwoord mogen staan.

Dat is ook niet wat hij zei. Je kunt rustig een volledig nieuw referentienummer aanmaken, opslaan en de volgende keer bij het treffen van een cookie van dat nummer een sessie voor een bepaalde gebruiker starten. Wachtwoordverificatie in die situatie slaat eigenlijk sowieso nergens op.

[Verwijderd]

Ik hoop wel encrypted, maar je weet maar nooit

[Isheara]

Het gaat dus om 75% van de actieve gebruikers dat last heeft hiervan.

http://m.androidcentral.c...ne-quarter-active-devices

Blijkt toch een lastig probleem te zijn.....aangezien de adoptie van de laatste versie van het OS niet erg groot is, zoals bij bv iOS.

[Verwijderd]

Ik denk toch een stuk minder. De fout zit in de stock browser. Niet alle gebruikers van een oude versie van Android zullen die gebruiken. Er zullen toch best wat mensen zijn die Chrome of Opera gebruiken.

Verder blijkt ook uit onderzoeken dat het online marktaandeel voor Android vrij laag ligt. Android en iOs maken elkaar daar maar weinig. Daaruit kan je de conclusie trekken dat op veel Android toestellen maar weinig wordt geïnternet.

Ik zal vanavond eens op de tablet van mijn vriendin kijken of ik cookies in Chrome en/of Internet kan vinden en hoeveel daarvan gevoelig zouden kunnen zijn. Zij is een volslagen a-technische, ik tik op alles, Android gebruiker. Het zal me dus benieuwen.

[vide]

Zolang er reclamebanners mogelijk zijn die scripts injecteren in pagina's, heel veel kans. Hoeveel bekende, grote sites hebben ondertussen al problemen gehad met kwaadaardige advertenties?

[johnkeates]

Ik bedoel niet de exploit kans, maar de kans dat het ook daadwerkelijk wat oplevert. Stel dat je op heel veel apparaten cookies kan stelen, maar die apparaten geen cookies hebben om te stelen of alleen de voorkeur voor kattenplaatjes vs. hondenplaatjes, wat betekent de real-world impact van zo'n exploit dan nog?

Dat er geen updates zijn wisten we al, en dat dit precies is waarom versplintering en vendor customisations niet goed zijn ook, maar voor dit soort zaken is het dan juist wel goed om te onderzoeken wat het nou precies betekent voor gebruikers.

[Armin]

Stel dat je op heel veel apparaten cookies kan stelen, maar die apparaten geen cookies hebben om te stelen of alleen de voorkeur voor kattenplaatjes vs. hondenplaatjes, wat betekent de real-world impact van zo'n exploit dan nog?

Dat is net zoiets als vragen, wat nu als ik geen waardevolle spullen in huis heb, hoe erg is het dan als ik de deur niet op slot doe ...

Het probleem is dat bij de meeste telefoons er juist wél waardevolle cookies zijn. O.a. je inlog tokens op websites die je bezocht hebt.

[Patriot]

Stel dat je op heel veel apparaten cookies kan stelen, maar die apparaten geen cookies hebben om te stelen of alleen de voorkeur voor kattenplaatjes vs. hondenplaatjes, wat betekent de real-world impact van zo'n exploit dan nog?

Dat is net zoiets als vragen, wat nu als ik geen waardevolle spullen in huis heb, hoe erg is het dan als ik de deur niet op slot doe ...

Is dat zo een onredelijke vraag dan? Even buiten of ik het eens ben met het idee dat er daadwerkelijk niks aanwezig is, áls dat het geval is dan is er toch inderdaad geen noodzaak tot beveiliging?

[Armin]

Is dat zo een onredelijke vraag dan?

Ja, want het is én een retorische vraag , én: "Het probleem is dat bij de meeste telefoons er juist wél waardevolle cookies zijn. O.a. je inlog tokens op websites die je bezocht hebt."

[Patriot]

Is dat zo een onredelijke vraag dan?

Ja, want het is én een retorische vraag , én: "Het probleem is dat bij de meeste telefoons er juist wél waardevolle cookies zijn. O.a. je inlog tokens op websites die je bezocht hebt."

Ik snap dat je het retorisch bedoelde, maar ik ben het niet eens met de suggestie dat iets wat geen waarde heeft toch beveiligd moet worden.

Dat gezegd hebbende, er is genoeg reden om je zorgen te maken om deze exploit, er zullen naast een hoop waardeloze doelwitten inderdaad ook een boel mensen zijn met cookies van relatief belangrijke websites die geen SSL gebruiken.

[Armin]

Ik snap dat je het retorisch bedoelde, maar ik ben het niet eens met de suggestie dat iets wat geen waarde heeft toch beveiligd moet worden.

Nee, JOUW statement was retorisch,. Jij stelt immers eerst dat een bepaald iets niet waardevol is, en vraagt dan hardop waarom dat uberhaupt beveiligd zou moeten worden. "Duh!"

Echter ... het probleem is dat jouw stelling onjuist is. Cookies zijn wel degelijk waardevol want bevatten allerei informatie. Enkele voorbeelden jouw emailadres, wachtwoord, gebruikersnaam, etc.

Lijkt mij extreem evident dat je dat niet in handen van een willekeurige website wil laten komen.

Er is een reden waarom cross-domain cookies inherent onmogelijk horen te zijn. Dit is dus een veiligheidslek die het fundament van cookie-security breekt.

[Patriot]

Ik snap dat je het retorisch bedoelde, maar ik ben het niet eens met de suggestie dat iets wat geen waarde heeft toch beveiligd moet worden.

Nee, JOUW statement was retorisch,. Jij stelt immers eerst dat een bepaald iets niet waardevol is, en vraagt dan hardop waarom dat uberhaupt beveiligd zou moeten worden. "Duh!"

Nee, ik vroeg me letterlijk af of je dat zo onredelijk vond. Je stelde de vraag (moet de deur nog op slot als er niets waardevols binnen is) op zo'n manier dat het leek alsof je het antwoord evident vond. Bovendien had ik daarvoor nog niets gezegd

Echter ... het probleem is dat jouw stelling onjuist is. Cookies zijn wel degelijk waardevol want bevatten allerei informatie. Enkele voorbeelden jouw emailadres, wachtwoord, gebruikersnaam, etc.

Informatie die er allemaal in zou kunnen staan, maar dat hoeft niet. Nogmaals, ik ben niet van mening dat dit een ongevaarlijk lek betreft, maar iemand vraagt zich hardop af of het wel zo gevaarlijk is als er niets te halen valt, en je reactie is om te doen alsof het schier onmogelijk is dat er geen nuttige informatie in cookies staat. Dat vind ik een beetje vreemd, want dat kan gerust.

[Armin]

Bovendien had ik daarvoor nog niets gezegd

Ja, ik verwarde je inderdaad met iemand anders.

Informatie die er allemaal in zou kunnen staan, maar dat hoeft niet. Nogmaals, ik ben niet van mening dat dit een ongevaarlijk lek betreft, maar iemand vraagt zich hardop af of het wel zo gevaarlijk is als er niets te halen valt, en je reactie is om te doen alsof het schier onmogelijk is dat er geen nuttige informatie in cookies staat. Dat vind ik een beetje vreemd, want dat kan gerust..

Inderdaad dat kan gerust. Dat was echter niet de indruk die ik kreeg van 'johnkeates'. Die vroeg om 'real world' impact indien er niets waardevols stond. Dan is het inderdaad per definitie nul.

En voor veel gebruikers zal dat wellicht zo zijn. 'johnkeates' suggereerde in andere posts lager in eerste instantie dat het allemaal wel meevalt in zijn algemeenheid. Deels omdat hij in het probleem van sessie cookies niet helemaal snapte, maar ook daarna bleef bij het bagataliseren. En daar agiteer ik tegen, omdat het gewoon onwaar is.

En het dan vaag doen over 'real world impact' vind ik bovendien een stropop, want het is juist afhankelijk van de gebruiker zijn gedrag.

Probleem is echter dat die gewone gebruiker dat zelf moeilijk kan inschatten omdat die geen enkele idee heeft wat er in cookies opgeslagen wordt. Cookies bevatten soms totale bagger, soms echter privacy gevoelige data en in weer ergere gevallen zelfs directe inlogcodes. Nu dat dus allemaal onbeschermt is, is het dus een potentieel gevaar dat je juist als eindgebruiker vrijwel niet kunt inschatten.

Telebankieren via een browser of bij paypal inloggen is bijvoorbeeld kwetsbaar indien een willekeurig ander tabje open staat. Dus dan maar niet meer telebankieren zonder alle andere tabs te sluiten?

En GMail en Hotmail en aanverwante diensten zijn nog meer vatbaar via hun permanente cookies. Dan moet je dus alle cookies gaan wissen na gebruik van die diensten?

En dat een willekeurige reclame banner jouw emailadres kan uitlezen uit een cookie, moeten we maar accepteren zolang er geen uitgevoerde exploit is?

Bovendien gaat het ook om apps die de browser als module gebruiken, die potentieel data opslaan in cookies.

Non-Tweaker kan ik enkel het advies geven, gebruik een andere browser (totdat er wellicht een update komt), juist omdat de potentiele ik 'real world impact' zo groot is.

[Patriot]

Overigens lijkt me dat je niet zomaar bij cookies kunt die over een ssl verbinding zijn gezet, hoewel je daar waarschijnlijk wel weer omheen kunt werken door de gebruiker via een ssl verbinding met self signed certificaat te sturen.

Je advies om de stock browser niet meer te gebruiken vind ik natuurlijk wel een hele goede!

[Armin]

Overigens lijkt me dat je niet zomaar bij cookies kunt die over een ssl verbinding zijn gezet,

Via deze exploit dus juist wel!

Immers het is jouw eigen browser (of app die het browser framework gebruikt) op jouw telefoon, die de cookies uitleest. Hoe die cookies gezet zijn (SSL of niet) maakt dan niet uit, want is enkel het transport. Het is jouw eigen browser die ze doodleuk afgeeft aan een willekeurige site vanaf jouw disk.

Nu kan de cookies inhoud zelf wel encrypted zijn. Dan kun je de content niet uitlezen, maar dat hoeft dus in veel gevallen niet. Bij sessie-cookies stuur je immers de (encrypted) content zelf op via een verborgen iframe of zo, en je krijgt direct toegang.

Op de epxloit pagina staat er al een voorbeeld met GMail/Google.

[Patriot]

Ik bedoel meer dat de website zelf over een niet-ssl verbinding ook niet bij ssl-cookies kan, zou dus een dubbele fout zijn als dat ook kan.

[Armin]

Ik bedoel meer dat de website zelf over een niet-ssl verbinding ook niet bij ssl-cookies kan, zou dus een dubbele fout zijn als dat ook kan

Dat kan dus wel! Dat is nu net het enge ...

Een van de diverse mogelijkheden:
1) Jij maakt een SSL connectie met GMail
2) GMail zet een encryped sessie cookie neer
3) Later maak jij een verbinding met website X die een advertentie met kwaadaardig script laadt van domain Y.
4) Het kwaadaardige script (*) leest het GMail cookie uit en maakt in een verborgen iframe een connectie met GMail en kan zo inloggen.

SSL protectie heeft dus geen enkel effect, want de kwetsbaarheid zit in jouw browser. SSL beschermt enkel de verbinding over het internet.

*) uitgevoerd door jouw browser en dus vanuit jouw IP.

[Patriot]

Ik doelde op cookies met de secure-flag. Die bestaan in feite alleen in een ssl context, zou het al bijzonder vreemd vinden als je daar bij kan op een niet beveiligde pagina.

Daarnaast zouden bepaalde cookies van dergelijke websites sowieso httpOnly moeten zijn. Hoewel ik me afvraag of de stock browser op Android daar iets mee doet.

[Armin]

Ik doelde op cookies met de secure-flag. Die bestaan in feite alleen in een ssl context, zou het al bijzonder vreemd vinden als je daar bij kan op een niet beveiligde pagina.

Dat weet ik dat je die bedoelde, maar daar kun je dus gewoon bij. Dat is nu net de ernst van dit lek.

Een niet-beveiligde pagina, kan dus cookies van een beveiligde website lezen.

Daarnaast zouden bepaalde cookies van dergelijke websites sowieso httpOnly moeten zijnn

Het punt is dat de opslag/het opvragen van die cookies een lek heeft. Dus hoe ze op jouw apparaat komen en of ze encrypted zijn maakt dus geheel niets uit. Cookies die over een HTTPS SSL/TLS verbinding op jouw telefoon komen zijn net zo kwetsbaar als gewone cookies. En of ze encrypted zijn maakt ook niet uit (al maakt het het gebruik van de inhoud uiteraard soms wel wat lastiger).

Elke willekeurige website kan dus alle cookies via dit lek uitlezen.

[Patriot]

Ik doelde op cookies met de secure-flag. Die bestaan in feite alleen in een ssl context, zou het al bijzonder vreemd vinden als je daar bij kan op een niet beveiligde pagina.

Dat weet ik dat je die bedoelde, maar daar kun je dus gewoon bij. Dat is nu net de ernst van dit lek.

Een niet-beveiligde pagina, kan dus cookies van een beveiligde website lezen.

Daarnaast zouden bepaalde cookies van dergelijke websites sowieso httpOnly moeten zijnn

Het punt is dat de opslag/het opvragen van die cookies een lek heeft. Dus hoe ze op jouw apparaat komen en of ze encrypted zijn maakt dus geheel niets uit. Cookies die over een HTTPS SSL/TLS verbinding op jouw telefoon komen zijn net zo kwetsbaar als gewone cookies. En of ze encrypted zijn maakt ook niet uit (al maakt het het gebruik van de inhoud uiteraard soms wel wat lastiger).

Elke willekeurige website kan dus alle cookies via dit lek uitlezen.

Ik heb het even uitgezocht, want dat speculeren van mijn kant levert zo weinig op. Secure cookies zijn, zoals je al zegt, inderdaad uit te lezen. Cookies met een httpOnly-flag zijn niet uit te lezen: Toegang vanuit javascript is sowieso niet mogelijk, ongeacht of de SOP goed wordt nageleefd.

[johnkeates]

En hoe zijn die tokens waardevol? Of, hoe waardevol zijn die tokens? Iedereen gilt meteen over auth. enz., maar niemand komt met concrete voorbeelden.

[Armin]

Je kunt er potentieel mee inloggen. Dus als jij nu ingelogd bent op website X, en gaat vervolgens naar website Y kan die via een script dat cookie uitlezen en gebruiken om een request op website X met jouw credentials uit te voeren. Lekker als het je email is ...

En dan niet alleen website Y, want die vertrouw je wellicht, maar ook die ramdom reclame banners die jij ziet die van talloze vreemde domeinen komen, kunnen bij die cookies.

Daarnaast kunnen we natuurlijk lekker dataminen. Alle informatie die in cookies staat is kwetsbaar. Dus ook jouw gebruikersnaam en email die handig opgeslagen zijn voor site A zodat je ze niet elke keer in hoeft te vullen, zijn nu uitleesbaar voor de heel wereld.

Enige methode die dit voorkomt is (automatisch) alle cookies wissen na sluiten van je browser.

[johnkeates]

Joepie, X en Y, waar zijn de voorbeelden? Profilen, minen, hijacking, bla bla bla, als je daar voor 13:30 vandaag mee aan kwam had je nog iets nieuws te vertellen...

Alles kan, maar waar gaan we dit in de praktijk terugzien waar het uitmaakt? Noem eens een site, een applicatie, iets waar de exploit daadwerkelijk schade aan kan richten. Ze zijn er vast zat, maar niemand heeft nog een echt voorbeeld kunnen noemen. Ik kan er al wel een paar bedenken, maar het gaat mij er eigenlijk vooral om dat mensen die alles een beetje na papegaaien even nadenken en iets nuttigs zeggen.

[Armin]

Misschien de link naar de exploit code zoals gegeven eens daadwerkelijk te lezen?

Er staat o.a. een voorbeeld hoe je Google password en login gestolen kan worden. Meer op een presenteerdblaadje en meer duidelijk hoe gevaarlijk deze kwetsbaarheid is, kun je het niet krijgen ...

[johnkeates]

Misschien dat je even moet quoten waar die code staat, want nergens op de AOSP tracker, MFS exploitDB, CVE lijst referenties, of 1337day staat code om met een gestolen cookie een wachtwoord op te halen.

Ik heb de exploit code voor het lezen van cookies al gelezen voor dat het op tweakers.net stond, ze lopen hier erg achter. De mutatie RSS feed op de twee grote CVE sites zijn sneller, en de MSF exploit db autoupdater geeft ook netjes meldingen als er nieuwe kits zijn.

Als we dan toch in detail treden, het gaat vooral om een lek in de SOP die het stelen van cookies mogelijk maakt. Je kan er eigenlijk nog wel veel meer mee doen. Bijvoorbeeld zonder vreemde constructies data op andere domeinen manipuleren, lekker je frame of iframe uit wandelen en code injecteren via javascript zonder dat de browser vind dat dat niet mag.

Maar mijn vraag zoals in de fipo is nog hetzelfde: wat zijn gestolen cookies in real world situaties waard?

[Reactie gewijzigd door johnkeates op 24 juli 2024 09:49]

[Armin]

Maar mijn vraag zoals in de fipo is nog hetzelfde: wat zijn gestolen cookies in real world situaties waard?

Ik snap je vraag waarschijnlijk niet. Dat is je immers nu al herhaalde malen duidelijk gemaakt, maar dus nogmaals: bijvoorbeeld in kunnen loggen op jouw GMail account en mail versturen onder jouw naam.

Maar het hangt natuurlijk van de data af. All data die in cookies staat is kwetsbaar. De gevolgen zullen varieren tot 'niets', via het in handen komen van privacy gevoelige data zoals je emailadres doro onbekende websiites tot het kapen van een actieve sessie van je emailprovider of wellicht zelfs actieve banksessie.

Het is allemaal mogelijk. Het ene is makkelijker dan het andere en de tijd zal leren hoeveel er misbruik gemaakt zal worden en waarvoor.

Maar kennelijk wil jij horen dat het allemaal koffiedik kijken is, allemaal speculatie en waarschijnlijk reuze zal meevallen? Immers de potentiele gevolgen van cookie-data uitlezen zijn evident, dus ik snap het punt dat je wilt maken niet.

Als gebruiker zou ik het niet afwachten, en dus gewoon of een alternatieve browser gaan gebruiken of je cookies wissen. De potentieel gevolgen zijn namelijk enorm.

[johnkeates]

Je snapt de vraag inderdaad niet. Ten eerste om dat je nog steeds verwijst naar een ander type exploit dan puur en alleen een cookie die je van device X op je eigen systeem gekregen hebt zoals met de meeste mining gebeurt. Hell, ik kan zelfs een cookie kopiëren van Chrome naar FireFox op m'n computer hier en dan blokkeert Gmail de verbinding direct.

Maar kennelijk wil jij horen dat het allemaal koffiedik kijken is, allemaal speculatie en waarschijnlijk reuze zal meevallen? Immers de potentiele gevolgen van cookie-data uitlezen zijn evident, dus ik snap het punt dat je wilt maken niet.

Dat is nou precies wat ik bedoel. potentiële gevolgen. Waar zijn ze dan? Uiteraard is het niet erg handig dat je nu exploits wat simpeler kan schrijven, maar nieuw zijn ze niet. Daarnaast zijn de gevolgen helemaal niet evident.

Los daar van: natuurlijk moet een gebruiker geen browser gebruiken met een lek als dit, en natuurlijk is het niets iets wat lekker open moet blijven, maar daar gaat het helemaal niet om. Het gaat om het technische aspect van de inhoud van de cookies van een ander apparaat dat je op je eigen apparaat krijgt om daarna doelgericht iets met bepaalde soorten data te doen.

Niet of je een of andere exploit die al bestond nu makkelijker kan uitvoeren. De data in cookies kan gevoelig zijn, maar hoe groot is dat percentage? Hoe veel systemen gebruiken op het moment nog cookies voor iets anders dan identificatie? Hoe groot is bijv. ook de impact van systemen die nu eigenlijk eens bijgewerkt worden?

Nogmaals: dit gaat helemaal niet over het user-facing aspect, dat staat, zoals ik al zei, in de fipo ook redelijk helder.

je cookies wissen. De potentieel gevolgen zijn namelijk enorm.

Dit is een grapje zeker? De onderliggende SOP bug ga je niet omzeilen door je cookies te wissen. Hell, in 99% van de gevallen als je een exploit draait op een target ga je als je van SOP hacks gebruik maakt helemaal geen donder met je cookies doen, maar injecteer je gewoon lekker javascript waar je maar wil. Voor de exploitability voegen cookies nauwelijks iets toe.

[Verwijderd]

bijvoorbeeld in kunnen loggen op jouw GMail account

In theorie zou dat kunnen. Alleen denk ik dat 99% van alle gebruikers Gmail gebruikt via de meegeleverde app. De vraag zal dan ook zijn hoeveel gebruikers internetten via de meegeleverde Internet app, daadwerkelijk ergens inloggen en in hoeverre die cookies vervolgens bruikbaar zijn in gestolen vorm.

Blijven de tracking cookies over die ik, hoe vervelend verder ook, niet echt schokkend kan noemen.

Ik heb het idee dat de real life impact van de bug vrij klein is.

Potentieel heb je gelijk. Het is een heel vervelend lek. Maar naar mijzelf en mijn omgeving kijkend wordt ik er nog niet warm of koud van. De apparaten worden voor meer dan 90% gebruikt voor apps en via Internet voor een toevallig katten videootje via Feesboek. Dat een hacker er achter komt dat m'n meisie bij het legioen van kat video kijkers hoort... Het zij zo.

Neemt niet weg dat ik hoop dat fabrikanten hun verantwoordelijkheid nemen en het lek voor oudere versies van Android dichten.

[Verwijderd]

Lekker als het je email is ...

Mail inzien is niet zo erg.. veel apps krijgen die permissie in android.
Dat men mail kan gaan sturen uit jouw naam is veel erger.
Of men bij je G-account komt, die werkt ook met cookies

[Reactie gewijzigd door Verwijderd op 24 juli 2024 09:49]

[Armin]

Dat men mail kan gaan sturen uit jouw naam is veel erger.
Of men bij je G-account komt, die werkt ook met cookies

Dat zijn dus precies twee voorbeelden wat hiermee kan ...

Op de exploit pagina staat zelfs al een kant-en-klaar script voor 'G-account' toegang.

[johnkeates]

Dat is net zoiets als vragen, wat nu als ik geen waardevolle spullen in huis heb, hoe erg is het dan als ik de deur niet op slot doe ...

Nee, dat is het niet. Als je perse een analogie nodig hebt om het te snappen zou het meer zo gaan:

"Wat als mijn deur op slot is maar de gordijnen open zijn en iemand kan zien dat ze mijn vingerafdruk nodig hebben om het slot te ontgrendelen"

of als we het over profiling hebben:

"Wat als iemand in mijn prullenbak kan kijken en ziet dat ik vaak naar de Jumbo ga om mijn boodschappen te doen en treinkaartjes naar Groningen gekocht heb"

Dat zijn eerder de analogieën waar je naar op zoek bent...

[Armin]

Wellicht zal inderdaad op een bepaalde telefoon geen waardevol cookie te vinden zijn. Net zoals als men inbreekt via een niet afgesloten deur zonder braakschade en je hebt geen waardevolle spullen je ook 'geluk' hebt.

Echter een van de basisprincipes van cookies is dat site A niet de data van site B kan uitlezen. Die cookies van site A kunnen vanalles bevatten van totaal onzinnige data tot jouw gebruikersnaam + wachtwoord. Dat is het punt hier. Niet of en dat cookies soms inderdaad geen waardevolle data bevatten.

Cookies zijn ontworpen om veilig te zijn tegen cross-domein toegang zodat je er potentieel belangrijke data in kunt opslaan. En nu blijkt nu net die fundementele beveiliging op Android niet te bestaan.

[Armin]

Ik mis dan kennelijk geheel je punt?

Jij vroeg of de real world impact groot was. Lijkt mij evident dat die enorm groot is. Waarom zou die immers niet extreem groot zijn? Het is een veiligheidslek van de eerste orde waarbij alles in cookies leesbaar is door iedereen site.

Dat cookies behalve belangrijke data ook enorm veel bagger zoals "de voorkeur voor kattenplaatjes vs. hondenplaatjes" lijkt mij niet echt terzake doende, aangezien het een feitelijkheid is dat ze ook inlogcodes en andere zeer privacy gevoelige data bevatten.

Log je in op GMail/YouTube, staat je GMail token daar. Log je in op Tweakers staat je Tweakers token daar. Staat je email in een cookie gelogd, kan iedere banner je email achterhalen. Etc Etc.

Tenzij je vraag is, bij hoeveel mensen zou dan nu het geval zijn, snap ik dus de relevantie van je vraag niet. En mocht dat je enige vraag is, lijkt mij het antwoord redelijk triviaal: bij het overgrote merendeel van de gebruikers.

Voor de gewone gebruiker is dus enkel het devies: alle cookies altijd legen bij afsluiten van de browser, want dit is een fundamenteel lek in de basis security.

[johnkeates]

Jij vroeg of de real world impact groot was. Lijkt mij evident dat die enorm groot is. Waarom zou die immers niet extreem groot zijn? Het is een veiligheidslek van de eerste orde waarbij alles in cookies leesbaar is door iedereen site.

En daar sla je de plank dan dus volledig mis. De real world impact heeft niks met de technische impact te maken. Ja, een exploit die je in staat stelt om alle cookies te lezen stelt je in staat om... alle cookies te lezen. De impact qua exploit mogelijkheden is inderdaad precies dat. Maar dat is de real world impact niet. Dat zou eerder zijn:

- Alle internet bankieren systemen zijn niet meer veilig
- De 3e wereld oorlog breekt uit
- Al het gras op de wereld wordt opeens oranje

Dat is een real world impact. De impact van cookie data lezen in het algemeen doet niet zo veel. Het is slechts data. Stel dat daar by default iets tussen zit wat wel een bepaalde impact heeft, bijv. gegevens waar je iets mee kan doen wat direct iets doet in de echte wereld (en dus niet iets zachts als user profiling, wat niet leuk is, maar niet echt heel veel echte impact zal hebben - op z'n best gerichtere advertenties).

Dat cookies behalve belangrijke data ook enorm veel bagger zoals "de voorkeur voor kattenplaatjes vs. hondenplaatjes" lijkt mij niet echt terzake doende, aangezien het een feitelijkheid is dat ze ook inlogcodes en andere zeer privacy gevoelige data bevatten.

Je weet duidelijk niks van cookies af. Cookies bevallen geen inlogcodes en andere zeer privacy gevoelige data.

De meest voorkomende cookies zijn:

- Sessie cookies
- Autologin cookies
- Profiling/Tracking cookies
- Voorkeuren cookies

Met sessie cookies kan je als de sessies niet gebonden zijn aan de browser sessie hijacking doen. Dat is best naar. Maar de hoeveelheid sites waar dat nog kan is beperkt tot sites die slecht gebouwd zijn en sites die hele oude frameworks draaien. Alles wat een beetje nieuw is, is by default al beschermd tegen dat type hijacking. Daarnaast verlopen sessies vrij snel, zijn ze gebonden aan een venster/tabblad, en is de data zelf niet meer dan een identifier, een random waarde die ergens in een database verwijst naar een gebruikersauthenticatie.

Autologin cookies bevatten ongeveer hetzelfde als sessie cookies, met het verschil dat ze vaak IP-locked en UA-locked zijn. Zijn ze dat niet, dan heb je geen cookie exploit nodig en is een beetje sniffen al voldoende om ze te misbruiken. Dat geldt overigens ook voor sessies. In beide gevallen betreft deze exploit een nieuwe vector voor een bestaande gebruikte hijacking methode.

Profiling/Tracking cookies zijn over het algemeen al uit te lezen. Daar heb je geen cookie exploits voor nodig. Dan heb ik het over cookies die gezet worden door sociale netwerken, advertentie netwerken, en de giganten als Google, Microsoft en Apple.

Voorkeuren cookies bevatten meestal key/value mapped data. Geen data waar je als inbreker iets mee kan. Ja, je zou de standaardtaal op een website die gekozen is door een gebruiker kunnen achterhalen. Joepie.

Verder zijn de cookies waar je het meeste last van kan hebben bij een hijack ook de cookies die automatisch al gewist worden door je browser zodra je een venster of tabblad sluit. Dat zijn sessie cookies. Die zijn dan ook (zoals ze heten) slechts voor een sessie geldig.

Log je in op GMail/YouTube, staat je GMail token daar. Log je in op Tweakers staat je Tweakers token daar. Staat je email in een cookie gelogd, kan iedere banner je email achterhalen. Etc Etc.

Ja, en specifiek aan die voorbeelden heb je niks. Ten eerste om dat Google en de bijbehorende diensten cookies vanaf een apparaat alleen accepteren als de user agent klopt en als het IP adres bekend is. Anders moet je je opnieuw aanmelden.

Kijk bijvoorbeeld eens op https://secure.tweakers.net/my.tnet/sessions waar je al je tweakers sessies kan zien. Nu doet tweakers volgens mij niet aan IP locking, maar volgens mij wel aan UA locking. Stel dat ik dus jouw sessie steel, dan kan ik daar niks mee om dat ik niet jouw UA heb. Of dat voor tweakers feitelijk geldt weet ik niet. Maar voor Google's services wel, Facebook en Twitter ook, en met hun tonnen andere relevante sites.

Met andere woorden (opgesomd):

- Ja, duh, cookies stelen betekent ook sessies stelen
- Sessies stelen kon al
- Sessies en email adressen stelen via ad banners kon al
- Supercookies gebruiken die gebruikers niet kunnen wissen kon al
- De sites waar je echt problemen mee krijgt als je sessies gejat worden hebben bescherming tegen het hijacken van sessies

Dus, nu we daar eindelijk voorbij zijn (als je het nu dan snapt):

Wat is de real world implicatie van het lezen van alle cookies? Wat gaat er gebeuren voor de gebruikers? Wat gaan feitelijke scenario's zijn die negatief uitpakken voor de gebruikers?

Op het moment is het gewon wat theorie en wat feitjes en een nieuws artikeltje (waarbij ook even vermeld moet worden dat het wel heel selectief gebeurt - kijk eens op de CVE lijst van MITRE, die wordt dagelijks aangevuld en daar hoor je niemand over), maar nog geen effect in de echte wereld. Nog geen massa's gebruikers die ergens last mee hebben. Het komt uiteraard, want die is al in MSF meegenomen en dus ook voor scriptkiddies in handbereik. Huur even een uurtje op een botnet en je hebt meer cookies dan je ooit op zal kunnen eten. Maar dan nog: Wat gaan we hier van terugzien? Welke sites zijn er op het moment waarbij een sessie of login hijack tot grote problemen gaat leiden? Namen, domeinen, gebruiksscenario's, dat is waar het om gaat bij real world implications.

[Reactie gewijzigd door johnkeates op 24 juli 2024 09:49]

[Armin]

Ja, en specifiek aan die voorbeelden heb je niks. Ten eerste om dat Google en de bijbehorende diensten cookies vanaf een apparaat alleen accepteren als de user agent klopt en als het IP adres bekend is. Anders moet je je opnieuw aanmelden.

Ah, dat is dus wat je mist! De exploit vind afhankelijk van het soort script dat gebruikt wordt, plaats vanaf jouw browser en dus jouw IP. Je kaapt immers potentieel de actieve sessie ...

Al die beveiligingen falen dus.

[Laurent]

Kijk bijvoorbeeld eens op https://secure.tweakers.net/my.tnet/sessions waar je al je tweakers sessies kan zien. Nu doet tweakers volgens mij niet aan IP locking, maar volgens mij wel aan UA locking. Stel dat ik dus jouw sessie steel, dan kan ik daar niks mee om dat ik niet jouw UA heb. Of dat voor tweakers feitelijk geldt weet ik niet. Maar voor Google's services wel, Facebook en Twitter ook, en met hun tonnen andere relevante sites.

Als je dan toch met JavaScript gericht cookies van een ander domein aan het verzamelen bent, kun je net zo goed de UA opslaan. Dat is een koud kunstje. Die beveiliging houdt geen stand.

- De sites waar je echt problemen mee krijgt als je sessies gejat worden hebben bescherming tegen het hijacken van sessies

Hierboven wordt ook verwezen naar GMail als werkend voorbeeld. Dit is dus niet waar.

[Reactie gewijzigd door Laurent op 24 juli 2024 09:49]

[johnkeates]

Als je dan toch met JavaScript gericht cookies van een ander domein aan het verzamelen bent, kun je net zo goed de UA opslaan. Dat is een koud kunstje. Die beveiliging houdt geen stand.

Uiteraard, dat houdt dus wel in dat de complexiteit van een geautomatiseerde aanval op grote schaal omhoog gaat en in de praktijk dus twee keer zo lang gaat duren. Geolocatie is dan wel weer een ander probleem.

Maar goed, we schetsen hier een grote bak verzamelde cookies, niet devices of local exploits. In de meeste gevallen zal je altijd moeten terugvallen tot bestaande XSS en XSRF aanvallen en heb je eigenlijk niks aan puur en alleen cookies. Ja, het maakt het voor lokale exploits ietsje eenvoudiger met programmeren, maar het is niet alsof je nu opeens een deur opent die er eerst niet was. Op 1337day kan je al jaren exploit code inzien die prima zonder SOP hack werkt. Ik zit dus vooral te zoeken naar de oh-zo-grote-impact van gestolen cookies. En dat is dus niet bestaande aanvallen, want.. die bestaan al!

Hierboven wordt ook verwezen naar GMail als werkend voorbeeld. Dit is dus niet waar.

Dat is dus niet helemaal waar. De verwijzing gaat niet op voor de vraag hoe je met enkel een gestolen cookie kan inloggen. De verwijzing is namelijk een local exploit, javascript injection (door dezelfde SOP bug) en je run-of-the-mill keylogging. Eigenlijk heeft dat helemaal niks meer met cookies te maken gezien usernames en passwords gewoon rechtstreeks uit de invoervelden gelezen worden.

[redecal]

sja, dit icm hacken van een advertentie netwerk en je kan dan best wel wat schade aanrichten lijkt me. ook omdat dit waarschijnlijk voor veel tablets zal gelden.

[redecal]

er zijn het verleden toch genoeg advertientie netwerken gehacked? en je vergeet dat een hoop mensen slechte wachtwoorden gebruiken voor bijna al hun diensten. als je dan een cookie kan kapen met bv:

user: [e-mail]
passw: 12345678

kan je waarschijnlijk ook in zn hotmail. er zijn namelijk genoeg sites die brak in elkaar zitten (paar jaar geleden was er zoiets gebeurd bij smulweb.nl) en er zijn ook genoeg websites met oude unsalted wachtwoorden waar alleen een md5 omgegooid is. site is opgeleverd, developer onderhoudt het niet meer want de site eigenaar denkt: werkt toch? ik ken genoeg van dat soort gevallen.

dan kan je met ogenschijnlijk iets ongevaarlijks toch aardig wat frauderen.

[johnkeates]

Nee. Dit heeft niks met advertentienetwerken te maken of met cookies. De aanname dat alle cookies door een aanvallende partij gelezen zijn hadden we al gemaakt, maar daarna? Welke sites zijn vatbaar? Hotmail en Gmail en eigenlijk alle multinational-hosted applicaties kan je vergeten, die zijn allemaal UA/IP/Geo/Sessie locked, of hebben 2-factor auth. Noem eens iets wat slecht beveiligd is en waar daadwerkelijk schade ontstaat. Waar ligt die grens? Waar zijn de voorbeelden? Usernames en Passwords staan niet in cookies, dus dat kan je alvast vergeten. Misschien niet als je een injection op een pagina doet waarna je textboxes kan uitlezen (en daarmee usernames en passwords), maar dat is niet de vector waar dit verdraaide artikel over gaat.

[Armin]

Hotmail en Gmail en eigenlijk alle multinational-hosted applicaties kan je vergeten, die zijn allemaal UA/IP/Geo/Sessie locked, of hebben 2-factor auth.

Gmail is dus bijvoorbeeld wél kwetsbaar!

De truc is nu net namelijk dat je huidige sessie ook gekaapt kan worden in sommige gevallen ...

En 2FA (als je het aan hebt staan) helpt dus ook maar beperkt, want hét idee achter cookie-tokens is nu net dat je het inloggen niet hoeft te doen.

2FA helpt wel enigsinds, indien of de sessie expired, or indien de site niet toegankelijk is met het sessie token. Een goed voorbeeld is de account-pagina van Hotmail. Je moet je dan expliciet een her-authentciatie met 2FA doen. Maar spam-email uit jouw naam versturen kan wel gewoon.

[johnkeates]

Ja, maar die sessie kan je dus enkel op hetzelfde apparaat gebruiken.
Als ik in NL op gmail zit en met een IP uit een ander deel van de wereld de gmail pagina refresh (bijv. via een VPN) dan zegt Google dat de sessie niet klopt en dat ik opnieuw moet inloggen. Als ik dan terugga naar mijn NL IP en de pagina ververs gaat ie verder waar ie was.

[Armin]

Ja, maar die sessie kan je dus enkel op hetzelfde apparaat gebruiken.

Ja en? Dat is juist het meest makkelijke voor een aanvaller.

Het is bijvoorbeeld genoeg om snel een dosis spam te versturen.

En zo werd de TLS BEAST attack ook uitgevoerd en dat was reden voor alle banken wereldwijd om hun SSL/TLS configuratie om te gooien en alle software huizen een patch in hun SSL/TLS configuratie op te nemen. En dat was nota bene nog met een aanzienlijk technisch kleiner risico dan dit.

Plus natuurlijk dat zoals aangegeven enkel een voorbeeld is. Alle data uit een cookie is uitleesbaar, en wat er mee kan gebeuren is afhankelijk wat erin staat.

Ik zou niet afwachten wat er allemaal mogelijk is, en ondertussen veel mist en stof opwekken door te roepen dat je conrete voorbeelden wilt hebben en je anders het probleem niet serieus neemt. Het concrete GMail voorbeeld lijkt mij al eng genoeg. Elke website die je bezoekt kan achter de schermen inloggen op jouw account als je niet oppast.

Als jij dat allemaal niet zo spannend vind goed, maar ga niet roepen dat er geen risico is.

[johnkeates]

Waar is dat concrete Gmail voorbeeld dan? Want ik heb het nog niet gezien. Alleen SOP en injection exploits, maar die zijn niet nieuw.

Ja, maar die sessie kan je dus enkel op hetzelfde apparaat gebruiken.

Ja en? Dat is juist het meest makkelijke voor een aanvaller.

Het is bijvoorbeeld genoeg om snel een dosis spam te versturen.

Oh? Is dat zo? Dus stel jij hebt device A, ik device B en een server die jouw cookies naar mijn apparaat overzetten. Daar kan ik dan niet mee inloggen om dat ze gebonden zijn aan jouw UA/IP. En dan? Hoe ga ik daar dan spam mee versturen? Dat is wat Google namelijk doet, die staan je niet toe om binnen een sessie de halve wereld om te reizen om daar met diezelfde sessie iets te doen.

TLS BEAST heeft niet niks mee te maken, net als bijv. eerdere SOP hacks, Heartbleed, MITM, Taps enz. Dit gaat om het gestelde probleem dat iemand's cookies uitlezen de wereld laat vergaan. Niemand komt hier met een voorbeeld of met exploit code.

[redecal]

nee, er zijn genoeg oude sites waar passwords en cookies WEL in staan, jij gaat ervan uit dat elke site goed onderhouden wordt en gebruikers altijd goede verschillende wachtwoorden gebruiken en dat is dus niet zo.

de zwakke schakel is een gebruiker die voor alles hetzelfde simpele wachtwoord gebruikt (dus ook voor zijn online email) en vervolgens op een slecht beveiligde website (die dus ouderwets password in cookie opslaat) registreert. ik heb als ontwikkelaar meerdere websites moeten herbouwen waarbij gewoon email en wachtwoord met alleen md5 eromheen in een cookie stonden. het herbouwen werd niet gedaan vanwege veiligheid, maar omdat na een x aantal jaar de klant een nieuw design wilde.

ik moet je eerlijk bekennen dat ik na de hack bij smulweb, waarbij mijn email en wachtwoord buitgemaakt waren op een hoop andere sites ook mijn wachtwoord heb moeten aanpassen want ondanks dat ik weet wat er kan gebeuren, gebruik ik niet voor elke site hetzelfde wachtwoord.

je kan natuurlijk blijven redeneren dat het niet gevaarlijk is en in een ideale wereld waarbij alle sites inderdaad goed beveiligd zijn is dit ook zo, maar als jij simpelweg iemands email en standaard wachtwoord kan achterhalen kan je gewoon een hoop troep uithalen! in mijn geval was mijn smulweb ww (waar ik overigens bijna nooit iets mee gedaan heb) hetzelfde als op bol.com waar ook al mijn adresgegevens in staan en waar je op acceptgiro kan bestellen. identiteitsfraude is dan ineens wel heel erg makkelijk....

[Reactie gewijzigd door redecal op 24 juli 2024 09:49]

[johnkeates]

Volgens mij snap je net zoals een paar andere mensen hier het punt nog steeds niet:

- Ik redeneer niet dat het niet gevaarlijk is
- Ik redeneer niet dat het geen impact heeft of gaat hebben
- Ik redeneer niet dat het geen security breach is
- Ik redeneer niet dat het geen privacy breach is

Ik stel simpelweg de vraag of mensen een voorbeeld zouden kunnen geven. Dat je dus een site of app noemt die z'n cookies of SOP zo gebruikt dat bij deze bug en bijbehorende exploit iemand in de echte wereld in de problemen zou raken.

Door met

er zijn

aan te komen zeg je eigenlijk dat je iets denkt, maar het niet kan onderbouwen.

Door

jij gaat ervan uit dat elke site goed onderhouden wordt en gebruikers altijd goede verschillende wachtwoorden gebruiken

te zeggen zie ik al dat je dus eigenlijk de meeste posts hier niet gelezen hebt.

[Reactie gewijzigd door johnkeates op 24 juli 2024 09:49]

[Lisadr]

Slechte 24,5% van de gerbuikers die regelmatig Google Play bezoeken hebben Android 4,4 of hoger.

https://developer.android...l?utm_source=ausdroid.net

De meeste Android gebruikers zijn vatbaar voor ernstige privacybug! Dat is wel ernstig! Nog een reden waarom Google fabrikanten moet pushen om hun OS te blijven steunen en niet naar een paar maanden te stoppen met updates.

[koelpasta]

"Slechte 24,5% van de gerbuikers die regelmatig Google Play bezoeken hebben Android 4,4 of hoger."

Maar dit is dus een ontzettend slechte meting van kwetsbare systemen. In werkelijkheid bezoeken mensen met oudere android versies de play store niet omdat de apps niet meer werken.
Het platform van kwetsbare apparaten zou naar mijn inschatting dus veel en veel groter moeten zijn dan 75%.

[Isheara]

Het gaat om 75% van de AKTIEVE devices, dus niet de rommel die in de kast ligt.

http://m.androidcentral.c...ne-quarter-active-devices

[Dorank]

Je hoeft niet handmatig de store in te gaan om in de statistieken te komen, update checks van applicaties triggeren de statistieken. Dus tenzij je betreffende checks hebt uitgeschakeld (de meeste zullen niet eens weten hoe), komen alle devices waar de playstore geinstalleerd is voor in de stats.

[_David_]

Je kan vanaf Android 4.0 Chrome gebruiken en 87,9% heeft 4.0 of hoger

[MadEgg]

Dat kan, maar wie doet dat? Veel mensen zullen niet eens weten dat ze nog een andere browser op hun mobiel kunnen installeren, laat staan dat ze dat gedaan hebben.

[RebelwaClue]

Aangezien de playstore aangeeft dat er tussen de 500 miljoen en 1 miljard installaties al zijn, zijn er nog veel mensen die dat gedaan hebben. Al is tussen de 500 miljoen en 1 miljard niet echt een nauwkeurig cijfer te noemen.

[SidewalkSuper]

Dit is mooie informatie, maar compleet nietszeggend.
Wie informeert de massa die hier niks van weet? Wie snapt dat dit een probleem is? Wie heeft er de mogelijkheid om te upgraden naar 4.0? Wie heeft de mogelijkheid om Chrome te installeren (zie ook mijn verhaal hieronder)? Wie doet het ook werkelijk?

Wat Lisadr hierboven zegt is de enige statistiek die wel relevant is in dit licht. Ongeveer een kwart van de Android-gebruikers is niet vatbaar.

[Verwijderd]

Daar staat netzogoed in de voorwaarden dat je privé gegevens verzamelt mogen worden, en gebruikt om advertenties te personaliseren.

[calvinturbo]

En dat is een probleem want?
Het kan zijn dat jij dat niet prettig vind, maar dat is dus niet per definitie een probleem.

[RebelwaClue]

Vergeet niet dat Chrome niet vatbaar is voor deze bug en Chrome is toch al tussen de 500 miljoen en 1 miljard keer geinstalleerd (volgens de Playstore). Deze mensen zijn dus al veilig ondanks een Android versie onder de 4.4. Maar het is een ernstige bug die opgelost moet worden.

[Aaargh!]

Gezien de historie van OS updates voor Android toestellen betekend dit feitelijk dat ruim 75% van de Android toestellen in de kliko kan.

[Dorank]

Nee, je kan Chrome installeren op 4.x (87.9% van alle telefoons die de Play store hebben) of je kan op 100% van de telefoons een andere browser installeren als default.

[monojack]

Of ook gewoon een reden om Android gewoon links te laten liggen. Hoe lang duurt dit spelletje nu al? Het blijft maar duren en duren en dit is enkel mogelijk omdat de gebruikers geen vuist maken. In plaats dat gebruikers eisen dat veiligheid een prioriteit wordt wentelen ze zich in nepargumenten over :marktaandeel dat de oorzaak zou zijn van al de malware problemen. Niet marktaandeel is de oorzaak, Android is de oorzaak zoals ook duidelijk mogen zijn uit dit mooie voorbeeld alweer.

[ivo1969]

Ik zelf ben een android gebruiker en heb nu nog een s2, dat toestel werkt waarovoor ik hem gebruik goed.
Echter ik draai dus op een verouderde 4.1.2 versie. Ik weet dat je custom roms kan downloaden en installeren, maar wat ik het zwakke van android vind is dat de fabrikanten van smartphones je maar een paar updates geven en dan is het op.

Ik ben dus geen Apple gebruiker, maar overweeg toch sterk over te stappen op apple aangezien je daar in mijn ogen veel langer updates krijgt voor je besturingssysteem

[dimitrimissinne]

Hier (voorlopig) ook nog een S2 op 4.1.2. Een paar maanden na het updaten van die laatst ondersteunde versie heb ik hem teruggeflashed naar 2.3.6 met een originele ROM omwille van slechtere prestaties en een belabberde batterijduur. Maar uiteindelijk toch uit noodzaak weer geupdate naar 4.1.2 omdat verscheidene apps niet meer te installeren waren op die originele (verouderde) software. Een custom ROM is uiteraard een optie maar ook weer niet, want je moet altijd wel ergens een toegeving doen.
Over Android zelf geen kwaad woord, maar die rotzooi die Samsung er van maakt loopt me de spuigaten uit. Alhoewel ik Android zelf (en niet die zware skins) altijd een super besturingssysteem vond/vindt zullen ze bij Google toch eerst orde op zaken moeten stellen vooraleer ik nog een Android toestel overweeg. En dan heb ik het vooral over het aanpakken van fragmentatie zodat over alle Android toestellen (binnen hun segment) een consistentere ervaring te beleven valt, op die manier wordt het misschien ook mogelijk om beter en gemakkelijker updates uit te rollen.

Afgelopen zaterdag heb ik in Lab9 een iPhone 6 besteld en van zodra die binnenkomt vliegt die Samsung zooi onherroepelijk de deur uit!

[Trygve]

Een custom ROM is uiteraard een optie maar ook weer niet, want je moet altijd wel ergens een toegeving doen.

Offtopic: Probeer nou eerst maar een custom ROM uit voordat je daarover gaat oordelen Bijvoorbeeld Cyanogenmod 11 met Xposed framework, dan kun je ontzettend veel naar wens instellen.

[Jeroenneman]

Ja, want je kunt je oude S2 nog vergelijken met een toestel van >700 euro.

Als je een nieuwe S5 of One M8 had gekocht had je ook weer prima verder gekund...

[dimitrimissinne]

Geen idee waar je het vandaan haalt maar ik vergelijk nergens mijn S2 met een nieuwer toestel. Lijkt me ook zinloos om dat te doen.
Ik wil gewoon geen smak geld uitgeven aan een nieuw Android toestel zoals die S5 of One M8 om dan binnen 18 maanden (ondertussen nog een jaar in geval van de vbn) weer met een end-of-life toestel te zitten.

[Aaargh!]

overweeg toch sterk over te stappen op apple aangezien je daar in mijn ogen veel langer updates krijgt voor je besturingssysteem

Google's policy is 18 maanden updates voor een toestel (18 maanden na release v/h toestel, niet 18 maanden nadat je 'm hebt gekocht). Apple heeft nooit aangekondigd hoe lang ze updates geven maar de 4S (3 jaar oud) krijgt nog een update naar iOS 8. Over het algemeen kan je tot 4 jaar na release updates krijgen. De 4S krijgt nog alle 8.x.x updates maar zal over een jaar waarschijnlijk geen iOS 9 krijgen.

[Glashelder]

Bij kritieke bugs echter heeft Apple in het verleden wel vaker updates vrijgegeven voor oudere versies van iOS. Dat er een nieuwere iOS versie uit is wil dus niet 100% zeker zeggen dat Apple je in de kou laat staan.

[_David_]

Je kan Chrome gebruiken vanaf Android 4.0

[F1Tim]

En er zijn er nog zoveel met Android 2.x... Als je daar echt een punt van maakt, kun je nog flashen met Cyanogenmod...
Dit wordt dus misschien een klucht zoals met XP en zijn huidige kwetsbaarheden...

[DinoBe]

Deze overweging was ik deze morgen ook al aan het maken. Mijn Xperia T heeft een paar weken terug de geest gegeven. Dit 'top' toestel uit 2012 krijgt exact 2 jaar release (september 2012) geen updates meer. Al bijna 1 jaar stond er op de site van Sony "Android 4.4 kitkat - under investigation" en dan een paar weken terug is aangekondigd dat de update naar 4.4 er niet zal komen.

Kort samengevat: ze houden je een jaar aan het lijntje om dan leukweg te zeggen: de update komt er niet. De support van het toestel is dus 1 jaar.

IOS 8 komt zelfs nog uit voor de Iphone 4S die gereleased is in oktober 2011...

Ik overweeg echt heel sterk nog een oude of tweedehandse iphone 4S of 5....

[Reactie gewijzigd door DinoBe op 24 juli 2024 09:49]

[chopper88]

Slechte zaak, ben benieuwd hoe Google hierop in gaat spelen gezien de browser niet als opzichzelfstaande entiteit te updaten is.
Hoop dat ze zsm gebruik maken van hun optie om apps op afstand te verwijderen/updaten.

Ik neem ook aan dat dit niet netjes bij Google is gerapporteerd, gezien ik niks terug lees over mogelijke oplossingen of reacties vanuit Google?

[The Zep Man]

Slechte zaak, ben benieuwd hoe Google hierop in gaat spelen gezien de browser niet als opzichzelfstaande entiteit te updaten is.

Play Store wordt ook met veel apparaten meegeleverd op dezelfde manier als de browser en wordt wel actueel gehouden. Technisch kan de browser wel geactualiseerd worden.

De vraag bij Android is echter: wie is ervoor verantwoordelijk? De standaardbrowser wordt aangeleverd door de fabrikant/leverancier van de telefoon en komt vaak uit het Android Open Source Project. Google houdt deze applicatie niet actueel, en zal waarschijnlijk een reactie klaar hebben waarin zij Chrome aanprijzen. Andersom zijn fabrikanten/leveranciers van telefoons ook minder geneigd om hun apparaten actueel te houden na twee jaar, omdat ze ook wel eens een nieuw toestel willen verkopen.

Hierom is het een slecht idee om een gevoelig iets als een browser te koppelen aan (een versie van) een besturingssysteem. Internet Explorer heeft dit in het verleden aangetoond, de Android stock browser toont dit nu aan.

[Reactie gewijzigd door The Zep Man op 24 juli 2024 09:49]

[Neko Koneko]

[...]
Play Store wordt ook met veel apparaten meegeleverd op dezelfde manier als de browser en wordt wel actueel gehouden. Technisch kan de browser wel geactualiseerd worden.

Google Play store is een onderdeel van het Gapps pakket, de stock browser is dat niet.

[The Zep Man]

[...]


Google Play store is een onderdeel van het Gapps pakket, de stock browser is dat niet.

Doet niets af aan mijn opmerking. Aan het einde van de dag is Gapps niets anders als een verzameling programma's die actueel worden gehouden. Individuele programma's (zoals de stock browser) kunnen ook actueel worden gehouden, zelfs als deze meegeleverd zijn met de telefoon. Dat was het commentaar dat ik op chopper88 zijn opmerking gaf.

Wie of wat software actueel moet houden was het tweede punt van discussie waar de tweede alinea van mijn post verder op inging.

[Reactie gewijzigd door The Zep Man op 24 juli 2024 09:49]

[calvinturbo]

Daarom dat tegenwoordig ook Chrome wordt gebruikt, die kan wel geupdate worden door Google.
De stock browser kan dat niet, want dit zat in AOSP en werd ook gecustomiseerd door de fabrikanten.

[Dreamvoid]

Tsja, FirefoxOS heeft het als fundament en ook iOS heeft een zwaar in het OS verzonken browser engine (die voor zowel HTML5 webapps en native apps te gebruiken is). Ook Windows en Windows Phone hebben de JavaScript en HTML5 browserengines als native applicatieframework draaien.

[Reactie gewijzigd door Dreamvoid op 24 juli 2024 09:49]

[The Zep Man]

Tsja, FirefoxOS heeft het als fundament en ook iOS heeft een zwaar in het OS verzonken browser engine (die voor zowel HTML5 webapps en native apps te gebruiken is). Ook Windows en Windows Phone hebben de JavaScript en HTML5 browserengines als native applicatieframework draaien.

Dat het gedaan wordt praat het niet goed. Elk apparaat wat geen beveiligingsupdates meer krijgt zal hierom onderhevig zijn aan veiligheidsgaten zodra deze bekend worden.

Zolang je beveiligingsupdates uitbrengt die nieuwe problemen oplossen is er niets aan de hand. Respectievelijk Mozilla, Apple en Microsoft kunnen hier op inspelen door wel langdurige ondersteuning te geven op toestellen waar hun software op draait.

[Reactie gewijzigd door The Zep Man op 24 juli 2024 09:49]

[Soldaatje]

Het is geen losse app maar misschien kan het toch wel op een andere manier updaten, met Google Play?
Het is wel vervelend inderdaad, een oplossing zou zijn een andere browser te gebruiken, maar niet iedereen zal dit snappen.

[Dreamvoid]

De stock apps worden geupdate via een Android security update, niet via de Store.

[Soldaatje]

Ja, maar ik dacht dat er ook bepaalde updates via de store gepusht kunnen worden naar devices? Dus niet alleen van apps.
Of ik zie het verkeerd.

[Reactie gewijzigd door Soldaatje op 24 juli 2024 09:49]

[RebelwaClue]

Googe Play Services bevatten nu veel API's die geupdate worden los van fabrikanten en providers (in Amerika zetten die er ook nog meuk op). Maar niet alles zit daar in, dus of deze bug aangepakt wordt, is nog maar de vraag.

[Armin]

Het enige devies is dan dus:
- alternatieve browser downloaden en gebruiken, of
- alle cookies altijd wissen bij elke keer afsluiten van de stock browser

[RebelwaClue]

Alleen apps geinstalleerd vanuit de Playstore kunnen worden geupdate en verwijderd op die manier. En er is zeker wel gemeld, maar (nog) geen reactie van Google. Nu zullen ze wel moeten, aangezien ik merk dat het nieuws overal nu te lezen is. Overigens ben ik bang dat de browsers geupdate moeten worden door de fabrikanten zelf en dan wordt het een kwalijke zaak.

[redecal]

sja, was dus toch een goeie call om mn HTC One-X+ aan de kant te gooien en te vervangen voor een Moto-G die wel normaal wordt ondersteund.

Hopelijk worden fabrikanten zoals Samsung en HTC eens afgestraft voor het niet updaten van hun telefoons ipv alleen maar focussen op nieuwe toestellen die ze in de markt willen zetten....

[Jeroenneman]

Je hoeft alleen maar Chrome te gebruiken ipv de stock browser...

[MsG]

Chrome is veel te zwaar voor de meeste smartphones. Maar een minderheid koopt een 600 euro topmodel met 3 dubbele hexacore. Ook hebben heel veel toestellen maar bijvoorbeeld 1GB interne opslagruimte, waardoor dat soort grote applicaties vaak niet eens meer lekker passen.

[Jeroenneman]

Eh...


Zelfs op een oude Galaxy SII gebruik ik naar alle tevredenheid de Chrome browser. Die was eerst inderdaad niet helemaal soepel, maar volgens mij nu prima te gebruiken.

En 1GB interne opslagruimte?
Dat is dan je eigen schuld.
Goedkoop wordt uiteindelijk altijd duurkoop.

[MsG]

"Zelfs op een Galaxy S II"? Dat is een wat ouder topmodel, met specificaties die nog steeds niet onderdoen voor de moderne middenmoot. De gemiddelde 100 - 150 euro middenmoot Android-toestel die volgens mij het grotere spectrum van Android beslaan zijn vaak nog wel minder dan dat. Ik heb een HTC Sensation met vergelijkbare specs als de jouwe, maar de Chrome-browser is toch echt een stuk trager ten opzichte van de ingebouwde browser. Weinig redenen om dan over te stappen voor mij.

[Jeroenneman]

Een wat ouder topmodel?

Dat ding is al 3 generaties uit. Ook al vind ik hem nog steeds prima, ik moet toegeven dat ie gewoon zijn tijd gehad heeft. En tja, dat mensen nog steeds middenmoot telefoons kopen, dat is gewoon niet slim (behalve de Moto G, das echt een nette telefoon).

Binnenkort weer investeren in een Moto X, dan kan die hopelijk weer een paar jaar mee.

[redecal]

dat is wel zo, maar het geeft wel aan dat ondersteuning en updaten van android geen overbodige luxe is. een hoop (oudere) apparaten gebruiken een ietwat aangepaste stockbrowser vanwege performance (asus tf 700, one x/x+ en vast wel meer)

[Verwijderd]

Of een andere browser die wel wordt onderhouden.
Ik heb Dolphin er op staan, en krijg regelmatig updates binnnen. ( op een 4.1.1 apparaat)

[Verwijderd]

Opera Mini is in landen met trage verbindingen en kleine databundels ook vrij populair, door de Turbo modus die Opera biedt. Dat zullen veelal ook toestellen zijn met oudere Android versies denk ik.

[SidewalkSuper]

Dat is niet zo makkelijk gedaan als gezegd. De massa zal Chrome waarschijnlijk niet installeren naast de stock browser, die hebben daar geen weet van. En dan heb je ook nog mensen waarbij het niet (makkelijk) kan.

Mijn ouders kunnen al geen gebruik maken van Chrome, omdat het interne opslaggeheugen bij hen maar 512MB groot is. Met een aantal basic apps heb je dat zo vol. Ze gebruiken dus de stock browser. FolderMount kan (kwam ik laatst achter) bovenstaand probleem ook niet oplossen icm een sd-kaartje.

[Verwijderd]

Sowieso is de Chrome browser vaak langzamer dan de stock Android browser. Ervaring is op een dual core , dus al een wat ouder apparaat.

[SidewalkSuper]

Wist ik niet, nog een belangrijk punt voor de massa dus om er niet voor te kiezen.
"Die oude was veel sneller" is voor velen een goed argument.

[mad_max234]

Dat is lapmiddel, wat nu als mensen net als ik de stock browser fijner vinden, moeten we dan maar verplicht iets gaan gebruiken wat we niet willen omdat men systeem heeft wat niet werkt in praktijk en miljoenen gebruikers nu dus de klos zijn.

En is probleem wat al jaren speelt, gebruikers roepen het al jaren dat ze het anders willen en dit groot probleem is, word niet of nauwelijks naar geluisterd.

[_David_]

De stock browser wordt niet meer ondersteund sinds Android 4.4, dus eventueel moet je wel switchen naar chrome of een andere browser.

[Kliko]

Hoe zit dit met Samsung toestellen? Die hebben de app "internet" met een blauw wereldbolletje als icon als ik het mij goed herinner. Is dit de stock app van android, of een browser van samsung?

[Zilla]

Dit "internetbolletje" is de stock browser en dus vatbaar voor deze aanval. (getest op een s3 met android 4.1.2).

[Verwijderd]

Zit je dan met je Android 2.3 . Waarschijnlijk is 2.3 sowieso al niet erg beveiligd meer. Chrome werkt trouwens niet op 2.3. Het Android OS heeft potentie maar de wijze waarop het updaten en aanpakken van bugs is georganiseerd is erg slecht. Ook de vele troep in de Android Store is trouwens niet om over naar huis te schrijven. Voor normale consumenten is er geen touw aan vast te knopen. Je bent afhankelijk van fabrikanten die na de verkoop van het toestel het modelnummer alweer zijn vergeten. De Android Alliantie is ook helemaal niet gebaat bij updates aangezien daar veel hardware fabrikanten inzitten die geld verdienen door de constante verkoop van nieuwe SoC's en andere belangrijke onderdelen in een smartphone. Ook de fabrikant van de toestellen heeft niets aan veel oude toestellen met nieuwe versienummers want zij moeten ook blijven verkopen. Android telefoons zijn een goed voorbeeld van 'Planned Obsolescence'.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 09:49]

[Dorank]

Android telefoons zijn een goed voorbeeld van 'Planned Obsolescence'.

Ik heb mijn vorige android telefoons geprobeerd te gebruiken met nieuwere versies via custom roms:
-G1/ADP1 van 0.9 naar 2.2/3
-Desire Z/G2 van 2.x naar 4.x

Maar het OS past op een gegeven moment niet meer bij de hardware. Het chronische gebrek aan geheugen zorgde ervoor dat de applicaties een onderling gevecht leverden voor RAM. De VM blijft dan ingrijpen door services te killen, die een paar seconden later weer restarten waardoor weer een andere service gekilled werd met een low memory/out of memory. Dit gaat dan gepaart met een snel leeglopende battij omdat de CPU vrijwel niet kan slapen.

Als je dan na zo'n 2 a 3 jaar alsnog de laatste versie wilt draaien zal je gewoon een nieuw toestel moeten kopen dat past bij die versie. Probleem zijn wel bugfixes. Maar je kan moeilijk afdwingen dat alle fabrikanten bugfixes blijven doorvoeren, zelfs de custom ROM bouwers verlaten oude telefoons als ze niet meer mee kunnen.

[redecal]

Het Android OS heeft potentie

zeker, ze zijn er bijna

nieuws: IDC: marktaandeel Android groeit naar 78 procent

[Verwijderd]

Ik vind het een vreemde reactie om een bepaald merk/applicatie/toestel een dominant marktaandeel toe te wensen. Ik hoop dat je zelf begrijpt dat dit nooit goed is op lange termijn voor de consument, zelfs niet voor fanboys.

Ik wens zelf geen enkele fabrikant een marktaandeel groter dan 35% toe, hoe graag ik ook hun producten zou gebruiken.

[redecal]

nee, sorry, was een sarcastische opmerking...

ik vind android een mooi platform, alleen de uitvoering is door de moordende concurrentie gewoon vaak niet lekker meer. er komen simpelweg teveel toestellen uit, waarvan veel ondermaats en met matige support. als je alleen al kijkt naar asus en samsung hoeveel tablets met verschillende SoC's er uitgekomen zijn, dat is gewoon lastig supporten. helemaal in het geval van samsung die naast eigen hardware ook nog eens die bloatware van een touchwizz maar moet blijven updaten.

wat dat betreft graven ze een beetje hun eigen graf want er komt een moment dat mensen af gaan haken omdat de producten die ze kopen niet (meer) aan de verwachtingen voldoen en een concurrent met een beter alternatief komt (vergelijkbaar wat met nokia en blackberry gebeurde).

ik kijk iedere keer schuin naar windows phone, maar heb teveel apps op android en ios die ik dan moet missen...

[catfish]

het bewijs dat de manier hoe er met Android wordt omgegaan ifv updates een ramp is
een OS op een smartphone is even kritisch geworden als op een desktop pc, producten die niet meer ondersteund worden zijn dus feitelijk waardeloos
aangezien de ondersteuning van heel veel Android toestellen ongelooflijk belabberd is, kan je bijna besluiten dat Android op zich waardeloos is

ik bedoel dit zeker niet als flamebait, maar als een omroep aan Google om hun zaakjes eindelijk op orde te brengen
niet om MS de hemel in te prijzen, maar het feit dat alle toestellen van WP de update krijgen is al veel beter (hoewel ik moeilijk kan geloven dat er niet meer patches zijn, maar dat idee heb ik dus ook bij Android)
Apple doet het dan misschien nog best (of Blackberry, maar daar heb ik geen ervaring mee)

[Reactie gewijzigd door catfish op 24 juli 2024 09:49]

[redecal]

alle windows phone toestellen? niet die van HTC...

[dj.verhulst]

dit is gewoon slecht,, dat ze na een relatieve korte tijd al stoppen met de support.
en het dan ook lastig maken ( voor de doorsnee noob ) om een alternatieve rom te installeren

nu worden veel telefoons afgeserveerd die best een hogere versie android aan kunnen..


zou de EU daar niet eens wat regels voor kunnen opstellen ??

tot die tijd maar firefox installeren dan maar

[Reactie gewijzigd door dj.verhulst op 24 juli 2024 09:49]

[SJBijzitter]

Kan Android niet via een update knop updaten? Ik heb laatst mijn Windows Phone 8.0 geüpdate (developer account nodig) naar Windows Phone 8.1 (gratis). Telefoon was een halfuurtje bezig, startte meerdere malen opnieuw op en daarna was ook alles klaar!

[dj.verhulst]

er is een knop om eventueel handmatig een update naar binnen te trekken.

maar het maffe is dat er een hele keten tussen zit die wel allemaal de neus de zelfde kant op moeten hebben staan.