Objekt mit 12 Linien & >300 Geräten angegriffen; 70% der Geräte kaputtprogrammiert

[DerStandart]

Es unterbindet jeglichen Zugriff, der auf Basis der physikalischen Adressen des Gerätes funktioniert, indem es dem Absender ein "Disconnect" sendet. (Vereinfacht dargestellt)

Das Programmieren lässt sich über eine Secure Gruppenadresse aktivieren. Somit ist sichergestellt, dass nur der Besitzer der richtigen Projektdatei die Aktivierung vornehmen kann. Da es sich beim Programmierschloss physikalisch um eine Tasterschnittstelle handelt, wäre auch denkbar, die Aktivierung durch Schlüsselschalter oder einfachen Tastendruck auszulösen.

[traxanos]

Könnte man als Angreifer das disconnect nicht einfach ignorieren? Hört sich irgendwie nicht so sicher an. Oder bekommt der zu Programmierende auch ein disconnect?

[meti]

Es unterbindet jeglichen Zugriff, der auf Basis der physikalischen Adressen des Gerätes funktioniert, indem es dem Absender ein "Disconnect" sendet. (Vereinfacht dargestellt)

Und unvereinfacht?

Auf den Disconnect muss der Absender ja nicht reagieren. Ich denke ja nicht, dass bei so einem Angriff, die der aus diesem Thread zb., jemand dasitzt und die Geräte mit ETS umkonfiguriert.

Edit: traxanos war schneller 😆

[Machinehead]

Hi,

just noch eines ausgelesen:

0000000B

Vielleicht kann man das mal in einer Liste sammeln.

Mit besten Grüßen,

M.H.

[jcd]

Mit einem Programmierschloss ist man diesbezüglich wunderbar abgesichert.

Wie soll das funktionieren?
Wenn ein Gerät X über den Bus programmierbar ist kann das doch nicht verhindert werden indem man ein Gerät Y irgendwo dazu hängt. Das kann Befehle auf dem Bus doch nicht verschwinden lassen?!
Allenfalls eine vollständige Blockade/ DOS-Störfeuer halte ich für denkbar, aber dann funktioniert eben gar nichts mehr.

[tobiasr]

Das kann Befehle auf dem Bus doch nicht verschwinden lassen?!

Doch kann es. Sobald ZWEI Telegramme gleichzeitig auf dem Bus sind, ist nur noch Datenmüll da. Die TPUARTs MÜSSEN sich nach Spezifikation um Kollisionserkennung kümmern (CSMA/CD). Dieses Datenschloss schickt einmal ein Disconnect (Info an den 'normalen' User in der ETS) und wird danach (hoffentlich) Datenmüll auf dem Bus produzieren.

Eine Besonderheit stellen hier z.B: ACK Telegramme da. Hier überlagern sich die Physikalischen Adressen (wegen der exakten Gleichzeitigkeit) idr. so, dass die Stärkste (entweder die mit den meisten oder wenigsten Nullen - weiß ich gerade nicht mehr) gewinnt und die Checksummenprüfung o.ä. wird vermutlich nicht so streng sein beim ACK. Bzw. ein gleichzeitig überlagertes ACK und NAK ergeben durch die Kodierung ein NAK (physikalisch 0 gewinnt ggü. 1 bzw. umgekehrt).

[hjk]

Jegliches Programmieren oder Entladen der KNX Geräte erfolgt verbindungsorientiert.
D.h. die ETS öffnet zunächst eine Verbindung zu dem Gerät und kann dann erst schreiben.
Das MDT Sicherheitsmodul SCN-SAFE.01 überwacht den gesammten Datenverkehr und sobald eine Verbindung geöffnet wird, sendet es sofort ein Disconnect.
Damit werden alle verbindungsorientierte Funktionen unterbunden. Ein Entladen oder eine Änderung der Programmierung ist damit unmöglich. Ebenso kann kein BAU Passwort gesetzt werden. Mit Kollosion hat das nichts zu tun.

[BadSmiley]

Wenn das umprogrammieren aber nicht durch die ETS, sondern durch eine eigene Software passiert, die den Disconnect Befehl einfach ignoriert?

[hjk]

Die Geräte bekommen ja den Disconnect, danach ignorieren sie die Versuche schlichtweg.
Egal welche Software da versucht ins Memory zu schreiben, er wird eine offene Verbindung gebraucht. Wenn aber jegliche Verbindungen sofort wieder vom Sicherheitsmodul abgebaut werden, ist dies unmöglich. Einen anderen Weg ohne bestehende Verbindung gibt es nicht.

[BadSmiley]

Okay, dann habe ich es von der falschen "Richtung" gesehen, stimmt. danke für die Erklärung!

[DerStandart]

Könnte man als Angreifer das disconnect nicht einfach ignorieren?

Auf den Disconnect muss der Absender ja nicht reagieren.

In dem Moment, wo das Gerät programmiert werden soll, findet eine Punkt-zu-Punkt Verbindung statt, auf physikalischer Ebene. In dem Moment, wo der Verbindungsaufbau stattfinden soll, sendet das Programmierschloss ein "T_Disconnect" auf den Bus. Das Gerät, welches programmiert werden soll, macht in dem Moment die Verbindung wieder zu und reagiert nicht mehr. Ob der Angreifer das dann ignoriert oder nicht, ist egal.

Wie soll das funktionieren?

Gut

Wenn ein Gerät X über den Bus programmierbar ist kann das doch nicht verhindert werden indem man ein Gerät Y irgendwo dazu hängt. Das kann Befehle auf dem Bus doch nicht verschwinden lassen?!

Da verschwindet nix, aber das Programmierschloss sendet - wie oben geschrieben - einfach ein Disconnect und damit ist das Thema erledigt.

Das Alleinstellungsmerkmal vom Lingg und Janke ist momentan, dass man das Programmieren per gesicherter Gruppenadresse erlauben kann. Das heißt, ich muss im Besitz des richtigen ETS Projektes (bzw. des darin enthaltenen Schlüssel) sein, um diese Gruppenadresse korrekt und secure ansprechen zu können. Wenn ich diese Gruppenadrese unsecure anspreche, reagiert das Programmierschloss nicht.

Physikalisch gesehen ist es eine Tasterschnittstelle, d.h. ich kann die Programmierung natürlich auch per angeschlossenem Taster freischalten.

[hjk]

Unser Sicherheitsmodul ist ein Reiheneinbaugerät mit 2TE. Da ist die Taste zur Freigabe bereits eingebaut.

[andrey]

Bei mir wurde vor halben Jahr auch die BCU-Passwörter geändert durch Unbekannten bösen Angriff! Glücklicher weise sind bei mir fast MDT Produkte verbaut, nur der GIRA X1 und paar andere Hersteller wurde betroffen. Die Ports habe weiter offen gelassen, warum sollte der Angreifer nochmal die BCU-Passwörter ändern hat er etwa viel Freizeit

Am 24. Dezember habe aus der Ferne Gira X1 App im aufgemacht und alle Rollladen runterfahren lassen. Dann als ich nach Hause kam war wieder diese Aktion, alles war auf Werksreset gemacht. Diesmal habe ich dann die Ports endgültig zu gemacht!

Gestern war mein X1 nicht mehr über 1.1.1 erreichbar dann habe ich für X1 1.1.200 vergeben und und konnte ich X1 wieder programmieren, es kam auch keine Meldung mehr mit dem BCU-Password. Wie kann das eigentlich sein?

[willisurf]

Die Ports habe weiter offen gelassen

Ok, hinterher ist man immer schlauer, aber das ist schon fahrlässig.

[svenkonstanzer]

...warum sollte der Angreifer nochmal die BCU-Passwörter ändern hat er etwa viel Freizeit

ok, es war nun schon ein Einbrecher da, also schliesse ich die Haustür nicht mehr ab, die Einbrecher sprechen sich ja untereinander ab ...