Verkeerde configuraties voor continue integratie en continue levering (CI/CD) die zijn ontdekt in het open-source TensorFlow machine learning-framework hadden kunnen worden uitgebuit om supply chain-aanvallen te orkestreren.
De verkeerde configuraties kunnen door een aanvaller worden misbruikt om “een supply chain-compromis van TensorFlow-releases op GitHub en PyPi uit te voeren door de build-agents van TensorFlow in gevaar te brengen via een kwaadwillig pull-verzoek”, zeiden Praetorian-onderzoekers Adnan Khan en John Stawinski in een rapport dat deze week werd gepubliceerd.
Succesvol misbruik van deze problemen zou een externe aanvaller in staat kunnen stellen kwaadaardige releases te uploaden naar de GitHub-repository, externe code-uitvoering te verkrijgen op de zelf-gehoste GitHub-runner en zelfs een GitHub Personal Access Token (PAT) op te halen voor de tensorflow-jenkins-gebruiker.
TensorFlow gebruikt GitHub Actions om de pijplijn voor het bouwen, testen en implementeren van software te automatiseren. Runners, die verwijzen naar machines die taken uitvoeren in een GitHub Actions-workflow, kunnen zelf worden gehost of worden gehost door GitHub.
“We raden u aan alleen zelfgehoste runners met privérepository’s te gebruiken”, merkt GitHub op in de documentatie. “Dit komt omdat forks van uw openbare repository potentieel gevaarlijke code kunnen uitvoeren op uw zelf-gehoste runner-machine door een pull-verzoek te maken dat de code in een workflow uitvoert.”
Anders gezegd: hierdoor kan elke bijdrager willekeurige code uitvoeren op de zelf-gehoste runner door een kwaadaardig pull-verzoek in te dienen.
Dit levert echter geen enkel beveiligingsprobleem op bij door GitHub gehoste runners, aangezien elke runner kortstondig is en een schone, geïsoleerde virtuele machine is die aan het einde van de taakuitvoering wordt vernietigd.
Praetorian zei dat het in staat was om TensorFlow-workflows te identificeren die werden uitgevoerd op zelfgehoste runners, en vervolgens fork pull-verzoeken van eerdere bijdragers te vinden die automatisch de juiste CI/CD-workflows activeerden zonder goedkeuring.
Een tegenstander die een doelrepository wil trojaniseren, kan daarom een typefout herstellen of een kleine maar legitieme codewijziging doorvoeren, er een pull-verzoek voor maken en vervolgens wachten tot het pull-verzoek is samengevoegd om een bijdrager te worden. Dit zou hen vervolgens in staat stellen code uit te voeren op de runner zonder een rode vlag te laten schijnen door een frauduleus pull-verzoek te maken.
Nader onderzoek van de workflow-logboeken bracht aan het licht dat de zelf-gehoste runner niet alleen niet-efemeer was (waardoor de deur werd geopend voor doorzettingsvermogen), maar ook dat de GITHUB_TOKEN-machtigingen die aan de workflow waren gekoppeld, uitgebreide schrijfrechten hadden.
“Omdat de GITHUB_TOKEN de toestemming Contents:write had, kon deze releases uploaden naar https://github[.]com/tensorflow/tensorflow/releases/”, aldus de onderzoekers. “Een aanvaller die een van deze ‘GITHUB_TOKEN’s heeft gecompromitteerd, zou zijn eigen bestanden aan de Release Assets kunnen toevoegen.”
Bovendien kunnen de content:write-rechten worden gebruikt om code rechtstreeks naar de TensorFlow-repository te pushen door de kwaadaardige code heimelijk in een feature branch te injecteren en deze in de hoofdbranch te laten samenvoegen.
Dat is niet alles. Een bedreigingsacteur zou de AWS_PYPI_ACCOUNT_TOKEN kunnen stelen die wordt gebruikt in de release-workflow om zich te authenticeren bij het Python Package Index (PyPI)-register en een kwaadaardig Python .whl-bestand te uploaden, waardoor het pakket effectief wordt vergiftigd.
“Een aanvaller kan ook de machtigingen van GITHUB_TOKEN gebruiken om het geheim van de JENKINS_TOKEN-repository te compromitteren, ook al werd dit geheim niet gebruikt in workflows die op de zelfgehoste runners draaiden”, aldus de onderzoekers.
Na de verantwoorde openbaarmaking op 1 augustus 2023 werden de tekortkomingen vanaf 20 december 2023 door de projectbeheerders aangepakt door goedkeuring te eisen voor workflows die werden ingediend vanuit alle fork pull-verzoeken en door de GITHUB_TOKEN-machtigingen te wijzigen in alleen-lezen voor workflows die op zelfgehoste lopers.
“Vergelijkbare CI/CD-aanvallen nemen toe nu steeds meer organisaties hun CI/CD-processen automatiseren”, aldus de onderzoekers.
“AI/ML-bedrijven zijn bijzonder kwetsbaar omdat veel van hun workflows aanzienlijke rekenkracht vereisen die niet beschikbaar is in door GitHub gehoste hardlopers, waardoor de prevalentie van zelfgehoste hardlopers toeneemt.”
De onthulling komt omdat beide onderzoekers onthulden dat verschillende openbare GitHub-repository’s, waaronder die geassocieerd met Chia Networks, Microsoft DeepSpeed en PyTorch, vatbaar zijn voor kwaadaardige code-injectie via zelfgehoste GitHub Actions-runners.
