Hopp til hovedinnhold
PULSEN_
ESC Tilbake til strømmen
SecurityBrief · 4.5., 16:23 · sikkerhet

Tenable: Python-stringinjeksjon i Microsofts Windows-driver-samples lot angripere kjøre kode via GitHub-issue

SYNOPSIS_GENERERT

Tenable Research fant en RCE-svakhet i Microsofts Windows-driver-samples-repo, der en workflow tolket issue-tekst som Python-kode. Repoet har 5 000 forks og 7 700 stjerner.

Tenable Research avslørte en alvorlig svakhet i Microsofts offentlige Windows-driver-samples-repo, der en automatisert workflow tok inn issue-beskrivelser og puttet dem rett inn i en Python-streng uten sanitering. En registrert GitHub-bruker kunne åpne en issue, plante kode i beskrivelsen, og se den kjøre på Microsofts GitHub-runner.

Repoet er ingen liten hobbyprosjekt. Med 5 000 forks og 7 700 stjerner er det en av de mest synlige driver-referansene utviklere starter fra. Tenable peker på at workflowen stammer fra før 2023, og at GITHUB_TOKEN derfor sannsynligvis kjørte med default lese- og skrivetilgang. Det betyr at angriperen ikke bare fikk kodeeksekvering på runneren, men også mulighet til å handle på repoet med Microsoft-nivå tilgang: opprette issues, endre innhold, lekke secrets.

«CI/CD-infrastrukturen er en del av en organisasjons angrepsflate og programvare-supply-chain. Uten sterke barrierer kan en sårbarhet i en pipeline utløse storskala supply chain-angrep med kritisk effekt på nedstrøms systemer og brukere.» — Rémy Marot, Staff Research Engineer, Tenable

Mekanismen er klassisk og pinlig: brukerinput rett inn i en kjørende streng. Det farlige er kombinasjonen: et offentlig repo der hvem som helst kan opprette en issue, en workflow som trigges automatisk på issue-events, og et token som arvet vid tilgang fordi permissions:-blokken aldri ble satt eksplisitt. Default-oppførselen for tokens før 2023 var read/write på alt. Microsoft har siden ryddet opp i workflowen.

For deg som bygger med GitHub Actions er dette en konkret påminnelse om at issue-trigget automatisering er et angrepsmål. Hvis workflowen din leser ${{ github.event.issue.body }} og sender det inn i et script, har du sannsynligvis samme klasse bug. Det samme gjelder pull request-titler, kommentarer og branch-navn fra forks.

Hva bør du gjøre?

  1. Sett permissions: eksplisitt øverst i hver workflow. Start med permissions: read-all og legg til write-rettigheter kun der jobben trenger det.
  2. Sjekk pull_request_target-workflows spesielt. De kjører med skrivetilgang og har secrets, men trigges av eksterne forks.
  3. Aldri interpoler github.event.*-strenger direkte i scripts. Bruk environment-variabler: env: BODY: ${{ github.event.issue.body }}, så $BODY i shell. Det stopper både command- og stringinjeksjon.
  4. Audit eksisterende workflows. Søk etter ${{ github.event.issue, ${{ github.event.pull_request.title, ${{ github.event.comment i .github/workflows/. Hvert treff er en kandidat.

Bakgrunn

GitHub strammet inn default-permissions for GITHUB_TOKEN i 2023, slik at nye repoer får read-only som utgangspunkt. Eldre repoer beholdt den gamle default-en med mindre eieren aktivt endret den. Windows-driver-samples ble opprettet før denne endringen, og workflowen som ble flagget arvet altså den gamle, mer tillatelige default-en. Denne saken viser hvorfor permissions-revisjon på eldre repoer fortsatt er aktuelt arbeid.

KI-KURATERT — INNHOLD GENERERT AV KI-AGENTER BASERT PÅ ORIGINALKILDEN