Diskstation gehackt

[blurrrr]

700+... jetzt alleine bei ioBroker?

 

[Synchrotron]

Sehe ich anders. Wenn man weiß, woher die Schwachstelle in einem System kommt (ioBroker) dann lasse ich diese doch nicht weiterlaufen, bis irgendwann mal der Hersteller die Lücke geschlossen hat. Vor allem bei so einem supergau, vertrau ich doch so einer Software nie und nimmer mehr. Weg damit

Es gibt einen Fix, den muss man aber selbst einspielen.

 

[Jim_OS]

Wenn man weiß, woher die Schwachstelle in einem System kommt (ioBroker) dann lasse ich diese doch nicht weiterlaufen, bis irgendwann mal der Hersteller die Lücke geschlossen hat.

Das habe ich ja auch nicht geschrieben. Ich schrieb: Je nach Wichtigkeit und Schweregrad sollte man darauf entsprechend reagieren.

Vor allem bei so einem supergau, vertrau ich doch so einer Software nie und nimmer mehr. Weg damit

Wieso "supergau"? Da scheint einfach eine Sicherheitslücke zu sein, wodurch entsprechende Dinge (z.B. Zugriff von außen durch Dritte) möglich sind. Das hat nichts mit Supergau zu tun. Das gab es beim DSM von Synology auch schon und wird es sicherlich immer mal wieder geben. Somit müsstest Du demnach dann auch das DSM löschen.
Natürlich bedeutet ein mehr an Software auch gleich ein mehr an potentiellen Fehlerquellen, aber (Sicherheits-)Lücken kannst Du nie ausschließen. Bei mancher Software mehr und bei mancher weniger.


Nachtrag: Nicht das jemand denkt ich würde etwas verharmlosen, oder eine gewisse Gleichgültigkeit an den Tag legen. Ich bin seit über 30 Jahren in der IT tätig und davon über 10 Jahre als (Server-)Admin. Ich bin also einiges gewöhnt.
In den Vor-Internet-Zeiten gab es halt nur Viren. D.h. keine Software aus dubiosen Quellen = keine Problem - außer den üblichen mit schlecht programmierter Software.
Jetzt in Internet-Zeiten und permanenter Online-Verbindung in die große weite Welt, kann jede kleine Lücke in einer Software zu entsprechenden Folgen führen und diese kann niemand vollständig verhindern. Es sei denn er zieht den Stecker. Ja wenn irgendwelche (Sicherheits-)Lücken in Hard- oder Software zu Schäden führen ist das natürlich ärgerlich, aber das gehört inzwischen zu dem Leben mit dazu. Zumindest wenn man auch online sein möchte.

VG Jim

 

[blurrrr]

Kleiner Nachtrag zum Thema "Sicherheitslücken" und der Tatsache, dass auch die Konkurrenz nicht verschont bleibt: Sicherheitsupdate: Angreifer könnten eigene Befehle auf Qnap NAS ausführen (aber die kommen ja auch nicht mehr als den negativen Meldungen raus) ?

 

[Jim_OS]

(aber die kommen ja auch nicht mehr als den negativen Meldungen raus) ?

Was für Synology ja auch nur von Vorteil ist. Stell Dir vor QNAP wäre bei dem Thema Software auch so "gut" wie Synology. Das würde m.M.n. dann wohl viele User dazu bewegen zu QNAP zu wechseln, weil es halt mehr Hardware-Leistung für's gleiche Geld gibt. Stabilität und Zuverlässigkeit waren bzw. sind (weiterhin) der Vorteil von Synology.

VG Jim

 

[Tommes]

Das sehe ich nicht zwangsweise so. Auch auf deinem Router sind Ports offen, damit Anbieterdienste oder auch der VPN funktioniert. Das macht das Thema noch lange nicht zu einem Sicherheitsproblem.

Das ist natürlich richtig. Das Problem ist in der Tat auch erstmal nicht - wie du bereits ausgeführt hast - der offene Port an sich, sondern der Dienst, der dahinter steht. Ich bin mir auch nicht wirklich sicher, ob der Port für meinen Minecraft Server, der als Docker-Image auf meiner DS216+ läuft, wirklich sicher ist, oder ich da irgendwo eine Sicherheitslücke aufgerissen habe. Aber ich habe zumindest versucht alles zu tun (ich spiele hier aktuell mit pfSense und dem Aufbau einer DMZ rum), um einen möglichen Angriff abzuwehren oder zu mindest mit einem geringen Schaden davon zu kommen, sollte es mal hart auf hart kommen. Und genau das streben die Big Player im Routergeschäft natürlich auch an. Die öffnen ja nicht einfach irgendwelche Ports und das dann auch mit dem nötigen Backgroundwissen sowie der Sicherung bzw. Überwachung der Ports.... theoretisch jedenfalls! (Bin ja auch nur Laie auf diesem Gebiet)

Das sehe ganz genauso. Man braucht Portweiterleitungen um überhaupt vernünftig von unterwegs mit den Diensten arbeiten zu können. ( oder man hat VPN)

Das Problem bei vielen Benutzern ist aber, das diese oftmals garnicht wissen, welche Ports sie überhaupt - dank z.B. UPnP - geöffnet haben, geschweige denn, das es z.B. einen gravierenden Unterschied zwischen Port 5000 und 5001, oder das es gar eine DSM Firewall, automatische Blockierung, 2FA etc. gibt. Da wird oft wild drauf los konfiguriert, ohne Sinn und Verstand. Und genau deshalb halte ich eine Portweiterleitung durchaus für gefährlich. Und genau aus diesem Grund hört uns liest man überall, das man idealer Weise VPN nutzen sollte und ja, ich nutze ausschließlich VPN, nur bei dem Minecraft Server hielt ich das für suboptimal. Anyway...

Ist ein schwieriges und vor allem vielfältiges Thema.

Tommes

 

[blurrrr]

Ist ein schwieriges und vor allem vielfältiges Thema.

Dafür gibt es ja die IT-Fachidioten ?

 

[Penthys]

Einen großen Teil der offenen Ports kann man auch mit dem Reverse Proxy eliminieren. Ich habe das vor ungefähr einem Jahr mal begonnen und etwa 80%-90% an offenen Ports schließen können wärend die dahinter stehenden Dienste jetzt über den Reverse Proxy bedient werden. Portscans und ähnliches laufen ins Leere und ich brauch mir keine Portnummern mehr zu merken, sondern verwende passende Subdomainnamen. 100% Sicherheit gibt es nicht, wenn man seinen Server auch verwenden will, aber man kann die Hürden etwas höher legen.

 

[Benares]

Halte ich für einen guten Ansatz, zumal man dann auch das ganze "Zertifikats-Geraffel" zentral behandeln kann.

 

[the other]

Moinsen,
nach erneutem Durchlesen beider Hack-bezogenen Threads bleibe ich bei meiner Aussage in diesem Thread am Anfang: nicht das OS, nicht die Anwendung ist das eigentliche Problem, sondern idR der / die Nutzer vor dem Screen.
*Ja, windows hat statistisch mehr User, daher mehr Gewinnversprechen, bei wesentlich größerer Nutzerzahl nimmt natürlich auch der Anteil nicht wissender / wollender Nutzer zu. Liegt aber eben vor allem am Nutzer...
*Daraus zu schließen, dass Apple und Linux alles total sicher machen ist ebenfalls quatsch, da ich auch Bekannte kenne, die sich ein ubuntu ziehen, stolz rumposieren und dann doch die gleichen dämlichen Fehler im Heimnetzwerk machen...liegt eben vor allem am Nutzer
*Das Konsumverhalten der analogen Welt (schnell, billig, egal wer bei der Herstellung leidet oder stirbt) kann auf die digitale Welt übertragen werden: schnell, geil was das alles kann, nein ich reflektiere mein Nutzerverhalten nicht und will/kann das auch nicht und habe auch kein Interesse das zu verändern, egal, ob dann das RKI (zB) mit DDOS Angriffen von seiner Arbeit abgehalten wird und mein Rechner unbekannterweise beteiligt war...liegt eben vor allem am Nutzer.
*hey, ich hab da ein NAS das ALLES kann...hey, ich hab da Geld für bezahlt, klar nutze ich das dann auch....wie, sich dazu einlesen und verstehen??? ...liegt eben vor allem am Nutzer

usw
Allein in den hiesigen Beiträgen geht (und das soll nicht als Anmache aufgefasst werden!!!) es um offene ssh Ports nach außen, Portfreigaben für DB Zugriffe im kommerziellen Umfeld, UPnP Portfreigaben...da wird man weder als Windows noch als Apple noch als Linux User zu gezwungen.
Ich habe ne Menge Fehler ebenfalls schon gemacht und bin dann nach und nach eingestiegen, zum Glück bislang ohne größere negative Folgen. Geholfen hat dabei aber nur der Wille, der Luxus dafür Zeit und Geld zu haben und viele viele Menschen in vielen Foren, die mich eben bei der Hand genommen /mir den Hintern versohlt haben.
EIN Motivationsgrund, hier eben auch meinen Senf dazu zu geben, in der Hoffnung, was zurück geben zu können.

sorry, war ein langer Tag, musste mal reden...

 

[blurrrr]

Nicht nur... aber praktisch liegt der "Nutzer"-Anteil vermutlich bei mindestens 95% (oder höher) ?

 

[servilianus]

Bin kein Profi, aber aus dem anderen Vorfall hier im Forum und den Berichten dazu läßt sich lesen, dass es eine schwerwiegende Schwachstelle im iobroker gibt (Gegenwart, denn die ist so lange da, bis man aktiv den Fix einspielt). Wer jetzt einen Port offen hat, um seinen iobroker zu erreichen, der geht davon aus, dass man dort die Anmeldedaten benötigt. Bei dieser Schwachstelle ist es aber nicht so.

Da ich selber den iobroker im Docker laufen habe, habe ich das Ganze für mich nochmal durchgeprüft.

Tatsächlich ist es so - und dies war mir ehrlich gesagt gar nicht so bewusst - dass bei der (Erst)Anlage des ioBrokers KEIN Admin-Konto mit Passwortschutz angelegt wird bzw. die Anlage selbiges verlangt oder zumindest angemahnt wird.

In der Grund-Konstellation kann man auf die Benutzeroberfläche des ioBroker gänzlich ohne einen wie auch immer gearteten Passwortschutz zugreifen. Man muss stattdessen manuell die Instanz "admin" hinzufügen. Erst mit dieser kann man überhaupt angepasste Benutzerrechte vergeben. Man muss hier manuell "Authentifikation" anklicken. Und: In der Grund-Konstellation läuft alles über http. Erst durch das Hinzufügen der admin-Instanz (oder meinethalben: Erweiterung) lässt sich ein zwangsweiser https-Zugang durch anklicken anlegen.

Mir ist tatsächlich erst jetzt aufgefallen, dass man die ganze Zeit die Web-Oberfläche von ioBroker ganz ohne Passwort und per http aufrufen konnte. Ich war - fälschlicherweise - davon ausgegangen, dass mein Mac ein iobroker-Passwort gespeichert hatte, als ich seinerzeit ioBroker per Docker ans Laufen gebracht hatte. Nur gab es schon damals gar kein Passwort....

 

[blurrrr]

Ich war - fälschlicherweise - davon ausgegangen...

Heisst ja nicht umsonst: Vertrauen ist gut, Kontrolle ist besser! ?

 

[Synchrotron]

Ist eigentlich ganz einfach: Mal ins Paketzentrum gehen und alles anschauen. Was muß tatsächlich - weil es benutzt wird - installiert sein ? Den Rest deinstallieren, ohne Gnade. Kann man sich alles wieder drauf laden, wenn man es mal in Betrieb nehmen will. Was nicht installiert ist, kann auch keine Sicherheitslücke haben.

Nächster Schritt: Systemsteuerung, alles durchgehen, was Dienste angeht. Alles abschalten, was man nicht aktiv benutzt. AFP ? FTP ? rsync ? SSH ? Wem das böhmische Dörfer sind, der braucht sie auch nicht. Aktivierte Dienste durchsehen, ob man Sicherheitseinstellungen hochstellen kann (z.B. SMB - Zugriff auf frühere Versionen nicht zulassen / sonst ist SMB1 aktiv).

Nächster Schritt: Im Router und auf der DS alles abschalten, was sich selbst Zugänge von außen oder nach außen konfiguriert. Zuerst weg mit UPnP und WPS. Faustregel: Ist es komfortabel, ist es auch gefährlich. Dann die vorhandenen Zugänge überprüfen, möglichst löschen. Wenn es im Router dicht ist, kann es auf der DS noch offen sein, ist dann nicht mehr direkt erreichbar. Übrig bleiben darf nur, was auf der DS (oder anderswo im Netz) aktiv ist und ordentlich abgesichert.

Jetzt - weil es jetzt überschaubar geworden ist - die paar übrigen Zugänge, Dienste und Programme einzeln überprüfen bzgl. Aktualität, Einstellungen (Passworte, 2FA etc.) und Absicherung, u.a. durch die Firewall oder Zertifikate. Das sollte man regelmäßig wiederholen, am besten einen festen wiederkehrenden Termin setzen. Wenn nur läuft, was muß, ist das kein Hexenwerk.

Normalerweise poste ich nicht 2x, in diesem Fall erlaube ich mir das hier einmal.

 

[servilianus]

Ich glaube - mit Hilfe eines Users - die Schwachstelle von ioBroker gefunden zu haben:

- Bei der Neu-Anlage von ioBroker im Docker-Syno wird kein Passwortschutz verlangt

- es gibt in ioBroker den Adapter Synology: "Erhalten Sie Status und steuern Sie Ihre NAS Synology".

- dort werden die Zugangsdaten hinterlegt.

Bingo: Zugriff auf die Diskstation durch Auslesen der entsprechenden Datei ist möglich.

 

[whitbread]

Naja - das wäre aber nur halbe Weg.
1.) Zugriff vom Docker-Container auf die NAS ist ja ein absolutes NoGo; die Trennung ist doch Sinn der Virtualisierung!
2.) Wenn ich den Syno-Adapter nutze (entgegen der NoGo-Regel) nutze ich doch nicht den Admin-Account dafür!
3.) Portweiterleitung (dazu ist schon alles gesagt)
Also nach der Logik müssen alle drei Fehler zugleich gemacht worden sein - ist das so bei den Betroffenen?!?

Klingt mir bis jetzt nicht nach einem SW-Bug. Ich fürchte eher, dass eine unsauber konfigurierte iobroker-Version genutzt wurde. Das erklärt aber noch nicht die Kenntnis des Admin-Passworts der Syno...

 

[Thonav]

Der Syno Adapter benötigt aber eben einen Admin.
Und dessen Daten liegen unverschlüsselt in einer ioBroker Datei.

 

[servilianus]

Zugriff vom Docker-Container auf die NAS ist ja ein absolutes NoGo; die Trennung ist doch Sinn der Virtualisierung!

Wenn ich den iobroker-Port 8081 nach außen hin durchreiche (um Gerätschaften von außerhalb des LAN zu steuern - und habe den ioBroker nicht durch ein Passwort abgesichert - und habe im Synology-Adapter ein Admin-Konto der Synology hinterlegt - ja, dann würde sogar ich mit meinen beschränkten Fähigkeiten gemeinsame Ordner fremder Leuts verschlüsseln können.

 

[Synchrotron]

Erschwerend kam hinzu, dass der iobroker ohne Patch zu knacken war, selbst wenn er gesichert war - das setzt dann schon etwas mehr voraus, erhöht aber die Zahl der verwundbaren Installationen von „kein Admin angelegt und PW vergeben“ um diejenigen „gesichert, aber nicht gepatcht “.

Wenn man dann den iobroker noch als Admin-GUI für seine DS einrichtet, incl. Anmeldedaten, hat man ein schönes Geschenkpaket für jeden geschnürt, der des Weges kommt und es einsammelt.

 

[whitbread]

Welche iobroker-Versionen waren bzw. sind denn betroffen?
Habe selbst derzeit nach meinen Crashes keine Instanz am Laufen, baue diese gerade auf Dockerbasis neu auf, da ich VMM derzeit nicht nutzen kann. An den Syno-Adapter gehört dann auch eine klare Warnung, damit der Übergriff vom iobroker auf die NAS unmöglich gemacht wird.
Damit können wir aber einen Ausbruch aus dem Docker-Container bzw. aus der VM ausschließen, oder?