# IoT Security Failures and Network Segmentation

**Podcast:** Engineering Kiosk
**Published:** 2026-03-03

## Transcript

Willkommen zu einer neuen Episode vom Engineering Kiosk Podcast.
Heute zoomen wir mal in einen Bereich rein, der gleichzeitig kreativ, unbequem und leider oft erst dann sichtbar wird, wenn es schon knallt.
IT-Security.
Wir schauen uns dafür drei Storys an, die irgendwie wie so ein schlechter Film klingen, aber ziemlich reale Learnings liefern.
Ein Casino.
bei dem ein IoT-Thermometer aus einem Aquarium plötzlich als Datenabflusskanal dient, inklusive 10 GB Traffic nach Finnland, ein Jeep Cherokee Hack, bei dem ein offener Port und eine unsignierte Firmware reichen, um vom Infotainment bis zum Kanbus zu kommen und ein aktueller Case rund um den Schlauberger-Roboter, MQTT und fehlende Autorisierung, bei dem plötzlich nicht nur ein Gerät, sondern tausende Geräte im Spiel sind.
Der rote Faden, Trust Boundaries, Netzwerksegmentierung, Zero Trust, Egress Traffic und die unbequeme Wahrheit, dass IoT Teil deines Systems ist, ob du es willst oder nicht.
Wenn du dich schon einmal gefragt hast, warum Segmentierung immer nach hinten geschoben wird, dann ist diese Episode für dich.
Wir legen los.
Viel Spaß.
Du bist leider nicht mehr der Jüngste, aber du kennst ja wahrscheinlich noch aus der Historie.
folgende Situation, du bist auf einer Party, auf einer gemütlichen Wohnungsparty oder so, wo findet die beste Party statt?
Natürlich stehst du mit jemandem in einem Kaltgetränk, einer Hopfenschorle in der Küche, weil in der Küche passieren immer die besten Partys und dann lernst du irgendwen Neues kennen.
Du triffst irgendwen, den du noch nie vorher getroffen hast, kommst ins Gespräch und dann kommt diese klassische Frage, ja und was machst du so?
Also mit dem Hintergrund, was machst du so beruflich?
Und die Person sagt, ja ich bin in der IT.
Wie viel Informationsgehalt hat diese Information für dich?
Genug Informationsgehalt, um weiterzufragen.
Was denn genau oder wo denn genau?
Du bist eher so der Optimist.
Ich bin eher so der Pessimist, weil diese Antwort, die sagt mir ungefähr gar nichts.
Das ist ungefähr so, als würdest du mir sagen, du hast ein Dach über dem Kopf.
Ich weiß aber nicht, hast du eine Wohnung, hast du ein Haus?
Besitzt du die Wohnung oder...
Bist du nur Mieter?
In welcher Stadt?
Wo bist du in einer WG?
Hast du vielleicht nirgendwo ein Zimmer?
Bist du vielleicht in irgendeiner Obdachlosenunterkunft?
Also es gibt so eine breite Varianz dieser möglichen Antwort.
Und in der IT ist das ja nicht anders.
Kannst du mir sagen, wie viele Jobs oder Bereiche es in der IT gibt?
Natürlich, da kann man bei ACM nachschauen.
Da gibt es ein Verzeichnis.
Gibt es Kategorien?
Wie ist die Informatik aufgeteilt?
Ich glaube, das sind so 22 Hauptkategorien.
Dann kannst du das nachschauen, natürlich.
Und pro Hauptkategorie gibt es dann sehr wahrscheinlich 37 Unterkategorien und davon dann, also dieser Baum wird sehr groß, würde ich mal sagen.
Und ich glaube, das Thema Security oder Sicherheit ist nicht nur ein Subbaum in deiner ACM-Kategorisierung, sondern Security ist ja schon wild und hochspezialisiert, wie eigentlich fast jeder Subbereich.
Da gibt es Red Teaming, Blue Teaming, Security Analysten, da gibt es Whitehead Hacker und...
Was habe ich noch vergessen?
Was fällt dir als Jobs im IT-Security-Bereich ein?
TISO, Chef ganz oben.
Okay, du bist jetzt eher so der Management-Kollege, verstehe ich.
Naja, wie dem auch sei.
Wir dachten uns in dieser Episode einfach mal, im Security-Bereich passiert so viel.
Und im Security-Bereich ist auch die Kreativität meines Erachtens nach unglaublich hoch.
Nicht nur von den Angreifern, sondern auch von den Beschützern.
Und es gibt natürlich ein paar weltweit bekannte Attacken, die es sogar bis in die Tagesschau geschafft haben.
Um mal drei zu nennen, das wäre Stuxnet.
Das ist dieser Hack damals in iranischen Anlagen, um Zentrifugen, glaube ich, langsamer zu schalten, um das iranische Atomprogramm zu stören oder ähnliches.
Dann gab es einmal Log4Shell in dieser Java Logging Library.
Und dann gab es einmal Heartbleed, wo, glaube ich, Speicher...
von anderen Prozessen geleakt wurde.
Das sind so die Riesendinger, würde ich mal sagen, die es bis in die, zumindest deutsche Tagesschau geschafft haben.
Wahrscheinlich auch in die österreichische Tagesschau.
Die heißt Zip2.
Zip2, okay.
Warum nicht einen einfachen Namen wählen?
Zeit im Bild.
Ist viel kürzer als Tagesschau.
Und wo ist Zeit im Bild 1?
Gibt es auch.
Das ist um 19.30 Uhr und Zip2 ist dann für die coolen Leute um 10 Uhr mit Interview und so.
Die mehr Zeit haben.
Ja, die keine Zeit haben, die dann um 10.
nochmal wirklich die News haben wollen.
Bisschen anders aufgestellt.
Wieder was gelernt, aber wir haben uns gedacht, wir lenken den Scheinwerfer mal auf weniger bekannte Hacks, weniger bekannte Attacken und lesen jetzt nicht nur einen Blogpost vor, sondern fragen uns wirklich aktiv, was können wir eigentlich daraus lernen?
Und wir versuchen mal ein bisschen, ich sag mal, ein bisschen tiefer als die ganz klassische Berichterstattung oder als das Offensichtliche zu gucken.
Bist du ready, Wolfgang, für den ersten Hack?
Hast du gerade geglaubt, irgendwas ist kaputt?
Ja, siehst du, so geht es mir auch oft.
Und dann brauche ich unbedingt einen Kaffee.
Oder wie der Andi sagen würde, einen Kaffee.
Und für diese Koffeinenergie, die ihr uns durch diese Kaffeespenden bereitstellt und die es uns eigentlich erst ermöglichen, diese Episoden zu produzieren, möchten wir uns einmal bedanken.
Und zwar bei den letzten Spendern.
Daniel, Jakob, Peter, Alfred, Florian, Michel.
Dimo, David, Lukas, Adrian, Nico, Matthias, Wolfgang, by the way, schöner Name, Elias, Björn, Franco, Dominik, Paul und Fabian.
Und egal, ob ihr uns einen Kaffee sponsert oder vielleicht sogar ein Kaffee-Abo wie der Fabian oder einen ganzen Monatsbedarf an Kaffee wie der David, wir schätzen jeden einzelnen Kaffee und freuen uns wirklich über dieses ganze Koffein-Feedback.
Vielen Dank von Andi und von mir und jetzt geht es auch schon wieder zurück zur Episode.
Ich bin natürlich absolut ready und vielleicht als kleine Hintergrundgeschichte, woher dieser Hack eigentlich kommt.
Der Andi hat den irgendwo so als Sidenote in dem Vortrag auf der diesjährigen Fosterm mitbekommen.
Also er wurde nicht genau erklärt, sondern nur so angerissen.
Aber Andi ist schon so nervös am Stuhl herumgerückt, wie er nur gehört hat, was das für ein toller Hack ist und dass der so cool ist.
Und darum ist das jetzt auch der erste Hack, den wir besprechen, weil der Andi würde sonst es gar nicht mehr aushalten.
Darum darf der Andi jetzt starten mit seinem...
Ersten Hack, der übrigens wirklich cool ist.
Ich kannte den Hack schon, aber er wurde mir auf der diesjährigen Foss wieder in Erinnerung gerufen.
Hast du ein Aquarium, Wolfgang?
Jetzt wollte ich gerade sagen, scharri aus, als würde ich Fische züchten, aber ich will jetzt niemanden beleidigen.
Nein.
Wahrscheinlich hast du ja irgendwo ein paar Silberfische im Bad oder ähnliches, aber nun gut, lassen wir das.
Es geht um ein Aquarium.
Es geht um ein Thermometer in einem Aquarium.
Die ganze Sache...
wurde im Sommer 2017 von den Medien aufgegriffen.
Und zwar hat damals eine sogenannte IT-Sicherheitsfirma mit dem Namen Darktrace ein Global Threat Report veröffentlicht.
Ihr kennt das, diese PDFs, wo man Customer Case Studies und so weiter und so fort announced.
Und eine Customer Case Study, die ging um ein amerikanisches Casino.
Ein amerikanisches Casino, wo die Software von der Firma Darktrace auffällige Aktivitäten im Netzwerk entdeckt hat.
Leider wurde das...
Casino nie genannt und leider wurden auch nie forensische Details zu dem ganzen Fall veröffentlicht.
Dennoch haben die Medien die ganze Sache aufgegriffen und natürlich weiter recherchiert.
Das bedeutet dann leider auch, der kommende Fall kann nicht sauber rekonstruiert anhand von einer Incident-Timeline behandelt werden.
Aber wir haben das Beste getan, um investigativen Journalismus zu betreiben.
Ja, jetzt bin ich gespannt.
Wie dem auch sei.
Also, was ist passiert?
Ein Casino in den USA hatte ein Aquarium.
Und heutzutage hat man natürlich nicht nur ein Aquarium, sondern man hat auch einen Thermometer in einem Aquarium, denn die Temperatur für Fische ist sehr wichtig.
Und natürlich könnte man jetzt einen Mitarbeiter anstellen, der rumgeht.
Haben wir 25 Grad in diesem Aquarium Wasser?
Oder man kann natürlich einen IoT-Sensor installieren.
Im Endeffekt gab es einen IoT-Sensor in diesem Aquarium, der hatte die Temperatur, die Fütterung, die Reinigung und Umweltwerte und so weiter überwacht.
Und diese Daten wurden dann an einen Computer gesendet.
Die Software von Darktrace hat dann über Zeit auffällige Datenabflüsse im Netzwerk beobachtet.
Und zwar wurden ungefähr 10 Gigabyte nach außen transferiert.
Kein anderes Gerät in diesem Casino, in der Serverlandschaft von dem Casino, hatte jemals Kontakt zu der externen Adresse, wo die 10 Gigabyte hingesendet wurden.
Kein anderes Gerät innerhalb des Casinos hat je diese Menge Daten außerhalb des Netzwerks transferiert.
Wenn man sich die Daten genauer angeguckt hat, wurden Protokolle genutzt, die eher fürs Videostreaming geeignet sind.
Und die Software hat all das erkannt.
Klingt irgendwie nach logischen Patterns, würde ich mal sagen.
Und Kudos für die Software.
Und dann hat man sich diesen ganzen Vorfall einmal genauer angesehen.
Und zwar wurde dieses Aquarium-Thermometer dafür genutzt, um ca.
10 GB Daten aus dem internen Netzwerk des Cosinos rauszuschleusen.
Wer das genau war, weiß man bis heute nicht.
Der Zielserver, wohin die 10 GB Daten gingen, stand irgendwo in Finnland.
Das heißt natürlich nicht automatisch, dass der Täter aus Finnland kommt.
Und die 10 GB, die kamen alle von diesem Thermometer oder irgendwo von Devices im Netzwerk?
Genau, die Software von Darktrace hat festgestellt, dass das Thermometer der Ausgangspunkt, also der Endpunkt im internen Netzwerk war und 10 GB Daten dann nach Finnland versendet hat.
Und was waren das für Daten?
Die Medien beschreiben, dass die Angreifer die High Roller Datenbank anvisiert haben.
High Roller im Casino, ich weiß ja nicht, wie viel Glücksspiel du machst, aber es gibt ja wahrscheinlich immer...
Das musst du mir jetzt erklären.
Es gibt halt immer so einen Raum in so einem Casino, okay, da sind halt die zahlungskräftigen Kunden aktiv und da wird eine Datenbank drüber geführt, wo man halt, ich sag mal, nicht nur um 1000 Dollar spielt, sondern vielleicht mal ein bisschen höher, ja, beim Poker und Blackjack und so weiter.
Das sind dann die Whales sozusagen, wie bei den Spielen, oder?
Da, wo man viel Geld rausbekommt.
Ganz genau.
Und natürlich hat ein Casino Interesse, diese High Roller irgendwie schön zu betütteln.
Und deswegen führen die natürlich eine Datenbank von diesen High Rollern, weil natürlich irgendwann auch Geldwäsche da ins Spiel kommt.
Woher kommt das Geld?
Pipapo.
Und mit hoher Wahrscheinlichkeit laufen die dann nicht wie in irgendwelchen Hollywood-Action-Filmen mit einem Koffer voll Geld und 10 Millionen zum Chip-Counter, sondern das wird dann mit hoher Wahrscheinlichkeit über Banktransfer gemacht.
Deswegen führen die so eine Datenbank.
Aber das müssen ja schon andere Infos auch gewesen sein, weil diese Datenbank hat, keine Ahnung, 200 Kilobyte wahrscheinlich, wenn es um Namen geht.
Das waren ja 10 Gigabyte, also da muss schon irgendwie mehr dran hängen.
Naja, also da wir es nicht genau wissen, was übertragen wurde und wir wissen auch nicht, wie die Highroller-Datenbank geführt wurde, welche Metadaten es ist, wenn da jede Transaktion mitgeliefert wurde, wenn da Daten in anderen Datenpaketen verpackt wurden.
Ich hatte gerade gesagt, dass die Software hat ein Protokoll, was normalerweise für Videostreaming genutzt wurde, dann bedeutet das, da werden Daten in Daten gepackt und das kann natürlich einen gewissen Overhead erzeugen.
Und 10 Gigabyte Outbound Transfer kann natürlich auch sein, okay, du musst erstmal das Netzwerk erkunden, Port Scans und so weiter, diese Informationen musst du zurück zum Angreifer.
Also das kann natürlich sein, dass die 10 Gigabyte nicht die 10 Gigabyte Größe der Datenbank ist, aber wie gesagt, das wurde nie explizit offengelegt.
Und politisch korrekt würde man sagen, ein ungewöhnlicher Outbound-Transfer von circa 10 GB über das Thermometer im Aquarium.
Okay, jetzt wissen wir, dass da 10 GB übertragen wurden über ein Streaming-Protokoll.
Das heißt, es muss aber nicht heißen, dass es wirklich dann irgendwie Videodaten waren, sondern es wurde nur irgendein Streaming-Protokoll an sich verwendet, oder?
Es können auch irgendwelche Live-Daten von einer Shell oder so gewesen sein, theoretisch.
Ja, natürlich.
Also im Endeffekt musst du dir die Frage stellen, welche Videodaten würdest du von einem...
Aquarium-Thermometer erwarten.
Ja gut, sowieso.
Aber auch dann, was innen drin ist, in so einem Streaming-Protokoll, kann ja dann auch nochmal alles sein.
Also du kannst ja die Datenbank genauso über das Streaming-Protokoll übertragen.
Genau, die High-Roller-Datenbank, das wurde von den Medien beschrieben, wurde aber nie explizit bestätigt.
Also es könnte theoretisch alles drin sein.
Es wurde nur die Größe des Transfers von circa 10 GB.
Okay, aber ich muss ja jetzt irgendwie von außen überhaupt mal da reinkommen zu diesem Fisch-Thermometer.
Genau, und da kommt nochmal so ein kleiner Disclaimer.
Die Medien haben das Ganze natürlich so aufgegriffen wie, okay, IoT ist böse, IoT kann alles ruinieren und Internet of Things ist auch unsicher.
Die reale Quellenlage ist alles ein bisschen mager, denn es gibt keine verifizierten technischen Details, dass man irgendwie über das Fischthermometer in die Datenbank vom Casino gekommen ist.
Also es steht nirgendwo explizit.
Das Fischthermometer hatte eine Sicherheitslücke, das Fischthermometer war offen im Internet, das Fischthermometer wurde gehackt und von da aus hat man weitergesprungen.
Das steht nirgends, aber das haben die Medien so aufgegriffen und wenn man jetzt, so wie es leider viele im Internet tun, einfach nur die Headline lesen, dann kann man da glaube ich auch sehr einfach drauf schließen, denn diese Fälle sind ja jetzt nicht weit hergeholt, dass irgendein IoT-Sensor offen im Internet steht, oder?
Ja, wie viele IoT-Sensoren hast du übrigens in deinem Netzwerk?
Und so Temperatursensoren?
Braucht da ja kein Aquarium wahrscheinlich, oder?
Ich bin kein Fischbesitzer, aber natürlich, ich habe ein paar IoT-Sensoren, stehen aber nicht offen im Internet.
Ja, das sagst du jetzt so leicht.
Ja, natürlich.
Also ich kann ja nur das sagen, was ich jetzt aktuell weiß.
Aber die Story, die halt oft verbreitet wird, ist, du hast einen Fisch, du hast einen Aquarium-Thermometer.
Ein Aquarium-Thermometer wurde gehackt.
Vom Aquariumthermometer ist man ins interne Netzwerk gesprungen, dann hat man ein sogenanntes Lateral Movement gemacht.
Das bedeutet, man bewegt sich seitwärts im Netzwerk und exploriert so ein bisschen das Netzwerk, hat dann die Datenbank gefunden und hat diese Daten dann nach außen geschleust.
Aber Achtung, der Initial Access, wie man eigentlich ins interne Netzwerk gekommen ist, ist nicht eindeutig belegt.
Deswegen geht man aktuell davon aus, dass der Angreifer irgendwie Zugriff auf das Corporate Network bereits hatte.
Und das entweder durch gestohlene Credentials, also Zugangsdaten, oder halt durch irgendwelche Brutforce-Attacken.
Und das verschiebt die Story natürlich komplett von IoT war das Einfallstor hin zu IoT war mindestens ein erfolgreicher Exit-Egress-Kanal und eventuell auch der, ich sag mal, Pivot-Punkt.
So nach dem Motto, dass man Zugriff aufs interne Netzwerk hat, zuerst das Thermometer gefunden hat und von diesem Thermometer weiter gehobt ist oder dieses Thermometer halt als Ausgangstür genutzt hat.
Und das ist natürlich eine ganz andere Perspektive auf diesen Sicherheitsvorfall.
Denn es wird nirgendwo genannt, dass dieses Thermometer ein Sicherheitsloch, also eine CVE hatte oder dass irgendwo ein Exploit genutzt wurde.
Was man aber, und das kommt jetzt noch dazu, aus dieser Case Study gesehen hat, ist, dass die Netzwerkanbindung beziehungsweise dass es einen Segmentierungsversuch des Aquariums bereits gab.
Also dieses Thermometer hatte eine VPN-Konfiguration.
Das ist geil, das erste Thermometer, den Sie kennen, der eine VPN-Konfiguration hat.
Es muss ja nicht das Thermometer selbst gehabt haben, es kann ja auch die Netzwerksegmentierung gehabt haben, die dann der VPN, den Jump-Host hatte.
Aber das bedeutet, es gab einen Segmentierungsversuch.
Und dieser Angreifer hat es irgendwie geschafft, die VPN-Konfiguration zu bekommen, um dann weiterzuspringen.
Und das ändert jetzt natürlich alles.
Das bedeutet, du, Wolfgang, der für die Überwachung des Aquariums zuständig ist, hast vielleicht auf eine Phishing-Mail geklickt.
Pun intended, oder?
Phishing-Mail?
Ach nee.
Ja, gut.
Also, wenn man sich die ganze Sache jetzt von der Perspektive anguckt und nicht sagt, ah, IoT ist...
sondern okay, Credentials wurden irgendwie geleakt, dann hat man irgendwie Zugriff darauf bekommen und dann ist man da weitergehopst.
Dann muss man natürlich schon gucken, was hat das betroffene Unternehmen eigentlich vorher getan, um sich zu schützen.
Und da kann man sagen, leider, es gibt keinen kompletten Post-Mortem, aber es wurde ein Versuch umgenommen, das Aquarium mit einer VPN-Konfiguration zu isolieren.
Das bedeutet, oder man kann darauf schließen, dass das Risiko grob gesehen wurde.
Und es gab eine Art Überwachung auf das Netzwerkverhalten.
Denn die Parameter, die ich gerade initial genannt hatte, kein anderes Gerät des Casinos hat mit dem Server in Finnland gesprochen, kein anderes Gerät hat diese Menge an Daten nach außen transferiert, plus warum kommuniziert ein Fischthermometer mit Videostream-Daten?
Also es gab schon Sicherheitsmechanismen und da muss man zugeben, irgendwie wurde das Risiko ja grob gesehen.
Aber auch nur grob.
Also bei mir gehen da ja schon ganz viele Red Flag.
Lichter an, wenn ich das so höre.
Jetzt, was können wir denn davon lernen?
Was würdest du empfehlen?
Kann man sowas verhindern?
Also klar, wir wissen nicht, wo die Person hereingekommen ist überhaupt, aber wenn wir das mal auf die Seite schieben, was können wir verhindern oder was können wir davon lernen?
Ja, da bin ich mal gespannt, ob ich deine roten Flaggen jetzt auch treffe.
Generell würde ich sagen, und ich betrachte den ganzen Fall jetzt aus, dieser Angreifer oder die Angreiferin hatte Zugangsdaten und nicht IoT ist insecure und hat den Exploit.
Oder hatte ein Sicherheitsloch und mit anderen Explore-Folos auf.
Generell ist das das beispielhafteste Szenario einer Exfiltration-Failure-Mode.
Einer was?
Hast du wieder mal in GPD irgendwie den englischen Begriff ins Deutsch probiert zu übersetzen?
Oder was ist das?
Nee, ich habe nämlich was zur Exfiltration-Taktik in einer Sicherheitsdatenbank gelesen, was Taktiken und Techniken von Angreifern beschreibt.
Das heißt wirklich so.
Exfiltration.
Denn...
Ein IoT-Gerät wurde genutzt als Initial Access.
Von da hat man sich dann seitwärts bewegt und dann hat man wieder über das Thermometer Daten rausgeschleust.
Das ist ja schon so relativ smart.
Aber was können wir jetzt daraus lernen?
Und jetzt kommt die Wahrheit, die viele Leute ignorieren.
IoT ist Teil eures Systems.
Was meine ich damit?
Die meisten Leute bestellen sich auf Temu irgendeinen Fenstersensor, binden den einfach ein und machen dann mit der nächsten Sache weiter.
Und da frage ich mich, warum?
Denn dieses Beispiel zeigt relativ gut, der Kernfehler ist nicht, dein Thermometer ist hackbar oder hat eine Sicherheitslücke, sondern ein nicht-kritisches Gerät, wie zum Beispiel ein Aquarium-Thermometer, hatte direkt oder indirekt einen Pfad zu kritischen Datenbanken oder Assets nennen wir es mal, beziehungsweise wurde als vertrauenswürdiger Transportkanal angesehen.
Denn sonst hätte man ja eine Netzwerksisolation, eine Netzwerktrennung gemacht.
Sonst hätte man ja gesagt, okay, das VPN von dem Thermometer, warum braucht das jetzt eine Route zu irgendwelchen Datenbanken oder zu irgendwelchen Fileservern oder eben?
Und das wird mit hoher Wahrscheinlichkeit bei dir zu Hause nicht anders aussehen, oder Wolfgang?
Ja, ich habe schon automatisch eine physikalische Trennung, weil ich Zigbee verwende.
bei meinen ganzen IoT-Sensoren und das dadurch auf einer anderen Netzwerkebene funktioniert, das hilft mir schon ein bisschen.
Das finde ich auch sehr sympathisch.
Aber klar, ich habe keine Regeln auf meinem Router, der irgendwelche Segmentierungen durchführt oder so von irgendwelchen Devices.
Ist mir ehrlich gesagt zu mühsam, mache ich auch absichtlich nicht so.
Aber es ist halt immer die Frage, wo hört das mühsam auf?
Wie groß bin ich als Firma, als kleine Firma, Casino?
Wo fängt man an mit der Sicherheit?
Das ist natürlich schon ein großes Thema.
Aber ich würde mal sagen, bei der Größe von dem Casino, wo es auch um sicherheitskritische Daten geht, soll es natürlich schon eine Segmentierung geben.
Aber ich kenne das selber, auch in Firmen, wie oft ist das, man hat irgendwie ein Device, fragt, hey, habt ihr WLAN, habt ihr eh intern WLAN oder können wir einfach reinhängen?
Und dann hängt es da mal drinnen.
Das macht vielleicht sogar irgendwie eine Untergruppe ohne der IT direkt und so weiter.
Also das passiert natürlich ständig, solche Dinge.
Und das ist genau der Punkt, denn es gibt halt keine sauberen, ich sag mal Trust Boundaries nennt man das.
Also Stichwort Zero Trust Network, kurzum, wer darf eigentlich mit wem kommunizieren?
Gibt es eine explizite Authentifizierung und Autorisierung?
Jetzt denkt ihr, wie jetzt, muss ich meinen Aquarium-Thermometer authentifizieren?
Ja, bitte, irgendwo, wenn das Daten irgendwo hinschreibt oder Daten transferiert.
Gibt es eine Art Validierung aller eigenen gehenden Daten?
hätte man hier auch machen können.
Eingehende oder ausgehende Daten.
Warum verlassen von einer Source-IP, die einen Thermometer darstellt, Videostream-Daten mein Netzwerk?
Fragwürdig.
Warum verlassen überhaupt Videostream-Daten mein Netzwerk?
Wir sollten nämlich intern bleiben, hoffentlich.
Netzwerksektentierung, Least Privilege, Monitoring und Logging aller Grenzen, aller Netzwerk-Boundaries.
Und das kann man alles natürlich mit VLANs und Port-Limitierungen und Co.
erschweren.
Eine vollständige Sicherheit gibt es auch hier nicht.
desto länger ein Angreifer im Netzwerk bleibt, umso eher findet er natürlich auch einen Weg.
Auch das, was du gerade gesagt hast, würde ich gerne challengen, weil wenn der Kollege nämlich bei dir im Netzwerk ist und bei dir im Home Assistant auch immer da ist, wird er mit hoher Wahrscheinlichkeit auch einen Weg finden, seine Befehle in Zigbee-Pakete zu packen, zu deinen Geräten zu senden, zum Beispiel zu deinem Heizungs- Steuerungsgerät, was vielleicht auch Zigbee fährt, weiß ich gerade nicht, um dir dann, ich sag mal, eine wahre Bude zu bescheren oder halt eine kalte.
Von daher, das würde ich mal sagen, ist eine Thematik, die so offensichtlich ist, dass sie von sehr vielen Leuten ignoriert wird.
Dass IoT Teil eures Systems ist und genauso wie ihr Laptops von irgendwelchen Consultants hoffentlich nicht ins komplette Firmennetzwerk lasst, sondern denen vielleicht ein eigenes Netzwerk gebt oder ähnliches.
müsste man das eigentlich mit IoT-Geräten genauso machen.
Ja, du lebst da auch in deiner Traumwelt.
Also in wie vielen größeren Firmen ich schon war, wo ich einfach voll Zugriff bekommen habe, relativ easy eigentlich auf alles.
Gut, ich bin eine vertrauenswürdige Person natürlich mit meinem Laptop, aber das ist natürlich schon ein Grundproblem.
Ich kenne natürlich auch die andere Variante, die ist dann sehr nervig.
Also ich kenne eine so eine Umgebung zum Beispiel, auf deren Servern Docker-Container haben automatisch nichts, wohin sie schreiben können oder wohin sie...
Pakete schicken können.
Die sind einfach automatisch totgeschalten und du musst dann wirklich jeden einzelnen Port, jede einzelne Internetadresse auf eine Allowlist setzen lassen.
Das heißt, wenn du dann irgendwelche Updates brauchst in deinem Container, genau IPs oder Domains über irgendeinen zentralen Proxy wieder freischalten lassen.
Also es ist dann natürlich sehr, sehr aufwendig und auf einer Seite, auf der Seite, der die Container vielleicht wartet oder updaten muss, natürlich sehr nervig.
Muss man auch dazu sagen.
Aber man sieht dann schon, es gibt da definitiv große Unterschiede, wenn es um Security geht.
Und die arme IT-Abteilung und Security-Abteilung, die sind halt dann die, die das immer alle abbekommen.
Und dann heißt es halt immer, die wollen uns blocken.
Und das ist halt der übliche Kampf in den Firmen.
Also ich verstehe natürlich beide Seiten irgendwo.
Aber mittlerweile bin ich eigentlich auch auf dem Pfad, einfach grundsätzlich mal nichts zu erlauben.
Least Privilege.
oder Zero Trust und alles andere muss dann wirklich auf eine Allowlist gesetzt werden.
Und warum so ein Fischthermometer grundsätzlich überhaupt mal Internetzugang haben kann, also auch nach außen versenden, ist sowieso die Frage.
Also vielleicht ist das über VPN gegangen, aber grundsätzlich, warum so ein Thermometer nach draußen telefonieren darf, ist ja auch schon mal eine grundlegende Frage, ob das wirklich Sinn macht.
Ja, ich verstehe, wenn man Deny All als Default setzt.
dass das auch für Softwareentwickler und Softwareentwicklerinnen anstrengend ist, weil du kannst nicht mal eben deployen, einen neuen Service, muss der Port freigeschaltet werden, die Route freigeschaltet werden und so weiter und so fort.
Auf der anderen Seite, und jetzt kommen wir zu dem Positiven in der ganzen Sache, du als Entwickler und Entwicklerin musst dir dadurch dann bewusst werden, was deine Applikation denn eigentlich tut.
Auf welchen Ports kommunizieren wir?
Ich bin mir nicht sicher, wie viele Leute wirklich wissen, auf welchen Ports die...
GRPC-Kommunikation läuft oder, oder, oder.
Welche Ports meine Applikation eigentlich braucht.
Oder einen ganz klassischen Fall, den ich eigentlich bei kaum einem Open-Source-Projekt sehe.
Dein Open-Source-Projekt braucht jetzt eine MySQL-Datenbank.
Okay, ich würde mal sagen, Standardanforderung.
Jetzt hast du eine MySQL-Datenbank irgendwo, du richtest für diese Applikation einen User ein.
Welche Rechte gibst du dem User denn?
Also welche Art von Queries macht denn diese Applikation?
musst diese Applikation die Alter-Permissions haben, um Tabellen umzuschreiben.
Wäre ja toll, wenn man die wegnehmen könnte, oder?
Und so weiter und so fort.
Und dass man zum Beispiel die Auflistung der Permissions, der Datenbank-Permissions, die ein Open-Source-Projekt braucht, habe ich fast nirgendwo gesehen bisher.
Ich hatte so ein ähnliches Problem, und das ist gar nicht im Open-Source-Bereich, aber genau wie ich zuerst gesagt habe, ein Container darf grundsätzlich...
Nicht nach Hause telefonieren, irgendwo im Internet was abrufen.
Also du setzt es auf eine Allowlist.
Jetzt hatte ich einen Online-Service genutzt, so einen Index-Such-Service und das SDK von denen.
Und es hat mich Stunden gekostet, um herauszufinden, welche Domains dort wirklich verwendet werden.
Weil das SDK natürlich alles weggekapselt hat und das war auch nicht irgendwo im Source-Code.
Ich hätte sogar nachschauen können, es war BHB.
Aber der macht natürlich irgendwelche Abfragen, bekommt dann irgendwelche Infos, an welcher Server er überhaupt senden muss.
Das ist halb dynamisch und natürlich Load Balancing und so weiter.
Also am Ende rauszufinden, was du da wirklich auf eine Allowlist setzen musst, ist wirklich schwierig gewesen.
Und auch in der Dokumentation, obwohl es eine sehr große Firma war, die den Online-Dienst angeboten hat, keine Infos dazu gefunden.
Also hat mir wirklich viel, viel Zeit gekostet.
Insofern, wenn man sowas anbietet, dass man dann auch sagt, okay, diese Sachen müsst ihr auf eurer Firewall freischalten, vor allem im Business-Kontext.
Also das ist eine Enterprise-Ready-Software oder Service, die dort verwendet wird.
Und trotzdem habe ich nichts gefunden in der Knowledge-Base.
Also da brauchst du gar nicht zu Open Source gehen.
Da kannst du auch im professionellen Umfeld unterwegs sein und nichts bekommen.
Klar hätte ich irgendein Support-Ticket aufmachen können und so weiter.
Oder vielleicht auf der Firewall von der IT sieht man das vielleicht aufschlagen, was da probiert wird.
Aber es ist dann wirklich schwierig und ich habe dann halt schlussendlich das Ganze so gelöst, dass ich mir wirklich ziemlich tief reingefuchst habe in den BHP-Code und dort dann Ausgaben gemacht hat, was da wirklich aufgerufen wird.
Das war glücklicherweise im BHP möglich und dann habe ich die Domains rausgeführt.
Schöne Story, das macht die ganze Sache aber nicht besser.
Auf keinen Fall.
Aber jetzt reden wir ja hier, IoT ist Teil eures Systems und ja, wir haben alle verstanden, dass wir jetzt irgendwie das Netzwerk segmentieren müssen.
Aber das gilt jetzt nicht nur für Firmen, das gilt auch für euch zu Hause.
Eine Story, die ich gerne teilen wollen würde, ist, ich habe meine Sensoren alle im selben Netzwerk und das ist natürlich nicht geil.
Dann hatte ich einen Bekannten zu Hause, der arbeitet unter anderem für Bechtel und macht da Netzwerke für große Firmen und für Kinos und allem sowas.
Somit ist der IT-technisch und netzwerktechnisch sehr bewandert.
Da sitzt er bei mir am Küchentisch, macht seinen Portscanner auf dem Handy auf, unseren Netzwerkscanner und zeigt mir mal eben ganz kurz, was er jetzt mal eben hier alles so sieht und pipapo.
Das bedeutet, wenn ihr IT-versierte Freunde habt, die ein bisschen was auf dem Kasten haben, ja, auch die können mal eben eure Lichter steuern, obwohl ihr das vielleicht gar nicht wollt.
Also vielleicht solltet ihr darüber nachdenken, euer Heimnetzwerk auch etwas zu segmentieren, sofern es denn auf WLAN und Zigbee und Co.
läuft.
Also es ist jetzt nicht nur für große Firmen was.
Aber machen wir mal mit dem zweiten Learning weiter, dass du Egress-Traffic als First Class Control betrachten solltest.
Wir haben gerade gesagt, da wurde 10 GB Outbound Traffic von einem recht unwichtigen Device beobachtet.
Was spannend ist, nicht, dass die Daten abgezogen wurden, sondern dass ein alternativer Kanal genutzt wurde, um die Daten abzuziehen.
Und wenn du jetzt mal ein bisschen recherchierst, dann findest du die MITRE Attack Database.
Das ist eine Abspaltung, ist eine Non-Profit-Abspaltung vom MIT, was sich darum kümmert, eine weltweit zugängliche Wissensdatenbank bereitzustellen, die Taktiken und Techniken von Angreifern darstellt, die auf Beobachtung aus der Praxis basieren.
Hört sich erstmal tierisch gut an.
Und in dieser Datenbank wird in der Kategorie Exfiltration explizit betont, dass Angreifer alternative Kanäle nutzen, wenn direkte HTTPS-Kanäle zu sichtbar wären.
Und das ist ja genau hier passiert.
Da hat jemand Pakete in Videostream-Protokolle gepackt und dann von einem Thermometer rausgepickt, weil klassischer HTTP-HTTP-S-Traffic zu sichtbar wäre.
Als ich das erst mal gelesen habe, habe ich gedacht, wow, super smart.
Und genau das meine ich mit Kreativität, womit ich die Folge auch eingeleitet habe.
Dass man Pakete in Paketen verpacken kann, alles irgendwie im Studium gehabt oder in der Ausbildung, das dann kombiniert mit alternativen Kanälen aus dem Netzwerk, wie zum Beispiel dieser IoT-Sensor in dem Aquarium.
Finde ich natürlich spannend.
Wobei ja mein initialer Gedanke eigentlich eher war, es ist ja schlecht, sowas über ein IoT-Device zu senden, weil da fällt es ja plötzlich auf, wenn ein IoT-Device 10 Gigabyte sendet, was es ja dann auch genau so war.
Und ich würde ja eher über einen Server gehen, der ganz viel Traffic hat, weil da fällt es noch weniger auf.
Aber wie man sieht, ja, wenn das IoT-Device dann offen ist und vielleicht einfacher zu übernehmen ist als ein Server, dann ist es natürlich klar, darüber zu gehen.
Naja, du kannst das aus zwei Perspektiven sehen.
Erstens könnte der Angreifer natürlich gesagt haben, okay, ich nutze jetzt dieses IoT-Device, dieses Thermometer, weil das mit hoher Wahrscheinlichkeit nicht gemonitort wird.
Die zweite Thematik ist, die 10 GB sind ja rausgeflossen.
Also der hat ja Erfolg gehabt.
Also von daher würde ich sagen, okay, touché.
Das ist ja das Problem bei dieser Monitoring-Software.
Du kommst zwar im Nachhinein drauf, aber die Daten sind halt schon mal weg.
Genau, es ist halt reaktiv und nicht proaktiv.
Ein weiteres Learning ist auch ganz interessant.
Behandle deine IoT-Beschaffung wie Software-Engineering.
Also das bedeutet, Kauf dir keine Devices ohne Update-Mechanik, keine Devices ohne sinnvolle Authentifizierung und Autorisierung, keine Devices ohne Logging oder State-Signale für zu Hause, würde ich sagen, okay, vielleicht.
Für ein Casino weiß ich jetzt nicht.
Und das letzte Learning, aber das ist ja hoffentlich ein alter Hut in dieser Szene, die uns jetzt hier auch zuhört.
Wenn wir davon ausgehen, dass der Angreifer Zugriff aufs Netzwerk hatte, Wenn wir davon ausgehen, dass das IoT-Device keinen Sicherheits-Lag hatte, dann gilt natürlich ganz klassische Credential und Access-Pass-Härtung, Two-Factor-Authentifizierung, device-spezifische Zugangsdaten, Abschalten von Default-Accounts, Einführung von Rate-Limits, Passwörter rotieren und so weiter und so fort.
Also eigentlich ganz klassisch die Elemente aus der OWASP Top 10 beachten, sollte ein alter Hut sein.
Das, glaube ich, sagt sogar das BSI.
Wobei mir in dem Fall eigentlich die Segmentierung am einfachsten vorkommt und eigentlich das sollte die absolute Grundlage sein.
Und sogar alle Heimrouter haben mittlerweile zwei WLAN-Netze und du kannst interne Netze machen.
Also es ist eh schon so viel möglich, dass man das relativ einfach umsetzen kann.
Und da hast du dann schon eine Barriere, die sehr tief im Stack sitzt, wo du erstmal drüber kommen musst.
Alles richtig und das ist ja auch alles jetzt nichts Neues, was wir hier erzählen.
Dennoch möchte ich euch alle einmal kurz bitten, diese Podcast-Episode kurz zu pausieren und euch zu fragen, wie gut seid ihr gerade aufgestellt.
Und ihr müsst euch dabei nie schämen, denn beim Wolfgang ist das genauso.
Bei mir ist das vielleicht genauso.
Und es ist ja auch schwierig, weil du willst ja eigentlich nur den Fenstertemperatursensor gerade installieren und du willst nicht dein komplettes Netzwerk neu modellieren anhand eines professionell erstellten Thread-Modeling etc.
Also wir verstehen das.
Doch es kann halt dazu führen, dass eure interne High-Roller-Datenbank über euer Fischthermometer nach außen, nach Finnland geschickt wird.
Aber warum ich auf dieser Segmentierung so herumhacke, ist ja auch, weil es einfach sehr oft ein Grundproblem ist.
Und auch bei unserer nächsten Geschichte ist es ein sehr zentrales System.
Und zwar ist es ein bisschen älterer Hack, der von 2015 ist.
Aber ich glaube, er ist immer noch sehr relevant und hat auch damals sehr viel bewegt.
Um was geht's?
Kurz erklärt.
Wie das groß herausgekommen ist mit einem Wired-Artikel, war das so, Sie haben das schön dargestellt, ein Wired-Redakteur sitzt in einem Auto, Jeep Cherokee, auf der Autobahn schnell und plötzlich fängt sein Autoradio verrückt spielen an, Scheibenwischer gehen ein, Klimaanlage schaltet sich Vollgas ein, ist vielleicht noch ganz nett und witzig.
Wie dann aber das Ganze übergegangen ist auf die Bremsen, die Bremsen wurden deaktiviert und die Steuerung.
wurde deaktiviert, war das schon nicht mehr so lustig.
Und das Ganze war eine Demonstration von zwei Security-Researchern zusammen mit Wired, mit dem Redakteur, die eben damals das ganze System von diesem Jeep aufgemacht haben und dann vollen Zugriff bekommen haben.
Und das war damals eben 2015, schon eine Zeit her, wobei ich nicht weiß, ob das wirklich viel, viel besser überall geworden ist.
Auf jeden Fall war das damals ein ziemlicher Weckruf für die Autoindustrie.
Das hat dann auch sehr, sehr viel bewegt natürlich, weil die Scheibenwischer wären ja noch okay oder würde man vielleicht noch tolerieren, aber wenn die Bremsen dann weg sind plötzlich, ist natürlich ein super GAU.
Und nebenbei waren das noch läppische 1,4 Millionen Autos, die da betroffen gewesen sind.
Also es war nicht nur dieses eine Jeep-Modell, sondern es war die Plattform an sich und das hat natürlich auch andere betroffen, aber das war so der weitverbreitetste damals.
Gibt es da mehr Infos zu, was da wirklich passiert ist?
Also ich meine, wenn die Security Researcher eine Kombination oder eine Demonstration mit Wired gemacht haben, Wired ist ja jetzt kein Klatschblatt, das bedeutet, mit hoher Wahrscheinlichkeit haben die dann auch alles offengelegt, oder?
Haben wir da Details zu?
Ja, ist natürlich super reported, da gibt es CVEs dazu, da gibt es Artikel.
Es hat dann ja auch Industrie einiges bewegt, dass wirklich Security-Standards geändert wurden.
Also von dem her gibt es da natürlich super viele Infos.
Was die im Prinzip gemacht haben, die haben angefangen einfach mal zu schauen, was kann denn dieses Auto.
Und das war halt damals zu frühen Zeiten, wo die angefangen haben, irgendwie online zu sein, WLAN anzubieten.
Und was die relativ schnell entdeckt haben, die Security-Researcher, dass im WLAN, wenn man bei WLAN mit dem Auto verbunden ist, dass da ein offener Port...
6667 war das damals, offen ist und da der D-Bus lauscht.
Das heißt, der D-Bus von diesem Infotainment und Navigation System im Auto ist da einfach nach außen offen und du kannst da Befehle zum D-Bus hinschicken.
Das System war ein QNX-Betriebssystem, das von BlackBerry entwickelt, ist ein Unix-artiges System und da gibt es eben auch den D-Bus, wo man einfach Befehle hinschicken kann.
Alle Linux-User kennen das ja mittlerweile.
Ziemlich wichtiger Bus eigentlich und so eine Hauptkommunikationsvariante.
Jetzt war das schon grundsätzlich mal sehr problematisch, wenn so ein wichtiger Port offen ist, aber es war nur das Infotainment-System mit der Navigation und es war im WLAN.
Sie sind dann aber relativ schnell draufgekommen, dass dieser Port auch im Mobilfunknetz offen ist.
Also die Autos waren alle online und wenn du in demselben Mobilfunknetz warst, hast du einfach, wenn du die IP von dem Auto gekannt hast, direkt auf diesen Port zugreifen können.
Das heißt, du hast jedes Auto, was irgendwie verbunden war mit dem Mobilfunknetz, sprich alle in dem Fall, Depus-Messages schicken können auf dem offenen Port 6667.
Da wurde also auch auf der Mobilfunkseite nichts gefiltert und du hast es direkt hinschicken können.
Jetzt warst du natürlich auf der Infotainment- und Navigationssystemseite.
Das ist noch nicht so kritisch grundsätzlich, obwohl du dann natürlich auch...
irgendwie einen Blödsinn anstellen kannst.
Aber die wollten natürlich noch weitergehen und haben versucht, in irgendeiner Form tiefer ins Auto vorzudringen.
Und die meisten kennen wahrscheinlich diesen CAN-Bus, der verwendet wird im Auto, um Informationen zu senden zwischen den einzelnen Microcontrollers und Devices, die so im Auto verbaut sind, aber auch so eine Bremsensteuerung zum Beispiel.
Und da war es aber schon nicht mehr so leicht hinzukommen von diesem Infotainment-System, weil da schon eigentlich eine...
Sicherheitsbarriere dazwischen war.
Es gab zwar eine Connection vom CAN-Bus zu dem Infotainment-System, aber das war natürlich relativ gut abgesichert.
Da war ein Hardware-System und da war es nicht möglich, einfach irgendwelche CAN-Bus-Messages zu schicken.
Sie haben dann aber relativ schnell herausgefunden, dass dieser Controller in diesem Infotainment-System, dass man dem eine neue Firmware aufspielen kann.
Das heißt, diese Connection von dem Infotainment-System zum CAN-Bus war offen bereit, einfach eine neue Firmware anzunehmen.
Egal, woher die stammt, keine Signierung, nichts.
Jetzt haben die einfach die Firmware umgeschrieben, haben die gepatcht und waren dann in der Lage, Canbus-Messages zu schicken auf dieses interne System, wo dann alles draufhängt, Bremsen und so weiter.
Jetzt ist es aber auch so, dass grundsätzlich auf dem Canbus ganz viele Messages herumfliegen, also zwischen den Steuergeräten und Bremsen, Devices, alles, was so im Auto verbaut ist.
Und wenn du jetzt nur eine Message injecten würdest, würde dann vielleicht noch gar nichts passieren, weil der...
Hauptsteuercontroller vielleicht immer sendet, Bremsen sind okay, Bremsen sind okay, wenn du da jetzt einmal irgendwas reinsteuerst, Bremsen sind aus, ja, das sind alles Highspeed-Befehle, da passiert dann relativ wenig.
Was sie dann aber herausgefunden haben, ist, dass es eine Möglichkeit gibt, diese Bremsen in so einen Wartungsmodus zu setzen.
Der ist speziell dafür da, wenn die Bremsen in der Werkstatt entlüftet werden, dann musst du irgendwie diese Bremsen deaktivieren, während die entlüftet werden.
Und sie haben es geschafft, diesen Diagnosemodus über CAN-Messages über einen CAN-Bus zu aktivieren und dann haben die Bremsen sich einfach abgeschalten und du konntest nicht mehr bremsen.
Glücklicherweise, so als kleinere Abschwächung von dem Ganzen, diese Diagnosefunktion geht nur bis zu einer gewissen Geschwindigkeit.
Das heißt, wenn du 100 kmh fährst, kannst du diesen Diagnosemodus nicht einschalten.
Also es geht nur bei niedrigeren Geschwindigkeiten.
So ein bisschen Abschwächung, nur leichte.
Also da hat noch irgendwo ein Sicherheitssystem gegriffen, aber grundsätzlich, sie haben dann wirklich bewiesen, sie können deine Bremsen deaktivieren und zwar nicht, wenn sie im Auto sitzen und bei WLAN mit dem Auto verbunden sind, sondern irgendwo auf der Welt, solange sie mit dem Mobilfunknetz in Verbindung stehen und haben dann Zugriffe auf tausende Autos im Prinzip gehabt.
Das Szenario klingt jetzt gar nicht so unwahrscheinlich bei der aktuellen Vernetzung von modernen Autos, oder?
Natürlich, das war ja eigentlich der erste Case in diese Richtung und das ist das Grundproblem, wenn du online bist und irgendwo einen Hack findest, dann hast du halt Zugriffe auf alle von diesen Devices.
wenn du das multiplizieren kannst.
Das ist halt der Nachteil von Cloud und von Systemen, die online sind.
Als Wired den Artikel veröffentlicht hat, wurde das alles nach dem Bilderbuch reported vorher und war das dann zu dem Zeitpunkt schon gefixt?
Also die Security-Researcher haben das natürlich, so wie es sich gehört, schon frühzeitig gemeldet.
Es wurde sogar ein Patch ausgerollt, bevor dieser Wired-Artikel erschienen ist.
Also ich glaube zwei Wochen zuvor.
Wobei, wenn ich jetzt Patch sage, man darf sich das nicht so vorstellen.
Ich habe da einen Patch, der bei Cloud eingespielt wird, sondern wir bewegen uns da im Jahr 2015.
Und damals hat das so funktioniert.
Over-the-Air-Updates gab es nicht, wahrscheinlich aus Sicherheitsgründen.
Das heißt, alle Kunden haben dann einen USB-Stick gesendet bekommen und haben diesen USB-Stick dann selber einstecken können, um diese neue Firmware aufzuspielen.
Oder den Patch waren im Prinzip Firewall-Regeln, auf gut Deutsch.
Also den D-Bus-Eingang im Prinzip blockiert.
Das geht am schnellsten.
Oder du fährst zu einer Werkstatt, aber sie waren angewiesen, dass die Leute das von sich aus machen.
Das ist natürlich ein großes Problem.
Also du kannst es nicht von der Entfernung jetzt irgendwie patchen.
Wie der Wired-Artikel aber herausgekommen ist, einen Tag später hat das Mobilfunknetz reagiert und hat einfach diesen Port in ihrem gesamten Mobilfunknetz gesperrt.
Das heißt, das war eigentlich die beste Variante, ist aber erst nach dem Wired-Artikel passiert, weil damit hast du dieses Einfallstore mal komplett geschlossen, weil du nicht mehr über das Mobilfunknetz gehen kannst.
Jetzt ist Jeep ja nur eine Automarke von vielen.
Hat das denn irgendwie einen größeren Effekt in der Automobilindustrie gehabt?
Oder waren das einfach nur zwei Hacker von irgendeiner Universität, die ein bisschen Research gemacht haben, Jeep hat es gefixt und dann sind wir einfach nur mit unserem Leben, haben weitergemacht wie normal?
Jeep hat es probiert, so zu framen, aber die ganzen Behörden haben dann relativ Druck gemacht, dass das höher gewertet wird, dass das wirklich eine Rückholaktion wird, dass das wirklich auf einen höheren Level gepusht wird.
Längerfristig hat es im Prinzip dann auch die ganze Branche bewegt, neue Standards einzuführen, neue Security Standards, wo dann einfach auch eine striktere Trennung vorgesehen wird vom Campus und vom Infotainmentsystem.
Also genau diese Segmentierung, die wir davor besprochen haben, dass die nochmal stärker gelebt wird und dadurch die Sicherheit erhöht wird.
Ein anderer Punkt, der natürlich ganz klar.
auch ein Riesenproblem ist und ich glaube, das ist auch besser geworden, wobei, wie gesagt, ich kann jetzt nicht für die Autoindustrie sprechen, aber der Secure Boot, dass du nicht so einfach einfach eine neue Firmware aufspielen kannst, sondern die Firmware signiert sein muss, das ist ja jetzt schon der Standard geworden, aber ich kenne es selber, gerade wenn man dann über IoT-Devices oder so spricht, da ist es eigentlich definitiv noch nicht der Standard.
Also da kann man relativ leicht meistens irgendwelche Over-the-Air-Updates sogar von der Firmware fahren und da hat sich das noch nicht zum Standard entwickelt.
Wenn ich jetzt darüber nachdenke, was können wir daraus so lernen, dann ist das ja schon relativ nah an der Thematik wie mit dem Aquarium.
Trust Boundaries, wer darf mit was kommunizieren.
Auf der anderen Seite das Infotainment-System mit dem Hauptbus-System.
Ja, würde ich schon sagen, dass da eine Kommunikationsmöglichkeit bestehen sollte.
Gut, jetzt Zugriff über WLAN, Zugriff über das Mobilfunknetz.
Das waren vielleicht ein bisschen zu offene Ports.
Die hätte man, glaube ich, streichen können.
War ja auch der Quick-Fix, wenn ich das jetzt so korrekt verstanden habe.
Was kann man daraus noch lernen?
Also ich möchte mal kurz die Autoindustrie in Schutz nehmen.
Ich glaube, sie haben schon sehr viel gelernt und haben da auch einiges verbessert, wenn es um Security geht.
Mir ist gerade eingefallen, dass mir ein Freund kürzlich erzählt hat, der beide Schlüssel von seinem VW verloren hat, nicht mehr in der Lage war, einen neuen Schlüssel zu bekommen von VW, weil die den Verschlüsselungscode nicht haben bei ihnen.
Das heißt, am Ende hat er den kompletten Bordcomputer und alles austauschen müssen.
Das waren viele Tausende Euro, weil dieser Schlüssel, dieser Verschlüsselungsschlüssel nur auf den eigentlichen Schlüsseln lebt, die du daheim hast.
Und wenn du beide verlierst, hast du keine Möglichkeit mehr, das werkseitig irgendwie zu resetten oder die neue Schlüssel zu holen.
Also vielleicht hat die Artobranche gelernt, wobei...
Ob das jetzt gut oder schlecht ist, ich glaube, man könnte das definitiv kundenfreundlicher zumindest machen, als wenn du dann die gesamte Elektronik austauschen musst im Auto und das mehrere tausend Euro kostet.
Aber man sieht auf jeden Fall, dass die Branche schon was gelernt hat von diesem Hack damals 2015.
Was wir jetzt davon lernen können oder ganz allgemein ist natürlich, einfach mal die Angriffsflächen zu reduzieren.
Das hast du schon richtig gesagt.
Also die Ports, die da offen sind, muss das im WLAN nach außen offen sein.
was muss man wirklich exponieren von dem System nach außen.
Dann natürlich Vertraue allen, was da reinkommt über meine externen Schnittstellen.
Also einfach einen Port offen zu haben und einfach alles zu akzeptieren, ohne eine Authentifizierung, Autorisierung, ist natürlich genauso ein Problem.
Also diese Zero-Trust-Policy, die du schon genannt hast, macht natürlich auf jeden Fall Sinn, dass man einfach mal alles ablehnt, was da reinkommt und man muss dann wirklich eine ordentliche Authentifizierung machen.
Egal, ob das jetzt auf Firewall-Seite ist oder im internen System.
Secure Boot habe ich schon erwähnt.
Also ich glaube, da kann man sicher noch einiges optimieren und ich wage es mal zu bezweifeln, dass alle Firmen auf ihren ganzen IoT-Devices oder kleineren Devices wirklich Secure Boot oben haben und dass man da keine Firmware so einfach flashen kann.
Also das bezweifle ich und sehe ich auch ständig noch, dass man da eigentlich keine Sicherheitsbeschränkungen bei ganz vielen Devices hat.
Seite unterwegs ist, sollte man sich vielleicht wirklich mal da auch umschauen.
Ist natürlich auch immer die Frage, unterstützt ist die Hardware, kann ist die Hardware überhaupt die Chips, die man verwendet.
Das ist halt auch immer so das Problem, dass die Hardware, vor allem wenn sie dann günstig sein soll, natürlich auch ein bisschen hinterherhinkt, bis man da die ganzen Security Features dann wirklich auch drin hat.
Beim Secure Boot, ich meine, klar, Signierung der Firmware, aber auch da gibt es ja super viele Lücken.
Certification, Pinning und so weiter.
Also diese ganze Thematik, nur deine Firmware zu zu signieren, ist ja nicht so einfach, wie wir es jetzt hier gerade so salopp sagen, denn die ganze Zertifikatsinfrastruktur dahinter und so weiter, die muss natürlich auch ordentlich stehen und auch ordentlich stabil aufgebaut sein.
Klar, und was machst du, wenn dein Hauptschlüssel verloren geht oder geklaut wird, dein CE, was auch immer?
Klar, also da hängt schon viel dran, aber das Problem ist ja, dass bei den meisten Devices, die ich zumindest so kenne, auch im professionellen Umfeld, da sind wir noch nicht mal so weit.
Also da gibt es einfach gar nichts.
Und du kannst da einfach einen Upload machen von deiner Firmware und that's it.
Also da sind wir gar nicht so weit, dass wir dann uns um die anderen Probleme kümmern müssen, sondern da ist schon mal grundsätzlich was falsch.
Wir reden hier von einem Case von vor elf Jahren.
Ja, ich hoffe mal, dass es bei der Autoindustrie ein bisschen besser ist.
Aber wenn man jetzt wieder auf IoT-Devices oder ganz allgemein Devices, die so herumfliegen, ausweitet, dann schaut es natürlich auch schlechter aus.
Wirklich, sogar im professionellen Umfeld, da ist halt Hardware teilweise 15 Jahre alt.
Und zwar nicht vor 15 Jahren gekauft, sondern vor 15 Jahren designt.
Und da ist halt wenig passiert in der Zwischenzeit.
Das ist das Problem oft.
Ich stelle mir gerade die Frage, du hast ja auch gesagt, wie wurde das gepatcht?
Und zwar wurden USB-Sticks versendet und allem drum und dran.
Jetzt frage ich mich gerade, Overseer-Updates, wäre das eine Lösung?
Weiß ich nicht.
Bringt auch schon wieder neue Attack-Vektors mit sich.
Alles wieder neu absichern.
Denn auch so eine Suchmaschine wie, wie heißt das, Shodan, da...
findest du ja immer wieder irgendwelche Hardware, irgendwelche Ölfeldern mitten in Texas, die man offen über das Internet steuern kann.
Also du verstehst, was ich meine.
Over-the-Air-Updates wäre eine schöne Thematik, das zu fixen, alles gut.
Aber da kommt ja ein riesiger Rattenschwanz mit, was dann vielleicht einen ähnlichen Sicherheitsvorfall auslösen kann.
Also ich glaube, dass wenn du von 1,4 Millionen Fahrzeugen sprichst, also wenn du wirklich viele Devices draußen hast, dann musst du heute ...
Over-Tier-Update anbieten.
Weil wenn da irgendwie etwas passiert, dann musst du in der Lage sein, das in kurzer Zeit zu patchen.
Mir ist schon klar, dass das auch wieder schwierig ist, aber da sprechen wir dann genau über die Sachen, die du erwähnt hast.
Wie kann ich das Ganze signieren?
Wie kann ich das sicher machen, dass mir niemand anderer deine Firmware aufspielt?
Was mache ich, wenn meine Schlüssel verloren gehen?
Und so weiter.
Das sind dann schon die Sachen, die man beachten muss, aber ich glaube, man kann es sich heute nicht mehr leisten, wenn du jetzt als Hausnummer über 1000 Geräte irgendwo draußen hast, da kein Over-the-Air-Update mehr zu machen, wenn du wirklich einen Fix ausliefern musst.
Wenn du jetzt, keine Ahnung, eine ganz spezielle Hardware auslieferst, ein MRT-Scanner-Gerät, was sowieso nicht online ist, wo es vielleicht nur 300 Stück gibt, dass du das dann mit USB belieferst, ein Krankenhaus wird sich nie einlassen auf Over-the-Air.
Das macht natürlich Sinn, aber wenn du jetzt in die Masse gehst, Autos oder irgendwelche IoT-Devices, wo es um tausende Stückzahlen geht, ich glaube, da musst du das heute anbieten.
Ich glaube, dass es dir heute niemand mehr verzeiht, wenn du sagst, du hast einen kritischen Patch, du kannst nicht mehr bremsen und dann sagst, ah, Over-the-Air ist aber schlecht.
Es ist zwar das Einfallstore, Over-the-Air, wie damals 2015, aber ich kann jetzt nichts patchen und wir rollen jetzt mal USBs aus und auf der Straße fahren 1,4 Millionen zwei Tonnen Vehikel herum, die plötzlich nicht mehr bremsen könnten.
Ich weiß nicht, ob ich das zu generalisiere, aber es ist schon faszinierend, dass zwei unterschiedliche Hacks sehr, sehr ähnliche Mitigation-Strategien haben.
Denn wir haben über Trust Boundaries gesprochen.
Wer darf mit wem kommunizieren?
Und es hört sich so an, als wenn man das richtig gemacht hätte, dass die zwei spezifischen Attacken dann ja eigentlich verhindert hätten werden können, oder?
Genau.
Es hätte sich verhindern lassen.
Und du hast es auch schon gesagt, 2015 war das.
Man hatte doch Zeit gehabt, das zu verbessern.
Und ich weiß nicht, ob du es mitbekommen hast, aber die letzten Tage ist es durch die Medien gegangen von diesem DJI-Staubsauger-Roboter.
Ich bin in einer anderen Bubble als du.
Hebe ich mal ganz kurz auf den aktuellen Stand.
Das ist mal ganz was Neues, dass ich dir News gebe, nicht du mir.
Und es war vor allem so ein Case, der jetzt auch durch die ganzen Mainstream-Medien gegangen ist, also jetzt nicht nur auf der technischen Seite.
Und zwar ging es da um einen Hack, der gar kein Hack war, weil die eigentliche Idee, die ein Nicht-Techniker hatte, Also es ist kein Developer, Hacker oder sonst irgendwas, sondern Sammy, hat er geheißen, wollte einfach nur so ein Spaßprojekt bauen und wollte mit dem Controller von seiner Konsole seinen Saugroboter steuern von DJI.
Und wie macht man das heutzutage, wenn man keine Ahnung hat, aber sagt selber glaube ich, dass er KI-Stratege ist.
Er hat einfach mal einen KI-Bot gefragt, in dem Fall Claude Code meines Wissens, und hat einfach mal gesagt, hauchen wir doch diesen ganzen Traffic ab von diesem Staubsauger-Roboter.
Und suche mir das dann raus, damit ich den selber steuern kann.
Also einfach über den Computer dann, Bluetooth, Konsole, wäre doch cool, wenn ich dann mit meinem Roboter herumfahren könnte in der Wohnung.
Und hat sich da seinen Token rausgeholt und so weiter, hat dann herausgefunden, okay, das Ganze funktioniert über MQTT.
Also ist auch wieder so ein klassisches IoT-Protokoll, wo Messages hin und her fliegen.
Und was dann aber ganz interessant war, er hatte plötzlich, wenn er auf den MQTT-Broker, auf den Server zugegriffen hat, nicht nur Zugriff auf seinen Staubsauger-Roboter, sondern auf 7000.
andere Saugroboter.
Und nochmal, wir sprechen da vom Februar 2026.
Und DJI ist ja jetzt keine kleine Firma unbedingt, sondern eine Firma mit Historie und die doch ein paar Geräte da draußen hat.
Es hat sich dann auch gezeigt, dass man noch andere Powerstations, glaube ich, ansprechen kann über den gleichen MQTT-Server.
Und dann waren so um die 10.000 Geräte in 20 verschiedenen Ländern.
hatte man da dann Zugriff drauf.
Und vor allem, wenn man bedenkt, was Staubsaugerroboter heutzutage liefern.
Die liefern dir ja Audio, Video, damit du nachschauen kannst, ob es deinem Hund gut geht.
Andi, du musst das ja verstehen.
Du machst das wahrscheinlich auch ständig.
Oder der Katze, wenn die gerade rumfährt mit dem Staubsaugerroboter oder so, dass man da mal schauen kann.
Das heißt, man hat vollen Zugriff in die Wohnungen hinein.
Plus natürlich Floorplan üblicherweise.
Also wie sind die Zimmer aufgeteilt?
Diese ganzen Dinge, wo immer alles sagen, ist doch egal.
Mein Staubsaugerroboter hat doch keine kritischen Daten.
Und genau die waren alle verfügbar.
Und das einzige Problem oder das Hauptproblem war, dass dieser MQTT-Broker, beziehungsweise ganz allgemein so PubSub-Systeme, die sind üblicherweise standardmäßig nicht abgesichert.
Das heißt, wenn du da ein Login hast und dich anmelden kannst, dann kannst du dich überall subscriben zu jedem Channel, zu jedem Topic.
Und du musst manuell SELs drüberlegen, dass du eben nur Zugriff auf ein spezielles Topic haben kannst, auf das Topic, Video, Audio.
Location von deinem Saugroboter und nicht von allen Saugrobotern.
Und man kann da ja mit einem Pub-Sub-System klassischerweise Subscriptions machen.
Das heißt, du kannst auf irgendwelchen Topics lauschen.
Und da gibt es auch Wildcards, also ein klassisches Sternchen zum Beispiel.
Das heißt, du kannst sagen, ich will jetzt auf alle Channels hochen, die Location heißen, mit einem Stern, also alle Saugroboter, deren Location.
Und dann bekommst du ständig alle Messages geschickt von allen Staubsauger-Robotern und ihre Location.
Und genau das war in dem Fall.
Das heißt, da gab es keine Autorisierung, nur eine Authentifizierung.
Aber klar, wenn du Besitzer von einem Staubsauger bist, kannst du dich authentifizieren, bekommst Zugriff und dann aber auch Zugriff auf alles andere.
Also da gab es keine Beschränkungen auf dieser Ebene.
Also auch da wieder Nullsegmentierung und eigentlich würde ich mal sagen, schon eine ziemliche Basiskonfiguration.
Aber ich kenne das selber.
Ich habe kürzlich mit MQTT-Servern zu tun gehabt.
Es ist schon ein eigenartiges Konzept, diese ACLs.
Und gerade wenn man mit Wildcards arbeitet, man muss ja mit den ACLs teilweise auch mit Wildcards arbeiten.
Es ist schon ein bisschen frickelig und irgendwie nicht so klar, wer was darf.
Also ich finde es auch irgendwie vom gesamten Design, vom Sicherheitsdesign, ein bisschen schwierig, muss ich zugeben.
Was spricht denn dagegen, dass einfach jeder Roboter ein eigenes MQTT-Topic kriegt und nur Zugriff auf dieses Topic haben kann?
Gar nichts.
Also jeder Roboter hat wahrscheinlich sein eigenes Topic, aber ich kann halt auch alle anderen Topics lesen.
Und das ist so hierarchisch aufgebaut, also zum Beispiel Tel für Telemetry slash Andis Roboter slash Location.
Und ich kann aber natürlich auch sagen, ich will jetzt subscriben zu Tel slash Stern slash Location.
Dann bekomme ich einfach alle Locations von allen Geräten.
Also das ist halt in MQTT so vorgesehen.
oder PubSub ganz allgemein.
Du hast jetzt Telemetrie auf den First Level gesetzt, aber du kannst auch deinen Roboter auf den First Level setzen und dann nur dir Zugriff auf das First Level von deinem Roboter geben und darunter Telemetrie und Commands und was weiß ich für Topics noch haben.
Also kurzum, ganz Basis, Software-Design, Isolierung, Mandanten-Isolierung ist hier falsch gelaufen.
Ja, es gab scheinbar einfach keine ACLs.
Also es hat einfach, so wie es aussieht, einfach jeder User auf alles Zugriff gehabt.
Und das ist natürlich, wenn du dann Cloud Code drüber jagst, der findet es natürlich relativ schnell heraus, weil der probiert das einfach mal aus.
Und wie gesagt, das war kein Hacker, das war kein Security Researcher, das war einfach ein Dude, der sich gedacht hat, er macht da jetzt ein Spaßprojekt.
Was heißt das denn jetzt für uns?
Heißt das jetzt, jedes neue Gerät, was ich mir jetzt kaufe, muss ich jetzt einmal Cloud Code über die API drüber jagen, um zu gucken, kann ich das zu Hause einsetzen?
Das kann es ja jetzt irgendwie auch nicht sein.
Ja, es gibt ja genug Security Tools, die du nehmen kannst, aber ich glaube, so diese Grundregeln, die Basissachen, die man einfach verstehen muss oder auch sich überlegen muss.
Das ist einfach, ich glaube, Authentifizierung, Autorisierung, also auf welche Objekte darf mein User dann wirklich Zugriff haben und dann halt eine sinnvolle Segmentierung, sei es auf User-Ebene, sei es auf Netzwerkebene.
Ich glaube, wenn man die drei Sachen sich einfach durchdenkt, Authentifizierung, Autorisierung und sinnvolle Segmentierung als Überbegriff, dann bist du wahrscheinlich schon relativ sicher.
Und wenn man jetzt die drei Cases betrachtet, dann ist es immer irgendwie ein Segmentierungsproblem gewesen.
Also ich habe irgendwie weiterspringen können.
Einen Hopp, weiter, raus aus meinem Käfig.
Wir haben ja auch mal über mehr Mandantenfähigkeit gesprochen in einer Episode und da ging es ja auch genau darum.
Also wie kann ich meine Mandanten, meine User einsperren in ihrem Bereich, damit die möglichst schwer nach außen kommen, ausbrechen können.
Und da macht halt einfach ein sinnvolles Management von Segmenten oder halt dementsprechend auch Autorisierung, was ja auch eine Segmentierung ist, einfach Sinn.
Ich will jetzt nicht sagen, diese Episode ist sehr netzwerklastig.
Denn wenn man sich die ganzen Cases mal im Detail anschaut, dann unterscheiden die sich natürlich schon.
Aber es ist schon beachtlich zu sehen, wie stark Netzwerksegmentierung oder Kommunikationssegmentierung, wer darf mit wem kommunizieren, also welchen Einfluss sowas haben kann und was eigentlich dadurch verhindert werden kann.
Denn es ist ja nicht einfach, aber der Impact ist Wahnsinn.
Ich frage mich halt immer und immer und immer und immer wieder, warum wird das immer so als nachgelagerter Prozess angesehen.
Weil auch du sagst ja, in vielen Firmen kommst du rein als Berater, kriegst Zugriff aufs Netzwerk.
Und das zeigt mir ja auch, dass es ein nachgelagerter Prozess ist.
Dass es jetzt irgendwo auf der To-Do-Liste ganz hinten steht.
Weil es ist ja nicht dringend, weil es ist ja nichts passiert.
Wahrscheinlich.
Oder ich kenne die Gründe nicht.
Oder vielleicht einfach, weil es kompliziert und schwierig ist.
Ich glaube, es ist kompliziert und ich könnte natürlich jetzt immer dieses Totschlag-Argument in den Raum werfen, sind halt gewachsene Strukturen.
Aber wie ein Freund von mir, der übrigens auch Security-Berater ist, immer sagt, ja, ist ganz nett, die gewachsenen Strukturen, aber dann lasst uns einfach in die Zukunft blicken und diese ändern.
Gewachsene Strukturen, was ist denn das für eine Ausrede?
Ja, das ist der aktuelle Case, aber das heißt ja nur, das klingt so wie ein Synonym für, okay, hier ist was zu holen.
Ja, es ist halt immer eine Ausrede einfach, warum das so ist, aber eigentlich interessiert mich sehr nicht, warum es so ist, sondern ich will es ja ändern.
Also wir wollen es ja in einen besseren Zustand überführen.
Und da brauchen wir uns eigentlich gar nicht überlegen, warum war das die letzten zehn Jahre anders, sondern eher, wie können wir es ändern oder warum ist es bisher noch nicht passiert vielleicht.
Aber auch das ist eigentlich gar nicht mehr so wichtig.
Die Frage ist, wie kann ich es ändern, wie kann ich in einen sicheren Zustand kommen?
Und darauf sollte man sich eigentlich konzentrieren.
Und ich glaube, man vergisst es auch oft, wir alle machen Fehler und man braucht halt in einem SQL-Statement nur irgendwo eine WHERE-Clause vergessen, wo irgendwas geprüft wird, sicherheitsrelevant ist und plötzlich bist du schon offen.
Und da würde ich mir jetzt gar nicht ausnehmen.
Das basiert uns, glaube ich, allen.
Da müssen wir damit leben.
Aber man kann ja auch heutzutage damit umgehen.
Es gibt Tools, Security, Checks.
Ich kann selber einfach mal statt der ID 5 oben in der URL ID 6 eingeben und schauen, ob ich plötzlich auf einen anderen User-Zugriff habe.
Diese easy Sachen.
Also es ist unsere Verantwortung und die müssen wir halt irgendwie wahrnehmen als Developer, auch wenn es nicht einfach ist.
Kommt halt einfach jetzt dazu.
Und wenn man online sein will und alles online haben will, muss man sich halt auch darum kümmern.
Der Wolfgang und ich haben noch mehr crazy Hacks vorbereitet, die vielleicht als Mitigation nicht immer die Netzwerksegmentierung haben.
Die haben wir jetzt gerade irgendwie, weiß ich nicht, per Zufall irgendwie so gebündelt.
Wir hatten noch ein paar hardware-spezifischere Hacks und vielleicht machen wir nochmal eine Episode Nummer 2 dazu.
Lasst uns einfach mal wissen, was ihr über diese Art von Format denkt oder beziehungsweise ob da irgendwas Überraschendes bei euch war.
Und ich würde jetzt super gerne wissen, was ist eure Ausrede?
die ihr in der Firma habt oder vielleicht auch im privaten Homelab, um euer Netzwerk nicht zu segmentieren.
Meine ist relativ einfach, warum ich das in meinem Homelab noch nicht habe.
Jetzt kommt, ich habe keine wichtigen Daten, oder?
Nein, nein, nein.
Das habe ich nie gesagt.
Wichtige Daten sind für mich wichtig.
Ob meine wichtigen Daten für dich wichtig sind, kann ich nicht beantworten, wie viel du über meine wichtigen Daten wissen möchtest.
Bei mir ist es aber super simpel.
Ich habe einfach kein DNS oder MDNS oder ähnliches.
in meinem Netzwerk.
Das bedeutet, auch in meinem Netzwerkscanner ist hardcoded eine IP von einem Samba-Share von meinem Proxmox-Server drauf.
Und wenn ich das Netzwerk segmentieren würde, dann müsste ich überall die hardgecodeten IPs abändern.
Und das ist natürlich schmerzhaft.
Du kennst das, wenn du schon mal versucht hast, ein recht komplexes Passwort auf einem kleinen Display von einem Netzwerkscanner einzugeben.
So was möchtest du nicht nochmal machen.
Und das versuche ich einfach zu vermeiden und so lange vor mir herzuschieben.
Also ganz klassisch.
könnte man sagen, gewachsene Strukturen oder ich muss es einfach machen, dann muss ich mir einfach mal ein oder zwei Tage Zeit nehmen und mich da durchbeißen, aber ich muss auch zugeben, ich bin mir gar nicht sicher, ob ich alle Stellen, wo ich eine hartgecodete IP drin habe, gerade im Kopf habe oder ob ich die dann über Wochen hinweg immer so, ah, dieses System fehlt gerade, ah, da muss ich die IP austauschen, aber ich will auch irgendwie kein...
DNS-Server und du kennst diese Problematik.
Wenn es nicht DNS ist, wer ist schuld am nächsten Outage?
DNS.
Es ist immer DNS.
Ausreden, Ausreden, Ausreden.
Übrigens, vielleicht noch eine Seitennote zu DJI.
Die hatten auch eine ganz coole Ausrede, weil Journalisten geschrieben haben, ja, da kann man doch alle Messages in Klartext lesen von den anderen Devices.
Dann haben die gesagt, nein, nein, nein, wir machen MQTT over TLS.
Da ist gar nichts in Klartext lesbar.
Aber wenn du einen User hast, dann hast du plötzlich halt...
Alles in Klartext.
Klar ist es nicht, weil sie verschlüsselt übers Internet, aber es kommt bei dir dann unverschlüsselt wieder an.
Also ja, Ausreden gibt es scheinbar viele.
Man sollte, glaube ich, lieber einfach probieren, das zu verbessern, anstatt die Energie in die Ausreden zu legen.
Und wenn man immer sagt, okay, meine Daten sind doch nicht zu wichtig, dann frage ich immer, ja, kann ich da einen Zugriff auf deine Daten haben?
Gibst du mir mal einen User, wo ich auf alle deine Daten zugreifen kann?
Wenn sie nicht zu wichtig sind, kannst du sie mir ja auch zeigen.
Ich bin ja sogar ein Freund.
Ich glaube, den besten Case oder das beste Gegenargument, was ich mal gehört habe, ist zu so Aussagen wie ich habe, nicht zu verbergen und so weiter.
Da ging es dann oft damals, als die Überwachungsdebatte losging.
Wärst du damit d'accord, Wolfgang, wenn ich Zukunft auf deine Amazon-Bestellung hätte und ich sehe, dass du ein Buch über Aids bestellt hast?
Wärst du damit d'accord, dass das jeder weiß?
Ja, ja, aber dann kommen ja immer die Leute und sagen, ich bestelle ja kein Buch über Aids.
Aber ich glaube, dass die wenigsten ihren Amazon-Account auch so teilen würden, egal was sie da bestellen oder auf deine E-Mails oder so.
Gib mir doch mal Zugriff auf deine E-Mails, nur lesen.
Und dieses Beispiel, das ich gerade genannt habe, heißt jetzt nicht, du hast Aids oder nicht Aids.
Es geht nur darum, wenn alle wissen, du hast ein Buch über Aids bestellt, was die in ihrem Kopf daraus machen.
Und du weißt, nicht jeder ist so gebildet, wie Aids sich verbreitet und so weiter, aber jeder hat Angst davor.
Möchte vermeiden, dass er oder sie Aids bekommt.
Und auf einmal brechen die Kontakte ab und so weiter, weil sie halt uninformiert sind, wie Aids sich überträgt.
Das war der Longtail von dieser Story.
Und die fand ich so schön, also so nahbar.
Und immer, wenn mir jemand sagt, ich habe nichts zu verbergen und wir sprechen über diese Story, dann sieht danach die ganze Sache relativ schnell anders aus.
Noch ein anderes Beispiel wäre die Suchhistorie.
Darf ich mal auf deine Google-Suchhistorie Zugriff bekommen?
Zeigst du mir die einfach mal.
Bin doch ein guter Freund.
Also von mir hast du wirklich nichts zu verbrechen.
Ich bin sehr dankbar, dass Chat-GPT-URLs einfach mit so einer UUID versehen werden und nicht mit der Zusammenfassung von meinem Chat.
Aber belassen wir es hierbei.
Sprengt mal in unsere Discord-Community.
Ich bin hart interessiert an euren Ausreden, warum ihr euer Netzwerk noch nicht segmentiert habt.
Und Hacks über MQTT, Stauksauberroboter, einem Jeep Cherokee oder eurem IIT-Sensor in eurem Hightech-Aquarium, warum ihr sowas nicht verhindert habt.
Ich habe mich jetzt mal nackt gemacht und einfach nur faul hat, weil ich einfach ganz zu Hause kein DNS betreibe.
Aber mein Heimnetzwerk ist auch kein Casino.
Das war es von uns.
Du schließt mir deine Ausrede.
Sehr gut.
Immer, immer.
Also man hat nur 24 Stunden am Tag, zwei Hände und schlafen muss ich auch noch.
Also von daher.
Und natürlich für euch neuen Content machen.
Wir sind raus.
Bis später.
Bye, bye.
Ciao.