Hacker kraakt baseband-chip telefoons om malware te installeren

Een onderzoeker van het Amerikaanse beveiligingsbedrijf Accuvant heeft een gat gevonden in de baseband-chips van meerdere telefoons, waardoor iemand die zichzelf voordoet als een telecomprovider malware op het toestel zou kunnen installeren.

Beveiligingsonderzoeker Martin Solnik, die zijn bevindingen volgende week op de Black Hat-beveiligingsbeurs in Las Vegas uit de doeken doet, zegt tegenover The Wall Street Journal in feite elke kwetsbare telefoon binnen negen meter te kunnen kraken. Daarvoor gebruikt hij een kleine zendmast, die volgens hem voor minder dan duizend dollar - omgerekend circa 750 euro - te krijgen is.

Solnik maakt daarbij misbruik van een beveiligingsprobleem in de baseband-chips van meerdere moderne telefoons, waaronder een aantal niet bij naam genoemde Android-telefoons, ten minste één oudere iPhone en meerdere BlackBerry-modellen. Precieze details over de hack ontbreken, maar met behulp van de vervalste zendmast zou Solnik er in slagen om malware te pushen naar het apparaat. Daarbij maakt Solnik misbruik van een protocol dat providers software-updates naar een smartphone laat sturen.

Tegenover persbureau Reuters zegt Solnik dat op dit moment slechts een handjevol experts de aanval op zou kunnen zetten. Het is onduidelijk of Google en Apple aan een oplossing werken, al zeggen de bedrijven wel op de hoogte te zijn van het probleem. BlackBerry zegt 'nauw samen te werken' met Solnik.

Reacties (44)

Volgens mij draait de radio-chip een eigen OS, de hack gaat dan niet via iOS of Android maar direct naar de baseband-chip (correct me if i'm wrong) Dan kan een Google, Apple, Miccrosoft of RIM daar weinig aan doen, maar moet je een nieuwe telefoon kopen met niet te hacken chips.

Nee, die zijn wel te upgraden, heet dan een baseband (firmware) upgrade. Moet uiteraard wel gebeuren voordat de malware erop staat, anders is het einde verhaal

Heb al eerder dingen hierover gelezen:
http://www.osnews.com/sto...ing_in_every_mobile_phone

Dit is inderdaad oud nieuws. Niet alleen om dat de technologie er al was, maar ook om dat het eerder gedaan was, maar dan door onderzoekers en studenten.

Een groot probleem was ook dat bij veel SoCs en chipsets de baseband en de cpu geheugen delen, en de baseband firmware het geheugen dat door het applicatie OS gebruikt wordt kan lezen en schrijven. Als je in de baseband bent kan je dus alles doen, het is nog erger dan draadloze remote JTAG...

Er zijn vrij veel apparaten die naast het OS of embedded OS nog een extra set RTOSsen en firmwares draaien die prima vatbaar is voor aanvallen om dat ze zo vaak een ondergeschoven kindje zijn bij het ontwerpproces, en gewoon als building block voor de hardware gezien worden en verder genegeerd worden.

Daarnaast zijn de baseband RTOSsen maar ook de firmwares in SSD's, HDD's, BMC's in servers, Intel's vPro en ME firmwares (waarbij de vPro nog het ergste is om dat je die niet kan uitschakelen en ook niet verder kan beveiligen, hij altijd DMA toegang heeft tot nagenoeg alles, en een vrij krachtige ARM CPU heeft met eigen interne flash en RAM).

In veel gevallen zijn het oude ontwerpen, vooral in baseband firmwares, om dat ze eenkeer grondig volgens een spec binnen een standaard gemaakt zijn, en dat zo ingewikkeld was en geld kostte om te bouwen en goed gekeurd te krijgen, dat er later hoogstens betere circuits toegevoegd worden voor de radiohardware en antenne's, en wat software modules voor nieuwe radio protocollen. Niemand wil ze echt van de grond af opnieuw bouwen, en om dat ze meestal alleen zonder documentatie, zonder JTAG en in een of andere nare QFP BGA package geleverd worden en niet zomaar te krijgen zijn en vooral niet per stuk, hebben de meeste fabrikanten schijt aan hackers die er iets mee proberen.

Daarnaast zijn ook vrij veel apparaten als kopieermachines, genetwerkte chipknip apparaten en NFC betaalsystemen die via een intern netwerk lopen maar ook VoIP telefoons extreem eenvoudig te kraken. Ten eerste om dat ze erg vatbaar zijn voor DoS en buffer overflow attacks door hun geringe resources (net als basebands), en als dat extern afgevangen wordt is er nog het probleem dat bijna al die embedded devices vaak hun firmware bij het opstarten extern ophalen of kunnen ophalen waarmee je dus een gehackte image kan uploaden. Vaak zijn ze met een slechte xor of crc "beveiligd" die je praktisch met trial and error kan creëren als je zou willen.

Nu is het nut van sommige hacks beperkt, als het te hacken apparaat bijvoorbeeld op zichzelf niet veel kan doen, maar het kan wel als prachtige trojan werken, gezien alles wat je op die apparaten aansluit er van uit gaat dat ze veilig zijn, of gewoon niet zonder kan functioneren (als we het bijvoorbeeld over storage controllers hebben, of embedded management processors en out-of-band processors als Intel's ME/vPro, en BMC's in het algemeen). Je kan ze niet met anti-virus software of firewalls bestrijden, je kan ze niet vanaf je OS verwijderen en je kan er fysiek ook niet bij.

[Reactie gewijzigd door johnkeates op 31 juli 2014 19:32]

Een buffer overflow komt niet tot stand omdat een systeem weinig resources heeft. De naam zegt het al, er wordt net genoeg in een buffer weggeschreven zodat hij vol zit en de rest van de payload op de stack wordt uitgevoerd omdat het buiten het gereserveerde bereik van de buffer komt en je deze als het ware laat overstromen. Verder mooi verhaal.

[Reactie gewijzigd door keesdewit op 31 juli 2014 21:47]

Dat klopt, maar als een systeem weinig resources heeft moeten die dus erg selectief ingezet worden. Daar mee doel ik dus op het feit dat je waarschijnlijk geen heuristics scans doet, geen DoS bescherming op filterbasis kan toevoegen enz. Gewoon om dat waarschijnlijk het RAM dan gewoon op raakt voor dat je het apparaat zinvol kan gebruiken.

Met bijvoorbeeld IPMI chips en BMC chips heb je dat probleem op een heel andere manier: daar zitten standaard genoeg slecht geïmplementeerde filters en checks in die juist gebruikt kunnen worden om in te breken. Meestal lijkt het er op dat een fabrikant of firmware programmeur dacht dat een KCS channel niet als attack vector gebruikt zou worden (assumptions.. the mother of all fuckups!) en gezien je vaak zonder root of administrator rechten met zo'n chip kan babbelen als de driver geïnstalleerd is (meestal via een poort boven de 1024 lokaal, of een socket die toch vrij vaak op nobody:nobody staat, of een userspace api die communiceert met een daemon die dan weer via shm met de controller driver in de kernel praat).

Het ergste is nog wel het Intel voorbeeld met de AMT on-chip, die extern benaderbaar is via ethernet en WiFi, niet uitgezet kan worden, en een redelijke RISC chip met eigen flash (meerdere MB's!) en RAM in de ICH/PCH verwerkt zit. Daar draait gewoon een klein OS op en je kan er op afstand maar ook via bijv. een USB stick code aan toevoegen (een exploit die code injection mogelijk maakt). Die optie zit in nagenoeg alle Qxx chipsets, die je o.a. in veel kassasystemen en pinautomaten waar je geld uit haalt terugziet. Er zit ook SoL in, wat betekent dat je als je er eenmaal in bent je gratis een command & control channel bij krijgt om met je gekraakte systeem te praten dat buiten de host interface om gaat en intern dus niet te detecteren is. Daar wordt al jaren aan gewerkt, onderzoekjes worden gepubliceerd, het zit in standaard toolkits voor scriptkiddies die niet kunnen hacken maar wel cool willen doen, en elke keer als Intel het gepatcht denkt te hebben gaat er weer wat anders mis.

Nu is dat natuurlijk niet de enige, maar wel een erg goed gedocumenteerde. HP's iLO en LO100, Dell's DRAC, Supermicro's implementatie.. allemaal vatbaar. Sommige gewoon via internet, maar allemaal lokaal via KCS. IBM lijkt het nog redelijk dichtgetimmerd te hebben, maar de rest.. tsja.

Ik denk dat fysiek-only firmware en controller exploits niet de grootste dreiging is.

Hoe beperkter de resources, hoe minder overhead je jezelf kunt permitteren. Als je met dat soort beperkingen zit kan je geen virtual machine, geen randomizer op geheugenadressen, en geen hogere programmeertalen toepassen, dus je moet het als programmeur allemaal zelf doen.
En volgens @JohnKeates moet de specialist die dat soort dingen kan programmeren (ze zijn steeds minder nodig, krachtige SOCs met gigabytes geheugen zijn tegenwoordig de standaard) alle aanvalsvectoren kennen en afdichten, zonder fouten te maken, en volgens de baas zonder een KB aan geheugen te verspillen. Nou, sterkte ermee! Correcte werking in alle gevallen bewijzen is al te veel gevraagd voor de meeste IT'ers (een paar testjes is geen bewijs), laat staan alle aanvalsvectoren afdichten.

Precies. Dat dus. Een paar slappe testjes, wat bewezen functionaliteit volgens de spec, en releasen het spul. Security mag niks kosten, moet zo snel mogelijk afgevinkt worden, en een specialist regelen die dat gaat doen mag eigenlijk ook niet. Gezien vanuit de hogere management lagen niet zo gek; die geven een budget en een maximale doorlooptijd mee, dat weer van boven komt om dat ze moeten presteren, de onderliggende team managers en projectleiders moeten de details maar uitzoeken en ach, de marketing maakt het wel goed, de product life cycle is toch niet zo lang, en na 1 of 2 grote updates wordt het product toch niet meer beschouwd als relevant.

Ik denk dat het voor de meeste mensen wel nieuws in en het geeft wel een idee hoe intelligentiediensten in principe alle kunnen hacken. De NSA hoeft allen maar legaal op de tech bedrijven te spioneren om zo voor alles en nog wat hacks te maken. Naderhand kan de hardware eventueel ook weer in originele staat worden gebracht.

Je hoeft er niet eens voor te spioneren hoor. Alles wat er tot nu toe bekend is, is gewoon met simpele onderzoekjes gevonden. Geen broncode nodig. Vaak ook geen service bussen of toegang nodig.

In het geval van Cisco telefoons is het bijvoorbeeld simpelweg een kwestie van een DHCP/BOOTP server met TFTP opzetten die sneller reageert dan Cisco's eigen management server. En als je met je pentest of evil device een telefoon te pakken hebt en je er een image op zet die als extraatje heeft dat ie ook DHCP/BOOTP en TFTP draait heb je een zichzelf-infecterend netwerk. Hoe kom je daar achter? Nou, gewoon even een lijntje waar zo'n toestel aan hangt sniffen. En hoe hack je een image? Nou, gewoon, openen met je favoriete hex editor om uit te zoeken waar je mee te maken hebt, en dan het ding uit elkaar halen. En wat als je niet in de kernel kan of root toegang kan krijgen? Nou, dan zorg je dat je een bufferoverflow of stackoverflow vector te pakken krijgt en zo je eigen code kan uitvoeren.

Je hoeft echt niks te bespioneren, je kan zelfs zonder zelf de hardware te bemachtigen om het te onderzoeken het in andermans netwerk doen.

Daarnaast is het ook niet zo dat dit extreem moeilijk is, je zou er zelfs een handleiding voor kunnen schijven dat zelfs de gemiddelde HBO'er het kan doen. Hell, je kan dit soort hacks zo ver in stapjes en opdrachten uitstippelen dat een MBO systeembeheerder dit nog kan leren. Het probleem met al deze exploits en aanvalsvectoren is niet dat ze er niet waren of onbekend waren, maar dat de meeste SysOps en DevOps afdelingen te lui en te onprofessioneel zijn om er iets mee te doen. Zowel ontdekken als patchen lijkt gewoon niet in de gedachten van de meeste ICT medewerkers op te komen. In de meeste gevallen wordt het zelfs gewoon afgeschoven op de leverancier of fabrikant, alsof het probleem daarmee opgelost is!

[Reactie gewijzigd door johnkeates op 1 augustus 2014 05:00]

Yep en de NSA en elk land dat genoeg geld heeft om aan cyberwarfare en spionage te doen zijn waarschijnlijk 5 jaar verder met dit soort techieken dan de aardige jongens die naar een hacker conferentie gaan om de mensen te waarschuwen. Vroeger was de grap dat Rusland een heel modern en rijk land is want 99% van de bevolking had een radiozender thuis alleen 10% was daarvan op de hoogte. Nu staar ik in de camera van mijn iPhone terwijl ik dit type. Ik wil ook een hacker worden, systemen worden alleen nog maar complexer en de engineers die de basis laag bouwde zijn op pensioen of dood. In de toekomst word het nog mogelijk dat je koelkast weigert om je toegang te geven want een of andere computergod vind dat je te dik bent en helpt je ongevraagd.

Tsja. In de meeste gevallen is het simpelweg zo dat mensen niet meer willen leren wat iets is of hoe het werkt. Maar gemakzucht blijft, dus dan maar iets wat niet onder controle is, en wat vaak goed lijkt te gaan.

Het is niet alsof het niet te leren is, maar het wordt gewoon niet gedaan. Iedereen krijgt op de middelbare school aardrijkskunde, 95% zal daar niks meer mee doen de rest van z'n leven, en toch blijven we daar op hameren zonder echt naar dingen als IT te kijken. Nu stel ik niet voor om aardrijkskunde dan maar af te schaffen, maar als we met z'n allen beslissen dat dat relevant is, en dat je ook dingen moet leren die je nooit van je leven gaat gebruiken (zoals hoe sediment ontstaat of wat erosie is) in de normale dagelijkse doen, dan lijkt het me helemaal niet raar om te beslissen dat het toch wel belangrijk is om tenminste in de basis te weten hoe digitale systemen werken.

En dan bedoel ik niet leren programmeren, dat is wat te hoog gegrepen, maar dingen als leren werken met Word of Excel, daar schiet niemand wat mee op. Ten eerste niet om dat een specifiek programma kennen vrij weinig met goede dingen maken te maken heeft (iedereen kan leren schrijven, maar niet iedereen is dan ook automatisch opeens een briljante schrijver die bestsellers aflevert), en ten tweede om dat je aan het eind van de rit nog steeds niet echt weet hoe het nou werkt.

Als je kijkt naar de dingen die je in het dagelijks leven echt veel gebruikt, dan is het toch schrikbarend om te zien hoe weinig iedereen er over weet.

Het is ook een beetje de sortering van vakken die je op het onderwijs tegen komt voor dat er naar een gespecialiseerde opleiding gekeken wordt na het eindexamen. Neem bijvoorbeeld de beta vakken vs. de rest. Er zijn er weinig, ze zijn ondervertegenwoordigd, en om een of andere reden lijken de meeste mensen de capaciteit niet te hebben om er ook echt iets mee te doen. Er wordt vaker gekozen voor een groepje vakken waar je er met wat leren en stampen wel mee weg komt, dan iets waar je daadwerkelijk iets voor moet kunnen bedenken. (wat overigens net zo goed voor de creatieve vakken geldt, ook daar mist de massa gewoon de capaciteit om het te doen)

Zijn we dan maar gewoon allemaal lekker de weg van de minste weerstand aan het volgen? Is echt dingen doen te moeilijk in het leven? Ik geef het misschien wat grof weer, maar volgens mij zijn alle negatieve toekomstbeelden die overal geschetst worden (van filosofische bedenksels tot aan apocalyptische blockbusters in de bioscoop) voornamelijk te wijten aan het niet bestaan van de wil om dingen te begrijpen. Het smoesje dat 'het te veel' of anders 'te complex' is gaat hier niet op. Kijk naar de HBO en hogere opleidingen, het is niet alsof er een verschil in de duur is, iedereen krijgt dezelfde tijd om iets in te doen. Er zit wel een lomp groot verschil in de bezetting van de richtingen, en hoe verschrikkelijk groot het deel van de opleidingen en studies is dat eigenlijk alleen maar bestaat om de wereld zoals ie nu is 'in stand' te houden of te conserveren. Dienst verlenen aan wat er al is, kleine optimalisaties binnen grotere systemen waarvan de massa de omvang niet kent...

Goed, het wordt een beetje een lang verhaal, maar tl;dr: mensen willen van alles, maar willen er niet echt wat voor doen. Dan krijg je problemen. Dit is het resultaat (het artikel, de koelkast die gehackt wordt, de privacy die verdwijnt ). Mensen hebben het er deels zelf naar gemaakt. Deal with it or fix it, stop whining.

Deal with it or fix it, stop whining.

Het gemiddelde publiek kan alleen whinen (naar de verantwoordelijken toe). Tenminste, ze zouden het niet moeten accepteren en zelf fixen lukt zeker niet.
Bovendien, het gemiddelde publiek heeft geen flauw benul van die zaken waar je over spreekt. Dus als je whinen/klagen/aanklagen aan hen moet overlaten... Vergeet 't dan maar.

Dat is ook een beetje de trekking van het verhaal. De mensen die het niet kunnen veranderen en er eigenlijk gewoon te weinig van weten huilen het hardst. Het zou een stuk prettiger zijn als ze gewoon naar school gaan of aan zelfstudie doen en problemen oplossen in plaats van er als bijstander om te zeiken. Maar, zo werkt de wereld helaas niet.

Heb al eerder dingen hierover gelezen:
http://www.osnews.com/sto...ing_in_every_mobile_phone

Klopt. Dit geldt overigens niet alleen voor mobiele telefoons. Draadloze netwerkkaarten hebben ook hun eigen microprocessor en firmware die zij inladen. Hetzelfde voor harde schijven, waarbij al eens is aangetoond dat je er andere software op kan zetten. Een wireless radio is natuurlijk kwetsbaarder, omdat je deze van buitenaf kan benaderen.

Ik weet ook van een scenario waarbij een specifiek model draadloze netwerkkaart een computer kon laten crashen wanneer de kaart een onverwacht signaal oppikte vanuit de lucht (van een ander, buggy WiFi apparaat). Dit werd uiteindelijk opgelost met nieuwe drivers.

Het kan zelfs met unmanaged switches! Want die hebben tegenwoordig zo goed als dezelfde chips als managed switches, maar dan zonder user interface en standaard switchen ze alles naar alles. Je zal er dan wel fysiek voor aanwezig moeten zijn, maar daar is ook prima firmware aanpassingen voor te regelen wat je feitelijk een niet te stoppen trojan met MITM en tap opties geeft die niet te vinden is om dat ie ergens zit waar je niet kan 'kijken'.

Moet uiteraard wel gebeuren voordat de malware erop staat, anders is het einde verhaal

Dat hangt er natuurlijk vanaf of deze malware de updatefunctionaliteit om zeep helpt (dan kan ook de malware zichzelf niet meer updaten)

Er kan een lek zitten in de baseband chip, maar het OS is waar de malware naartoe gaat, en daar moet de malware dus afgevangen worden.

Dat kan dus niet, gezien een baseband bijna altijd via shared memory werkt voor communicatie met het OS. Het OS heeft dus geen veilig plekje in het geheugen om te draaien, maar de baseband wel.

Tsja, de oplossing is dan dat het OS de baseband in een sandbox zet. Maar goed, dan gaat iedereen weer klagen over een beetje performanceverlies.

[Reactie gewijzigd door Dreamvoid op 31 juli 2014 22:14]

Niet precies; de baseband is niet iets wat onder controle van het OS valt, en andersom valt het OS weer niet onder de controle van de baseband. Het zijn twee zelfstandige systemen die met elkaar communiceren. Het punt is echter dat dat via gedeeld geheugen gaat, waarbij de baseband zijn eigen firmware op intern geheugen draait, maar het OS compleet op het gedeelde geheugen draait en dus gemodificeerd kan worden door de baseband. (Dit is niet de enige implementatie, maar wel een veel voorkomende)

Bellen gaat bijvoorbeeld niet zoals je denkt via de CPU, maar via een DSP die door de Baseband bestuurd wordt. Het OS zit daar een beetje als slave naast, en soms heb je nog dat er een switch op de amp zit die zolang ie vrijgegeven is door de baseband gebruikt kan worden voor het OS om rechtstreeks met de audio I/O te werken. In feite is het hele telefoon en datacommunicatie gedeelte zelfstandig en 'eigendom' van de baseband. Het OS en de CPU waar het op draait heeft vaak alleen maar communicatie met de baseband, en soms ook wel zelfstandig WiFi en Bluetooth (en NFC, IrDA enz.) als dat niet door de baseband gedaan wordt, wat logisch is, gezien je daar geen baseband voor nodig hebt. De CPU heeft bijvoorbeeld ook geen directe SIM toegang, dat gaat via de baseband. SMS, GSM, GPRS, alle G's, allemaal van de baseband.

De moderne smartphone is meer een mengsel van een PDA en een Telefoon dan je zou denken. Het zijn bijna losse circuits!

Dat weet ik, maar als de boel fatsoenlijk is afgeschermd van elkaar zou malware op een baseband chip niet veel meer moeten kunnen dan de radio benaderen. Het is vervelend natuurlijk als die betaal-nummers gaat bellen, maar toegang tot het OS en zijn geheugenregisters, waar alle echt gevoelige data staat (contactgegevens, emails, wachtwoorden, etc) zou voor een baseband chip onmogelijk moeten zijn in een goed opgezet OS.

Nee, zodra je het RAM direct kan benaderen maakt het niet uit wat voor OS je maakt, het zal altijd 'verliezen' van externe manipulatie, en al helemaal als de manipulatie door een externe chip komt die zelf wel eigen 'veilig' RAM heeft.

Niet als je de baseband zijn eigen RAM (of een gereserveerd deel ervan) geeft

[Reactie gewijzigd door Dreamvoid op 1 augustus 2014 19:37]

Dat heeft de baseband dus al. Het punt is dat het anders is dan je denkt. De baseband is niet een toevoeging op de telefoon waar het OS op draait, maar het OS is een toevoeging op de telefoon die op je baseband draait.

De basis is dus niet je applicatie CPU of je OS, maar de baseband.

[Reactie gewijzigd door johnkeates op 2 augustus 2014 02:47]

...maar het OS is en toevoegen op de telefoon die op je baseband draait.

Zou je dat willen herschrijven? Dat zinnetje snap ik niet. Bedoelde je dit?
"...maar het OS is een toevoeging op de telefoon die op je baseband draait."

Dat lijkt me stug. Een baseband chip is een applicatieprocessor (met veel eigen resources), geen hypervisor.

Dat is het punt niet, en bovendien is de term applicatieprocessor bedoeld om de CPU voor de user aan te duiden. Niet een algemene term om "cpu die applicaties uitvoert" aan te duiden, in dit geval.

De baseband is de telefoon, de CPU met je OS is extra. Dat is hoe de technologie op het moment gebouwd is. De baseband heeft alles voor zichzelf, en is afgeschermd, maar kan wel het RAM van de applicatie processor lezen en schrijven. Ik weet niet hoe ik het nog simpeler kan uitleggen. Dit is gewoon hoe het op het moment gebouwd is, en ook de reden waarom een baseband exploit zo gevaarlijk is (en ook een bron van jailbreaks is).

[Reactie gewijzigd door johnkeates op 2 augustus 2014 11:55]

Goeie uitleg. Maar kan een OS dan niet eenvoudig beveiligd worden tegen activiteiten van de baseband in kernel- en userspace? Het lijkt mij dat er op zijn minst iets proces-achtigs moet zijn met een id dat daar namens de baseband data vandaan probeert te halen of heen te sturen. Dat moet toch te blokkeren zijn door het OS? Anders hebben we volgens mij een ernstige security breach: een hack waarbij het OS compleet omzeild wordt omdat het geheugen gewoon rechtsstreeks van buitenaf is te manipuleren.

edit: plus een zwaar niet-integer computersysteem waarop 2 verschillende processors zonder strikte hierarchie gebruik maken van dezelfde geheugen resources.
edit 2: O nee, dat was een hardware-bug.

[Reactie gewijzigd door blorf op 1 augustus 2014 10:39]

Waarschijnlijk *kan* het wel, maar wordt het gewoon niet gedaan Het ontwikkelen van een baseband chip kost bakken met geld, de firmware is complex en wordt steeds verder op bestaande code gebouwd. De spec opnieuw implementeren om het goed te doen wil niemand.

Daarnaast is er op het moment volgens mij niet echt een bus of standaard om een baseband via een communicatie kanaal met een applicatie CPU te verbinden. Dat, plus het feit dat 'vroeger' shared memory het snelste en het makkelijkste was lijkt me de reden dat we hier nu mee zitten.

Zoals met zo veel van dit soort dingen is het niet precies een technische beperking, maar eerder iets wat blijkbaar de investering niet waard is voor fabrikanten.

De spec opnieuw implementeren om het goed te doen wil niemand.

Als een systeem in zijn basis lek is, moet het opnieuw bouwen gewoon verplicht worden. Welke instantie heeft er genoeg verstand van en zou die verplichting moeten afdwingen?

De overheid niet, en dat is nou toevallig ook de instantie die dat mag verplichten. Van de ITU of de GSMA ofzo hoe je niks te verwachten.

De baseband draait inderdaad een eigen baseband firmware.
ik zag in het artikel dat het in IOS 4.2.1 is opgelost. dus eigenlijk is alleen de oudste iPhone van 7 jaar gelden vatbaar voor deze bug en mensen die een iPhone hebben die ouder is dan 4 jaar en nooit een update hebben gedraait.
Voor Andoid geld waarschijnlijk hetzelfde, waardoor deze bug eigenlijk niet meer relavant is.

[Reactie gewijzigd door Madcat op 31 juli 2014 19:28]

Hoe is dit op Blackberry mogelijk? Voor zover ik weet legt daar de telefoon een secure encrypted tunnel naar zijn BES server voor software updates. Ook al zit daar een 'man in the middle' in de vorm van een gespoofde zendmast tussen, die zendmast heeft niet de private key van de BES server.

Niet elke BlackBerry zit op een BES server, dit is alleen bij bedrijven. Als particulier heb je zelf geen BES en zit je zonder de extra BES encryptie.

Daarnaast heeft dit niks te maken met dat het een BlackBerry is of een ander type telefoon. Deze installatie van malware gaat via de chip welke contact legt met het netwerk. Deze chip heeft zijn eigen systeem van de chipleverancier.

[Reactie gewijzigd door padrini op 31 juli 2014 18:32]

Niet alleen dat, maar baseband toegang geeft je in bijna alle gevallen ook toegang tot het applicatiegeheugen (RAM) en de CPU. Daar zitten je keys in als je symmetrische encryptie gebruikt, en ook de configuratie, die je dan naar hartelust kan aanpassen zodat je bijv. encryptie gewoon uitschakelt. BES gaat je er niet mee helpen Daarnaast is BES en heel BBOS niet op baseband-niveau, maar op applicatie niveau.

All you baseband are belong to us (youtube, 2012)

Ja en zo een chip ga / kan je ook niet echt vervangen voor een ander lijkt me .

Toch ben ik erg benieuwd voor welke mobieltjes op dit moment van toepassing is

Lijkt me dat dit een bepaalde chip of chipset is die in meerdere telefoons zit?

Haha, dit account is een voorgeprogrameerde bot die geactiveerd word door fp artikels die over Apple android of Blackberry gaan. Knap staaltje programmeerwerk!

Hoe kom je tot die conclusie ?

Ik lees:
Blackberry werkt nauw samen met de onderzoeker
Apple wil niet teveel kwijt maar de kans bestaat evengoed dat ze nauw samenwerken maar het niet zeggen
Google idem terwijl het niet eens duidelijk is of er wel een Google telefoon getroffen is. Het is per slot van rekening geen Android hack maar een hack van de chip die los staat van Android

BlackBerry is bekend met het probleem dit was toendertijd een probleem qualcomm for de iPhone 3GS wat vergelijkingen had met de Storm 2 en in 2009 kwam hier ook weer een artikel over. In 2011 ook weer en krijg het idee dat dit weer over het zelfde gaat.

BlackBerry had toen nog geen bewijzen dat het daadwerkelijk ooit gebeurd was maar werkte wel nauw samen met de ontdekker en in artikelen werd daar nog over geschreven in 2009 qua vergelijking met de iPhone 3GS. Dus weet niet of dit een geupdate hack is op basis van het verleden of gewoon iets wat weer als voorbeeld gebruikt is en weer eens opduikt want in de artikel van reutr wordt ook verwezen naar 2010 bijvoorbeeld.

[Reactie gewijzigd door Anoniem: 103465 op 31 juli 2014 20:38]