GitGuardian staat bekend om zijn jaarlijkse State of Secrets Sprawl-rapport. In hun rapport uit 2023 vonden ze meer dan 10 miljoen blootgestelde wachtwoorden, API-sleutels en andere inloggegevens die zichtbaar waren in openbare GitHub-commits. De conclusies uit hun rapport uit 2024 belichtten niet alleen 12,8 miljoen nieuw onthulde geheimen in GitHub, maar een aantal in de populaire Python-pakketrepository PyPI.
PyPI, een afkorting van de Python Package Index, host meer dan 20 terabytes aan bestanden die gratis beschikbaar zijn voor gebruik in Python-projecten. Als je ooit pip install [name of package], heeft het dat pakket waarschijnlijk uit PyPI gehaald. Veel mensen gebruiken het ook. Of het nu om GitHub, PyPI of andere gaat, zo stelt het rapport: “Open-sourcepakketten vormen naar schatting 90% van de code die vandaag de dag in productie wordt uitgevoerd.” Het is gemakkelijk in te zien waarom deze pakketten ontwikkelaars helpen te voorkomen dat elke dag miljoenen wielen opnieuw moeten worden uitgevonden.
In het rapport uit 2024 rapporteerde GitGuardian dat er meer dan 11.000 blootgesteld waren uniek geheimen, waarvan er in 2023 1.000 aan PyPI worden toegevoegd. Dat is niet veel vergeleken met de 12,8 miljoen nieuwe geheimen die in 2023 aan GitHub zijn toegevoegd, maar GitHub is een orde van grootte groter.
Een verontrustender feit is dat van de in 2017 geïntroduceerde geheimen er zes tot zeven jaar later nog steeds bijna honderd geldig waren. Ze hadden niet de mogelijkheid om alle geheimen op geldigheid te controleren. Toch werden er meer dan 300 unieke en geldige geheimen ontdekt. Hoewel dit licht alarmerend is voor de toevallige waarnemer en niet noodzakelijkerwijs een bedreiging is voor willekeurige Python-ontwikkelaars (in tegenstelling tot de 116 kwaadaardige pakketten die ESET eind 2023 rapporteerde), is het een bedreiging van onbekende omvang voor de eigenaren van die pakketten.
Hoewel GitGuardian over honderden geheimdetectoren beschikt, heeft het zich in de loop der jaren ontwikkeld en verfijnd. Enkele van de meest voorkomende geheimen die het in zijn algemene onderzoek uit 2023 ontdekte, waren OpenAI API-sleutels, Google API-sleutels en Google Cloud-sleutels. Het is voor een competente programmeur niet moeilijk om een reguliere expressie te schrijven om één gemeenschappelijk geheim formaat te vinden. En zelfs als het veel false positives zou opleveren, zou het automatiseren van controles om te bepalen of ze geldig waren de ontwikkelaar kunnen helpen een kleine schat aan exploiteerbare geheimen te vinden.
Het is nu geaccepteerde logica dat als een sleutel is gepubliceerd in een openbare repository zoals GitHub of PyPI, deze als gecompromitteerd moet worden beschouwd. In tests zijn honeytokens (een soort “verouderde” API-sleutel zonder toegang tot bronnen) door bots getest op geldigheid binnen een minuut nadat ze op GitHub waren gepubliceerd. In feite fungeren honeytokens als een ‘kanarie’ voor een groeiend aantal ontwikkelaars. Afhankelijk van waar je een specifiek honeytoken hebt geplaatst, kun je zien dat iemand daar rondsnuffelt en wat informatie over hem of haar krijgen op basis van telemetriegegevens die zijn verzameld wanneer het honeytoken wordt gebruikt.
De grotere zorg wanneer u per ongeluk een geheim publiceert, is niet alleen dat een kwaadwillende actor uw cloudrekening zou kunnen opdrijven. Vanaf daar kunnen ze verder. Als een AWS IAM-token met te veel toestemming zou uitlekken, wat zou die kwaadwillende actor dan kunnen vinden in de S3-buckets of databases waartoe hij toegang verleent? Zou die kwaadwillende actor toegang kunnen krijgen tot andere broncode en iets kunnen corrumperen dat aan vele anderen zal worden geleverd?
Of u nu geheimen doorgeeft aan GitHub, PyPI, NPM of een openbare verzameling broncode, de beste eerste stap als u ontdekt dat een geheim is gelekt, is het intrekken ervan. Onthoud dat kleine venster tussen publicatie en exploitatie voor een honeytoken. Zodra een geheim is gepubliceerd, is het waarschijnlijk gekopieerd. Zelfs als u geen ongeoorloofd gebruik heeft vastgesteld, kunt u moeten neem aan dat een ongeautoriseerde en kwaadwillende iemand het nu heeft.
Zelfs als uw broncode zich in een privéopslagplaats bevindt, zijn er talloze verhalen over kwaadwillende actoren die toegang krijgen tot privéopslagplaatsen via social engineering, phishing en natuurlijk gelekte geheimen. Als er uit dit alles een les schuilt, is het dat geheimen in platte tekst in de broncode uiteindelijk ontdekt worden. Of ze nu per ongeluk in het openbaar worden gepubliceerd of worden gevonden door iemand met toegang die ze niet zouden moeten hebben, ze worden gevonden.
Samenvattend: waar u uw broncode ook opslaat of publiceert, of het nu een privéopslagplaats of een openbaar register is, u moet een paar eenvoudige regels volgen:
- Bewaar geheimen niet in platte tekst in de broncode.
- Zorg ervoor dat degenen die een geheim te pakken krijgen, niet op expeditie gaan door de privileges die deze geheimen verlenen strikt te beperken.
- Als je ontdekt dat je een geheim hebt gelekt, trek het dan in. Het kan zijn dat u even de tijd moet nemen om ervoor te zorgen dat uw productiesystemen over het nieuwe, niet-gelekte geheim voor bedrijfscontinuïteit beschikken, maar trek dit zo snel mogelijk in.
- Implementeer automatiseringen zoals die aangeboden door GitGuardian om ervoor te zorgen dat u niet afhankelijk bent van onvolmaakte mensen om de best practices rond geheimbeheer perfect in acht te nemen.
Als u deze volgt, hoeft u wellicht niet de lessen te leren die 11.000 geheimbezitters waarschijnlijk op de harde manier hebben geleerd door ze op PyPI te publiceren.
