Angriff auf Synology NAS

Aktuell gelingt es Hackern, bei Synology NAS Systemen mit INTEL Architektur einen Bitcoin-Miner-Bot zu installieren. Auch wenn das nicht direkt mit domainFACTORY zu tun hat, wissen wir, dass viele Kunden das System nutzen und möchten dem Kollegen danken, der den Virus entdeckt und eine Anleitung erstellt hat, wie dieser zu entfernen ist, da ein einfaches DSM-Update in diesem Fall nichts nützt.

Gerne möchten wir Ihnen diese Lösung zur Verfügung stellen, bitte bedenken Sie dabei aber, dass es sich nicht um ein System von uns handelt und die Anleitung somit auf eigene Gewähr zu nutzen ist. Auch können wir keinen Support für Ihre NAS anbieten.

Wer kann betroffen sein?

Jeder, der eine Synology NAS basierend auf der Intel Plattform hat  UPDATE: Jeder, der eine Synology NAS mit einer DSM Version älter oder gleich DSM 4.2-3211 nutzt.
Eine Liste aller Synology Geräte mit verbautem Prozessor findet man hier. 

Eine Beschreibung des Virus ist hier zu finden.

Die genutzte DMS- Version erfährt man, wenn man als Admin eingeloggt auf Start -> Systeminformationen klickt. Dort wird sie bei „DSM-Version“ angezeigt.

systeminformationen

DSMversion

Wie findet man heraus, ob man den Virus hat?

Im Ressourcenmonitor kann geprüft werden, ob es eine ungewöhnliche Lastspitze gab. Bei über 80 % besteht ein aktuter Hinweis auf den Virus.

ressourcenmonitor

CPUlast

Der Prozess heißt meistens httpd-log.pid. Wenn mehrere httpd-log.pid Prozesse mit viel CPU Auslastung existieren, ist man betroffen.

prozesse

Virus entfernen

++++++++++++++++++++++++++++++++++

UPDATE 14.2.2014:

Das DSM-Update 4.3-3827 schließt die Sicherheitslücke und bereinigt die NAS bei Schädlingsbefall!

++++++++++++++++++++++++++++++++++

 

Der Virus kann mit SSH entfernt werden. Hierfür kann z.B. Putty verwendet werden.

In der Systemsteuerung kann der Zugriff via Terminal aktiviert werden.

systeminformationen

terminalaktivieren

Ermitteln Sie nun Ihre IP-Adresse und melden sich damit in Putty an.

ipaderesse

putty

Suchen Sie nun die httpd-log.pid Prozesse mit folgendem Befehl:

ps | grep httpd-log.pid

Das Ergibnis wird in etwa so aussehen (IP-Adresse durch Xe ersetzt):

15600 root     68336 S    /var/run/httpd-log.pid -B -q -o stratum+tcp://xxx.xxx.xxx.xxx:3340
15602 root     68336 S    /var/run/httpd-log.pid -B -q -o stratum+tcp://xxx.xxx.xxx.xxx:3340
15603 root     68336 S    /var/run/httpd-log.pid -B -q -o stratum+tcp://xxx.xxx.xxx.xxx:3340
15604 root     68336 S    /var/run/httpd-log.pid -B -q -o stratum+tcp://xxx.xxx.xxx.xxx:3340

Der Port hinter der IP-Adresse variiert dabei.

Ganz vorne ist die Prozess-ID (PID) zu finden, also in unserem Beispiel in der ersten Zeile „15600“. Die Prozesse werden wie folgt beendet:

kill -9 <PID>

Wechseln Sie nun in das Verzeichnis /var/run/:

cd /var/run/

Entziehen Sie der Datei httpd-log.pid zur Sicherheit alle Ausführrechte:

chmod a-x httpd-log.pid

und benennen sie um

mv httpd-log.pid httpd-log.pid.virus

In der rc.local kann nachvollzogen werden, dass der Virus bei jedem Neustart der NAS wieder geladen werden würde:

cat /etc/rc.local

/var/run/httpd-log.pid -B -q -o stratum+tcp://xxx.xxx.xxx.xxx:3336

Die Datei ist also schädlich, benennen Sie sie daher um:

mv /etc/rc.local /etc/rc.local.virus

Da nun keine rc.local Datei mehr exisitert, erstellen Sie nun eine neue, leere Datei:

touch /etc/rc.local

Prüfen Sie nun, ob eine „authorized_keys2“ Datei existiert. Sollten Sie diese selbst angelegt haben, prüfen Sie sie auf Auffälligkeiten, wir empfehlen, sie zu löschen:

rm -f ~/.ssh/authorized_keys2

Starten Sie nun Ihre NAS neu. Prüfen Sie nochmals, ob die Prozesse nun weg sind wie zuvor mit

ps | grep httpd-log.pid

und ob die CPU-Last nun gesunken ist und spielen dann SOFORT die neuste DSM Version ein.

 

End of article

Anna Philipp

Über den Autor

Anna Philipp

27 Kommentare

Bitte füllen Sie das Captcha aus : *

Reload Image

Die von Ihnen hier erhobenen Daten werden von der domainfactory GmbH zur Veröffentlichung Ihres Beitrags in diesem Blog verarbeitet. Weitere Informationen entnehmen Sie bitte folgendem Link: www.df.eu/datenschutz


  • Reseller4711
    Reseller4711 - 12. Februar 2014 um 16:26 Uhr

    Vielen Dank für diese Information und die ausführliche Checkliste/Anleitung.
    Gott sei Dank bin ich nicht betroffen, aber als Inhaber einer Synology NAS nun bestens informiert und wachsam.

  • Lochinger Design & IT Lösungen
    Lochinger Design & IT Lösungen - 13. Februar 2014 um 05:38 Uhr

    DIe Moral der Geschichte: Sämtliche Systeme immer möglichst Zeitnah auf den aktuellsten Stand bringen! Man kann nie vorsichtig genug sein.

  • bitminers
    bitminers - 13. Februar 2014 um 09:10 Uhr

    Es handelt sich natürlich um einen Bitcoin-Miner-Bot. Wir haben keine Bots im Einsatz und schon gar nicht auf fremden Systemen 🙂

  • Anna
    Anna - 13. Februar 2014 um 09:16 Uhr

    Oh – ja ist geändert!

  • Eugen
    Eugen - 13. Februar 2014 um 10:15 Uhr

    Ich kann keine Prozesse killen 🙁

    kill -9 5220
    kill: can’t kill pid 5220: Operation not permitted

    Woran kann es liegen? Hat jemand einen Tipp für mich?

  • Anna
    Anna - 13. Februar 2014 um 10:23 Uhr

    Eugen, sind Sie denn als root eingeloggt?

  • Eugen
    Eugen - 13. Februar 2014 um 10:34 Uhr

    @Anna: ich bin als Admin eingeloggt. Gibt es noch einen root-Zugang?

  • Anna
    Anna - 13. Februar 2014 um 10:37 Uhr

    Bitte loggen Sie sich einmal direkt als root ein, da der Prozess auch unter root läuft.

  • Eugen
    Eugen - 13. Februar 2014 um 11:00 Uhr

    @Anna: vielen Dank für die Unterstützung! Mir war nicht bewusst, dass root dasselbe Passwort wie der Admin hat.

  • Anna
    Anna - 13. Februar 2014 um 11:07 Uhr

    Hat es nun funktioniert?

  • C
    C - 13. Februar 2014 um 11:46 Uhr

    Hallo,

    Ist das auch möglich wenn die NAS nicht im Internet erreichbar ist (man muss ja DynDNS und Port öffnen)?

  • Anna
    Anna - 13. Februar 2014 um 13:43 Uhr

    Wenn die Ports nicht nach außen freigegeben sind, sollte eigentlich keine Gefahr bestehen. Eine Prüfung kann dennoch nicht schaden. 😉

  • Michael Boehm
    Michael Boehm - 13. Februar 2014 um 17:55 Uhr

    Hallo Zusammen,

    wie ich gestern feststellen durfte sind nicht nur ALLE Synology Systeme betroffen der Mining-Bot benennt sich auch in regelmaessigen umstaenden um.

    Eine sichere Moeglichkeit den Mining-Prozess ausfinding zu machen ist ps | grep stratum.tcp

  • Michael Boehm
    Michael Boehm - 13. Februar 2014 um 18:00 Uhr

    Den Bot faengt man sich ein wenn man port 22,23,5000 oder 5001 per Portforwarding von Aussen zugaenglich gemacht hat..

    Unter welchem Port man ihn veroeffentlicht hat ist hierbei nicht Relevant wenn Sie z.b Router-Port 80 auf Synology-Port 5000 weitergeleitet haben werden Sie auch attakiert.

    VG

  • Sebastian
    Sebastian - 14. Februar 2014 um 09:43 Uhr

    Danke für den Hinweis. Bin zum Glück nicht betroffen.

  • typo3fan
    typo3fan - 14. Februar 2014 um 12:16 Uhr

    Es trifft auch aktuellere Versionen 🙁
    „Synology DiskStation Manager versions 4.3-3776-3 and below allow a remote unauthenticated user to append arbitrary data to files on the system under root privileges.“
    http://www.kb.cert.org/vuls/id/615910
    http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-6987

  • Con
    Con - 14. Februar 2014 um 14:41 Uhr

    Kann es sein, dass das Problem durch das aktuelle Update behoben wurde? Jemand Erfahrung?
    https://www.synology.com/en-global/releaseNote/model/DS2411+

  • Hans Meier
    Hans Meier - 14. Februar 2014 um 15:45 Uhr

    Nein, das Problem wurde bereits mit dem Hotfix 4 behoben, laut Auskunft des freundlichen Supports bei Synology. Das ist wohl schon zwei Monate draussen. Bei mir läuft alles sauber.

  • Anna
    Anna - 14. Februar 2014 um 17:44 Uhr

    Die Sicherheitslücken wurden durch das Update behoben, der Virus müsste dann aber, falls vorhanden, trotzdem noch entfernt werden.

  • Rüdiger
    Rüdiger - 14. Februar 2014 um 21:34 Uhr

    das aktuellste Update entfernt auch die Malware http://stadt-bremerhaven.de/synology-dsm-update-4-3-3827-bereinigt-nas-bei-schaedlingsbefall/

  • Anna
    Anna - 14. Februar 2014 um 21:47 Uhr

    Danke für den Hinweis, Rüdiger! Wir haben den Beitrag entsprechend aktualisiert!

  • Bernhard
    Bernhard - 14. Februar 2014 um 23:32 Uhr

    Habe eine DS 409+, die infiziert ist.
    Update gibt es keines.
    Die Prozess-ID zählt laufend hoch – damit kann ich den Prozess auch nicht killen.
    Bekomme dann immer die Meldung „kill: can’t kill pid #####: No such process“ (##### ist die jeweils eingegebene Prozessnummer)
    Wie werde ich die Malware los?
    Danke für Eure Hilfe

  • Bernhard
    Bernhard - 14. Februar 2014 um 23:33 Uhr

    PS: Wollte heissen: DSM 4.3 gibt es für die DS 409+ nicht und damit auch kein aktuelles Update…

  • Bernhard
    Bernhard - 14. Februar 2014 um 23:41 Uhr

    So – möglicherweise war das auch falscher Alarm (kenne mich mit Linux kaum aus). Also „ps | grep httpd-log.pid“ ergibt bei mir „20233 root 2968 S grep httpd-log.pid“. Die Prozessnummer vorne zählt laufend hoch – jede Abfrage ergibt einen neuen höheren Wert. Im Verzeichnis „/var/run/“ finde ich keine Datei namens „httpd-log.pid“. Die CPU ist nach einem Restart auch wieder auf beinahe 0%. Kann ich sicher sein, dass ich doch nicht betroffen bin? Danke für Eure Hilfe!

  • Michael Boehm
    Michael Boehm - 16. Februar 2014 um 14:30 Uhr

    Hallo Bernhard,
    nutzen sie besser;

    ps | grep stratum.tcp

    wenn dies nur ein ergebnis hat z.b.

    mboehm 28057 0.0 0.0 3200 384 pts/8 S+ 14:29 0:00 grep stratum.tcp

    dann haben sie nur den Prozess von grep gefunden.

    finden sie min. 2 dann laeuft auch ein echter prozess.

    vg

  • Bernhard
    Bernhard - 16. Februar 2014 um 22:54 Uhr

    Hallo Michael!
    Danke sehr. Dann habe ich Gott sei Dank wirklich nur den Prozess von grep gefunden und jetzt verstehe ich auch, warum die Prozessnummer mit jedem Aufruf wechselt.
    LG

  • Georgekneer
    Georgekneer - 17. August 2018 um 21:05 Uhr

    Smart Communications