DSM 6.x und darunter Sicherheit

[jahlives]

Für alle die noch mit einer Vor-1337-Version unterwegs sind http://secunia.com/advisories/41487/ und noch das Original dazu http://archives.neohapsis.com/archives/fulldisclosure/2010-09/0375.html

 

[Matthieu]

Ich hab jetzt aus Interesse mal nach QNAP gesucht und die sind auch schon aktenkundig:
http://archives.neohapsis.com/archives/bugtraq/2009-09/0169.html

MfG Matthieu

 

[thedude]

Könnt ihr sowas nicht an etwas prominenterer Stelle im Forum anpinnen?

gruss
dude

 

[itari]

Aber so richtig verstehe ich die Gefahr nicht ... da gelangt ein wenig JavaScript via eines Logfiles auf die DS ... aber was kann das ausrichten? Solange man da keine gültigen AJAX-Aufrufe generiert, kann doch da gar nichts passieren. Und wer kennt schon die richtigen AJAX-Aufrufe? Kaum einer ...

Itari

 

[jahlives]

@itari
Klar die Gefahr ist nicht wirklich immens. Shell Kommandos sind damit ja nicht möglich. Trotzdem so was darf nicht sein

User (example.comnone)): "/><script>alert("Check Point VDT"</script>
331 Password required for "/><script>alert("Check Point VDT"</script>

Das ist Basic: Never trust incoming data. Wenn noch nichtmal ein html strip und ein check auf verdächtige Zeichen gemacht wird, dann finde ich persönlich sehr schwach.
Ein simples striptags und die Gefahr wäre gebannt. Das wäre noch nicht mal eine 1Cent-Kosten-Lösung.

 

[itari]

So ganz kann ich dem nicht unbedingt folgen: Für Benutzernamen/Kennworte sollten alle Zeichen des Unicodes möglich sein. Ob die dann gequotet werden oder nicht, ist eigentlich egal bzw, wird vielleicht sogar (und irgendwo dann wieder reversiert). Die Frage ist ja nur, ob sie auch so im Protokoll drinn stehen sollen oder nicht und ob sie dort überhaupt etwas auslösen. In reinen HTML-Textfelder wird ja nichts Skriptiges wirksam ... sieht halt nur 'gefährlich aus'.

Meinem Gefühl nach macht sich da jemand an der falschen Stelle mächtig wichtig ... aber vielleicht habe ich es ja auch nicht wirklich verstanden.

Itari

 

[jahlives]

Habe das mal auf einer 1141 Firmware probiert und der Text steht wirklich "nur" einfach im Log und sonst nix weiter. Von dem her wirklich nicht so gefährlich. Scheint zumindest bei der Anzeige nicht ausgeführt zu werden.

Trotzdem zumindest unschön, denn es zeigt, dass imho nicht ganz so sauber gearbeitet wurde. Da hat man auf die Prüfung der Daten nicht wirklich wert gelegt

Kommando zurück: Bei einem Klick auf Speichern und einem öffnen im Browser wird der Schnippel ausgeführt!!
Noch ein Bildchen davon

 

[jahlives]

Auch bei der 1337 wird das Script beim Speichern ausgeführt, wenn es kein JS Blocker verbietet!

 

[itari]

Bei einem Klick auf Speichern und einem öffnen im Browser wird der Schnippel ausgeführt!!

Ja toll ... und wo wird es ausgeführt? Im Browser auf dem PC ... ich sagte doch schon, wenn damit kein AJAX-Call ausgeführt wird, ist das nur ne nette Spielerei, denn es wirkt sich ja nicht auf die DS aus. Oder hast du es hinbekommen, eine Datei auf der DS zum Beispiel zu löschen?

Itari

 

[thedude]

Ich glaube in diesem Fall geht es nicht darum die DS anzugreifen, sondern "über Bande" den PC. Und das ist unschön. Das kann man drehen und wenden wie man will oder?

gruss
dude

 

[itari]

Ich glaube in diesem Fall geht es nicht darum die DS anzugreifen, sondern "über Bande" den PC. Und das ist unschön. Das kann man drehen und wenden wie man will oder?

Es handelt sich um JavaScript ... also um etwas, was im Browser sowieso bei fast jeder Webseite abläuft. Man mag darüber streiten wollen, ob JavaScript für den PC 'gefährlich' ist, auf dem der Browser läuft. Aber da sind wir, sobald wir mit den DSM aufrufen eigentlich bereits hinweg, denn dieser arbeitet massiv mit JavaScript.

Die einzige berechtigte Sorge wäre, ob man mittels JavaScript auch auf dem Web-Server Unsinn anstellen kann. Das kann man durch entsprechende unabgesicherte AJAX-Calls (welche dann cgi-Skripte auf dem Server mit 'root'-Rechten ausführen). Das war ja meine Feststellung, ob es an dieser Stelle Probleme gibt oder ausgetestet geben könnte ... dazu gab es aber weder in den verlinkten Beiträgen noch hier, eine fundierte Aussage. Ich würde schon gerne erfahren wollen, was genau das 'Gefährliche' ist.

Itari

 

[thedude]

Es handelt sich um JavaScript ... also um etwas, was im Browser sowieso bei fast jeder Webseite abläuft. Man mag darüber streiten wollen, ob JavaScript für den PC 'gefährlich' ist, auf dem der Browser läuft. Aber da sind wir, sobald wir mit den DSM aufrufen eigentlich bereits hinweg, denn dieser arbeitet massiv mit JavaScript.

JavaScript kann m.M. natürlich gefährlich für den PC werden. Es ist neben Flash ja eines der Haupteinfallstore für Maleware durch den Browser. (Ich erlaube nicht jeder Website das ausführen von JS und Flash sondern führe mit NoScript eine Whitelist.) Und wenn nun jemand von aussen irgendwie Javascript im DSM unterbringt welches dann bei dir lokal auf dem PC ausgeführt wird und irgendeine Sicherheitslücke ausnutzt (also klassisches XSS) um dann einen Trojaner/Virus oder sonst was runterlädt und bei dir installiert dann ist das schon ein Problem. Oder verstehe ich den Sachverhalt hier vollends verkehrt?

gruss
dude

 

[jahlives]

Ich glaube in diesem Fall geht es nicht darum die DS anzugreifen, sondern "über Bande" den PC. Und das ist unschön. Das kann man drehen und wenden wie man will oder?

gruss
dude

Ganz genau. Über den PC bei dem ich weiss das der DSM admin angemeldet ist einen Angriff auf die DS. Da kann ich so einfach ein externes Payload runterladen und dem PC unterschieben z.b. ein Keylogger um das admin PW rauszuholen.
Ich weiss itari, es ist keine direkte Bedrohung für die DS, aber über den PC des admins wird es auch zu einer für die DS.
Oder man könnte versuchen die Cookies auszulesen. An das Cookie des DSM würde man wohl rankommen.

Und das Script läuft mit lokalen Rechten im Browser. Mehr Rechte ist für ein Javascript nicht zu holen

 

[itari]

Im Moment kann ich der Diskussion nicht mehr folgen.

Ich dachte, es geht um eine Geschichte, die die DS in irgendeiner Weise gefährdet. Das scheint jetzt nicht der Fall zu sein. Die Diskussion, wie man seinen Browser vor 'gefährlichem' JavaScript schützt, ist in meinen Augen eine ganz andere Baustelle.

Itari

 

[jahlives]

Ich habe das jetzt noch mit ein paar JS-Payloads probiert. Konnte problemlos einen JS-Keylogger nachladen. Man könnte auch ein gefaktes Login Fenster vom DSM präsentieren mit der Mitteilung die Session sei abgelaufen und der Bitte sich nochmals anzumelden. Wenn der User nicht ganz genau auf die URL schaut, dann schickt er mir damit sein admin PW.
Konnte sogar mit einem JS-Portscanner mein LAN scannen und die Resultate an einen externen Server schicken!
Den EICAR Testvirus konnte ich auch problemlos nachladen (allerdings schlug dann Norton an)
Die Möglichkeiten für diese Lücke sind beinahe unbegrenzt. Bei unvorsichtigen Usern könnte man auch bat und cmd Files zur Ausführung bringen, mit Zugriff auf den lokalen Windows Script Host.

Klar das meiste wird von einer guten Security Software auf dem Client abgefangen. Aber es darf doch nicht sein, dass eine Kiste (DS) zu der ich eine Vertrauensstellung haben, dem User solche Mist unterschieben kann.

Zur Zeit ist meine Empfehlung: FTP Zugriff komplett abschalten. Am besten FTP Service runternehmen

Btw: Ich könnte mir gut vorstellen, dass FTP nicht die einzige App ist, die gescheiterte Logins 1:1 ins Log schreibt. Daher könnte theoretisch jeder Service der einen Login bietet und in den DSM Logs auftaucht, diese Lücke nutzen!
Dabei wird mir wirklich etwas schlecht

Das mit den anderen Services teste ich mal später noch.
Mir reicht das jedoch als Proof-of-Concept zur Aussage: Der DSM hat eine riesige Sicherheitslücke, welche es ermöglicht fremden Code mit lokalen Rechten auf dem Client auszuführen. Das sollte imho ein Grund für einen sofortigen Patch sein. Synolgy weiss es hat aber bis jetzt noch überhaupt nicht reagiert

Ich habe den angefügten JS-Port-Scanner problemlos testen können

 

[thedude]

@Itari: Die DS wird einfach als Angriffsvector für das LAN genutzt indem sie steht. Das Szenario ist einfach: Man hat zuhause die DS stehen. FTP von aussen offen. Jemand versucht sich einzuloggen und nutzt dabei die im Advisory genannte Sicherheitslücke aus. Die DS schreibt den dadruch eingeschläusten code ins log als wäre es ein normaler Zugriffsversuch. Schaut man sich nun vom PC aus das log an (natürlich hat man für seine DS JavaScript erlaubt - wie du schon sachtest tut der DSM ja sonst auch gar nicht) kommt der code zur Ausführung. Es kann nun wie es jahlives ja schon getestet hat beliebiger code aus dem Internet nachgeladen werden. Viren, Trojaner, Keylogger was Du willst. Um den PC zu infizieren. Mit vollen Rechten u.U. Dadurch ist alles in Gefahr was Du in Deinem LAN hast samt DS und der Daten darauf. Das ist epic fail wie man so schön sagt.

@jahlives: Laut dem advisory soll das Problem in 3.0-1337 gefixt sein. ist dem etwas nicht so?

Ich kann auch nur jedem raten FTP am Router dicht zu machen, solange diese Sache nicht genau geklärt ist. Vorsicht ist besser als Nachsicht.

gruss
dude

 

[jahlives]

@thedude
Ich mache so einen Lärm darum, weil es entgegen der Aussage im Advisory in 1337 eben IMMER noch nicht gefixt ist!
FTP am Router dichtmachen bringt nicht viel, weil damit das Problem bei Zugriffen aus dem LAN immer noch nicht gelöst ist. Gerade bei Firmen könnte das durch einen bösen LAN User gnadenlos ausgenutzt werden. Was es dopplelt so gefährlich macht, weil interne User meist Wissen über die Topographie des LANs haben

@itari
Sorry aber wenn ich mit Hilfe der DS ein fremdes Netzwerk scannnen kann, wohlgemerkt ein LAN!!, dann ist das schon ein Problem der DS. Synolgy hat hier einen "perfekten" Hook in der Firmware um mehr oder weniger beliebigen Code zu laden und lokal auf der Kiste des admins auszuführen. Da klau ich doch einfach den DSM Login Cookie und bin eingeloggt, wenn der DSM aus dem Internet erreichbar ist.
Klar es braucht noch mindestens eine Aktion des Users um das Ganze zu starten. Ganz automatisch geht es ned.

Also zumindest bei telnet wird der so manipulierte Login Name nicht in die Logs übernommen. ssh kann ich ned testen weil mein ssh nur mit Zertifikaten läuft. Das kriegt die Firmware bei Anmeldefehlern ned mit

Probiert das doch bei Euch auch aus. Und meldet es an Synology mit Firmware Version und Modellname. Je mehr User "meckern" umso eher wird es hoffentlich einen Fix geben dafür.
Ganz ehrlich wäre es für mich ein Grund Synology den Rücken zu kehren, wenn das nicht inner kürzester Zeit gefixt wird

 

[itari]

Wie gesagt, ich verstehe es nicht. Bin zu dumm für sowas

Mir ist schleierhaft, wie du mit JavaScript ein LAN ausspähen willst. Würde ich gerne mal machen. Ich würde auch gerne die Fernsteuerung einer DS oder eines LANs mittels PC-Browser-JavaScript gerne in mein AdminTool aufnehmen - hab nur keinen Plan, wie das gehen soll. Und klar, ich würde auch gerne die Admin-Anmeldung capturen wollen ... Und das alles auf einmal, wenn ich mir mein FTP-Protokoll im DSM anschaue ... Poste mir mal dazu eine Anleitung

Itari

 

[jahlives]

@itari
Mit Javascript kann man einen Portscanner basteln (siehe Anhang). Man kann mittels AJAX unsichtbar Daten nachladen. Man könnte mit JS die lokalen Cookies (wohl auch das Login Cookie vom DSM) auslesen. Man könnte über JS den Verlauf in deinem Browser so manipulieren, dass du beim Klick auf zurück nicht auf der eigentlich erwarteten Seite landest. Man könnte eine gefakte Login Seite vom DSM anzeigen und sich das admin PW zuschicken lassen.
Man könnte einen Keylogger nachladen. Man könnte dem User cmd resp bat Files unterschieben.
Und v.a. hat man ein JS das mit den höchst möglichen Rechten läuft. Theoretisch kann man bei einem lokal ausgeführten Script durch geschickte Programmierung auch auf das lokale Filesystem des Clients zugreifen. Ich will jetzt nicht sagen was das bedeuten würde

 

[thedude]

FTP am Router dichtmachen bringt nicht viel, weil damit das Problem bei Zugriffen aus dem LAN immer noch nicht gelöst ist.

Klar aus Richtung LAN schützt das nicht. Allerdings schützt es alle Privatleute die momentan FTP aus dem Internet offen haben. Und wer als Privatman seinem eigenen LAN nicht trauen kann, hat ganz andere Sorgen. Klar es muss SCHLEUNIGST gefixt werden. Aber FTP zu machen oder gar ganz deaktivieren hilft als adhoc Lösung schonmal weiter.

@Itari: Ziehst Du diese Geschichte absichtlich ins lächerliche?

gruss
dude