Nederlanders vinden beveiligingsprobleem in browser iOS 6
Nederlandse beveiligingsonderzoekers hebben tijdens de Pwn2Own-hackwedstrijd in Amsterdam een beveiligingsprobleem in de browser van iOS-versies 5 en 6 gevonden. Met javascript is het mogelijk om onder meer foto's en video's te stelen.
Naast foto's en video's kunnen ook het adresboek en de browser-history worden geplunderd. Dat vertelt een van de beveiligingsonderzoekers die het probleem ontdekten, Certified Secure-ceo Joost Pol. Zijn bedrijf won de Pwn2Own-hackwedstrijd voor mobiele devices, die woensdag werd gehouden in Amsterdam.
De opdracht van de wedstrijd was om een beveiligingslek in iOS 5.1.1 te vinden, maar de hack van Pol en zijn collega, Daan Keuper, bleek ook te werken op iOS 6. Die nieuwste versie komt woensdagavond uit, maar is dus kwetsbaar, denkt Pol. Zij hebben de code getest op de gold master en in de regel is dat de versie die ook naar het grote publiek wordt uitgerold. "De hack werkt sowieso op de iPhone 4S", zegt Pol tegen Tweakers.net. "En waarschijnlijk ook op de iPhone 5." De gestolen gegevens konden worden verstuurd naar een eigen server van de onderzoekers.
De kwetsbaarheid zit in de just in time-compiler van Safari, die javascript omzet naar machinecode. "Je hebt op iOS als aanvaller in feite twee mogelijkheden om native code uit te voeren", zegt Pol. "Dat is return-oriented programming of de jit-compiler." Bij return-oriented programming worden de bestaande machine-instructies van een bepaald programma in een specifieke, door de aanvaller gekozen volgorde uitgevoerd, waardoor hij zijn eigen code kan samenstellen.
Het serveren van wat simpele javascript is voldoende om de gegevens te stelen. Het surfen naar een besmette website kan dus leiden tot gegevensdiefstal. Pol: "Het risico bestaat uit mensen die dit niet voor de lol doen, zoals wij, maar die bijvoorbeeld via geïnfecteerde advertenties foto's stelen. Dat is voor veel mensen toch een pijnlijk punt."
Omdat ook Android en BlackBerry OS de webkit-engine van Safari gebruiken, is de kans volgens Pol groot dat ook die kwetsbaar zijn voor het beveiligingsprobleem. "Maar dat hebben we niet getest", benadrukt hij. De onderzoekers kregen voor het ontdekken van het beveiligingsprobleem de hoofdprijs van 30.000 dollar. Andere deelnemers ontdekten onder meer een beveiligingsprobleem in de nfc-implementatie van de Galaxy S3, waardoor shellcode kon worden uitgevoerd.
Reacties (60)
Dat de kwetsbaarheid in de JIT compiler zit is min of meer een voordeel. Zo zijn apps met een browser onderdeel (zoals Twitter clients) niet kwetsbaar.
Vziw is de JIT compiler een Safari ding, en heeft Chrome dan weer V8 (geloof ik). Ik kan het fout hebben, maar dan is dit dus een Apple ding.
Verder niks wat een OTA update niet snel kan updaten.
Vziw is de JIT compiler een Safari ding, en heeft Chrome dan weer V8 (geloof ik). Ik kan het fout hebben, maar dan is dit dus een Apple ding.
Verder niks wat een OTA update niet snel kan updaten.
jit is een javascript ding .... en dat schakel ik gewoon uit, javascript is al tijden lek en een onprettige scripttaal
Hoe die je dat met alle AJAX sites? of is web 2.0 niet jouw ding?
laat web 2.0/html5 maar snel komen.
AJAX programmeer methode is enorm onvriendelijk .... samenraapsel.
We kunnen beter een echt OOP georienteerde ontwikkelomgeving voor de web hebben ipv allerlei losse taaltjes waarvan de meeste uit lekken bestaan.
AJAX programmeer methode is enorm onvriendelijk .... samenraapsel.
We kunnen beter een echt OOP georienteerde ontwikkelomgeving voor de web hebben ipv allerlei losse taaltjes waarvan de meeste uit lekken bestaan.
en ajax/javascript is deel van al de HTML5 meuk die je overall ziet 
Zonder te willen vloeken in de kerk, maar as3 (actionscript) is taal-structuur technisch gezien de opvolger van javascript. Die is gemodelleerd op de ecma 4 standaard. Die standaard is uiteindelijk doodgebloed. Maar als javascript er nu zo uit zou zien, dan was het programmeren erin iig een stuk prettiger.
Zonder JavaScript werkt bijna geen enkele site.
Maar jij bent die andere 300 miljoen iOS gebruikers niet, die er dus wel last van kunnen hebben 
[Reactie gewijzigd door watercoolertje op 20 september 2012 09:38]
Dat was een kritiekpunt op de nieuwe browser in iOS 4 als ik het me goed herinner (de rendering engine van webviews binnen apps was anders dan die in Safari), maar volgens mij hebben ze dat rechtgetrokken (mag ook wel, aangezien er best veel crossplatform / hybrid apps zijn die in webviews draaien. JIT is slechts een optimalisatietechniek, Chrome's V8 Javascript engine heeft ook JIT (hiero), als één van de optimalisaties ten opzichte van naïeve JS engines.
Zo, dat is een redelijk groot lek dan. Als dit ook op android werkt hoop ik dat ze snel een oplossing uitrollen aangezien ik dan ook niet veilig ben. 
En je hoopt dit niet als het niet voorkomt op Android? Ik zou zeggen, patchen die hap, waar dit ook voorkomt. Vind foto's trouwens nog niet zo boeiend, contacten stelen vind ik veel erger.
Tenzij je die leuke foto's van de sexy nacht op vakantie met je vriendin ook op je iOS hebt staan.
Alle data die wordt gestolen is potentieel "erg". Behalve misschien muziek.
Alle data die wordt gestolen is potentieel "erg". Behalve misschien muziek.
Nou android is voor mij wat belangrijker omdat ik er zelf een heb. Maar je hebt gelijk natuurlijk. Het is zowieso belangrijk.
Is het zo raar dat iemand het beste met zichzelf voor heeft op de eerste plaats en dan pas met andere onbekende?
Google kan het gat wel fixen maar het hangt nog altijd van de fabrikant van je telefoon af hoe snel die is met een fix, mocht dit lek ook inderdaad aanwezig zijn op Android.
Kan je beter Internet Explorer erop zetten: http://www.youtube.com/watch?v=gRNS7w5DvMM
Dat is niet eens grappig te noemen.
lezen! android gebruikt de webkit van Safari voor zijn eigen browser. Grote kans dat de android browser dezelfde fout bevat.
Dat lijkt me hoe dan ook stug gezien de V8 engine niet in Safari for IOS zit. De verwarring hierboven is nog begrijpelijk, maar dat van jou is wel erg verwarrend op een verwarring
Ik denk dat ze chrome voor iOS bedoelen. Naar mijn weten heeft chrome een eigen javascript engine behalve op de iOS versie want daar moet je die van apple gebruiken (appe staat geen andere toe)
In iOS 5, Apple introduced a new JavaScript engine called Nitro, which significantly increased the performance of JavaScript in the Mobile Safari browser. For a while, iOS 5 had the fastest-executing JavaScript in the mobile browser ecosystem. Again, Android has caught up: the JavaScript engine in Android 4 is a major step up from Android 2.x (Gingerbread).
[Reactie gewijzigd door dulion op 19 september 2012 16:41]
Goede actie zo worden mensen beloond om fouten op sporen en krijgt het bedrijf de kans om dit op te lossen helemaal top.
Voor de bovenstaande reacties, ik zou maar niet googlen op android, beveiligingslek/virus aangezien er 10 tallen in omloop zijn.
Voor de bovenstaande reacties, ik zou maar niet googlen op android, beveiligingslek/virus aangezien er 10 tallen in omloop zijn.
Maar niet in de browser die elke willekeurige site kan triggeren. Maar buiten de app store als je zelf buiten de appstore dingen gaat installeren... CalimeroVoor de bovenstaande reacties, ik zou maar niet googlen op android, beveiligingslek/virus aangezien er 10 tallen in omloop zijn.
Als ik het artikel lees zit het lek dus eigenlijk in de webkit engine en niet in de browsercode? Nogal een verschil na zo'n titel te lezen.
Idd, het wordt ook niet helemaal duidelijk.
Ik weet het zelf ook niet helemaal zeker, maar volgens mij wordt javascript optimalisatie apart ingeladen en hoeft het dus zeker niet bij de webkit in te zitten.
Als het in de webkit engine zit dan treft het mogelijk ook de webkit browsers in Windows zoals Google Chrome en Safari. Dat is nog een veel belangrijker gat dan dat het ook Android browsers treft.Als ik het artikel lees zit het lek dus eigenlijk in de webkit engine en niet in de browsercode? Nogal een verschil na zo'n titel te lezen.
Ik neem aan dat dit muisje nog wel een staartje zal krijgen...
Nee, het zit in de JS engine; Webkit is het component dat een DOM (html) + CSS omzet in iets visueels, de rendering. De Javascript engine is hetgeen dat Javascript code interpreteert en uitvoert (en optimaliseert, waar in dit geval de zwakte in zit). De 'browser' is wat die twee combineert met een UI en zaken als bookmarks, tabs, etc.
Webkit is de HTML rendering engine, dus daar kan nooit een JavaScript exploit in zitten. Dat zal in Safari's JS engine zitten.
Ik vind dit dus echt super wedstrijden. Naar mijn mening is 30.000 dollar een mooi bedrag voor de eerste prijs! Mag zelfs nog iets meer zijn!
Lang geleden had Android ( < 2.3.4) een soortgelijke* vulnerability (website bezoeken, die vervolgens, door middel van een exploit, bestanden upload naar een server).
http://www.metasploit.com.../android_htmlfileprovider
http://www.exploit-db.com/exploits/18164/
* Totaal andere opzet maar met hetzelfde resultaat: bestanden stelen.
Ik neem aan dat Apple op launch day met een hotfix komt, de iPhones die nu op de pallets staan om uitgeleverd te worden kun je niet makkelijk meer voorzien van een fix..
http://www.metasploit.com.../android_htmlfileprovider
De PHP-versie (iets anders opgezet, zelfde resultaat):This module exploits a cross-domain issue within the Android web browser to exfiltrate files from a vulnerable device.
http://www.exploit-db.com/exploits/18164/
* Totaal andere opzet maar met hetzelfde resultaat: bestanden stelen.
Ik neem aan dat Apple op launch day met een hotfix komt, de iPhones die nu op de pallets staan om uitgeleverd te worden kun je niet makkelijk meer voorzien van een fix..
[Reactie gewijzigd door donny007 op 19 september 2012 16:41]
Nou begin ik me wel een beetje zorgen te maken... ik gebruik nog Eclair.
Echt wel slecht dat Android toen geen updatemechanisme had dat bugfixes automatisch installeerd.
*getypt vanaf mijn ICS tablet
Echt wel slecht dat Android toen geen updatemechanisme had dat bugfixes automatisch installeerd.
*getypt vanaf mijn ICS tablet
Laatste tijd worden er wel veel fouten gevonden in browsers ....
Maar de laatste tijd wordt er ook meer gezocht naar deze fouten...
Er worden al sinds midden jaren 90 hopen JavaScript exploits in browsers gevonden. Dit is nou eenmaal inherent aan het feit dat 'men' heeft bedacht dat client-side scripting handig was. Het is alleen het paard van Troje gebleken, maar goed - de geest kan niet meer terug in de fles.
Wat me opvalt, is dat met het laatste lek in IE overheden op de wereld en mensen op bijvoorbeeld Twitter en Facebook oproepen tot een ban van die browser. Nu hoor je dat wat minder. Groter probleem bij dit soort fouten dat updates minder frequent plaatsvinden en dat mensen minder snel hun iOS (of ander mobiel OS) apparaat updaten.
ik dacht dat iOS gebruikers juist spectaculair snel updaten, omdat die updates altijd centraal vanuit Apple gepushed worden. Dat gebeurt met Android niet (behalve met de Nexus reeks), daar moet het eerst langs de maker van de telefoon, en eventueel nog de telco als het een branded toestel is.
Updates worden niet echt 'gepushed' vanuit Apple, er wordt slechts aangegeven dat er een update is. Echter, het is wel waar dat iOS gebruikers redelijk snel upgraden. Het helpt natuurlijk ook dat Apple / iOS niet afhankelijk is van 3e partijen om de updates uit te geven / geschikt te maken voor hun devices.
Als ze hem uit brengen is het inderdaad voor alles tegelijk, maar voordat ze hem uitbrengen zijn we vaak ook weer een maand of wat verder als ze al erkennen dat het een bug is, waren iPhones niet ruim een jaar te jailbraiken via de browser?...
Ik heb trouwens bij Samsung en Asus bijna maandelijks updates/bugfixes. Dat staat compleet los van de update naar een nieuwe Android versie he waar je nu op probeert te bitchen
Ik heb trouwens bij Samsung en Asus bijna maandelijks updates/bugfixes. Dat staat compleet los van de update naar een nieuwe Android versie he waar je nu op probeert te bitchen
[Reactie gewijzigd door watercoolertje op 20 september 2012 09:50]
Ik denk dat je jezelf nogal vergist in de update snelheid van IOS. Indien er een ernstige bug gevonden wordt (waar ik dit deels onder vind vallen) dan hebben ze natuurlijk als eerst response tijd nodig, maar daarna gaat het updaten van een IOS apparaat met een noodgang naar mijn idee. Iedere keer als je de telefoon aansluit op Itunes (dus op je pc/mac door de autostart functie) zal hij controleren op updates, de gebruiker klikt vervolgens alleen op ja/nee en de update loopt. Op je Iphone zal indien er een update OTA beschikbaar is er continu een icoontje boven je settings pictogram geplaatst zijn en ook vanuit daar is updaten niets meer dan 1 knop indrukken.
Als ik dit vergelijk met mijn Samsung Galaxy S update proces dan ben ik het weer wel met je eens, dat was een enorm gedoe. Eerst naar de site, het toestel vinden, vervolgens wordt je voor de keuze gesteld welke 'subtype' je hebt, daarvan download je de update, en dan moet je aardig wat stappen door (welke gegevens wilt u backuppen, bla bla bla) je moet er maar op zitten te wachten. Mogelijk dat dit tegenwoordig ook via een soort 'Itunes' pakket is van samsung. En dan sla ik het feit dat Android base eerst moet geupdate worden door google en dan vervolgens samsung nog een rom moet uitbrengen nog even over.
(laat ik even weg dat de subversie update uiteindelijk nog de verkeerde rom downloade waardoor ik uiteindelijk nog mijn telefoon brickte!)
Als ik dit vergelijk met mijn Samsung Galaxy S update proces dan ben ik het weer wel met je eens, dat was een enorm gedoe. Eerst naar de site, het toestel vinden, vervolgens wordt je voor de keuze gesteld welke 'subtype' je hebt, daarvan download je de update, en dan moet je aardig wat stappen door (welke gegevens wilt u backuppen, bla bla bla) je moet er maar op zitten te wachten. Mogelijk dat dit tegenwoordig ook via een soort 'Itunes' pakket is van samsung. En dan sla ik het feit dat Android base eerst moet geupdate worden door google en dan vervolgens samsung nog een rom moet uitbrengen nog even over.
(laat ik even weg dat de subversie update uiteindelijk nog de verkeerde rom downloade waardoor ik uiteindelijk nog mijn telefoon brickte!)
[Reactie gewijzigd door ultimasnake op 19 september 2012 16:48]
Neemt zijn punt niet weg. Dit probleem werkt op 5.1.1 en 6.0.0, Apple kennende duurt het even voordat we 6.0.1 te zien krijgen waarin dit wordt gefixed. En dan zijn er al wat foto's gestolen als dit actief wordt gebruikt. Doet me denken aan mijn post in het nieuwsbericht over IE: Bij IE moet iedere kleine fout meteen in de pers en roept iedereen dat je moet stoppen met IE te gebruiken, als dit bij een andere browser gebeurd, gaat het meer van, wacht maar af, er komt een update, zelfs al is dat lek veel groter.
Tegenwoordig worden alle updates bij iOS OTA gepusht, dus aansluiten met iTunes hoeft (al lang) niet meer. Zodra hij een update vindt haalt hij hem automatisch binnen (mits op wifi), en daarna kan de user hem updaten wanneer hij/zij wil.
Vanavond na 19.00 uur komt iOS 6 OTA beschikbaar overigens
Mijn iPhone heeft sinds iOS 5 volgens mij maar enkele keren aan iTunes gehangen. Dat is echt verleden tijd, en gelukkig maar
edit: typo's...
Vanavond na 19.00 uur komt iOS 6 OTA beschikbaar overigens
Mijn iPhone heeft sinds iOS 5 volgens mij maar enkele keren aan iTunes gehangen. Dat is echt verleden tijd, en gelukkig maar
edit: typo's...
[Reactie gewijzigd door JanvdVeer op 19 september 2012 17:10]
Samsung heeft - tenminste voor mijn telefoon - het programma Kies, waarmee je redelijk eenvoudig backups kunt maken en je telefoon kunt updaten naar de meest recente versie (indien beschikbaar). Die nog geprobeerd?
[Reactie gewijzigd door YopY op 19 september 2012 18:36]
Je kan in iOS niet overstappen naar een alternatieve browser, dus er valt weinig aan te doen.Wat me opvalt, is dat met het laatste lek in IE overheden op de wereld en mensen op bijvoorbeeld Twitter en Facebook oproepen tot een ban van die browser.
[Reactie gewijzigd door Dreamvoid op 20 september 2012 01:32]
mm NFC rooting is leuk
ov-chipkaart kun je ook gebruiken als tag met anytag b.v. op de s3
ov-chipkaart kun je ook gebruiken als tag met anytag b.v. op de s3
Ja, omdat het UID (unieke id) altijd uit te lezen is. Iedere 2.56MHz RFID-tag kun je gebruiken als NFC tag. Als je er meer mee wil (zoals lezen en schrijven) heb je de sleutels nodig.ov-chipkaart kun je ook gebruiken als tag met anytag b.v. op de s3
Wat is de afstand van NFC op de s3?
Als het een paar cm is valt die vulnerability nog mee, maar boven een bepaalde marge hoef je alleen maar langs de verkeerde persoon of het verkeerde device te zijn gelopen om een shellscript uit te laten voeren...
Uit het gelinkte artikel blijkt dat deze exploit ook schijnt te werken op andere manieren, waaronder via email en de browser...
De vraag is ook of het S3 specifiek is, of Android 4.0.4...
http://labs.mwrinfosecuri...wn2own-at-eusecwest-2012/
Als het een paar cm is valt die vulnerability nog mee, maar boven een bepaalde marge hoef je alleen maar langs de verkeerde persoon of het verkeerde device te zijn gelopen om een shellscript uit te laten voeren...
Uit het gelinkte artikel blijkt dat deze exploit ook schijnt te werken op andere manieren, waaronder via email en de browser...
De vraag is ook of het S3 specifiek is, of Android 4.0.4...
http://labs.mwrinfosecuri...wn2own-at-eusecwest-2012/
MWR showed an exploit against a previously undiscovered vulnerability on a Samsung Galaxy S3 phone running Android 4.0.4. Through NFC it was possible to upload a malicious file to the device, which allowed us to gain code execution on the device and subsequently get full control over the device using a second vulnerability for privilege escalation.
The same vulnerability could also be exploited through other attack vectors, such as malicious websites or e-mail attachments.
Enkele meters met de juiste apparatuur. De beperking van enkele centimeters zit hem vooral in de stroomvoorziening van de chip (inductie). De antennes van de NFC-lezer kunnen tot op enkele meters signalen ontvangen, en zenden hard genoeg om ontvangen te kunnen worden op enkele meters afstand*.Wat is de afstand van NFC op de s3?
Dus in theorie kan een zeer gevoelige zend- en ontvanginstallatie met eigen energiebron communiceren met de NFC-chip, mits deze niet kijkt naar de power draw om zo een kaart in nabijheid te detecteren.
* MIFARE-chips en lezers bevatten anti-collision technologie om te voorkomen dat veel rfid-devices in een kleine ruimte, zoals naast elkaar geplaatste ov-chipkaart poortjes, gaan storen.
[Reactie gewijzigd door donny007 op 19 september 2012 17:01]
Dus een fout in Webkit die 'waarschijnlijk' (kan nog niet getest worden) in finale versie iOS 6 zit en 'waarschijnlijk' (is niet getest) ook in andere Android toestellen, en een fout in NFC bij de S3 wordt bij tweakers.net:
Nederlanders vinden beveiligingsproblemen in browser iOS 6... Hoe neutraal is dit?
Nederlanders vinden beveiligingsproblemen in browser iOS 6... Hoe neutraal is dit?
Tis niet Webkit, maar de JavaScript engine van Safari.
300 miljoen devices tegenover 20 miljoen...
Waar je bij die 300 miljoen maar een verkeerde website moet bezoeken (geen gerichte aanval) en waar je die 20 miljoen mensen alleen kan bereiken als je in de buurt bent en je weet dat iemand een SGS3 heeft...
Niet zo raar dat het iOS lek (wat niet in Android zit, kan tweaker mooi brengen maar het is een lek in javascript wat niks met webkit te maken heeft)...
Waar je bij die 300 miljoen maar een verkeerde website moet bezoeken (geen gerichte aanval) en waar je die 20 miljoen mensen alleen kan bereiken als je in de buurt bent en je weet dat iemand een SGS3 heeft...
Niet zo raar dat het iOS lek (wat niet in Android zit, kan tweaker mooi brengen maar het is een lek in javascript wat niks met webkit te maken heeft)...
Op dit item kan niet meer gereageerd worden.
Populair: Tablets E3 2013 Mobiele telefoons Google Sony Apple Microsoft Games Politiek en recht Consoles
© 1998 - 2013 Tweakers.net B.V. onderdeel van De Persgroep, ook uitgever van Computable.nl, Autotrack.nl en Carsom.nl • Hosting door True
