Google heeft het SLSA (Supply-chain Levels for Software Artifacts) framework geïntroduceerd, dat de bestaande ervaringen samenvat met betrekking tot het beschermen van de ontwikkelinfrastructuur tegen aanvallen tijdens de stadia van coderen, testen, bouwen en verspreiden van een product.
De ontwikkelingsprocessen worden steeds complexer en afhankelijker van externe hulpmiddelen, wat gunstige omstandigheden creëert voor aanvallen die niet gericht zijn op het ontdekken en exploiteren van kwetsbaarheden in het eindproduct, maar op de compromittering van het ontwikkelingsproces zelf (supply chain-aanvallen, meestal gericht op het inbrengen van kwaadaardige wijzigingen tijdens het coderen, de wijziging van de verspreide componenten en afhankelijkheden).
Het framework houdt rekening met 8 soorten aanvallen die verband houden met de bedreigingen van het inbrengen van kwaadaardige wijzigingen tijdens de stadia van coderen, bouwen, testen en verspreiden van het product.
- A. Het inbrengen van wijzigingen in de broncode die backdoors of verborgen fouten bevatten die tot kwetsbaarheden leiden.
Voorbeeld van een aanval: ‘Hypocrite Commits’ — de poging om kwetsbaarheidspatches in de Linux-kernel te pushen.
Voorgestelde beschermingsmethode: onafhankelijke beoordeling van elke wijziging door twee ontwikkelaars.
- B. Compromitteren van het platform voor broncodebeheer.
Voorbeeld van een aanval: het inbrengen van kwaadaardige commits met een backdoor in de Git-repository van het PHP-project na het uitlekken van ontwikkelaarswachtwoorden.
Voorgestelde beschermingsmethode: verbetering van de beveiliging van het platform voor broncodebeheer (in het geval van PHP werd de aanval uitgevoerd via een weinig gebruikte HTTPS-interface die wijzigingen toestond zonder verificatie van de SSH-sleutel, terwijl een onbetrouwbare MD5 werd gebruikt voor het hashen van wachtwoorden).
- C. Wijzigingen aanbrengen tijdens de overdracht van code naar het build- of continue integratiesysteem (de gebouwde code komt niet overeen met de code in de repository).
Voorbeeld van een aanval: het inbrengen van een backdoor in Webmin door wijzigingen aan te brengen in de bouwinfrastructuur, waardoor bestanden met code werden gebruikt die verschilden van de bestanden in de repository.
Voorgestelde beschermingsmethode: integriteitscontrole en identificatie van de bron van de binnenkomende code naar de build. de server.
- D. Compromitteren van het build-platform.
Voorbeeld van een aanval: de SolarWinds-aanval, waarbij tijdens de bouwfase een backdoor in het SolarWinds Orion-product werd ingebracht.
Vorgestelde beveiligingsmethode: implementatie van uitgebreide beveiligingsmaatregelen voor het assemblageplatform.
- E. Verspreiding van malware via onbetrouwbare afhankelijkheden.
Voorbeeld van een aanval: inbrengen van een backdoor in een populaire bibliotheek event-stream, door het toevoegen van een onschadelijke afhankelijkheid, die vervolgens in een van de updates van die afhankelijkheid kwaadaardige code opnam (de kwaadaardige wijziging was niet zichtbaar in de git-repository en was alleen aanwezig in het kant-en-klare MNP-pakket).
Vorgestelde beveiligingsmethode: herhaaldelijke toepassing van SLSA-eisen op alle afhankelijkheden (in het geval van event-stream zou een controle de samenstelling van de code hebben ontdekt die niet overeenkwam met de inhoud van de hoofd Git-repository).
- F. Uploaden van artefacten die niet zijn aangemaakt in het CI/CD-systeem.
Voorbeeld van een aanval: toevoeging van kwaadaardige code aan het CodeCov-script, waardoor aanvallers informatie konden extraheren die was opgeslagen in de omgevingen van de klanten van de continue integratiesystemen.
Vorgestelde beveiligingsmethode: controle van de bron en integriteit van artefacten (in het geval van CodeCov had ontdekt kunnen worden dat het script Bash Uploader dat van de website codecov.io werd aangeboden niet overeenkwam met de code uit de projectrepository).
- G. Compromitteren van de pakketrepository.
Voorbeeld van een aanval: onderzoekers slaagden erin om spiegels van enkele populaire pakketrepositories op te zetten met als doel kwaadaardige pakketten via hen te verspreiden.
Vorgestelde beveiligingsmethode: verificatie dat de verspreide artefacten zijn samengesteld uit de opgegeven bronteksten.
- H. Verwarring van de gebruiker om een verkeerd pakket te installeren.
Voorbeeld van een aanval: gebruik van typogratiering (NPM, RubyGems, PyPI) om pakketten in repositories te plaatsen die qua spelling lijken op populaire applicaties (bijvoorbeeld coffe-script in plaats van coffee-script).
Om de gemelde bedreigingen te blokkeren, biedt SLSA een reeks aanbevelingen en hulpmiddelen voor het automatiseren van de creatie van metadata voor audits. SLSA vat de typische aanvallmethoden samen en introduceert het concept van beveiligingsniveaus. Elk niveau stelt specifieke eisen aan de infrastructuur die garanderen dat de artefacten die worden gebruikt bij de ontwikkeling integer zijn. Hoe hoger het ondersteunde niveau van SLSA, hoe meer beveiligingsmaatregelen zijn geïmplementeerd en hoe beter de infrastructuur beschermd is tegen typische aanvallen.
- SLSA 1 vereist dat het bouwproces volledig geautomatiseerd is en metadata ('provenance') genereert over hoe artefacten zijn verzameld, inclusief informatie over de bronbestanden, afhankelijkheden en het bouwproces (een voorbeeld van een metadata-generator voor auditing is gesuggereerd voor GitHub Actions). SLSA 1 omvat geen elementen ter bescherming tegen kwaadaardige veranderingen, maar identificeert de code op de eenvoudigste manier en biedt metadata voor kwetsbaarheidsbeheer en risicioanalyse.
- SLSA 2 breidt het eerste niveau uit met de eis van het gebruik van versiebeheersystemen en bouwservices die geauthentiseerde metadata genereren. Toepassing van SLSA 2 maakt het mogelijk om de oorsprong van de code te traceren en voorkomt ongeautoriseerde wijzigingen in de code, mits er gebruik wordt gemaakt van betrouwbare bouwservices.
- SLSA 3 bevestigt dat de bronbestanden en het bouwplatform voldoen aan de normen die auditmogelijkheden voor de code en de integriteit van de geleverde metadata garanderen. Het wordt aangenomen dat auditors platforms kunnen certificeren op basis van naleving van de normen.
- SLSA 4 is het hoogste niveau en voegt de volgende eisen toe aan de eerdere niveaus:
- Verplichte beoordeling van alle wijzigingen door twee verschillende ontwikkelaars.
- Alle bouwstappen, code en afhankelijkheden moeten volledig worden gedeclareerd, alle afhankelijkheden moeten afzonderlijk worden geëxtraheerd en geverifieerd, en het bouwproces moet worden uitgevoerd zonder toegang tot het netwerk.
- Toepassing van een proces voor reproduceerbare builds - de mogelijkheid om het bouwproces zelf te herhalen en te verifiëren dat het uitvoerbare bestand is opgebouwd uit de geleverde bronbestanden.
Bron: opennet.ru
