[English]Die 3CX Desktop App des Telefonsystem-Anbieters 3CX wurde per Lieferkettenangriff (Supply-Chain-Attack) mit Malware infiziert. Im Nachgang habe ich noch einige zusätzliche Informationen. So ist der Vorfall inzwischen von 3CX bestätigt und sowohl Cyble als auch Kasperky haben Analysen vorgelegt. Laut Kaspersky scheint die nordkoreanische Hackergruppe Lazarus mit dem Angriff in Verbindung zu stehen. Möglich wurde der Angriff auch, weil eine 10 Jahre bekannte Schwachstelle in Windows durch Microsoft nur als "opt-in" zu schließen deklariert wurde – kaum jemand kennt diese Möglichkeit. Und längst nicht alle Virenscanner erkennen die Bedrohung.
Anzeige
Worum geht es?
Zum 30. März 2023 hatte ich im Blog-Beitrag 3CX Desktop-App in Supply-Chain-Attack infiziert (29. März 2023) eine Warnung für die Blog-Leser, die die Telefonsystem-Software des Anbieters 3CX verwenden, herausgegeben. Zu diesem Zeitpunkt bestand der Verdacht, dass deren 3CX Desktop App kompromittiert sein könnte.
Inzwischen gibt es, neben der in obigem Blog-Beitrag erwähnten Sentinel-Analyse noch eine weitere Analyse von Cyble mit dem Titel A Comprehensive Analysis of the 3CX Attack.
3CX ist ein internationaler Entwickler von VoIP-IPBX-Software. Das 3CX-Telefonsystem, eine auf offenen Standards basierende, softwarebasierte Telefonanlage, war ursprünglich nur unter Windows einsetzbar, kann aber seit 2016 auch unter Linux und auf Cloud-Plattformen eingesetzt werden. 3CX Desktop App ist eine Anwendung, mit dem am Desktop direkt mittels eines Headsets telefoniert werden kann. Die 3CXDesktopApp ist für Windows, macOS, Linux und Mobilgeräte verfügbar.
Die Infektion ist bestätigt
Henry Barson hatte in diesem Kommentar darauf hingewiesen, dass der 3CX CEO, Nick Galea, diesen Vorfall zum 30. März 2023 in der 3cx-Community in diesem Post bestätigt hat:
It is true. For the record we contacted SentinelOne for more information but never received it. We are issueing a new build as we speak we apologize for the inconvenience.
Zudem weist Blog-Leser Righter in diesem Kommentar auf die offizielle Bestätigung 3CX DesktopApp Security Alert vom 30. März 2023 im 3CX-Blog hin. Dort heißt es, dass die mit
Update 7 ausgelieferte Electron Windows App mit den Versionsnummern 18.12.407 und 18.12.416 eine Sicherheitslücke enthält. Die Electron Mac App-Versionsnummern 18.11.1213, die mit Update 6 ausgeliefert wurde, und 18.12.402, 18.12.407 & 18.12.416 in Update 7 sind ebenfalls betroffen.
Der Blog-Beitrag enthält noch die Information, dass die Ziel-Domain der Schadfunktionen deaktiviert wurde (wenig hilfreich, wenn die App und damit das System kompromittiert ist), und dass Antivirus-Lösung die 3CXDesktopApp.exe erkannt und in Quarantäne geschoben hätten (auch dies trifft nicht immer zu, siehe weiter unten zu Trend Micro).
Florian R. hatte mich am 3. April 2023 noch per Mail auf einen Post eines 3CX-Mitarbeiters aufmerksam gemacht (ist leider etwas liegen geblieben, da ich die Woche privat eingespannt war). Im 3CX-Blog hat Marcus Kogel, Marketing Manager DACH, 3CX, zum 1. April 2023 ein Update zum Sicherheitsvorfall: Samstag, 1. April 2023 veröffentlicht. Interessant sind ggf. die Empfehlungen für Nutzer/Administratoren.
In diesem Kommentar weist Stefan Kanthak auf eine Kommunikation mit 3CX aus dem Jahr 2013 hin, und verlinkt auf den securelist.org-Beitrag VULNERABLE and COMPLETELY outdated 3rd-party libraries/components used in 3CX Phone System 11. Die hatten schon damals ihre Lieferkette nicht wirklich im Griff.
3CX-Angriff über 10 Jahre alten Windows-Bug
Beim Supply-Chain-Angriffs wurden zwei DLLs, die von Windows Desktop-Anwendungen verwendet werden, durch bösartige, mit Malware ergänzte Versionen ersetzt.Eine der ersetzten DLLs ist die d3dcompiler_47.dll aus dem DirectX-Paket. In der kompromittierten Variante enthält die DLL eine verschlüsselte bösartige Nutzlast. Eine dieser Nutzlasten fungiert dabei als Trojaner, der Informationen von den Benutzersystemen stiehlt.
An dieser Stelle wird der aufmerksame Beobachter aufmerken und die Frage stellen, wieso eine legitime DLL aus Windows so einfach ersetzt werden kann? Diese werden doch durch Microsoft üblicherweise digital signiert. Verändert Angreifer eine solche Datei, bricht die digitale Signatur und das Laden sollte durch Windows verweigert werden.
Anzeige
Der Lieferkettenangriff durch Austausch der signierten DLLs war möglich, weil es seit zehn Jahren einen Windows-Bug gibt, den die Angreifer ausnutzen konnten. Daher betrachtet Windows diese manipulierte DLL-Datei weiterhin als gültig signiert. Die Kollegen von Bleeping Computer weisen in diesem Beitrag darauf hin, dass der Bug eigentlich längst geschlossen sein könnte.
Will Dormann wies darauf hin, dass die ausgenutzte Schwachstelle CVE-2013-3900 "WinVerifyTrust Signature Validation Vulnerability" erstmals am 10. Dezember 2013 durch Microsoft öffentlich gemacht wurde. Microsoft erklärte damals, dass das Hinzufügen von Inhalten zum Authenticode-Signaturabschnitt einer EXE (WIN_CERTIFICATE-Struktur) in einer signierten ausführbaren Datei möglich ist, ohne dass die digitale Signatur ungültig wird.
Microsoft hatte damals entschieden, eine bereitgestellte Korrektur optional zu machen. Bleeping Computer vermutet, weil legitime, signierte ausführbare Dateien sonst ungültig würden, weil diese Daten im Signaturblock einer ausführbaren Datei speichern. Das heißt, die Änderung kann auf Basis eines Opt-in aktiviert werden. Dazu ist ein manueller Eingriff in die Registrierung erforderlich, bei dem Einträge zu setzen sind. Microsoft hat im Artikel zu CVE-2013-3900 die erforderlichen Befehle als .reg-Datei veröffentlicht.
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography\Wintrust\Config] "EnableCertPaddingCheck"="1" [HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Cryptography\Wintrust\Config] "EnableCertPaddingCheck"="1"
Im betreffenden Support-Beitrag, der am 21. Januar 2022 letztmalig aktualisiert wurde, heißt es, dass dieser Registry-Fix zwar manuell zu setzen sei, dann aber für Windows 10 und Windows 11 gelte. Der "dicke Hund der Woche" kommt aber noch. Auf Twitter weist jemand am 5. Januar 2023 darauf hin, dass Windows 11 den ggf. manuell gesetzten Schutz für CVE-2013-3900 entfernt.
Wer diesen Schutz benötigt, muss die Registrierungseinträge erneut manuell setzen. Bleeping Computer hat in diesem Beitrag noch einige Details zum Thema zusammen getragen. Also mal wieder "Microsoft heißt perfektes Chaos" – mehr ist dazu nicht mehr zu sagen.
Backdoor durch 3CX-Software
Sicherheitsforscher von Kaspersky haben sich die kompromittierte 3CX Desktop App genauer angesehen und die Analyse samt neuen Erkenntnissen im Beitrag Not just an infostealer: Gopuram backdoor deployed through 3CX supply chain attack veröffentlicht. Eingangs war zwar von einem Trojaner die Rede, aber die Sicherheitsforscher von Kaspersky mussten feststellen, dass die infizierte Anwendung auch einen Hintertür (Gopuram) auf den Systemen installieren kann.
Die Kollegen von Bleeping Computer berichten hier (ein deutschsprachiger Beitrag findet sich bei heise), dass die von der nordkoreanischen Hackergruppe Lazarus seit mindestens 2020 für Angriffe auf Kryptowährungsunternehmen verwendete Gopuram-Backdoor beim 3CX-Vorfall auch als zweite Stufe der Nutzlast in die Systeme einer begrenzten Anzahl betroffener 3CX-Kunden eingeschleust wurde.
Laut Bleeping Computer ist Gopuram eine modulare Backdoor, die von ihren Betreibern dazu verwendet werden kann, die Windows-Registrierung und -Dienste zu manipulieren und Datei-Timestomping durchzuführen, um sich der Erkennung zu entziehen. Die Backdoor kann verwendet werden, um Nutzdaten in bereits laufende Prozesse zu injizieren, unsignierte Windows-Treiber mithilfe des Open-Source-Kernel-Treiber-Dienstprogramms zu laden sowie eine teilweise Benutzerverwaltung über den Befehl net auf infizierten Geräten durchzuführen.
Laut Kaspersky wurden weniger als zehn Systeme infiziert, was darauf hindeutet, dass die Hintermänner für den Lieferkettenangriff darauf aus waren, bestimmte Firmen gezielt zu kompromittieren, um finanzielle Vorteile zu erlangen (z.B. Crypto-Geld zu stehlen).
Trend Micro patzt bei 3CX
Blog-Leser Sascha M. hat mich am 5. April 2023 per Mail kontaktiert, weil er mich auf das Thema Erkennung des 3CX-Schädlings durch TrendMicro Worry Free Business Security hinweisen wollte. Er schrieb dazu:
Hallo Günter,
vorweg das Wichtigste: herzlichen Dank für Deinen Block! Absolute Spitzenklasse und wir lesen immer wieder gerne bei Dir.
Evtl. habe ich ein Thema was für Dich und Deinen Block interessant sein könnte:
Bei vielen unserer Kunden haben wir 3cx und TrendMicro Worry Free Business Security (WFBS on Prem) oder Worry Free Business Security Services als Teil des XDR (WFBSS) im Einsatz.
Nach dem großen Thema um 3cx ist es natürlich wichtig, dass die eigene und natürlich die AV-Software des Kunden auf solchen Risiken reagiert.
Nach Blog ist TrendMicro das Thema bereits seit dem 30.03.2023 bekannt. Doch bis heute reagiert weder das XDR noch die onPrem-Lösungen auf die kompromittierten Dateien.
In Anbetracht der Tatsache, dass jeder der 3cx im Einsatz hat oder hatte, angehalten ist sämtliche Systeme zu scannen, dürften TrendMicro Kunden sich hier in falscher Sicherheit wiegen.
TrendMicro habe ich bereits am 31.03.2023 auf den Umstand hingewiesen, gestern hat sich dann der Support dem Thema angenommen. Bisher jedoch nur Nachfragen zu Lizenznummern, den Dateien und LOG Einträgen (welche leer sind).
Ich habe Dir ein Video angehängt, welches auch an TM geschickt wurde. Im Video haben wir noch die Pattern 18.359.00, aktuell ist die 18.361.00 aber auch hier: Erkennungsrate 0.
Keine Ahnung was TrendMicro da macht, für mich persönlich ein absolutes NoGo.
Immerhin reagiert die TrendMicro E-Mail Security auf die Dateien (hilft zwar nichts, irgendwer scheint aber doch seinen Job gemacht zu haben).
Ergänzung: Während des Schreibens der Mail kam eine Mail von TrendMicro, demnach könne es nicht an TrendMicro liegen und die Patterns sollten reagieren.
Hier noch ein Screenshot von einem Kunden zu dem ich eben gerade Kontakt hatte.
3cx läuft in der kompromittierten Version auf dem System und brav daneben ein TrendMicro der nichts unternimmt.
Trend Micro und 3CX-Erkennung, zum Vergrößern klicken
Obiger Screenshot zeigt die Analyse durch TM, in nachfolgendem Screenshot sind die kompromittierten DLLs zu sehen. Der Virenschutz patzt also und wiegt die Kunden in Sicherheit.
Keine Ahnung, ob sich da nun was getan hat. Falls jemand Trend Micro und 3CX im Einsatz hat, sollte er doch mal genauer nachschauen, ob wirklich keine Infektion vorliegt. Danke an Sascha für den Hinweis. Das Video selbst habe ich mal nicht hochgeladen.
Ähnliche Artikel
3CX Desktop-App in Supply-Chain-Attack infiziert (29. März 2023)
31.000 3CX-Telefonanlagen in Deutschland per Internet erreichbar
Schwachstelle in Windows 3CX-Telefonanlagen, Patchen ist angesagt
2015
Guten Abend.
Wir kommen von ApexOne und setzen aktuell Deepsecurity (beides von Trend Micro) ein. Ebenso kommt die XDR-Lösung VisionOne zum Einsatz.
Sowohl ApexOne, Deepsecurity und auch die XDR Lösung haben zeitnah reagiert und entsprechend geblockt bzw. reportet. Trend war bei uns somit tatsächlich sehr schnell. Kurz nach Deinem ersten Blogbeitrag zum Thema 3CX, gingen bei uns erste Meldungen ein. Die angesprochene "Worry Free" Lösung kenne ich nicht.
Gruß, Christian
Jetzt war ich gerade irritiert. gleicher Name, gleiche Umgebung. :-)
Also wir haben die gleichen Produkte im Einsatz. Zusätzlich hatten in der drauffolgenden Woche noch einen Anruf von unserem Trend Micro Ansprechtpartner. Er hat mit uns einen Termin mit einem Trend Micro Techniker abgestimmt, der einmal auf unsere Umgebung geschaut hat und die Funde geprüft hat.
Vielen Grüße
Anderer Christian
Kann mir bitte wer verraten wie diese schwachstelle bitte funktionieren soll?
Also man kann nach der signatur irgendwelchen daten müll anhängen,
gut dieser kann auch malware sein.
Aber das ist kein ausführbarer Bereich der dll… also wie soll der Code bitte zur Ausführung kommen?
Man braucht dafür doch irgend einen anderen Code der dann aber erst recht unsigniert ist etc…
Also was ist der so große voreilt davon irgend ein payload in einem nicht ausführbarem teil einer dll abzulegen?
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2013-3900
Liest sich etwas wie eine Backdoor, die in the wild vom wem auch immer (noch) genutzt wird. Daher ggf. auch die Herangehensweise in Bezug auf den Fix bzw. Verhalten Win11.
Hier ist es beschrieben: https://www.darkreading.com/attacks-breaches/3cx-breach-cyberattackers-second-stage-backdoor
die dll mit dem Schadcode mach schon mal gar nichts, man braucht eine 2te die den Code liest in ein ausführbaren speicher Bereich packt und dann ausführt hier in dem Fall eine modifizierte ffmpeg.dll unsigniert natürlich.
Finde Bilder auf Imgur bissl ungünstig. Ohne JS sieht man da nix, Cookies gibt es ungefragt dazu.
"Der Lieferkettenangriff durch Austausch der signierten DLLs war möglich, weil es seit zehn Jahren einen Windows-Bug gibt, den die Angreifer ausnutzen konnten. Daher betrachtet Windows diese manipulierte DLL-Datei weiterhin als gültig signiert."
Das ist dumnerweise VÖLLIG IRRELEVANT!
1) (nicht nur) diese DLLs werden (nicht nur von ahnungslosen Fricklern wie denen bei 3CX, sondern auch Mozilla, Google, Microsoft, …) mitgeliefert und in die PRIVATEN Verzeichnisse der jeweiligen Programme installiert;
2) da (nicht nur die ahnungslosen Frickler bei 3CX) ihren Schrott noch immer ohne /DEPENDENTLOADFLAG:2048 bauen (siehe https://skanthak.homepage.t-online.de/!execute.html oder
https://devblogs.microsoft.com/oldnewthing/20230328-00/?p=107978) und weder SetDefaultDllDirectories() (siehe https://msdn.microsoft.com/en-us/library/hh310515.aspx) noch LoadLibraryEx() (siehe https://msdn.microsoft.com/en-us/library/ms684179.aspx) mit dem Flag LOAD_LIBRARY_SEARCH_SYSTEM32 aufrufen laden deren Programme auch Windows-System-DLLs aus ihrem Installationsverzeichnis;
3) da typische Windows-Frickler an allen unter 2) genannten Stellen auch LOAD_LIBRARY_REQUIRE_SIGNED_TARGET (siehe https://msdn.microsoft.com/en-us/library/ms684179.aspx) nicht verwenden lädt ihr Schrott DLLs ohne Prüfung der digitalen Signatur, d.h. es ist völlig wurscht, ob der für CVE-2013-3900 notwendige Registry-Eintrag gesetzt ist oder nicht.
Das schaut natürlich wieder "super" gut aus, danke für die ausführliche Analyse. Also noch so eine Software (und nein ich spreche nicht jedem Programmierer seine Fähigkeiten ab, ich kenne selbst welche die eine ordentliche Arbeit abliefern) die einfach broken by design und nicht nach best practice programmiert ist. Es wird echt mal langsam Zeit, dass sich hier was ändern. Man hat es jeden Tag nur noch mit Software zu tun, bei der nicht mal Ansatzweise über die Sicherheit nachgedacht wurde oder über irgendwelche Basics. Ich weiß ja nicht woran es klemmt, aber das ist erstens nicht meine Aufgabe, da ich kein Programmierer bin und aus gutem Grund keiner werden wollte und zweitens ist das nicht meine Gehaltsklasse. Nur bekomme ich als IT-Admin jedes mal den Shitstorm ab, wenn es irgendwo eine Sicherheitslücke gibt für die ich nicht mal was dafür kann. Ich habe langsam kein Bock 1000 mal im Jahr den Kopf für schlecht programmierte Software hinhalten zu müssen. Nur, weil nicht nach gewissen Regeln und Standards programmiert wird. Kann ja dennoch Sicherheitslücken geben, aber so wie ich das in diesem Fall lese sind das ja wirklich Grundlagen, die so programmiert sein sollten.
Apropos "Dicke Hunde": bei JEDEM Upgrade werden nur die Registry-Einträge (oder Dateien bzw. Verzeichnisse) übernommen, die die Upgrade-Routinen kennen und berücksichtigen. Da viele der bei M$FT heute frickelnden Kinder Altherthümer aus 2013 noch nicht oder nicht mehr kennen ist das beobachtete Verhalten dummerweise Standard: JEDER Administrator "darf" daher nach JEDEM Upgrade alle seine Änderungen prüfen.
Siehe beispielsweise die zum Stopfen einer SAFER und AppLocker-Lücke notwendige https://skanthak.homepage.t-online.de/appcert.html
Ach, nicht nur das.
Selbst Microsoft bekommt es nicht hin, sich an die eigenen Standards zu halten.
Beispielsweise, wenn ich die Temp-Verzeichnisse auf ein anderes Laufwerk lege und dementsprechend die Variablen %temp% und %tmp% angepasst habe.
Ein Programm hat IMMER diese Variablen zu lesen und seine temporären Dateien in den dort hinterlegten Temp-Ordnern zu speichern.
Und die meisten Programme bekommen es auch nicht hin, ihre Temp-Dateien beim Beenden aufzuräumen.
So darf man eigentlich täglich die Temp-Verzeichnisse manuell oder per Script leeren.
Guten Morgen,
das Problem mit Trend Micro kann ich bestätigen. Habe gerade am Donnerstag noch die letzten 3CX Apps entsorgt wo parallel auch immer Trend Micro lief habe mich zwar kurz gewundert warum 3CX überhaupt noch lief obwohl es sich, nach Versionsnummer, um eine kompromittierte Version handelt dann aber nicht weiter drüber nachgedacht. 3CX deinstalliert, noch einen Scan laufen lassen (der überall sauber war) und alles für gut befunden.
Jetzt wird natürlich ein Schuh draus…
Hat jemand Erfahrungen mit dem Setzen des RegKeys "EnableCertPaddingCheck"?
Irgendwas, was danach nicht mehr funktioniert?
Die FAQ des am 11.4.2023 aktualisierten Sicherheitshinweises https://msrc.microsoft.com/update-guide/vulnerability/CVE-2013-3900 enthält folgenden DEUTLICHEN Hinweis, dass SAFER alias SRP weiterhin unterstützt wird:
| Wirkt sich das neue Überprüfungsverhalten auf Richtlinien für Softwareeinschränkungen aus?
| Für Kunden, die sich für die strengere Verifizierung entschieden haben, kann jede
| Richtlinie für Softwareeinschränkungen, die von signierten Dateien abhängt oder
| einen bestimmten Herausgeber erwartet, betroffen sein, wenn die Signatur einer
| Datei nicht den strengeren Anforderungen der Authenticode-Signaturüberprüfung
| entspricht.