[30c3] lecture: Attacking HomeMatic

[frank]

1) sollte gelöst sein - probier mal

version 8748, eben über update, leider noch nicht.

3) kann man auch drüber nachdenken. was macht am meisten sinn? die rawmessage ist sicher einfach, aber nicht von vielen lesabar. werde auch einmal drüber schlafen

sinn macht wahrscheinlich beides. die "lesbare" variante für den normalen gebrauch, um einschätzen zu können, ob man eventuell selbst der auslöser war. bei parallel genutzer eq3 software mit selber hmid ist man zb selbst der angreifer. auch die einschätzung der qualität des angriffs finde ich wichtig. war es "nur" spionieren (lesen) oder sogar aktives manipulieren (schreiben) der devices. spätestens jetzt muss man tätig werden, um die alten einstellungen wieder herzustellen.

die raw-message für tiefer gehende analysen. denkbar ist ja immer auch ein fehlalarm (warum auch immer). mit einem notify/watchdog schalte ich bei mir im moment bei allen io logIDs=all für mindestens 10 min an. jede weitere erkennung in dieser zeit setzt den timer neu. so hoffe ich, die komplette angriffswelle zu loggen. dabei fehlt dann leider die erste rawmessage. oder man schreibt die raw-message mit level0/1 ins fhem.log. sollte für jeden wichtig genug sein.

ein automatisches deassign halte ich für gewagt.

das ist wahr. dann muss die erkennung schon 100% funktionieren. ausserdem könnte das dem angreifer auch gefallen.

ein deasign kann man machen indem man das attribut IOGrp ändert (hoffe ich )

ich schaffe nur ein "um-assignen". ein echtes "deassign" (device mit keinem io assignt) kann in seltenen fällen auch ohne angriff nützlich sein. bisher habe ich dann ignore genutzt oder unpair.

wann soll man es nun deassignen? man könnte ein Reading "prot:babbling" einführen, wenn  mehr als 150 messages in 1h an ein device gesendet werden. Der User könnte dann das deassign fahren. wäre möglich.

gute frage. sehr vom device und anwendungsfall abhängig. der zwischenstecker mit leistungsmesser kann äusserst gesprächig werden. da werden die 150 messages manchmal nicht reichen. ein fensterkontakt wird manchmal wochenlang nicht betätigt. optimal wäre ein attribut zum einstellen. oder aus dem attribut actCycle einen passablen wert ableiten.

insgesamt sollten 1600 messages in 1h möglich sein. Wenn der Hacker nun den Angriff über 11 devices macht wird er es wohl doch schaffen.  Kann man nichts machen.
Im Falle des deassign muss der User immer noch reagieren und es wiederherstellen! Irgendwann.

die beste abwehr für diesen fall scheint mir im moment ein umassignen auf einen cul. der pariert alle angriffe.