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 (http://events.ccc.de/congress/2013/Fahrplan/events/5444.html)
Mirror:
http://ccc.devsn.se/congress/2013/Fahrplan/events/5444.html (http://ccc.devsn.se/congress/2013/Fahrplan/events/5444.html)
Gibts auch als Livestream über http://streaming.media.ccc.de/ (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
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 (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
Hätten die Hacker die Bedienungsanleitung gelesen (was natürlich gegen die Hacker-Ehre Verstößt :P), 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
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...
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
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
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
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 (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
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
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
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
Hallo Martin,
habe einen separaten Thread (http://forum.fhem.de/index.php/topic,18193.0.html (http://forum.fhem.de/index.php/topic,18193.0.html)) dazu aufgemacht.
ciao walter
@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
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 ;D. Allerdings werden die Angriffe von protoEvents nicht angezeigt (sollten sie doch, oder ?). Sollte aus meiner Sicht
noch ergänzt werden:
--- 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
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
Hi Martin!
--
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.
--
genau deshalb wäre eine umgehende Benachrichtigung doch sehr wichtig. Wenn jemand meine Türe öffnen möchte, egal ob er es schafft oder nicht, würde ich doch gerne gleich Alarm auslösen und nicht in ein paar Minuten :-)
Falls das möglich ist, bin ich also sehr dafür, dass gleich ein notify auslöst.
Liebe Grüße
Martin
p.s.: name: hm_sabotage an die hm vorhandenen angelehnt?
ich habe jetzt
sabotageAttackId
sabotageAttack
als readings definiert. da mit kann man ein notify bauen wie
define sabo notify .*:sabotage.* ....
da sind dann alle devices und alle sabotage errors drin neben den Beiden noch das cover, falls vorhanden
kommentare?
Hi Martin,
klingt gut, reagiert das jetzt gleich oder mit den x Minuten verzögert?
p.s.: bitte schau dir mal meine Mails bzgl. Rauchmelder durch, danke! :-)
Hi Martin
reagiert sofort bei den devices.
HMInfo ist verzögert wie vor.
Gruss Martin
hallo martin,
ich teste gerade angriffe auf mein system mit externem fhem und cul auf einem laptop. auf dem spy-system ist eigentlich nur der cul und eine vccu definiert. dann habe ich mir eine von der vccu "eingesammelte" unknown-id genommen und auf verdacht mit dieser id ein hm-cc-tc definiert. ein getconfig auf diese id hat mir dann sämtliche einstellungen des devices generiert. soweit eigentlich nichts aufregendes.
aber auf dem zu schützenden opfer-system wurde keine sabotage-meldung generiert, obwohl dort hmlan und hmusb die ausspähung wahrgenommen haben. siehe log. aus diesem thread habe ich herausgelesen, dass getconfig eigentlich erkannt werden sollte. oder ist der thread doch zu alt und es hat sich etwas geändert?
########## spy-system ######################################################
2015.06.06 17:40:16 4: CUL_Parse: cul868 A 0C 1D 8670 1936FF 000000 00CC44F4 -80
2015.06.06 17:40:16 3: CUL_HM set test01 statusRequest
2015.06.06 17:40:16 4: CUL_send: cul868As 09 1E A112 1ACE1F 1936FF
2015.06.06 17:42:53 4: CUL_Parse: cul868 A 0C 1E 8670 1936FF 000000 00CC43F7 -78.5
2015.06.06 17:42:53 4: CUL_send: cul868As 09 1F A112 1ACE1F 1936FF
2015.06.06 17:42:53 4: CUL_Parse: cul868 A 0A 1F 8002 1936FF 1ACE1F 00F6 -79
2015.06.06 17:42:53 4: CUL_send: cul868As 10 20 A001 1ACE1F 1936FF 00040000000000
2015.06.06 17:42:53 4: CUL_Parse: cul868 A 1A 20 8010 1936FF 1ACE1F 020100020105850A1A0BCE0C1F0F000000F7 -78.5
2015.06.06 17:42:54 4: CUL_send: cul868As 0B 21 A001 1ACE1F 1936FF 010E
2015.06.06 17:42:54 4: CUL_Parse: cul868 A 0E 21 8002 1936FF 1ACE1F 01020C004CF6 -79
########## opfer-system #########################################################
2015.06.06 17:40:16.744 0: HMLAN_Parse: hmlan1 R:E1936FF stat:0000 t:0207EE74 d:FF r:FFC7 m:1D 8670 1936FF 000000 00CC44
2015.06.06 17:40:16.777 0: HMLAN_Parse: hmusb1 R:E1936FF stat:0000 t:001C531D d:FF r:FFB8 m:1D 8670 1936FF 000000 00CC44
2015.06.06 17:40:16.959 0: HMLAN_Parse: hmlan1 R:E1ACE1F stat:0000 t:0207EF4B d:FF r:FFB8 m:1E A112 1ACE1F 1936FF
2015.06.06 17:40:16.977 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:001C53F3 d:FF r:FFB0 m:1E A112 1ACE1F 1936FF
2015.06.06 17:42:53.497 0: HMLAN_Parse: hmlan1 R:E1936FF stat:0000 t:020A52D9 d:FF r:FFC7 m:1E 8670 1936FF 000000 00CC43
2015.06.06 17:42:54.001 0: HMLAN_Parse: hmlan1 R:E1ACE1F stat:0000 t:020A5377 d:FF r:FFB8 m:1F A112 1ACE1F 1936FF
2015.06.06 17:42:54.016 0: HMLAN_Parse: hmlan1 R:E1936FF stat:0000 t:020A53FB d:FF r:FFC7 m:1F 8002 1936FF 1ACE1F 00
2015.06.06 17:42:54.038 0: HMLAN_Parse: hmlan1 R:E1ACE1F stat:0000 t:020A54B0 d:FF r:FFB8 m:20 A001 1ACE1F 1936FF 00040000000000
2015.06.06 17:42:54.055 0: HMLAN_Parse: hmusb1 R:E1936FF stat:0000 t:001EB76B d:FF r:FFBA m:1E 8670 1936FF 000000 00CC43
2015.06.06 17:42:54.081 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:001EB809 d:FF r:FFAF m:1F A112 1ACE1F 1936FF
2015.06.06 17:42:54.095 0: HMLAN_Parse: hmusb1 R:E1936FF stat:0000 t:001EB88C d:FF r:FFB9 m:1F 8002 1936FF 1ACE1F 00
2015.06.06 17:42:54.116 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:001EB942 d:FF r:FFB0 m:20 A001 1ACE1F 1936FF 00040000000000
2015.06.06 17:42:54.143 0: HMLAN_Parse: hmlan1 R:E1936FF stat:0000 t:020A553A d:FF r:FFC7 m:20 8010 1936FF 1ACE1F 020100020105850A1A0BCE0C1F0F000000
2015.06.06 17:42:54.162 0: HMLAN_Parse: hmusb1 R:E1936FF stat:0000 t:001EB9CC d:FF r:FFB9 m:20 8010 1936FF 1ACE1F 020100020105850A1A0BCE0C1F0F000000
2015.06.06 17:42:54.807 0: HMLAN_Parse: hmlan1 R:E1ACE1F stat:0000 t:020A57F7 d:FF r:FFB8 m:21 A001 1ACE1F 1936FF 010E
2015.06.06 17:42:54.827 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:001EBC89 d:FF r:FFB0 m:21 A001 1ACE1F 1936FF 010E
2015.06.06 17:42:54.939 0: HMLAN_Parse: hmlan1 R:E1936FF stat:0000 t:020A587B d:FF r:FFC7 m:21 8002 1936FF 1ACE1F 01020C004C
2015.06.06 17:42:54.975 0: HMLAN_Parse: hmusb1 R:E1936FF stat:0000 t:001EBD0E d:FF r:FFB9 m:21 8002 1936FF 1ACE1F 01020C004C
noch ein list des ausgespähten devices. es ist zwar ein sabotage-reading vorhanden. der timestamp ist aber schon älter. war vor meinem versuch identisch.
Internals:
DEF 1936FF
IODev hmusb1
LASTInputDev hmusb1
MSGCNT 235
NAME Thermostat.Bad
NR 226
NTFY_ORDER 50-Thermostat.Bad
STATE Tsoll:6.0°C, Tist:19.6°C, Hist:68%, Mode:central, Bat:ok
TYPE CUL_HM
channel_01 Thermostat.Bad_Weather
channel_02 Thermostat.Bad_Climate
channel_03 Thermostat.Bad_WindowRec
hmlan1_MSGCNT 118
hmlan1_RAWMSG E1936FF,0000,02E9DE30,FF,FFC6,7E86701936FF00000000C444
hmlan1_RSSI -58
hmlan1_TIME 2015-06-06 21:47:01
hmusb1_MSGCNT 117
hmusb1_RAWMSG E1936FF,0000,00FE3A4E,FF,FFBA,7E86701936FF00000000C444
hmusb1_RSSI -70
hmusb1_TIME 2015-06-06 21:47:01
lastMsg No:7E - t:70 s:1936FF d:000000 00C444
protLastRcv 2015-06-06 21:47:01
protResnd 2 last_at:2015-06-06 17:11:42
protSnd 7 last_at:2015-06-06 17:12:45
protState CMDs_done
rssi_at_hmlan1 avg:-57.65 min:-59 max:-57 lst:-58 cnt:118
rssi_at_hmusb1 avg:-70.06 min:-74 max:-67 lst:-70 cnt:117
rssi_hmusb1 avg:-70 min:-76 max:-68 lst:-76 cnt:4
.userreadings:
Humidityabsolut:
TIME 2015-06-06 21:39:25
modifier none
perlCode {AbsoluteFeuchte(ReadingsVal($name,"measured-temp",0),ReadingsVal($name,"humidity",0))}
t 1433619565.99152
trigger (measured-temp|humidity)
value 11.5
Readings:
2014-11-02 11:11:50 .D-devInfo 00FFFF
2014-11-02 11:11:50 .D-stc 58
2015-06-06 21:47:01 .protLastRcv 2015-06-06 21:47:01
2015-06-06 17:21:08 Activity alive
2015-06-06 17:42:54 CommandAccepted yes
2014-11-02 11:11:50 D-firmware 2.1
2014-11-02 11:11:50 D-serialNr JEQ0044345
2014-11-02 11:14:18 PairedTo 0x1ACE1F
2014-11-02 11:14:18 R-backlOnMode auto
2014-11-02 11:14:18 R-backlOnTime 25
2014-11-02 11:14:18 R-btnLock off
2014-11-02 11:14:18 R-burstRx off
2014-11-02 11:14:18 R-pairCentral 0x1ACE1F
2014-11-02 11:14:18 RegL_00: 01:00 02:01 05:85 0A:1A 0B:CE 0C:1F 0F:00 00:00
2015-06-06 17:42:54 battery ok
2014-11-02 11:14:25 controlMode central
2014-11-02 11:14:25 day-temp 16.5 C
2014-11-02 11:14:25 decalcDay Sat
2015-06-06 17:42:54 desired-temp 6.0
2014-11-02 11:14:25 displayMode temp-only
2014-11-02 11:14:25 displayTemp setpoint
2014-11-02 11:14:25 displayTempUnit celsius
2015-06-06 21:47:01 humidity 68
2015-06-06 21:39:25 humidityAbsolut 11.5
2015-06-06 21:39:26 humidityAbsolutTrend →→
2015-06-06 21:47:01 measured-temp 19.6
2014-11-02 11:14:25 night-temp 6 C
2014-11-02 11:14:25 party-temp 20 C
2015-05-31 03:40:35 sabotageAttack ErrIoAttack cnt:2
2015-06-06 21:47:01 state T: 19.6 H: 68
2015-06-06 00:01:57 time-request -
Helper:
HM_CMDNR 126
cSnd 011ACE1F1936FF020E,011ACE1F1936FF030E
mId 0039
rxType 140
Bm:
Cul_hm_get:
cnt 1
dmx 0
max 1
tot 1
mAr:
HASH(0x13f1538)
Thermostat.Bad
?
Cul_hm_set:
cnt 40
dmx 0
max 11
tot 303
mAr:
HASH(0x13f1538)
Thermostat.Bad
?
Io:
newChn +1936FF,00,01,00
nextSend 1433620021.86479
rxt 2
vccu ccu
p:
1936FF
00
01
00
prefIO:
hmusb1
Mrssi:
mNo 7E
Io:
hmlan1 -58
hmusb1 -68
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
Rssi:
At_hmlan1:
avg -57.6525423728814
cnt 118
lst -58
max -57
min -59
At_hmusb1:
avg -70.0683760683761
cnt 117
lst -70
max -67
min -74
Hmusb1:
avg -70
cnt 4
lst -76
max -68
min -76
Attributes:
IODev hmusb1
IOgrp ccu:hmusb1
actCycle 000:10
actStatus alive
alias 10. Thermostat
autoReadReg 5_readMissing
comment Lueftung
event-on-change-reading .*
expert 2_full
firmware 2.1
group Heizung.Bad
model HM-CC-TC
msgRepeat 3
room 40_Bad,98_Ventile
serialNr JEQ0044345
stateFormat Tsoll:desired-temp°C, Tist:measured-temp°C, Hist:humidity%, Mode:controlMode, Bat:battery
subType thermostat
gruss frank
sabotage wird gemeldet, wenn ein veränderndes Kommando gefunden wird.
getConfig liest nur - ebenso wie statusRequest. Das wird nicht alarmiert.
Jedes setzen sollte als Angriff erkannt werden.
Zitat von: martinp876 am 07 Juni 2015, 11:54:10
sabotage wird gemeldet, wenn ein veränderndes Kommando gefunden wird.
getConfig liest nur - ebenso wie statusRequest. Das wird nicht alarmiert.
Jedes setzen sollte als Angriff erkannt werden.
alles klar.
ein aktives auslesen meiner devices von unbefugten würde ich aber schon als eindeutige atacke auf mein system werten. eventuell die vorbereitung eines direkten angriffs durch setzen/verändern. denkbar wäre ja auch ein "lahmlegen" der devices durch permanentes absetzen von getconfig/statusrequest. quasi ein überlastungsangriff (DoS).
wäre so eine erkennung zu aufwändig, oder bist du der ansicht, dass das ok ist?
#############################################################################
edit: das setzen einer neuen desired-temp wurde gerade auch nicht als attacke gemeldet.
edit2: registersetzen funktioniert auch ohne meldung. es wurden nicht mal die register-readings aktualisiert. erst ein getconfig auf dem opfer-system zeigt auch hier die aktuellen registerwerte. aber weiterhin kein meldung.
########## angreifer ########################################################
2015.06.07 16:06:43 4: CUL_Parse: cul868 A 0C 2F 8670 1936FF 000000 00B739F6 -79
2015.06.07 16:06:44 4: CUL_send: cul868As 09 30 A112 1ACE1F 1936FF
2015.06.07 16:06:44 4: CUL_Parse: cul868 A 0A 30 8002 1936FF 1ACE1F 00F5 -79.5
2015.06.07 16:06:44 4: CUL_send: cul868As 10 31 A001 1ACE1F 1936FF 00050000000000
2015.06.07 16:06:44 4: CUL_Parse: cul868 A 0A 31 8002 1936FF 1ACE1F 00F6 -79
2015.06.07 16:06:44 4: CUL_send: cul868As 19 32 A001 1ACE1F 1936FF 00080100020105840A1A0BCE0C1F0F01
2015.06.07 16:06:44 4: CUL_Parse: cul868 A 0A 32 8002 1936FF 1ACE1F 00F5 -79.5
2015.06.07 16:06:45 4: CUL_send: cul868As 0B 33 A001 1ACE1F 1936FF 0006
2015.06.07 16:06:45 4: CUL_Parse: cul868 A 0A 33 8002 1936FF 1ACE1F 00F5 -79.5
2015.06.07 16:06:45 4: CUL_send: cul868As 10 34 A001 1ACE1F 1936FF 00040000000000
2015.06.07 16:06:45 4: CUL_Parse: cul868 A 1A 34 8010 1936FF 1ACE1F 020100020105840A1A0BCE0C1F0F010000F6 -79
########## opfer ##########################################################
2015.06.07 16:06:41.924 0: HMLAN_Parse: hmlan1 R:E1936FF stat:0000 t:06D8C7FA d:FF r:FFC7 m:2F 8670 1936FF 000000 00B739
2015.06.07 16:06:41.955 0: HMLAN_Parse: hmusb1 R:E1936FF stat:0000 t:04ECFE0E d:FF r:FFB5 m:2F 8670 1936FF 000000 00B739
2015.06.07 16:06:42.095 0: HMLAN_Parse: hmlan1 R:E1ACE1F stat:0000 t:06D8C8A6 d:FF r:FFB7 m:30 A112 1ACE1F 1936FF
2015.06.07 16:06:42.128 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:04ECFEBB d:FF r:FFAE m:30 A112 1ACE1F 1936FF
2015.06.07 16:06:42.227 0: HMLAN_Parse: hmlan1 R:E1936FF stat:0000 t:06D8C92A d:FF r:FFC7 m:30 8002 1936FF 1ACE1F 00
2015.06.07 16:06:42.256 0: HMLAN_Parse: hmusb1 R:E1936FF stat:0000 t:04ECFF3F d:FF r:FFB5 m:30 8002 1936FF 1ACE1F 00
2015.06.07 16:06:42.423 0: HMLAN_Parse: hmlan1 R:E1ACE1F stat:0000 t:06D8C9ED d:FF r:FFB7 m:31 A001 1ACE1F 1936FF 00050000000000
2015.06.07 16:06:42.448 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:04ED0001 d:FF r:FFAE m:31 A001 1ACE1F 1936FF 00050000000000
2015.06.07 16:06:42.547 0: HMLAN_Parse: hmlan1 R:E1936FF stat:0000 t:06D8CA6A d:FF r:FFC7 m:31 8002 1936FF 1ACE1F 00
2015.06.07 16:06:42.576 0: HMLAN_Parse: hmusb1 R:E1936FF stat:0000 t:04ED007E d:FF r:FFB4 m:31 8002 1936FF 1ACE1F 00
2015.06.07 16:06:42.741 0: HMLAN_Parse: hmlan1 R:E1ACE1F stat:0000 t:06D8CB2B d:FF r:FFB6 m:32 A001 1ACE1F 1936FF 00080100020105840A1A0BCE0C1F0F01
2015.06.07 16:06:42.768 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:04ED0140 d:FF r:FFAD m:32 A001 1ACE1F 1936FF 00080100020105840A1A0BCE0C1F0F01
2015.06.07 16:06:42.859 0: HMLAN_Parse: hmlan1 R:E1936FF stat:0000 t:06D8CBA2 d:FF r:FFC7 m:32 8002 1936FF 1ACE1F 00
2015.06.07 16:06:42.884 0: HMLAN_Parse: hmusb1 R:E1936FF stat:0000 t:04ED01B6 d:FF r:FFB6 m:32 8002 1936FF 1ACE1F 00
2015.06.07 16:06:43.039 0: HMLAN_Parse: hmlan1 R:E1ACE1F stat:0000 t:06D8CC55 d:FF r:FFB6 m:33 A001 1ACE1F 1936FF 0006
2015.06.07 16:06:43.058 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:04ED026A d:FF r:FFAE m:33 A001 1ACE1F 1936FF 0006
2015.06.07 16:06:43.169 0: HMLAN_Parse: hmlan1 R:E1936FF stat:0000 t:06D8CCD7 d:FF r:FFC7 m:33 8002 1936FF 1ACE1F 00
2015.06.07 16:06:43.194 0: HMLAN_Parse: hmusb1 R:E1936FF stat:0000 t:04ED02EB d:FF r:FFB6 m:33 8002 1936FF 1ACE1F 00
2015.06.07 16:06:43.354 0: HMLAN_Parse: hmlan1 R:E1ACE1F stat:0000 t:06D8CD90 d:FF r:FFB5 m:34 A001 1ACE1F 1936FF 00040000000000
2015.06.07 16:06:43.376 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:04ED03A4 d:FF r:FFAE m:34 A001 1ACE1F 1936FF 00040000000000
2015.06.07 16:06:43.493 0: HMLAN_Parse: hmlan1 R:E1936FF stat:0000 t:06D8CE1B d:FF r:FFC7 m:34 8010 1936FF 1ACE1F 020100020105840A1A0BCE0C1F0F010000
2015.06.07 16:06:43.514 0: HMLAN_Parse: hmusb1 R:E1936FF stat:0000 t:04ED042F d:FF r:FFB6 m:34 8010 1936FF 1ACE1F 020100020105840A1A0BCE0C1F0F010000
probier noch einmal - sollte jetzt gehen.
Was kritisch sein könnte ist, dass "trigger", also Button press nicht abgefangen werden können. FHEM weiss nicht, war das gesendet hat.
während du geantwortet hast, hatte ich meinen post editiert. registeränderungen wurden auch nicht erkannt.
wiegesagt - probier mal mit der Version in SVN
Zitat von: martinp876 am 07 Juni 2015, 19:45:17
wiegesagt - probier mal mit der Version in SVN
grundsätzlich funktioniert jetzt desired-temp und regset.
probleme gibt es aber nach shutdown restart. da melden ohne atacke so gut wie alle devices diverse atacken. im folgenden log schreibt ein notify jeweils eine logzeile, wenn das attack reading aktualisiert wird. die ersten beiden atacken auf thermostat.bad(1936FF) sind echte atacken. der rest sollte falsch laufen.
ps: mein notify ist aber ein ziemlicher zeitfresser sehe ich gerade.
gruss frank
noch ein versuch...
das sieht jetzt verdammt gut aus, danke. keine falschmeldungen bisher und desired-temp und regset werden sauber erkannt. komischerweise nun auch statusrequest und getconfig. das kann ja nur zufall sein. ;)
trotzdem hätte ich noch ein paar kleine wünsche.
1. im attack-reading gibt es ja den counter. dieser wird aber nach einem shutdown restart mit der ersten attack-meldung zurückgesetzt. also die alten werte überleben den restart, aber der counter fängt dann bei einer neuen attacke mit 1 an. wäre es nicht schöner, wenn der counter auch nach restart weiterzählt?
2. bei einem fremdsetzen von desired-temp ändert sich auch das reading desired-temp im opfer-device. das ist auch gut so, da man sieht, was aktuell eingestellt ist. im gegensatz dazu verhält es sich mit den register-readings leider anders. hier wird keine änderung, die durch den angreifer erfolgt ist, angezeigt. lediglich das attack-reading lässt erahnen, dass etwas passiert ist. hier sollte man verbessern, meine ich. entweder die readings ebenfalls ändern. die daten sollten ja empfangen worden sein. oder vielleicht besser, ein automatisches getconfig anschmeissen, um auf jeden fall alle änderungen in fhem zu haben.
3. wäre es denkbar im attack-reading einen näheren hinweis auf die attacke zu bekommen. zb "attack:getConfig" oder "attack:regSet" neben dem counter? und/oder die auslösende raw-message?.
gruss frank
hallo martin,
ich habe mein system jetzt mal mit einer message attackiert, die ein ack provoziert. im sekundentakt wird mit einem simplen at eine weather-event-message vom angreifer gesendet. das funktioniert mit jeder beliebigen id des opfer-systems an die zentrale adressiert. das assignte opfer-io antwortet immer brav, bis es nach kurzer zeit im status overload ist. nach einer weile waren sogar meine 2 io ausser gefecht gesetzt, da sie über eine vccu gemanaged werden. der angreifer kann sogar den overload erkennen, wenn die ack irgendwann nicht mehr gesendet werden.
wäre es möglich eine erkennung für diese DoS-angriffe zu implementieren? dann könnte man diesen angriff eventuell abwehren/entschärfen, indem man das assigning des devices "aufhebt", mit dessen id die message gesendet wird. zb durch eine neue option für das attribut IOgrp => "ccu:none". oder sogar ein automatisches "de-assigning". dadurch würde man zwar das device "verlieren", aber die io würden noch funktionieren.
gruss frank
1) sollte gelöst sein - probier mal
2) könnte evtl im autoReadReg erweitert werden. Also ein automatisches getConfig einbauen. muss ich einmal drüber schlafen
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
ein automatisches deassign halte ich für gewagt.
ein deasign kann man machen indem man das attribut IOGrp ändert (hoffe ich :) )
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.
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.
Zitat1) sollte gelöst sein - probier mal
version 8748, eben über update, leider noch nicht.
Zitat3) 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.
Zitatein 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.
Zitatein 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.
Zitatwann 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.
Zitatinsgesamt 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. ;)