iOS Leak FAQ
Apples Quellcode-Katastrophe
Florian Maier beschäftigt sich mit diversen Themen rund um Technologie und Management.
Manfred Bremmer beschäftigt sich mit (fast) allem, was in die Bereiche Mobile Computing und Communications hineinfällt. Bevorzugt nimmt er dabei mobile Lösungen, Betriebssysteme, Apps und Endgeräte unter die Lupe und überprüft sie auf ihre Business-Tauglichkeit. Bremmer interessiert sich für Gadgets aller Art und testet diese auch.
Bei AppleApple ist man Leaks gewohnt - wenn es um kommende Produkte oder neue Betriebssystem-Versionen geht. Seit dem 8. Februar 2018 befindet sich Apple allerdings in einer noch nie dagewesenen Situation: Ein anonymer User hatte auf der populären Plattform GitHub einen großen Teil des iOS-Quellcodes publik gemacht. Vielerorts ist vom größten Leak aller Zeiten zu lesen. Alles zu Apple auf CIO.de
Foto: Imageman - shutterstock.com
Was für ein iOS Leak?
Wie zuerst von Motherboard berichtet, wurde der geleakte iOS-Quellcode inzwischen wieder gelöscht - allerdings dürften unzählige User zuvor auf die Daten zugegriffen haben. Apple war gezwungen, sich auf den Digital Millennium Copyright Act zu berufen, um den Quellcode offline zu bekommen. Natürlich ließ die Reaktion Informierter nicht lange auf sich warten - wie etwa von Sicherheitsforscher Karl Koscher:
Fun thing about the DMCA: it required Apple to state, under penalty of perjury, that the iBoot source code was legit: https://t.co/PKHZqcEe6h
— Karl (@supersat) February 8, 2018
Laut Apples Anwälten geht es bei dem nun entfernten Content um "eine Reproduktion von Apples 'iBoot'-Quellcode". Dass es sich hierbei um proprietären Code handelt, braucht man nicht eigens zu erwähnen.
Was für ein Quellcode?
Der Quellcode um den es bei diesem Leak geht, stammt aus iOS 9.3, das im Frühjahr 2016 veröffentlicht wurde. Der Code-Abschnitt, der auf Github online gestellt wurde, ist der sogenannte "iBoot"-Quellcode. Wie der Name nahelegt, ist dieser für vertrauenswürdige Bootvorgänge innerhalb der iOS-Software zuständig. Ein solcher läuft jedes Mal ab, wenn Sie Ihr iPhoneiPhone einschalten. Laut Apple stellt dieser iOS-Bootloader "den ersten Schritt in einer ‚chain of trust‘ dar, wo jeder Schritt den nächsten auf die Signierung durch Apple überprüft." Wird dieser erste Schritt kompromittiert, könnte Schadsoftware auf dem entsprechenden Device ausgeführt werden. Alles zu iPhone auf CIO.de
Welche Folgen hat der Apple Leak?
In einem ersten Statement bemüht sich Apple um Schadensbegrenzung: "Alter Quellcode von vor drei Jahren scheint geleakt worden zu sein, aber die Sicherheit unserer Produkte hängt nicht von der Geheimhaltung unseres Quellcodes ab. In unseren Produkten gibt es mehrere Sicherheits-Layer, sowohl auf Hardware-, als auch auf Softwareseite. Wir empfehlen unseren Kunden, immer die neueste Software-Version zu installieren, um von den aktuellsten Schutzmaßnahmen zu profitieren".
Und welche Folgen hat er wirklich?
Während der iOS-Leak mit Sicherheit ziemlich peinlich für Apple ist, könnte er auch ziemlich gefährlich werden. Schließlich handelt es sich beim Bootvorgang um das Herzstück des iOS-Quellcodes, das an vorderster Front den Schutz vor Malware und anderen Angriffen gewährleisten soll. Dieser Code ist immerhin wertvoll genug, dass Apple im Rahmen seines Bug-Bounty-Programms bis zu 200.000 Dollar an Softwareentwickler bezahlt, die Schwachstellen darin entdecken.
Sicher hat der geleakte Code bereits zwei Jahre auf dem Buckel, aber es ist alles andere als unwahrscheinlich, dass mindestens Teile davon auch in der neuesten Version von iOS 11 enthalten sind. In erster Linie dürfte der geleakte iBoot-Quellcode für Jailbreaks verwendet werden. Zudem könnte iOS damit angeblich auch auf Nicht-Apple-Plattformen zum Laufen gebracht werden. Ein geradezu unvorstellbares Szenario für das Unternehmen aus Cupertino. Doch detailliertes Wissen über den iOS-Quellcode könnte auch kriminellen Hackern zu Gute kommen. Die dürften die geleakten Daten längst auf Schwachstellen und Inkonsistenzen durchforsten, um bei Erfolg ausnahmslos alle iOS-Versionen anzugreifen - nicht nur 9.3.
- Offenes Verderben
Öffentliche WLAN-Netzwerke stellen einen verbreiteten Angriffsvektor für Hacker dar, die auf der Suche nach privaten Daten sind. Sie sollten also wenn möglich stets den Umweg über VPN nehmen. Avast Software hat im Vorfeld des Mobile World Congress 2016 ein Experiment dazu am Flughafen von Barcelona durchgeführt. Das Ergebnis: Tausende MWC-Besucher hatten die Gefahr aus Bequemlichkeit ignoriert und ihre Devices und Daten aufs Spiel gesetzt. - Datenverzicht
Wo keine Daten sind, kann auch nichts gestohlen werden, verloren gehen oder missbraucht werden. Die erste Generation von Security-Lösungen für Mobile Devices versuchten die Geräte komplett abzuschirmen, um die Daten zu schützen. Inzwischen wissen wir, dass Device Management alleine nicht genügt. Verschiedene mobile Geräte und Betriebssysteme zu managen, kann dafür sorgen, dass IT-Abteilungen mit Anfragen überhäuft werden. Das wiederum fördert die allgemeine IT-Sicherheit in den betreffenden Unternehmen. Nicht. - Nonstop-No-Go
Ein weiterer Weg, Hacker vor den Kopf zu stoßen: Sorgen Sie dafür, dass Ihre Applikationen möglichst wenig Angriffsfläche bieten. Dazu sollten Sie sicherstellen, dass die Cyber-Bösewichte nicht massig Zeit haben, um einen strategischen Pfad zu Ihrer IP zu finden. Indem Sie dauerhafte Verbindungen gar nicht erst zulassen, machen Sie es den Angreifern schwer. - Vollstreckungsbescheid
Einer der schnellsten und einfachsten Wege, um Kontrolle über mobile Applikationen zu gewinnen: Prüfen Sie Ihre Richtlinien! Jedes Unternehmen sollte über einfach durchsetzbare Richtlinien verfügen, die sowohl den Zugriff der Mitarbeiter auf Mobile Apps als auch den Ressourcen-Zugriff der Applikationen selbst abdeckt. Angestellte, die nur über eine absehbare Zeit im Unternehmen sind, brauchen zum Beispiel keinen Zugriff auf das gesamte Netzwerk - stattdessen sollten sie nur auf die Applikationen zugreifen können, die sie für ihre Aufgaben benötigen. Übergreifende Berechtigungen von Third-Party-Apps sollten übrigens ebenfalls der Kontrolle der IT-Abteilung unterliegen und nicht den Mitarbeitern beziehungsweise Usern. - Schlüssel zum Glück
Security-Entwicklertools sind eine wunderbare Sache, wenn es um den Schutz Ihrer Daten geht. Mit jedem IT-Sicherheits-Layer wird es für die Netzschurken schwieriger, auf die Daten zuzugreifen. Klingt eigentlich logisch, oder? Und trotzdem ist das alles andere als "Business as usual". - Fusionsküche
IT-Sicherheit und der App-Entwicklungsprozess werden immer noch getrennt voneinander betrachtet. Dabei sollte Security längt im gesamten Entwicklungsprozess integriert sein - von den ersten Tests über die eigentliche Produktion bis hin zur Übermittlung an den App Store. Den Aspekt der IT-Sicherheit nicht in den Gesamtprozess mit einzubeziehen, kommt einem gewaltigen Fail gleich. Nur damit Sie Bescheid wissen. - Fremde Federn
Entwickler setzen bei der App-Entwicklung oft auf Komponenten von Dritten - zum Beispiel, wenn es um File-Format-Parsing oder Kompression geht. Diese modularen Bestandteile passen den Apps meist wie ein gut eingetragenes Paar Kampfhandschuhe und es wäre nicht effizient, diese jedesmal neu zu entwerfen. Allerdings sollten Ihre Entwickler in diesem Fall auf jeden Fall überprüfen, dass jede Komponente von Drittherstellern auf dem neuesten Stand ist. Auch nach Release!
Was heißt das für mein iPhone?
Der Durchschnitts-User hat wahrscheinlich - erst einmal - wenig zu befürchten. Um mit Entdeckungen aus dem iBoot Leak Ihr iPhone anzugreifen, bräuchte ein krimineller Hacker (sehr wahrscheinlich) physischen Zugang zu Ihrem Gerät. Und dazu ein bisschen Zeit, um eine böswillig modifizierte iOS-Version darauf zu installieren. Und selbst dann ist es noch nicht sicher, ob die Hacker Erfolg haben: Apple baut seit dem iPhone 5S einen speziellen Co-Prozessor (Secure Enclave) in die Hauptplatinen eigener Geräte ein, der unter anderem Sicherheit bei den Boot-Vorgängen gewährleistet. Und überhaupt: Wenn Sie auf Apple vertrauen, ist ohnehin alles halb so schlimm.
Dieser Artikel basiert auf einem Beitrag unserer US-Schwesterpublikation Macworld.