 Hallo, ihr hört den Vortrag Broadcom Bluetooth zerlegen in der Übersetzung von Stefan und Eibwen. Herzlich willkommen auf der Bühne Dennis Jans und Jiska Klassen. Vielen Dank für die Einleitung. Ich bin Dennis und ich habe mich für mein Master für Bluetooth entschieden. Ich habe die Firmware eines Bluetooth-Kontrollers reverse-engineered, einem Controller von Broadcom und heute beschäftigen wir uns nicht nur mit dem Framebox, mit dem ich das gemacht habe, sondern ich habe auch ein paar Beispiele mitgebracht. Wenn ihr euch schon mal damit beschäftigt habt, dann wisst ihr, dass das relativ aufwendig ist und Zeit, auch drin viel Zeit braucht und deshalb könnt ihr euch die Frage stellen, warum macht man sowas überhaupt? Wenn man sich also die Firmware mal genauer anschauen will, dann ist das sehr hilfreich, wenn man sich mit der Sicherheit des ganzen Systems beschäftigen möchte. Und noch besser, wenn es euch gelingt, die Firmware anzupassen, dann kann man daraus eine Experimentierplattform für Bluetooth machen und man kann bestehende Verhaltensweisen des Systems verändern und man kann so eine Art Open Source Touch dem ganzen geben, obwohl das ja eigentlich proprietäre Software ist. Und natürlich braucht man ganz viel Hintergrundwissen in verschiedenen Aspekten, Sicherheit, Code-Analyse, wie drahtlose Systeme funktionieren und nicht viele Leute haben die Zeit, um sich all das einzuarbeiten. Aber dadurch, dass wir jetzt uns diese Arbeit gemacht haben, kann die Community davon ganz stark profitieren. Wir haben in der Vergangenheit ähnliche Sachen gemacht, vielleicht kennt ihr das Nexmon Projekt, wo wir ein Wi-Fi Controller reverse engeniert haben und auch dessen Firmware modifiziert haben. Wir brauchen erst mal eine kleine Einführung Bluetooth Begriffe und wie so ein Controller eigentlich funktioniert. Und das erste ist das so-called Host Controller Interface. Das ist eine Protokollschicht zwischen dem Bluetooth Controller und dem eigentlichen Rechner, der das Bluetooth Modul verwendet. Und das gibt es überall in jedem Betriebssystem, das Bluetooth verwendet. Die oberen Schichten sind im Betriebssystem implementiert und die unteren Schichten in der Firmware. Und dazu gehört zum Beispiel der sogenannte Link Manager LLMP. Und diese unteren Schichten managen die Verbindung zu anderen Geräten, zum Beispiel das Pairing. Das ein interessanter Unterschied ist, dass das Link Management Protokoll über die Funkschnittstelle verwendet wird, während das Host Controller Interface nur zwischen Modul und Betriebssystem verwendet wird. Das HCI kann man sich von der Betriebssystemseite aus anschauen. Man kann BT Snoop verwenden, um entsprechende Pakete in Wireshark oder TCP Dump sich anschauen zu können. Und ihr werdet wahrscheinlich LLMP Pakete nicht in Wireshark gesehen haben, denn das passiert innerhalb des Controllers und kann von außen nicht beobachtet werden. Und deswegen kann man das mit einer entsprechenden Capture Software nicht aufzeichnen. Die andere Sache ist, dass man das nicht einfach auf der Funkschnittstelle mithören kann, weil das zum Beispiel wegen des Frequency Hoppings das zu Bluetooth gehört nicht einfach mit aufzeichnen kann. Und wir haben hier ein paar Sachen eingebaut, mit denen das möglich werden. Und da geht es also um dieses Framework, was ich gebaut habe. Und hier geht es um ein paar Features, die wir da implementiert haben. Wir haben das Internal Blue genannt. Es ist Open Source. Man kann das auf GitHub finden. Im Moment ist es nur mit dem Nexus 5 kompatibel, wenn man alle Features verwenden will. Aber wir arbeiten daran, das auf andere Bluetooth Chips und Telefone und Raspberry Pi zu potieren. Und das sollte bald soweit sein, dass man auch mit anderen Geräten was machen kann. Wir haben schon mal einen Vortrag gehalten, wo wir den Vortrag, wo wir das Framework verwendet haben, um bestimmte Details über Bluetooth zu erklären. Und unter dem Link hier unten auf der Folie könnt ihr mehr dazu erfahren. Das Entscheidende ist, dass wir Hersteller spezifische HCI Befehle verwenden, um in die Firma einzugreifen. Und wir haben ein Python API geschrieben, um dann direkt mit der Firma reden zu können und die Features zu implementieren, die für uns interessant sind. Eine der ersten Sachen, die wir gemacht haben, war ein LNP Monitor zu implementieren, damit wir mitbeobachten können, was da eigentlich passiert. Und dazu gehört dann auch, dass wir LNP Pakete indizieren können. Und das hat sich als sehr interessant herausgestellt, weil wir damit ausprobieren konnten, wie sich andere Geräte verhalten, wenn man ihnen unerwartete Pakete schickt. Und wir haben damit einen kleinen Proof-of-Concept gebaut, der diese Fix-Coordinate Invalid-Curve-Attack implementiert. Und wir konnten damit zeigen, dass dieser Angriff bei einer ganzen Reihe von Geräten funktioniert, indem wir diese Pakete senden konnten. Wir konnten auch in älteren Broadcom-Firmware-Versionen entsprechende Probleme finden. Wenn man denen bestimmte Daten sendet, dann stürzen die ab. Oder man kann dann sogar bestimmte Funktionen aufrufen, die sogar noch interessanter sind als ein Crash. Wenn wir mal mit dem wichtigsten Detail anfangen, wie können wir die Firma verändern? Broadcom hat Hersteller spezifische Erweiterung, um RAM zu lesen und zu schreiben und Code im RAM zu starten. Das Ganze passiert im Adressraum der Firma und wird dann eben auch auf dem Bluetooth-Modul ausgeführt. Broadcom verwendet das, um Firmware-Updates durchzuführen. Das sind HCD-Dateien, die diese Firmware-Updates enthalten. Wenn ihr so ein Firmware-Update durchführt, dann solltet ihr solche Dateien finden. In dieser Datei stehen tatsächlich nur eine Reihe von diesen Befehlen drin, um temporäre Patches in das Rom zu laden. Bei anderen Herstellern heißt das Petram. Auch das haben wir reverse-engineered. Wir wissen jetzt, wie man dieses Patching selber machen kann. Was auch sehr interessant ist, dass diese Dateien weder verschlüsselt, noch signiert sind. Man kann die relativ einfach anpassen, sobald man verstanden hat, wie die aufgebaut sind. Auch das, was da im Rom passiert, ist nicht in irgendeiner Weise abfussiert. Man kann das ganz problemlos verstehen. Im Moment schreiben wir Assembler-Code und wir schreiben auch Assembler-Patches. Wir wollen das in Nexmon einbauen, damit wir den Code mit C schreiben können. Natürlich müssen wir erst mal das eigentliche Reversing machen. Das ist zwar nicht obfussiert, aber es gibt keine Strings. Es ist sehr schwer, das zu verstehen. Ich habe ein Tool verwendet, das versucht die funktion, die anonymen Funktionen in Module zu sortieren. Das Problem ist, dass wir dann hunderte von Modulen haben, die noch nicht so, das macht keinen Spaß. Es gibt 2.500 Seiten Blutdokumentation und wir wissen, wo die Parameter stehen sollten. Dann sucht man nach genau diesen Konstanten irgendwo im Assembler-Code. Wenn man dann was findet, dann könnte das genau die Funktion sein. Das haben wir monatelang gemacht auf den Standardsstachen und dann wieder auf den Code starren. Dann haben mich Leute gefragt, funktioniert das auf aktuellen Geräten? Das Problem ist, dass selbst der Nexus 6P von 2015 ist. Ich habe einen Entwickler-Bord mir besorgt. Das ist auch etwas älter von dem letzten Jahr. Die Firma wurde von Broadcom gekauft. Es war Zypress, aber das ist genau das, was Broadcom verwendet. Ich konnte tatsächlich genau dieselben Befehle verwenden, um die Firma zu modifizieren und auch zu extrahieren. Ich habe es am 6. Dezember bekommen und drei Tage später hatte natürlich alle Funktionsnamen. Irgendwo hat irgendjemand eine Symboldatei vergessen, die tatsächlich eine vollständige Symboldatei für 11.000 Funktionen enthält. Sehr schön. Also ja, einfach ein bisschen früher die Entwickler-Bords kaufen. Dann nähern wir uns mal der ersten Demo. Wir haben dieses Linkmanager Protocol, was das erste interessante Ding ist. Es wird in der Firma implementiert. Man kann es irgendwie von draußen nicht sehen. Man kann es nicht mit Wire Shark sehen. Wir haben jetzt einen Patch geschrieben, der in die Funktionen reinhuckt und der vorwortet die HCI-Pakete alle zurück zum Android-Telefon. Dort haben wir Debugmodus aktiviert und dort können wir es dann zum Host-Computer zurückleiten mit einem Custom-Dissector in Wire Shark, können wir es dann lesen und dann haben wir unseren Monitor-Mode. Außerdem haben wir einen LMP Injection-Mode. Da können wir die Funktion verändern, die LMP-Pakete tatsächlich verändert zu anderen Geräten. Dann können wir beliebige Pakete zu anderen Geräten schicken. Dann gehen wir mal in die Kommando-Zeile. Die Frameworks starten wir mal. Das hier ist so ein Kommando-Zeilen-Interface. Damit können wir mit der Firma interagieren. Da können wir den Monitor-Mode starten, indem wir das hier eingeben. Das startet Wire Shark und installiert all die Patches auf die Firmware des Telefons. Von hier auf sehen wir dann allen LMP-Traffic in Wire Shark. Aber zurzeit haben wir kein Bluetooth-Verbindung, deswegen sieht man da nichts. Es funktioniert. Jetzt müssen wir noch irgendwie Verkehr erzeugen, wir können sie pairen, aber ich möchte etwas anderes zeigen. Bluetooth hat ein paar interessantere Features, jedenfalls die vielleicht nicht jeder kennt. Für mich war es jedenfalls eine Überraschung. Selbst wenn das Gerät nicht als discoverable, also als entdeckbar gesetzt worden ist, dann kann niemand anderes trotzdem immer noch verbinden, solange man die MAC-Adresse kennt. Man merkt davon nicht mal was, weil der Pairing-Prozess übersprungen wird. Das heißt, solange man die MAC-Adresse kennt, kann man sofort damit verbinden und sofort kommunizieren. Die MAC-Adresse herauszufinden ist auch nicht so schwer. Da gibt es so ein Talk, der heißt Bluetooth Smart Like Chicken, Bluetooth riecht wie Hühnchen und da könnt ihr mehr darüber lernen. Ich kann hier einfach Connect eingeben und eine MAC-Adresse angeben. Auf der rechten Seite sehen wir ein Nexus 6P, das wird unser Ziel sein. Hoffentlich könnt ihr die MAC-Adresse grad so lesen. Auf der linken Seite ist das Nexus 5, welches wir für Test nutzen und das wird auch für Internal Blue benutzt. Wenn ihr seht, das 6P ist nicht entdeckbar, weil es nicht in Bluetooth-Milionär ist. Ich kann trotzdem mit ihm verbinden, wenn ich Connect und die MAC-Adresse eingebe. Es könnte ein paar Versuche, ah nee, es hat sofort funktioniert. Jetzt sehen wir ein bisschen Traffic. Was wir auch sehen ist, wir auf dem Nexus 6P sieht man nichts, der Nutz hat nichts mitbekommen, aber wir haben trotzdem eine Verbindung. Hier seht ihr all die Sachen, die auf dem Protocol Layer passieren. Es gibt Feature Request, Versionsrequests und ganz viele andere Sachen und die Namensrequests, damit die sich gegenseitig den Namen kennen. Jetzt können wir beliebige LMP-Pakete senden. Zum Beispiel mit 01, was ein Namens-Anfrage ist. Dann sehen wir hier drüben den Namens-Anfrage und da sehen wir die Antwort mit dem Namen drin. Dann soll man hier irgendwo sehen, den Namen Nexus 6P, so wie unser Gerät heißt. Aber ich kann irgendwelche LMP, oh, das andere Gerät ist schon wieder disconnected. Falls das andere Gerät nichts, wenn das Detach, dann muss man das neu attachen, weil wenn das Gerät eine Weile lang nichts sieht, dann wird es einfach disconnected, wenn wir nicht gepärt sind. Und wenn wir jetzt ein Feature Request sehen, dann kriegen wir eine Antwort, dass das nicht unterstützt ist, so wie es richtig ist. Das ist natürlich sehr interessant für einen Sicherheitsforscher und dann können wir uns anschauen, wie genau die Sachen reagieren, wenn man ein interessanter Paket ist. Das sollte jetzt die erste Demo gewesen sein und machen wir mal weiter mit den Slides. Das andere im Blutflussstandard ist, dass man Geräte miteinander verbinden können muss, die weder Anzeige noch Eingabenmöglichkeiten haben. Und das ist zum Beispiel bei jedem Headset der Fall und das bedeutet, dass man als Man in the Middle natürlich das Gerät darstellen kann gegenüber dem anderen Gerät als eins, dass keine Eingabenmöglichkeiten haben. Und hier ist ein kleines Demo Video, wo man sehen kann, wie wir auf der linken Seite Nexus 5, auf der rechten Seite iPhone und ich verbinde die miteinander und ich habe die Eigenschaften der Geräte miteinander verbunden. Und man sieht, dass auf dem iPhone kommt nur die Frage, ob man das möchte oder nicht. Aber ohne weitere identifizierenden Daten, links sieht man die ID-Nummer, die normalerweise rechts auch zu sehen sein sollte. Und auf dem iPhone gibt es keine Warnung, mit welchem Gerät man sich tatsächlich verbindet. Und auch kein Hinweis, dass man prüfen sollte, dass das andere Gerät tatsächlich keine Ein- und Ausgabenmöglichkeiten hat. Und dann haben wir die Verbindung. Das sind Sachen, die im Standard definiert sind, das ist also nicht so überraschend. Die Frage ist, können wir mehr Fehler finden? Zuerst wollte ich gar nicht irgendwelche Fehler im Bluetooth finden, sondern ich wollte erst mal verstehen, wie das eigentlich funktioniert. Und hier gibt es so einen kleinen Bug, wo die Parameter überprüft werden. Und da gibt es einen Händler, der gar keine Checks hat. Und dann habe ich die Firma-Version, die mir zur Verfügung stehen, habe ich überprüft und habe festgestellt, dass sie in 2014, dass sie das einfach korrigiert haben. Aber sie haben ältere Geräte nicht, für ältere Geräte keine neue Version, keine neue Version bereits gestellt haben. Und dann habe ich Broadcom kontaktiert und habe gesagt, ihr habt ein Problem und Broadcom hat gesagt, wir haben kein Problem. Dann habe ich Ihnen mehr Details gezeigt und Sie haben immer noch gesagt, nein, machen wir nicht. Und dann habe ich schließlich die Antwort bekommen, ja, das hat keine Auswirkungen auf die WLAN Performance. Also bei meinem nächsten X-Point achte ich darauf, dass der Standard kompatibel ist. In meinen Tests konnte ich tatsächlich alles Mögliche damit machen. Und darüber kann man zum Beispiel auf einem anderen Gerät Bluetooth ausschalten. Und Broadcom hat nicht wirklich viel darüber erzählt, also habe ich das selber getestet. Und ich habe eine ganze Reihe von Geräten, deren Firmware dieses Problem noch hat. Und das iPhone 6 gehört dazu, ältere MacBook Pros, mein Nexus 5, der Raspberry 3. Und dann habe ich meine Studenten gefragt, darf ich eure Geräte testen? Nee, bist du verrückt? Und das ist die Liste, die ich in den letzten Wochen zusammenstellen konnte. Und das ist das, was ich hier demonstrieren möchte, BTB Gone, also Bluetooth sei weg. Und damit werde ich hier das Abspielen des Tons aber auf dem Lautsprecher beenden. Ich muss hier in das Bluetooth hier reingehen. Screen an Screen, die Telefone zeigen. Und ich hatte noch ein Song, Bluetooth ist nicht real. Lass uns mit der Demo anfangen. Also erstmal patchen will ich hier das Nexus 5 mit unserer lustigen Angriffsoftware. Das dauert einen kleinen Moment, bis das iPhone mitbekommt, dass das Bluetooth jetzt tatsächlich ausgeschaltet ist. Und jetzt ist es weg. Und dann wird es wieder eingeschaltet und dann kann ich das aber immer wieder wiederholen. Das geht so schnell, dass die Person, die das Gerät, das iPhone benutzt, das auch gar nicht wieder eingeschaltet bekommt. Das geht viel zu schnell dafür. Und was passiert da eigentlich genau? Also Crash ist tatsächlich der beste Fall. Dieser Handler, das ist der Handler A, weil ich hier nicht offenlegen will, wo das wirklich ein Problem liegt, weil es Broadcom noch nicht gefixt hat. Und dieser Handler sollte zwei Parameter nehmen und es prüft den Bereich nicht, der da tatsächlich verwendet wird. Und der Compiler tut beide Händler direkt hintereinander. Und deswegen können wir von diesem Handler aus den anderen aufrufen über 250 unterschiedliche Funktionen. Und darüber können wir Funktionen ausführen. Auf dem Nexus 5 haben wir uns das genauer angeschaut, dass wir den Testmodus aktivieren können. Den soll man normalerweise nur aktivieren können, wenn man ein Routrechter auf dem Gerät selber hat. Und dann kann man die verschiedenen Frequenzen testen und ähnliches. Und das kann ich jetzt tatsächlich aus der Ferne starten. Das habe ich jetzt nicht mitgebracht, weil ich das würde hier nicht so richtig gut funktionieren, weil hier einfach zu viel Traffic ist. Und deswegen hier im Video, auf der rechten Seite mache ich den Angriff. Und wir sehen hier den Standard-Testmodus, wie es durch alle Frequenzen durchgeht. Die Pakete sind hier nicht ganz in der richtigen Reihenfolge, weil ich hier nur eine Warteschlange gesteckt habe. Und zuerst Test-Control und Test-Activate. Und zuerst werden sie nicht akzeptiert. Und nach dem Fragezeichen Payload kann man sehen, dass es dann akzeptiert wird. Und links kann man sehen, wie der Test tatsächlich abläuft. Und dann wird es tatsächlich akzeptiert. Magie. Wenn man das jetzt kombiniert mit der Unterdrückung des aktiven Frequenzsprungs, dann kann man tatsächlich das Zielgerät zum Beispiel dazu bringen, eine bestimmte Wi-Fi-Frequenz zu blockieren, weil die ja im Zweifelzweil über die selber Antenne senden. Und das haben wir auf dem Letztags 5 und auf dem Xperia Z3 ausprobiert, weil sie denselben Controller verwenden. Das funktioniert wahrscheinlich auch mit anderen Geräten, die denselben Controller verwenden. Als wir den Back gefunden haben, haben wir angefangen, eine Toolchain zu bauen, damit man entsprechende Tracepoints innerhalb der Firma setzen kann, damit man ein bisschen besser sieht, was da im Controller passiert. Wir haben eine Emulation aufgesetzt mit Unicorn und Radatoo. Aber das ist zwar sehr langsam, damit kriegt man aber die gesamte Funktionsaufrufsequenz. Und ich habe einen Student, der gerade mit QEMO am Arbeiten ist, um das schneller zu machen. Es gibt jede Menge Ausgabe aus dieser Geschichte, die wir noch nicht vollständig analysieren konnten. Da steckt also wahrscheinlich noch mehr drin. Jetzt müssen wir diese Bugs irgendwie fixen, weil es irgendwie ein bisschen problematisch. Deswegen habe ich euch auch nicht gesagt, was genau man senden muss, um das Problem zu zeigen, weil es müsste irgendwie, wenn wir das machen würden, dann so ein Patch raus geben würden, dann könnte man direkt davon ablesen, wo der Fehler ist und dann ist es ein bisschen problematisch. Man könnte einen generischen Fix bauen, irgendwie, dass man nicht mehr zu unbekannten Geräten antwortet und so weiter. Aber als ich das gemacht habe, getestet habe, manchmal crasht dann tatsächlich die Verbindende des Verbindengeräten manchmal. Also hatte ich den nächsten Back gefunden, während ich den ersten fixen wollte. Also kann ich jetzt leider keinen Fix veröffentlichen. Weil sie den nächsten Back schon wieder verursachen. So, wie lange wird es diesen Back noch geben? Na ja, ziemlich lange wahrscheinlich, weil es paar Geräte gibt, die keine Hersteller-Updates mehr kriegen. Es muss aber in den Hersteller-Updates kommen. Wir können das natürlich auch veröffentlichen als HDDatei, aber das wird natürlich kein effizientes Update sein. So, es ist natürlich ein Henne-Eye-Problem, dass wir das nicht veröffentlichen können. Es gibt von uns den Hinweis, dass ihr Bluetooth wahrscheinlich besser ausschalten solltet, insbesondere wenn es vor 2017 produziert worden ist. Aber im Allgemeinen, schaltet es einfach aus. Es ist die sicherste Option. Und es gibt alte Geräte mit Bluetooth 3.0, die sind nicht verwundbar, aber trotzdem ist es eine große Anzahl an Geräten, die verwundbar sind. Vielen Dank. Und wieder, wenn ihr Fragen habt, dann haben wir hier acht Mikrofone in dem Raum. Bitte stellt euch an an den Mikrofonen und ihr könnt eure Fragen stellen. Der Signalengel hat eine Frage aus dem Internet. Ja, jemand aus dem Internet fragt, ob man, wie man erraten kann, wie die Mac-Adresse eines Bluetooth-Gerätes ist. Können wir noch mal die Kamera einschalten auf meinem magischen Kasten hier? Also, wenn man hier in die Einstellung geht, über und dann unten sieht man, dass die WLAN und die Bluetooth-Adresse normalerweise sich nur in eine Stelle unterscheiden. Also, die Antwort ist ja. Ihr müsst wissen, dass das aber nicht bei jedem Telefon so ist. Einige Hersteller versuchen, die Geräteadresse dynamisch zu unterscheiden, dynamisch zuzuweisen, so dass man das nicht mehr tracen kann. Und das hört vom Hersteller ab. Zumindest die unteren Bits sollten sich dann tatsächlich dynamisch unterscheiden. Und manchmal geht es also manchmal nicht. Okay, die nächste Frage von Mikrofon Nr. 8. Ganz da hinten in der Halle. Danke für euren Vortrag. Ich wäre interessierter, wie man zu einer Bluetooth-Divis connecten kann mit nur der Mac-Adresse, während es nicht veröffentlicht ist. Es gibt Möglichkeiten, die Mac-Adressen von Geräten in deiner Nähe in Erfahrung zu bringen. Selbst zum Beispiel, wenn das Gerät nicht erreichbar ist, aber man Bluetooth im Moment verwendet, zum Beispiel um Musik über Kopfhörer zu hören, dann kann man natürlich mit einem entsprechenden Gerät den Bluetooth-Funk mithören. Und dann kann man natürlich die Mac-Adresse auf die Art und Weise rausfinden. Und in diesem Talk hier wurde sehr genau erklärt, wie man aus diesen Paketen diese Mac-Adresse rauslesen. Es ist nicht so einfach wie bei WLAN, aber es ist definitiv möglich. Nächste Frage von Mikrofon 1. Vielen Dank für den Vortrag. Die Frage ist, hat die Firma irgendwelche Absicherung gegen Exploits? Und falls es das heißt, würde es dagegen helfen? Es gibt keine Adress, randomisation. Die meisten Sachen sind globale Adressen im Firmware-Adressraum und das RAM ist ausführbar. Also man kann auf dem Stack ausführen, auf dem Hieb. Es gibt eigentlich überhaupt keinen Schutz gegen Angriffe. Ich glaube, auch die neuen Modelle haben das nicht. Und was uns relativ gut hilft, LNP hat eine Versionsabfrage und Antwort. Und wir können sehr einfach rausfinden, ob die Firma angreifbar ist und dann genau den Angriff laufen lassen, für die auf dieser Firma funktionieren mit genau den richtigen Adressen. Die nächste Frage von Mikrofon 2. Dann 1, 3 und 5. Hallo. Vielen Dank für die Arbeit. Insbesondere für Bluetooth begann. Es ist das neue TV begann. Ihr hattet ein Slide, das iPhone 6 verwundbar ist. Funktioniert das auch mit dem neuesten Telefon? Nur bis zum iPhone 6, das ist das neueste Gerät, was ich in die Finger bekommen konnte. Ein iPhone 8 funktioniert nicht. Das Problem ist, dass viele Leute, die schlechte Musik spielen, neue Telefone haben. Der Angriff funktioniert nicht auf dem iPhone 6, aber diese Framework funktioniert. Das funktioniert auf jedem Broadcom Chip. Broadcom nutzt diesen Mechanismus für alle Geräte. Das heißt, wir können diese Framework für alle Geräte benutzen. Das heißt, wir müssen bloß Reverse-Engineern, wo die realen Adressen sind und so weiter. Aber du brauchst immer Route auf dem Gerät, um unser Framework hier einsetzen zu können. Nun die Frage von Microphone Nummer 1. Habt ihr eine Liste von verwundbaren Chipsets, sodass ich wissen kann, ob mein Device verwundbar ist? Ja, haben wir. Die Liste ist aber sehr unvollständig. Ich hab auch die Versionen und Unterversionen dieser Telefone. Aber wenn du gerät hast, dass Bluetooth 4.0 bis 4.2 unterstützt und ein Broadcom Controller hat, dann ist es wahrscheinlich angreifbar. Microphone Nummer 3. Vielen Dank für den Vortrag. Habt ihr euch Auto-Bluises angeschaut und falls nicht, wollt ihr mal darüber nachdenken? Ich hab dieses Tool tatsächlich, wir haben andere Geräte, andere Angriffe getestet. Ich hab mit dem Tool an meinem Autoradio ausprobiert. Der Angriff ist schon gepatched worden, aber mein Autoradio war definitiv noch angreifbar. Man kann diese Tests verwenden, aber wir haben uns das noch nicht speziell angeguckt. Dann 5 das Internet und dann Nummer 6. Was ist die Angriffsoberfläche, die von eurem Angriff gegeben wird? Das ist schwer zu sagen. Wir können definitiv Speicher verändern im Nexus 5 und dafür müssen wir noch sehr viel mehr analysieren, wie die Firmenwerte jeweils funktionieren, ein bisschen Fussing betreiben. Bestimmte Sachen funktionieren nur, wenn man mehrere Pakete kombiniert und es ist also schwer zu sagen, was der schlimmste anzunehmende Fall ist. Der schlimme Fall ist definitiv, dass man beliebigen Code in der Firmenwerte ausführen kann. Wenn man das dann noch mit einem Problem im Betreiber auf der OS-Seite kombinieren könnte, dann wäre der schlimmste anzunehmende Fall, dass man tatsächlich über die Funktionsschnittschnelle auf den Host drauf kommt. Wir haben gesehen, dass es bei WLAN, bei den Broadcom Chips, genau solche Probleme gab, wo man tatsächlich einen Rechner ruten konnte über Probleme im WLAN-Treiber und der Netzwerkschen-Stelle. Nun, aus dem Internet. Kennt ihr irgendwelche sind, sind alte MacBooks gepatched oder so? Könnt ihr das erkennen? Nicht wirklich. Wir können versuchen, den Chip nicht zu crashen, indem wir prüfen, ob wir vernünftige Antworten zurückbekommen, aber die einzige Möglichkeit wirklich zu prüfen, ob das Ding angreifbar ist, indem wir es crashen. Wenn jetzt Broadcom sagen würde, die folgenden Chips sind angreifbar, was sie nicht getan haben, das wollen sie auch nicht, dann könnte man das wirklich sicher sagen, aber im Moment kann man tatsächlich nur das Ding zum Absturz bringen. Nun, Mikrofon Nummer 6, bitte. Wird es möglich sein, die Versendungsstärke zu erhöhen von den Bluetooth, so dass man das auch weiter wegmachen kann? Also die Sache ist, wir patchen die Firma auf den Chip und der Chip macht natürlich den ganzen Link-Layer. Allerdings die physische Funktionen-Stelle, die ist irgendwo anders auf dem Chip und die wird nicht von diesem Teil gesteuert. Wir suchen danach, vielleicht können wir die Einstellungen da ändern. Ich glaube, da kann man nicht so wahnsinnig viel dran drehen, aber in unterschiedlichen Weltgegenden gelten unterschiedliche Regeln für diese Leistung und wir haben es noch nicht gefunden. Nächste Frage von Mikrofon Nummer 4. Der Bluetooth Chip hat das Zugriff auf den Rahmen vom Host. Also es ist nicht so wie bei WLAN, wo man direkten Zugriff auf den Host-Speicher hat. Es sind tatsächlich zwei Prozessoren und über die Verbindung zwischen Host-Prozessor und dem Bluetooth-Modul läuft über eine serielle Verbindung zum Beispiel oder USB. Noch eine Frage von Mikrofon Nummer 3. Vielen Dank für den interessanten Talk. Habt ihr diese Verwundbarkeit dem BSI gemeldet, damit das BSI das sagen kann auf ihrer Website? Das heißt, damit dort stehen kann, dass man keine Bluetooth verwenden sollte? Das hört sich nach einer guten Option an. Wir haben Broadcom gefragt, wann wir das veröffentlichen können. Sie haben zumindest zugegeben oder zugestanden, dass es im Sommer veröffentlichen werden kann. Aber das BSI zu involvieren ist eine gute Idee. Gibt es noch eine weitere Frage aus dem Internet? Bitte Mikrofon für das Internet. Ob es irgendwelche Geräte gibt, die gepatcht worden sind, die vor 2017 rausgekommen sind? Ich glaube nicht. Broadcom hat zwei Monate gebraucht, um überhaupt zu bestätigen, dass es diese Angriffsmöglichkeit gibt. Ups, das gibt es ja wirklich. Und dann am 9. Dezember wollt ihr den Vortrag wirklich halten? Ich habe das neueste iOS Update auf dem iPhone 6 geladen und das ist definitiv noch angreifbar. Also ich denke, dass die ersten Patches so in ein, zwei Monaten rauskommen, aber wir wissen es nicht genau. Eine letzte schnelle Frage von Mikrofon1. Denkt ihr es ist möglich, wann zu erkennen, wann die Verwundbarkeit eingeführt worden ist, um zu schauen, wann die ersten Devices rausgekommen sind, die wir herausgekommen sind, die wir hacken können? Sollte es nicht alles rückwärtskompatibel sein seit 2012? Also könnte man das nicht irgendwie genauer bestimmen? Also das nächste 5 hat eine Firmware von 2012 und irgendwo, als es 2014 noch existierte, in jeder Firmware gibt es ein Bilddatum und das könnte man abrufen und abfragen, aber die Angriffsmöglichkeit gibt es seit vielen Jahren. Vielen Dank, großer Ausblaus für Dennis Jans und Jessica Klausen. Ihr habt gehört.