ungebetener Besuch von ???

[jp112sdl]

Wie gesagt, soll kein gemotze sein, sondern ich wollte einfach mal wissen, ob es einen Grund dafür gibt, dass diese Schwachstellen nicht gepatcht werden.

Die, die nicht wissen was sie tun, kaufen einen HmIP-AP und nutzen die Cloudlösung.
Alles sicher, Zugriff über die App, man muss keine eingehenden Ports öffnen und sich um nichts kümmern.

Die, die wissen was sie tun, gehen zur "Profi-Lösung" CCU3 über.
Oder?
Wer dann aber auch noch eine Portweiterleitung direkt auf das Gerät einrichtet, weiß wirklich nicht, was er tut.
Ich persönlich würde sowieso nie für eines meiner LAN-Geräte ein Loch von außen nach drinnen aufbohren.

[shartelt]

wenn Du Deine HUE bridge direkt ins internet stellst, kannst nur drauf warten bis Deine Lichter wild an und aus geschalten werden…

imho muss der Hersteller da gar nix machen….

wer sein NAS direkt ins Internet stellt wundert sich auch nich, wenn seine private foto sammlung weg ist und die privaten Filmchen auf gewissen seiten gepostet werden unter der Kategorie Amateur….

[MichaelN]

Da andere Geräte auch im Netz hängen und sicherer gegen Hacker gemacht werden können,

Welche Geräte wären das, die du per Portweiterleitung im Netz präsentieren magst?

[rentier-s]

Verzeiht mir die dumme Frage, aber wenn wir hier von Hacken einer CCU reden, ist eine Bruteforce Attacke auf den Admin User gemeint. Oder gibt es da noch andere Angriffsziele?

[Fonzo]

Welche Geräte wären das, die du per Portweiterleitung im Netz präsentieren magst?

Egal was im Netz hängt, man sollte eben genau wissen was man tut. Beispiele für Systeme die im Internet hängen gibt es genug wie Plex Server, Windows Home Server, Fritzbox hinter NAT, sichere Gebäudeautomationssysteme.

[cmjay]

ist eine Bruteforce Attacke auf den Admin User gemeint. Oder gibt es da noch andere Angriffsziele?

Man kann eine CCU auch ohne Brute Force übernehmen. Der diesbezügliche Angriffsvektor wurde hier im Forum vor vielen Jahren auch mal dokumentiert (als in bestimmten Situationen hilfreiches Tool, nicht als Anleitung zum Hacking). Allerdings wurden aus Sicherheitserwägungen alle entsprechenden Verweise von den Admins entfernt. Die Schwachstelle existiert aber wohl immer noch. Wenn ich mich nicht irre, dann nutzt @Black genau diese Schwachstelle, wenn er unbedarften Usern, die gehacked worden sind, hilft wieder Zugang zu ihrer CCU WebUI zu bekommen.
Also Fluch und Segen zugleich.

[Xel66]

Nö, ist keine Schwachstelle. Das ist ein ganz normaler dokumentierter Zugang, über den man ganz normal mit der CCU kommunizieren kann. Könnte man auch anders zu Fuß machen. Diese Schnittstelle nutzen auch andere Tools. Wäre es eine normale Schwachstelle im eigentlichen Sinn, wäre sie definitiv in der Zwischenzeit gefixt worden.

Gruß Xel66

[jmaus]

Nö, ist keine Schwachstelle. Das ist ein ganz normaler dokumentierter Zugang, über den man ganz normal mit der CCU kommunizieren kann. Könnte man auch anders zu Fuß machen. Diese Schnittstelle nutzen auch andere Tools. Wäre es eine normale Schwachstelle im eigentlichen Sinn, wäre sie definitiv in der Zwischenzeit gefixt worden.

Auch darüber hinaus gibt es in der WebUI einige Angriffsvektoren die leider technisch bedingt ohne komplette Neuprogrammierung bzw. Umstrukturierung der WebUI nicht abzustellen sind. D.h. Selbst wenn man die WebUi auf Authentifizierung + https-only stehen hat gibt es Möglichkeiten auch ohne Kenntnisse von Nutzeraccounts bzw Passwörter kommandos an die WebUI über Port 80/443 zu senden damit man nicht nur in die WebUI jederzeit reinkommt, sondern sogar Kommandos senden kann um die gesamte Speicherkarte unmittelbar löschen zu lassen. Und wie schon gesagt, leider lässt sich diese "Lücke" nicht ohne komplettes Neuschreiben der WebUI bzw. austauschen integraler Javascript-Frameworks die die WebUI nutzt abstellen. Und genau deshalb gilt weiterhin, trotz inzwischen auf verschiedenen ebenen vorgenommener Verbesserungen, bzgl Sicherheit: Niemals die WebUI (Port 80/443) einer CCU/RaspberryMatic via Port-Forwarding im Internet direkt verfügbar machen.

Ich würde allerdings sogar soweit gehen die These aufzustellen, das sich dies nur auf die WebUI auf Port 80/443 bezieht, es aber wohl OK ist z.b. den verschlüsselten bzw via Authentifizierung geschützten XMLRPC Teil via Port Forwarding freizugeben, da dieser meines Wissens aktuelle keine kritischen Angriffsvektoren hat im Gegensatz zur WebUI selbst.