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)

[curumir]

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/

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.

[donny007]

Wat is de afstand van NFC op de s3?

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*.

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 23 juli 2024 22:36]

[Luminair]

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.

[YopY]

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.

[BoringDay]

jit is een javascript ding .... en dat schakel ik gewoon uit, javascript is al tijden lek en een onprettige scripttaal

[bitflusher]

Hoe die je dat met alle AJAX sites? of is web 2.0 niet jouw ding?

[BoringDay]

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.

[batjes]

en ajax/javascript is deel van al de HTML5 meuk die je overall ziet

[Aeternum]

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.

[Dreamvoid]

Zonder JavaScript werkt bijna geen enkele site.

[watercoolertje]

Maar jij bent die andere 300 miljoen iOS gebruikers niet, die er dus wel last van kunnen hebben

[Reactie gewijzigd door watercoolertje op 23 juli 2024 22:36]

[donny007]

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

This module exploits a cross-domain issue within the Android web browser to exfiltrate files from a vulnerable device.

De PHP-versie (iets anders opgezet, zelfde resultaat):
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 23 juli 2024 22:36]

[Eloy]

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

[L-VIS]

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.

[ultimasnake]

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!)

[Reactie gewijzigd door ultimasnake op 23 juli 2024 22:36]

[Loller1]

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.

[JanvdVeer]

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...

[Reactie gewijzigd door JanvdVeer op 23 juli 2024 22:36]

[YopY]

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 23 juli 2024 22:36]

[arjankoole]

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.

[YopY]

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.

[watercoolertje]

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

[Reactie gewijzigd door watercoolertje op 23 juli 2024 22:36]

[Dreamvoid]

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.

Je kan in iOS niet overstappen naar een alternatieve browser, dus er valt weinig aan te doen.

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 22:36]

[JoJo_nl]

mm NFC rooting is leuk
ov-chipkaart kun je ook gebruiken als tag met anytag b.v. op de s3

[donny007]

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.

[Scrummie]

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.

[Bosmonster]

Idd, het wordt ook niet helemaal duidelijk.

[Luminair]

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.

[pe1dnn]

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.

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.

Ik neem aan dat dit muisje nog wel een staartje zal krijgen...

[YopY]

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.

[Dreamvoid]

Webkit is de HTML rendering engine, dus daar kan nooit een JavaScript exploit in zitten. Dat zal in Safari's JS engine zitten.

[Anoniem: 154887]

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?

[Dreamvoid]

Tis niet Webkit, maar de JavaScript engine van Safari.

[watercoolertje]

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)...

[Anoniem: 471672]

Laatste tijd worden er wel veel fouten gevonden in browsers ....

[Xatom]

Maar de laatste tijd wordt er ook meer gezocht naar deze fouten...

[Dreamvoid]

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.

[Anoniem: 390382]

Ff Out of the box: Als je JavaScript uit zet dan kan er toch weinig gebeuren?

[YopY]

Dan gebeurt er idd weinig, aangezien best wel veel websites/apps afhankelijk zijn van Javascript

[Dreamvoid]

Da's prima, maar dan werken de meeste websites niet meer.

[mokkol]

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!