 Ok, dann legen wir mal los, hallo. Ich bin Timo Ramsauer und ich erzähle was über Blackbox Live Protocol Fussing. Erst mal ganz kurz was über mich. Ich mache gerade meinen IT Security Master zum einen an der TU Darmstadt, aber auch an der NTNU in Norwegen. Genau, dann möchte ich mich bei Lars Almon von der SEMU Group aus Darmstadt bedanken und bei Vasilayers von der NTNU und außerdem bei Daniel Meister, die mich bei den Projekten ein bisschen unterstützt haben. Wenn ich nicht gerade... Ah genau, meine Masterarbeit schreibe ich gerade. Die ist im industriellen IT-Sicherheitsbereich und da geht es darum, dass ich IT-Sicherheit versuche zu messen, ein paar Metriken zu rauszufinden, wie wir unseren Fortschritt darstellen können. Falls ihr darüber mit mir reden wollt, dann spreche ich mir gerne nach dem Talk nochmal an. Da soll es aber heute nicht drüber gehen. Auch nicht geht es über das, was ich sonst mache. Ich spiele nämlich sehr gerne Quidditch auch. Da würde ich euch alle einladen, das auch mal einfach auf YouTubern zu gucken oder auch in der Nähe von Hamburg ist bald die DM oder in Bamberg die auch die Europameisterschaft. Einfach mal vorbeischauen, das ist immer eine coole Sache. Ich will das Ganze an einem Fallbeispiel hochziehen und zwar am Protokoll MQTT. Das ist relativ verbreitetes Protokoll für IoT-Geräte. Das wird also mit Schodern, wenn man da einfach mal Internet sucht, dann findet man da ca. 65.000 Geräte, weil jetzt zu der letzten Stand. Das ist relativ light-wide und wird oft eingesetzt. Das Ganze setzt auf TCP auf, verbindungsorientiert. Und folgt dem Publish-Subscribe-Pattern. Das sieht so aus. Wir haben einen Publisher, ein Broker und ein Subscriber. Der Publisher und der Subscriber verbindet erstmal auf dem Broker. Das passiert natürlich auch auf TCP-Ebene auch, aber dann auch nochmal auf Applikationsebenen mit so einer Connect-Nachricht. Und dann kann der Subscriber auf Topics subscriben. Und was dann passiert, ist, dass ein oder mehrere Publisher auf diesem Publish-Topic was publishing kann. Und wenn dann da was gepublished wird, dann wird das ein Broker gesandt. Und dieser Broker sendet das dann alle Subscriber weiter. Das ist so das wesentliche Prinzip. Als Beispiel hätte man jetzt zum Beispiel Temperatursensor und irgendwie eine Klimaanlage und dann noch ein Smartphone, die alle irgendwie Endgeräte sind. Zusätzlich dann oben zu sehen der MQTB Broker. Und der Temperatursensor würde jetzt zum Beispiel hier im Raum immer wieder die Temperatur messen und wird hier einfach periodisch an den Broker schicken, also auf zum Beispiel das Topic Temperatur einfach publishing. Und das Smartphone und die Klima-Störung werden dann zum Beispiel als Subscriber angemeldet, haben vorher einfach dieses Subscriber-Paket geschickt und erhalten deswegen dann vom Broker einfach dieses Paket mehr oder weniger. Die Daten kriegen sie weitergeleitet. Ein Endgerät kann auch gleichzeitig Publisher und Subscriber sein auf verschiedenen Topics. Zum Beispiel können jetzt auch noch eine Solltemperatur zum Broker schicken und die wird dann auch an die Klimaanlage weitergeleiten. Wie sieht jetzt so ein Paket von MQTB überhaupt aus? Wir haben ganz viele verschiedene Felder. Als erstes kommt immer der MQTB-Header und dann gibt es noch das eigentliche Kontrollpaket. Damit erkannt werden kann, von welchem Typ das Kontrollpaket ist, kommt als erstes der MQTB-Kontrollpaket-Type. Das ist einfach 4 bits lang. Da steht dann zum Beispiel codiert drin, dass das ein Connect-Paket ist. Das habt ihr ja auch oben schon. Da ist ein Connect-Acknowledge oder ein Subscriber-Paket. Dann kommen mit 4 bits ein paar Flex und dann die Remain längst die codiert, wie lang das eigentliche Kontrollpaket ist und zum Beispiel dann zum Beispiel ein MQTB-Connect-Paket und auch da gibt es wieder ganz verschiedene Datentypen, die da einfach auftreten. In MQTB gibt es einen UTF-8 codierten String. Da ist es immer so, dass man erstmal 2 bytes hat, die angeben, wie lang der String ist und dann kommen die wirklichen UTF-8 bytes. Zum Beispiel wird immer der Protokoll-Name beim MQTB-Connect gesendet. Das ist immer der String MQTB und das ist dann als 04 MQTB codiert, weil MQT ist 4 lang und 04 beschreibt das Ganze. Genau, dann gibt es noch ein Protokoll-Level. Da ist jetzt gerade MQTB-Version 5 rausgekommen. Das heißt, da könnte dann zum Beispiel 5 drin stehen. Dann kommen noch verschiedene Flags, sind dann wieder ein oder 2 bytes bittlang. Dann kommt ein Keybelive, das ist eine Zahl, die in 2 bytes codiert ist und verschiedene Properties, die einfach auch andere unterschiedliche Codierungen immer wieder haben können, die unterschiedlichen Felder. Genau, und jetzt haben wir unsere Klimaanlage zu Hause und wir wollen die irgendwie testen. Da kann man natürlich ganz viel testen. Man kann das User-Interface irgendwie testen, ob einem das gefällt, aber halt auch auf Security-Tests machen. Da kann man natürlich rangehen und ganz, ganz viele Testsfälle schreiben. Das ist auch wichtig und das sollte auch gemacht werden. Aber was man halt auch machen kann, ist einfach Fuzzing und das ist ein Random-Testing-Methode und damit kann man erste Hinweise auf Sicherheits-Lügen zum Beispiel oft finden und kann ja weiter analysieren und dann letztendlich Schwachpunkte finden. Genau, wie funktioniert das? Als Erstes werden einfach zufällige Pakete generiert. Diese Pakete senden wir dann an einen Testziel und dann versuchen wir irgendwie, das zum Abstütze bringen, irgendwie eine Sicherheitslücke aufzudecken. So, zufällige Pakete generieren. Erste Idee wäre jetzt einfach, wenn man ganz stupide rangeht, entwickeln wir das mal. Könnte man erst mal sagen, das sind einfach zufällige Bits ans Netzwerk in der Phase. Das ist natürlich relativ offensichtlich schon. Funktioniert das erstmal nicht, weil das wird gar nicht angenommen. Das hängt schon, also das geht überhaupt, da wird überhaupt keine GCP-Verbindung aufgebaut. Das funktioniert nicht. Das heißt, wir sollten die unteren Schichten einfach valide halten. Es macht natürlich auch irgendwo Sinn, zum Beispiel den TCP-Stack zu testen, das kann man machen, ist hier jetzt aber Autoscop. Wir wollen letztendlich die Applikationsschicht testen und alles darunter sollten wir dadurch auch valide halten. Hier gibt es aber auch ein Problem, und zwar kommt es jetzt bei der Anwendung an, aber ganz einfache Checks, wie Protokollnahme und Version-Schlagen fehlen. Damit wir jetzt nochmal erinnern, so sah dieses MQTT Connect-Paket aus, und wir haben da als Erstes wirklich diesen Namen und das Level, das MQTT Connect-Paket ist auch mal das erste, was gesendet wird. Jetzt stellen wir uns so ein Broker vor, wie die Software da aufgebaut ist, dann kommt als Erstes im Prinzip ein bis zwei Ifs, die dann testen, okay, ist der Protokollnahme tatsächlich 0,4 MQTT und ist Version 5, ich nehme das Paket gar nicht an. Das heißt, diese 7 Bytes müssen exakt übereinstimmen, damit wir über die ersten 2 Ifs überhaupt hinauskommen. Das ist also eine Chance, wenn wir einfach Wendem-Sachen hinschicken, von 1 zu 2 mal 7 hoch 8, 2 hoch 7 mal 8, genau. Und wenn man das jetzt mal bei Dack-Dack-Go-ein-Tipp, dann kommt halt 0 raus. Das ist auch ziemlich nah dran. In Wirklichkeit ist es eher 1,4 mal 10 hoch minus 17. Das heißt, wenn ich jetzt Lotto spielen würde, würde ich gewinnen, super. Nächste Woche gehe ich wieder Lotto spielen, mache genau das Gleiche, ich gewinne wieder, ob ich nur ein Ticket gekauft habe und habe dann auch Geburtstag, dann ist das ungefähr die Wahrscheinlichkeit. Wenn wir da tatsächlich so viele Pakete generieren wollen, können wir mal durch diese 1,2 Ifs durchkommen. Das heißt, diese 1,2 Ifs werden dann sehr gut getestet, aber der Rest halt nicht. Und das ist irgendwie blöd. Das heißt, es macht irgendwie Sinn, tatsächlich die Struktur des Protokolls auseinanderzunehmen, ein bisschen, und dann immer nur einzelne Felder zum Beispiel zu fassen. Das ist eine Möglichkeit, die man aber wählen könnte. Genau, das klingt schon nach ein bisschen mehr Arbeit. Und gleichzeitig haben wir auch das Problem, dass wir immer noch keine Applikationslogik drin haben, weil wir müssen ja als erstes immer dieses Connect-Paket senden und gibt es noch ein bisschen weitere Logik und die müssen wir zuwürzlichen dann auch noch implementieren. Das wäre der nächste Schritt. Das ist dann schon richtig viel Arbeit und dann, ja, es wird komplizierter. Es gibt dann noch ein paar andere Ideen, die sehr smart sind, wo man dann die Bagger an die Software oder die Hardware dransetzt. Und das sind echt coole Sachen, weil man da systematisch immer wieder die CodeCoverage erhöhen kann. Man schickt einfach zufällige Werte erstmal rein aus einem gewissen Pool oder man hat erstmal 1, 200 valide Pakete, die man da rein schickt und die wandelt man einfach zufällig ein bisschen ab. Und dadurch, dass man zufällig immer wieder Änderungen macht, erreicht man andere Codezweige und kann dadurch dann, genau, systematisch immer die CodeCoverage erhöhen, wenn man dann andere Codezweige erreicht hat, dann fügt man das wieder zum originalen Pool hinzu und kann auch das abgeendet, das wir wieder abändern und irgendwann kann man dadurch eine riesige CodeCoverage erhöhen. Und das ist eine echt klasse Sache, aber da ist natürlich die Voraussetzung, dass man irgendwie die Bagger überhaupt anschließen kann. Und wenn man irgendwelche IoT-Geräte hat, dann ist das nicht trivial, dann muss man die dann schon zum Teil aufschrauben, blöden, kaputt machen, ist blöd, wenn man zu Hause einfach testen will. Oder, genau. Und deswegen habe ich mich davon auch getrennt und habe halt einen anderen Ansatz und das ist genau dieses Blackbox Live Protocol Fussing. Was ohne Aufschrauben funktioniert. Ich behandle das IoT-Gerät einfach als Blackbox. Und was ich mache ist, dass diese Klimaanlage, also der Temperatursensor, sendet sein Paket los, wie zum Beispiel jetzt. Das geht dann in der Mitte durch den Fasser, den ich da eingefügt habe, hindurch. Und da wird das Paket einfach verändert, dann wird das Paket zum Broker geschickt und auf dem Rückweg kann dann wieder das Gleiche passieren. Das heißt, der Broker schickt zurück. Ich ändere wieder im Netzwerk einfach die Daten ab und sie kommen dann letztendlich im Ziel an. Genau. Großer Vorteil, irgendwer anders hat die Arbeit gemacht. Das ist immer klasse. Irgendwer anders hat die Applikationslogik geschrieben, weil die letztendlich im gesamten IoT-System irgendwie drin ist. Wir haben auch das Gesamtsystem testen und nicht nur einzelne Komponenten im System. Und meine Hoffnung ist, dass sich dadurch auch Schwachstellen eher noch aufzeigen. Nachteile. Wir haben immer noch nicht das Problem gelöst, dass wir die Pakete irgendwie auseinandernehmen müssen, zum Beispiel um einzelne Felder zu fassen. Und unsere Komponenten generieren unter Umständen viel zu wenig Daten. Wenn wir einen Temperatursensor haben, der will irgendwie Energie sparen, der sendet dann einmal in eine Minute seine Temperatur raus. Und das Grundprinzip von fassen ist, dass wir super viele Tests machen. Das ist der große Vorteil. Wir müssen nicht jeden Test einzeln schreiben, sondern wir können einfach eine unglaubliche Menge an Tests generieren, weil das ist ja nur Zufall letztendlich. Und die dann an das Testshop schicken. Und wenn wir uns jetzt auf das System verlassen und nur einmal in einem Minuten Testfall haben, dann müssten wir ewig fassen. Und das funktioniert einfach nicht. Damit haben wir den Vorteil vom Fassen leider nicht mehr. Das heißt, dafür brauchen wir auch noch irgendeine Lösung, damit das Ganze funktioniert. Genau. Bisschen Implementierung, wie mache ich das, dass ich die auseinandernehme? Ich habe mich da einfach jetzt auf Scar Pie oder Skate Pie nennst du auch einige verlassen. Wer es nicht kennt, ich beschreibe es ganz gerne ein bisschen als Wire Shark für Python, wobei es eigentlich noch viel mehr kann. Aber es versteht von Haus aus schon sehr viele Protokolle. Das ist eine nette Sache. Und man kann auch relativ einfach neue Protokolle hinzufügen. Ich habe es tatsächlich für MQT Version 5, das ist ja die ganz neue, versucht. Es dauert dann doch länger, wenn es noch besser werden wird, und das Protokolle komplexer ist. Deswegen bin ich leider noch nicht fertig zugekommen. Aber es ist so ein Grundsatz an MQT, die ist zum Beispiel drin für Version 4 funktioniert es. Genau. Und zusätzlich kann man aber nicht nur desecten, also die einzelnen Felder von Paketen auseinandernehmen, sondern man kann auch neue Pakete zusammenstehlen und dann auch Checksums und Längenfelder neu berechnen, weil wir wollen immer, dass ein Paket halbwegs valide ist, aber nicht ganz valide zum Fassen. Das heißt, wenn wir unterschiedliche Sachen da reinpacken und dadurch dann die Längen nicht mehr stimmen oder die Checksums nicht mehr passen, und das ist jedes Mal der Fall, dann schlägt das immer an einem Checksums-Test, zum Beispiel, fehl. Und das wollen wir nicht. Das heißt, diese Felder müssen wir neu berechnen, damit wir ein halbwegs valides Paket haben. Genau. Das heißt, was ich jetzt mache, ist, dass ich erstmal Beispiel-Traffic habe, MQGT-Traffic zum Beispiel, den ich einfach aufnehmen kann, und daraus generiere ich Templates, die man jetzt hier vorne sieht. Und da es im Prinzip für jede Schicht, die existiert, ein Eintrag drin. Das erste ist jetzt oben zum Beispiel die Schicht MQGT Publish. Eine Protokollschicht ist das. Für MQGT ist es dann der Header und das wirkliche Paket-Typ. Man könnte dann auch die Applikation dahinter, also da gehen irgendwelche Daten drüber. Und das könnte auch noch eine eigene Ebene wieder haben. Man kann alles im Prinzip, wenn man will, über MQGT schleusen. Und auch das könnte man dann wieder als Layer einfügen. Da habe ich jedes Schicht im Prinzip zweimal drin. Einmal, wenn es zum Broker gesendet wird, und einmal, wenn es vom Broker kommt und zurückgeht. Und genau, da hat man dann für jedes Schicht, hat man da jedes Feld drin, und kann dann da einstellen, welche verschiedenen Fussing-Technik man darauf anwenden will. Ich habe da im Moment zwei Module drin implementiert. Das eine ist von Scapey selber. Das hat auch eine Fussing-Methode. Was die macht, ist, dass die einfach einen komplett zufälligen Wert da reinsetzt. Das ist gerade für Bitfelder, wo es nur 0 oder 1 gibt, oder auch für Bytefelder meist relativ sinnvoll. Da einfach was Zufälliges zu setzen. Für Strings können wir da aber noch etwas smarter werden. Und Fusser wie Radamsa nutzen. Das ist ein General Purpose Fusser, den ich da einfach im Hintergrund verwende. Und das ist eine ziemlich coole Sache, insbesondere weil es einfach super einfach ist. Wir haben Radamsa und packen da einfach einen String rein, unsere Datenbasis. Und er wirft einfach ganz viele zufällige andere Strings raus, wo irgendwelche Pattern verändert wurden. Das heißt, z.B. wird die Zahl negativ gemacht oder ganz lange, oder das String von das Easter-Hack wird angepasst. Da gibt es intern ganz viele Sachen, die ausprobiert werden, wo wir dann Glück haben können, dass es für unser Protokoll irgendwie ein Problem gibt. Das heißt auch, das kann man einführen. Man kann Radamsa generell auch mit einem Pool füttern, also nicht nur mit einem String, sondern mit einem großen Pool, dass man z.B. die vergangenen Werte, die man bisher so gesehen hat, die im Traffic drin waren, dass man die da einfach reinschläust. Generell ist es so gehalten, dass man noch verschiedene unterschiedliche Fussing-Techniken da jetzt reinbauen könnte. Im Moment habe ich nur diese implementiert. Aber das könnte man noch erweitern, wenn da Bedarf besteht. Jetzt wollen wir die Pakete an Ziel senden. Da müssen wir einfach einen Mann in den Sinn melden machen. Da gibt es natürlich verschiedene Varianten. Wir können Beta-Cab nehmen. Das ist ein Tool, was meine Linsenmittel mit ganz vielen verschiedenen Techniken auf Ethernet, Wi-Fi, Bluetooth und USB machen kann. Ich habe es selber mit Bluetooth und USB nicht getestet. Scar-by unterstützt es theoretisch auch. Und irgendwie müsste es mein Fass eigentlich auch können. Das wäre lustig ausprobieren, berichtet mir gerne. Das wäre auf jeden Fall interessant nochmal der Anwendungsfall. Müsste mal ein bisschen anpassen. Also sonst guckt einfach ins TCP-Proxy-Budel mit TCP-Tunnels. Ist aber jetzt nicht wirklich der Fokus. Weil letztendlich kann man auch eigentlich den Fasser einfach bei den enddevices als Broker einstellen. Beim Fasser stellt man den Broker an, die IP einfach. Und dann hat man einen Mandel-Middle. Muss man dann so ein bisschen auf dem Anwendungsfall abhängig machen, was man dann Gerät vor sich hat, wie man dann praktisch Mandel-Middle hinkriegt. Das müsst ihr dann gucken. Wenn tatsächlich TLS eingesetzt wird, was oft auch nicht wird, weil die einfach von Ressourcen beschränkt sind. Und weil es ja aufwand ist, dann muss man die TLS-Zertifikate austauschen. Das ist auch im Fasser so drin, dass wenn da eine TLS-Verbindung reinkommt, dass es auch gemacht werden kann. Das muss man dann einfach so konfigurieren. Da muss man dann natürlich die Zertifikate entsprechend einfach in den enddevices auch ersetzen. Und ja, das wird dann im Prinzip von Fasser, die TLS-Schicht wird einmal runtergestrippt und dann wieder draufgesetzt zum Broker hin. Genau. Das heißt, was jetzt passiert, ist, dass der Temperaturesansatz Beispiel jetzt mal erst mal eine TLS-Verbindung, eine TCP-Verbindung, einfach zum Fasser aufbaut. Gleichzeitig baut der Fasser dann eine equivalente TCP-Session zum Broker auf und verbindet die im Prinzip und schleust im Prinzip die Pakete erstmal einfach durch. Was wir jetzt aber zusätzlich noch machen können, ist, das Feature habe ich jetzt einfach multiplexer mal genannt, dass wir für jedes Paket, was vom Temperaturesansatz reinkommt, dass wir einfach zwei Pakete daraus machen, die unterschiedlich fassen und die dann zum Broker weiterleiten. Der Broker antwortet dann jeweils wieder auf die Pakete und das Ganze kommt, wird dann weitergeleitet an die Klimaanlage. Auf bestimmte Pakete wird auch geantwortet. Zum Beispiel auf das Connect gibt es dann das Connect Acknowledge. Das heißt, in dem Fall würde der Broker dann natürlich auch auf beide TCP-Sessions zum Fasser hin antworten. Was ich dann mache, ist, dass ich einfach nur für die erste TCP-Session die Pakete auch wieder tatsächlich weiterleite an den Temperaturesensor und das, was über die zweite Session kommt, einfach wegwerfe. Sodass das Ent-Device dann tatsächlich eine Connect Acknowledge bekommt und damit weiß okay, die Verbindung ist erfolgreich aufgebaut und ich kann jetzt zum Beispiel meine Publish-Pakete senden. Genau, und mit diesem Multiplexer behebe ich dann tatsächlich das Problem so ein bisschen, dass die Endgeräte viel zu wenig Daten senden, weil ich einfach dadurch noch den Traffic multipliziert kann. Genau, jetzt haben wir da irgendwie ganz viel Traffic und irgendwas passiert im Netzwerk und unsere Geräte machen irgendwas, aber wie sehe ich denn überhaupt? Wann bin ich denn erfolgreich? Wann habe ich einen Fehler im Endgerät gefunden? Das ist ja die große Frage. Und da müssen wir einfach Wege finden, diese zu identifizieren. Das Einfachste, was irgendwie immer geht, ist zu gucken, ob der Service noch am Leben ist. Das habe ich auch als separat das Modul ausgelagert, weil das muss man dann für den einzelnen Anwendungsfall richtig anpassen. Bei MQTT gibt es den MQTT-Ping, aber zumindest für die, ich habe das in Python alles geschrieben, für die Python-Bibways habe ich dann nicht in der richtige Implementierung gefunden. Deswegen habe ich das einfach als Hack gemacht, dass ich mich einfach auf ein Test-Topic-Subscribe fette habe und dann da immer drauf publishe. Das Test-Topic heißt Heartbeat und da sende ich dann einfach hin und es kommt zurück und wenn es zurück kommt, dann ist es nur am Leben und sonst halt nicht. Es ist im Prinzip ein Ping, aber es ist halt nicht das MQTT-Ping-Modul. Genau, was kommt dann daraus? Ich habe im Prinzip drei verschiedene Geräte. Das erste ist der Server, dann der Fuzzer und hier der Client. Ich kann als erstes einfach mal den Server starten. Das ist ein Mosquito, der verbreitet das Server. Rechts habe ich hier ein MQTT Explorer, damit wir einfach sehen, was passiert ein bisschen. Ich hoffe, dass man das ein bisschen sehen kann. Dann kann ich als erstes aus Beispiel-Graphik diese Templates generieren, die ich euch ja schon gezeigt hatte. Da kommt jetzt ganz viel Outboard, wird aber auch schön in der Teilgelicht. Genau, da können wir mal reingucken, wie die ausraut. Ich habe das auch schon gesehen. Das heißt, wir haben als erstes wieder dieses Two-Burker-Field. Das heißt, das wäre die MQTT-Layer, die zum Worker hingesendet wurde. Scape-E hat intern für den MQTT-Header einfach MQTT. Dann sehen wir alle unterschiedlichen Felder. Das wäre zum Beispiel das Felt-Type, also das ist der Control-Packet-Type. Und da haben wir dann im Beispiel-Traffic diese Values gesehen, einfach Werte von 0 bis 14. Dann wird da auch noch der Typ angezeigt, den das intern hat. Das ist in dem Fall ein Bit-Inam-Field, weil das waren ja diese 4-Bits und das ist ein Innovation-Intern. Darauf könnten wir zum Beispiel hier einen Fuzz einstellen. Das machen wir aber nicht hier, sondern was wir tun ist, dass wir das im MQTT Publish machen, und zwar bei dem Topics-Bring. Hier habt ihr auch schon gesehen, vorher sind da weniger zufällige Topics einfach gesichtet worden. Da könnten wir zum Beispiel den Radamser eintragen. Da ist einmal Abspeichern. Und dann können wir auch den Fuzz auch schon starten. Hier seht ihr jetzt auch schon, dass der Hard-Beat aufploppt. Das ist der immer wieder hingesendet wird zum Server. Das wird vom Fuzz gemacht. Dann starten wir auch noch einen Client, der einfach zu dem Fuzz-Packet hinsetzt, sendet. Rechts seht ihr die jetzt auch schnell aufploppt mit ganz vielen verschiedenen Topics. Da wird das Topic was ursprünglicher Test, weil wie ihr links seht, der hat einfach abgeändert. Da haben wir dann ganz viele unterschiedliche Sachen. Hier sieht man auch hier etwas verbosen Output. Hier ist zum Beispiel ein Leerstwinger einfach reingepackt worden. Oder hier was ganz Langes. Dann hat man hier irgendwie zufällige Bytes mittendrin. Da ist mein Programm abgestürzt. Das zeig ich, dass es erfolgreich ist. Wunderbar. Das liegt daran, dass ursprünglich war hier Test. Jetzt haben wir ein Dollarzeichen am Anfang und irgendwie zufällige Sachen dahinter. Das hat dazu geführt, dass auch der Broker abgestürzt ist. Da ist eine Assertion viel geschlagen. Dieser Mosquito Broker ist eben abgestürzt. Das Ganze liegt an der CVE 2018 12543. Das ist eine Schwachstelle im Mosquito Broker, die wir da gefunden haben und noch mal validiert haben. Das Problem ist einfach, dass wenn da irgendein String mit Dollar, dann kommt irgendwas, was nicht siss ist, was so eine Spezialvariable in Mosquito ist. Es ist ein Spezialtopic. Dann wird halt die Assertion getriggert und dann stürzt das Ganze ab. Das sollte natürlich nicht so sein. Das ist ein Dinal-of-Service-Attacke. Das ist schlecht. Jetzt ist das natürlich auf MQTT gemünzt. Damit können generell irgendwie alle MQTT-Systeme gefasst werden. Nicht unbedingt alle Versionen. Das Ganze habe ich aber so konstruiert, dass es auch darauf ausgelegt ist, dass es relativ einfach für andere Protokolle anwenden kann. Da ist eine gewisse Anpassung nötig. Zum einen müssen wir wissen, ob das live-Funktion funktioniert. Das muss man anpassen, weil wir dann andere Services haben und da müssen wir anders überprüfen, ob die noch leben. Wir werden ja jeweils die Felder neu berechnet. Zum Beispiel Längenfelder werden neu berechnet. Da muss man auch angeben, welche Felder neu berechnet werden sollen. Das sind allerdings einfache Anpassungen, die man da machen kann. Das Projekt ist auch auf GitHub. Das ist ein Moment in der Phase, wo ich es nutzen kann, aber sonst eigentlich niemand. Man hat schon gesehen, dass das Programm ist abgestürzt als erfolgreich ist. Das funktioniert für mich wunderbar. Es ist beendet und ich kann im Blog sehen, was passiert ist. Wenn ich das nutzen soll, muss ich das verbessern. Wenn ihr das nutzen wollt, sagt mir am besten Bescheid. Das guckt nicht nur auf GitHub. Es schreibt mir aber auch gerne eine E-Mail. Das hat auch ein paar Quarks. Zum Benutzen zum einen, aber zum Developen vor allem. Ich will da gerne noch ein paar Sachen ergänzen. Vielleicht habt ihr auch noch Ideen. Könnt ihr gerne auch in den Raum werfen? Ja, genau. Auch Fragen stellen, wenn ihr welche habt. Sonst wäre das schon erst mal so weit für mich. Hast du das mit anderen Protokollen auch probiert? Oder hast du einen Plan, das auch vielleicht auch andere Protokolle zu erweitern? Ich habe es im Moment tatsächlich nur für MQTT. Deswegen das Projekt heißt ja auch sogar MQTT Fuzzing. Das war für mich der erste Anwendungsfall. Ich habe versucht, die Architektur so zu halten. Ich würde da gerne noch andere Sachen probieren. Aber dafür brauche ich halt ein bisschen Zeit. Oder auch andere Menschen, die da Lust auf haben. Wenn es um andere Protokolle geht, wo man nicht die Fälle unbedingt kennt, sondern eine Benär-Protokolle, die aber dann ja doch häufig auch mit Check-Summen kommen. Wie würdest du diese Fälle identifizieren? Du bist ja erst mal blind und modifizierst nur bittweise, musst aber dann letztlich irgendwo das CRC-Feld rausfinden und rekonstruieren. Also man müsste das Protokoll letztendlich in Skypy implementieren. Man muss dann aber nicht das ganze Protokoll implementieren und sagen wir mal jedes einzelne Feld, das man ja eventuell nicht kennt, wenn irgendwas Pubertäres ist, da reinnehmen. Aber man müsste dann im Prinzip einen Warfeld anlegen einen großen Blob und dann das CRC-Feld noch dazu. Wie man letztendlich rausfindet, was davon das CRC-Feld ist, das ist dann euch überlassen. Aber da muss man halt irgendwie das Protokoll erst mal die kompilen, dass man zum Beispiel herausfindet, dass dann das CRC-Feld ist. Danke schön. Was ist, wenn das gefasste System nicht einfach sauber abstürzt, sondern ich sag jetzt mal intern irgendwie und Fasi-State kommt, gibt es da Ideen oder Ansätze, das zu detektieren? Genau, also im Moment ist die Überprüfung ja einfach, ob es noch antwortet. Fasi-State kann halt sehr viel sein, es könnte auch irgendwelche Security-Probleme geben, dass da auf andere Sachen abgestattet wird, dass dann vom letztendlichen Anwendungsfall tatsächlich abhängig. Was man dann für das einzelne Protokoll, für die einzelnen Systeme implementieren muss, dann muss man dann das Modul, das heißt Keep Alive bei mir, ich weiß gar nicht genau, vielleicht, das muss man einfach anpassen, man kann da auch, wenn man zum Beispiel SSH-Zugriff auf dem Broker hat, kann man dann auch noch mal die Broker-Logs damit reinziehen, wenn da irgendwelche Fehlermeldungen auftreten, dass man das macht, aber das ist dann tatsächlich von einem Einzelfall abhängig, was man da noch überprüfen kann. Man kann auch, das wird bei anderen Fasing-Techniken auch gemacht, dass man da guckt, ob irgendwelche falschen Zugriffe stattfinden, die nicht stattfinden dürften, da kann man noch einiges machen, da kann man dann auch generell in die Fasing-Paper noch mal reingucken, aber das konnte ich nicht so allgemein halten, dass es für alles funktioniert. Ich will da erst mal nur so dieses Framework bereitstellen und der Einzelfall muss dann, muss man dann draufsetzen. Gut, sonst noch was. Ja, genau. Also, wer tatsächlich mal einwärtsen will, meldet euch gerne bei mir. Ich versuche dann das noch aufzubessern, gebe euch auch Hilfe, wie ihr es benutzen könnt, tatsächlich. Es ist auch dokumentiert. Es gibt dann Paper zu, wo ihr auch reinschauen könnt. Das ist auch fast aktuell. Genau, also ein bisschen Doku ist da. Ansonsten, genau, spreche mich darauf an, spreche mich gerne auch auf IoT Security, Industrial IoT Security Security Metering an und ansonsten danke, dass ihr hier wart und noch einen schönen Abend euch.