Analyse von Angriffen auf die Software-Lieferkette
3CX ist ein bekanntes Unternehmen, das VoIP- und Unified Communications-Produkte anbietet. Das Unternehmen behauptet, über 600,000 Installationen und 12 Millionen tägliche Benutzer zu verfügen. Zweifellos ein verlockendes Ziel für Betrüger.
Ende März wurde 3CX Opfer des 3CX Supply Chain Angriffs, einem ausgeklügelten Software-Supply-Chain-Angriff, bei dem es gelang, Malware in die Desktop-Software des Unternehmens einzuschleusen. Die Malware zielt darauf ab, Informationen zu stehlen, bietet aber auch eine Hintertür.
In diesem Beitrag werden wir diesen Angriff auf die Lieferkette untersuchen und die Abfolge der Ereignisse aus verschiedenen Blickwinkeln verfolgen. Dabei könnten wir Erfahren Sie, wie der Angriff blockiert oder abgeschwächt werden kann.
Inhaltsverzeichnis
Wie der Angriff durchgeführt wurde
Die Angreifer kompromittierten zunächst ein Softwarepaket namens X_TRADER von einer Firma namens Handelstechnologien mit Sitz in Chicago, IL. Die Software enthielt Malware ( VERSCHLEIERTES SIGNAL Backdoor) eingeschleust. Das Installationsprogramm wurde mit einem gültigen Code-Signing-Zertifikat digital signiert. Böse Akteure sind möglicherweise in den Build eingedrungen pipeline bis 2021 und modifizierte die Software, bevor sie verpackt und signiert wurde. Dies war der erste Sprung im verketteten Lieferkettenangriff. Bis März 2022 war dies berichtet im Rahmen von Operationen DreamJob alias BLINDINGCAN und AppleJeus, wobei die Zielgruppe US-amerikanische Organisationen in den Bereichen Nachrichtenmedien, IT, Kryptowährung und Fintech sind.
Diese Software wurde 2020 (!) eingestellt, stand aber ab 2022 zum Download bereit. Ein 3CX-Mitarbeiter installierte sie auf einem PC. Die Bösewichte stahlen die Firmenanmeldeinformationen des Mitarbeiters vom kompromittierten Computer. Interessanterweise VERSCHLEIERTES SIGNAL verwendete eine URL unter der Trading Technologies-Website für Befehls- und Kontrollzwecke (eine Taktik, die häufig verwendet wird, um einer Entdeckung zu entgehen).
Zwei Tage nach dem ersten Angriff nutzten die Angreifer das VPN des Unternehmens, um auf die internen Systeme von 3CX zuzugreifen. Sie nutzten den FRP-Reverse-Proxy, ein öffentliches Tool, das sowohl für das Gute als auch für das Böse verwendet werden konnte, um sich seitlich zu bewegen. Sie wussten, was sie mit dem gewonnenen Fußabdruck tun sollten: Sie kompromittierten die Build-Systeme von Windows und macOS. Jede Umgebung mit unterschiedlichen Tools. Beispielsweise verwendeten sie das SigFlip-Tool, um den RC4-verschlüsselten Shellcode in den Signaturanhang des d3dcompiler_47.dll.
Software-Updates für die 3CX Desktop-App für Windows und macOS wurden infiziert. Dies war der zweite Hop in diesem (ersten?) mehrstufigen Supply-Chain-Angriff. Das Software-Update für Windows, das ebenfalls ordnungsgemäß mit einem 3CX-Codesignaturzertifikat signiert ist, legt zwei schädliche Dateien ab, ffmpeg.dll und d3dcompiler_47.dll (mit gleichwertigem .dylib Bibliotheken für macOS), die von dem gutartigen 3CXDesktopApp ausführbare Datei (über Side-DLL-Ladetechnik). Der in der zweiten DLL verschlüsselte Shellcode lädt eine weitere DLL, die von IconSpeicher GitHub-Repository: eine ICO-Datei, die den verschlüsselten Command and Control (C2)-Server enthält.
Dafür wurden über 20 Domänen bereitgestellt, was uns zeigt, wie sorgfältig der Angriff auf die Software-Lieferkette geplant wurde.
Die Verbindungen von den PCs der Opfer zu den C2-Domänen begannen am 06. März 2023 und endeten am 29. März.
Bitte beachten Sie, dass (1) kein Quellcode in einem Code-Repository geändert wurde, sondern die Malware-Nutzlast während des Builds eingeschleust wurde, (2) ein legitimer ffmpeg DDL wurde durch ein bösartiges ersetzt und über Side-DLL-Loading geladen und (3) eine beliebte VoIP-App wurde mit mehrstufiger Malware in eine Waffe verwandelt.
Wie der Vorfall gehandhabt wurde
Es scheint, dass 29CX am 3. März von Dritten Berichte über einen böswilligen Akteur erhielt, der „eine Schwachstelle in ihrem Produkt ausnutzte“. Anti-Malware-Plattformen haben ihre Aufgabe (teilweise) erfüllt.
Am 30. März 2023 wird die 3CX CISO, Pierre Jourdan, veröffentlichte eine Sicherheitsalarm Kunden und Partner werden darüber informiert, dass ihre Electron-App (Desktop-Client) nach einem Update mit Malware ausgeliefert wurde. Der Beitrag listet die betroffenen Versionen (für Windows und Mac) auf, gibt eine kurze Erklärung zu den anfänglichen Eindämmungsmaßnahmen und eine kurze Empfehlung, weiterhin mit dem Web-Client statt mit dem infizierten Desktop-Client zu arbeiten.
Meiner Meinung nach war die anfängliche Mitteilung, wenn auch etwas knapp, auf den Punkt gebracht. Es ist für keinen Anbieter leicht zu erkennen, dass es ein ernstes Sicherheitsproblem gibt, das möglicherweise viele Kunden betrifft. Das Unternehmen erkannte das Problem und wies sofort auf einen möglichen Schuldigen hin:
„Erwähnenswert – dies scheint ein gezielter Angriff einer Advanced Persistent Threat gewesen zu sein, vielleicht sogar staatlich gefördert, die einen komplexen Supply-Chain-Angriff durchführte und auswählte, wer die nächsten Stufen ihrer Malware herunterladen würde.“
Das Unternehmen bot eine Alternative an, um die Funktionsfähigkeit des Produkts aufrechtzuerhalten: Progressive Web App oder PWA, anstelle der Desktop-App, basierend auf der Elektron Rahmen.
„Wir empfehlen Ihnen dringend, stattdessen unsere PWA-App zu verwenden. Die PWA-App ist vollständig webbasiert und kann 95 % der Funktionen der Electron-App. Der Vorteil besteht darin, dass keine Installation oder Aktualisierung erforderlich ist und die Chrome-Websicherheit automatisch angewendet wird.
Der Grund, warum wir zwei Apps haben, ist, dass die PWA-Technologie noch nicht verfügbar war, als wir die Electron-App gestartet haben. Jetzt ist sie ausgereift und funktioniert wirklich gut.“
Nun, die Web-App könnte auch infiziert sein, und eine PWA kann per Definition Code in Service Workern (JavaScript-Code) mit (eingeschränktem) Zugriff auf lokale Ressourcen ausführen. Der Beitrag behauptete, dass die PWA zu diesem Zeitpunkt nicht infiziert war. Wir können verstehen, warum in vielen der über 277 Kommentare zu dem Beitrag einige gefragt haben, ob die erwähnte PWA-Alternative oder die PBX-Serversoftware selbst kompromittiert wurde.
Am selben Tag, 3CX beauftragte Mandiant mit der Untersuchung, mit weiteren Anweisungen. Im Grunde genommen wird das Update für
Installieren Sie die Win/Mac-Desktop-App vor Ort, deinstallieren Sie die Electron-App für betroffene Versionen und wechseln Sie zur PWA-Alternative. Das reicht nicht unbedingt aus, da die Malware möglicherweise Zugriff auf betroffene Systeme hat, die Malware persistent speichert oder sich sogar seitlich ausbreitet. Die vollständige Entfernung von Malware ist nicht so einfach. Wir können verstehen, dass angesichts der Dringlichkeit nicht immer der beste Weg zur Bewältigung eines Vorfalls gefunden wird … es sei denn, das Szenario wurde im Voraus durchgeplant und geeignete Abhilfemaßnahmen identifiziert.
Die folgender Beitrag, jetzt vom CEO des Unternehmens, versucht, die Kunden mit der Ankündigung eines reinen Sicherheitsupdates für die DesktopApp zu beruhigen. Einige grundlegende Schutztechniken wie Passwort-Hashing wurden implementiert („Besser als nie ist zu spät; nie erfolgreich zu sein wäre eine zu lange Zeit.“, Chaucer Dixit im Jahr 1386.) Konkrete, umgesetzte Schutzmaßnahmen sind besser als gute Absichten und geplante Pläne… Aber wie wurden Passwörter früher gespeichert?
Wie dem auch sei, Google hat das bestehende 3CX-Codesignaturzertifikat für ungültig erklärt und Antivirenanbieter haben auch jede mit diesem Zertifikat signierte Software blockiert. Die MSI-Installationsprogramme für das DesktopApp-Update mussten mit einem neuen Codesignaturzertifikat neu generiert werden, was einige Stunden dauerte. Das war zu erwarten!
3CX hat vorsorglich einen neuen Build-Server bereitgestellt. Dies ist sinnvoll: Ohne Analyse war nicht bekannt, wie die Malware eingeschleust wurde.
Am selben 1. April veröffentlichte der CEO eine Update zum Sicherheitsvorfall. Der Beitrag beschreibt, was das Unternehmen unternommen hat (eine umfassende Untersuchung durchgeführt und den gesamten Quellcode der clientseitigen Software validiert). Die Sicherheit kann auch samstags nicht warten.
Als der Vorfall analysiert war und die Infrastruktur des Angreifers bekannt war, wurden das GitHub-Repository und die Domänen für die vom APT verwendeten C2-Server entfernt, wodurch die Malware effektiv ausgeschaltet wurde.
Im April 11th, der CISO hat die erste Ergebnisse aus der Vorfallanalyse. Als Erster wurde der mit Nordkorea in Verbindung stehende APT UNC4736 erwähnt.
Am Freitag, den 20. April, veröffentlichte Mandiant die erste Analyse des Vorfalls. YARA- und Snort-Erkennungsregeln wurden veröffentlicht.
Am selben Tag veröffentlichte der CEO von 3CX einen neuen Beitrag mit dem suggestiven Namen „Taten, nicht Worte – Unser 7-Stufen-Sicherheitsaktionsplan!“. Der Untertitel ist recht interessant: „Sicherung der Zukunft von 3CX nach der ersten kaskadierenden Software-in-Software-Lieferkettenangriff.“ Die Schritte der entworfenen Sicherheitscharta sind:
- Verstärkung mehrerer Ebenen der Netzwerksicherheit.
-
Modernisierung schafft Sicherheit.
-
Laufende Überprüfung der Produktsicherheit.
-
Verbesserung der Produktsicherheitsfunktionen.
-
Durchführen fortlaufender Penetrationstests.
-
Verfeinerung des Krisenmanagements und des Alarmbehandlungsplans.
-
Aufbau einer neuen Abteilung für Netzwerkbetrieb und Sicherheit.
Dieses lobenswerte Programm wird von den Analysten sicherlich im Auge behalten werden …
Nachwirkungen: So reagierte die Branche
Seit der Vorfall öffentlich wurde, sind erst wenige Wochen vergangen. Doch die Branche reagiert.
CVE-2023-29059 wurde zugewiesen. Stand heute hat es einen CVSSv7.8-Risiko-Score von 3 (HOCH). Die 3CX-Produkte haben nur 16 CVEs aufgelistet, was im Vergleich zu Anbietern mit ähnlichen Implementierungsstufen gut aussieht. Aber dieser Vorfall ist nicht die übliche Verwundbarkeit in der Tat. Dies ist ein aktiver gezielter Angriff durch eine Active Persistent Threat (APT), wie die CISO ist am bekanntesten.
Die CWE-506 Die Kategorisierung dieses Vorfalls als „eingebetteter Schadcode“ hilft uns nicht wirklich dabei, zu verstehen, wie wir solche Angriffe auf die Software-Lieferkette verhindern können. Leider haben die Bösewichte viele Möglichkeiten, Schadsoftware zu verbreiten, und Angriffe auf die Lieferkette sind das neue Kronjuwel in ihrem Arsenal. CWE-506 sollte verbessert werden, um die aktuellen Szenarien abzubilden, einschließlich derer, die auf dem Eindringen in das Build-System basieren.
Die APT, die von Mandiant als UNC4736 bezeichnet wurde, verwendet Taktiken und Techniken, die denen der weithin bekannten Lazarus Group (APT38) ähneln, die vom nordkoreanischen Staat gegründet wurde, und den Tätern der WannaCry-Ransomware-Kampagne von 2017. Solche Verbindungen zwischen schlechten Akteuren in stalinistischen Staaten mit regulären Arbeitszeiten sind schwer nachzuweisen, aber Forscher von Menschenmenge und ESET stellte fest, dass die verwendeten Taktiken, Techniken und Verfahren (TTPs) denen ähneln, die Lazarus APT38 üblicherweise verwendet. Das Verständnis ihrer Funktionsweise ist für die Erkennung, Prävention und Ausrottung von entscheidender Bedeutung.
Noch schwieriger ist es, ihre in Geheimnisse gehüllten Ziele zu kennen.
Dieser Angriff ist wichtig genug, CISA, die US-amerikanische Cybersicherheitsbehörde, veröffentlichte eine beratend mit den Beiträgen der Anbieter und Links zu mehreren Analysen zum Supply-Chain-Angriff. Diese zu lesen ist für Cyber-Sec-Experten relevant.
Der Vorfall erinnert uns an den SolarWinds-Angriff. Angesichts der enormen Auswirkungen beeilten sich viele Anbieter, die infizierten VoIP-Desktopprodukt-Installationsprogramme zu analysieren. Aber das ist nur der letzte Schritt. Weitere Details sind erforderlich, um zu verstehen, was mit der Sicherheit der Build-Systeme der beiden betroffenen Organisationen nicht geklappt hat und welche Schritte die böswilligen Akteure unternommen haben, um diese Build-Systeme zu beeinträchtigen und die Malware während des Builds einzuschleusen. Andernfalls wird sich dieser Vorfall immer wieder wiederholen.
Und nun: Lehren gezogen!
Wenn man einen Mannschaftssport betreibt und hinterher jemandem aus der eigenen Mannschaft zuhört, der jeden noch so kleinen Spielfehler erklärt, ist das selbst für den gelassensten Geist ein herber Schlag. Aber hier in Spanien ist jeder ein Nationaltrainer! Lassen Sie mich also als Pep Guardiola, José Mourinho, Alex Ferguson und Arrigo Sacchi gleichzeitig agieren.
Handeln Sie, als stünde Ihr Build-System unter schwerem Artilleriefeuer. Vielleicht können Sie einen Mitarbeiter nicht daran hindern, nicht autorisierte Software auf Arbeits-PCs zu installieren. Wahrscheinlich fordern Entwicklungsteams strengere Richtlinien. Aber seien Sie wachsam beim Erstellen und Bereitstellen pipelineWenn Sie Software an Kunden liefern, sollte die Sicherheit bei der Erstellung der Software genauso wichtig sein wie die Sicherheit des Softwareprodukts selbst.
VorfallvorbereitungEs ist schwierig, vielleicht sogar steril, die wahrscheinlichsten Szenarien für Sicherheitsvorfälle vorherzusehen. Sollte ich lernen, einen Defibrillator zu benutzen? Nein, es sei denn, ich lebe mit einer Neigung zum Kartenlesen.iac Verhaftung. Aber um Himmels willen! Seien Sie darauf vorbereitet, Ihren Build von Grund auf neu zu erstellen, mit Widerruf und Erneuerung von Schlüsseln, Zugriffstoken, öffentlichen Schlüsselpaaren und Zertifikaten.
Build-Systeme müssen bestimmte Eigenschaften haben: Der aktuelle Trend zu Builds in flüchtigen Umgebungen und mit isolierten/parameterlosen/hermetischen und sogar reproduzierbaren könnte der Rahmen sein, um verhindern Angriffe wie der auf 3CX Supply Chain Attack, wenn sie durch zusätzliche Anforderungen an andere Systeme im Build & Deploy ergänzt werden pipeline. Sehen Build-Anforderungen für Google SLSA als Referenz.
Die richtige Kommunikation ist der Schlüssel. Transparenz ist Pflicht. Das Problem herunterzuspielen oder unter den Teppich zu kehren, ist das Schlimmste, was eine Organisation tun kann. Sicherheitsvorfälle schaden dem Ruf oft stärker als anderen Vermögenswerten, und eine schlechte Kommunikation nach dem Verstoß kann katastrophale Folgen haben.
Verwandeln Sie Probleme in Chancen. Ein guter Vorfall kann Verbesserungen bei Sicherheitskontrollen auslösen, die nie ihren Weg in den engen Produktplan gefunden haben. Sogar wesentliche Dinge wie ordnungsgemäßes Passwort-Hashing und Dokumentation der Sicherheitskonfiguration/-härtung könnten kurzfristig eingeplant werden. Aber für Angriffe auf die Lieferkette, die Härtung der Build-Systeme und das Hinzufügen von Attestierungen und Integritätsprüfungen bei jedem Schritt des Builds und der Bereitstellung pipelines sind unerlässlich. Es sollte für einen Angreifer nicht so einfach sein, solche Änderungen in das Build-System einzuschleusen.
Seien Sie vorbereitet. Andernfalls könnte Ihr Unternehmen einer existenziellen Bedrohung ausgesetzt sein, wie beispielsweise dem 3cx-Software-Lieferkettenangriff.





