Voorkom aanvallen op de toeleveringsketen met Build Verifier van Encryption Consulting

Codeondertekening is een cruciaal mechanisme om authenticiteit en vertrouwen te waarborgen en ervoor te zorgen dat software tijdens de distributie niet wordt gecompromitteerd. In de huidige, onderling verbonden wereld, waar software de basis vormt, is de beveiliging van de softwareleveringsketen belangrijker dan ooit. Recente gebeurtenissen, zoals de SolarWinds-aanval, hebben de kwetsbaarheden binnen deze leveringsketen blootgelegd en dienen als een duidelijke herinnering aan het belang van het waarborgen van codeondertekeningspraktijken . Deze blog gaat dieper in op de complexiteit van dergelijke aanvallen, werpt licht op de uitvoering ervan en onderzoekt proactieve beveiligingsmaatregelen om de softwareleveringsketen te versterken.

Wat Build Verifier in het kort voorkomt: een aanval in de stijl van SolarWinds, waarbij kwaadwillende code in de build wordt geïnjecteerd vóór de codeondertekening, zodat het resulterende artefact een geldige, legitieme handtekening bevat. Build Verifier detecteert dit door tijdens het buildproces onafhankelijk de hashes van bestanden opnieuw te berekenen en deze te vergelijken met de hashes die bij het inchecken zijn opgeslagen. Bij elke afwijking, inclusief in configuratiebestanden en afhankelijkheden, mislukt de build automatisch, niet alleen in de code zelf.

Key Takeaways

• SolarWinds slaagde erin omdat de aanvallers de buildserver hadden gecompromitteerd vóór het ondertekenen, niet het ondertekeningsproces zelf; een geldige handtekening op reeds kwaadaardige code is precies de foutmodus waarop Build Verifier zich richt.
• Deze pagina beschrijft een specifieke preventieve maatregel (hashverificatie tijdens de build). Voor de algemene procedure voor incidentafhandeling bij een vermoeden van een inbreuk, zie Versterk de beveiliging van codeondertekening tegen integriteitsomzeilingen..

Wat is een SolarWinds-aanval?

De SolarWinds-aanval was een grootschalige aanval op de toeleveringsketen die gericht was op het SolarWinds Orion-platform, een veelgebruikte software door grote bedrijven en overheidsinstanties voor het beheer van infrastructuur. Door SolarWinds te compromitteren tijdens de softwareontwikkelingsfase, kregen de aanvallers toegang tot de netwerken van de klanten van het platform, die hun uiteindelijke doelwit 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 kwaadaardige code in software-updates op 20 februari 2020. Op 26 maart 2020 werden de gecompromitteerde updates verspreid onder SolarWinds-klanten, waardoor de Sunburst-backdoor op hun netwerken werd geïnstalleerd. De aanvallers kregen via deze backdoor directe toegang. SolarWinds gebruikte codeondertekening, maar de aanvallers voegden de kwaadaardige code tijdens de ontwikkeling in, waardoor de codeondertekening werd omzeild . Sunburst communiceerde met de servers van de aanvallers, vermomd als legitiem verkeer. Vervolgens zetten de aanvallers de malware Teardrop en Raindrop in om de aanval op geselecteerde slachtoffers uit te breiden. De aanval had een aanzienlijke impact op organisaties die afhankelijk waren van SolarWinds Orion.

Laten we elk van deze componenten stap voor stap bespreken:

1. 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.

2. 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.

3. 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.

4. 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.

1. Ongeautoriseerde toegang verkrijgen tot codeondertekeningssleutels

   Deze tactiek houdt in dat de cryptografische sleutels worden bemachtigd die worden gebruikt om softwarecode te ondertekenen. Deze sleutels garanderen gebruikers dat de gedownloade software niet is gemanipuleerd. Door deze sleutels te stelen, kunnen aanvallers hun kwaadaardige code ondertekenen, waardoor deze er authentiek en betrouwbaar uitziet voor gebruikers en beveiligingscontroles.

2. 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.

3. 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.

4. 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:

1. 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.

2. Bouwverifier

   Een extra preventieve maatregel tegen dergelijke aanvallen omvat een rigoureus hashvalidatiesysteem dat naadloos is geïntegreerd in de softwareontwikkelingspipeline. Het proces begint met het berekenen van bestandshashes telkens wanneer code wordt ingecheckt in een specifieke releasebranch. Deze hashes worden veilig opgeslagen in een versleuteld bestand met behulp van CodeSign Secure van Encryption Consulting . Vervolgens, wanneer de buildserver een build start vanuit de aangewezen branch, haalt deze de code op en berekent hashwaarden voor alle bestanden, die vervolgens in een tekstbestand worden opgeslagen. Een Build Verifier-module vergelijkt deze hashwaarden vervolgens met de hashwaarden die veilig zijn versleuteld 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.

Conventionele hashvalidatie versus buildverificatie

	Conventionele hashvalidatie	Bouwverifier
strekking	Alleen broncode	Code, configuratiebestanden en afhankelijkheden
Verificatiemethode	De ondertekeningsserver herbouwt en vergelijkt de hashes onafhankelijk.	De hashes die bij het inchecken worden berekend, worden vergeleken met de hashes die tijdens het bouwproces opnieuw worden berekend.
Falend gedrag	Ondertekening wordt geweigerd vanwege mismatch.	De build wordt als MISLUKT gemarkeerd en de CI/CD-pipeline verstuurt direct meldingen.
Detecteert een inbreuk op de buildserver in de stijl van SolarWinds.	Ja, voor wijzigingen in de broncode.	Ja, inclusief wijzigingen die verborgen zijn in configuratiebestanden of afhankelijkheden die een controle op basis van alleen de code mogelijk over het hoofd ziet.

Veelgestelde Vragen / FAQ

Zou Build Verifier de SolarWinds-aanval specifiek hebben gedetecteerd?

De aanvallers van SolarWinds hebben de buildoutput rechtstreeks op de gecompromitteerde buildserver aangepast vóór de ondertekening. Een hash-mismatch tussen de ingecheckte code en de berekening tijdens het buildproces is precies de afwijking die Build Verifier moet detecteren. Hierdoor mislukt de build en wordt de pipeline op de hoogte gesteld, in plaats van een geldig ondertekend maar gemanipuleerd artefact door te laten.

Vervangt Build Verifier de noodzaak voor HSM-gebaseerde sleutelopslag?

Nee, ze pakken verschillende risico's aan. Sleutelopslag met HSM-ondersteuning voorkomt diefstal van certificaten; Build Verifier voorkomt dat een gecompromitteerde build ooit de ondertekeningsstap met een geldige handtekening bereikt. Beide beveiligingsmaatregelen vullen elkaar aan, ze vervangen elkaar niet.

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.