Replay-Angriff auf Zigbee-Steckdose

Begonnen von Prof. Dr. Peter Henning, 29 Februar 2020, 12:44:59

Vorheriges Thema - Nächstes Thema

Prof. Dr. Peter Henning

In einem kleinen Forschungsprojekt ist es uns im Labor gelungen, mittels eines Sniffers Zigbee-Pakete mitzuschneiden und auf eine Zigbee-Steckdose einen Replay-Angriff zu fahren, d.h. sie unbefugt zu schalten. Die Anleitung dafür werde ich natürlich nicht veröffentlichen - §202c StGB steht dem im Wege. Vielleicht kann ich das aber auf dem 7. FHEM-User-Treffenin Karlsruhe mal demonstrieren lassen.


Außerdem ziehe ich für mich den Schluss, dass ich Zigbee-Geräte nicht für sicherheitskritische Zwecke einsetzen werde.


LG

pah

justme1968

das ist aber nichts neues...

siehe z.b. hier: https://research.kudelskisecurity.com/2017/11/21/zigbee-security-basics-part-3 oder hier: https://github.com/riverloopsec/killerbee oder hier: https://courses.csail.mit.edu/6.857/2017/project/17.pdf

da bei funk geräten unabhängig davon immer das risiko des absichtlichen oder unabsichtlichen jamming besteht (und sogar einfacher durchzuführen ist als gezielte attacken) sind diese grundsätzlich nicht für sicherheitskritische sensor oder schaltaufgaben geeignet.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Prof. Dr. Peter Henning

Dass dies per se nichts Neues ist, kannst Du in meinen SmartHome Hacks nachlesen (erschienen im Mai 2016, der erste dokumentierte Hack von Zigbee war im November 2015).

Neu ist allerdings, wie einfach das in diesem Falle war, mehr will ich dazu an dieser Stelle nicht äußern.

Erstens sind offenbar die Änderungen am Protokoll nach wie vor unzureichend, und zweitens wird die entsprechende Software rapide weiter entwickelt.

LG

pah

volschin

Zitat von: justme1968 am 29 Februar 2020, 13:02:04
da bei funk geräten unabhängig davon immer das risiko des absichtlichen oder unabsichtlichen jamming besteht (und sogar einfacher durchzuführen ist als gezielte attacken) sind diese grundsätzlich nicht für sicherheitskritische sensor oder schaltaufgaben geeignet.
Hast Du zwar recht, aber Störung mit Jammer und ein Replay sind zwei paar Schuhe. Ist zwar unschön, wenn durch Jammer Alarmsensoren außer Kraft gesetzt werden, aber das z.B. ein Schloss mittels Replay geöffnet wird, ist nochmal eine andere Hausnummer.
Intel NUC+Ubuntu 24.04+Docker+FHEM6
HomeMatic: HM-MOD-RPI-PCB+HM-USB-CFG2+hmland+diverse, HUE: Hue-Bridge, RaspBee+deCONZ+diverse
Amzn Dash-Buttons, Siro Rollos
4xRPi, 4xCO20, OWL+USB, HarmonyHub, FRITZ!Box 7690, Echo Dots+Show8, HomeBridge

justme1968

bei meinem kommentar lag der schwerpunkt vor allem auf dem 'unabsichtlichen'.

ich habe einen s300ht der reproduzierbar alle hm aktoren in der nähe lahm legt sobald die batterie zur neige geht. die anderen 5 haben das problem nicht. ein panstamp hat mangels brown out detection ähnliche probleme gemacht. ein hm türgriff sensor ebenfalls.

funk ist einfach prinzipiell anfällig. und wenn ich aus diesem grund nicht sicherheitskritisches per funk betreibe kümmert mich auch die replay attacke  nicht mehr :).
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Prof. Dr. Peter Henning

Prinma - aber meine OW ist sehr kritisch und der Verlegung von Kabeln gegenüber prinzipiell abgeneigt. Frag nicht nach den Kommentaren, als ich bei unseren neuen Fenstern auch im Schlafzimmer auf Rollladenmotoren bestanden habe und vier Dosenlöcher untereinander gesetzt habe.

LG

pah

volschin

Außerdem für Mietwohnungen keine Option.
Intel NUC+Ubuntu 24.04+Docker+FHEM6
HomeMatic: HM-MOD-RPI-PCB+HM-USB-CFG2+hmland+diverse, HUE: Hue-Bridge, RaspBee+deCONZ+diverse
Amzn Dash-Buttons, Siro Rollos
4xRPi, 4xCO20, OWL+USB, HarmonyHub, FRITZ!Box 7690, Echo Dots+Show8, HomeBridge