Afgelopen donderdag werd bekend dat iBoot-code van iOS 9 op GitHub terecht was gekomen, kort daarna liet Apple weten dat dit lek nauwelijks effect zou hebben op de veiligheid, en al helemaal niet van iDevices waar iOS 10 of later op staat.

Inmiddels is het Motherboard gelukt om de origine van dit lek te achterhalen en op te tekenen hoe dit allemaal in zijn werk ging. Interessant om te lezen, en niet alleen omdat het leest als een jongensboek. Dat laatste is wel het geval, want het verhaal begon bij een werknemer bij Apple die helemaal geen hoge post had (a low-level Apple employee), die het 'gewoon' leuk vond om deze code met zijn naaste vrienden te delen.



Daarbij waren geen kwade bedoelingen, in tegendeel, het groepje vrienden probeerde juist ervoor te zorgen dat de code zich niet verder zou verspreiden. Dit ging een tijd goed, terwijl deze werknemer van Apple al in 2016 deze code kopieerde, was het pas in de loop van het jaar daarna dat ze steeds meer de controle erover kwijtraakten.

Het resultaat was dat de iBoot-code op een gegeven moment op de software deel-site Mega terecht kwam, waar het snel door een moderator-bot weer verwijderd werd. Maar dat betekende nog meer verspreiding, waardoor het uiteindelijk op GitHub Utrecht kwam, en zo'n beetje de hele jailbreak en security-community het nu in handen heeft.

Vragen die dit oproept

De grote vraag die dit verhaal oproept is hoe het mogelijk was dat iemand zonder een hoge status binnen Apple niet alleen de iBoot-code kon kopiëren, maar ook toegang tot nog veel meer code had. Apple mag beweren dat de veiligheid nooit van broncode afhangt, maar hoe meer van je code op straat ligt, hoe meer mogelijkheden er kunnen zijn voor reverse engineering van die code, en het vinden van mogelijke gaten daarin.

Het wordt interessant om te zien hoe Apple hier de komende tijd mee om zal gaan. Het lijkt voor de hand te liggen dat op zijn minst een aantal interne veiligheidsprotocollen verder aangescherpt zullen worden, want dat lijkt het minste wat er op dit moment in Cupertino zal moeten gebeuren.



met dank aan forumlid 'VwVanFan', die dit nieuws als eerste meldde

Met alle respect: hiet staat ongeveer hetzelfde verhaal, maar met een hele andere nuance uitgelegd:
https://tweakers.net/nieuws/135099/stagiair-bij-apple-was-verantwoordelijk-voor-lekken-iboot-broncode.html

Ik zie de andere nuance niet...

Broncode is bij zowat alle IT bedrijven voor iedereen beschikbaar. Ook bij Apple. Het motto is dat iedereen code van de collega's moet kunnen inkijken omdat nu eenmaal alles in mekaar grijpt. Als het iCloud team een netwerk probleem heeft met iOS moeten die de netwerk code van iOS kunnen inzien. Als ze daarvoor een bericht moeten sturen en wachten, wordt het probleem nooit opgelost in de meeste gevallen.

Ik zie dan ook niet in wat Apple zou kunnen aanpassen. Tenzij stagiairs geen toegang meer geven. Maar wat komen ze dan nog doen bij Apple?

Stagiairs worden in de USA veelvuldig misbruikt om bv. koffie te zetten, de telefoon te beantwoorden etc. Dat is niet de taak van een stagiair. Die komt om de praktijk te leren. En de praktijk in programmeren leer je niet door koffie te zetten, maar door code te schrijven.

Apple is één van de bedrijven waar stagiairs nog behandeld worden zoals het zou moeten, vziw.

Het is allemaal nogal een storm in een glas water, als je 't mij vraagt. Oude code, van één systeem. Zeker interessant voor jailbreakers, maar zijn die er nog?

Ik ben het helemaal eens met cyrano. De enige oplossing zou zijn stagiaires niet meer inzage te geven, maar dan snijdt je in je eigen vingers en vooral in je eigen toekomst.

Ik kan nog wel enigszins meegaan met het verhaal, misschien zou je startende medewerkers enigszins kunnen beperken wat betreft de toegang. Maar ik zou niet weten hoe je dit in de praktijk uit zou moeten werken, en ben benieuwd of ze hiervoor bij Apple wel een oplossing kunnen vinden.

Misschien is het eerder een geval van bedrijfscultuur, die moet zodanig zijn dat je dit soort code helemaal niet naar buiten mee wilt nemen.

Wat ik hoor is dat ze de logging gaan bijstellen én koppelen aan een "fysisch ID", waarschijnlijk in de vorm van een badge, watch of iphone.

Dan kunnen ze meteen zien wie verantwoordelijk is voor de kopie. Dat zou genoeg moeten zijn om 't te voorkomen.

Het maakt het systeem natuurlijk meteen een doelwit voor "testers", die willen zien of ze er voorbij kunnen komen met social engineering.

Hey Henk, mag ik je iphone effe lenen? Mijn batterij is leeg...