Eind maart 2023 legden beveiligingsonderzoekers de bedreigingen van een bedreiging bloot complexe software supply chain-aanval over zakelijke communicatiesoftware van 3CX, voornamelijk de desktop-app voor spraak- en videogesprekken van het bedrijf. De onderzoekers waarschuwden dat de app op de een of andere manier door een trojan was gehackt en dat het gebruik ervan de organisatie zou kunnen blootstellen aan een mogelijk exfiltratieplan door een bedreigingsacteur. De aanval kreeg de naam 'Smooth Operator' en er zijn aanwijzingen dat deze al maanden aan de gang is.
Dus wat is er precies gebeurd, hoe brengt het gebruik van deze getrojaniseerde versie u in gevaar, en hoe had dit voorkomen kunnen worden door gebruik te maken van softwareondertekening en -verificatie?
Allereerst: wat is 3CX?
3CX is een op software gebaseerde, open standaard IP PBX (Private Branch Exchange) die een traditionele hardware PBX vervangt. Het is ontworpen om bedrijven in staat te stellen te bellen en gebeld te worden met behulp van VoIP-technologie (Voice over Internet Protocol), waarmee spraakcommunicatie via internet wordt verzonden. 3CX bevat ook geavanceerde functies zoals videoconferenties, aanwezigheid, instant messaging en meer, en kan op locatie of in de cloud worden geïmplementeerd. Windows, macOS en Linux zijn slechts enkele van de populaire besturingssystemen waarop de app beschikbaar is. Daarnaast is de client dankzij een Chrome-extensie toegankelijk via browsers en heeft de client zelfs een PWA-versie en is hij beschikbaar als mobiele applicatie voor Android- en iOS-apparaten.
U kunt een idee krijgen van de potentiële gevolgen van een software-aanval op de toeleveringsketen van de 3CX-website, waarop 600,000 bedrijven hun app gebruiken en meer dan 12 miljoen dagelijkse gebruikers hebben.
Een voorproefje van de aanval: wat u moet weten
Dit is een beetje ingewikkeld, dus we zullen het in stappen opsplitsen:
- Je downloadt een een getrojaniseerde versie van de desktop-app of als u deze al hebt geïnstalleerd, kunt u deze eenvoudig bijwerken met een getrojaniseerde versie.
- Het uitvoerbare bestand 3CXDesktopApp.exe laadt een kwaadaardige dynamische linkbibliotheek (DLL) met de naam ffmpeg.dll.
- De ffmpeg.dll wordt gebruikt om een gecodeerde payload uit d3dcompiler_47.dll te extraheren en uit te voeren.
- De malware downloadt vervolgens onschuldig ogende pictogrambestanden die worden gehost op GitHub en die met Base64 gecodeerde tekenreeksen bevatten die aan het einde van de afbeeldingen zijn toegevoegd.
- Die gecodeerde gegevens worden vervolgens gedecodeerd en gebruikt om een andere fase te downloaden, die de gecodeerde C&C-server bevat waarmee de achterdeur verbinding maakt om de mogelijke uiteindelijke lading op te halen.
- In de laatste fase wordt de info-stealer-functionaliteit in de praktijk gebracht, inclusief het verzamelen van systeemgegevens en browsergegevens van Chrome-, Edge-, Brave- en Firefox-browsers. Dit kan het opvragen van de browsegeschiedenis en informatie uit de tabel Plaatsen omvatten, maar ook mogelijk het opvragen van de tabel Geschiedenis.
Aanvankelijk 3CX bagatelliseerde de aanval, maar gaf later toe dat het een reële bedreiging was en stelde voor de app te verwijderen en opnieuw te installeren met hun specifieke instructies, en in de tussentijd de PWA-versie te gebruiken totdat het bedrijf erin slaagt het incident te ontwarren en te verzachten.
Een andere zeer belangrijke factor om in gedachten te houden is dat het compromis een code-ondertekeningscertificaat omvat dat wordt gebruikt om de getrojaniseerde binaire bestanden te ondertekenen. Nou ja, niet precies. Het maakt feitelijk gebruik van een bekende kwetsbaarheid genaamd CVE-2013-3900 (oorspronkelijk gepubliceerd in 2013 maar bijgewerkt in 2022 en deze week opnieuw) om het te maken verschijnen legitiem ondertekend.
Déjà Vu: dit is al eerder gebeurd
Als dit verhaal van a De getrojaniseerde 3CX-versie klinkt bekend omdat het al eerder is gebeurd.
In dit geval is het uHet is niet duidelijk of een open-source upstream-bibliotheek die het bedrijf gebruikt, geïnfecteerd is geraakt of dat een daadwerkelijke aanval de ontwikkelomgeving van het bedrijf heeft geschonden.
In andere bekende aanvallen, van 'Kingslayer' (2016) tot 'CCleaner' (2017), 'VestaCP' (2018), 'WIZVERA VeraPort' (2020), en helemaal tot aan 'SolarWinds' (2020), is het een Een gangbare praktijk van bedreigingsactoren om te proberen de servers van een bedrijf, de gebouwde omgeving of het daadwerkelijke downloadbare uitvoerbare bestand in gevaar te brengen. Het vermommen van iets slechts en gevaarlijks als iets dat u kunt vertrouwen, is immers een geweldige manier om ervoor te zorgen dat mensen uw lading vertrouwen en downloaden.
Dat maakt deel uit van de definitie van a aanval op de software supply chain – de aanvallers hebben de softwaretoeleveringsketen gecompromitteerd om kwaadaardige software onder een groot aantal slachtoffers te verspreiden. In elk van deze bekende gevallen slaagden de aanvallers erin kwaadaardige code in legitieme softwarepakketten te injecteren, die vervolgens onder gebruikers werden verspreid. De aanvallers konden dit vaak doen door een vertrouwde softwareleverancier of -provider in gevaar te brengen, zoals een software-updateserver of een certificaat voor het ondertekenen van code.
Door nietsvermoedende klanten een aangepaste versie van een legitieme applicatie te laten downloaden, kunnen de aanvallers vrijwel alles erin verbergen.
En hier is het grootste probleem: 'nietsvermoedend'. Het uitvoerbare bestand, het binaire bestand of de afbeelding is immers afkomstig van het creërende bedrijf, blijkbaar door het bedrijf goedgekeurd, en bevat zelfs een ondertekend certificaat. Wat kan een klant nog meer doen? Moeten ze het bedrijf bellen om elke update te verifiëren? Scan de code (indien beschikbaar) voor het bestaan van achterdeurtjes? Dat is absurd en onrealistisch. Maar daar is iets dat gedaan kan worden.
Hoe kunt u een vertrouwenslaag toevoegen naast een certificaat?
Het voorgestelde model is vrij eenvoudig en is gebaseerd op hetzelfde idee als dat van code-signingcertificaten. Een code-ondertekeningscertificaat is een digitaal certificaat uitgegeven door een derde partij dat wordt gebruikt om software of code digitaal te ondertekenen. Wanneer software is ondertekend met een code-ondertekeningscertificaat, kunnen gebruikers de authenticiteit en integriteit van de software verifiëren voordat deze wordt geïnstalleerd of uitgevoerd.
Ondertekeningscertificaten worden uitgegeven door een vertrouwde derde partij certificeringsinstanties (CA's), die de identiteit van de software-uitgever en de integriteit van de softwarecode verifiëren. De certificeringsinstantie gebruikt cryptografische algoritmen om een digitale handtekening van de software te creëren, die vervolgens in de ondertekende code wordt opgenomen. Wanneer een gebruiker de software probeert te installeren of uit te voeren, controleert zijn systeem de digitale handtekening om er zeker van te zijn dat deze overeenkomt met de handtekening die door de certificeringsinstantie is gegenereerd. Als de handtekeningen overeenkomen, wordt de software als authentiek beschouwd en is er sinds de ondertekening niet mee geknoeid.
Dit systeem is gebaseerd op cryptografie met publieke sleutels, ook wel asymmetrische cryptografie genoemd – een cryptografiemethode die twee verschillende sleutels gebruikt, een publieke sleutel en een privésleutel, om gegevens te coderen en te decoderen. In de context van code-ondertekening wordt een privaat-publiek sleutelpaar gebruikt om software en code te ondertekenen.
In dit proces genereert de software-uitgever een privaat-publiek sleutelpaar, waarbij de private sleutel geheim wordt gehouden en de publieke sleutel beschikbaar wordt gesteld aan anderen. De software-uitgever gebruikt vervolgens zijn privésleutel om een digitale handtekening te maken van de software of code die hij wil ondertekenen. Deze digitale handtekening is een hashwaarde die wordt gegenereerd door de software of code door een wiskundig algoritme te laten lopen en vervolgens de resulterende hashwaarde te coderen met de privésleutel van de uitgever.
Wanneer een gebruiker de ondertekende software of code downloadt, gebruikt zijn systeem de openbare sleutel van de software-uitgever om de digitale handtekening te decoderen en te verifiëren dat deze overeenkomt met de hashwaarde van de gedownloade software of code. Als de digitale handtekening geldig is, kan de gebruiker erop vertrouwen dat er niet met de software of code is geknoeid sinds deze door de software-uitgever is ondertekend.
Gebaseerd op dit eenvoudige concept is de voorgestelde oplossing om elke nieuwe release, binair bestand en image rechtstreeks te ondertekenen met de bedrijfssleutel of de build-pijplijnsleutel en de gebruiker gewoon te vragen de handtekening te verifiëren wanneer hij de software downloadt of updatet.
Natuurlijk zijn de zaken niet altijd zo eenvoudig. Als de slechte actoren de buildserver hebben geïnfiltreerd, is het ondertekenen van de build daar al zinloos. Als de belangrijkste infrastructuur in gevaar is gebracht, is de hele exercitie eveneens zinloos.
Maar gebruikers vragen een handtekening te verifiëren, iets dat snel en gemakkelijk automatisch kan worden gedaan, is een kleine prijs die moet worden betaald om de volgende aanval op de softwaretoevoerketen te helpen voorkomen.
Maar wacht, zou je kunnen zeggen, wat als het eigenlijk een open-source bibliotheek upstream is die de bron van de besmetting is? In zo'n geval is het ondertekenen van een build zinloos, omdat de compromitterende code 'ingebouwd' is.
Dit is waar we moeten beginnen met het overwegen van een ecosysteem van vertrouwen, gebaseerd op het ondertekenen en verifiëren van deze handtekeningen. Als deze open-sourcepakketten werden ondertekend en de handtekeningen werden geverifieerd toen ze in de bedrijfscode werden opgenomen, zou dit de kans op een inbreuk kunnen verkleinen.
Waar de schrijver binnenkomt
Schriftgeleerde heeft een tool geïmplementeerd genaamd Valint waarmee u ondertekenen en verifiëren bestanden, mappen en afbeeldingen. Zonder de noodzaak om ingewikkelde PKI-systemen te onderhouden, implementeert de tool een nieuwe aanpak waarbij uw reeds gevestigde geverifieerde identiteit (zoals bijvoorbeeld uw Google-, Microsoft-, GitHub- of AWS-identiteit) wordt gebruikt om het gewenste artefact te ondertekenen. U kunt later hetzelfde hulpmiddel gebruiken om te verifiëren dat het artefact is ondertekend en wat de identiteit is die is gebruikt om het te ondertekenen.
Stel dat uw build-pijplijn een containerinstallatiekopie produceert als uiteindelijk artefact. Direct nadat de afbeelding is gemaakt, moet u deze ondertekenen en de ondertekende versie uploaden naar de repository waar uw klanten deze kunnen downloaden. Eenmaal ondertekend kan de afbeelding niet meer worden gewijzigd: deze is vergrendeld. Iedereen die dat wil, kan controleren of het ondertekend is en of de handtekeningidentiteit overeenkomt met wat het bedrijf heeft gepubliceerd.
Deze tool is slechts een deel van de mogelijkheden die worden geboden door de implementatie van de Scribe SaaS-oplossing voor uw organisatie. Met als doel zowel de beveiliging van uw softwaretoeleveringsketen als uw algehele transparantie te verbeteren, is er alle reden om te gaan kijken wat Scribe u te bieden heeft.
Deze inhoud wordt u aangeboden door Scribe Security, een toonaangevende aanbieder van end-to-end software supply chain-beveiligingsoplossingen die state-of-the-art beveiliging levert voor codeartefacten en codeontwikkelings- en leveringsprocessen in de software supply chain. Meer informatie.
Gerelateerde berichten
