Hacker Doci1989 zu Ostern zu Besuch

[Roland M.]

Hallo Michael!

Der richtige Weg wäre ja die Sicherheitslücken zu schließen, statt die User zu warnen.

Sehr provokant gefragt: Welche Sicherheitslücken?
Was kann der Hersteller eines Produktes mit einem Webserver dafür, wenn ein Kunde durch Portforwarding den Webserver im Internet veröffentlicht?

Ein Einfallstor scheint ja zu sein, daß man neue User anlegen kann ohne als Admin angemeldet zu sein.

Meiner Meinung nach scheint das aber nicht das primäre Angriffsziel zu sein.
Ich will es nicht gänzlich ausschließen, aber der Port 8181 (http://<IP_der_CUU>:8181/Gott.exe=sprach="...") wird kaum freigegeben. Der Webserver mit Port 80 scheint mir in Kombination mit dem "Automatischen Anmelden", auch als Admin, das Problem zu sein.

Könnte man da nicht (zumindest in der RaspberryMatic) ansetzen?

Egal, ob RM oder Original-CCU: solche Änderungen gehen nur in neuen FW-Revisionen ein. Wie bringt man Benutzer alter Versionen dazu, ein Update zu machen - wenn vielleicht sogar diese Änderung schon im Voraus bekannt und als unbequem abgestempelt wird? Oder gar für Benutzer, die z.B. vom Elektriker/Bauherren eine CCU hingestellt bekommen haben und es funktioniert mit FW-Stand Hausbau ja ohnehin alles?

Aber dennoch, mein Vorschlag dafür wäre:
- Automatisches Anmelden nicht als Admin möglich
- Automatisches Anmelden nur innerhalb des eigenen Netzes (oder als Komfortfunktion innerhalb definierbarer Netze, z.B. VPN)

Was uns aber auch gleich zur Überarbeitung der Benutzerstufen (Gast / Benutzer / Admin) führt, wieder ein Fass ohne Boden...


Roland

[jmaus]

Der richtige Weg wäre ja die Sicherheitslücken zu schließen, statt die User zu warnen.

Ein Einfallstor scheint ja zu sein, daß man neue User anlegen kann ohne als Admin angemeldet zu sein. Könnte man da nicht (zumindest in der RaspberryMatic) ansetzen?

Nein, das geht meines erachtens derzeit nicht und würde es notwendig haben weite teile der WebUI (und dessen APIs) komplett in die Mülltonne zu werfen damit diese Sicherheitslücke beseitigt wird während man die Benutzertrennung von Gast vs. User vs. Admin aufrechterhält. Vielleicht kann man das wenn man irgendwann die WebUI wie im noch offenen PullRequest komplett auf Bootstrap umgestellt hat. Müsste man dann nochmal schauen. Aber aktuell ist es technisch nicht möglich zu verhindern, das man mit einer sessionID eines normalen Nutzeraccounts in der WebUI auch Admindinge ausführen kann (wenn man weiss wie).

Eine Alternative dazu wäre als profanes Mittel diese Problematik zu beseitigen, indem man einfach genau diese Benutzerleveltrennung von Gast- vs. User- vs Adminaccount gänzlich abschafft und vor allem die Möglichkeit des Auto-Logins als erstes komplett entfernt. Das sollte somit die WebUi ein ganzes Stück sicherer machen, denn dann kann man sich nicht einfach z.b. die sessionID eines Gast- oder Nutzeraccounts schnappen und diese dann für das ausführen von potentiell kritischen Adminaktionen (z.b. ein 'system.Exec') wiederverwenden.

[alchy]

EQ-3 hat einige der Schwachstellen vor Jahren schon erhalten und nicht darauf reagiert (außer irgendwann die rote Warnung in die Klickibunti zu integrieren mit Portforwarding und dann irgendwann den Pseudofirewallkram einzuführen.

Und natürlich ist das *IMHO* ein Bugs und auch ein Mangel des Herstellers und nicht nur die Dummheit der User.
Wenn ein User denkt seine CCU ins Netz per Portforwarding stellen zu müssen und ein 250 Zeichen Passwort vergeben hat usw. und denkt das damit alles halbwegs sicher ist, darf er sich ein Stückweit auch darauf verlassen.
Was, nun schon mehrfach gepostet, eben überhaupt nicht der Fall ist.

Noch mal der Hinweis: im Forum werden keine Wege beschrieben, wie man fremde CCUs übernehmen kann.
Es gibt schon genug User wie unseren Doci1989 der Just2Fun solche User "ärgert" .
Und es ist ja nicht mehr als ärgern. Da das Forum die CCUs ja wieder repariert, kommen die User mit einen blauen Auge davon, verlieren nicht mal Geld wenn sie es mit Bedacht tun.
Ich hatte schon oft skizziert, was auch passieren könnte wenn mal ein richtiger Verbrecher die Chance nutzt. Auch das wird passieren, wie bei allem ist es nur eine Frage der Zeit.

BTW.
Gerade habe ich wieder eine CCU gefunden die vollkommen schutzlos im Netz steht. (stand)
Sollte jemanden die anhängende Programmstruktur bekannt vorkommen:
Du bist nicht weit davon entfernt der nächste hier im Thread zu sein.
Makaber, da es sich auch noch um eine Installation mit Türöffnung handelt.
Leider habe ich bisher keine Kontaktdaten auf der CCU gefunden um mit den Besitzer in Kontakt zu treten. Sein gesamten Netzwerk zu scannen nach Kontaktdaten, fehlt mir die Zeit und die Lust.

Alchy

[chka]

wir können ja die kleine Sammlung aufmachen von schutzlosen

Grüße nach Neuffen, mehr weiß ich nicht

[MichaelN]

Das ist wirklich erschreckend. Und ich dachte mittlerweile weiß JEDER um diese Risiken.

[jp112sdl]

Das ist wirklich erschreckend. Und ich dachte mittlerweile weiß JEDER um diese Risiken.

Ich denke mal, der geringste Anteil an Nutzern wird sich
a) vor dem Anschaffen von HM ausgiebig in einem (diesem) Forum über das Produkt und alle auftretenden "wurde hier schon tausendmal beschrieben"-Themen informieren, noch wird es sich
b) um IT-Kenner handeln.

Hingegen liefert eine allgemeine Suche nach "Wie komme ich von unterwegs auf mein System" viele "mach ne Portweiterleitung" Treffer.

[zautrix]

Das ist ja alles aufregender als jeder Krimi!

Also, wenn ich das richtig sehe, ist doch Doci der oder die einzige, der/die etwas nachhaltig unternimmt damit solche CCUs vom Netz genommen werden.
Da ich mal davon ausgehe, dass Doci hier mitliest ( und sich noch nicht tot gelacht hat ):
Hallo Doci, danke für das ganze gute Entertainment das du hier verursachst.
Mein Popcorn Vorrat ist noch voll, also "the show must go on!".
Oder müsste es eher "shodan must go on" heißen?

[jmaus]

Aber dennoch, mein Vorschlag dafür wäre:
- Automatisches Anmelden nicht als Admin möglich
- Automatisches Anmelden nur innerhalb des eigenen Netzes (oder als Komfortfunktion innerhalb definierbarer Netze, z.B. VPN)

Vielleicht war ich nicht deutlich genug: auch mit einem automatischen Anmelden nur eines "Gast" Nutzeraccounts kann man einfach sich die session ID (sid) dieser Anmeldung schnappen und - wenn man weiss wie - problemlos sämtliche Adminoperationen über die WebUI (Port 80) inkl sämtliches ReGaSkriptibg durchführen um nicht nur die komplette CCU durcheinander zu würfeln, sondern sogar komplett zu zerstören.

Hier würde einzig alleine zu einem gewissen Anteil helfen, 1. die Möglichkeit des automatischen Anmelden gänzlich zu entfernen und 2. auch die Trennung von Gast, Nutzer, Admin auch komplett zu entfernen oder diese Funktionalität in sowas wie Benutzerdarstellung zu ändern und mit einer großen Warnung beim Anlegen eines Gast/Nutzers darauf hinzuweisen das diese vermeintlich limitierten Zugangsformen keinerlei Sicherheitstechnische Kapselung darstellen und man mit einem Gastaccount die komplette CCU/RaspberryMatic sich selbst zerstören lassen kann - wenn man eben weiss wie!

[jmaus]

die Idee ist gut, wird aber leider jede Menge False Negatives produzieren, weil die meisten Homerouter kein NAT/NAT Reflection beherrschen und damit keinen Request von der internen IP auf die Public Adresse machen können. Wenn, dann bräuchte man da wirklich externen Dienst, der das von außen prüft.

[...]

Aber ob das alles sich auch lohnt muss ich mir erst einmal nochmal durch den Kopf gehen lassen.

Nun habe ich gerade mal eine erste Version eines solchen (erst einmal rein auf nmap basierten) check skriptes erarbeitet und eingebaut. Mit diesem neuen "/bin/checkPortForwarding.sh" Skript (welcher im nächsten nightly build dann mit an bord sein sollte) sollte nun hoffentlich ein vermeintlich kritisches Port Forwarding erkannt werden (wenn der genutzte Router eben die von Alex genannte NAT/NAT Reflection beherrscht). Die eigentlich darauf folgenden WebUI Alarmierung habe ich noch nicht eingebaut, weil ich erst einmal auf diesem Wege hier erste Erfahrungen mit diesem neuen Checkskript sammeln möchte.

Wäre also schön wenn sich ein paar Tester hierfür einfinden könnten die auch nicht davor zurückschrecken temporär ein Port Forwarding auf ein Testsystem einzurichten damit man mit verschiedensten Routerkonstellationen hiermit Erfahrungen sammeln kann ob das Konzept prinzipiell aufgeht und auch wirklich nützlich ist. Und wenn ja, dann könnte man in der Tat auch darüber diskutieren wie oft dieses Checkskript ausgeführt werden sollte, auch weil die Ausführung dieses Skriptes mitunter bis zu 15-20 Minuten dauern kann um nach allen offenen Ports zu scannen.

Wer also beim Testen mitmachen kann und möchte kann mit dem morgigen nightly build das "/bin/checkPortForwarding.sh" Skript auf der Kommandozeile einfach ausführen und es sollte dann bei einem erkannten Port Forwarding (was eben bis zu 20 Minuten dauern kann) eine ERROR Message ausgeben sowie den Rückgabewert des Skriptes auf 1 setzen.

[MichaelN]

Ich bin bestimmt kein Experte für die berüchtigte Suchmaschine, aber ich finde auf die schnelle über 1600 CCUs mit Portweiterleitung allein für DE und - auf Basis nicht evaluierter Stichproben - sind davon 20-30% ohne Passwort im Netz. Also ohne jegliche Zugangsbeschränkung besuchbar. Echt ein Wunder, das hier nicht mehr Hilferufe aufschlagen.