Code ondertekening is een cruciaal mechanisme om authenticiteit en vertrouwen te waarborgen en ervoor te zorgen dat software niet wordt gecompromitteerd tijdens de distributie. In de huidige, onderling verbonden wereld, waar software de basis vormt, is de beveiliging van de softwaretoeleveringsketen belangrijker dan ooit. Recente gebeurtenissen, zoals de SolarWinds-aanval, hebben de kwetsbaarheden die binnen deze toeleveringsketen kunnen worden uitgebuit, aan het licht gebracht en vormen een duidelijke herinnering aan het belang van beveiliging. codeondertekeningspraktijkenIn deze blog duiken we in de complexiteit van dergelijke aanvallen, belichten we de uitvoering ervan en onderzoeken we proactieve beveiligingsbenaderingen om de softwaretoeleveringsketen te versterken.
Wat is een SolarWinds-aanval?
De SolarWinds-aanval was een enorme supply chain-aanval die gericht was op het SolarWinds Orion-platform, een veelgebruikte software voor infrastructuurbeheer door grote bedrijven en overheidsinstellingen. Door SolarWinds tijdens de softwareontwikkelingsfase te hacken, kregen de aanvallers toegang tot de netwerken van de klanten van het platform, die hun uiteindelijke doelwitten waren.
Bij een supply chain-aanval wordt de schadelijke code tijdens het creatie- of productieproces in het product geïnjecteerd, waardoor hackers de eindgebruiker kunnen uitbuiten zodra deze het geïnfecteerde product ontvangt. In dit geval infiltreerden de aanvallers de software-updates met schadelijke code voordat de updates naar klanten werden gedistribueerd als onderdeel van routinematig onderhoud.
Het voordeel van deze aanvalsstrategie is dat het een verborgen achterdeur creëert naar het netwerk van elke eindgebruiker die het gecompromitteerde product gebruikt. Met het SolarWinds Orion-platform hadden de aanvallers een nog krachtiger toegangspunt, omdat het de netwerken van de gebruiker bestrijkt en zo aanzienlijke controle biedt.
Eenmaal binnen konden de hackers extra malware inzetten om hun mogelijkheden uit te breiden, de aanval te escaleren en onopgemerkt te blijven. Deze aanval had een verstrekkende impact en trof talloze organisaties die voor hun bedrijfsvoering afhankelijk waren van SolarWinds Orion, waardoor gevoelige gegevens in gevaar kwamen.
Hoe werd de SolarWinds-aanval uitgevoerd?
De SolarWinds-aanval begon met het invoegen van schadelijke code in software-updates op 20 februari 2020. Op 26 maart 2020 werden gecompromitteerde updates gedistribueerd naar SolarWinds-klanten, waardoor de Sunburst-backdoor op hun netwerken werd geïnstalleerd. De aanvallers kregen directe toegang via deze backdoor. SolarWinds gebruikte codeondertekening, maar de aanvallers voegden de schadelijke code toe tijdens de ontwikkeling, waardoor ze de beveiliging omzeilden. code ondertekeningSunburst communiceerde met de servers van de aanvallers, vermomd als legitiem verkeer. Vervolgens gebruikten de aanvallers Teardrop- en Raindrop-malware om de aanval op geselecteerde slachtoffers uit te breiden. De aanval had aanzienlijke gevolgen voor organisaties die afhankelijk waren van SolarWinds Orion.
Laten we elk van deze componenten stap voor stap bespreken:
-
Sunspot-malware
Sunspot, geïmplementeerd in september 2019, was de eerste malware die werd gebruikt bij de SolarWinds-aanval. Het enige doel was om heimelijk een kwaadaardige backdoor in de Orion-broncode van SolarWinds te plaatsen, die onopgemerkt op de buildserver opereerde. Zodra Sunspot de buildcommando's van Orion detecteerde, verving het de legitieme code stilletjes door de gecompromitteerde versie.
-
Sunburst Backdoor-malware
Sunburst, de belangrijkste backdoor-malware, bevond zich in het DLL-bestand "SolarWinds.Orion.Core.BusinessLayer.dll". De functie ervan was om via HTTP verbinding te maken met de servers van de aanvallers. Het was verborgen in een trojanversie van een Windows Installer-patchbestand, dat naast legitieme updatebestanden bestond. Sunburst ging na de installatie twee weken in slaapstand om detectie te voorkomen en activeerde vervolgens de verbinding met het domein van de aanvallers. Het vermomde zijn communicatie als SolarWinds API-verkeer en registreerde gevoelige netwerkgegevens van het slachtoffer.
-
Het Solorigate DLL-bestand
De aanvallers integreerden de code van Sunburst in een DLL-bestand en noemden het "OrionImprovementBusinessLayer" om het minder opvallend te maken. Deze klasse bevatte de volledige backdoorfunctionaliteit, ontworpen om lichtgewicht en onopvallend te zijn. Het werd in de methode "RefreshInternal" geplaatst om regelmatige aanroep te garanderen zonder de normale werking te verstoren.
-
Traan en regendruppel
Na de eerste verkenning met Sunburst, implementeerden de aanvallers aanvullende malware, Teardrop en Raindrop, gericht op specifieke slachtoffers die geschikt werden geacht voor escalatie.
De SolarWinds-aanvallers voerden een nauwgezet plan uit om de buildserver te compromitteren vóór de codeondertekeningsfase en de schadelijke code te injecteren. Hun infiltratie van de buildserver gaf hen een strategische basis om de software-updateprocedure te manipuleren en de introductie van schadelijke code vóór de kritieke codeondertekeningsstap te garanderen. Dit stelde de aanvallers in staat onopgemerkt te blijven, omdat de gecompromitteerde code de handtekening van een geldig SolarWinds-certificaat droeg, wat een misleidende schijn van authenticiteit creëerde.
Wat zijn de methoden om een dergelijke aanval succesvol uit te voeren?
Laten we eens kijken naar de verschillende strategieën die gebruikt kunnen worden om soortgelijke aanvallen uit te voeren en de softwarevoorzieningsketen in gevaar te brengen.
-
Ongeautoriseerde toegang verkrijgen tot codeondertekeningssleutels
Deze tactiek houdt in dat je de cryptografische sleutels Wordt gebruikt om softwarecode te ondertekenen. Deze sleutels garanderen gebruikers dat er niet met de gedownloade software is geknoeid. Door deze sleutels te stelen, kunnen aanvallers hun schadelijke code ondertekenen, waardoor deze authentiek en betrouwbaar lijkt voor gebruikers en beveiligingscontroles.
-
Het doorbreken van de buildserver, zoals waargenomen in het SolarWinds-incident
De buildserver was een cruciaal doelwit in de SolarWinds-aanval. Aanvallers infiltreerden deze server, die verantwoordelijk was voor het compileren en verpakken van software-updates. Door de buildserver te hacken, kregen ze controle over het software-updateproces, waardoor ze kwaadaardige code konden injecteren vóór de codeondertekeningsfase. Deze manipulatie hielp hen om kwaadaardige updates te verspreiden naar nietsvermoedende gebruikers.
-
Malware rechtstreeks in de broncode-opslagplaats injecteren (moeilijk omdat het permanente sporen achterlaat)
Het rechtstreeks injecteren van malware in een broncoderepository is een uitdaging, omdat het vaak traceerbare sporen achterlaat. Deze repository is waar ontwikkelaars de broncode van softwareprojecten opslaan en beheren. Ongeautoriseerde wijzigingen, waaronder het invoegen van malware, kunnen mogelijk worden geïdentificeerd en herleid tot de aanvaller. Hierdoor is deze methode riskanter en gevoeliger voor detectie.
-
Het werkstation van de ontwikkelaar als doelwit voor compromissen
Een andere aanpak is het compromitteren van de werkstations van ontwikkelaars. Ontwikkelaars gebruiken deze machines om code te schrijven, testen en ontwikkelen. Als een aanvaller toegang krijgt tot de werkstations van ontwikkelaars, kunnen ze de code manipuleren voordat deze in de repository wordt opgeslagen. Deze tactiek is moeilijk te detecteren, tenzij er robuuste endpointbeveiligingsmaatregelen zijn.
Strategieën om zich tegen dergelijke aanvallen te beschermen
Om soortgelijke aanvallen te voorkomen, kunt u de volgende maatregelen nemen:
-
Hash-validatie
Hashvalidatie is een cruciale verdediging tegen aanvallen op de toeleveringsketen, zoals de SolarWinds-inbreuk. Het fungeert als een strenge poortwachter in het softwareontwikkelingsproces en zorgt ervoor dat de te ondertekenen code overeenkomt met de code die veilig is opgeslagen in de broncoderepository. Deze beveiligingsmaatregel houdt in dat de buildserver een codehash genereert, die vervolgens wordt gecontroleerd door de ondertekeningsserver.
De ondertekeningsserver verifieert onafhankelijk de integriteit van de code door een deterministische build te starten binnen de broncoderepository en hashes te vergelijken. Alleen wanneer deze hashes overeenkomen, autoriseert de ondertekeningsserver de codeondertekening, wat een robuuste beveiligingslaag biedt die beschermt tegen ongeautoriseerde codewijzigingen.
-
Bouwverifier
Een extra preventieve maatregel tegen dergelijke aanvallen is een rigoureus hashvalidatiesysteem dat naadloos is geïntegreerd in de softwareontwikkelingspijplijn. Het proces begint met het berekenen van bestandshashes wanneer code wordt ingecheckt in een specifieke releasebranch. Deze hashes worden veilig opgeslagen in een gecodeerd bestand met behulp van CodeSign Secure van Encryption ConsultingWanneer de buildserver vervolgens een build start vanuit de aangewezen branch, haalt deze de code op en berekent hashwaarden voor alle bestanden. Deze worden opgeslagen in een tekstbestand. Een Build Verifier-module vergelijkt deze hashwaarden vervolgens met de veilig versleutelde hashwaarden in de repository.
De build verloopt succesvol als er een match wordt gevonden voor alle hashwaarden. Eventuele verschillen in hashwaarden zorgen er echter voor dat de Build Verifier de build als mislukt markeert, waardoor het proces onmiddellijk wordt stopgezet en meldingen via de CI/CD-pijplijn worden geactiveerd. Deze robuuste aanpak garandeert een strenge verificatie van de code-integriteit in meerdere fasen, wat de beveiliging van de softwaretoeleveringsketen aanzienlijk verbetert.
Hoe kan Build Verifier van Encryption Consulting dit voorkomen?
De Build Verifier van Encryption Consulting speelt een cruciale rol bij het waarborgen van de integriteit van het buildproces. Het systeem identificeert deze wijziging direct en categoriseert de betreffende build als een FAILURE. Vervolgens worden er meldingen gegenereerd en verzonden naar de relevante partijen om onmiddellijk corrigerende maatregelen te nemen. Deze functionaliteit onderstreept de effectiviteit van de Build Verifier van Encryption Consulting bij het waarborgen van de veiligheid en betrouwbaarheid van de softwareontwikkelingspijplijn.
Hoewel de conventionele methode van hashvalidatie ongetwijfeld een waardevol verdedigingsmechanisme is tegen aanvallen op de toeleveringsketen, tilt Build Verifier van Encryption Consulting softwarebeveiliging naar een hoger niveau. Beide benaderingen delen het kernprincipe van het waarborgen van code-integriteit door hashes te matchen. Het belangrijkste verschil ligt echter in de reikwijdte van hun waakzaamheid. De conventionele benadering richt zich primair op de code en controleert of deze overeenkomt met de versie van de repository.
Build Verifier van Encryption Consulting biedt een meer omvattende verdedigingsstrategie. Het systeem analyseert de code en houdt daarbij ook cruciale configuratiebestanden en afhankelijkheden nauwlettend in de gaten. Deze bredere scope stelt het in staat om subtiele wijzigingen te detecteren die bij de traditionele hashvalidatie wellicht onopgemerkt blijven.
Conclusie
Gezien de SolarWinds-aanval, die kwetsbaarheden in de softwaretoeleveringsketen blootlegde, is het cruciaal om proactieve beveiligingsmaatregelen te overwegen. Aanvallers plegen dergelijke inbreuken door buildservers zorgvuldig te compromitteren vóór het codeondertekeningsproces, schadelijke code in software-updates te introduceren en detectie te omzeilen door middel van geldige handtekeningen.
Kortom, het beveiligen van de softwaretoeleveringsketen vereist innovatieve benaderingen zoals Build Verifier van Encryption Consulting, waarmee vertrouwen en zekerheid in de digitale wereld worden gewaarborgd. Naarmate cyberdreigingen evolueren, blijft het cruciaal om een stap voor te blijven. Build Verifier getuigt van proactieve beveiliging in een complex cybersecuritylandschap.
