Ende März 2023 entlarvten Sicherheitsforscher einen Bedrohungsakteur Komplexer Software-Supply-Chain-Angriff über Geschäftskommunikationssoftware von 3CX, hauptsächlich die Desktop-App des Unternehmens für Sprach- und Videoanrufe. Die Forscher warnten, dass die App irgendwie mit einem Trojaner infiziert sei und dass ihre Verwendung die Organisation einem möglichen Exfiltrationsplan eines Bedrohungsakteurs aussetzen könnte. Der Angriff wurde als „Smooth Operator“ bezeichnet und es gibt Hinweise darauf, dass er schon seit Monaten andauert.
Was genau ist also passiert, wie stellt die Verwendung dieser trojanisierten Version ein Risiko für Sie dar und wie hätte dies durch den Einsatz von Software-Signierung und -Verifizierung verhindert werden können?
Das Wichtigste zuerst: Was ist 3CX?
3CX ist eine softwarebasierte IP-PBX-Anlage (Private Branch Exchange) mit offenen Standards, die eine herkömmliche Hardware-PBX-Anlage ersetzt. Es soll es Unternehmen ermöglichen, Anrufe mithilfe der VoIP-Technologie (Voice over Internet Protocol) zu tätigen und zu empfangen, die Sprachkommunikation über das Internet überträgt. 3CX umfasst außerdem erweiterte Funktionen wie Videokonferenzen, Präsenz, Instant Messaging und mehr und kann vor Ort oder in der Cloud bereitgestellt werden. Windows, macOS und Linux sind nur einige der beliebten Betriebssysteme, auf denen die App verfügbar ist. Darüber hinaus ist der Client dank einer Chrome-Erweiterung über Browser zugänglich, verfügt sogar über eine PWA-Version und ist als mobile Anwendung für Android- und iOS-Geräte verfügbar.
Auf der 3CX-Website können Sie sich einen Eindruck von den potenziellen Auswirkungen eines Software-Supply-Chain-Angriffs verschaffen. Auf dieser Website nutzen 600,000 Unternehmen ihre App und über 12 Millionen Nutzer pro Tag.
Ein kleiner Einblick in den Angriff: Was Sie wissen müssen
Da dies etwas komplex ist, unterteilen wir es in Schritte:
- Sie laden eine herunter Sie haben die trojanisierte Version der Desktop-App installiert oder Sie haben sie bereits installiert und aktualisieren sie einfach mit einer trojanisierten Version.
- Die ausführbare Datei 3CXDesktopApp.exe lädt eine schädliche Dynamic Link Library (DLL) namens ffmpeg.dll.
- Die ffmpeg.dll wird verwendet, um eine verschlüsselte Nutzlast aus d3dcompiler_47.dll zu extrahieren und auszuführen.
- Die Malware lädt dann harmlos aussehende Symboldateien herunter, die auf GitHub gehostet werden und Base64-codierte Zeichenfolgen enthalten, die an das Ende der Bilder angehängt werden.
- Diese verschlüsselten Daten werden dann entschlüsselt und zum Herunterladen einer weiteren Stufe verwendet, die den verschlüsselten C&C-Server enthält, mit dem sich die Hintertür verbindet, um die mögliche endgültige Nutzlast abzurufen.
- In der letzten Phase wird die Info-Stealer-Funktionalität in die Praxis umgesetzt, einschließlich der Erfassung von Systemdaten und Browserdaten von Chrome-, Edge-, Brave- und Firefox-Browsern. Dies kann das Abfragen des Browserverlaufs und von Informationen aus der Tabelle „Orte“ sowie möglicherweise das Abfragen der Verlaufstabelle umfassen.
Zunächst 3CX spielte den Angriff herunter, gab jedoch später zu, dass es sich um eine echte Bedrohung handelte, und schlug vor, die App gemäß den spezifischen Anweisungen zu deinstallieren und neu zu installieren sowie in der Zwischenzeit die PWA-Version zu verwenden, bis es dem Unternehmen gelingt, den Vorfall zu entschlüsseln und einzudämmen.
Ein weiterer sehr wichtiger Faktor, den es zu beachten gilt, ist, dass die Kompromittierung ein Codesignaturzertifikat beinhaltet, das zum Signieren der trojanisierten Binärdateien verwendet wird. Nun ja, nicht ganz – es nutzt tatsächlich eine bekannte Schwachstelle namens CVE-2013-3900 (ursprünglich 2013 veröffentlicht, aber 2022 und diese Woche erneut aktualisiert), um es zu schaffen erscheinen rechtmäßig unterzeichnet.
Déjà Vu: Das ist schon einmal passiert
Wenn diese Geschichte von a Die von einem 3CX-Trojaner befallene Version kommt Ihnen bekannt vor, weil sie schon einmal vorgekommen ist.
In diesem Fall sind es SieEs ist nicht klar, ob eine vom Unternehmen verwendete Open-Source-Upstream-Bibliothek infiziert wurde oder ein tatsächlicher Angriff die Entwicklungsumgebung des Unternehmens verletzt hat.
Bei anderen berühmten Angriffen, von „Kingslayer“ (2016) über „CCleaner“ (2017), „VestaCP“ (2018), „WIZVERA VeraPort“ (2020) bis hin zu „SolarWinds“ (2020), ist es ein Eine gängige Vorgehensweise von Bedrohungsakteuren besteht darin, entweder die Server, die Build-Umgebung oder die tatsächlich herunterladbare ausführbare Datei eines Unternehmens zu kompromittieren. Schließlich ist die Tarnung von etwas Schlechtem und Gefährlichem als etwas, dem Sie vertrauen können, eine großartige Möglichkeit, Menschen dazu zu bringen, Ihrer Nutzlast zu vertrauen und sie herunterzuladen.
Das ist Teil der Definition von a Angriff auf die Software-Lieferkette – Die Angreifer haben die Software-Lieferkette kompromittiert, um Schadsoftware an eine große Anzahl von Opfern zu verteilen. In jedem dieser berühmten Fälle konnten die Angreifer Schadcode in legitime Softwarepakete einschleusen, die dann an Benutzer verteilt wurden. Dies gelang den Angreifern häufig, indem sie einen vertrauenswürdigen Softwareanbieter oder -anbieter kompromittiert haben, beispielsweise einen Software-Update-Server oder ein Codesignaturzertifikat.
Indem die Angreifer ahnungslose Kunden dazu bringen, eine modifizierte Version einer legitimen Anwendung herunterzuladen, können sie praktisch alles darin verbergen.
Und hier liegt das Hauptproblem – „ahnungslos“. Schließlich stammt die ausführbare Datei, Binärdatei oder das Image von der erstellenden Firma, wurde offenbar von dieser genehmigt und enthält sogar ein signiertes Zertifikat. Was kann ein Kunde noch tun? Sollten sie das Unternehmen anrufen, um jedes Update zu überprüfen? Den Code (falls verfügbar) auf die Existenz von Hintertüren scannen? Das ist absurd und unrealistisch. Aber dort is etwas, das getan werden kann.
Wie können Sie über ein Zertifikat hinaus eine Vertrauensebene hinzufügen?
Das vorgeschlagene Modell ist ziemlich einfach und basiert auf der gleichen Idee wie Code Signing-Zertifikate. Ein Codesignaturzertifikat ist ein von einem Dritten ausgestelltes digitales Zertifikat, das zum digitalen Signieren von Software oder Code verwendet wird. Wenn Software mit einem Codesignaturzertifikat signiert wird, können Benutzer die Authentizität und Integrität der Software überprüfen, bevor sie sie installieren oder ausführen.
Signaturzertifikate werden von vertrauenswürdigen Drittanbietern ausgestellt Zertifizierungsstellen (CAs), die die Identität des Softwareherausgebers und die Integrität des Softwarecodes überprüfen. Die Zertifizierungsstelle erstellt mithilfe kryptografischer Algorithmen eine digitale Signatur der Software, die dann in den signierten Code einbezogen wird. Wenn ein Benutzer versucht, die Software zu installieren oder auszuführen, überprüft sein System die digitale Signatur, um sicherzustellen, dass sie mit der von der Zertifizierungsstelle generierten Signatur übereinstimmt. Wenn die Signaturen übereinstimmen, gilt die Software als authentisch und wurde seit der Signatur nicht manipuliert.
Dieses System basiert auf der Public-Key-Kryptografie, auch bekannt als asymmetrische Kryptografie – einer Kryptografiemethode, die zwei verschiedene Schlüssel, einen öffentlichen Schlüssel und einen privaten Schlüssel, zum Ver- und Entschlüsseln von Daten verwendet. Beim Codesignieren wird ein privates-öffentliches Schlüsselpaar zum Signieren von Software und Code verwendet.
Dabei generiert der Softwarehersteller ein privates-öffentliches Schlüsselpaar, wobei der private Schlüssel geheim gehalten und der öffentliche Schlüssel anderen zugänglich gemacht wird. Der Softwareherausgeber verwendet dann seinen privaten Schlüssel, um eine digitale Signatur der Software oder des Codes zu erstellen, den er signieren möchte. Bei dieser digitalen Signatur handelt es sich um einen Hash-Wert, der dadurch generiert wird, dass die Software oder der Code einen mathematischen Algorithmus durchläuft und der resultierende Hash-Wert anschließend mit dem privaten Schlüssel des Herausgebers verschlüsselt wird.
Wenn ein Benutzer die signierte Software oder den signierten Code herunterlädt, verwendet sein System den öffentlichen Schlüssel des Softwareherausgebers, um die digitale Signatur zu entschlüsseln und zu überprüfen, ob sie mit dem Hash-Wert der heruntergeladenen Software oder des heruntergeladenen Codes übereinstimmt. Wenn die digitale Signatur gültig ist, kann der Benutzer sicher sein, dass die Software oder der Code seit der Signatur durch den Softwareherausgeber nicht manipuliert wurde.
Basierend auf diesem einfachen Konzept besteht die vorgeschlagene Abhilfe darin, jede neue Version, Binärdatei und jedes Image direkt mit dem Unternehmensschlüssel oder dem Build-Pipeline-Schlüssel zu signieren und den Benutzer einfach aufzufordern, die Signatur zu überprüfen, wenn er die Software herunterlädt oder aktualisiert.
Natürlich sind die Dinge nicht immer so einfach. Wenn die Angreifer den Build-Server infiltriert haben, ist es bereits sinnlos, den Build dort zu signieren. Wenn die Schlüsselinfrastruktur kompromittiert wurde, ist die ganze Aktion ebenfalls sinnlos.
Aber die Aufforderung an die Benutzer, eine Signatur zu verifizieren, was schnell und einfach automatisch erledigt werden kann, ist ein geringer Preis, der dazu beiträgt, den nächsten Angriff auf die Software-Lieferkette zu verhindern.
Aber Moment, Sie fragen sich vielleicht: Was wäre, wenn tatsächlich eine vorgelagerte Open-Source-Bibliothek die Quelle der Kontamination wäre? In einem solchen Fall ist das Signieren eines Builds wiederum sinnlos, da der kompromittierende Code „eingebaut“ ist.
Hier müssen wir anfangen, über ein Ökosystem des Vertrauens nachzudenken, das auf dem Signieren und Verifizieren dieser Signaturen basiert. Wenn diese Open-Source-Pakete signiert und die Signaturen überprüft würden, wenn sie in den Code des Unternehmens integriert würden, könnte die Wahrscheinlichkeit eines Verstoßes verringert werden.
Wo der Schreiber ins Spiel kommt
Schreiber hat ein Tool namens implementiert Valint dass ermöglicht es Ihnen, unterschreiben und überprüfen Dateien, Ordner und Bilder. Ohne dass komplizierte PKI-Systeme verwaltet werden müssen, implementiert das Tool einen neuartigen Ansatz, bei dem Ihre bereits etablierte verifizierte Identität (wie beispielsweise Ihre Google-, Microsoft-, GitHub- oder AWS-Identität) zum Signieren des gewünschten Artefakts verwendet wird. Sie können dasselbe Tool später verwenden, um zu überprüfen, ob das Artefakt signiert wurde und welche Identität zum Signieren verwendet wurde.
Nehmen wir an, Ihre Build-Pipeline erzeugt als letztes Artefakt ein Container-Image. Gleich nachdem das Image erstellt wurde, sollten Sie es signieren und diese signierte Version in das Repository hochladen, wo Ihre Kunden sie herunterladen können. Sobald das Bild signiert ist, kann es nicht mehr geändert werden – es ist gesperrt. Jeder, der möchte, kann überprüfen, ob es signiert ist und ob die Signaturidentität mit der vom Unternehmen veröffentlichten Identität übereinstimmt.
Dieses Tool ist nur ein Teil der durch die Implementierung bereitgestellten Funktionen Scribe SaaS-Lösung für Ihre Organisation. Mit dem Ziel, sowohl die Sicherheit Ihrer Software-Lieferkette als auch Ihre allgemeine Transparenz zu verbessern, gibt es allen Grund, herauszufinden, was Scribe Ihnen bieten kann.
Diese Inhalte werden Ihnen von Scribe Security zur Verfügung gestellt, einem führenden Anbieter von End-to-End-Sicherheitslösungen für die Software-Lieferkette, der modernste Sicherheit für Code-Artefakte sowie Code-Entwicklungs- und Bereitstellungsprozesse in der gesamten Software-Lieferkette bietet. Weitere Informationen.
Zusammenhängende Artikel
