DSM 6.x und darunter Sicherheit

[jahlives]

Und wer als Privatman seinem eigenen LAN nicht trauen kann, hat ganz andere Sorgen.

Du kannst deinem LAN nicht mehr trauen, wenn du auch nur einmal das FTP Log im DSM geöffnet hast und als html Seite im Client (Button Speichern) angeschaut hast
Ich würde einen Angriff so machen: Erstmal einen Login mit dem manipulierten Username, damit das Script geladen werden kann. Dann um das zu verbergen etwa 100 Login Versuche mit "normalen" Usern (verschiedene Proxies nutzen wegen auto Block) Damit wäre die eigentlich gefährlich Logmeldung im DSM auf den ersten Blick nicht mehr zu sehen und viele admins würden sich das Log wohl runterladen, um sich das genauer anzuschauen. Und tschüss admin pc! Weil die html Seite alle Logeinträge auf einmal anzeigt, kommt es gleich zur Ausfürhung auch wenn es "nur" die 7017. Logmeldung ist, die den JS Code enthält.
Und man ist ja nicht nur auf JS angewiesen. html kennt noch andere nette Tags z.B. objects für Flash oder JavaApplets (stellt sich dann allerdings die Frage ob man den Aufruf in 100 Zeichen Code unterbringen kann) oder iframes

 

[itari]

@itari
Mit Javascript kann man einen Portscanner basteln (siehe Anhang).

hmm, ja ... aber das würde man sicherlich auch einfach hinbekommen, den dafür braucht man ja keine besonderen Rechte

Man kann mittels AJAX unsichtbar Daten nachladen.

Ja, aber das kann man ja auch auf ganz normalen Webseiten machen. Davon geht alleine keine Gefahr aus, weil man ja nicht so ohne weiteres auf andere URLs zugreifen kann (sondern nur auf seine eigenen). Und ja das habe ich ja auch eingeräumt, das man sich per AJAX-Calls Zugriff auf die cgi-Skripte der DS verschaffen kann, wenn man (1) weiß, wie die Aufrufe funktionieren (Namen, Optionen usw.) und (2), wenn diese Aufrufe nicht von den cgi-Skripten validiert werden - darüber wurde aber nichts berichtet.

Man könnte mit JS die lokalen Cookies (wohl auch das Login Cookie vom DSM) auslesen.

Spannend, aber das als Angriff zu werten, was eigentlich sowieso jede Webseite macht. Also nicht wirklich etwas sonderlich beunruhigendes ... jedes Sex-Seite im Web macht das ...

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.

Ja, das ist manchmal unangenehm; aber ein Angriff ist das nicht wirklich ... lediglich eine Irritation. So ungefähr wie wenn ich eine unsichtbare Seite über eine Webseite lege, um deine Klicks abzufangen. Ist halt ne nette Technik.

Man könnte eine gefakte Login Seite vom DSM anzeigen und sich das admin PW zuschicken lassen.

Ja, aber dazu muss man nicht mit JavaScript so tricksen, das kann man auch einfacher machen. Siehe Kommentar eins vorher.

Man könnte einen Keylogger nachladen.

Das habe ich nicht verstanden ... Keylogger, die auf der jeweiligen Webseite die Tasten-Events abfangen, ist doch was völlig Normales. Und dass du auf fremden Seiten diese Event abfangen kannst, hab ich noch nicht gesehen - würde mich sehr interessieren. Dass du außerhalb des Browser, die Tastatur mitbekommst, halte ich für ein schwerwiegenden Browserfehler ... wenn das ginge, dann hat der Browserhersteller sein Versprechen nicht gehalten und muss nachbessern. Ist mir aber nicht wirklich bekannt, dass das geht.

Man könnte dem User cmd resp bat Files unterschieben.

Das geht nur in 'schlechten' Browsern (IE) und da eigentlich nur dann, wenn du bewußt die Sicherheit aufmachst. Ansonsten wäre das auch ein Browserfehler ...

Und v.a. hat man ein JS das mit den höchst möglichen Rechten läuft.

JavaScript läuft im Browser (und sonst nirgends) und bekommt die Rechte des Users, der den Browser aufruft. Völlig normal und nicht zu beanstanden.

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

Ja, ich habe selbst solche Webeditoren und Zeichentools für den IE geschrieben. Das geht aber auch nur unter dem IE einfach; ansonsten brauchst immer Unterstützung: richtige Java-Applets, z.B. in der File-Station der Zugriff auf das lokale Dateisystem oder eben Flash-Plugin oder andere Plugins oder Browsererweiterungen (Gears). Und bei allen diesen Plugins musste einmal ja zu gesagt haben. Also z.B. ist die File-Station auf der DS in dieser Sicht richtig 'gefährlich'.

Itari

PS. Ich ziehe nichts ins Lächerliche; ich möchte gerne verstehen, was das 'Gefährliche' ist und nicht nur vage Vermutungen hören, die einen nicht wirklich irgendwohin bringen.

 

[jahlives]

Also itari: Zum ersten ist das gefährlich weil die meisten Browser per default viel laxere Sicherheitseinstellungen für lokale Seite haben (also file:/// Seiten)
zum zweiten war der JS Keylogger nur ein Bsp. Was spricht dagegen via einem geschickten JS eine "echten" keylogger zu laden (auf Systembasis)? Mit Flash kann man auch ganz nette Sachen machen. Das ist ein klassischer Drive-By-Download, bei dem nur noch der Browser resp eine Sicherheitssoftware eine Chance hat etwas auszurichten. Und die meisten Sicherheitstools haben fürs LAN ja gesonderte Vertrauensstellungen.
Eigentlich müsste Synology schreiben: "Wir empfehlen ihnen dringend eine Sicherheitssoftware zu installieren und regelmässig upzudaten, wenn Sie den DSM nutzen wollen (v.a. die Logs), denn wir können nicht garantieren, dass wir Ihnen nicht seitens des DSM eventuell ungeprüften 3rd Party Code unterschieben, der bei ihnen lokal ausgeführt wird. Dies da wir leider kein Budget mehr hatten, um die Logzeilen vor der Ausgabe im DSM mittels einer htmlentities-Funktion zu entschärfen."
Macht sich gut als Werbeslogan, oder?

 

[thedude]

Genau. Wie ich schon sagte ist der DSM mit der Lücke erstmal nur ein Einfallstor für code der wiederum anderen code aus Netz besorgen kann um damit wiederum flash zu exploiten oder irgendeine andere im Browser oder seinen Plugins vorhandene Lücken auszunutzen.

Sicher das ist dann eine Lücke im Browser oder Plugin. Stimmt. Aber die Lücke im DSM ermöglicht "über Bande" das ausnutzen wiederum dieser Lücken. Eben auch für Leute die sonst sehr drauf achten auf welchen Seiten sie sich rumtreiben im Internet. Beim nächsten nutzen des DSM erwischt es sie halt. Und wenn man dann nicht alles up to date hat auf seinem system oder eine 0-day Lücke irgendwo hat steht man doof da. Mehr wollen jahlives und ich ja gar nicht sagen.

gruss
dude

 

[itari]

Ich würde gerne lernen wollen, wie man das macht,

- mit file://-Webseiten Dateien zu manipulieren,
- einen 'echten' Keylogger zu laden,
- mit JavaScript ein Flash-Script zu landen, welche ein System korrumpiert, was nur dann funktioniert, wenn man auch JavaScript einsetzt

Dein Vorschlag 'Benutzereingaben' zu quotieren (die htmlentities-Funktion haben sie ja nicht, weil sie kein PHP einsetzen) ist sicherlich wünschenwert und ich habe auch nichts dagegen, dass Synology dies bei der Ausgabe von Logfiles und Protokollen tut. Wie werden ja sehen, ob Synology dazu etwas einfällt.

Itari

 

[jahlives]

Ich würde gerne lernen wollen, wie man das macht,

- mit file://-Webseiten Datein zu manipulieren,
- einen 'echten' Keylogger zu laden,
- mit JavaScript ein Flash-Script zu landen, welche ein System korrumpiert, was nur dann funktioniert, wenn man auch JavaScript einsetzt

@itari
- Ich will keine Webeiten Dateien auf der DS ändern. Ich lade dir lokal beim Betrachten der runtergeladenen Verbindungslogs ein Javascript.
- wie theDude schon sagte Lücken im Browser, das geht leider schon
- wieso mit Javascript? Ich gebe als Login Name beim ftp einfach ein flash Objekt an (musst nur sicherstellen, dass der Aufruf in 100 Zeichen passt)

Dies ist ehrlich gesagt eine der grössten Lücken, die mir in einer Websoftware jemals untergkommen ist. Das war die root-Sache in Versionen < 1337 ein Klacks dagegen

 

[jahlives]

@itari
Du hast natürlich recht, dass dies keine direkte Bedrohung für die DS ist. Dem will ich auch gar nicht widersprechen. Obwohl für mich die Sache insofern noch nicht gegessen ist als dass ich nicht weiss, welche Zeilen aus den Logs sonst noch so in den diversen DSM Logs angezeigt werden. Wenn die auch Usereingaben 1:1 übernehmen, dann ist fast kein loggender Service gefeilt davor.
Und wir hätten immer noch den Punkt offen, dass es gemäss dem Security Heini aus dem Advisory (Secunia hat es überigens auch draussen) möglich sein könnte Code in den DSM zu "injecten" und damit direkt beim Betrachten der Logs ausführen. Könnte mir zwar vorstellen, dass dies genau der Teil ist, den Synology mit 1337 "gefixt" hat. Wobei sie dann vergessen hätten, dass sie diesen "Code" immer noch in den Logs haben und eine DSM Option bieten, den "Code" auf den Client zu übertragen!
Dann hätten sie den DSM geschützt und das Problem nur noch auf den Clients des admins, der seine Logiles lokal betrachten will
Wobei ich mich frage welche der beiden Optionen "besser" wäre: Denn ein Flankenangriff via Client wird wohl mehr Angriffpunkte bieten als eine Frontalattacke auf den DSM.

Wenn es wirklich so ist und sie diesen Teil (Code injection ins JS des DSM) gefixt haben mit der aktuellen Firmware, dann haben sie wirklich gechafft das Kamel vom Schwanz her ins Nadelöhr zu fädeln. Es ist für mich keine Frage des "könnte man allenfalls in den Syslog Files bereits abfangen", sondern das MUSS man bereits dort abfangen. Es kann doch nicht sein, dass es der Applikation überlassen wird. So muss man jede einzelne App schützen. Wenn man hingegen vor dem Eintrag ins Syslog bereits statt < < verwenden würde, wären auf einen Schlag alle Apps geschützt, die mit den Logfiles hantieren. Der Aufwand jede einzelne App zu schützen dürfte bei weitem grösser sein als der Aufwand das einmal sauber in den Syslog resp den Kern der Firmware zu implementieren

Gruss

tobi

 

[Tribun]

Ich kenne die DS und AJAX lediglich aus Sicht des Anwenders.
Die Einschätzung, wann, wie und wo ein Sicherheitsrisiko auftritt, vermag ich aus meinem derzeitigen Kenntnisstand nicht einzuschätzen.

Ich gehe mit euch konform, daß die größte Schwachstelle im System derjenige ist, welcher vor dem Monitor sitzt.

Obwohl eine gesundes Maß an Paranoia die Überlebensfähigkeit erhöht, betrachte ich dies etwas entspannter:

• Eine DS, die vom Internet, (evtl. rund um die Uhr) aus erreichbar ist, ist nicht LAN, sondern Internet! Insofern stimme ich TheDude zu, seinem LAN durchaus vertrauen zu können.
• Der User der mit vollen adminstrativen Rechten (ohne Benutzerkontensteuerung von Vista, Win7) im Internet unterwegs ist, hat enormes Zerstörungspotential. Mal ehrlich, wer arbeitet als Hauptbenutzer oder sogar als Admin täglich am PC?
• Eine präparierte Webseite kann mir ebenso eine Textdatei mit FTP-Kommandos im Windowsverzeichnis ablegen. Der Download wird initiert, der Aufruf der Progis erfolgt über den Run-Schlüssel im HKCU-Stamm . .
  Ab dem nächsten Windowsneustart nimmt dieser 'Dämon' seine Arbeit auf. Da ist Windows gefährdeter als andere OS.
• Der 'sichereste' Rechner ist der, der nicht 'IM NETZ' ist.
• Wenn die Authorisierung zum adminstrativen Zugriff auf die DS mittels Zertifikaten, harter ständig geänderter Passworte erfolgt, diese sich hinter einem Router mit weniger offensichtlichen 'offenen' Ports zur Weiterleitung ODER der administrative Zugriff nur innerhalb des LAN gestattet ist, relativiert das doch die Risiken.
• Offene (web-) Verzeichnisse kann ich nebenbei mit .htaccess dichtmachen
• Solange kein unauthorisierter ssh-Zugriff auf das Herz der DS erfolgen kann, ist doch die Schadwirkung auf die DS auch wieder geringer
• müssen wir heute 'Angst' Key-Loggern haben, sind es 'morgen' Gedankenlesegeräte . . .
• Einen Rundum Voll-Kasko-Schutz gibt es nicht, gab es nicht und wird es NIE geben!
• unterschiediche Konten für Windowsanmeldung und DS reduzieren ebenso die Risiken
• Die einzigste Chance ist doch das Minimieren evtl. Risiken, Trennen von öffentlich zugänglicher und Privater/Produktiv/Backup-Systeme, Minimierung eines administrativen Personenkreises.
• Und was im Browser so abläuft, sollte einem Virenscanner schon auffallen
• Und wenn die Paranoia so weit fortgeschritten ist, kann man ein eigens Benutzerkonto auf dem PC einrichten, welches ausschließlich für administrativen Zugriff zum DSM vorgesehen ist. DER Browser wird unter diesen Konto gestartet, evtl. DNS und Gateway auf 127.0.0.1 umleiten und Ruhe ist im Schacht!, da wird nix mehr nachgeladen, was dem Client schaden kann. Oder eine Virtualmachine (Microsoft Virtual PC oder Virtuozzo) wird für die Adminstration benutzt, um den Client 'sauber' zu halten.

Ich will's ja mit der DS einfacher haben . .

Tribun

 

[jahlives]

syno.allen hat mit gerade meine Vermutung bestätigt: Mittels 1337 wurde nur der Fix für die Code Injection direkt im DSM gemacht. Der Download Teil wurde "vergessen".
Also ist/war es bei alten Versionen sogar möglich direkte code Injection ins JS des DSM zu machen.
Bei der aktuellen firmware nur noch über den Download der Datei in den lokalen admib Client PC

@tribun
für dich ist es also okay wenn eine Applikation ungeprüfte/ungefilterte Usereigaben übernimmt und weiteren Apps zur Verfügung stellt? Hauptsache es ist bequem/einfach?
Es stimmt dass das grösste Problem eines Systems davor sitzt. Nur wenn die DS diese Daten gar nicht ausliefern würde, dann könnte auch ein noch so grosser DAU nicht reinfallen

 

[Tribun]

@jahlives
Nö, nach der Chronologie der Post besteht das Problem doch nur, wenn eine präparierte Anmeldung hinterlassen wurde, die möglicherweise 'ausführbaren' Code enthält, das Logfile abgespeichert wurde und wieder im Browser betrachtet wurde (?) Dann betrifft es immer noch nur die Browsersession.

Was die

ungeprüfte/ungefilterte Usereigaben

betrifft, dafür ist es ja eine "Protokollierung" - also eine Erfassung dessen, was getan wird.
Daß diese 'Inhalte' interpretierbar sind, ist nicht ok, da stimme ich dir zu!
Nur ist es dann ein allgemeines Problem von HtmL/PHP, die den 'Text' von 'Irgendwoher' aufbereiten und in diesem Falle eine Sicherheitslücke aufreißen. Es wird ebenso unmöglich sein, jede Buchstaben-Zahlenkombination zu verifizieren, die den Interpreter passiert, daß es sich hierbei nicht um einen Befehl oder ein ausführbarens Script handeln darf. Ein Restrisiko wird immer bestehen, weil alle Programme/Routinen IMMER komplexer werden.

Für eine permanet im Internet hängende und damit Angriffen ausgesetzte DS sind deine Befürchtungen durchaus berechtigt.

Nur meine ich, daß es darüberhinaus gravierendere Risiken gibt.

Und wie gesagt bei forteschrittener Paranoia, kann ich per VirtualMachine Zugriff zur DS herstellen. Somit ein abgeschlossenes Biotop.

meint Tribun

PS: Rauchen KANN tödlich sein. Das Leben IST (immer) tödlich!

 

[jahlives]

@jahlives
Nö, nach der Chronologie der Post besteht das Problem doch nur, wenn eine präparierte Anmeldung hinterlassen wurde, die möglicherweise 'ausführbaren' Code enthält, das Logfile abgespeichert wurde und wieder im Browser betrachtet wurde (?) Dann betrifft es immer noch nur die Browsersession.

Was die betrifft, dafür ist es ja eine "Protokollierung" - also eine Erfassung dessen, was getan wird.
Daß diese 'Inhalte' interpretierbar sind, ist nicht ok, da stimme ich dir zu!
Nur ist es dann ein allgemeines Problem von HtmL/PHP, die den 'Text' von 'Irgendwoher' aufbereiten und in diesem Falle eine Sicherheitslücke aufreißen. Es wird ebenso unmöglich sein, jede Buchstaben-Zahlenkombination zu verifizieren, die den Interpreter passiert, daß es sich hierbei nicht um einen Befehl oder ein ausführbarens Script handeln darf. Ein Restrisiko wird immer bestehen, weil alle Programme/Routinen IMMER komplexer werden.

Für eine permanet im Internet hängende und damit Angriffen ausgesetzte DS sind deine Befürchtungen durchaus berechtigt.

Nur meine ich, daß es darüberhinaus gravierendere Risiken gibt.

Und wie gesagt bei forteschrittener Paranoia, kann ich per VirtualMachine Zugriff zur DS herstellen. Somit ein abgeschlossenes Biotop.

meint Tribun

PS: Rauchen KANN tödlich sein. Das Leben IST (immer) tödlich!

@Tribun
Da müsste noch nichtmal eine grosse Veriifizierung der Daten vorhanden sein. Einfach < mit < und > mit > in die Logs und alles ist wie gewohnt. Ausser dass der Code keinesfalls ausgeführt werden kann, egal was der Nutzer macht und klickt.
Der Download des Logfiles ist ein "Feature" des DSM und darum sollte dieses Feature schon abgesichert werden seitens Synology (Firmware).

Und genau weils ein Risiko ist Userdaten in HTML auszugeben, gilt der Grundsatz: Prüfen prüfen und prüfen, weil never trust incoming data.
Wenn man es schon nicht rausstrippen will, was ich verstehen kann, weil man sonst die verwendeten Usernamen bei fehlgeschlagenen Logins velieren würde, dann muss man allfällige Steuerzeichen entschärfen. Was bei HTML Tags sehr einfach ist indem man wie oben beschrieben die spitzen Klammern durch ihre HTML Entsprechung ersetzt

 

[jahlives]

Hier noch die Antwort von syno.allen aus dem intl Forum. Darin wird bestätigt, dass bei den Versionen < DSM 3 die Code Injection direkt ins JS des DSM möglich sind

Re: Cross Scripting bug in all Firmware versions

Sent: Sep 29th, '10, 13:51
From: syno.allen
To: jahlives
Dear jahlives:
In DSM 3.0 we have resolved possible html/javascript injection when displaying connection logs in DSM Log Viewer.

As you have mentioned, saved connection logs still haven't properly escape logs and cause javascript injection.

We will have a DSM 3.0 hotfix on Oct. to address this issue.
syno.allen

Und noch eine Bermerkung zum Downgrade auf ältere FW-Versionen

Gemäss syno.allen überlegt sich Synology ob sie das Problem auch in den alten Firmwaren angehen wollen v.a. weil es immer mehr User gibt, die wieder - wegen irgendwelchen Problemen mit 1337 - einen Downgrade machen wollen.
syno.allen empfiehlt bis auf Weiteres keinen Downgrade von 1337 auf frühere Versionen zu machen.

 

[jahlives]

Noch als Nachtrag: In Firmware 1354 hat Syno die sowohl für die Online Logs als auch für die lokalen Logs die Tags entschärft, wie es sich gehört mit einem htmlentities

<td align="center" >[FONT=monospace]
[/FONT]<script type="text/javascript">alert("Hallo Welt")</script>
</td>