CVE-2024-58354: Kritisk fejl i cal.com’s GitHub Actions
Fejl i cal.com’s GitHub Actions-opsætning kan give angribere skriveret til kildekoden. Ret workflow-filerne selv, da ingen officiel opdatering findes.
Hvad er det?
CVE-2024-58354 er en sårbarhed i den måde, det open source-baserede bookingsystem cal.com, der senere er omdøbt til cal.diy, kører automatiske tests på GitHub. Projektets arbejdsgang pr.yml bruger triggeren pull_request_target, som giver skriverettigheder til projektets hemmelige adgangsnøgle GITHUB_TOKEN, selv når koden kommer fra en ekstern bidragyder. Denne rettighed sendes videre til en anden arbejdsgang, check-types.yml, som henter og kører den indsendte kode direkte, blandt andet via yarn install og scripts i package.json. En angriber kan derfor sende et pull request, en foreslået kodeændring, med skadelig kode, der bliver kørt med fuld skriveadgang til repositoriet.
Hvem rammer det?
Sårbarheden rammer selve GitHub-repositoriet for cal.com, nu cal.diy, og alle, der selv vedligeholder eller har lavet en fork, en kopi, af projektet med samme arbejdsgangsfiler. Det rammer også danske udviklingsteams, der har genbrugt samme mønster, pull_request_target kombineret med afvikling af ekstern kode, i deres egne GitHub Actions-opsætninger, uanset hvilket produkt de arbejder på. Der findes ingen rettet version, da fejlen ligger i projektets CI-konfiguration og ikke i selve bookingprogrammet.
Hvad kan ske?
En angriber, der kan oprette et pull request, hvilket typisk kun kræver en almindelig GitHub-konto på et offentligt projekt, kan få egen kode kørt med skriveadgang til repositoriet. Herfra kan angriberen indsætte commits, godkende og flette egne pull requests, slette eller ændre kommentarer og slette eller tvangsopdatere grene. I praksis kan angriberen indsætte bagdøre eller skadelig kode direkte i projektets kildekode, som senere kan havne i produktionsversioner, hvis nogen bygger og udruller koden uden nærmere kontrol.
Hvor alvorligt er det?
CVSS-scoren er 9,9 ud af 10, kritisk. Angrebet kræver ingen adgang til systemet i forvejen ud over muligheden for at oprette et pull request, hvilket er let opnåeligt på offentlige GitHub-projekter. Der kræves ingen handling fra en bruger eller administrator, og angrebet kan gennemføres over netværket med lav teknisk kompleksitet. Konsekvensen er høj for integritet og tilgængelighed, da angriberen kan ændre kildekode og slette grene, mens fortrolighed rammes i mindre grad. Der er ikke oplyst aktiv udnyttelse, men sårbarhedstypen, kaldet et repository-overtagelsesangreb, er velkendt og let at afprøve, når mønsteret er identificeret.
Hvad gør jeg nu?
Der findes ingen officiel rettelse, så I skal selv ændre jeres arbejdsgangsfiler, hvis I bruger samme mønster.
- Fjern eller erstat pull_request_target med den mere sikre trigger pull_request, når arbejdsgangen skal teste ekstern kode.
- Undgå at give arbejdsgange med skrivetilladelse til GITHUB_TOKEN adgang til at hente og køre kode fra pull requests, I ikke selv kontrollerer.
- Gennemgå alle jeres GitHub Actions-filer for kombinationen af pull_request_target og checkout af ekstern kode, uanset hvilket projekt de tilhører.
- Kræv manuel godkendelse, før arbejdsgange med forhøjede rettigheder kører på pull requests fra eksterne bidragydere.
- Hvis I selv vedligeholder en fork af cal.com eller cal.diy, opdatér til seneste version af arbejdsgangsfilerne, når projektet retter fejlen.
- Kontakt en sikkerhedsrådgiver, hvis I ikke selv har ressourcer til at gennemgå CI/CD-opsætningen, eller hvis I er i tvivl om, hvorvidt jeres udviklingsmiljø er ramt.
Ret workflow-filer inden næste kodebidrag
Vi anbefaler, at alle udviklingsteams, der bruger GitHub Actions, straks gennemgår arbejdsgangsfiler for kombinationen af pull_request_target og afvikling af ekstern kode, uanset om de bruger cal.com eller ej. Er I ikke selv bidragydere til eller forkere af cal.com-projektet, kan I vente med akut handling, men bør stadig bruge sagen som anledning til at tjekke egne CI-opsætninger. Har I en fork eller intern videreudvikling af projektet, bør rettelsen prioriteres nu, da der ikke findes en officiel opdatering at vente på.
Tidslinje
Konkrete eksempler
Dansk udviklingsteam med intern fork
Et dansk it-team har lavet en intern fork af cal.com til firmaets bookingløsning og har genbrugt de originale GitHub Actions-filer uden ændringer. En ekstern person opretter et pull request med skjult skadelig kode i et testscript. Da arbejdsgangen kører koden automatisk med skriveadgang, får angriberen mulighed for at ændre kildekoden, før teamet opdager det.
Ofte stillede spørgsmål
Er vi ramt af denne sårbarhed?
I er kun direkte ramt, hvis I selv driver eller har forket cal.com eller cal.diy-projektet på GitHub og bruger de nævnte arbejdsgangsfiler. Bruger I derimod bare selve bookingprogrammet som en færdig tjeneste, er I ikke direkte berørt af denne konkrete sårbarhed.
Hvordan tjekker vi, om vores GitHub Actions har samme problem?
Gennemgå alle .github/workflows-filer for triggeren pull_request_target. Tjek om arbejdsgangen efterfølgende henter og kører kode fra pull requests, for eksempel via checkout-handlinger eller kommandoer som yarn install, npm install eller lignende build-scripts.
Kan vi vente til weekenden med at rette det?
Har I ikke selv en fork eller aktiv udvikling på cal.com-projektet, kan I godt vente. Har I derimod åbne pull requests fra eksterne bidragydere på et projekt med samme mønster, bør rettelsen ske, før næste pull request behandles.
Skal vi anmelde hændelsen, hvis vi bliver ramt?
Bliver jeres kildekode kompromitteret, og indeholder projektet personoplysninger eller driver kritiske systemer, kan det udløse anmeldelsespligt efter databeskyttelsesforordningen. Vurdér konkret omfang og data sammen med jeres databeskyttelsesrådgiver.
Hvorfor er der ingen officiel opdatering?
Fejlen ligger i projektets egen CI/CD-konfiguration, altså opsætningen af automatiske tests, og skal derfor rettes af dem, der ejer den pågældende GitHub-repository, ikke via en almindelig softwareopdatering.
Rammer dette også vores egne interne GitHub-projekter?
Ja, hvis I bruger samme kombination af pull_request_target og afvikling af ekstern kode i jeres egne arbejdsgange, uanset hvilket produkt I udvikler. Sårbarhedsmønsteret er generelt og ikke unikt for cal.com.
CVSS-detaljer
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:H/A:H
CWE-svaghedstyper
Original NVD-beskrivelse (engelsk)
cal.com (calcom repository, later renamed cal.diy) is affected by a repository takeover vulnerability in its GitHub Actions workflows. The workflow pr.yml uses the pull_request_target trigger with the repository’s default write permissions and passes them down to check-types.yml. check-types.yml then performs a ‘dangerous’ checkout of the attacker-submitted pull request code (via the dangerous-git-checkout action) and subsequently executes it (through yarn install and package.json scripts). An attacker can open a pull request whose code runs arbitrary commands with the repository’s write-scoped GITHUB_TOKEN, allowing them to push commits, merge or mutate pull requests, add or delete comments, and delete or force-push branches, thereby compromising the repository. The main branch is affected; no patched version is available.
Referencer & kilder
Eksterne kilder
Brug for hjælp med jeres sikkerhed?
Vi hjælper SMV’er med at omsætte trusler som denne til konkrete handlingsplaner.