TS-109/209/?? Warnung vor Sicherheitslücke

    Auch, wenn ich in diesem Forum als Sid (der böse Junge, der sein Spielzeug kaputt macht) nicht sonderlich geliebt bin, finde ich es meine Pflicht, die NAS-User vor einer signifikanten Sicherheitslücke zu warnen:


    Ich bin durch Zufall auf eine offensichtlich schwere Sicherheitslücke zumindest der QNAP TS-109/209 gestoßen. Habe mich auf meinem NAS mal per ssh umgeschaut, weil ich partout nicht den public key des NAS meiner known_hosts zufügen konnte. Bin dabei auf einen offensichtlich ganz dicken Hund gestoßen:


    Die Schlüssel auf dem NAS unter /etc/ssh sind uralt mit Timestamp 4. Juni 2007.
    Das läßt gleich 2 böse Sicherheitslücken vermuten:
    a) die Schlüssel sind auf der QNAP-CD und für alle Geräte identisch.
    b) die Schlüssel wurden in einer Zeit erzeugt, als Debian's ssh, ssl das Sicherheitsproblem hatten, d.h. sie sind obendrein noch unsicher.


    Inzwischen weiß ich von 3 Usern (gusmax, christian und ich selbst), das auf allen Geräten die Keys in /etc/ssh identisch sind! Wer's nicht glauben mag oder selbst prüfen will, hier die md5-Hashes dazu:


    76ff0b6cbde6ecbba5e9a31de084774b ./ssh_host_rsa_key.pub
    3511672c225acb87bd59457f198cc278 ./ssh_host_dsa_key.pub
    cf0f683a740ccb0a226872c8551f89d3 ./ssh_host_dsa_key
    88d2a7eace69cf7f084dd8529d170a4f ./ssh_host_rsa_key


    Meine erste Idee zur Beseitigung des Sicherheislochs war:
    1. mit ssh-keygen neue Schlüssel erzeugen.
    Geht aber nicht, auf dem NAS existiert der Befehl nicht :(


    2. also selbst ordentliche Keys auf meinem lokalen Rechner erstellen mit:
    ssh-keygen -t rsa -C admin@nas
    ssh-keygen -t dsa -C admin@nas
    und auf das NAS in /etc/ssh hochladen. Klappt prima, man muß nur auf den Clients die alten 'fake-keys' aus der 'known_hosts' entfernen - es werden aus Sicherheitsgründen keine 2 verschiedenen Keys von einem Server akzeptiert.. Dann die Ernüchterung: 1x Reboot des NAS und alles ist wieder beim Alten.


    Das ganze Verzeichnis /etc/ssh wird dabei neu erstellt - die Daten kommen wohl aus dem Flash :shock:


    Das ist mein Hinweis, Kommentare dazu und Sclüsse daraus überlasse ich Euch.


    Ingo

    Hallo Ingo,


    keine Ahnung, warum man Dich hier nicht gut behandelt hat. Aber Deine Entdeckung ist schon ne dicke Nummer.
    Das darf wirklich nicht sein.


    Das sollte zügig gefixt werden! Weiß Qnap bescheid?

    Hallo,


    Um ehrlich zu sein hatte ich gehofft das dieses Thema schnellsten weiter unten verschwindet. Das ganze dann auch gleich aus mehreren Gründen.


    1. Seine "Entdeckung" existiert schon eine Weile und mit etwas Recherche findet man diese auch im com Forum.


    2. Hatte Ingo mich zu diesem Thema per PN kontaktiert, offensichtlich ist ihm die ihm Aufmerksamkeit wichtiger als für Sicherheit zu sorgen: indem man wie in solchen Fällen üblich den Hersteller kontaktiert und diesem das Problem nahelegt. Wenn dann keine Reaktion kommt kann man sowas auch veröffentlichen.


    3. Ingo war bzw. ist bekannt, das im Moment daran gearbeitet wird und in Naher Zukunft soll ein Fix erscheinen. Nochmals das Zitat das Ingo vorliegt:

    Zitat

    [17:09:51] Qnap: we have implemented the ************* in the coming release on ************.
    [17:09:56] Qnap: and SSH will be planned.


    4. Ist ihm bekannt das man das Problem mit etwas Handarbeit umschiffen kann um vorerst die Sicherheit zu gewährleisten. Dazu installiert man sich openssh und dabei wird eine neuer Schlüssel generiert und dieser wird dann über den alten Key drüber kopiert. Das ganze hält bis zum nächsten Neustart, man kann es allerdings auch über ein Shell Script in den autorun legen und somit wird der Schlüssel erneut ersetzt.


    5. Stelle ich mir folgende Fragen:


    - wer weiss das er just in diesem Moment einen Datentransfer, Login oder was auch immer zwischen einem Qnap NAS und einem Client abhört ?
    - wer macht sich die Mühe um wegen mir Familienbilder eines Menschen aus z.B. Oberammergau anzuschauen ein NAS zu "hacken"?
    - wer kann dies mal eben so entschlüsseln ?
    - etc.


    Versteht mich nicht falsch: denn ich finde dieses Problem auch nicht in Ordnung, aber wie damit umgegangen wird finde ich absolut falsch.


    Fakt ist doch das Ingo mit dem öffentlichen anschneiden dieses Themas alle NAS Nutzern keine Gefallen getan hat und mehr Schaden als Nutzen zufügt!



    Christian

    Zitat von "christian"

    Hallo,


    2. Hatte Ingo mich zu diesem Thema per PN kontaktiert, offensichtlich ist ihm die ihm Aufmerksamkeit wichtiger als für Sicherheit zu sorgen: indem man wie in solchen Fällen üblich den Hersteller kontaktiert und diesem das Problem nahelegt. Wenn dann keine Reaktion kommt kann man sowas auch veröffentlichen.


    Christian


    Wenn schon, dann doch bitte auch die PN vollständig zitieren.
    Hier ist gesamte PN-Verkehr, mag sich Jeder selbst ein Urteil bilden:


    =============================================================================
    Gesendet am: Sa 6. Sep 2008, 13:55
    Von: ingo2
    An: christian
    Betreff: SICHERHEIT ??????????????????


    Hallo Christian,


    Ich bin durch Zufall auf eine offensichtlich schwere Sicherheitslücke der QNAP TS-109/209 gestoßen:


    Habe mich auf meinem NAS mal per ssh umgeschaut, weil ich partout nicht den public key des NAS meiner known_hosts zufügen konnte. Bin dabei auf einen vermutlich ganz dicken Hund gestoßen - deshalb auch erstmal als PN ;)


    Die Schlüssel auf dem NAS unter /etc/ssh sind uralt mit Timestamp 4. Juni 2007.
    .... usw.


    =====================================================================================
    Gesendet am: Sa 6. Sep 2008, 17:19
    Von: christian
    An: ingo2
    Hallo Ingo,


    ein bisschen denken und etwas nachforschen. Dann viel es mir wieder ein nur finden kann ich es nicht mehr. Das Problem ist bekannt und ja meine hashes stimmen mit deinen auch überein.


    Ich zitiere:


    [17:09:51] Qnap: we have implemented the ************* in the coming release on ************.
    [17:09:56] Qnap: and SSH will be planned.


    Es liegt also an dir das Thema erneut aufzugreifen.



    Christian
    ===========================================================================


    Ingo


    P.S.: heute kam ein Firmware-Update - im Change-Log ist nichts davon erwähnt

    Jetzt frage ich mich, warum Microsoft die Sicherheitslöcher in ihrer Software erst veröffentlichen, wenn diese geflickt wurden.
    Was hat Microsoft dazu bewogen ?


    Hast du wingestens eine Anleitung erstellt, wie man einen eigenen Key für SSH erstellt und Neustartsicher ist ?


    1. Ich persönlich würde ich nie einen SSH Port zum Internet öffnen, egal wie sicher oder unsicher SSH ist.
    2. Nutzt man für solche Anwendungen VPNs.
    3. aktiviertes DMZ auf seinem Router ist gefährlicher.

    Zitat von "christian"


    Um ehrlich zu sein hatte ich gehofft das dieses Thema schnellsten weiter unten verschwindet. Das ganze dann auch gleich aus mehreren Gründen.
    [...]
    Versteht mich nicht falsch: denn ich finde dieses Problem auch nicht in Ordnung, aber wie damit umgegangen wird finde ich absolut falsch.


    Fakt ist doch das Ingo mit dem öffentlichen anschneiden dieses Themas alle NAS Nutzern keine Gefallen getan hat und mehr Schaden als Nutzen zufügt!


    Zitat von "Eraser-EMC2-"

    Jetzt frage ich mich, warum Microsoft die Sicherheitslöcher in ihrer Software erst veröffentlichen, wenn diese geflickt wurden.
    Was hat Microsoft dazu bewogen ?


    Das kann ich so nicht teilen.


    Nachdem diese mögliche Lücke offensichtlich anderweitig definitiv bekannt war UND ein Workaround, den man mit Bordmitteln (wenn auch evtl. umständlich) hinbekommt existiert, darf das ganze IMHO nicht "unter dem Teppich" verschwinden nach dem Motto "hoffentlich merkt's keiner, bevor der Fix heraußen ist". Ich bin als noch-nicht-Anwender einer QNAP-Kiste ausdrücklich dankbar für das "öffentliche Anschneiden" und kann, sofern meine künftige Kiste auch betroffen ist (die 509 vermutlich! Wer weiß es?) die betreffende Funktionalität stilllegen/unbenutzt lassen oder eben den Workaround benutzen. So what? Besser ich weiß die Lücken als daß ich nichtsahnend tatsächlich drüberfalle.


    Security by Obscurity, das ist was für Closed-Source-Riesen wie Microsoft.


    mfG Matthias

    Es gibt nicht viel hinzuzufügen - das sind die wesentlichen Punkte.


    Man kann über das Verhalten mancher selbsternannten Sicherheitslückenwarner denken was man will. Das in dem Bereich zuweilen übliche Verfahren ist, den ggf. betroffenen Hersteller mit Bits und Bytes über das Problem zu informieren. Dann hat der Hersteller auch Zeit, ein Statement, einen Fix, und falls nicht kurzfristig möglich einen Plan zu erstellen - und zu päsentieren. Solche Mitteilungen werden auch entsprechend verdankt.


    QNAP hat erkannt, dass es einen einfachen und gangbaren Weg braucht, um die statischen, und leider nicht bei der Grundinstallation bei Installation des Systemes neu erzeugten Zertifikate auszutauschen. Die Arbeiten sind im Gang - das sieht in diesen Tagen so aus:




    Zitat von "ingo2"

    b) die Schlüssel wurden in einer Zeit erzeugt, als Debian's ssh, ssl das Sicherheitsproblem hatten, d.h. sie sind obendrein noch unsicher.

    Wie kommt der Ingo2 zum Schluss, dass diese Keys auf einer Debian-basierenden Distribution erzeugt wurden, und folglich vom evidenten Problem der massive Verkleinerung der Entropie des Seeds für den Pseudozufallszahlgenerator in (Debian) OpenSSL efährdet und folglich zu einem schwachen Schlüssel führen soll? Der Verweis auf ein Erstellungsdatum einer Datei ist schon etwas dünn. Ob Unterstellung oder zu Beweiskraft lasse ich im Moment mal dahinestellt. FMI: http://www.debian.org/security/2008/dsa-1571


    -Kurt.

    Zitat von "schumaku"

    Wie kommt der Ingo2 zum Schluss, dass diese Keys auf einer Debian-basierenden Distribution erzeugt wurden, und folglich vom evidenten Problem der massive Verkleinerung der Entropie des Seeds für den Pseudozufallszahlgenerator in (Debian) OpenSSL efährdet und folglich zu einem schwachen Schlüssel führen soll? Der Verweis auf ein Erstellungsdatum einer Datei ist schon etwas dünn. Ob Unterstellung oder zu Beweiskraft lasse ich im Moment mal dahinestellt. FMI: http://www.debian.org/security/2008/dsa-1571


    Sorry - er hat das nicht behauptet, sondern vermutet.
    Ist ersichtlich, wenn man nicht gar so verkürzt zitiert (Hervorhebung von mir):

    Zitat von "ingo2"


    Die Schlüssel auf dem NAS unter /etc/ssh sind uralt mit Timestamp 4. Juni 2007.
    Das läßt gleich 2 böse Sicherheitslücken vermuten:
    a) die Schlüssel sind auf der QNAP-CD und für alle Geräte identisch.
    b) die Schlüssel wurden in einer Zeit erzeugt, als Debian's ssh, ssl das Sicherheitsproblem hatten, d.h. sie sind obendrein noch unsicher.


    a) trifft ja wohl zu, b) läßt sich möglicherweise z.B. per http://www.heise.de/netze/tools/chksslkey testen. Den von dem Debian-OpenSSL-Problem ebenfalls betroffenen unsicheren Schlüssel von FritzBoxen (Heise-Link!!) hat der Test jedenfalls gefunden, und die prominente Veröffentlichung bei Heise hat beileibe nicht die Diskussion ausgelöst, wie Ingos Beitrag hier. Wo ist das Problem, weswegen hier jetzt so gegenseitig aufeinander herumgehackt werden muß?