 Es geht los mit dem Vortrag. Prey und MH haben einen nächsten Vortrag über das Lockpicking, also über das Schlosserknacken. Dieses Mal geht es um Bluetooth-Schlossern in Hotels. Großer Applaus für Prey und MH. Das ist nicht Hacka Japudi, aber vielen Dank. Ja, vielen Dank. Wer hat denn schon mal Lockpicking betrieben? Und wer hat das mit Bluetooth-Schlossern gemacht? Also dann seid ihr ja komplett richtig. Wir zeigen euch, wie man damit anfangen kann. Und es ist sehr interessant. Wer sind wir für die Leute, die uns nicht kennen? Prey ist ein Sicherheitsforscher, er ist Lockpicker, er ist interessiert an Technologie aller Ast, aller Art. Und offensichtlich hat er zu viele Nächte in Hotel verbracht. Ich bin Michael, ich bin ein Schlossnerd, Schlossernnerd. Ich sammle Schlosser. Und als ich noch jung war, waren die halt alle mechanisch. Wir haben die Sportsfreunde der Sperrtechnik gegründet. Wir sind übrigens auch hier vertreten, wir haben einen Village. Aber all neue Schlosser wurden dann halt elektronisch. Und ich wurde Elektronagenieur und hab eigentlich da das selber gemacht. Und das hat mich dann zu Bluetooth geführt. Wir haben diese Präsentation schon in Frühjahr gehalten, in Vegas. Aber wir waren ein bisschen ... Ja, heute mit Media CCC haben wir hoffentlich einen besseren Provider, welcher die Präsentation in die Weite Welt streamt kann. Und was geht's denn heute? Es geht um Smart Devices und smarte Geräte, die zum Beispiel mit Bluetooth Low Energy funktionieren. Und ich ... wir zeigen euch, wie man die hacken kann und wie man die auch baut mit einer Batterie. Und wie wir damit zu den Hotelsystemen gekommen sind. Also zu einer kurzen Einführung in Bluetooth Low Energy, wie funktioniert so was, wie kann man das analysieren. Und am Ende erzählen wir noch etwas wie genauer was wir mit dem Hersteller des Hotel-Schließsystems gemacht haben. Wie funktioniert so ein Bluetooth-Schloss? Man hat ein Schloss, das ist kommuniziert mit dem Smartphone über Bluetooth LA. Und natürlich ist das aber auch irgendwie mit einem Backend in der Cloud verbunden, im Internet, wo es mit HTTPS kommuniziert. Die möglichen Angriffspunkte wären zum Beispiel die Hardware, das Schloss selber, man hat Elektronik, man kann Firmen auslesen, man kann seinen Kanal antacken, machen Stromverbrauchsanalyse. Manchmal kann man auch den Flash lesen oder schreiben, sogar ohne das Schloss öffnen zu müssen. Oder die Mechanik attackieren, darauf hemmern oder einiges mit Magneten. Das Smartphone, damit seid ihr wahrscheinlich vertraut. Da gibt es verschiedene Attacke, Angriffe, die möglich sind. Und natürlich kann man auch im Internet die API, diesen Web-Service versuchen anzugreifen. Die API hat wahrscheinlich in welchen Schwächen verwundbar gehalten. Vielleicht hat sie gar keine Autentifizierung oder schwache Autentifizierung, kaputte Autentifizierung. Also hier geht es jetzt ein bisschen weniger um dieses Ende des Ecosystems, aber wir starten jetzt mal an mit den Verbindungen. Wir haben da Bluetooth Low Energy, wir haben das, die Verbindung zum Internet. Beide diese Verbindungen kann man natürlich abhören. Man kann man in der Mittel oder Maschine in der Mittel machen und man kann versuchen eine der beiden Seiten quasi vorzutäuschen. Und meistens ist dann das System irgendwo angreifbar. Ganz kurz zu Bluetooth Low Energy. Das wurde als billiger Alternative zum klassischen Bluetooth designed. Es ist ein Teil von Bluetooth 4.0. Es gibt schon eine Weile. Und Leute, die die klassischen Bluetooth kennen, es ist ziemlich anders. Was kann man damit machen? Meistens sind es sogenannte IoT-Devices. Meistens haben die aber keine eigene IP-Adresse, sondern z.B. so was wie smarte Lampen, Schlösser, Sexspielzeuge usw. Wie steht es um die Sicherheit von Bluetooth LE? Eines der ersten Papers, das ich darüber gesehen habe, hieß, mit wenig Energie kommt auch wenig Sicherheit. Und es ist eigentlich so wahr, ja. Es gibt solche, die die Elipid Curve benutzen, aber das ist nicht der Regelfall. Also die Applikation muss schliessendlich die Sicherheit gewährleisten. Wie kann man denn jetzt von Unbarkeiten suchen? Wir suchen jetzt das Bealei genauer an. Zuerst muss man selber ein Gerät haben, die App installieren, selber analysieren, wie das mit dem Schloss kommuniziert. In Android gibt es da eine einfache Option. Man kann den Debug Maud einschalten und das HCI Snooplock einschalten. Das schreibt dann ein Pickup-File mit den Bluetooth-Daten auf euer FI-System. Es gibt ja das Endliches. Für IOS muss man ein Debug-Zertifikat beantragen von Apple. Das ist dann ein paar Tage gültig. Dann kann man die ab einfach starten, wie man das normalerweise tun würde. Und dann lockt es das im Hintergrund. Und ich würde euch empfehlen, schreibt euch auch immer grad dazu, um welche Zeit ihr was gemacht habt. Danach viel einfacher, um mit dem Lockfile etwas zu korrelieren. Und am Schluss holt ihr halt das Lockfile vom Telefon, ladet das herunter und öffnet das in Wireshark. Wireshark können wahrscheinlich die meisten. Und ja, man hat einen Sendern-Twanger, man hat diesen Bluetooth-Protokoll Stack und der interessante Teil ist dann, welche Daten auf welches Bluetooth-Handel gesendet werden. Das ist, was man mit dem eigenen Gerät machen kann, aber wenn man ein anderes System angreifen will oder das angreifbar wäre, dann muss man Bluetooth-LE einfach mithören aus der Luft. Das ist relativ einfach, weil es nur drei Funkkanäle gibt, auf denen das funkt. Und es gibt günstige Geräte ab 25 Dollar, welche Sniffen können. Die meisten davon unterstützen eine Wireshark-Live-Ansicht. Das heißt, man kriegt dann kurz eine Live-Daten-Strom in den Wireshark. Der Nachteil, man hat nur einen Advertising-Kanal. Und wenn ihr keine Standard-Hopping-Squence habt, dann verpasst ihr wahrscheinlich den Anfang. Also es geht im Prinzip, aber wenn ihr was zuverlässiges möchtet, dann gibt es Beetle-Check von Daniel Kockl. Es ist quasi eine Formel für günstige Bluetooth-Alle USB-Geräte, die ihr auf der Folie seht. Das unterstützt drei Geräte, wenn man alles auf verschiedene Kanale einstellt, dann könnt ihr ziemlich zuverlässig die verschiedenen Verbindungen mithören. Diese Tools können dann auch Moor als Sniffing, sie können auch eine Verbindung hi-checken. Und wenn man das mal aufsetzt, ich habe das ein bisschen auf einem Norddoxer-Art aufgemacht. Das ist ein bisschen ein anderes Setup. Wenn man das jetzt zum Beispiel Batterie betrieben macht, könnte man das in ein Rauchmelde oder einiges einbauen und einfach mal ein paar Stunden mithören lassen. Es gibt auch ein neues Tool, das heißt Mirage. Der Entwickler hat die anderen Tools quasi genommen und versucht daraus etwas Besseres zu machen. Es kann so was wie man in der Mitte. Es ist sehr umfangreich, aber es ist auch sehr komplex. Zum Starten würden wir euch das Beetle-Check empfehlen. Und wenn ihr nicht weiter kommt, dann könnt ihr Mirage nehmen. Jetzt wissen wir, wie wir das mit dem Bluetooth-Alle machen können. Aber jetzt schauen wir uns mal den Backend-Link an. Normalerweise ist es TLS-verschlüsselt. Es gibt nur noch wenige Apps, die nur HTTPS. Aber wenn man das selber einfach ein bisschen umleiten kann, dann kann man das HTTPS-Traffic ansehen. Bei anderen Apps kann man bloß bei sich selber ein CR-Zertifikat installieren können. Und ich würde euch vorstellen, macht das mal mit ein paar Apps, das ist sehr interessant. Das ist relativ einfach auf iOS. Man installiert es und sagt, dass es vertrauenswürdig ist. Auf Android ging das auch ganz einfach. Aber mit 7 Apps, weil Apps nicht mehr den Certificate-Store vom Internet nutzen. Man muss es dann entweder beruhten oder man kann die App modifizieren, sodass die System-Sertifikat auf einem nicht geruhteten Telefon. Normalerweise funktioniert das. Aber es gibt ein paar Apps, die das versuchen zu verhindern mit Keypinning. Und Mike erzählt euch was dazu über. Hier hatten wir ein Konferenz-Hotel in Vegas. Und das hier ist passiert. Die App sagt ihr freundlicherweise sogar, was falsch ist. Nämlich, dass das Certificate-Pinning fehlgeschlagen ist. Die App sagt, wir können dem Gerät nicht vertrauen. Wir müssen das Certificate selber checken. Normalerweise ist es das Ende der Analyse. Man kann das auf verschiedene Weisen angehen. Normalerweise gibt es mehr als einer App. Und probier einfach mal die andere. Und häufig tut es eine der beiden Apps nicht. Oder bei Android kann man häufig auch eine alte Version der App bekommen, die das vielleicht nicht tut. Aber falls das nicht funktioniert, kann man die App modifizieren und neu signieren. Dann schauen wir uns später noch an, was man da modifizieren kann. Dazu benutzen wir einen Tool namens Frida. Das ist für Mobile-Anwendungsentwickler ein bisschen macht einem Angst, weil man kann da ziemlich viel ändern. Es gibt da gute Tutorials im Internet, was man in Frida machen kann. Wenn man eine geroutete Android-Device hat, dann muss man hier so ein Server laufen lassen. Dann benutzt man Objection. Zum Beispiel hier die Master Lock BLE App. Und dann sagt man Android SSL Pinning Disable. Und dann passiert das. Wenn nicht, wenn Objection nicht funktioniert, dann muss man die App analysieren und schaut sich das JavaScript-Pfeil an. Und da sieht man, wie die Checkmethode überladen wird von der HTP Framework. Und dann returned es einfach. Und so haben wir das einfach returned. Und dann sehen wir den nicht verschösseten Traffic. Und jetzt nochmal eine Nachricht an die Hersteller. Ja, TLS Pinning ist hilfreich, falls der User einen falschen CA installiert hat. Aber letzten Endes für die Leute, die das analysieren, macht das keinen großen Unterschied. Sobald das funktioniert, gibt es hier verschiedene Tools. Zum Beispiel die Mitm Proxy-Tool auf Unix, Chars Proxy für Mac, Verb und so weiter. Hier ist zum Beispiel ein Mitm Proxy Beispiel. Hier sieht man ein bisschen den Fluss der Nachrichten. Wenn man ein bisschen genauer reinschaut, dann sieht man die dekodierten Nachrichten. Und hier seht ihr auch ein Beispiel, wo wir noch später mal zu kommen. Ein kleiner Hinweis für euch. Genau das, sobald ihr das System das erst mal startet, weil man sonst ein paar Events verpasst. Zum Beispiel irgendwas mit Software-Updates oder Firmware-Updates. Es ist auch gut, ein altes Android-Gerät zu haben, geroutet. Nur dafür. Jetzt, wo wir wissen, wie wir die Daten bekommen, schauen wir uns an, wie wir sie analysieren. Zum Beispiel haben wir hier ein Beispiel mitgebracht, so ein kleines Schloss. Es ist mechanisch nicht sicher, aber man kann wahrscheinlich einfach reinbeißen und es geht kaputt. Man kriegt es von Alibaba oder Amazon und so ein kleines Puzzle. Interessanterweise hat diese Firma noch andere Schlösser. Sie machen zum Beispiel die Bike-Sharing-Systeme hier auf dem Camp. Es gibt also genau dieses Schloss auch als Fahrradschloss oder anderen Schlössern. Es ist einfach integriert, zum Beispiel in diese E-Roller. Es ist so ein bisschen interessant, hier in dieses System reinzuschauen. Aber denkt dran, die Firma hat dies inzwischen verbessert. Als die unverschüsselten Daten mitgeschnitten worden sind, können wir einfach das Passort sehen. Wenn man genau hinschaut, sieht man hier vom Backend-Server zur App. Auch 16 Bytes sehen namens Lock-Key. Also Schlüssel-Schloss, Schlüssel-Schlüssel. Und das könnte jetzt ein IS-128-Schlüssel sein, was ein Verschützungsergriff aus der vielen Systeme genutzt wird. Und jetzt sehen wir hier einen Traffic zwischen dem Gret und dem Schloss. Am Anfang sah das zufällig aus, aber als wir das einfach mal probiert haben, die IS-128 Electronica Book-Decryption benutzt haben, dann sieht das nicht mehr so zufällig aus. Also das ist jetzt nicht mehr verschlüsselt. Also haben wir den richtigen Weg gefunden, um das zu entschlüsseln. Was machen wir jetzt? Wie finden wir jetzt mehr darüber aus? Um das jetzt zu analysieren, schauen wir uns das Lock an und was passiert, wenn wir das Schloss mehrmals öffnen oder schließen. Und dann schauen wir uns die Bytes an, die sich ändern. Dann finden wir ein bisschen raus, was für Muster es da gibt. Hier gibt es eine Sitzungsnummer, manchmal erst die 4-byte, manchmal 3-byte. Das ist immer die gleiche. Dann ist das hier einfach ein Beispiel, wo man das Protokoll daran erkennen kann, indem man ihm einfach lange genug zuschaut. Hier sieht man Replay Protection, also eine zufällige Zahl, die von dem Schloss generiert wird, die jede Sitzung geändert wird. Aber die ändert sich jede Sitzung, aber innerhalb der Sitzung ändert sich nicht. Das heißt, wenn man innerhalb der gleichen Sitzung wieder drin ist, dann kann man einfach die Pakete wieder replen. Nachdem man das jetzt analysiert hat, was macht man jetzt? Man könnte jetzt Software schreiben, welche die Applikationen nachahmt. Da gibt es BluePie und da kann man dann die Applikationen modifizieren und schauen, was passiert, wenn wir es ein bisschen anders machen. Macht das Schloss das immer noch mit oder lehnt das die Versuche dann ab? Da haben wir jetzt keine offensichtlichen Schwachstellen gefunden, außer dass, falls man den geheimen Schlüssel schert, das es dann ein Problem gibt. Natürlich möchte man auch das gesamte System anschauen. Wenn man das jetzt zum Beispiel ins Scooter einbaut, dann ist der Schlüssel auch verschieden für alle verschiedenen Scooter oder gibt es an einem Schlüssel andere Schlösser? Ja, das war ein Protokoll, das nicht so schwierig war, zum Verstehen. Aber was ist denn, wenn das Protokoll absolut keinen Sinn ergibt? Der nächste Schritt könnte sein, die Applikationen zu reverse-engineeren. Das ist je nachdem in einigen Ländern illegal, also prüft das zuerst. Man kann, wenn man etwas dekompiliert, dann kriegt man halt den Quasi-in-Qualtext und für Android ist das halt Java und manchmal häufig Java, aber es gibt auch nativen Code und es gibt dann Code, mit welchen man das wieder erneut kompellieren kann. Viele können vielleicht Ideas, für iOS ist das anders, ähnlich, aber man muss zuerst die Applikation in einem entschlüsselten Form kriegen. Wenn ihr das habt, dann sucht man quasi für Anker, also für Android, für Bluetooth. Also wenn ihr was seht, das Bluetooth-Gate oder Set so heißt, dann sind das die Orte, wo das geschrieben und gelesen wird. Dann könnt ihr suchen nach iOS, Key oder ähnlichem. Dann seht ihr vielleicht etwas, was so aussieht. Eins, zwei, drei, vier, fünf. Das könnt ihr, ja, vielleicht solltet ihr das genauer anschauen. Etwas, was oft passiert, ist, dass die App verschleiert ist und dann sieht sie aus wie C001 und das ist dann halt schwierig zum Lesen, aber man mit den passenden Tools macht es halt alles wieder ein bisschen einfacher. Wenn man z.B. das sieht, da ist ein Array, da ist Null, dann ist vielleicht, ja, kann man das, ja, man muss halt den richtigen Anker finden und dann findet man so heraus, was was ist. Und unsere Meinung zu Verschleierung, es macht zwar alles schwieriger für Leute, wie welche, welche halt Responsible Disclosure machen, aber kriminelle hindert das eigentlich nicht am Reverse-Engineering. Also macht das nicht, macht ein richtiges Sicherheitsprotokoll, dann müsst ihr das auch nicht verschleiern und verstecken. So, was haben die denn jetzt gefunden? Ich fasse nochmal kurz zusammen, was schon publiziert wurde. Ein Beispiel, das ihr jetzt selber ausprobieren, ist so ein billiges Vorangeschloss von dieser Firma. Da wird der Passcode quasi im Gradtext übermittelt. Wir gehen mal davon aus, dass der Hersteller weiß, dass er keine Verschlüsselung nutzt, so haben wir nicht informiert. Wenn man jetzt ein Key mitliest aus der Luft, dann kann man den einfach erneut replayen und kann quasi essen jeden Schloss. Ja, alle Schlösser öffnen. Es gab eine Präsentation an der DEF CON vor ein paar Jahren von Robert Ramney und sie haben 16 Schlösser getestet und 12 hatten Unparkheiten in diesem Stil. Man konnte z.B. eben Replayattacken führen und so weiter. Und 14 davon waren Vorangeschlösser und nur zwei davon haben, ging nicht kaputt. Das erste war von der Firma Masterlock, damit haben wir ein bisschen rumgespielt. Wir haben eine einliche Attacke auf einem anderen Schloss gehabt, aber jetzt haben wir so ein antiques Tool genutzt, das heißt Magnet. Vielleicht habt ihr schon mal davon gehört und wir versuchen mit den Motor, einfach die Priorität des Motors zu andern und so den Motor zu rotieren, ohne dass es wirklich angeschaltet ist. Und das 80 Dollar teure Vorangeschloss geht auf. Das war ganz einfach, aber nicht so Bluetooth-Lockpicking. Das zweite, das ist... Also dieses Schloss sucht einfach Lockpicking in IoT und dann findet ihr die alte Präsentation, wenn es euch interessiert. Die Nokia waren die ersten Bluetooth Vorangeschlösser, die es gab. Also was ich jetzt zeige, gilt für die alte Version. Inzwischen ist das gefixt. Das neue haben wir uns das nicht genauer angeschaut. Dieses Nokia hat RS-128 benutzt und das hat auch verschiedene Schlüssel benutzt für eure Freunde. Aber die Zeitrestriktion war nur in der App gelöst. Das ist die erste große Schwachstelle. Und das zweite ist, die haben individuelle Sessionkeys für jedes Session benutzt. Aber diese Sessionkeys wurden auf eine unsichere Art generiert. Das war halt Security by Obscurity und mit einem Disassembler haben wir dann herausgefunden, wie dieses Protokoll funktioniert. Das ist ziemlich einfach. Es sendet eine Nonze und ein 12345 Schlüssel und das wird dann in die Mitte von diesem Pre-Share Key hinein gepackt und damit wurde dann der neue Session Key generiert, um das Schloss zu öffnen. Wenn man das herausgefunden hat, dann war es ziemlich einfach, die Verschlüsselung zu knacken. Jetzt kommt zum interessanten Teil die Hotelschlüssel. Vorher hatten wir eher Vorhangeschlüssel oder einfache Sachen und jetzt machen wir das mal so im Reanleben. Warum machen wir das? Also warum machen Hotels das? Es ist ganz einfach, man kann Self-Check-In machen, man spart Personal und man muss halt nicht mehr an der Rezeption vorbei. Das sind weniger Lötte, die man braucht. Es ist vielleicht praktisch für, wenn es lange Erwartungslangen hat, dass man halt direkt ins Zimmer gehen kann. Was sind denn die Herausforderungen? Das ist nicht euer Schloss, also ihr könnt euch nicht offiziell damit verbinden. Diese Hotels, also die Schlösser sind wahrscheinlich alt und wurde wahrscheinlich etwas retrofitting gemacht. Wahrscheinlich haben die nicht die modernsten Crypto-Chips. Und das ist ein ziemlich komplexes Ecosystem mit Buchungsplattformen vom Hotel selber und so weiter, dass man irgendwie managen muss. So wie funktioniert das? Normalerweise bucht ihr ein Hotelzimmer und die Buchung ist dann irgendwie auf einem Recount registriert und wir haben halt herausgefunden, dass z.B. Booking-Nummern als aufsteigende Nummern generiert wurden unter meinen Namen und so konnte man das relativ einfach nachbauen. Ja, das ist normalerweise, wir haben dann relativ einfach ein Proxy genommen und das Logo zu ersetzen und hier haben wir jetzt den normalen News-Kreis gezeigt und wir haben das in zwei Hotels probiert, nennen wir News-Hotel H, da haben wir Systeme gefunden, die wir nicht knacken konnten. Wir haben die analysiert und gesehen, dass es richtige Crypto nutzt. Aus unserer Perspektive sieht das so aus, dass der Hersteller einen geheimen Schlüssel hat, welchen der Benutzer nie sehen wird und dann gibt es unseren Schlüssel und eine verschlüsselte Version, die erinnert mir K-Stern. Jetzt sendet die ab zum schlossenden K-Stern und das Schloss nutzt nun K-As, um K-Stern ins K zu entschlüsseln. Jetzt ist der K bekannt und so kann man verschlüsselt kommunizieren. Wir haben keine direkten Attacke, wir haben eine Attackemöglichkeit gefunden und wir mussten jetzt weiter machen mit firmware dumps und das will man nicht unbedingt im Hotel probieren. Wir haben nicht weiter experimentiert, weil aussehn einem Grund, dass das System nach unserem ersten Tag nicht mehr funktioniert hat. Wir wissen nicht, um woran es lag. Wir haben ein anderes Hotel probiert. Das ist eher so ein S4-Stern-Hotel und man kann die Abkurse überall benutzen, wo man den Normalschlüssel auch benutzen könnte. Also wenn ich meine Buchung zu meiner App verbinde, dann finde ich sowas, das heißt Mobile Key, es ist ein Array von vielen Bites. Ich habe die meisten zensiert, im BLA-Verkehr sieht man dann alle diese Bites auch unverschlüsselt in der Luft. Ja, das sieht nicht so gut aus, ist das eine Replayer Attacke und dann habe ich das genau angeschaut und nein, das ist ein Teil des Handshakes und nach so einer 4-Bite-Signatur wird einfach der gesamte Key übertragen. Das sieht nicht so gut aus. Zuerst müssen wir schauen, was die anderen Bites machen. Genau, dann haben wir das gleiche Ding noch einmal gemacht. Wir haben uns wieder mehrere Sitzungen angeschaut, haben alles aufgezeichnet. Dann haben wir am Ende etwas gefunden, was sich ändert. 32 Bites, Bits. Wir dachten, das könnte eine Nose sein und das andere eine CRC. Bei den ersten drei Nachrichten hatten wir recht. Es gibt Tools, die solche CRCs reversen. Wir haben jetzt einfach ein Python-Script benutzt, um viele CRCs auszuprobieren. Da gibt es einen XOR-Wert, der sich ändern kann. Richtungen können sich ändern und so weiter. Das haben wir eigentlich nur gebrut. Ja, das haben wir einfach versucht. Und dann haben wir es gefunden. Mit dem richtigen Polynom gefunden. Dann haben wir den Seat auch gefunden. Da war er konstant im gleichen Hotel. Das war der WC konstant im gleichen Hotel. Das heißt, wir wussten, wie wir die ersten drei Nachrichten bauen können. Da brauchen wir als Seat immer die letzte CRC. Aber in der Mitte haben wir zwei Bites gefunden, die ein bisschen komplizierter waren. Da gab es immer sechs Bites, die 0 waren und dann zwei Bites, die sich immer geändert haben. Dann haben wir ein bisschen damit rumgespielt. Da waren ein paar Werte, mit denen wir rumspielen konnten. Und dann sah es in etwa so wie das hier aus. Dann war es immer die Wert von den vorherigen Berechnungen. Und das hat dann den CRC-Wert der realen Anwendung übertragen. Wir wussten dann, wie wir das selber bauen können. Das war ein großer Durchbruch für das Projekt. Wir haben wieder ein Python-Script geschrieben mit BluePie, was die CRC's gehandhabt hat und so weiter. Natürlich brauchen wir wieder ein Schlüssel. Also seht ihr hier unsere Abherrattacke. Wir haben das innerhalb des Zimmers gemacht, um die Zimmernachbarn zu fördern. Aber da seht ihr jetzt die eigentliche Übertragung. Da sieht man auf dem Laptop-Screen die Schlüsseldaten. Dann haben wir das in unser Python-Script getan. Und dann habe ich das gesagt, machen wir das doch mal. Dann bin ich mal in den Hacker Outfit gegangen und geschaut. Dann nutzen wir mal die Snifte-Daten. Dann sind wir einfach in den Raum reingegangen. Das hat funktioniert. Wir sind dann einfach in den 37. Stockwerk eines Luxushotels gekommen. Das ist so viel zum Thema chinesische Vorhänge-Schlösser. Dann haben wir jetzt ein paar andere Sachen gemacht. MK hat ein Script geschrieben und wir wollten herausfinden, wie groß ist dieses Problem? Wir haben in einem Hotel geschaut und da haben wir gesehen, dass die BLE-Namen relativ einfach nachzuprüfen sind. Es war einfach Base64 encodiert. Es gibt in anderen Hotels auch einfache Variationen von diesem Protokoll. Das hat uns gesagt, das ist ein größeres Problem. Das heißt, der Herrsteller dieser Schlösser ist eine deutsche Firma. Und die haben vielleicht so 2000 Deployments in Hotels. Und dieses System ist aber nicht überall. Und das liegt daran, dass sie es noch gerade erst ausrollen und in den 5-Stern-Hotels ist es auch noch nicht drin, weil da wollen sie anscheinend so etwas nicht haben. Das ist ganz interessant, weil das kann man in realen Angriffen benutzen. Also wo kann man das benutzen? Naja, das Problem ist, man braucht vielleicht, man muss tatsächlich neben dem Schloss sein, um das zu sniffen. In Fitnesscenter könnte man vielleicht in einem Mülleimer tun. Dort kann man dann den Sniffer rein tun. Da hat es aber irgendwie nicht funktioniert. Aber es gibt noch etwas Besseres, nämlich den Lift. In Lift kann man ganz einfach drin sein mit einem Rucksack und jeder nutzt dort seine Schlüssel. Und wenn man den Simulator-Skript benutzt, dann versucht einfach jeder sich mit deinem Laptop zu verbinden, weil es so aussieht wie der Aufzug. Und dann können wir natürlich den Schlüsseldampen für schöne Benutzung. So, das war natürlich sehr schön. Wie geben wir das jetzt dem Hersteller weiter? Wir haben uns bei einem Hersteller gemeldet und wir kriegen eine Antwort. Wir haben technische Details den gesenden. Die erste Reaktion war, das sieht interessant aus, aber es kann ja nicht funktionieren. Und dann haben wir eine ziemlich spezifische Mail geschrieben, haben gesagt, glaubt mir, wir haben da solche Kinder einen richtigen Hotel probiert. Und dann ging das dann alles ziemlich schnell. Sie werden sich nicht, sie haben gut mitgearbeitet. Aber wie ist denn das jetzt mit dem Update? Das Schwierige daran ist, dass man so ein gesamtes Hotel, ein ganzes Ökosystem updaten muss. Und das geht dann halt nicht einfach so remote. In einigen Hotels muss man von Tür zu Tür laufen und das mit einem zum Beispiel Infrared Gerät oder eigentlichem Update. Und je nachdem muss man dann halt auf die Android-Apps und die iOS-Apps noch updaten. Und ja, je nachdem muss es auf alte neue Schlösser kompatibel sein. Und wir wollten das so lange man noch normale Keycards nutzen kann. Es ist noch relativ neu und wir dachten, es ist in Ordnung, dass wir noch ein bisschen Warte bitte verschlüssen mit der Veröffentlichung. Es gibt ein anderes Problem. Also der App-Hersteller ist halt ein anderer Hersteller als der Schlosshersteller oder in den Hotels und die haben jetzt halt leider erst vor zwei Wochen davon erfahren. Das war ein bisschen dumm gelaufen. Und ja, scheinbar soll das ca. jetzt starten in der August. Wir haben ein Update-Prozess. Wir haben noch nichts Konkretes gehört, aber wir denken, dass es gut kommt, gut wird. Was solltet ihr jetzt mitnehmen aus dieser Präsentation? Das ist nicht einfach, um mitzuhören. Mit einfachen Tools. Und wenn ihr das mal... Also geht das nicht an euch, sondern eher an die Hersteller. Macht sichere Protokolle, versuch nicht in welche Obhiaskeitschen und ähnliches, weil man wird es trotzdem rauskriegen. Das ist eine komische Annahmen. Und was wir gelernt haben, BLE wird nicht nur ein Spielzeug genutzt, sondern es geht jetzt in die richtige Welt, eben in Hotels und ist nicht mehr nur in die Uhr oder in der Kühlschrank. Und wenn ihr... Wenn es euch mehr interessiert, findet ihr unsere Slides online. Und an vielen Orten, wo ihr blaue Text gesehen habt, das sind Links mit mehr Informationen. Und wir haben jetzt noch 2,7 Minuten Zeit für Fragen. Wir haben Zeit für ein paar Fragen. Also hebt eure Hände, respektive. Ne, läuft zum Mikrofon. Und übrigens, wenn ihr Feedback zur Übersetzung habt, dann könnt ihr das in der Twitter abgeben unter dem Hashtag C3T. Wir sind mit dem Handel alt C3Lingo erreichbar. So, es kommt nun die erste Frage. Kommt vielleicht doch keine Frage. Ich bin Michael, meine Frage. Es geht um andere Transporte. Zum Beispiel NFC, RFID. Wird das in Hotels benutzt in diesen Schlossern? RFID ist der Standardweg, das zu tun. Es gab... Das haben wir jetzt nicht direkt gesehen, aber es gab Bluetooth. Aber das System gesehen, wo wir das Handy direkt an das Schloss halten müssen, um die Tür zu öffnen. Aber ja, das haben wir uns jetzt nicht weiter angeschaut. Das ist häufig in uns Smartphones. Das heißt, das ist jetzt die Technologie, die alle benutzen. Früher haben sie Magnetstreifen, Technologie benutzt, aber auch RFID. Do we have another question? Yes, up there. Go ahead. Gibt es Bluetooth-Schlösser, welche zuerst einen Pairing machen? Das haben wir nicht gesehen, sondern das wäre ziemlich unkomfortabel, weil man so viel Zeit damit verbringen müsste. Weil alle Schlosssysteme häufig irgendwelche unverschüsselten Linklayer benutzen und alles andere benutzen sie auf dem Application-Layer. Das einzige Hochsicherheitsgerät, was ich diese Art gefunden habe, war so ein Gepäck-Tag einfach. Danke für die Antwort. Gibt es mehr Fragen? Das ist wahrscheinlich nicht der Fall. Fragen aus dem Internet. Gibt es Fragen aus dem IoT. Vielen Dank und viel Spaß beim Hacken solcher Dinge.