ioBroker unsicher?

[WildGuy]

Hi,

ich habe jetzt diverse Webseiten durchforstet und mich ein bisschen bzgl. ioBroker schlau gemacht, scheint ja eine ganz nette Geschichte zu sein, aber leider habe ich auch immer wieder gelesen, dass ioBroker (?) in manchen Fällen eine Übernahme von NAS-Geräten ermöglicht hat. In welchem Zusammenhang ist das denn zu verstehen bzw. was ist da das Problem? Ist ioBroker so unsicher, oder wurden die Systeme nicht richtig konfiguriert? Falls letzteres - wo lag das Problem?

 

[rednag]

Hab das ganze nur am Rande mitbekommen.
Laut diverser Forenbeitrage gibts es wohl hier keinen singulären Einstiegspunkt.
Ich denke es ist ein Zusammenspiel von offenen Ports, Passwortstärke und der Konfiguration von ioBroker.
Alternativen wären ioBroker Cloud oder VPN.
Kenne die ioBroker Cloud, bzw. das ganze ioBroker nicht wirklich. Broken by Design

 

[the other]

Moinsen,
wenn ich mich recht entsinne war es ein Zusammenspiel diverser Faktoren:
zum einen wurde iobroker installiert, anschließend das standardisierte Passwort des Admins NICHT abgeändert. Zum anderen war ein Zugriff von außen via PWL erlaubt. Und so war dann der Weg recht kurz, schien es, dass sich jemand auf die Standardsport klopfend mit den nicht individuell vergebenen Credentials zuerst auf den iobroker schalten konnte (weil direkt von extern erreichbar gemacht) und sich dann von dort weiter aufs NAS gehangelt hat.
Was ich sagen will: es ist nicht unbedingt das Programm selber, sondern (mal wieder) der Benutzer vor dem Bildschirm, der hier sein Unheil anrichtet.
Warum sollte man unbedingt auf den iobroker von außerhalb zugreifen? Warum (wenn es denn SOOO wichtig ist) nicht über einen sichereren Zugangsweg (vpn?)? Warum nicht die Credentials ändern und härten? usw...

Mit so einer Herangehensweise wird vermutlich nahezu JEDES Stück software zu einem potentiellen Einfallstor...
jm2c

 

[EOL15]

Warum sollte man unbedingt … von außerhalb zugreifen?

Weil es geht!

Warum … nicht über einen sichereren Zugangsweg (vpn?)?

Weil das viel zu umständlich und aufwendig ist!

Warum nicht die Credentials ändern und härten?

Blödsinn! Für was?

Mit so einer Herangehensweise wird vermutlich nahezu JEDES Stück software zu einem potentiellen Einfallstor...

Jetzt übertreibst du aber!

 

[blurrrr]

"Einfach so" wird vermutlich nix unsicher sein (ausser man konfiguriert Dinge "falsch", oder eben "garnicht"), ansonsten würde es die Software vermutlich erst garnicht geben. Nutze es selbst zwar nicht und hab es auch nur am Rande mitbekommen, aber irgendwie so, wie @the other es beschrieben hat, war es wohl. Wenn Du es also einfach nur lokal laufen lässt (ohne Freigabe nach aussen) un die Zugangsdaten alle "vernünftig" änderst, sollte einem internen Betrieb eigentlich nix im Wege stehen.

 

[WildGuy]

Danke für die Erläuterungen. Dann scheint es ja wohl doch eher so, als hätte man a) entweder irgendwas falsch gemacht, oder b) die Standard-Passwörter nicht geändert. Das man dadurch dann aber auch direkt auf das System kommt, finde ich schon nicht ohne... Denke, ich werde mir das erstmal anschauen und falls es mir zusagt, läuft es dann rein intern. Mal besser nichts riskieren...

 

[Ulfhednir]

Den potentiellen Angriffsvektor hatte ich in einem anderen Forum bereits beschrieben. Die Verbindung zwischen den NAS-Geräten (Synology) und ioBroker hat(te) folgenden Rückschluss ergeben:
Für den Hack sind zwei Komponenten notwendig:
1.) die ioBroker-Instanz ist mittels Portfreigabe öffentlich zugänglich (was ohnehin ein No-Go ist)
2.) in der ioBroker-Instanz der Synology-Adapter installiert

Zum Zeitpunkt der Übernahme wurde das Kennwort für das Synology-Konto unverschlüsselt in einer Konfigurationsdatei durch den Synology-Adapter gespeichert.
Ein findiger Angreifer brauchte so nun also lediglich das Internet auf offene ioBroker-Installationen abklappern und wiederum die Konfigurationsdatei auslesen.
In der Regel dürfte dort ein Konto mit administrativen Rechten hinterlegt sein - der Rest dürfte halbwegs klar sein.

Glücklicherweise hat der russische Entwickler "relativ" zeitnah auf mein Anliegen reagiert und eine Verschlüsselung eingebaut, sodass das Auslesen in Klartext nicht mehr möglich ist.

 

[the other]

Moinsen und willkommen @Ulfhednir
...schön, dass du auch am Start bist.
Ich erinnere mich an deinen Post, ging ja damals wild zur Diskussion, das Thema.
Ein paar Gedanken in diesem Zusammenhang:

Allgemein ist es in diversen Foren zum Thema "smart home" immer wieder anzutreffen, dass...
...diverse Geräte im Heimnetz mit einer Integration eingebunden werden, auch wenn dafür Administratorenrechte vergeben werden müssen (da hat dann die Zentrale für das IoT Gelöt ein admin-Konto oder aber die nötigen admin credentials für das NAS...naja.)
...die in der "smart home"-Zentrale benötigten credentials (für diverse Dienste / Anwendungsszenarien ja durchaus wichtig) einfach so, im plaintext, in den Konfigurationsdateien stehen.
...vorhanden Schutzmechanismen, um die credentials zu verbergen (zumindest in der Konfiguration der Dienste), einfach ignoriert werden.

Schönes Beispiel dafür: home assistant
Klar kann man sein zB synology NAS da integrieren (um definierte Werte auszulesen), dann ist aber ein admin Konto erforderlich. Für mich persönlich ein no-go. Muss aber natürlich jede*r selbst wissen.
Immerhin bietet die Konfiguration bei home assistant die Möglichkeit, dass bei der Eintragung von credentials ein sogenanntes "secret" genutzt wird. Dafür bietet home assistant eine extra Datei, in welcher die credentials ganz normal eingetragen werden und mit einem "geheimen" Namen ein Alias bekommen. Nur dieses Alias sollte dann natürlich auch in die eigentliche Konfiguration eingetragen werden.
Also hier dann nicht für zB die Anmeldung bei einem Wetterdienst im Netz eintragen "Name: the other Passwort:1234" sondern nach Anlegen der Aliasverknüpfung diese nutzen.

Wird (wie immer wieder mal den screenshots zu entnehmen ist) leider oft nicht umgesetzt.
jm2c