Synology DiskStation Manager (DSM) 4.3-3776 - Multiple Vulnerabilities

[süno42]

Wobei ich mich ja auch die ganze Zeit bereits frage, weswegen du überhaupt eine Synology (resp. ein "Home"-NAS) gekauft hast, denn unter deinen Gesichtspunkten ähneln sie sich doch alle.
[...]
Du scheinst mir einfach nicht zur Zielgruppe zu gehören. Btw. denke ich das aber auch von Unternehmen, denn die "professionellen" DS und RS von Synology basieren ja auf der gleichen Firmware wie die günstigesten Home-DS. Als Unternehmen würde ich mich auch keiner Synology anvertrauen.

Hinterher ist man immer schlauer und weiß dann genau, was man sich gekauft hat. Gerade im Softwarebereich ist dies nicht immer sofort erkennbar. Der Normalverbraucher führt in der Regel keine Penetrationstests für gekaufte Software durch.

 

[kaylark]

Kurz zusammengefaßt, Personen die Zugriff auf Deine Diskstation haben (teilweise reicht eine Zugriffsmöglichkeit auf die Anmeldemaske im Webbrowser ohne Anmeldung aus), können Dir Daten stehlen.

Bei DSM 4.2 kommt hinzu, daß diese Software für CSRF-Angriffe anfällig ist, was nicht bedeuten muß, daß DSM 4.3 besser schützt. Es reicht im Prinzip aus, daß Du im Browser eine Webseite aufrufst, die selbst versteckt auf Deine Diskstation zugreift. So können Deine privaten Daten mit wenig Aufwand unkontrolliert in die weite Welt (Internet) gelangen.


Viele Grüße
Süno42

Meine DS ist über das Internet erreichbar. Heisst das, dass jeder, der bereits auf meine Anmeldemaske kommt, Daten stehlen kann - auch wenn er keine Anmeldedaten hat? Das wäre ja ein fatales Sicherheitsrisiko!!!
Ich verwende noch 4.1

Sollte ich den externen Zugriff kappen?

 

[jan_gagel]

Was auch noch eine interessante Frage wäre: Bezieht sich das auf die Anmeldung am DSM (Port 5000) oder sogar auf den normalen Apache (Port 80)? Ist die PhotoStation auch betroffen?

 

[süno42]

Meine DS ist über das Internet erreichbar. Heisst das, dass jeder, der bereits auf meine Anmeldemaske kommt, Daten stehlen kann - auch wenn er keine Anmeldedaten hat? Das wäre ja ein fatales Sicherheitsrisiko!!!
Ich verwende noch 4.1

Sollte ich den externen Zugriff kappen?

Ich habe nicht alle in dem Bericht angeführten Angriffsvarianten verifiziert. Aber demnach solltest Du davon ausgehen, daß dem so ist. Ich kann Dir nur sagen, wie ich verfahren würde. Ich persönlich würde den externen Zugriff unverzüglich kappen.

 

[MoritzDorn]

Hallo,

ich konnte bei zwei DSM 4.3 Systemen das Problem nicht nachstellen,
bei zwei Systemen mit DSM 4.2 konnte ich das Problem nachstellen,
bei Systemen, bei denen man sich nicht anmelden kann (DSM 4.2), konnte ich das Problem auch nicht nachstellen.

Daher meine Vermutung, dass DSM 4.3 davon aktuell nicht betroffen zu sein scheint, ggf. auf 4.3 aktualisieren und gut ist, die NSA hat eure Daten ja schon längst.

 

[süno42]

bei Systemen, bei denen man sich nicht anmelden kann (DSM 4.2), konnte ich das Problem auch nicht nachstellen.

Ich habe es mal getestet, Punkt 3 (Partial remote content download) funktioniert auch ohne Anmeldung mit DSM 4.2 (4.2-3211)

https://diskstation:5001/scripts/uistrings.cgi?lang=.////////////////////////////////////////////////////////////////////////////////////////../../../../../etc/synoinfo.conf​

Zugleich liefert das Beispiel auch Paßwörter für Benachrichtigungsdienste (z.B. E-Mail)


Viele Grüße
Süno42

 

[rauppe31]

Ich hab den DSM-Zugriff von aussen bei mir schon mal gesperrt.

 

[jan_gagel]

Ich habe es mal getestet, Punkt 3 (Partial remote content download) funktioniert auch ohne Anmeldung mit DSM 4.2 (4.2-3211)

https://diskstation:5001/scripts/uistrings.cgi?lang=.////////////////////////////////////////////////////////////////////////////////////////../../../../../etc/synoinfo.conf​

Zugleich liefert das Beispiel auch Paßwörter für Benachrichtigungsdienste (z.B. E-Mail)


Viele Grüße
Süno42

Danke, damit läßt sich ja was anfangen. Beide meiner DiskStations (siehe Signatur) liefern o. g. Datei via Port 5000. Via Port 80 kommt nur ein 404er zurück. Wenn jemand den Sys-Apache nicht von außen zugreifbar hat, sollte es also keine Probleme geben, richtig?

Unschön ist die Sache trotzdem.

 

[süno42]

Danke, damit läßt sich ja was anfangen. Beide meiner DiskStations (siehe Signatur) liefern o. g. Datei via Port 5000. Via Port 80 kommt nur ein 404er zurück. Wenn jemand den Sys-Apache nicht von außen zugreifbar hat, sollte es also keine Probleme geben, richtig?

Unschön ist die Sache trotzdem.

Ja, das sollte so unproblematisch sein.

 

[jahlives]

nicht vergessen, gerade im Firmenumfeld: die meisten erfolgreichen Angriffe kommen von Innen z.B. ein gekündigter Arbeitnehmer, der einen Groll auf die Firma hat. Bei solchen Lücken sagt der Merci

 

[raymond]

nicht vergessen, gerade im Firmenumfeld: die meisten erfolgreichen Angriffe kommen von Innen z.B. ein gekündigter Arbeitnehmer, der einen Groll auf die Firma hat. Bei solchen Lücken sagt der Merci

Da stimme ich zu: auch schonmal sowas gelesen.

 

[süno42]

Noch ein bißchen mehr Futter:

1. Partial remote content download (Version 2)
2. Zugriff auf diverse interne Daten ohne Authentifizierung

https://diskstation:5001/webfm/webUI/uistrings.cgi?lang=./////////////////////////////////////////////////////////////////////////////////////../../../../../etc/synoinfo.conf
https://diskstation:5001/phpsrc/web/sample.php
https://diskstation:5001/webapi/audiostation.auth
https://diskstation:5001/webfm/sql/SharingMgrTemp.sql

 

[hopeless]

Ich nutzte die AudioStation auf Port 8080.
Dort funktionieren bis auf den letzten link die Lücken leider auch alle.
Schade, dann muss ich wohl vorerst auf Musik von der DS, auf der Arbeit verzichten und mache vorerst alle Ports nach draussen dicht!

 

[Matthieu]

Der letzte Link funktioniert bei mir überhaupt nicht. Der vorletzte liefert lediglich eine kurze Info der API-Authentifizierung die aber nichts nützliches enthält. Die API gibt öfter mal derartige Antworten wenn ihr etwas fehlt oder man Infos anfordert die auch ohne Auth zugänglich sein müssen.
Was unterscheidet Link 1 von den oben genannten Lücken? Sieht für mich nach Code-Reuse aus oder einem Link aus (hab es mir mal gespart per SSH nachzusehen was es mit den Dateien auf sich hat).
Bei Link 2 versagt offenbar PHP. Betrifft aber nur diese eine Datei die wohl auf allen DSen identisch sein dürfte. Oder versteh ich da was falsch? Was ist so schlimm an dem bisschen Quelltext?

MfG Matthieu

 

[süno42]

@Matthieu:

Der erste Link ist analog zu dem bekannten Exploit. Dieses CGI-Skript hat eine wesentlich andere Dateigröße und beinhaltet einen anderen absoluten Pfad. Es gibt noch diverse andere dieser CGIs mit ähnlichem Verhalten. Es scheint so, daß die Wiederverwendung des Codes auf viel Codeduplizierung basiert. Zumindest hat es den Anschein. Genaueres ließe sich nur durch eine genaue Analyse der verlinkten Bibliotheken sagen.

Die anderen Links sollen verdeutlichen, daß bei den Zugriffsberechtigungen keine wirkliche Struktur zu erkennen ist. Ein Großteil der Dateien scheint ohne Authentifizierung zugreifbar zu sein, wobei darunter auch Daten sind, deren Offenbarung durch einen direkten Zugriff offensichtlich nicht gewollt ist. Wofür soll man wohl SQL-Skripte oder PHP-Quellcode aus dem Verzeichnis herunterladen können.

Link 3 macht es eventuell erforderlich, daß diese Datei direkt zugreifbar ist, aber derzeit kann ich es mir nicht erschließen, für welchen Anwendungsfall das gelten soll.


Insgesamt wirft dies ein schlechtes Bild auf Synology.


Viele Grüße
Süno42

 

[hopeless]

Was ist so schlimm an dem bisschen Quelltext?

Sorry, ich habe das evtl. falsch Geschrieben, meine Aussage bezog sich auf den Link in #26. Dort liefert die DS u.a.folgendes aus:

SYNOJSLIB_Strings={};
_s=SYNOJSLIB_Strings;
_s.['unique']='die Seriennummer der DS';
_s.['eventmail1']='echte emailadresse' (vom admin);
_s.['eventmail2']='noch eine';
_s.['eventuser']='dazu gehöriger Username/Anmeldename' (vom admin);
_s.['eventpasscrypted']='dazugehöriges (verschlüsseltes) Passwort' (vom admin);

und das sind Sachen, die ein Server auf keinen Fall so einfach herausgeben sollte.

 

[juwi]

Der letzte Link funktioniert bei mir überhaupt nicht. Der vorletzte liefert lediglich eine kurze Info der API-Authentifizierung die aber nichts nützliches enthält. Die API gibt öfter mal derartige Antworten wenn ihr etwas fehlt oder man Infos anfordert die auch ohne Auth zugänglich sein müssen.
Was unterscheidet Link 1 von den oben genannten Lücken? Sieht für mich nach Code-Reuse aus oder einem Link aus (hab es mir mal gespart per SSH nachzusehen was es mit den Dateien auf sich hat).
Bei Link 2 versagt offenbar PHP. Betrifft aber nur diese eine Datei die wohl auf allen DSen identisch sein dürfte. Oder versteh ich da was falsch? Was ist so schlimm an dem bisschen Quelltext?

MfG Matthieu

Was mich u.a. stört sind natürlich die freie Verfügbarkeit aller benutzten Ports sowie die Emailadresse vom Admin usw.
Auf der anderen Seite kommt man eh nur via VPN beim mir aufs NAS. Von daher ist es für meinen Anwendungsfall unproblematisch.

 

[Matthieu]

Sorry, ich habe das evtl. falsch Geschrieben, meine Aussage bezog sich auf den Link in #26. Dort liefert die DS u.a.folgendes aus:

Entschuldige, ich hab vorhin vergessen explizit auf den Beitrag von süno42 zu verweisen. Ich kann deine Reaktion voll und ganz verstehen. Ich habe meinen https-Zugang (auch wenn er nicht über den Standard-Port ging und deswegen recht selten von potenziellen Angreifern abgeklopft wird) mittlerweile ebenfalls geschlossen. Mein Beitrag bezog sich aber explizit auf süno42.

@süno42:
Was die Content Download-Lücke angeht, müssen wir abwarten wie lange Synology benötigt um das zu schließen. Ob es in einer Datei oder in 10 vorkommt, spielt für mich aber nicht wirklich eine Rolle - wichtig ist nur dass Synology alle Lücken schließt und nicht eine Datei vergisst.
Den letzten Link scheint hier bisher auch niemand reproduzieren zu können.
Zur API: Das ist ein sehr komplexes Thema welches Synology jetzt langsam Stück für Stück dokumentiert. Wenn es dich interessiert, such mal nach "dsmwebapi" oder auch nach meinem CNAT-Tool. Da gibt es reichlich Infos. Der Antwort der Auth-Datei kann eine Anwendung beispielsweise entnehmen, ob Domain- oder LDAP-User Zugriff haben.

MfG Matthieu

 

[BavariaR]

Sieht nicht so aus wie wenn die Sicherheitslücke mit dem DSM 4.3-3776 -1 update geschlossen worden wäre :-((((

 

[Matthieu]

Sieht nicht so aus wie wenn die Sicherheitslücke mit dem DSM 4.3-3776 -1 update geschlossen worden wäre :-((((

Die ersten Anzeichen lt. Forum für 3776-1 gab es auch, bevor die Lücken bekannt wurden ...

MfG Matthieu