MR-Meldung: [Malware Remover] Removed vulnerable files or folders. Malware ID: MR2102

    Zitat von eyetap

    Die /usr/local/sbin/7z* wird offenbar mit jedem neuen Malware Remover Scan neu erstellt....

    Du hast recht. Neuer Scan, neues Dateidatum.


    Der Nutzen dieser Maßnahme dürfte aber nur von kurzer Dauer sein. Der Schädling kann ja auch die weiterhin vorhandene Originaldatei aufrufen. Also nur eine kurze Atempause, in der Qnap hoffentlich das Problem löst und den Angriffspunkt absichert.

    Hab das Thema auch mit meinem TS453D und so und so gerade ein Support Ticket offen das ich um dieses Topic ergänzt habe. Mal sehen was QNAP sagt...


    Zitat von Anthracite

    Mein NAS kann nur über SSH von außen erreicht werden, und der Zugang ist gut abgesichert. Zeichen einer böswilligen Aktivität durch Malware habe ich nicht sehen können.


    Also sorry, aber "nur" per SSH von außen erreichtbar.... Da finde ich das "nur" sehr bedenktlich.... Mir ist eine Mauer lieber als eine Tür mit gutem Schloss ;)

    Dann doch lieber per VPN einloggen.

    Noch was Wichtiges zum 7z-Skript von Qnap:


    Das Skript schreibt die 7z-Aufrufe in die Datei

    /share/<App-Installationsvolume>/.qpkg/MalwareRemover/7z.log


    Wer gehackt worden ist, sollte in die Datei hineinschauen. Mit Glück (Malware-Remover ist gelaufen, während die Verschlüsselung noch im Gange war) steht da dann auch das Passwort drin, was zum Entschlüsseln benötigt wird.

    Das dürfte dann aber nur diejenigen betreffen, die zum Zeitpunkt des Angriffs bereits den aktuellen MR drauf hatten, bzw. die aktuellste Signatur von heute... Oder woher soll das Script gekommen sein?

    Ich weiß nicht, seit wann der Malware-Remover das 7z-Skript austauscht. Das Datum des Skripts kommt vom letzten MR-Lauf, nicht vom erstmaligen Austausch). Vllt. ist das schon seit ein paar Tagen aktiv.


    In jedem Falle, ein Blick in die Datei lohnt für Betroffene. Einige könne Glück haben, die anderen haben durch den Blick keine nennenswerte Zeit verschwendet.

    Ich habe heute auch diese Nachricht vom Malware Remover erhalten:

    Code
    Removed vulnerable files or folders. Malware ID: MR2102

    Wo finde ich denn die "files or folders", die removed wurden?


    Wenn ich die Meldung aufrufe, lande ich im "Systemereignisprotokoll" und finde denselben Text, aber sonst keine weiteren Details...

    Gleiche Meldung wie alle hier. Zudem Folgendes in dem Quarantäneordner (.qpkg\MalwareRemover\.quarantine) vom MR mit heutigem Datum und vor wenigen Stunden angefertigt.


    Ich habe keine Ahnung was das ist, aber ich teile die Vermutung, dass es mit HBS zu tun hat. Was sagen die QNAP-Experten hier?

    Code
    ./etc/config/qsync/home/mgnt_cgi/bin/access_inbound_job/__init__.py ./etc/config/qsync/home/mgnt_cgi/bin/access_inbound_job/access_inbound_job.py ./etc/config/qsync/home/mgnt_cgi/bin/access_inbound_job/cli_access_inbound_job.py ./etc/config/qsync/home/mgnt_cgi/bin/get_fs_info/__init__.py ./etc/config/qsync/home/mgnt_cgi/bin/get_fs_info/get_fs_info.py ./etc/config/qsync/home/mgnt_cgi/bin/get_hbs_info/__init__.py ./etc/config/qsync/home/mgnt_cgi/bin/get_hbs_info/get_hbs_info.py ./etc/config/qsync/home/mgnt_cgi/bin/get_storage_info/__init__.py ./etc/config/qsync/home/mgnt_cgi/bin/get_storage_info/get_storage_info.py ./etc/config/qsync/home/mgnt_cgi/bin/list_funcs/__init__.py ./etc/config/qsync/home/mgnt_cgi/bin/list_funcs/list_funcs.py ./etc/config/qsync/home/mgnt_cgi/bin/list_item_names_in_dir/__init__.py ./etc/config/qsync/home/mgnt_cgi/bin/list_item_names_in_dir/list_item_names_in_dir.py ./etc/config/qsync/home/mgnt_cgi/bin/pipe_dict_to_cmd/__init__.py ./etc/config/qsync/home/mgnt_cgi/bin/pipe_dict_to_cmd/pipe_dict_to_cmd.py ./etc/config/qsync/home/mgnt_cgi/bin/read_conf_file/__init__.py ./etc/config/qsync/home/mgnt_cgi/bin/read_conf_file/read_conf_file.py ./etc/config/qsync/home/mgnt_cgi/bin/read_json_file/__init__.py ./etc/config/qsync/home/mgnt_cgi/bin/read_json_file/read_json_file.py ./etc/config/qsync/home/mgnt_cgi/bin/rru/__init__.py ./etc/config/qsync/home/mgnt_cgi/bin/rru/common1.py ./etc/config/qsync/home/mgnt_cgi/bin/rru/rwlock.py ./etc/config/qsync/home/mgnt_cgi/bin/rru/util_aid.py ./etc/config/qsync/home/mgnt_cgi/bin/rru/util_cli.py ./etc/config/qsync/home/mgnt_cgi/bin/rru/util_file.py ./etc/config/qsync/home/mgnt_cgi/bin/rru/util_file2.py ./etc/config/qsync/home/mgnt_cgi/bin/rru/util_log.py ./etc/config/qsync/home/mgnt_cgi/bin/rru/util_log2.py ./etc/config/qsync/home/mgnt_cgi/bin/rru/util_nas.py ./etc/config/qsync/home/mgnt_cgi/bin/rru/util_nas2.py ./etc/config/qsync/home/mgnt_cgi/bin/rru/util_nas_base.py ./etc/config/qsync/home/mgnt_cgi/bin/rru/util_net.py ./etc/config/qsync/home/mgnt_cgi/bin/rru/util_perf.py ./etc/config/qsync/home/mgnt_cgi/bin/rru/util_rr2_log.py ./etc/config/qsync/home/mgnt_cgi/bin/rru/util_rwlock.py ./etc/config/qsync/home/mgnt_cgi/bin/rru/util_sys.py ./etc/config/qsync/home/mgnt_cgi/bin/rru/util_sys2.py ./etc/config/qsync/home/mgnt_cgi/bin/rru/util_time.py ./etc/config/qsync/home/mgnt_cgi/bin/rru/util_xattr.py ./etc/config/qsync/home/mgnt_cgi/bin/rru/xattr.py ./etc/config/qsync/home/mgnt_cgi/bin/run_cmd/__init__.py ./etc/config/qsync/home/mgnt_cgi/bin/run_cmd/run_cmd.py ./etc/config/qsync/home/mgnt_cgi/bin/run_cmd_get_json/__init__.py ./etc/config/qsync/home/mgnt_cgi/bin/run_cmd_get_json/run_cmd_get_json.py ./etc/config/qsync/home/mgnt_cgi/bin/update_mgnt_module/__init__.py ./etc/config/qsync/home/mgnt_cgi/bin/update_mgnt_module/update_mgnt_module.py ./etc/config/qsync/home/mgnt_cgi/bin/upload_one_file/__init__.py ./etc/config/qsync/home/mgnt_cgi/bin/upload_one_file/upload_one_file.py ./etc/config/qsync/home/mgnt_cgi/bin/write_conf_file/__init__.py ./etc/config/qsync/home/mgnt_cgi/bin/write_conf_file/write_conf_file.py ./etc/config/qsync/home/mgnt_cgi/bin/__init__.py ./etc/config/qsync/home/mgnt_cgi/bin/hbs_mgnt.py
    Zitat von Anthracite

    Der Nutzen dieser Maßnahme dürfte aber nur von kurzer Dauer sein. Der Schädling kann ja auch die weiterhin vorhandene Originaldatei aufrufen. Also nur eine kurze Atempause, in der Qnap hoffentlich das Problem löst und den Angriffspunkt absichert.

    Wenn das was BleepingComputer schreibt stimmt, dann verstehe ich, dass Qnap diese Attacken mit CVE-2020-36195 (betrifft Multimedia Console / Media Streaming Add-on) in Verbindung bringt.


    Zusätzlich zitiert BleepingComputer wie folgt:


    Zitat von Bleeping Computer

    "QNAP strongly urges that all users immediately install the latest Malware Remover version and run a malware scan on QNAP NAS. The Multimedia Console, Media Streaming Add-on, and Hybrid Backup Sync apps need to be updated to the latest available version as well to further secure QNAP NAS from ransomware attacks. QNAP is urgently working on a solution to remove malware from infected devices," QNAP stated in a security advisory.


    Unterm Strich würde ich das dann so interpretieren, dass Geräte, welche die aktuelle Multimedia Console / Media Streaming Add-on sowie das aktuelle HBS3 installiert haben, bzgl. dieser Attacke sicher und der Angriffspunkt abgesichert sein sollten. Sehe ich das falsch?


    Was mich dann aber etwas verwirrt ist, dass QNAP dann mit der Gießkanne über alle Systeme drüber geht um - für nicht aktualisierte Systeme - etwas Zeit zu gewinnen.

    Ich hoffe, dass das nur ein ev. etwas ungewöhlicher aber netter Zug ist.


    Zitat von Anthracite

    Das Skript schreibt die 7z-Aufrufe in die Datei

    /share/<App-Installationsvolume>/.qpkg/MalwareRemover/7z.log

    Diese Datei existiert bei mir gar nicht.

    Ich schließe daraus, dass 7zip - zumindest seit der Anpassung - bis zum Zeitpunkt des Nachsehens einfach gar nicht gelaufen ist.

    Zitat von Nash123

    (.qpkg\MalwareRemover\.quarantine)

    Da stehen also die gelöschten Dateien. Jetzt wissen wir, was die Malware ist: Hybrid Backup und QSync. War uns das nicht schon immer klar :evil:?


    Qnap scheint einige (nicht mehr benötigte?) Skripte, die den Qlocker-Angriff ermöglicht könnten, über den Malware-Remover entfernt zu haben.


    Meine Vermutung, die Meldung MR2102 sei durch die Änderung des 7z-Skriptes gekommen, ist dann wohl falsch. HBS/Qsync waren's scheinbar.


    EDIT:

    Zitat von eyetap

    Was mich dann aber etwas verwirrt ist, dass QNAP dann mit der Gießkanne über alle Systeme drüber geht um - für nicht aktualisierte Systeme - etwas Zeit zu gewinnen.

    Womöglich hat Qnap den Angriffspunkt noch nicht sicher identifizieren können. Da wird eventuell eine Sicherheitslücke ausgenutzt, die jemand anders vor Qnap gefunden hat.

    Zitat von tiermutter

    Es sind scheinbar sämtliche QNAP NAS betroffen, bei denen der MR (versionsunabhängig) am 26.04.21 neue Definitionen erhalten hat.

    Wo sehe ich das denn? Das QLog schweigt sich darüber auch aus.

    Bei mir auch keine Infos von QuLog, ich deute das daraus, dass die Meldung erst seit heute auftaucht und auch auf allen meiner Systeme lediglich Definitionsupdates erfolgt sind (weil es ja nichts anderes sein kann), alle aber unterschiedliche Versionen und Kombinationen von QTS und MR haben.

    Scans die heute morgen um 0300 gelaufen sind, haben noch nichts gefunden.

    Zitat von QNAPDanielFL

    I was told from our security team, " In fact, if users saw the message, it means the vulnerability patched."


    Because this message is scaring many people, "MR team just rollbacked the rule temporarily


    Tomorrow, we will deploy new rule again"


    We will try to implement this in a way that does not make it look like you just got malware.


    Laut QNAP Mitarbeiter im Englischen Forum wird das Update für malware remover jetzt erstmal zurückgezogenen und dann via Update "besser" formuliert.


    Was für ein Chaos

    Zitat von Anthracite

    Womöglich hat Qnap den Angriffspunkt noch nicht sicher identifizieren können. Da wird eventuell eine Sicherheitslücke ausgenutzt, die jemand anders vor Qnap gefunden hat.

    Oder bekannte Lücken, die vom Anwender nicht "geschlossen" wurden, was ich als wesentlich wahrscheinlicher ansehe.

    Ich bräuchte auch keinen Bestimmten Vector, wenn ich Malware-Programmierer wäre.

    - QNAP im Netz finden

    - Konnekten und auf letzte 20 CVE testen

    - wenn Lücke gefunden dann verwenden

    Habe die Meldung auch bekommen, auf NAS und dem Remote Backup NAS, recht Zeitnahe.


    War ein kleiner Schreck, aber da nur über VPN zu erreichen, war ich 1 Minuten Googlen später schlauer, Fehlalarm.


    Bei mir wurde nur HBS Altlasten weg geräumt.

    Mein Testsystem war den Tag über aus, dann eingeschaltet konnte es das fragliche Update nicht mehr ziehen und hier wurde noch nichts verschoben.

    Protokolleintrag:

    Code
    admin (internal Host IP) Malware Remover Malware Removal [Malware Remover] Removed vulnerable files or folders. Malware ID: MR2102n Fundort TS853A

    Konfigurationsbeschreibung:


    UPNP Off; SSH, CLOUD Services off, Multimedia Komponenten off.


    Das System erhält lediglich Firmware Updates und App Updates und befindet sich in einem segmentierten Netz hinter einer IPS FW.


    Meine Suche orientierte sich daher an den lokal installierten Komponenten, eigentlich ist auf dieser Maschine nur HBS3 aktiv und der Malware Remover, Qboost, Helpdesk, SSD Profiling, Multimedia etc. Dienste sind gestoppt. Ich bin daher davon ausgegangen, dass diese Maschine sicher sei.


    Nach längerem Testen der Systemumgebung muss ich feststellen, dass HBS3 FTP Ports öffnet und sich dem UPnP bedient um diverse Ports zu öffnen in der gesamten erreichbaren Netzwerk Infrastruktur. Dabei werden die UPnP Komponenten mittels UDP 1900 getriggert. Da die Border FW diese Kommunikation abwürgt, denke ich das ist halbwegs sicher.


    Trotzdem verunsichert mich die Malware Remover Meldung.


    Meine Fragen hier an das Forum:


    Woher kommt die Malware Meldung?
    Klar ich habe gelesen dass die meissten vom Fehlalarm reden, aber hatten alle Betroffenen HBS3 installiert?
    Wenn ja war der Service aktiv oder gestoppt?


    Was gibt es für Aussagen von QNAP dazu?

    (Support Ticket ist von mir seit 25. April eröffnet, bis dato keine Antwort erhalten, werde updaten sofern hilfreiches von QNAP kommt)


    Generelle Frage:

    Gibt es eine bekannte Dokumentation von HBS3, welche die Funktionen und verwendeten Netzwerk Zugriffe und Mechanismen dokumentiert?

    Bei mir ist die Meldung auf meiner vQTScould auf Azure aufgetreten. Der Malware Remover hat eine ganze Liste von Dateien entsorgt:

    Code
    ./share/CACHEDEV1_DATA/.qpkg/HybridBackup/rr2/cgi/access_inbound_job/__init__.py ./share/CACHEDEV1_DATA/.qpkg/HybridBackup/rr2/cgi/access_inbound_job/access_inbound_job.py ./share/CACHEDEV1_DATA/.qpkg/HybridBackup/rr2/cgi/access_inbound_job/cli_access_inbound_job.py ./share/CACHEDEV1_DATA/.qpkg/HybridBackup/rr2/cgi/get_fs_info/__init__.py ./share/CACHEDEV1_DATA/.qpkg/HybridBackup/rr2/cgi/get_fs_info/get_fs_info.py ./share/CACHEDEV1_DATA/.qpkg/HybridBackup/rr2/cgi/get_hbs_info/__init__.py ./share/CACHEDEV1_DATA/.qpkg/HybridBackup/rr2/cgi/get_hbs_info/get_hbs_info.py ./share/CACHEDEV1_DATA/.qpkg/HybridBackup/rr2/cgi/get_storage_info/__init__.py ./share/CACHEDEV1_DATA/.qpkg/HybridBackup/rr2/cgi/get_storage_info/get_storage_info.py ./share/CACHEDEV1_DATA/.qpkg/HybridBackup/rr2/cgi/list_funcs/__init__.py ./share/CACHEDEV1_DATA/.qpkg/HybridBackup/rr2/cgi/list_funcs/list_funcs.py ./share/CACHEDEV1_DATA/.qpkg/HybridBackup/rr2/cgi/list_item_names_in_dir/__init__.py ./share/CACHEDEV1_DATA/.qpkg/HybridBackup/rr2/cgi/list_item_names_in_dir/list_item_names_in_dir.py ./share/CACHEDEV1_DATA/.qpkg/HybridBackup/rr2/cgi/pipe_dict_to_cmd/__init__.py ./share/CACHEDEV1_DATA/.qpkg/HybridBackup/rr2/cgi/pipe_dict_to_cmd/pipe_dict_to_cmd.py

    ...und noch viele mehr...

    Code
    ./share/CACHEDEV1_DATA/.qpkg/HybridBackup/rr2/test/support/scripts/realtime/gen_mass_events.sh ./share/CACHEDEV1_DATA/.qpkg/HybridBackup/rr2/test/support/scripts/realtime/get_fs_of_path_list.sh ./share/CACHEDEV1_DATA/.qpkg/HybridBackup/rr2/test/support/scripts/realtime/get_fs_of_path_list_pipe.sh ./share/CACHEDEV1_DATA/.qpkg/HybridBackup/rr2/test/support/scripts/realtime/get_items_in_dir.sh ./share/CACHEDEV1_DATA/.qpkg/HybridBackup/rr2/test/support/scripts/realtime/hbs_v2_cgi.sh ./share/CACHEDEV1_DATA/.qpkg/HybridBackup/rr2/test/support/scripts/realtime/kill_burst_events_proc.sh ./share/CACHEDEV1_DATA/.qpkg/HybridBackup/rr2/test/support/scripts/realtime/kill_mass_events_proc.sh ./share/CACHEDEV1_DATA/.qpkg/HybridBackup/rr2/test/support/scripts/realtime/remote_gen_burst_events.sh ./share/CACHEDEV1_DATA/.qpkg/HybridBackup/rr2/test/support/scripts/realtime/remote_gen_mass_events.sh ./share/CACHEDEV1_DATA/.qpkg/HybridBackup/rr2/test/support/scripts/realtime/remote_get_fs_of_path_list.sh ./share/CACHEDEV1_DATA/.qpkg/HybridBackup/rr2/test/support/scripts/realtime/start_v3_client_job.sh ./share/CACHEDEV1_DATA/.qpkg/HybridBackup/rr2/test/support/scripts/env.sh ./share/CACHEDEV1_DATA/.qpkg/HybridBackup/rr2/test/support/README.rst ./share/CACHEDEV1_DATA/.qpkg/HybridBackup/rr2/test/support/requirements.txt ./share/CACHEDEV1_DATA/.qpkg/HybridBackup/rr2/test/__init__.py

    Auf meiner lokalen 1282 sind diese Dateien noch vorhanden - und der Malware Remover hat NICHT gemeckert...


    Ticket bei QNAP ist offen - noch keine Reaktion.

    Habe die Antwort vom Support erhalten, spiegelt das wieder was bereits angemerkt wurde:

    Zitat von QNAP Support

    Sehr geehrter Herr x,


    die Malware-Entferner-ID MR2102 bedeutet, dass anfällige alte HBS cgi-Dateien entfernt werden. Das heißt, dass die alten anfälligen HBS-Konfigurationsdateien entfernt werden, nachdem Benutzer die HBS 3-App aktualisiert haben.



    Das ist nur eine Bereinigungsmeldung. Bitte machen Sie sich keine Gedanken wegen dieser Warnung. Wir werden versuchen, dies im nächsten Firmware-Update zu beheben.

    Die Leute vom QNAP haben Humor oder deren Service Partner:D

    Bei mir lautete es so:


    Zitat

    ...The extensive research and work is currently ongoing. QNAP malware ID MR2102 addresses infected or potentially compromised files. For your safety, the QNAP Intelligent Remover System has done this work to protect you. No further activity on your part is necessary. We thank you for your trust and for using our service and would be happy if you would rate your experience in a survey. Please use the following link...

    Beziehe ich die Informationen von tiermutter mit ein, erscheint mir die HBS3 Version kompromitiert zu sein und ursächlich unter anderem das Einfallstor für die Ransomware Atacke zu sein. Wenn das so ist, ist dies natürlich mega peinlich für einen NAS Hersteller der eine "ultimative Backuplösung" mit Slogans wie sichern Sie so Ihre wertvollen digitalen Daten wirbt. Für einen unbedarften User der keine Snapshots macht, alle Internetlinks und UPnP und Services aktiviert ist, es ja wohl der Rohrkrepierer schlechthin. QNAP HBS3, der Reisswolf unter den NAS Systemen^^

    Die Frage steht für mich noch im Raum:

    Ist das ein Fehler in einer HBS3 Version, da diese Entwickler seitig kompromitiert wurde, oder ist das ein Feature/Funktion in HBS3, dass UPnP und Portöffnungen und Verbindungen auf verschiedenen Ebenen versucht werden? Ich will es jetzt in der Umgebung nicht nochmals testen... :/

    Zitat von QNAPOPFER

    erscheint mir die HBS3 Version kompromitiert zu sein und ursächlich unter anderem das Einfallstor für die Ransomware Atacke zu sein.

    Davon ist doch die ganze Zeit schon auszugehen... wird jetzt natürlich nochmal untermauert.

    Zitat von QNAPOPFER

    mega peinlich für einen NAS Hersteller

    Die CVE zur HBS3 Lücke ist schon nen hartes Stück, gar keine Frage!

    QNAP kann aber nunmal nichts dafür, dass die Leute ihr NAS nackig ins Netz stellen. Sicherheitslücken treten immer und überall auf, deshalb macht man sowas nicht. Auch wenn die Lücke in HBS3 schon ein Knaller ist: wäre diese nicht gewesen, hätte man halt die nächste Lücke ausgenutzt.

    Zitat von QNAPOPFER

    oder ist das ein Feature/Funktion in HBS3, dass UPnP und Portöffnungen und Verbindungen auf verschiedenen Ebenen versucht werden?

    Davon habe ich jetzt nichts mitbekommen :/