Een gedetailleerde handleiding voor misbruik van codeondertekening

Introductie

Het bouwen van een veilige IT-infrastructuur vereist het implementeren van sterke beveiligingsmaatregelen. Enkele voorbeelden hiervan zijn de implementatie van een Public Key Infrastructuredoor monitoringproducten in uw omgeving te installeren of door gebruik te maken van legitieme CodeondertekeningsoplossingenCode Signing is het proces waarbij software wordt ondertekend ter authenticatie voor gebruikers.

Codeondertekening gebruiken certificatenEen softwareontwerper ondertekent zijn software met een certificaat dat zijn publieke sleutel bevat. De ontvanger van de software kan vervolgens verifiëren dat de publieke sleutel deel uitmaakt van een sleutelpaar met de privésleutel van de ontwerper, waardoor de software wordt geauthenticeerd. Code Signing bevestigt ook de originaliteit van digitale informatie, zoals softwarecode, en stelt de legitimiteit van de auteur vast.

Code Signing speelt een belangrijke rol omdat het legitieme software kan onderscheiden van malware of malafide code. Technisch gezien creëert Code Signing een hash van de code en versleutelt deze met een privésleutel, waaraan de handtekening wordt toegevoegd. Tijdens de uitvoering wordt deze handtekening gevalideerd en als de hash overeenkomt, geeft dit de zekerheid dat de code niet is gewijzigd. Het biedt ook de zekerheid dat de code afkomstig is van de legitieme auteur die beweert de auteur te zijn.

Hoewel codeondertekening de beveiliging van code verbetert, kan het problemen opleveren en kwetsbaar zijn voor aanvallen of misbruik als het niet correct wordt geïmplementeerd. De recente Solar Winds-aanval is een voorbeeld waarbij het codeondertekeningsproces werd gecompromitteerd en valse code als legitieme software in systemen en eindpunten werd geïmplementeerd. Het doel van een aanvaller is om de weg van de minste weerstand te vinden.

Er zijn veel sectoren, zoals de game-industrie, die hun code veel sneller willen uitbrengen of implementeren. Het omzeilen van processen of het niet volgen van best practices voor beveiliging komt bijvoorbeeld veel voor, waardoor organisaties het slachtoffer worden van misbruik van codeondertekening.

Hoe wordt codeondertekening gebruikt?

Code Signing wordt voor verschillende doeleinden gebruikt. De meest voor de hand liggende toepassing is het ondertekenen van softwarecode met de privésleutel van de ontwikkelaar. Zoals eerder vermeld, wordt de software ondertekend om te garanderen dat de code geen schadelijke code bevat, om de ontvanger van de gegevens te laten weten dat de ontwikkelaar is wie hij of zij zegt te zijn, en om vertrouwen op te bouwen tussen de ontwikkelaar en de eindgebruiker.

Met ondertekende code kunnen gebruikers erop vertrouwen dat de code geen kwaadaardige bedoelingen op de achtergrond bevat, aangezien de codeondertekenaar hiervoor verantwoordelijk zou worden gehouden. Andere gebieden waar codeondertekening wordt gebruikt, zijn bedrijfsapplicaties, IoT-apparaten (Internet of Things) en Development en IT Operations (Dev Ops).

Bij bedrijfsapplicaties worden alle interne code, scripts, pakketten, enz. ondertekend via code signing. De scripts en pakketten worden om dezelfde redenen ondertekend als de code: aanvallers kunnen er schadelijke payloads in verbergen. IoT-apparaten gebruiken code signing voor authenticatie- en validatiedoeleinden. Updates voor zowel firmware als software worden door ontwikkelaars ondertekend, evenals berichten tussen gebruikers op IoT-apparaten.

Met Public Key Infrastructures (PKI's) in gebruik, authenticeren codeondertekeningscertificaten gebruikers binnen het netwerk van een organisatie. Door hun certificaat te 'ondertekenen' met hun privésleutel, met behulp van de publieke sleutel, kan de identiteit van de gebruikers worden gevalideerd. Met Dev Ops zijn integratie en code-implementatie continu gaande. De code wordt in meerdere instanties geïmplementeerd op containers en cloudsystemen, wat betekent dat deze containerimages tijdens meerdere fasen van de levenscyclus van de code moeten worden ondertekend.

Misbruik van codeondertekening

Een veelvoorkomende reden voor misbruik van code signing is om slachtoffers te voorzien van code die er legitiem uitziet, maar schadelijke software bevat die gevoelige informatie van gebruikers kan stelen of hun systemen volledig kan vernietigen. Aanvallers kunnen ook code signing-certificaten stelen van legitieme ontwikkelaars, waardoor ze code kunnen vrijgeven onder de naam van een vertrouwde maker, waardoor ze malware kunnen verspreiden naar meer slachtoffers. Misbruik van code signing kan op verschillende manieren plaatsvinden.

• Sleuteldiefstal

  Wanneer digitale certificaten of sleutels slecht worden opgeslagen en beheerd, opent dit de deur voor kwaadwillenden, die de privésleutels van vertrouwde gebruikers kunnen stelen. Met deze sleutels kunnen ze code ondertekenen als een andere identiteit, en kunnen ze certificaten laten uitgeven onder de naam van de vertrouwde identiteit en dat certificaat binnen het netwerk misbruiken.

  Een klein softwareontwikkelingsbedrijf bewaart bijvoorbeeld zijn privésleutel op een onbeveiligde server. Een aanvaller kan de sleutel stelen door toegang te krijgen tot de server met behulp van een phishingaanval die gericht is op de beheerder. Door gebruik te maken van Hardware-beveiligingsmodules (HSM's) Sleutels kunnen volledig veilig worden bewaard voor aanvallers, omdat ze fysiek toegang tot de HSM moeten hebben met de juiste inloggegevens om de daarin opgeslagen sleutels te stelen.

• Codeerfouten

  Een andere, minder bekende fout die misbruik van codeondertekening kan veroorzaken, is wanneer codeondertekende software kwetsbaarheden bevat. Als er kwetsbaarheden in software aanwezig zijn en kwaadwillenden deze ontdekken voordat ze worden gepatcht, dan is hun codeondertekening voor niets geweest. Hoewel de code is ondertekend, kunnen aanvallers deze kwetsbaarheden misbruiken om malware op de systemen van slachtoffers te installeren. Code moet grondig worden getest vóór implementatie om er zeker van te zijn dat er geen kwetsbaarheden aanwezig zijn.

  Een ontwikkelaar voert bijvoorbeeld een software-upgrade uit om een ​​bug met hoge prioriteit te verhelpen. De code wordt ondertekend en zonder grondige beveiligingstests naar klanten gepusht. Deze code bevat echter achterpoortjes die toegang geven tot gevoelige klantgegevens, wat veel gevolgen kan hebben voor de organisatie en haar klanten.

• Systeemcompromis

  Als een systeem gecompromitteerd is en er software op dat systeem wordt ondertekend, kan de code vóór de daadwerkelijke ondertekening worden gewijzigd. Hierdoor kunnen malware-payloads verborgen worden in code die legitiem is ondertekend, zonder medeweten van de ontwikkelaar. Eenmaal binnen het systeem kunnen aanvallers een klein stukje schadelijke code in de software injecteren voordat de build is ondertekend. Codeondertekening werd op deze manier misbruikt tijdens de recente SolarWinds-aanval. Door ervoor te zorgen dat uw systemen up-to-date zijn met alle beveiligingspatches, kunt u de veiligheid van uw online omgeving waarborgen.

• Gebruik van ingetrokken/verlopen certificaten

  Wanneer een sleutel of verlopen certificaat in gevaar is, en de geldigheid van dat certificaat niet wordt gecontroleerd door een Certificate Authority (CA), dan kan dat certificaat worden gebruikt om codeondertekening van schadelijke software toe te staan.

  Certificaten die verlopen of ingetrokken zijn, moeten in de Certificaatintrekkingslijst (CRL) zodat CA's kunnen vaststellen dat het certificaat niet meer gebruikt mag worden totdat het vervangen of vernieuwd is.

Bekende misbruiken bij codeondertekening

Door te leren van eerdere misbruiken met code signing, kunnen we gegevens in de toekomst beschermen. Er hebben zich in het verleden een aantal opvallende gevallen van code signing voorgedaan, maar vandaag richten we ons op drie van de meest opvallende, te beginnen met SolarWinds. In 2020 ontdekte de organisatie SolarWinds dat haar kernsystemen waren gecompromitteerd. Met behulp van een supply chain-aanval wisten aanvallers in september 2019 toegang te krijgen tot een Microsoft365-account van SolarWinds.

Hierdoor kregen de aanvallers toegang tot de code van SolarWinds en andere systemen, waardoor ze codeondertekening konden misbruiken. Door code te bewerken voordat deze werd ondertekend, konden deze aanvallers een type malware implementeren, een zogenaamde Remote Access Trojan (RAT), waarmee ze op afstand toegang kregen tot de computers van hun slachtoffers.

Deze RAT zat verborgen in de updates van Orion, een netwerkbewakingssoftware van SolarWinds. Dit leidde tot een campagne die een command-and-control-infrastructuur creëerde op de apparaten van de slachtoffers. Overheidsfunctionarissen, particuliere organisaties en veel Amerikaanse federale overheidsinstanties werden getroffen door Solar Winds.

Een andere aanval die misbruik maakte van codeondertekening was de D-Link-aanval. Een leverancier van netwerkapparatuur, D-Link genaamd, publiceerde per ongeluk zijn privé-codeondertekeningssleutels bij het publiceren van de broncode voor een firmware-update. In dit geval konden aanvallers deze sleutels gebruiken om zelfgeschreven code te kopiëren, maar ontvangers ervan overtuigen dat ze vertrouwde code van D-Link ontvingen.

Het belang van het beschermen van privé-codeondertekeningssleutels kan niet genoeg worden benadrukt, aangezien diefstal van uw digitale identiteit kan leiden tot verlies van gevoelige gegevens, rechtszaken en meer. Bij de D-Link-aanval was slechts één van de vier gelekte ondertekeningssleutels geldig, maar er is slechts één geldig certificaat nodig om deze te misbruiken.

Een laatste misbruik van code signing waar we het over zullen hebben, is Shadow Hammer. In 2019 werd het code signing-proces van een grote computerfabrikant, ASUS, gehackt. Met behulp van de live-updatefunctie van ASUS' software lanceerden de hackers malware om achterdeurtjes te creëren in de computersystemen van duizenden gebruikers.

Omdat de malware door ASUS was ondertekend, werkte de live updatetool de systemen bij, waardoor aanvallers gevoelige gegevens van de slachtoffers konden stelen. Door systemen te beschermen door software bij te werken en uw andere systemen veilig te houden, voorkomt u dat uw codeondertekeningsproces wordt overgenomen.

Beveiliging van codeondertekeningscertificaten

Er zijn een aantal verschillende best practices voor codeondertekening die u kunt volgen om ervoor te zorgen dat uw codeondertekeningsproces een veilige omgeving biedt om in te werken. Nationaal Instituut voor Wetenschap en Technologie (NIST) publiceert een aantal aanbevelingen over best practices voor certificaten en codeondertekening die gebruikers kunnen bekijken. Sommige zijn voor de hand liggender dan andere, maar we zullen ze toch allemaal doornemen.

1. Het beveiligen van privésleutels op HSM's

   Een van de zwakke punten van veel organisaties is het gebrek aan beveiliging rondom hun privésleutels. Of ze nu in de cloud of on-premises zijn, Hardware Security Modules kunnen uw privésleutels volledig beschermen tegen aanvallers. Een Hardware Security Module is een gespecialiseerd, zeer betrouwbaar fysiek apparaat dat alle belangrijke cryptografische bewerkingen uitvoert, waaronder encryptie, decryptie, authenticatie, sleutelbeheer en sleuteluitwisseling.

   HSM's zijn gespecialiseerde beveiligingsapparaten, met als enig doel cryptografische materialen te verbergen en te beschermen. Ze beschikken over een robuust besturingssysteem en beperkte netwerktoegang, beschermd via een firewall. HSM's zijn bovendien fraudebestendig en fraudebestendig. Omdat een on-premises HSM fysiek toegankelijk moet zijn om sleutels te stelen, worden ze beschouwd als een van de beste manieren om te voorkomen dat ongewenste gebruikers toegang krijgen tot cryptografische privésleutels.

2. Controle over het codeondertekeningsproces

   Alleen al aan de hand van twee van onze drie praktijkvoorbeelden van misbruik van code signing, kunt u zien dat het beheersen van het code signing-proces van uw organisatie essentieel is voor het volgen van best practices voor code signing. Een onderdeel van het beveiligen van het code signing-proces is het gebruik van authentieke en veilige code signing-oplossingen, mocht u voor deze optie kiezen.

   Codeondertekeningsoplossingen bieden alle infrastructuur voor het ondertekenen van code en andere documenten, terwijl u zich bezighoudt met de beveiliging van het systeem. Naast veilige codeondertekeningsoplossingen zijn het beheren van wie toegang heeft tot privésleutels, het valideren van gebruikersidentiteiten en het gebruik van tweefactorauthenticatie op codeondertekeningsservices slechts enkele andere manieren om uw codeondertekeningsproces te beheren.

3. Codevalidatie

   Voordat u code ondertekent, moeten applicaties grondig worden gecontroleerd op kwetsbaarheden of malware. Daarnaast moeten verouderde functieaanroepen uit de code worden verwijderd. Door code dubbel en driemaal te controleren op kwetsbaarheden of beveiligingslekken, voorkomt u dat uw organisatie onveilige code publiceert die door kwaadwillenden kan worden misbruikt om gevoelige gegevens van uw gebruikers te stelen.

4. Gewijde systemen voor codeondertekening

   Om het hoogste beveiligingsniveau te garanderen tijdens het codeondertekeningsproces, mag het systeem dat codeondertekening implementeert, ALLEEN codeondertekening uitvoeren. Op deze manier wordt voorkomen dat er kwetsbaarheden worden veroorzaakt door andere software die uw codeondertekeningsservices kunnen beïnvloeden. Bij twee van de eerder genoemde gevallen van codeondertekening werd het codeondertekeningsproces gekaapt vanwege kwetsbaarheden in andere software.

   Als er veel verschillende software op een computer is geïnstalleerd, kan elk daarvan een potentieel doelwit zijn voor misbruik door aanvallers. Een onderdeel van deze aanpak is dat het systeem volledig moet worden bijgewerkt en gepatcht om een ​​zo veilig mogelijke omgeving te creëren.

5. Controle van de geldigheid van certificaten

   Bij het uitvoeren van een PKI moeten certificaten worden gevalideerd voordat ze mogen worden gebruikt. Bij codeondertekening is dit hetzelfde. Geen enkel certificaat mag worden gebruikt voor codeondertekening, tenzij de geldigheid ervan is geverifieerd. Certificaten moeten niet alleen vóór codeondertekening, maar ook tijdens het proces op hun geldigheid worden gecontroleerd. Dit beschermt tegen eventuele overwegingen in de Public Key Infrastructure.

6. Certificaat Levenscyclusbeheer

   Een belangrijk onderdeel van het succesvol runnen van een PKI is het hebben van een sterke Levenscyclus van certificaten Er is een certificaatbeheerplan opgesteld. De stappen van de certificaatlevenscyclus en hoe certificaten in elke fase worden beveiligd, zijn als volgt:

   1. De reis van mijn leven

      In de detectiefase van de certificaatlevenscyclus wordt het netwerk doorzocht op ontbrekende, verlopen, gecompromitteerde of ongebruikte certificaten. Indien gevonden, moeten deze certificaten worden ingetrokken, verlengd of vervangen. Deze fase van de levenscyclus is uiterst belangrijk, omdat hiermee hiaten in de beveiliging van de Public Key Infrastructures worden opgespoord en doorgegeven aan alle aanwezige monitoringtools. Dit maakt het mogelijk om de inbreuken in het systeem te verhelpen zonder verlies van gevoelige gegevens.

      In deze beheerfase worden ook de certificaten binnen de PKI geïnventariseerd, ter ondersteuning van toekomstige Discovery-fases en eventuele PKI-audits. Het detecteren van verkeerd beheerde of verlopen certificaten dient uitsluitend met vertrouwde software te gebeuren, aangezien het ontbreken van een certificaat in de Discovery-fase ertoe kan leiden dat aanvallers dat certificaat kunnen gebruiken voor misbruik van codeondertekening.

   2. Creatie/Aankoop

      In de Creatie-/Aankoopfase van de levenscyclus worden de certificaten aangemaakt of aangeschaft voor gebruik door de certificaataanvrager. Een gebruiker of apparaat stuurt een Certificaatondertekeningsaanvraag (CSR) aan een uitgevende certificeringsinstantie. De CSR bevat de openbare sleutel en andere registratiegegevens die nodig zijn om de gebruiker in de PKI te registreren. De certificeringsinstantie controleert vervolgens de informatie in de CSR en maakt, indien deze geldig is, het certificaat voor de gebruiker aan.

      De uitgevende certificeringsinstantie (CA) kan deel uitmaken van de eigen PKI van de organisatie of lid zijn van een externe PKI (Public Key Infrastructure). Als een PKI van een derde partij wordt gebruikt, moet het certificaat worden aangeschaft. Bij het aanmaken of aanschaffen van certificaten moet de uitgevende certificeringsinstantie (CA) er zeker van zijn dat de gegevens in de aanvraag legitiem zijn, aangezien een aanvaller zich kan voordoen als een andere persoon om een ​​certificaat te verkrijgen voor kwaadaardig gebruik.

   3. Montage

      De installatie van een certificaat is van cruciaal belang, omdat een slecht geïnstalleerd certificaat misbruikt kan worden voor kwaadaardige doeleinden. Toegang tot het certificaat moet mogelijk zijn, aangezien browsers en andere gebruikers de authenticiteit ervan moeten kunnen verifiëren.

      Toch is de beveiliging van het certificaat nog steeds van het grootste belang tijdens het installatieproces. Om het hoogste niveau van certificaatverwerking en -beveiliging te garanderen, stelt de CA bij de installatie van het certificaat beleid in dat ervoor zorgt dat alleen geautoriseerde personen wijzigingen in het certificaat kunnen aanbrengen.

   4. Opslag

      Om inbreuk te voorkomen, is de opslag van codeondertekeningscertificaten essentieel, aangezien slecht opgeslagen certificaten door kwaadwillenden kunnen worden gestolen en gebruikt. Zoals eerder vermeld, moeten certificaten weliswaar veilig worden opgeslagen, maar moeten ze nog steeds leesbaar zijn voor software en andere gebruikers om de certificaten te authenticeren. Gebruik Hardware Security Modules om de privésleutels van certificaten op te slaan voor een veilige opslag.

   5. Monitoren

      Het bijhouden van certificaten en hun status is essentieel voor een sterk codeondertekeningsproces. Dit is een fase die continu doorgaat, aangezien certificaten op elk moment kunnen verlopen of verloren kunnen gaan. De monitoringfase houdt bij welke certificaten moeten worden ingetrokken, verlengd of vervangen, via de inventaris die in de Discovery-fase is gemaakt.

      Als blijkt dat een certificaat vervangen, verlengd of ingetrokken moet worden, wordt het doorgestuurd naar de volgende fase van de certificaatlevenscyclus. Voor een goede bewaking dienen sterke, geautomatiseerde monitoringsystemen aanwezig te zijn. Geautomatiseerde monitoring zorgt ervoor dat er geen menselijk toezicht plaatsvindt en dat certificaten die de volgende fase nodig hebben, niet over het hoofd worden gezien.

   6. Vernieuwing

      Een certificaat komt in de verlengingsfase van de certificaatlevenscyclus terecht wanneer de vervaldatum nadert. Certificaten moeten een vervaldatum hebben van maximaal vijf jaar om aan de best practices te voldoen.

      Afhankelijk van of er sprake is van automatische of handmatige certificaatverlenging, kunnen certificaten zo worden ingesteld dat ze automatisch worden verlengd zodra hun vervaldatum nadert. Een systeembeheerder kan ook een lijst bijhouden van alle vervaldatums van certificaten, zodat ze op het juiste moment handmatig kunnen worden verlengd. Het is raadzaam om het verlengingsproces te automatiseren, aangezien menselijke fouten ertoe kunnen leiden dat de vervaldatum van certificaten over het hoofd wordt gezien.

   7. herroeping

      Certificaten moeten worden ingetrokken als blijkt dat ze onjuist of anderszins misbruikt zijn. Wanneer een certificaat wordt ingetrokken, worden het certificaat en de bijbehorende gegevens opgenomen in een certificaatintrekkingslijst.

      Deze lijst wordt regelmatig gecontroleerd door certificeringsinstanties, zodat alle aanvragen voor certificaatondertekening die dezelfde gegevens bevatten, worden afgewezen. Om de intrekkingsfase van de certificaatlevenscyclus te beschermen, moeten CRL's up-to-date worden gehouden. Het toestaan ​​van het gebruik van ingetrokken certificaten geeft kwaadwillenden immers toegang tot gevoelige gegevens.

   8. Vervanging

      De laatste fase van de certificaatlevenscyclus is de vervangingsfase. Wanneer u overstapt van het kopen van certificaten naar het aanmaken van eigen certificaten voor uw organisatie, moeten de gekochte certificaten worden vervangen. Dit gebeurt zelden, omdat het veel gemakkelijker is om een ​​certificaat van de oorspronkelijke leverancier te verlengen dan het te vervangen.

      Vervanging van certificaten mag alleen worden uitgevoerd door vertrouwde uitgevende certificeringsinstanties. Daarnaast dienen in elke fase van de levenscyclus na de vervangingsfase best practices te worden gevolgd, aangezien de levenscyclus van een certificaat opnieuw start wanneer een certificaat wordt vervangen door een nieuw certificaat.

Codeondertekeningsdiensten van Encryption Consulting

Om uw codeondertekeningsproces in elke fase te beschermen, kunt u het beste eens kijken naar de oplossingen van Encryption Consulting Codeondertekeningsoplossing – CodeSign Secure. CodeSign Secure biedt een veilige en flexibele oplossing voor uw codeondertekeningsbehoeften voor alle besturingssystemen, waaronder Windows, Linux, Macintosh, Docker en Android- en iOS-applicaties. Digitaal ondertekende code garandeert dat de software op computers en apparaten betrouwbaar en ongewijzigd is.

Wij beschermen uw codeondertekeningssleutels met uw keuze voor HSM die FIPS 140-2 niveau 3 compliant. We helpen u bij het ontwerpen van workflows en beleid om uw taakindienings- en goedkeuringsproces te beveiligen en te stroomlijnen. Daarnaast integreren we uw malware- en virusdetectiesoftware volledig met CodeSign Secure voor optimale monitoring van het codeondertekeningsproces. CodeSign Secure is ontwikkeld op een open REST API, waardoor integraties en vereisten op maat mogelijk zijn.