×

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

Beveiligingsonderzoeker legt backdoors bloot in iOS 7 - update

Door , 167 reacties, submitter: SaintK

Beveiligingsonderzoeker Jonathan Zdziarski claimt een aantal backdoors in iOS 7 te hebben gevonden. De achterdeurtjes kunnen gebruikt worden om de versleuteling van het OS te omzeilen. Apple ontkent de claims.

Volgens Zdziarski is gebruikersdata toegankelijk via de zogenaamde file_relay-functie. Zo kan een aanvaller toegang tot vrijwel alle data op een iPhone of iPad krijgen, ook al zou deze versleuteld moeten zijn. Zo zijn bijvoorbeeld adresboeken uit te lezen, accountgegevens op te vragen en gps-logs te bekijken. Onduidelijk is nog of de file_relay-functie ook op afstand is te gebruiken om een apparaat uit te lezen of uitsluitend lokaal toegepast kan worden. Wel moet een iPhone of iPad eerst via pairing aan een computer gekoppeld worden om file_relay te kunnen benutten. De zogenaamde pairing records kunnen echter buitgemaakt worden of een iPhone-bezitter kan overgehaald worden om zijn toestel in een gemanipuleerd apparaat te plaatsen, bijvoorbeeld een dockingstation om vervolgens een pairing record te genereren.

Zdziarski beschrijft ook pcapd, een geïntegreerde packet sniffer voor het onderscheppen van netwerkgegevens. Pcap kan op afstand via wifi geactiveerd worden.

De beveiligingsonderzoeker stelt dat de backdoors en de ongedocumenteerde functies waarschijnlijk onder druk van de Amerikaanse geheime diensten in iOS zijn aanbracht door Apple. De functionaliteit zou voor debugging- en supportdoeleinden nutteloos zijn. Ook oudere iOS-versies zouden een deel van de backdoors bevatten.

Zdziarski concludeert dat Apple de privacy van zijn gebruikers schendt door het onder andere mogelijk te maken om encryptie geheel te omzeilen en door de gebruiker niet te informeren als er data wordt afgetapt. Ook zouden de backdoors kansen bieden aan criminelen en andere kwaadwillenden.

Apple laat in een reactie weten dat het gaat om 'diagnostische functies'die de privacy en beveiliging niet zouden schaden. Volgens Apple moet een gebruiker eerst zijn telefoon unlocken en toestemming geven als deze gekoppeld wordt aan een andere computer. Ook herhaalt Apple zijn eerder gemaakte claim dat het nooit heeft samengewerkt met overheidsdiensten om backdoors in zijn producten in te bouwen.

Update, 22/7, 11:50: Reactie van Apple toegevoegd aan het artikel.

Door Dimitri Reijerman

Redacteur

21-07-2014 • 17:12

167 Linkedin Google+

Submitter: SaintK

Reacties (167)

Wijzig sortering
Om volledig te zijn, al wil ik Tweakers niet teveel anti-Apple sensatie wegnemen, schreef hij ook:

DON’T PANIC

Before the journalists blow this way out of proportion, this was a talk I gave to a room full of hackers explaining that while we were sleeping, this is how some features in iOS have evolved over the PAST FEW YEARS, and of course a number of companies have taken advantage of some of the capabilities. I have NOT accused Apple of working with NSA, however I suspect (based on released documents) that some of these services MAY have been used by NSA to collect data on potential targets. I am not suggesting some grand conspiracy; there are, however, some services running in iOS that shouldn’t be there, that were intentionally added by Apple as part of the firmware, and that bypass backup encryption while copying more of your personal data than ever should come off the phone for the average consumer. I think at the very least, this warrants an explanation and disclosure to the some 600 million customers out there running iOS devices. At the same time, this is NOT a zero day and NOT some widespread security emergency. My paranoia level is tweaked, but not going crazy. My hope is that Apple will correct the problem. Nothing less, nothing more. I want these services off my phone. They don’t belong there.

[Reactie gewijzigd door Zyphrax op 21 juli 2014 17:30]

En dat klopt ook, vooral dit stukje;
At the same time, this is NOT a zero day and NOT some widespread security emergency.
Punt is wel, dat mocht iemand je mobiel hebben, dat ze hem helemaal kunnen uitlezen. Waarom heeft je mobiel gencrypte bestanden of zelfs een password als dat in zijn geheelheid omzeild kan worden.
Sorry, maar dat is onzin en stierenpoep, in de slides staat ook duidelijk:
 Connect to lockdownd (tcp:62078) via usbmux or TCP
Authenticate with intercepted / generated pairing record
 Invoke “StartService” command with name of the service we wish to start
 Profit*
Je hebt dus een paring record nodig. Die wordt gemaakt op het moment dat iemand de code op de telefoon invoert, of op het moment dat als je geen code hebt je op "Trust" klikt bij het aansluiten van externe apparaten.

Daarnaast werkt dit uiteraard pas als de telefoon tenminste 1x geunlockt is na het opstarten. Als een telefoon dus uit stond of aan staat maar de code nog niet ingevoerd is, dan is alle data nog gewoon gecodeerd en kan je helemaal niks uitlezen, zelfs niet als je een pairing record hebt.

Die records kan je stelen of 'maken' door in te breken bij MDM software in het geval van een bedrijfstoestel, maar dan moet je dus inbreken bij de systemen van het bedrijf dat MDM doet... de methodes die verder in het document staan zijn ook allemaal helemaal niet zo triviaal, dingen als SSL spoofing gaat je zonder MDM of Profiles niet lukken en als je die twee wel hebt, tsja, dan kan je via MDM dus ook Pairing uitzetten of een record maken voor jezelf.

Plaatje ter verduidelijking dat dit echt niet een makkelijk iets is en ook lang geen default beveiligingsprobleem is: http://imgur.com/VRvZVtG

[Reactie gewijzigd door johnkeates op 21 juli 2014 20:24]

Ga vooral termen roepen wat overigens helemaal niet nodig is als jezelf een fatsoenlijke onderbouwing hebt.

In de papers staat: (sorry voor lange copy/paste en verkeerde encoding)
Generate additional pairing records for exclusive use
There are a few frightening things to knowabout the pairing mechanism in
iOS.
Pairing happens automatically, without any user interaction
(up until iOS 7), and only takes a few seconds.
Pairing can be performed by anything on the other end
of the USB cable. The mobile device must either have no
passcode, or be unlocked. If the user has “Require

Passcode” set to anything other than “Immediate”, then
it is also possible to pair with the device after it is turned
off, until the lock timer expires. So if the user has a device
unlocked to play music, and connect it to an alarm
clock or a charger running malicious code, whatever it’s
connected to can establish a pairing record that can later
on be used to gain access to the device, at any point in
time, until the device is restored or wiped.
 While the pairing process itself must take place over
USB (Renard), at any time after that, the phone can be
accessed over either USB or WiFi regardless of whether
or not WiFi sync is turned on. This means that an
attacker only needs a couple of seconds to pair with a
device, and can then later on access the device to
download personal data, or wreak other havoc, if they
can reach it across a network. Additionally, an attacker
can easily find the target device on a WiFi network by
scanning TCP:62078 and attempting to authenticate
with this pairing record. As the pair validation process is
very quick, sweeping a LAN’s address space for the
correct iOS device generally only takes a short amount
of time.
 Because of the way WiFi works on these devices, an
attacker can take advantage of the device’s “known
wireless networks” to force a phone to join their network
when within range, so that they can attack the phone
wirelessly. This is due to iOS’ behavior of automatically
joining networks whose name (not MAC address) it
recognizes, such as “linksys” or “attwifi”. It may even be
possible for a government agency with privileged access
to a cellular carrier’s network to connect to the device
over cellular (although I cannot verify this, due to the
carrier’s firewalls).
Essentially, that tiny little pairing record file is the key to
downloading, installing, and even manipulating data and
applications on the target device. That is why I have advised
law enforcement agencies to begin seizing desktop machines,
so that they can grab a copy of this pairing record in
order to unlock the phone; a number of forensic imaging
products (including some I’ve written), and even open
source tools (A cross-platform software library and tools to
communicate with iOS devices natively) are capable of
acquiring data from a locked mobile device, so long as the
desktop’s pairing record has been recovered. The pairing
record also contains an escrow keybag, so that it can unlock
data that is protected by data-protection encryption
(Renard). This is good news for the “good” cops, who do
crazy things like get warrants; it’s very bad for anyone who
is targeted by spy agencies or malicious hackers looking to
snoop on their data.

[Reactie gewijzigd door Douweegbertje op 21 juli 2014 19:36]

Dat is inderdaad wat in de paper staat. Met andere woorden: je hebt nog steeds een paring record nodig, en je kan ook alleen maar pairen als het apparaat niet gelockt is. Maar als een apparaat niet gelockt is heb je weer geen hacks nodig om bij de data te komen en dan is deze 'backdoor' niet echt een toevoeging...
Nee, ook niet als je niet zomaar de telefoon mag "hebben"? Nu kun je domweg dat ding 24/7 blijven volgen, alle data eraf halen wat jij wilt zonder dat die gene er ook maar iets van af weet. Je hebt gewoon geen fysieke toegang nodig om helemaal los te gaan. Als dat nou geen backdoor is, weet ik het ook niet meer hoor :)
Wat bedoel je met zomaar de telefoon mogen hebben?

Als je uitgedeelde apparatuur bedoelt, tsja, dat kan met alles wel... als iemand anders je een "nieuw" apparaat stuurt kan die er van tevoren van alles mee gedaan hebben.

Een backdoor betekent volgens mij gewoon:
a feature or defect of a computer system that allows surreptitious unauthorized access to data
zoals dat in de meeste woordenboeken staat.

Nu is unauthorised iets wat je dan misschien wat in context moet plaatsen.
Stel dat ik een werkgever ben en jou een telefoon voor werk geef, dan zou het als ik dat zo in een contract gezet heb en het wettelijk mag niet 'unauthorized' zijn als ik van tevoren monitoring op afstand gebruik. Maar daar heb je deze ongedocumenteerde diensten niet voor nodig, daar gebruik je gewoon MDM voor. Dat is trouwens niet iOS-specifiek, maar geldt voor alle hard- en software.

Zie zoals eerder aangehaald http://imgur.com/VRvZVtG

[Reactie gewijzigd door johnkeates op 21 juli 2014 20:24]

Waarom encryptie en ww als dat omzeild kan worden?
Omdat dan slecht een paar % van de mensen dat kunnen en niet iedereen.
Dezelfde rede waarom jij je auto of huis op slot doet als je weg bent. Dan kan niet iedereen binnen komen, maar als iemand het echt zou willen, komt hij toch wel binnen.
Raar voorbeeld, doe het dan even helemaal goed vergelijken met jouw voorbeeld.
In jouw geval zit er gewoon een knopje met een pincode onder de auto waarbij sporadisch heel je auto opengaat en een printer gestart wordt waarbij letterlijk al je gegevens over het aantal gereden km's, locaties e.d. wordt geprint. Overigens weet jij helemaal niet van dat knopje af.

Over het stukje, "als iemand echt wilt komt hij toch binnen": ja dat klopt en dat weet je dan uiteindelijk ook. Bijvoorbeeld om het ruitje in te tikken. Vrij logisch, net zoals het bijvoorbeeld mogelijk zou kunnen zijn om je iOS password met een bruteforce te kraken(?).
Dank voor deze toevoeging. Laten we hopen dat Apple hier een gepaste verklaring voor heeft en hier wat aan doen.

Dit gezegd hebbende.... dit lijkt mij vooral consequenties te hebben voor zakelijke gebruikers..
Helaas zal die gepaste verklaring nooit komen. Het schijnt dat hij al een mail naar JOBS zelf heeft gestuurd en hier nooit antwoord op heeft gehad.
Deze omissies in de beveiliging van persoonlijke informatie wordt door Zdziarski dan ook als verdacht bestempeld. Zijn e-mails over dit onderwerp aan Steve Jobs en meer recent Tim Cook bleven echter onbeantwoord.
Aangezien jobs alweer enige tijd verscheiden is moet het dus gaan om backdoors die al jaren bestaan!
En wist deze persoon er ook al lang vanaf en heeft hij het ook lang stil gehouden. Waarom? Heeft hij Apple eerst tijd gegeven om de beveiling op orde te krijgen vooradt hij de publiciteit zocht? Dat zou wel heel netjes zijn nl.
Om nu direct over een backdoor te praten, dit kan ook intern gebruikt worden door iOS zelf, dat de files unencrypted toegankelijk zijn via deze library komt omdat iOS na de eerste unlock ge encrypte bestanden toegankelijk maakt voor het systeem. Dit werkt dus niet zonder de telefoon eerst te unlocken na het booten. Hier zou enkel potentieel misbruik van kunnen worden gemaakt als er fysiek toegang is en de telefoon aanstaat. Dit lijkt me eerder een erg knullige en domme design fout dan een backdoor.

Grappig detail is dat ze in de PDF ook PCAP noemen als een potentile backdoor, dit wordt echter (ook in OS X) gebruikt om bandbreedte bij te houden.

Je kunt dit artikel dus gerust met een korreltje zout nemen, alu hoedjes zijn niet nodig aangezien ze niet bewust voor de NSA zijn ingebouwd (zie file_relay in eerdere iOS versies en de mogelijkheden, daar had de NSA destijds niets aan waardoor het niet specifiek voor de NSA is ingebouwd lijkt mij)

[Reactie gewijzigd door Tim.k op 21 juli 2014 17:42]

Dat een functie er misschien qua design inzit, betekent niet dat het daarom niet geexploit kan worden, en daarmee is het dus duidelijk een veiligheidslek waar veel gebruikers niet vanaf weten en moet je het dus *niet* met een korreltje zout nemen. Je kan t namelijk niet uitzetten om jezelf zo te beveiligen.
Met het korreltje zou doel ik op backdoors, want dat lijkt het niet te zijn. Dat het een veiligheidsrisico is ben ik volledig met je eens, al is het maar een erg klein risico dat hooguit Jailbreakers kan treffen en misschien developers die hun device in debug modes hebben staan.
Je kan idd die conclusie niet trekken het gaat om de interne werking.
Misschien controleert het wel of de bestanden niet corrupt zijn ...

Het probleem is meer van: 'he dat is verdacht we gaan het een backdoor noemen'

Zonder feiten zijn er geen conclusies.
Tot zover het idee (zoals vaak aangevoerd door Apple-fans) dat Apple-producten veiliger zijn m.b.t. infiltratie van de NSA dan andermans producten. Echt verbazen doet het me trouwens niet want van een Amerikaans bedrijf kun je niet verwachten dat het 's lands eigen veiligheidsdiensten buiten de deur zal kunnen houden.
Uh,,nee, want de NSA kan hier alleen maar wat mee als ze even bij je langskomen en een kabeltje aansluiten. De functinaliteit is niet beschikbaar via 3G of Wifi, is ookal door de omderzoeker aangegeven. Daarom ziet hij dit niet als een zero-day.

Zegt niet dat dit minder vervelend is, maar zeker niet zoals jij het beschrijft.
Waar rook is, is vuur. Niemand zegt dat dit de enige backdoors zijn: het zijn enkel de ontdekte backdoors.
Ja want in Android zullen dit soort dingen niet zitten,... Apple is toch niet achterlijk, die weten ook dat dit soort dingen vroeg of laat gevonden wordt. En wat winnen ze er mee? De kans is dus groot dat ze het niet geheel vrijeillig doen. En als dat zo is, zullen ook Android en Windows Phone met dit soort features zijn uitgerust.

Reden voor Europa om eens met een eigen OS, een eigen processor etc. uit te komen. Want nu zijn we veel te afhankelijk van een land dat keer op keer laat blijken niet met z'n verzntwoording/macht om te kunnen gaan.

En nu doe ik mn aluhoedje weer af want het begint te kriebelen...
Ik verwacht al tijden geen privacy meer. Als ik privacy wil regel ik het wel anders dan op zulle apparaten.
Dit soort nieuws komt al een tijdje niet meer hard aan bij mij.

Natuurlijk wel een kwalijke zaak!
Consumenten zal het een worst wezen, maar bedrijfsleven..

Stukje over privacy:
Mobile Workers: ‘I Want My BlackBerry Back’
http://www.cio.com/articl...t-my-blackberry-back.html

[Reactie gewijzigd door pineapple23 op 21 juli 2014 21:19]

Het wordt tijd dat het de consumenten ook geen worst meer zou wezen...
Consumenten zal het een worst wezen, maar bedrijfsleven..
Hoho, niet alle consumenten over 1 kam scheren he.
Ik ben een consument en geef enorm om mijn privacy.
Ik denk dat je dat niet zo kunt stellen.
"de meute zal het een worst wezen" lijkt me beter.
het selecte groepje wat zich er nog wel druk om zal maken, zitten waarschijnlijk ook hier op tweakers :)
Oei, pijnlijk voor Apple. Zijn deze bevindingen al geverifieerd door andere onderzoekers? En als ze niet op afstand kunnen worden gebruikt, zijn het dan wel bruikbare backdoors?
Als ik de presentatie bekijk van deze hacker, dan valt het me op dat de services waarvan gebruik worden gemaakt, eerst moeten worden aangezet via closed access. Dit komt ook overeen met wat in de Snowden files staat. Dus eerst moet de iPhone aan een usb kabel gehangen worden.
De service kan niet worden aangezet via malware omdat toegang tot localhost niet mogelijk is.

Wel wordt beweerd dat de services worden onderhouden met de iOS releases, wat duidt op een bewuste actie.

Ik vermoed dat we er meer over zullen horen nu anderen het ook kunnen onderzoeken.
Dit zit natuurlijk anders bij iDevices met een jailbreak, maar gelukkig is hier nog weinig malware voor, zeker als je je aan de bekende repo's in Cydia houdt. Toch, een 'hack' repo maken en hier gekraakte versies opzetten van bekende tweaks en games besmet met malware en je kunt redelijk wat mensen pakken als je repo populair word.

[Reactie gewijzigd door s1h4d0w op 22 juli 2014 09:13]

Uit interesse: hoe ziet een beveiligingsexpert het verschil tussen een backdoor die door menselijke fout (nalatigheid, een slecht ontworpen beveiligingssysteem of gewoon puur toeval) en een bewust ingebrachte backdoor?

Claimen dat iets 'zeer waarschijnlijk' onder druk van een externe partij werd gentroduceerd impliceert dat je een methode hebt om met enige zekerheid bewuste en accidentele lekken te scheiden. Ik vraag me af hoe dat praktisch werkt.
De indruk die ik nu kreeg uit de presentatie is dat het gaat om volledig gemplementeerde methodes in iOS. Deze zijn welliswaar niet gedocumenteerd voor app developers of andere externen, maar wel nauwkeurig gecoded. Het zijn dus niet toevallige foutjes of beveiligingsgaten in de wel gedocumenteerde code.
klopt, hij onderbouwt ook waarom hij denkt dat het niet 'per ongeluk' is. Onder andere omdat deze services nog actief ontwikkeld worden door Apple.
Wat ik nu vreemd vind, is dat dit over een backdoor gaat in een Apple OS en de hele thread gaat opeens over Android, Windows en Open Source, :?
Dan moet je de thread nog maar eens lezen. Een paar jongens gaan uitgebreid in op het lek, de oorzaak en de gevolgen.
Die hele android-iOS war moet je maar gewoon wegminnen. :P
" terwijl het bedrijf onlangs nog claimde dat het nooit heeft samengewerkt met overheidsdiensten om backdoors in zijn producten in te bouwen."

Tja, dan gaan mensen per direct graven natuurlijk en uiteindelijk gaat iemand iets vinden. Op dit moment geloof ik Apple best dat ze de backdoors niet hebben ingebouwd voor derden. Ik geloof niet dat het door onkunde tot stand is gekomen. Dus waar ik dan zelf op uit kom: ze hebben het voor eigen doeleinden zo gemaakt. Welke doeleinden, geen idee. Het zou zomaar puur voor customer support kunnen zijn.
De onderzoeker (en schrijver van dit artikel) heeft daar al aan gedacht: "De functionaliteit zou voor debugging- en supportdoeleinden nutteloos zijn."
Zoals ik hierboven aangeef, netwerk functionaliteit uitlezen a.h.v. Pcap is niet ongewoon, gebeurt ook bijvoorbeeld via wireshark op windows. Dus helemaal uitsluiten zou ik het niet.
Oh, kom dan maar even langs en doe maar iets magisch om direct alles uit te lezen want zonder dat programma valt hier niets te zien. In dit verhaal start direct bij de boot libpcap op en dumpt gelijk alles wat hij tegen komt. Dit staat standaard overal aan :)
Dit is niet normaal. Misschien in dev-mode maar niet standaard op letterlijk elk device.
Gebeurd ook op OS X. libpcap wordt gebruikt om bandbreedte bij te houden.
Nog n keer, ja het wordt bij ontzettend veel OSen standaard meegeleverd. Vrijwel elk *nix systeem, BSD en OS X heeft het, en bij sommige is het zelfs genstalleerd. Echter, start het ook per direct bij het booten? Dumpt het gelijk data? En kun je het uberhaubt ergens terug vinden? Voor iOS 7 is het antwoord Ja, ja en nee..
Dit hoort gewoon Nee, nee en ja te zijn.
Daar zeg ik helemaal niets over. Ik zeg alleen dat PCAP gebruikt wordt om bandbreedte bij te houden wat in mijn ogen toch wel een legitieme reden is voor iOS om deze bij boot te starten, anders zou PCAP dit niet bij kunnen houden voor iOS.

Wat mij betreft handelt iOS dit prima af, er is geen toegang voor developers en de dumps zijn niet toegankelijk.

[Reactie gewijzigd door Tim.k op 21 juli 2014 18:40]

Connecting to this service immediately starts a packetsniffer on the device, allowing the client to dump thenetwork traffic and HTTP header data traveling into andout of the device. While a packet sniffer can, on rareoccasion, be helpful to a developer writing network-based applications, this packet sniffer is installed bydefault on all devices andnotonly for devices that havebeen enabled for development. This means anyone with apairing record can connect to a target device via USB orWiFiandlisteninonthetarget’s network traffic. It re-mains a mystery why Apple decided that every singlerecent device needed to come with a packet sniffer. Thisservice presents no visual indication to the user that thedevice is being accessed.
Direct uit zijn paper.
Daar staat letterlijk dat pcapd alleen maar start als je de service aan zet. En dat kan pas als je lockdownd authenticatie gedaan hebt.

En dat is lang niet zo makkelijk als je denkt: http://imgur.com/VRvZVtG
Waarom niet de paper van zijn blog, hij heeft daar meerdere papers en deze is er geen van (third party pdf fileshare dienst)
En waarom moet dit per default aan staan op 600 miljoen devices?
De reden zou zijn (uit de slices van de onderzoeker):
Maybe for Genius Bar or Apple Support? No.
- Data is in too raw a format to be used for tech support
- Can’t be put back onto the phone in any way
- Tech support use shouldn’t call for bypassing backup password
- Data is far too personal in nature for mere tech support
De eerste twee klinken niet logisch; Te raw? Met een goede tool moet die data te behappen zijn. De 3e en 4e houden natuurlijk wel stand.

Zelf ben ik heel erg benieuwd; de onderzoeker lijkt een zeer gerespecteerd iemand te zijn met best een boel credentials. Toch ben ik benieuwd naar reacties van andere specialisten, en natuurlijk van Apple. Waar ik extra benieuwd naar ben is de impact; hoeveel kan men doen zonder de telefoon in de hand te hebben bijvoorbeeld. Van de ene kant heeft hij het over wifi-sniffing, van de andere kant is er een boel voor lokaal access dicht gezet.

Al met al nogal een bom onder het security-beleid van Apple, en ik ben heel benieuwd hoe hier op gereageerd wordt...

edit: zie post van Zyphrax, de onderzoeker zelf geeft al een flinke disclaimer...

[Reactie gewijzigd door curumir op 21 juli 2014 20:53]

Eerste punt is voor support doeleinden natuurlijk wel valide. Het moet niet zo zijn dat ik bel met CS van Apple over mijn Apple product, en dat ik een kwartier in de wacht gezet word omdat ze even mijn apparaat uitlezen en dat het zon groot bestand word dat ze het nog even moeten verwerken voordat ze het kunnen gebruiken.

Ben verder wel benieuwd naar de beweegreden van de onderzoeker om al zo snel te concluderen dat het bijna zeker onder druk van de NSA ingebouwd is. Zoals ik het nu lees zou dit (volgens de onderzoeker) alleen voor de NSA een bruikbare backdoor zijn, maar waarom zou Apple er zelf niet ook gebruik van kunnen maken?

De informatie die de NSA er uit kan plukken zou voor een bedrijf als Apple natuurlijk ook van belang kunnen zijn.
Als zij een specifieke tool hebben die met de raw-data meteen iets kunnen doen... Vergeet ook niet dat de meeste (alle?) backdoors alleen te gebruiken zijn als je het toestel in handen hebt. Zover ik het snap is alleen de sniffer mogelijk via het Internet te gebruiken, nadat hij lokaal (evt wifi?) is geactiveerd.

Zie verder beneden voor een disclaimer van de onderzoeker waar hij meer toelichting geeft (post van zyphrax).
Je moet niet zomaar in de "ik denk" vorm hier iets neerzetten op basis van je persoonlijke mening. Er is namelijk iemand geweest die wel de moeite heeft genomen om het n en ander uit te zoeken en die heeft een mooie 'paper' c.q. presentatie gemaakt waar je vrijwel alles terug kan vinden. Als je de moeite had genomen om dat te lezen ipv iets ongefundeerd neer te zetten was je ook wel tot de conclusie gekomen dat het niet voor de lol er in zit.
Vrijwel alle mogelijke "legitieme" redenaties worden namelijk netjes ontkracht.

Om het alvast wat simpeler te maken de opsomming;
- Op elk device draait een 'packet sniffer' die gewoon interessante data "opslaat" en is in feite benaderbaar via het internet al dan niet wifi.
- Het is mogelijk om raw data op te halen op basis van wat je zelf wilt. Mocht het dus voor "support" zijn, dan wil je dit niet in raw data waar je dan eigenlijk niets aan hebt. Los van dat wordt de gehele encryptie genegeerd wat ook niet nodig was geweest voor bijv. support.
- Van overige applicaties kan ook alles worden "gejat", zelfs cache files en verwijderde records ('database' records dus). Van Twitter kunnen PM's, verwijderde spullen, Oauth tokens en screenshots gehaald worden.

Alles wijst dus op een algemene backdoor waarbij je letterlijk -alles- wat je maar wilt kunt "pakken", monitoren en zelfs gebruiken om verder remote te blijven monitoren.
Je punten kloppen niet, staat niet in dit artikel maar is al wel aangegeven door de onderzoekers, het is niet beschikbaar via wireless ( Wifi, 3G ), het is daarom ook geen zero-day gat. Ze willen het graag opgelost zien maar het is geen groot issue aldus de onderzoekers.
Daar heb ik het ook niet over. Punt is dat het beschikbaar is, en je kan er de klok op gelijk zetten dat dit een rede heeft. Moet iets een zero-day zijn om "gevaarlijk" te zijn? Heel het nut van een backdoor is o.a. ook dat alleen "jij" oftewel de "maker" ervan, toegang er tot hebt. Niet voor niets heet het een backdoor en niet een groot gapend gat.
Je eerste reactie gaat over pcap dat dit iets standaards is. Ja, dat staat op ontzettend veel devices, maar ze draaien niet standaard als je boot...

En verder prima, voor mij part vergeten we dan voor jou dit packet sniffer puntje, blijven er nog x-aantal andere openstaan waar niemand een normale verklaring voor heeft.
Er valt wat dit betreft veel te speculeren:
- per ongeluk (bij die SSL-bug laatst was dat best aannemelijk te noemen)
- in lijn daarvan tevens ook n.a.v. eigen doeleinden; je kunt bijvoorbeeld als externe partij gewoon niet onomstotelijk verkondigen dat dit niet gebruikt kan zijn voor debugging
- op last van de regering, en dergelijke verzoeken kunnen in het geheim worden gedaan (waarbij het juist veelzeggend is als je als organisatie niets zegt, er kan dus worden opgedragen om het vooral maar te ontkennen)
- een of meerdere werknemers met een dubbele agenda, hetzij kwaadwillend (al dan niet crimineel) of in opdracht van eerder genoemde regering
Hebben ze enig idee of deze backdoors ook in iOS 8 zitten (waarschijnlijk wel) en of er in iOS 8 nieuwe backdooors zijn gentroduceerd?
terwijl het bedrijf onlangs nog claimde dat het nooit heeft samengewerkt met overheidsdiensten om backdoors in zijn producten in te bouwen.
Ben toch wel heel benieuwd naar de reactie van Apple. Tim, kom er maar in.
Ik heb een gelekte reactie gevonden:
We at the fantastic offices of Apple believe in the magic of our devices and joy they bring to millions of families. These amazing features are built in to support you even better in time of need. We collect your information to analyse and enhance the experiences to try and improve the best mobile devices in the world. We thank this developer for the outstanding work he did and giving us a chance to enhance the unmatched trust in our brand even further.
Tim Cook

Wedden dat ik er niet ver naast zit? :+

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

*