×

Help Tweakers weer winnen!

Tweakers is dit jaar weer genomineerd voor beste nieuwssite, beste prijsvergelijker en beste community! Laten we ervoor zorgen dat heel Nederland weet dat Tweakers de beste website is. Stem op Tweakers en maak kans op mooie prijzen!

Cookies op Tweakers

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

Meer informatie

Ontdekker Broadpwn-lek toont mobiele wifi-worm tijdens presentatie

Door , 40 reacties

De ontdekker van het Broadpwn-lek, dat recentelijk door onder meer Apple is gedicht, presenteerde zijn onderzoek donderdag in Las Vegas. Tijdens de presentatie toonde Nilay Artenstein een demo van een worm die zich via wifi naar mobiele apparaten verspreidt.

Zo toonde hij hoe de kwaadaardige software van telefoon naar telefoon kon verspreiden, zonder dat gebruikers daarvoor een actie uit hoefden te voeren. Hiermee wilde hij de gevolgen van het Broadpwn-lek aantonen, waarvan de details inmiddels staan beschreven in een blogpost. Tijdens zijn presentatie ging hij in op de ontdekking van deze remote exploit die werkt op Android en iOS. De aanval richt zich op de Broadcom BCM 43xx-wifichipset en maakt het mogelijk om op afstand code uit te voeren in de application processor van kwetsbare smartphones. Google en Apple hebben het lek met kenmerk CVE-2017-9417 inmiddels gepatcht.

Artenstein legde uit dat er drie vereisten zijn om van een daadwerkelijke remote exploit te kunnen spreken. Zo mag er geen menselijke interactie nodig zijn, mogen er geen aannames gemaakt worden over het doelsysteem omdat er weinig over bekend is, en moet het systeem na uitvoeren van de exploit zo stabiel mogelijk blijven. Onder deze voorwaarden ging hij op zoek naar een exploit die zoveel mogelijk apparaten zou raken.

Het direct aanvallen van de processor is moeilijk. Daarom keek de Exodus Intelligence-onderzoeker naar twee chips die in verbinding staan met de processor: baseband en wifi. Deze vormen een mogelijkheid om de kernel aan te vallen. Het probleem met baseband was dat er veel fragmentatie tussen verschillende fabrikanten is, waardoor een enkele bug een beperkt effect heeft. Daarom richtte hij zich op de wifichipset, die in alle gevallen afkomstig is van Broadcom. Een mooie bijkomstigheid daarbij is dat er geen beschermingsmaatregelen als aslr en dep aanwezig zijn.

Een andere bijkomstigheid was dat een deel van Broadcom recentelijk was overgenomen door Cypress, dat veel specificaties openbaar maakte. Met zicht op de eerste 'regel' van remote exploits ging hij op zoek naar een exploit die geen interactie vereiste. Hij maakte hierbij gebruik van het feit dat een wifi-apparaat regelmatig uitzendt naar welke accesspoint het op zoek is. Voordat bijvoorbeeld een smartphone een via wpa2 beveiligde verbinding maakt, is er een sprake van een associatieproces zonder authenticatie. Daarbij wordt gebruikgemaakt van authenticatiepakketten, die volgens de onderzoeker een interessante eigenschap bezaten. Zo had het pakket een gedeelte van variabele lengte waarin informatie opgeslagen kon worden.

Door een bug in een protocol voor de prioritering van netwerkverkeer kwam hij erachter dat hij op deze manier de buffer op de chipset kon overschrijven. De indeling van het geheugen wordt daarbij vastgelegd tijdens het opstarten, waardoor deze statisch is. Dat zorgt ervoor dat goed te voorspellen is welk gedeelte te overschrijven is door middel van de overflow, ook na een herstart van het apparaat. Door enig geluk was het uiteindelijk mogelijk om een manier te vinden een payload af te leveren en code uit te voeren. Het enige wat een slachtoffer daarvan merkt is dat zijn wifi-icoontje voor korte tijd verdwijnt. Bevindt de telefoon zich bijvoorbeeld in de broekzak en staat wifi aan, zal dat vaak onzichtbaar zijn.

Op deze manier was Artenstein in staat om een worm te ontwikkelen, die zich van het ene geïnfecteerde toestel naar het andere verspreidt. Volgens de onderzoeker is het de eerste echte netwerkworm sinds een lange tijd.

Door Sander van Voorst

Nieuwsredacteur

28-07-2017 • 06:56

40 Linkedin Google+

Reacties (40)

Wijzig sortering
Toch even een extra quote uit het bron artikel waarin de ontdekker meer info geeft over welke smartphones precies gebruik maken van deze wifi chip.
THE BCM43XX FAMILY

Broadcom’s WiFi chips are the dominant choice for the WiFi slot in high-end smartphones. In a non-exhaustive research, we’ve found that the following models use Broadcom WiFi chips:

Samsung Galaxy from S3 through S8, inclusive
All Samsung Notes3. Nexus 5, 6, 6X and 6P
All iPhones after iPhone 5

The chip model range from BCM4339 for the oldest phones (notably Nexus 5) up to BCM4361 for the Samsung Galaxy S8. This research was carried out on both a Samsung Galaxy S5 (BCM4354) and a Samsung Galaxy S7 (BCM4359), with the main exploit development process taking place on the S7.
Ik heb even de releasenotes van 10.3.3 erbij gepakt. Metdeze versie zijn alle iPhones hier iig tegen gepatched
Wifi
Beschikbaar voor: iPhone 5 en hoger, iPad 4e generatie en hoger en iPod touch 6e generatie
Impact: een aanvaller binnen bereik kan mogelijk willekeurige code uitvoeren op de wifichip
Beschrijving: een probleem met geheugenbeschadiging is verholpen door een verbeterde verwerking van het geheugen.
CVE-2017-9417: Nitay Artenstein van Exodus Intelligence
Met 10.3.3 ben je dus safe tegen deze exploit.
Pas op, dit gaat niet over Android en IOS maar over de Broadcom BCM 43xx, mits die in FullMAC mode draait (en dus het 'host' OS niet een deel van de driver-layers in software doet SoftMAC).

Dit gaat dus ook over bijvoorbeeld de Raspberry Pi 3 B.

Dat de exploit nog niet uitgewerkt is is niet belangrijk; geef het een weekje. En huiver over die veel complexere Baseband chip die terzijde genoemd wordt in de Broadpwn blogpost. Geen idee welke in mijn slimme meter zit. Maar er zit vast wel een zero day in.

teun
Het is maar net wat die zero-day doet :+
Het gaat om een proof of concept en is niet in het wild gebruikt. Je hebt waarschijnlijk een ander probleem. Mogelijk kan iemand op het forum je hier verder mee helpen.
Het probleem is dat je dit niet zo kan stellen. Het is gemeld door iemand van voeder trouw, denk je dat een kwaadwillende persoon met goud in handen dat goud weg geeft?
Je zou maar een Android telefoon hebben met deze chip... De vraag is niet wanneer je een update krijgt, maar wanneer je de worm te pakken hebt. Via WiFi is deze worm snel te verspreiden. Het is schandalig dat fabrikanten zo veel controle hebben bij het uitrollen van updates. Als het hun even niet uit komt stoppen ze met de ondersteuning. Google heeft het probleem opgelost, maar of dat ooit op een telefoon zal verschijnen blijft voor mij een raadsel. Apple heeft voor iOS 11 nog even tussen update uitgebracht die voor zorgde dat deze aanval niet meer mogelijk is.

Fixed: typo's.

[Reactie gewijzigd door Xieoxer op 28 juli 2017 10:42]

Misschien een idee om de update als worm te verpakken dan :+

Zowel Apple als Google fixen ontzettend veel mogelijke exploits. iOS apparaten krijgen snel een update, maar 90+% van de Androids niet of heel veel later. Android is ook nog eens opensource, dus de fix laat ook makkelijk de exploit zien. Kijk bijvoorbeeld naar een probleem in Bluetooth file browser: https://android.googlesou...f2029ddbf7055ff%5E%21/#F3

Maar exploits als Stagefright is ook behoorlijk ernstig en ook dit is in veel Android apparaten niet gepatched en toch loopt het niet zo’n vaart als ten tijde van Anna Kournikova worm en andere XP exploits zoals Blaster. Een niet SP2 van Windows XP was binnen 30 seconde al compromised. Of Android gebruikers hebben het niet door dat ze een virus hebben of blijkbaar valt het mee met de infecties.
Akelige aan Android's vorm van open source is dat iedereen kan zien wat erin zit, maar ook al weet je precies waar het lek zit, je kunt als puntje bij paaltje komt helemaal niks aanpassen op de telefoon. Je hebt geen rechten om systeembestanden aan te passen, je kunt de code wel inzien maar als je die zelf compileert en op de telefoon weet te plaatsen werkt de wifi niet en heeft de GPU allerlei kuren, omdat de fabrikant er toch net een paar duizend extra patches op heeft gedaan die niet in die source code tree staan.

Al wat je kunt doen is geen al te gevoelige data op je telefoon zetten, zorgen dat er een kopie is van belangrijke data, en er maar het beste van hopen.

De juiste weg naar veilige Android telefoons lijkt mij om het systeem juist open te maken, de gebruiker root rechten toe staan, en zorgen dat open-source ontwikkelaars - met name Linux kernel developers - patches te laten doorvoeren op alle modellen. Niet elke gebruiker hoeft straks zijn eigen kernel te bouwen, via een online community kun je die wel laten distribueren door degenen die dat wel kunnen. Net als bijvoorbeeld een Ubuntu op je PC.
Hoe mooi het ook klinkt, wie zegt er dat die developers te vertrouwen zijn?
Ik durf dat te beweren. Er komt geen letter code in die niet door meerdere mensen is gezien.
Dat is *heel* wat anders dan de developers niet kunnen vertrouwen.

Iemand niet vertrouwen omdat ze foutjes maken is onhandig, dan kun je niemand meer vertrouwen.
Iemand niet vertrouwen omdat ze bewust foute code in je OS opnemen, dat is best een aardige defense-strategie als je inderdaad redenen hebt om te twijfelen aan de intenties van die mensen.

Laat de linux kernel nou net door letterlijk duizenden mensen van honderden bedrijven en stichtingen worden ontwikkeld en dan is het al vrij snel onmogelijk vol te houden dat ze allemaal niet betrouwbaar zijn.
En hoe kun je weten dat dat (heatbleed) een fout was en geen bewuste exploit?

Oftewel er kan iemand opzettelijk een backdoor creëren en alle mensen die dat controleren is het dus niet opgevallen.
Vrijwel onmogelijk wederom vanwege codereviews.
Uhm nee, als ik per ongeluk een bug schrijf of expres hoe zie jij welke van de 2 het is dan?

Codereviews zijn leuk en ook zeker nuttig maar zeker niet sluitend, genoeg code met tig reviews waar toch nog bugs in zitten en dus mogelijke exploits...
Uhm nee, als ik per ongeluk een bug schrijf of expres hoe zie jij welke van de 2 het is dan?

Codereviews zijn leuk en ook zeker nuttig maar zeker niet sluitend, genoeg code met tig reviews waar toch nog bugs in zitten en dus mogelijke exploits...
Uhm jawel. Dat weet ik doordat er simpelweg codereviews zijn. Ik zeg niet dat die bugs per definitie tegenhouden. Maar iemand die wetende dat meerdere mensen naar zijn code gaan kijken, nog steeds een achterdeur in wil bouwen is of heel dom of zoveel slimmer dan al zijn collega's dat ik durf te zeggen dat je het bij het verkeerde eind hebt. Maw code reviews houden wel degelijk kwaadwillenden tegen.
Wat een onzin, een bug is een bug of die nou expres of per ongeluk geschreven is kan je als reviewer helemaal niet zien. Er komen zat bugs door reviews heen en dus kan daar net zo goed een bewuste bug tussen zitten...

En wie heeft het over collega's je hebt het over open source projecten waar mensen elkaar helemaal niet hoeven kennen om toch een bijdrage te kunnen leveren.

[Reactie gewijzigd door watercoolertje op 29 juli 2017 13:45]

Tjonge jonge.

Als iemand een stuk code introduceert en daar een bug in laat zitten kost hem dat goodwill als die bug gevonden wordt.
Als je continue goede code introduceerd bouw je net zo goed goodwill op, mensen vertrouwen je code dan eerder en zullen er welliicht wat minder snel naar kijken. Maar jij gelooft ook niet dat je stelling op gaat dat je even snel een kritische bug kunt inschieten in een stuk code waar niemand jou als ontwikkelaar kent. Juist bij nieuwe ontwikkelaars wordt er extra gelet op stijl, functie en veiligheid omdat je als 'oude rot' er meestal niet op zit te wachten dat iemand nieuw ineens de 'verkeerde' kant op gaat werken omdat hij simpelweg niet beter weet, of inderdaad minder positieve bijdragen wil leveren.

Die goodwill opbouwen kost een tijd, mensen leren je in die tijd kennen en vertrouwen, en dat vertrouwen is nou precies het vertrouwen dat ook naar de eindgebruiker doorgegeven wordt.

Je zet de band die opensource ontwikkelaars onderling met elkaar hebben, en zeker binnen projecten vaak met elkaar hebben wel erg makkelijk weg als 'een groepje willekeurige mensen die aan elkaars code rommelen'. Dat zo iets op de werkvloer binnen bedrijven kan gebeuren lijkt me net zo goed mogelijk. Detacheerder hier, afdelingen die onderling met elkaar strijden daar, en laten we idustriele spionage tussen bedrijven, landen of zelfs "echte" collega's niet vergeten.

Maargoed, wijs vooral de bugs aan waarvan we weten dat ze inderdaad in bijvoorbeeld de linux kernel zaten, kennelijk een tijd gemist zijn door de code reviews en waarvan de bedoelingen evident was de bedoelingen niet in de haak waren.
Dat noem je nog altijd collega's vind ik persoonlijk, je hebt er op professioneel vlak contact mee. Maar je gaat voorbij aan wat ik zeg. Een bug is heel wat anders dan een exploit. Expres een exploit schrijven die een ander niet ziet is veel moeilijker omdat er gegarandeerd dingen in zitten die alarmbellen doen rinkelen. Plus het feit dat je maar de gok moet maken dat je exploit niet gevonden wordt maakt de kans dat je dat überhaupt gaat proberen marginaal. Meestal moet je stukken code aanraken die op gevoelige plekken zit. Dat zien reviewers natuurlijk ook meteen. Daarnaast moet je vertellen wat je pull request doet. Iedere letter code die daar niets mee te maken heeft is natuurlijk ook verdacht. In principe is jouw comment dus onzin, en niet die van mij.
Ik denk dat voor security patches de fabrikanten niet moeten tussen komen. Deze worden door Google rechtstreeks gedaan via Play Services.
Google voert security patches uit voor de Android software, niet voor de kernel of de drivers. Dat kunnen zij ook niet door de wildgroei en het gebrek aan standaardisatie.

[Reactie gewijzigd door The Zep Man op 28 juli 2017 07:27]

Ha ok. En zouden ze dit toch niet (eventueel tijdelijk) software-matig kunnen oplossen?
Klinkt als een issue dat in de WiFi driver opgelost moet worden. En als er iets notoir is om proprietary code zijn het wel wifi drivers (in custom roms altijd gezeik omdat er een binary blob aan data ingeladen moet worden waar de rom maker weinig mee kan bij issues).
Google kan dus weinig betekenen in deze.
Niet eens (enkel) in de driver. Al maakt die soms ook aannames dat de WiFi-firmware altijd betrouwbaar is.

Het probleem zit primair in de WiFi firmware. Daarvoor is zelfs de fabrikant van je telefoon afhankelijk van Broadcom, dat maakt het er allemaal niet makkelijker op.
Tja de kern van het google android probleem, door de wildgroei is android nu zo populair, dat was de bedoeling van google. bijeffect dat updates en patches bijzaak geworden zijn.
Nee, voor patchen van deze issues ben je rechtstreeks afhankelijk van de fabrikant en niet van Google. Dus geen update van fabrikant, dan heb je dus echt een probleem..
Vanaf security patch 2017-07-05 is deze gepatcht in Android.

https://source.android.com/security/bulletin/2017-07-01

Je kan in de nieuwe Android versies zien welke security patch je hebt bij "over de telefoon" in instellingen.
Samsung zit op 1-7-2017 de patch van google zit in 5-7-2017 (CVE-2017-9417).
Grote kans dat Samsung telefoons nog een maand kwetsbaar blijven.
Ik verwacht niet nog een snelle patch van Samsung.
Eng maar goed dat hij in de openheid dit deelt. Vraag me af hoeveel er onder de pet blijft van niet zulke vriendelijke mensen.
Het is ook mogenlijk op andere non-broadcom chips je moet er alleen veel tijd voor over hebben, denken dat jouw chip mega veilig is omdat het geen broadcom is, is een waanidee.. (omdat je het niet weet is het niet veiliger :+)

Uiteindelijk zullen de fabrikanten die meer specificaties bekent maken veiliger zijn dan de degene die dat niet doen. (want degene die de moeite nemen om dingen te reverse engineren zijn meestal de foute lui met geld)

*typo edit

[Reactie gewijzigd door stewie op 28 juli 2017 10:06]

De titel van dit artikel mag wat mij betreft wel wat alarmerender. Ik kreeg een bericht van mijn werkgever, terwijl ik dit bericht helemaal niet had opgemerkt terwijl ik toch meerdere malen per dag tweakers check. Maar met deze kop...."mwah, niet interessant"
Ik vond een app (WiFi Chipset INFO) om de wifi chips van je android device te checken, en te kijken of je kwetsbaar bent voor broadpown.

Mijn Xiaomi Redmi Note 4 is gelukkig niet kwetsbaar, zit een Xiaomi chip in volgens de software.

[Reactie gewijzigd door Gwannoes op 28 juli 2017 10:56]

Voor Android zouden ze moeten afstappen van dat patchen per provider. je hebt nu kans dat een virus van je telefoon een mobiele infectiehaard maakt die alle andere telefoons die niet gepatched zijn gaat hacken of netwerk ddosen gaat uitvoeren. 70 % van alle hedendaagse telefoons heeft deze broadcom bug.

Voor Apple hebben ze dan wel een fix, maar lang niet iedereen update zijn/haarr telefoon.

Ben benieuwd hoe dit zich gaat ontwikkelen, dit zou nog wel eens volledig uit de klauwen kunnen lopen.
Hopelijk is mijn Nokia 5310 uit 2007 al gepatched voor dit probleemje :9~
Het verbaast me dat er hier puur en alleen over smartphones wordt gesproken. Het is inmiddels ook duidelijk dat ook MacBooks met een Broadcom uit de BCM43xx-familie kwetsbaar waren (Bron: https://nakedsecurity.sop...apple-patch-for-broadpwn/.

Gelukkig heeft Apple hier al een patch voor uitgebracht via MacOS 10.12.6.

Op dit item kan niet meer gereageerd worden.


Apple iPhone X Google Pixel 2 XL LG W7 Samsung Galaxy S8 Google Pixel 2 Sony Bravia A1 OLED Microsoft Xbox One X Apple iPhone 8

© 1998 - 2017 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Hardware.Info de Persgroep Online Services B.V. Hosting door True

*