Nachtrag/ Funktionsweise USB unter Linux:
Der Linux Kernel stellt dem USB Controller ein "USB Subsystem" zur Verfügung. Dieses besteht aus 2 Teilen. Der erste Teil ist ein "Low Level Treiber", der dem USB Controller die Kommunikation mit dem verbundenen USB Gerät ermöglicht. Der zweite Teil ist das "USB Core", das die Auswahl des richtigen Treiber ermöglicht. Woher kennt das "USB Core" den richtigen Treiber, der dann von den Apps verwendet werden kann? Jeder Treiber für USB Geräte muss sich unter Linux beim "USB Subsystem" registrieren. Aus diesem Grund enthält jeder Treiber für USB Geräte den Funktionsaufruf "usb_register" im Programmcode. Wird jetzt ein USB Gerät mit dem USB Steckplatz verbunden, dann wird der USB Controller versuchen Informationen über das Gerät direkt vom Gerät abzufragen. Diese Informationen werden dann im "USB Core" verwendet, um den richtigen Treiber zu laden. Ist kein Treiber registriert, dann muss einer nachgeladen werden. Dafür muss der Anwender in der Regel einen passenden Treiber installieren, das unter Android ein Problem sein kann. Ist ein passender Treiber geladen, dann kann die App das USB Gerät verwenden.
###MSG v. 18.2.25###############
Wie bereits erwähnt, gab es bei den Apple Mobilgeräten ein Sicherheitsproblem mit dem USB Steckplatz.
Neue Versionen:
iOS 18.3.1 and iPadOS 18.3.1
für
iPhone XS and later, iPad Pro 13-inch, iPad Pro 12.9-inch 3rd generation and later, iPad Pro 11-inch 1st generation and later, iPad Air 3rd generation and later, iPad 7th generation and later, and iPad mini 5th generation and later
iPadOS 17.7.5
für
iPad Pro 12.9-inch 2nd generation, iPad Pro 10.5-inch, and iPad 6th generation
Was ist passiert?
Apple schützt die USB Schnittstelle mit eine Art "Blocker" Programm (evtl. muss man es in den Einstellungen manuell aktivieren und danach ein Neustart). Auf Android Systemen kann es vorhanden sein, aber muss nicht. Dieses "Blocker" Programm hatte eine Sicherheitslücke.
Wie muss man sich die Funktionsweise des Programms vorstellen? Ihr habt das Mobilgerät vor euch zu liegen und der "Lockscreen" ist aktiviert, d.h. man müsste erst eine PIN oder Ähnliches eingeben, um das Gerät zu aktivieren. Jetzt nehmt ihr ein USB Gerät und verbindet es mit dem Mobilgerät. Ohne USB Sperre würde der USB Controller des Mobilgerätes das USB Gerät über das Kabel abfragen (zumindest kenne ich es so vom Android). Mit dieser Abfrage erhält der Controller Informationen über das USB Gerät, wie Hersteller und Geräteklasse; und kann dann entscheiden, welches Treiberprogramm verwendet werden muss. Der Treiber ist letztlich eine Datei, die Informationen enthält, wie die Kommunikation mit dem USB Gerät erfolgen muss und ermöglicht diese. Ist es ein einfaches Gerät, wie eine Tastatur, dann wird der Controller einen einfachen Treiber laden. Ist es eine externe Disk, dann wird es bereits spezieller und es wird ein angepasster Treiber eventuell vom Kernel nachgeladen. Das passiert alles, obwohl der Zugriff auf das Mobilgerät eingeschränkt ist. Habt ihr jetzt zum Beispiel eine Tastatur angeschlossen, dann könnt ihr vielleicht bereits die PIN auf dem "Lockscreen" mit der Tastatur eintragen. Gibt es einen "Blocker", dann sollte dieses nicht möglich sein und es wird vielleicht sogar ein durchgestrichenes USB Symbol angezeigt (zumindest kenne ich das so von Android Mobilgeräten).
Wenn jetzt das System aber bereits nur durch die USB Verbindung so viele Aktionen ausführt, dann könnte man dieses vielleicht für einen Angriff ausnutzen. Schließlich werden bereits Daten gesendet und verarbeitet. Im Normalfall würde das USB Gerät erkannt werden, aber man könnte nichts machen, weil das Mobilgerät im "Lock" Modus ist. Aber wenn es eine Sicherheitslücke, eine fehlerhafte Programmierung, bei einem der im Hintergrund ablaufenden Prozesse gibt, dann könnte man manipulierte Daten senden, um dadurch die Möglichkeit zu erhalten, einen schädlichen Programmcode einzuschleusen (vielleicht ein Exploit). Beispiel "Lockscreen"... Der "Lockscreen" erwartet eine 4 stellige PIN für die Freigabe. Jetzt nehmen wir mal an, wir hätten die Möglichkeit über ein Programm an die USB Schnittstelle mehr Daten als nur die 4 stellige PIN zu senden. Der "Lockscreen" enthält dann auch noch eine fehlerhafte Programmierung (es ist nur ein theoretisches Beispiel!) und prüft nicht, ob die Daten nur aus 4 Zahlen bestehen. Dazu kommt dann noch, dass der zugesicherte Speicher für die 4 Zahlen nicht gesichert ist. Wenn man jetzt weiss, dass die Daten eines Programms in einer ganz bestimmten Reihenfolge gespeichert und von der CPU verarbeitet werden, dann könnte man auf die Idee kommen, dem Programm "Lockscreen" eine sehr lange Zeichenkette zu übergeben. Wenn man dann Glück hat, dann könnte man dadurch den Speicherbereich, der eigentlich danach folgenden Daten manipulieren oder seinen eigenen Programmcode einfach einfügen und zur Ausführung bringen, d.h. man könnte den "Lockscreen" einfach deaktivieren, zum Absturz bringen oder sein eigenes Programm zur Ausführung bringen, das dann eine "Hintertür" auf dem Mobilgerät öffnet. Ich hoffe, dass ich es halbwegs verständlich erklären konnte. :)
Irgendwo auf Youtube müsste ein Video vom "Chaos Computerclub" existieren. Ich glaube jedenfalls, dass es von denen kam. Da hat mal jemand eine ähnliche Sicherheitslücke präsentiert. Manchmal machen die sowas. Ansonsten hatte Apple vor vielen Jahren bereits eine ähnliche Lücke. Zumindest glaube ich zu wissen, dass es Apple war. Apple hatte sein neuestes MacOS PC System präsentiert mit dem Vermerk "Sicherstes System aller Zeiten". Ein damals bekannter Hacker hatte sich das zu Herzen genommen und ist dann damals auf das MacOS System losgegangen. Das Einfallstor war ebenfalls eine externe Schnittstelle; Thunderbolt oder ein einfacher serieller Steckplatz... Dazu müsste man auch noch etwas finden. Weitere Suchbegriffe wären Kompilieren, Debuggen, Maschinencode.
Ist es schlimm keinen "Blocker" zu haben? Wenn das System richtig arbeitet, man die Einstellungen und Funktionsweisen kennt, dann ist das Risiko akzeptabel. Man hat mit einem "Blocker" auf jeden Fall ein besseres Gefühl. Ihr müsst deswegen nicht gleich ein Samsung Smartphone oder Apple Smartphone kaufen...