[English]Noch ein kleiner Nachtrag von dieser Woche in Punkto QNAP-Sicherheit. Der Hersteller QNAP hat eine Hintertür in Form eines Kontos in der Disaster Recovery-App beim NAS-Backup beseitigt. Zudem wurden QNAP NAS-Geräte wohl Opfer einer breit angelegten Ransomware-Kampagne.
Anzeige
Ich hatte es die Woche schon mitbekommen, aber noch wenig Zeit, darüber zu bloggen. Leser Joachim S. hatte mir zudem die Woche eine Mail mit einem entsprechenden Hinweis geschickt (danke dafür):
Guten Tag,
vielleicht ein Hinweis für Ihren Blog. Es scheint als wenn es aktiv Angriffe auf QNAP Systeme gibt. Ich habe selber einen Kollegen der mit einer verschlüsselten QNAP beim Kunden dasteht.
Wie schon geschrieben – mir fehlte die Zeit, das sofort im Blog zu thematisieren – und wer mir angreifbaren NAS-Systemen im Internet hängt, ist eh verloren.
QNAP entfernt Backdoor
Die Woche gab es eine Meldung, dass der Hersteller QNAP eine kritische Schwachstelle beseitigt hat, die Angreifern ermöglicht, sich mit festcodierten Zugangsdaten bei QNAP NAS-Geräten (Network-Attached Storage) anzumelden. Die Sicherheitslücke CVE-2021-28799 wurde von dem taiwanesischen Unternehmen ZUSO ART in HBS 3 Hybrid Backup Sync, der Disaster-Recovery- und Datensicherungslösung des Unternehmens QNAP gefunden. QNAP hat dann für folgende Produkte Fixes bereitgestellt.
- QTS 4.5.2: HBS 3 Hybrid Backup Sync 16.0.0415 und später
- QTS 4.3.6: HBS 3 Hybrid Backup Sync 3.0.210412 und später
- QuTS hero h4.5.1: HBS 3 Hybrid Backup Sync 16.0.0419 und später
- QuTScloud c4.5.1~c4.5.4: HBS 3 Hybrid Backup Sync 16.0.0419 und später
QNAP empfiehlt in diesem Advisory vom 23. April 2021 das Produkt HBS 3 Hybrid Backup Sync auf die aktuellste Version zu aktualisieren. Ist aber etwas zu spät und zu kurz gesprungen. Die Kollegen von Bleeping Computer schreiben in diesem Artikel zur betreffenden Sicherheitswarnung des Herstellers, dass die Backdoor ausgenutzt wurde und zitieren den Hersteller:
Anzeige
QNAP confirmed that Qlocker ransomware has used the removed backdoor account to hack into some customers' NAS devices and encrypt their files.
There appears to be a number of users affected by Ransomware (QLocker) due to this vulnerability. Please Update your HBS3 version ASAP
QLocker-Ransomware-Angriff auf QNAS
Und damit schließt sich der Kreis zum Hinweis von Blog-Leser Joachim S. weiter oben, dass ein Kollege bei einem Kunden vor einem verschlüsselten QNAP-System stände. Denn diese Woche gab es wohl eine massive QLocker-Ransomware-Kampagne mit der die oben erwähnte Backdoor in den QNAP-Produkten ausgenutzt, und per Internet erreichbare Systeme verschlüsselt wurden.
Betroffene fanden dann ihrer Dateien auf den QNAP NAS-Laufwerken als passwortgeschützte 7zip-Archive vor. QNAP rät Betroffenen, das Gerät nicht abzuschalten und sich beim Support des Herstellers zu melden (Grund unbekannt, ich tippe aber, um die Dateien auf Grund des nachstehend erwähnten Bugs zu restaurieren). Kurzzeitig gab es wohl einen Bug auf der Seite der Cyberkriminellen, die eine Entschlüsselung ermöglichte – das ist aber behoben, wie man in diesem Tweet-Thread lesen kann.
Die Kollegen von Bleeping Computer haben dies in diesem Artikel aufgegriffen. Ein ähnlicher Artikel auf Deutsch findet sich bei heise. In obigem Tweet melden die Kollegen von Bleeping Computer, dass die Hintermänner der QLocker-Kampagne in fünf Tagen gut 260.000 US-Dollar an Lösegeld einstreichen konnten. Keine Ahnung, wie groß die Gruppe ist, unter der diese Lösegeldsumme geteilt werden muss – aber bei ca. 500 US Dollar pro Fall müssen einige Leute die geforderten 0,01 Bitcoin wohl gezahlt haben – motiviert die Gangs zu weiteren Aktionen.
Abschließende Frage: Wenn ich sehe, wie häufig QNAP NAS-Laufwerke erfolgreich per Ransomware angegriffen werden, ist es doch eine schlechte Idee, diese per Internet zugreifbar zu machen. Wie haltet ihr das als QNAP-Nutzer eigentlich.
Ergänzung: Es gibt einen Nachfolgeartikel Nachlese zum QNAP-NAS-Ransomware-Angriff (April 2021)
Ähnliche Artikel
QNAP schließt RCE-Schwachstelle in QTS NAS-Betriebssystem
Fix für kritische Schwachstelle in QNAP-NAS-Geräten (7.10.2020)
AgeLocker-Ransomware zielt auf QNAP NAS-Laufwerke
Warnung: Schwachstelle in QNAP NAS wird angegriffen, 62.000 Infektionen
QNAP Sicherheitswarnung vor eCh0raix-Ransomware
QSnatch-Malware zielt auf QNAP-NAS-Laufwerke
Warnung: Ransomware-Angriffe auf QNAP-/Synology-NAS
Anzeige
NAS mit einer vom Hersteller irgendwie gestrickten Software sowie SMB im allgemeinen gehören einfach nicht ans Internet… Dafür gibt es Lösungen wie Own/NextCloud.
Was soll ich von einem Produkt/Hersteller halten, der eine Backdoor einbaut?
1) Alles gut, ist ja bequemer für mich
2) Einfach prinzipiell Müll
Schwere Entscheidung…uiuiuiui
Ich muß die NAS nicht im Internet haben.
I.d.R. habe ich auch andere Rechner. Wenn diese übernommen werden, sind sie im LAN und können auch mein Backup zerstören.
Suuuper…
Wer also liest, das er sicher sei, weil sein Backupserver (natürlich) nicht vom Internet aus erreichbar ist wähnt sich in falscher Sicherrheit.
Eine Backup-Strategie, die diesen Namen verdient, beinhaltet immer auch eine Ebene mit nicht dauerhaft beschreibbaren Medien. Wer dies berücksichtigt, kann sich bei Ransomware-Angriffen relativ entspannt zurücklehnen.
QNAP hat hier wohl etwas geschlampt, das ist unerfreulich und es häuft sich in letzter Zeit…
Immerhin reagieren sie bei solchen Vorfällen zügig, so zumindest mein Eindruck. Darf man vom Marktführer und teuersten Anbieter (zusammen mit Synology) aber auch definitiv erwarten.
Für die Backup-Strategie ist aber jeder von uns selbst verantwortlich und es ist immer gut, die Verfügbarkeit der eigenen (Firmen-)Daten *nicht* von der fehlerfreien Funktion eines einzelnen Geräts bzw. von der Integrität eines einzelnen Herstellers abhängig zu machen.
Wer seine Backup Lösung bzw. seine NAS nicht ins Netzt hängt, hat den entscheidenden Vorteil das er nicht zu den ersten Opfern gehört und seine QNAP Firmware rechtzeitig updaten kann. Die Wahrscheinlichkeit das der Angreifer jetzt grade schon im eigenen Netzt ist um die QNAP auf diese Art und Weise anzugreifen ist eher gering.
Generell ist alles höher gefährdet was offen im Netzt erreichbar ist, egal ob Mailserver, RDP, NAS, Sicherkeitskameras, Drucker, etc. Solche Angriffe werden mehr und mehr werden weil es leichte Ziele sind.
Solche geräte hängen bei meinen kunden grundsätzlich nicht am Netz.
Wird ein Dienst nach aussen gebraucht, wird der port geändert und der Dienst gehärtet, d.h. alle möglichen Sicherheitsfunktionen eingeschaltet.
Werden mehrere Dienste benötigt, wird ein VPN vorgeschaltet (auf nicht standard port).
Meine eigenen gerätedienste sind nur über SSH Tunnel auf geändertem SSH port erreichbar.
https://en.wikipedia.org/wiki/Security_through_obscurity
Das ändern von Ports fällt für mich in diese Kategorie.
Generell halte ich die Nutzung von internen Diensten per VPN als bestes Mittel.
Ich sehe das ändern von standard-Ports als zusätzliche Sicherheit an.
Sollte wirkliche einmal VPN oder SSH angreifbar sein, dann ist es so für die Angreifer schwieriger diese zu finden.
Wir haben eine QNAP-NAS, die als OEM von Fujitsu Siemens vertrieben wurde.
Da ist der Support wirklich grottenschlecht, man bekommt kaum Sicherheitsupdates.
Ein Flashen von der Fujitsu Siemens-Software auf die Original QNAP-Software wird offiziell nicht unterstützt.
:-(
Schon die letzten 15 Jahre erwarte ich mir das ein NAS System mehr kann als SMB. Wer steht schon beim Kunden und macht mal schnell eine ssh Verbindung auf um ein File herunterzuladen oder neue Termine zu checken ?
Solche Patzer leisten nur den Cloud Anbietern Vorschub, wenn du dir nicht mal mehr eine Box für X € ins Office stellen kannst die du mit GUI durch konfigurierst.
Letztendlich scheitert es auch an ordentlichen Filesystemen mit Snapshots und eine simplen Heuristik die erkennt wenn außergewöhnlich viele Dateien gleichzeitig geändert werden.
Offsite backup das nur append only ist ohne Admin Intervention fehlt natürlich auch.
Betrifft das nur QNAPs, auf die eine Portweiterleitung gemacht wurde oder generell alle die im Netz hängen?
Dieser Fehler betrifft nur QNAPs – aber eine "Portweiterleitung" (1 Port oder exposed hosts aka alle Ports?) ist für mich das Grundrezept für die nächste Katastrophe – egal ob es sich um ein NAS oder ein anderes Gerät handelt.
-> auch wenn ich nur einen Dienst über 1 Port veröffentlichen will, muss ich mMn verstehen, welches Produkt/welcher Dienst öffentlich erreichbar ist, wie gut die Reputation des Herstellers ist (Security Audits/Fixes/etc.) und welche darunter liegenden Dienste ggf. betroffen sind (TCP Stack Vulnerabilities, Q4'20+Q2'21).
Wenn ich einen Tresor habe, stelle ich den auch nicht an die nächste Straßenkreuzung, weil er ja "eigentlich sicher" ist. Es gibt keinen Grund dass der Rest der Welt an meinem Tresor rumfummelt und ggf. beweist, dass er doch nicht so sicher ist wie angenommen.
Wenn ich den doch an die nächste Kreuzung stellen muss (Geldautomat) ergreife ich weitere Maßnahmen zur Sicherung.
Eine Portänderung ist ungefähr so als würde man auf den Tresor an der Straßenkreuzung eine Spitzendecke legen und ne Blumenvase drauf stellen.
Eine Portweiterleitung war nicht zwingend erforderlich in diesem Fall. Ich habe einen Fall bei dem war nur der Dienst "myqnapcloud" aktiv, warum auch immer.
Das reichte anscheinend aus um "Opfer" zu werden.
Aber im Grunde ist ein Tunnel zu einem Cloud-Dienst, den man nicht nutzt auch, auch nicht ungefährlich.
Ich verwende die Cloud Dienste vom QNAP eigentlich nicht, dennoch läuft bei mir ein "ncloud" Prozess.
[~] # ps | grep cloud
11311 admin 5312 S /usr/local/sbin/ncloud
Ich frage mich, ob sich dieser alleine dadurch schon zu den QNAP Servern verbindet und mich angreifbar macht.
Wie können solche nicht benötigten Dienste generell deaktiviert werden?