(Un-)Sicherheit der OpenWB

[sonnenanbeter]

Wieso ist eigentlich der MQTT Server der OpenWB nicht mit einem Passwort abgesichert? Warum gibt es keine Zugangsbeschränkung für die Einstellungen im Webinterface? Ist für die neue API eine Authentifizierung geplant?

Ich habe eine Weile gesucht, aber keine wirkliche Infos dazu gefunden. Das Thema Sicherheit scheint bei der Entwicklung von OpenWB bisher so gut wie keine Rolle zu spielen. Das halte ich für ein Problem, denn in Zeiten von Ransomware, IoT Botnetzen und steigender Gefahr für Sabotage sollten zumindest grundlegende Sicherheitsvorkehrungen unverzichtbar zu einem modernen Produkt dazu gehören.

Es ist schon fast ein wenig putzig: mir als Besitzer wird der Zugang per SSH verweigert (damit ich nichts "kaputt" mache), aber über das Webinterface oder MQTT können aus dem lokalen Netzwerk völlig unkontrolliert beliebige Einstellungen vorgenommen und Steuerwerte geschrieben werden. Von Elektronik habe ich leider nicht so viel Ahnung, aber ist das nicht letztlich auch nicht ganz ungefährlich für den Betrieb? Wenn es schon nicht standardmäßig mitgeliefert wird, würde ich gerne selber ein paar ACLs für den Mosquitto vergeben und das Webinterface wenigstens mit einem Basic Auth absichern, aber ich komme nicht dran.

[zut]

Was hindert dich, selbst einen root-berechtigten User hinzuzufügen und dessen public key in seinem .ssh-Verzeichnis unter authorized_keys hinzuzufügen? So hab ich das getan, um bei der Entwicklung und beim Debugging zu helfen.

[sonnenanbeter]

Bei einer im Onlineshop gekauften Box kann man keine Benutzer hinzufügen. Klar, ich kann mir beim Support einen SSH Zugang erbitten oder mir selber die SD Karte heraus popeln und auf das Dateisystem zugreifen, aber das ist doch gar nicht die Frage hier.

Deine Antwort lautet also in etwa "ja, OpenWB ist unsicher und das ist..." egal? geht nicht anders?

[mrinas]

Es ist schon fast ein wenig putzig: mir als Besitzer wird der Zugang per SSH verweigert (damit ich nichts "kaputt" mache), aber über das Webinterface oder MQTT können aus dem lokalen Netzwerk völlig unkontrolliert beliebige Einstellungen vorgenommen und Steuerwerte geschrieben werden. Von Elektronik habe ich leider nicht so viel Ahnung, aber ist das nicht letztlich auch nicht ganz ungefährlich für den Betrieb? Wenn es schon nicht standardmäßig mitgeliefert wird, würde ich gerne selber ein paar ACLs für den Mosquitto vergeben und das Webinterface wenigstens mit einem Basic Auth absichern, aber ich komme nicht dran.

Über MQTT können beliebige Werte (auf gewisse Bereiche innerhalb des Brokers) geschrieben werden, das ist richtig. Damit bekommt man m.E. aber bestenfalls die openWB in einen Zustand dass sie nicht mehr, oder nicht mehr so wie gewünscht, funktioniert. Ein Szenario wo dies zu einem gefährlichen Einfluss auf die Hardware oder Elektroinstallation kann ich aktuell nicht sehen.

Zudem halte ich dieses Szenario (zielgerichtete Manipulation der Werte im Broker) für sehr unwahrscheinlich, wenngleich technisch möglich.
Sehr viel warhscheinlicher ist da scannen & ausnutzen bekannter (weil gepatchter) Sicherheitsproblemen in einer der installierten Komponenten. Hilfe ist hier m.E. ausschließlich das regelmäßige Update der Komponenten auf den aktuellsten Stand. Das müsste durch openWB sichergestellt werden, man selbst hat bei fertigen Images & Boxen keinen Zugriff darauf.

Selbst kann man zudem die Wahrscheinlichkeit für ein solches Szenario reduzieren, z.b. dadurch dass die openWB nicht direkt aus dem Internet erreichbar ist, oder ggf. in ein separates Netzwerk, z.b. Gästenetzwerk o.ä. verschoben wird um Zugriff von einer potentiell openWB auf andere Komponenten zu verhindern oder zu limitieren.

[sonnenanbeter]

Ja sicher, das ist alles richtig. Aber so ein bisschen Authentifzierung kann ja nun wirklich nicht zu viel verlangt sein. Und so richtig kompliziert drüfte die Implementierung eigentlich auch nicht sein. Oder gibt es technische Gründe? Fehlt es an Entwicklerkapazität?

Was würde denn eigentlich passieren, wenn die Leistung des Ladepunktes böswillig höher konfiguriert wird, als die Zuleitung verkraftet? Oder inkompatible Einstellungen zum Fahrzeug vorgenommen werden?

Für ein kommerzielles Produkt, das auch an ganz normale Endanwender verkauft wird, ist gar keine Sicherheitsvorkehrung aus meiner Sicht einfach mangelhaft.

[aiole]

Ja sicher, das ist alles richtig. Aber so ein bisschen Authentifzierung kann ja nun wirklich nicht zu viel verlangt sein. Und so richtig kompliziert drüfte die Implementierung eigentlich auch nicht sein. Oder gibt es technische Gründe? Fehlt es an Entwicklerkapazität?

Du kannst passende PR zuarbeiten, die dann vom Team geprüft und wenn ok gemergt werden. Genau dafür steht das System open source auf Github.
Auch an fähigen Entwickler:innen besteht sicher Interesse. Kannst du beides über support@openwb.de einbringen (Auch wenn's wider Erwarten länger dauert - alle Nutzer:innen freuen sich über Verbesserungen.).

Was würde denn eigentlich passieren, wenn die Leistung des Ladepunktes böswillig höher konfiguriert wird, als die Zuleitung verkraftet? Oder inkompatible Einstellungen zum Fahrzeug vorgenommen werden?

a) Falls das Lastmanagement manipuliert würde, löst bei tatsächlicher A-Überschreitung dein LSS aus - keine Gefahr

b) Eine WB bietet Strom an. D.h. es ist egal ob 16A oder 32A angeboten werden - ein normaler OBC mit 11kW nimmt nur 3x 16A. Des Weiteren sind die EV bezüglich WB/Ladung hervorragend abgesichert. Kann also nichts passieren. Die Angst kann man EV-Neueinsteiger:innen getrost nehmen.

[sonnenanbeter]

Okay, das ist also alles angeblich gar nicht schlimm und darum kann das so bleiben, findet ihr.

Nach einem Blick ins GitHub kann ich meine Frage nach dem Warum nun auch selbst beantworten: die Webapp ist im Kern ein MQTT Client in JavaScript und daher ist anonymer Zugriff in den Mosquitto ACLs konfiguriert.

In dieser Architektur ist eine sichere Authentifizierung dann wohl doch nur relativ umständlich zu integrieren und jeder Zugriff auf die Webapp selbst müsste gesichert werden.

Ein interessantes Gesamtkunstwerk, dieses OpenWB

[openWB]

Die Benutzerverwaltung mit verschiedenen Rechten steht auf der Agenda.
Dennoch muss man klar kommunizieren und hinterfragen was du damit sicherstellen möchtest.

Wenn es darum geht Manipulation zu vermeiden musst du ja eine Stufe drunter schon ansetzen.
Die openWB liest Daten von anderen Geräten, Zählern, usw. Aus.
Oft geschieht dies per ModbusTCP oder Rest APIs.
Unverschlüsselt und ohne Authentifizierung. Das können wir nicht beeinflussen. Da hilft nur ein gekapseltes Netz der Komponenten. In einem EFH mit normaler Netzwerkhardware nicht umsetzbar.

Ist ein Angreifer in deinem Netz und möchte eine Überlast erzeugen kann er hier ansetzen und manipulierte Daten bereitstellen.
Heisst du musst auf diesem Layer schon vor Zugriffsschutz sorgen. Das gilt im übrigen für alle IOT Geräte. Ist ein Angreifer so weit hast du aber denke ich andere Probleme als das dein Auto lädt obwohl es nicht soll oder andersrum.

Zugangsschutz zum Netzwerkkabel ist wenn die openWB außen montiert ist auch ein Thema. Das musst du ein Layer drunter sicherstellen. Die Frage ist wie paranoid du bist und welche Risiken bestehen.

Zumindest für die Hardware und dein Fahrzeug keine.

Im Firmenumfeld sollte ohnehin ein SysAdmin für Netzsicherheit sorgen.

In dieser Architektur ist eine sichere Authentifizierung dann wohl doch nur relativ umständlich zu integrieren und jeder Zugriff auf die Webapp selbst müsste gesichert werden.

Der verschlüsselte Zugriff ist schon jetzt möglich. Die Authentifizierung am Client folgt noch.
Aber nochmal, das ist nur ein Baustein in der Gesamtinfrastruktur.


Die Frage ist wie weit du das treiben möchtest.
Der übliche Endandwender ist erfahrungsgemäß eher an Einfachheit interessiert.

[aiole]

Okay, das ist also alles angeblich gar nicht schlimm und darum kann das so bleiben, findet ihr.

Da hast du mich komplett missverstanden. Mein Text war ernst gemeint.

[sonnenanbeter]

Ich habe verstanden, dass es in Bezug auf die Elektrik kein Risiko gibt. Und das man natürlich gerne Patches einreichen darf.

Außerdem ist eine Benutzerrechte-Feature in Planung. Und Sicherheit muss sowieso ganzheitlich gedacht werden. Da wäre eine Mosquitto ACL auch nur ein kleiner Baustein.