Auteur
Een gids om u bewust te worden van de risico's waaraan u wordt blootgesteld en een paar tips om u ertegen te beschermen.
Onlangs is er een nieuw soort cyberdreiging aan het licht gekomen: aanvallen op de toeleveringsketen van software. Hoewel ze zeldzaam zijn, hebben ze enorme gevolgen, en bescherming ertegen wordt steeds belangrijker. Vanwege de verscheidenheid aan gebruikssituaties is er niet één regel die u op uw python-projecten kunt toepassen om veilig te zijn en zoals altijd hangt het af van uw context.
Inleiding
In traditionele industrieën is een toeleveringsketen alles wat een bedrijf in staat stelt om een product aan de klant te leveren. Als u bijvoorbeeld een croissant bij de bakker koopt, maken alle ingrediënten, de verpakking en het transport deel uit van de toeleveringsketen.
In het softwaredomein is een toeleveringsketen alles wat invloed heeft op uw software voordat deze in productie wordt genomen. Het omvat alles van de ontwikkelingsfase tot het releaseproces, inclusief de code die u hebt geschreven, uw afhankelijkheden, uw buildomgeving, uw IDE, uw image register - elk onderdeel waarmee uw software op enig moment interageert!
De term “toeleveringsketen” is onlangs in het nieuws gekomen vanwege cyberaanvallen die een grote impact hadden. Van alle aanvallen is Solarwinds misschien wel de bekendste. De Amerikaanse overheid, grote techbedrijven zoals Microsoft en Intel, maar ook ziekenhuizen, energiebedrijven en financiële instellingen zijn getroffen.
Ironisch genoeg is de hoofdoorzaak de infectie van Solarwinds Orion, een netwerkbeveiligingsmonitor. Het buildsysteem was gecompromitteerd en alle nieuwe releases tussen maart en juni 2020 waren geïnfecteerd met malware. Het resultaat is dat alle klanten die hun software in die periode hebben bijgewerkt, besmet zijn geraakt.
Hoewel de Solarwinds-aanval grotendeels door de media is behandeld, zijn er tientallen soortgelijke aanvallen waar we nog nooit van hebben gehoord. Gelukkig houdt de Cloud Native Computing Foundation ze allemaal bij in een openbare opslagplaats. U zult misschien verrast zijn door de versnelling van deze aanvallen in de afgelopen paar jaar.
Het is niet haalbaar om alles wat te maken heeft met de beveiliging van de toeleveringsketen in één blogpost te behandelen, dus we zullen ons in dit artikel vooral richten op projecten die Python als primaire taal gebruiken.
Hoe uw afhankelijkheden beheren in Python
Hoewel Python een “batterijen inbegrepen” filosofie heeft, hebt u vaak externe bibliotheken nodig die u kunt downloaden van PyPI, de officiële Package Index en op dit punt moet u heel voorzichtig zijn.
Het Python-ecosysteem is al doelwit geweest, met name door het gebruik van twee technieken:
De eerste techniek heeft betrekking op een commando dat elke Python-ontwikkelaar minstens één keer in zijn/haar carrière heeft uitgevoerd:
pip installeren
Hackers publiceren pakketten met bijna dezelfde naam als bestaande pakketten in de hoop dat u een typefout maakt en hun pakket installeert in plaats van het officiële pakket. Een pakket met de naam python3-dateutil in plaats van de officiële datumutil is onlangs gedetecteerd.
De python-gemeenschap is hard werken om het risico te beperken, maar het risico is nog steeds hoog.
De tweede techniek, afhankelijkheidsverwarring, is geavanceerder dan de eerste en heeft te maken met hoe pip werkt onder de motorkap.
Deze keer stelt deze opdracht u bloot aan het risico:
pip installeren --extra-index-url
Wanneer u dit commando typt, gebeurt er het volgende:
Laten we een voorbeeld nemen:
In dit voorbeeld wordt het pakket van de kwaadwillende hacker op de machine geïnstalleerd. Het hogere versienummer staat namelijk op de openbare pakketindex.
U hebt misschien al begrepen wat er mis kan gaan met dit proces. Iemand met slechte bedoelingen kan pakketten publiceren op een openbare repository die dezelfde namen hebben als de pakketten die gehost worden op interne pakketindexen en ze labelen met een belachelijk hoog versienummer. Bovendien is het vinden van relevante pakketnamen niet zo moeilijk als aangetoond door deze beveiligingsonderzoeker.
Dit commando kan worden gekwalificeerd als “onveilig door ontwerp”. Deze aanval maakt gebruik van een functie van de Python pakketbeheerder en slechts enkele ontwikkelaars zijn zich bewust van dit gedrag.
Hoe u zich tegen deze aanvallen op de toeleveringsketen kunt verdedigen
Om u te verdedigen tegen typo-squatting aanvallen, kunt u een vergrendelingsbestand. A goed slotbestand heeft de volgende kenmerken:
Het goede nieuws is dat er een pakket bestaat dat als doel heeft om een vergrendelingsbestand voor u te maken: pip-tools. Met slechts een paar commando's kunt u een slotbestand genereren met alle attributen die we eerder beschreven hebben.
$ python3 -m venv my-env # maak een nieuwe virtuele omgeving aan $ bron my-env/bin/activate # activeren $ pip install pip-tools==6.3.0 # installeer het pakket waarmee u u uw afhankelijkheden goed kunt beheren $ echo “sacremoses==0.0.46” >> requirements.in # voeg het pakket van uw keuze in requirements.in $ pip-compile --generate-hashes # compileert requirements.txt met hashes gebaseerd op wat u in requirements.in hebt gezet
Uw requirements.txt bestand zou er als volgt uit moeten zien:
Nu u dit bestand hebt, dat al uw afhankelijkheden met hun bijbehorende versies en hashes bevat, kunt u de volgende keer dat u gaat implementeren de volgende opdracht uitvoeren:
pip install --require-hashes -r requirements.txt
Zo weet u zeker dat de pakketten die u in productie gebruikt, niet gewijzigd zijn. Ervan uitgaande dat u voorzichtig bent geweest toen u uw vereisten.in bestand 👀, kunt u er ook op vertrouwen dat u het pakket downloadt dat u echt wilt, omdat alles geautomatiseerd is. Geen risico op een typefout!
Deze best practice is goed ter verdediging tegen typo-squatting aanvallen, maar hoe zit het met afhankelijkheidsverwarring?
Als u kijkt naar de pip documentatie, zult u zien dat er twee opties zijn die u kunt gebruiken om pakketten van een interne repository te downloaden:
In de documentatie staat:
Zoals u kunt zien, is er een klein verschil tussen de twee en het is op het eerste gezicht niet duidelijk. Het verschil is dat als u de --index-url optie, pip zou alleen pakketten ophalen uit de repo met de URL die u hebt opgegeven, en niet uit openbare repositories. Dus, als u het gedrag dat we eerder beschreven wilt vermijden, gebruik dan --index-url liever dan --extra-index-url en u zult veilig zijn!
Ten slotte kunt u, om de nieuwste kwetsbaarheden te volgen die in uw afhankelijkheden zijn ontdekt, ervoor kiezen om periodiek de GitHub advies database of beter nog, gebruik hulpmiddelen zoals dependabot die automatisch een pull-verzoek zal indienen op uw repo om een afhankelijkheid bij te werken waarin onlangs een kritieke kwetsbaarheid is geïdentificeerd.
Samenvatting
In dit artikel hebben we het concept van de toeleveringsketen voor de softwarewereld geïntroduceerd. We hebben specifiek onderzocht hoe dit concept van toepassing is op het Python-ecosysteem. Typo-squatting en afhankelijkheidsverwarring zijn uitgelegd en er zijn oplossingen voorgesteld om het risico op compromittering te beperken.
Deze korte inleiding tot de beveiliging van de toeleveringsketen besloeg slechts het topje van de ijsberg, we hebben niet de kans gehad om te bespreken hoe systemen bouwen of zelfs uw IDE's kan worden gecompromitteerd, maar dat laat ik voor een ander artikel!
Bedankt voor het lezen! Ik hoor graag uw feedback. Als u het leuk vond om te lezen, kijk dan gerust naar onze openstaande posities bij Artefact 🙂
