Willkommen im Loxone Community Forum. Um alle Funktionen nutzen und sehen zu können, registriere dich bitte zuerst. Dies gilt auch für das herunterladen von Dateien.
Sicherheitslücke: Hintertür im Smart Home von Loxone [Bericht auf Heise Online]
Sicherheitslücke: Hintertür im Smart Home von Loxone [Bericht auf Heise Online]
Hallo zusammen,
um den mannigfaltigen Diskussionen um die Sicherheit der von außen erreichbaren Loxone-Installationen noch einen drauf zu setzen, habe ich soeben diesen Artikel auf Heise-Online gefunden.
Bestätigt meine bisherige Einschätzung und die vieler anderer, dass ein direkter Zugriff auf den MiniServer absolut keine Option ist. VPN ist also Pflicht.
Durch die Vergabe von Standard-Passwörtern und Schwächen im firmeneigenen DDNS-Dienst waren Smart-Home-Systeme von Loxone über das Internet angreifbar. Auf Hinweis von c't dämmte der Hersteller das Problem stark ein; ein Restrisiko besteht aber weiterhin.
Loxone-Installation mit mehreren Extensions, Dimmer-Extension, DMX, 1-Wire (alles aktuell noch im Auslieferungszustand);
FritzBox, Netgear Plus Switch mit mehreren VLANs, Intel NUC mit VMWare ESXi 6.5 (pfSense, Loxberry, Kleinkram)
Bekannt war das schon länger und Loxone wurde auch immer wieder darauf hingewiesen.
@florian wird Zeit das ihr pro MS ein Passwort macht analog wie es A1 hinter dem Modem macht.
Ist schon gruselig was ihr da macht!
Es werden ja auch Bausteine beim Update verändert die eine Nachbearbeitung der Config erforderlich machen da gibt es von eurer Seite keine Vorbehalte da sollte es bei der Sicherheit kein Thema sein!
Aber ich denk mir nach dem 1. Prozess bei den Amis ist das eh erledigt.
gestern war bei stern tv wieder ein unnötiger bericht über it sicherheit unnötig da so kriminelle neue ideen bekommen es gibt eine gerätesuchmaschine für
Bin erst kurz davor, meinen Miniserver in Betrieb zu nehmen und habe mir lediglich das Video angesehen. Da ist doch ganz klar, dass admin admin nicht sicher ist. Denke doch, dass man ein bisschen Smartheit auch von jemandem erwarten kann, der sich selbst sein Smarthome programmiert. Allen Partnern muss das ohnehin zuzutrauen sein.
Ja, man (Loxone) könnte einfach automatisch nach einem neuen und sichereren Passwort verlangen, so wie das manche Programme tun. Da fragt man sich schon ein bisschen, warum nicht?
Aber eine "Hintertür" ist das doch nicht, das ist eine offen stehende Eingangstür. Ich meine auch, dass Statistiken belegen, dass meistens spontan eingebrochen wird. Also, kein kleiner Hack auf ein Einfamilienhaus mit Ausspionieren der Kameras und danach gezieltes Einbrechen. Vielmehr in Wohngebieten rumlatschen, schauen, ob wer da ist, Fenster auf der unbeleuchteten vom Nachbarn abgewandten Seite einschlagen, rein, alles Wertvolle mitgenommen, sich über den riesigen Verteilerkasten und das automatische Licht gewundert, raus, fertig.
Ich sehe diesen Bericht auch völlig überzogen. Sobald du ein Gerät oder einen Account über das Internet zugänglich machst, solltest du wissen, dass es suboptimal ist, Standard-Zugangsdaten oder einfache Passwörter zu verwenden.
Dass Admin/Admin den Miniserver angreifbar macht, ist doch völlig logisch. Das würde ich aber nicht nur dann ändern, wenn ich den MS über Portfreigabe freischalte sondern auch für internen Zugang.
Als Hintertür würde ich das auch nicht bezeichnen, das ist analog zu einem Steckenlassen des Schlüssels in der Haustür...
Tatsächlich sind viele Leute aber sehr faul und wenn sie bequemer auf ihre Heimautomation zugreifen können, um vor dem Haus die Kaffeemaschine einzuschalten, dass wird es einen recht hohen Prozentsatz von Leuten geben, die das tun.
Und da genau diese Leute das Risiko auch meist nicht wirklich einschätzen können ("Meine Seriennummer kennt ja keiner..."), sehe ich den Hersteller an dieser Stelle sehr wohl in der Pflicht es seinen Nutzer zumindest so schwer wie möglich zu machen, unsichere Konfigurationen zu verwenden. Da sollte man wirklich wissen, was man tut...
Und der vergleich mit der offenen Autotür im Bericht hinkt auch etwas. Das Risiko einer unverschlossenen Tür kann Ottonormalverbraucher sehr viel besser einschätzen als einen IP-Fernzugang, den man ja nicht so wirklich anfassen und betatschen kann...
Loxone-Installation mit mehreren Extensions, Dimmer-Extension, DMX, 1-Wire (alles aktuell noch im Auslieferungszustand);
FritzBox, Netgear Plus Switch mit mehreren VLANs, Intel NUC mit VMWare ESXi 6.5 (pfSense, Loxberry, Kleinkram)
Benjamin Jobst : da bin ich völlig deiner Meinung! Wer ein Smart Home installiert und dann die Standard-Passwörter lässt ist nicht nur selber Schuld, sondern handelt auch noch Fahrlässig.
Der Vergleich mit der offenen Autotür am Parkplatz ist daher gerechtfertigt. Ein MS ist ja keine Webcam, die man "schnell mal so" ins Internet hängt, sondern benötigt entweder einen professionellen Partner (der, wenn er das PW mit dem Kunden nicht ändert, zur Verantwortung gezogen gehört) oder eine Privatperson, die sich mit der Materie auseinandersetzt.
Die Überschrift von Heise ist reines Clickbaiting
Zuletzt geändert von PBaumgartner; 31.08.2016, 11:46.
Ihr hackt auf dem falschen Problem rum...
Das admin/admin Kombination ist nicht das Hauptproblem, sondern der Cloud-Service, der sich durch Dritte systematisch auslesen lässt. Das ist besser als shodan.io. In dem Moment wo ein anderer, meinetwegen richtiger Exploit auftaucht, kann man die Geräte gezielt aufsuchen und bearbeiten.
Ist der Unterschied nicht der, dass man bei einem anderen dynDNS-Dienst bestenfalls eine aktuelle öffentliche IP erfährt, während man beim Loxone-DNS-Service gleich ein Loxone-Smart-Home "an der Angel" hat?
Es geht nicht einfach um die öffentliche IP. Bei einem DynDNS Service ist nicht klar, dass da ein Loxone SmartHome dahinter hängt. Beim CloudDNS schon. Es sind des Weiteren MAC-Adressen, die meistens der Reihe nach vergeben werden. Du brauchst also für alle angebundenen Loxone-Smarthomes nur URL des CloudDNS mit der MAC-Adresse. Ein großes Sicherheitsrisiko ist die 3xx HTTP-Weiterleitung. Oft wird der Tipp gegeben, dass man, wenn man schon den MiniServer ans Netz hängt, man wenigstens den Port ändert, damit man nicht gleich über eine globale Portsuche gefunden wird. Dies ist bei der bisherigen Arbeitsweise völlig sinnlos. Durch die Weiterleitung bekommt man den neuen Port auch noch auf dem Silbertablett serviert. Bei einem DynDNS Service müsste man schon einen Portscan machen um den Port herauszufinden.
Da von der 6-Byte MAC-Adresse die ersten 3 Bytes dem Hersteller zugeordnet sind (OUI=Organization Unique Identifier), bleiben nur die letzten 3 Bytes, um alle MS durchzunummerieren. Mit 3 geschachtelten Schleifen von 0 bis 256 lassen sich die URLs (inkl. konfiguriertem Port, wie Sven richtig erläutert hat) sämtlicher bei Loxone DNS Cloud registrierter MS abfragen. Das ist schon sehr bedenklich.
Da bei anderen DynDNS Diensten die Namen vom Nutzer individuell vergeben werden, ist ein systematisches Abfragen aller Loxone User nicht möglich.
Ihr hackt auf dem falschen Problem rum...
Das admin/admin Kombination ist nicht das Hauptproblem, sondern der Cloud-Service, der sich durch Dritte systematisch auslesen lässt.
Das sehe ich genauso! Wer "admin/admin" nutzt ist selbst schuld. Aber der Designfehler des Cloudservice ist das eigentliche Problem. Und genau das haben wir hier schon vor langem diskutiert. Aber daran scheint ja Loxone wiede rnichts zu ändern. Kann man den CloudDNS denn wenigstens abschalten?
Sollte sich unter "Miniserver konfigurieren" auf der Registerkarte "Zugriff" abschalten (eigentlich) lassen oder den Cloud DNS Service in der Registrierung komplett deaktivieren.
VPN ist doch echt kein Hexenwerk. Eine Fritzbox gibt bei Einrichtung alle relevanten Infos raus. VPN an/aus bei Bedarf ist zwar etwas nervig, aber man greift ja nicht ständig auf sein Haus zu, oder? Eine automatische Aktivierung wäre schon chic....
An dem Thema sicherer Passwörter/Sicherheitshinweis bei unsicherem Passwort ist man so weit ich mal was gehört habe auch schon dran....
Da Du mit einem iPad unterwegs bist: ein VPN "On-Demand", welches für iPhone und iPad vollautomatisch nach Bedarf das VPN aufbaut gibt es schon! Wurde hier im Forum mehrfach diskutiert und im dann im Loxwiki beschrieben: http://www.loxwiki.eu/display/LOX/VPN+on-demand
Gruß Jan
Miniserver v14.5.12.7, 2x Ext., 2x Relay Ext., 2x Dimmer Ext., DMX Ext., 1-Wire Ext., Gira KNX Tastsensor 3 Komfort, Gira KNX Präsenzmelder, Fenster- und Türkontakte, Loxone Regen- und Windsensor, Gira Dual Q Rauchmelder vernetzt, 1x Relais-Modul Loxberry: SmartMeter, MS Backup, CamConnect, Weather4Lox Lüftung: Helios KWL EC 370W ET mit Modbus TCP - via Pico-C Heizung: Stiebel Eltron WPF 5 cool (Sole-Wasser WP) mit ISG, FB-Heizung mit 18 Kreisen, Erdsonde - via modbus/TCP Node-RED: IKEA Tradfri
Ich bin der gleichen Meinung wie Loxone, dass man dem Benutzer kein Kennwort aufzwingen muss. Im internen Netz ist das Risiko gering, und für Testinstallationen im LAN brauche ich keine sicheren Kennwörter.
Sehr wohl könnte Loxone aber verhindern, dass Requests von außerhalb des eigenen Subnets mit der Admin/Admin-Kennung anmelden dürfen. Die Quelle des Requests dürfte nach meinem Wissen auch in einer ge-NAT-eten Verbindung enthalten sein, oder sonst erlaubt man auch der Gateway-IP keinen Zugriff mit dem Standardkennwort.
NAT wirkt nur nach Außen, richtig. Sonst wüsste der interne Client ja überhaupt nicht wohin er das Paket schicken soll.
Richtig, man braucht dem User kein Passwort aufzwingen. Das tun aber auch die Router nicht. Die haben ein automatisch generiertes PW drin und jeder kann es ändern. Wo ist das Problem? So wären die Geräte "sicher" und wenn man dann in einer Testumgebung admin/1234 setzt, dann hat der User dies aktiv so gewünscht. Das würde diese ganzen Diskussionen hier sparen. Ich weiß sogar von Partnern, die Ihren MiniServer am Netz haben mit admin/admin. Ich weiß von Elektrikern, die das System einbauen wollen und auf dem Seminar noch nicht einmal das Grundlegende verstehen. Wie sollen die denn das Thema Sicherheit verstehen und managen? Hier wird geschrieben, dass Leute, die den MiniServer ans Netz hängen Mindestkenntnisse in Netzwerktechnik brauchen und man dann auch erwarten kann, dass die Sicherheit beachtet wird. Hallo???
Wie oft behandeln wir hier Themen wie "Ich kann auf meinen MiniServer von außen nicht zugreifen. Was mache ich falsch?" Und alle helfen bereitwillig. Die Konsequenz aus Euren Aussagen wäre, dass in solchen Fällen ganz klar gesagt werden müsste, dass man sich einen Profi holen muss und auch keine Hilfestellungen gegeben werden dürfen.
Wieviele Leute wird es denn da draußen geben, die den Zugriff nach wochenlangem Basteln soeben hinbekommen haben. Meint Ihr, dass die dann nochmals das System ändern und Gefahr laufen wollen den Zugang wieder zu killen?
Wo soll denn hier das Problem sein ein generiertes PW einzusetzen?
Ein Partner, der viele Anlagen aufbaut und sich hier beschwert, dass er immer ein anderes PW hätte, der sollte soviel Verständnis haben, dass er sich einen "Rohling" anlegt und mit diesem den Miniserver startet. Dort hat er dann auch gleich alle Einstellungen zu Zeitserver DNS-Server etc. mit drin und kann so loslegen. Was für ein Aufwand??!
Sicher ist das (noch) nicht die Pflicht von Loxone, aber in Zeiten dieser Cyberattacken und Sicherheitsdiskussionen wäre dies ein richtiges Zeichen. Muss denn erst wieder reihenweise was passieren bis das zur Vorschrift wird??
Gruß Sven
Miniserver; KNX; Vitogate; EnOcean (EnOceanPi); Loxone Air; Caldav-Kalenderanbindung; RaspberryPi und für keine Frickellösung zu schade :-)
Ich bin der gleichen Meinung wie Loxone, dass man dem Benutzer kein Kennwort aufzwingen muss.
In diesem Punkt stimme ich Dir zu. Dass Loxone allerdings einen Cloud DNS Dienst bereitstellt, der ein systematisches Ausspionieren aller registrierten MS erlaubt, das ist ein eklatanter Sicherheitsmangel an dem Design dieses Dienstes. BSiege, Sven und Prof. Mobilux haben bereits auf das eigentliche Problem hingewiesen. Unter https://www.loxforum.com/forum/faqs-...4402#post54402 habe ich noch ein paar Erläuterungen zu dem eigentlichen Problem gepostet (irgendwie sind hier 2 Threads zum gleichen Problem aufgemacht worden).
Ich bin der Ansicht, dass eine Firma wie Loxone überhaupt kein Interesse daran haben dürfte, dass in einer zukünftigen c't eine Fortsetzung des Artikels erscheint mit dem (jetzt noch fiktiven) Text:
Eine kriminelle Hackerbande hat eine Sicherheitslücke im Webinterfaces des MS gefunden, die es einem Angreifer auch ohne Kenntnis des Admin-Kennwortes erlaubt, einen vollen Zugriff auf den MS zu erlangen. Durch den von Loxone empfohlenen und propagierten hauseigenen Cloud DNS Dienst war es den Hackern erst möglich, diese Sicherheitslücke systematisch auszunutzen und sich in alle registrierten und öffentlich zugänglichen MS einzuhacken. Der Cloud DNS Dienst erlaubt es dem Hackern nämlich ein ausspionieren aller MS, da der Dienst als URL die MAC-Adresse der MS verwendet und sehr einfach alle Kombinationen getestet werden können. Da in der Konfiguration des MS i.d.R. der Name und die Adresse des Hauses hinterlegt waren, konnte die Bande gezielt in die ausspionierten Häuser einbrechen und sogar vorhandene Sicherheitsmaßnahmen, die über MS implementiert waren, umgehen. In einigen Fällen konnte sogar die Haustür automatisch geöffnet werden, so dass keine Spuren eines Einbruches sichtbar waren.
Ich glaube, dass dann viele angehende Häusle-Bauer, die keine tiefergehende Ahnung von Security haben, ein anderes System wählen, wenn so eine Meldung erscheint. So etwas kann nicht im Interesse von Loxone sein und daher sollten die schnellstmöglich das Design des Dienstes verbessert werden. Aus diesem Grund kann ich auch nicht verstehen, dass Loxone das Problem nur in den unsicheren Kennwörtern sieht. Eine Idee für eine "Nachbesserung" des Cloud DNS Dienstes habe ich in dem verlinkten Post bereits geschrieben.
Gruß Jan
Miniserver v14.5.12.7, 2x Ext., 2x Relay Ext., 2x Dimmer Ext., DMX Ext., 1-Wire Ext., Gira KNX Tastsensor 3 Komfort, Gira KNX Präsenzmelder, Fenster- und Türkontakte, Loxone Regen- und Windsensor, Gira Dual Q Rauchmelder vernetzt, 1x Relais-Modul Loxberry: SmartMeter, MS Backup, CamConnect, Weather4Lox Lüftung: Helios KWL EC 370W ET mit Modbus TCP - via Pico-C Heizung: Stiebel Eltron WPF 5 cool (Sole-Wasser WP) mit ISG, FB-Heizung mit 18 Kreisen, Erdsonde - via modbus/TCP Node-RED: IKEA Tradfri
Hört doch auf mit der Haarspalterei. Auf ein paar tausend reguläre Miniserver kommt vielleicht eine Laborumgebung, oder?
Herstellervorgaben für Passwörter sind an sich kein Problem. Das Problem ist, wenn ich Defaultpasswörter Googeln kann. Als Hersteller bin ich fein raus, wenn ich beim ersten Verbinden einen User und ein Passwort vergeben MUSS. Dann ist die Entropie schon extrem viel höher. Ob Lab/Lab , null/malschauen , admin01/d47ghwefq&jhegqwerwq
verwendet wird, man ist fein raus. Sogar wenn die Fantasie nur für admin/admin oder admin/1234 ausreicht.
Und dass wir jetzt auch mal etwas Positives erwähnen: Obwohl kein SSL im Miniserver, an die Passwörter im Klartext kommt man nicht so einfach ran. Was nicht heisst, dass da plötzlich ein Tool auftaucht, das dies kann. Wäre auch nicht das erste Mal.
Wir verarbeiten personenbezogene Daten über Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen, Werbung zu personalisieren und Websiteaktivitäten zu analysieren. Wir können bestimmte Informationen über unsere Nutzer mit unseren Werbe- und Analysepartnern teilen. Weitere Einzelheiten finden Sie in unserer Datenschutzrichtlinie.
Wenn Sie unten auf "Einverstanden" klicken, stimmen Sie unserer Datenschutzrichtlinie und unseren Datenverarbeitungs- und Cookie-Praktiken wie dort beschrieben zu. Sie erkennen außerdem an, dass dieses Forum möglicherweise außerhalb Ihres Landes gehostet wird und Sie der Erhebung, Speicherung und Verarbeitung Ihrer Daten in dem Land, in dem dieses Forum gehostet wird, zustimmen.
Kommentar