[30c3] lecture: Attacking HomeMatic

Loredo · 27 Dezember 2013, 21:59:24

Aus gegebenem Anlass möchte ich für Interessierte auf einen Talk "Attacking HomeMatic" beim 30c3 am Montag um 1600 hinweisen:

http://events.ccc.de/congress/2013/Fahrplan/events/5444.html

Mirror:
http://ccc.devsn.se/congress/2013/Fahrplan/events/5444.html

Gibts auch als Livestream über http://streaming.media.ccc.de/ bzw. anschließend On-Demand.

Interessant dabei ist auch die Vorstellung von Homegear, einer weiteren Alternative für die direkte Kommunikation mit HomeMatic Geräten. Vielleicht ja mal grundsätzlich Interessant.

Gruß
Julian

justme1968 · 31 Dezember 2013, 13:25:19

die vorträge sind inzwischen alle online. der homematic vortrag ist hier: http://media.ccc.de/browse/congress/2013/30C3_-_5444_-_en_-_saal_g_-_201312301600_-_attacking_homematic_-_sathya_-_malli.html.

ich glaube attacking ist hier etwas hoch gegriffen... martins modul ist dagegen ja schon eine ganze invasion

nach dem winzigen nebensatz am anfang das alles nur gilt wenn die default keys nicht geändert werden hätte es eigentlich auch schon fertig sein können.

gruss
andre

Samsi · 31 Dezember 2013, 14:30:07

Hätten die Hacker die Bedienungsanleitung gelesen (was natürlich gegen die Hacker-Ehre Verstößt

), dann hätten Sie gewusst, das der Motion Detector 70 Sekunden nach einlegen da Batterie im Modus zur 'Platzierung' ist, also nur optischen Feedback per LEDs gibt, so das man ihn platzieren kann

Wenigstens sollte jetzt jedem klar sein, das man besser den AES Schlüssel in der Homeatic Config Software ändert, wenn man eine KeyMatic hat.

Ich finde es aber gut, das sie darauf eingehen, das man erkennen kann, wenn jemand anderes die gleiche Adresse verwendet. Vielleicht kann Martin so etwas auch implementieren

Grüße

martinp876 · 31 Dezember 2013, 15:15:19

Ist schon einmal angesprochen worden.
Man müsste also erkennen, wenn kommandos an das device gesendet werden, die nicht aus der eigenen Zentrale kommen.... werde einmal nachdenken...

martinp876 · 31 Dezember 2013, 15:49:55

der einfache level ist nicht so komplex.
man kann erkennen, wenn kommandos an ein device gesendet werden
- von IOs die nicht der HMId des eingetragenen IOs entsprechen (beim pairen konnte so etwas auftreten...)
- wenn kommandos mit 'unserer' HMId gesendet werden und dies nicht unsere letzte message ist.

damit wären alle config request abgedeckt sowie alle set

wir können nicht erkennen wenn jemand einen tastendruck emuliert, als einen gepeerten Sensor oder FB nachstellt.

Werde es noch zu einem Reading umbauen - ich denke es gehört zu protokol... aber es muss auch in Readings,falls jemand triggern will. In jedem Fall wird es dann auch von HMInfo erfasst werden - in der "Critical " sektion

Gruss Martin

martinp876 · 31 Dezember 2013, 16:19:40

wer testen will - aktuell gibt es keine Readings, nur logs.
Level ist 1.

Messages können provoziert werden, wenn man an ein device sendet von einem IO mit anderer HMId oder wenn man von einem anderen System sendet.
Also die HMId nicht der des eingetragenen IO device ist (SRC id faken) oder das zuletzt gesendete Kommando nicht identisch ist (2. System zum senden nutzen)

Es werden config kommandos und sets überwacht. Auch das Lesen der Config oder ein statusRequest

Gruss Martin

martinp876 · 01 Januar 2014, 20:12:28

Es ist eine Version im update morgen.
Erkannt wird, wenn ein lesen oder schreiben von einem anderen als der assignten IOId ausgeführt wird oder ein entsprechendes Kommdo von einer anderen Quelle kommt.
Das ganze ist in
protoErrIoId_<id>
protoErrIoAttack

HMInfo erkennt diese Probleme und erzeugt ein Reading, auf das getriggert werden kann.
Es werden - wie bei allen Protokoll-Anzeigen in HMinfo die Events und die betroffenen Devices angezeigt

Gruss Martin

wkarl · 02 Januar 2014, 08:06:56

Hallo Martin,

am Ende der session wird erwähnt, dass die Kollegen einen TC emulieren können und damit einen VD kontrollieren. Diese Möglichkeit ist in diesem Forum schon ein paar mal diskutiert worden. Es fehlten aber immer die Informationen bzgl der Kommunikation TC-VD.
Ich vermute mal aus dem source code (https://www.homegear.eu/index.php/Downloads) der Kollegen könnte man diese Informationen gewinnen. Aktuell bin ich zwar mit der fhem-Lösung zufrieden wie sie funktioniert, aber wer weiß wofür man dies noch gebrauchen könnte.

ciao walter

justme1968 · 02 Januar 2014, 09:39:35

den satz auf deren wiki seite das alle devices auch wenn sie nicht gepeert sind eine grüne status led zeigen statt einer roten finde dich auch interessant. gerade bei meinen nicht gepeerten fenstergriffen habe ich in letzter zeit mehr und mehr rot.

ich weiß das du einen virtuellen aktor dafür vorschlägst. aber es ging definitiv immer ohne bisher.

gruss
andre

martinp876 · 02 Januar 2014, 09:47:21

Hi Andre
verwendest du CUL oder HMLAN? Rot sollte nicht sein... Bei CUL wird es hierzu eine Nachbesserung geben. Siehe (bei CUL)
http://forum.fhem.de/index.php/topic,18189.msg120847.html#msg120847
Dass grün angezeigt wird ... es gibt auch gelb - wenn keine antwort kommt, wo keine angefragt ist (also auch bei unpeered). Sieht für mich (mit Farbschwäche) fast wie grün aus....
gehört aber nicht in diesen "attacking" thread.

@Walter
kann man sich ansehen... ist aber ein anderes Thema, nicht sicherheit wie in diesem Threat

Gruss Martin

justme1968 · 02 Januar 2014, 09:48:49

hab grad den anderes thread gesehen.

ich hab beides. cul und hmlan mit gleicher id. es scheint nicht davon abzuhängen wer reagiert.

die drei farben kann ich sehr gut unterscheiden. gelb hab ich oft wenn zu viel in der luft ist. z.b. wenn ich über fhem direkt den rolladen triggere.

gruss
andre

wkarl · 02 Januar 2014, 10:57:31

Hallo Martin,

habe einen separaten Thread (http://forum.fhem.de/index.php/topic,18193.0.html) dazu aufgemacht.

ciao walter

martinp876 · 02 Januar 2014, 12:24:50

@andré

ich hatte nicht dich mit den Farben gemeint - nur die Aussage der homegears hinterfragen wollen.

Für den fall "multi-IO" habe ich in HMLAN die timing-berechnung schon eingecheckt. Wenn auch eine CUL mitspielt fehlt noch etwas - habe ich gerade bei Rudi eingekippt. Es gibt definitiv Probleme wenn eine CUL (die ist schneller als mein HMLAN) empfängt und als IODev HMLAN festgelegt ist. HMLAN antwortet dann zu schnell. Der Zeitstempel wird, sobald Rudi es eincheckt - vereinheitlicht werden.

Gruss Martin

marc2 · 03 Januar 2014, 21:07:06

Hi !

Ich habe das heute mal ausprobiert, wobei ich mich auf den zweiten Fall beschränkt habe (HMId identisch). Funktioniert soweit wunderbar wenn sich
Beaglebone und Raspi bekriegen

. Allerdings werden die Angriffe von protoEvents nicht angezeigt (sollten sie doch, oder ?). Sollte aus meiner Sicht
noch ergänzt werden:

Code Auswählen

 --- 98_HMinfo.pm	2014-01-03 20:53:57.127509499 +0100
+++ /opt/fhem/FHEM/98_HMinfo.pm	2014-01-03 20:51:50.276209722 +0100
@@ -410,7 +410,7 @@ sub HMinfo_SetFn($@) {##################
       my ($found,$para) = HMinfo_getParam($id,
                              ,"protState","protCmdPend"
                              ,"protSnd","protLastRcv","protResnd"
-                             ,"protCmdDel","protResndFail","protNack","protIOerr");
+                             ,"protCmdDel","protResndFail","protNack","protIOerr","protErrIoAttack");
       $para =~ s/( last_at|20..-|\|)//g;
       my @pl = split "\t",$para;
       foreach (@pl){
@@ -420,26 +420,26 @@ sub HMinfo_SetFn($@) {##################
         $_ =~ s/CMDs // if ($type eq "short");
       }
       if ($type eq "short"){
-        push @paramList, sprintf("%-20s%-17s|%-10s|%-10s|%-10s#%-10s|%-10s|%-10s|%-10s",
-                      $pl[0],$pl[1],$pl[2],$pl[3],$pl[5],$pl[6],$pl[7],$pl[8],$pl[9]);
+        push @paramList, sprintf("%-25s%-17s|%-10s|%-10s|%-10s#%-10s|%-10s|%-10s|%-10s|%-10s",
+                      $pl[0],$pl[1],$pl[2],$pl[3],$pl[5],$pl[6],$pl[7],$pl[8],$pl[9],$pl[10]);
       }
       else{
-        push @paramList, sprintf("%-20s%-17s|%-18s|%-18s|%-14s|%-18s#%-18s|%-18s|%-18s|%-18s",
-                      $pl[0],$pl[1],$pl[2],$pl[3],$pl[4],$pl[5],$pl[6],$pl[7],$pl[8],$pl[9]);
+        push @paramList, sprintf("%-25s%-17s|%-18s|%-18s|%-14s|%-18s#%-18s|%-18s|%-18s|%-18s|%-18s",
+                      $pl[0],$pl[1],$pl[2],$pl[3],$pl[4],$pl[5],$pl[6],$pl[7],$pl[8],$pl[9],$pl[10]);
       }
       push @IOlist,$defs{$pl[0]}{IODev}->{NAME};
     }
 
-    my $hdr = sprintf("%-20s:%-16s|%-18s|%-18s|%-14s|%-18s#%-18s|%-18s|%-18s|%-18s",
+    my $hdr = sprintf("%-25s:%-16s|%-18s|%-18s|%-14s|%-18s#%-18s|%-18s|%-18s|%-18s|%-18s",
                              ,"name"
                              ,"State","CmdPend"
                              ,"Snd","LastRcv","Resnd"
-                             ,"CmdDel","ResndFail","Nack","IOerr");
-    $hdr = sprintf("%-20s:%-16s|%-10s|%-10s|%-10s#%-10s|%-10s|%-10s|%-10s",
+                             ,"CmdDel","ResndFail","Nack","IOerr","IOAttack");
+    $hdr = sprintf("%-25s:%-16s|%-10s|%-10s|%-10s#%-10s|%-10s|%-10s|%-10s|%-10s",
                              ,"name"
                              ,"State","CmdPend"
                              ,"Snd","Resnd"
-                             ,"CmdDel","ResndFail","Nack","IOerr") if ($type eq "short");
+                             ,"CmdDel","ResndFail","Nack","IOerr","IOAttack") if ($type eq "short");
     $ret = $cmd." done:" ."\n    ".$hdr  ."\n    ".(join "\n    ",sort @paramList)
            ;
     $ret .= "\n\n    CUL_HM queue:$modules{CUL_HM}{prot}{rspPend}";

Spricht eigentlich etwas dagegen, das ganze nicht nur auf Ebene von HMinfo als als reading zu erfassen, sondern direkt beim Device ? Aktuell
wird der Angriff zwar sofort erkannt und als "internal" am Device gespeichert. Das Reading und somit ein mögliches Notify wird erst beim nächsten
Update von HMinfo generiert/ausgelöst. Je nachdem wie häufig das update läuft also ggf. recht spät. Wenn das Reading am Device hängen würde,
könnte man sofort per Notify Gegenmaßnahmen einleiten.

Gruß, Marc

martinp876 · 04 Januar 2014, 13:09:51

Hi Marc,

nein, in protoEvents war es aktuell nicht geplant.
meine Sicht:
protoEvents zeigt protokoll-probleme an - soll eine übersichtlich und erfassbare Liste bleiben - mit "wahrscheinlichen" Problemen.
Eine Attacke ist etwas anderes, meine ich... aber vielleicht liege ich falsch. werde es überdenken.

Du kannst aber mit hm -d param ....... eine eigenen liste erstellen.

Es als Reading auszugeben hatte ich auch erwogen. Wollte erst einmal Tests abwarten.
Das mit der Verzögerung sehe ich gelassen - der update von HMinfo sollte zumindest alle paar Minuten laufen. Wenn du dir eine email schickst oder sonst was postest wirst du kaum schneller reagieren können (hier hätte ich gerne eine Diskussion - liegen ich falsch?). Eine Automatische Reaktion des Systems kann ich mir schlecht vorstellen. Ok, man könnte eine Sirene anschalten, oder Beleuchtung - das macht sinn.
Wenn es je Device "vorhanden" wirst du immer noch ein generelles notify basteln - hoffe ich.

Ein Reading ist wohl dennoch sinnvoll. Es wird sich aber nie automatisch rücksetzen/löschen - wie auch.
Vorschläge für Namen des Readings?

Gruss Martin