Útok na OVHcloud CLI: ako sa dali prepísať vydania na GitHube a ako ich chrániť

V pondelok 19. októbra 2026 útočník, ktorý ovládol GitHub účet prispievateľa OVHcloud, vymenil binárky v piatich už existujúcich vydaniach oficiálneho nástroja príkazového riadka. Zdrojový kód ani build pipeline sa nezmenili. Stačilo, že GitHub vydania neboli nezmeniteľné. Tento článok rozoberá, čo sa podľa dostupných správ stalo, a ukazuje, ako si zabezpečiť vlastné vydania podpisom cez cosign a ako ich overovať pred spustením.

Čo sa stalo

• Kedy: 19. októbra 2026 medzi 12:47 a 14:21 UTC (14:47 až 16:21 stredoeurópskeho letného času). Súbory boli dostupné približne 94 minút.
• Čo bolo zasiahnuté: vydania v0.11.0 až v0.15.0 nástroja ovhcloud-cli. Verzia v0.10.0 je podľa OVHcloud čistá. Podľa správ si súbory stiahlo zhruba 250 ľudí alebo systémov.
• Ako: útočník použil ukradnutý prístup k GitHub účtu prispievateľa a v existujúcich vydaniach nahradil súbory lokálne zostavenými škodlivými binárkami. Podľa OVHcloud sa interné build systémy neskompromitovali. Release workflow vtedy ani nebežal.
• Prečo to prešlo: v repozitári nebola zapnutá nezmeniteľnosť vydaní (release immutability). Oprávnený používateľ preto mohol meniť už zverejnené súbory priamo na GitHube, bez kontroly zo strany CI/CD.
• Odhalenie: problém nahlásil zákazník. OVHcloud súbory vymazalo a ešte v ten večer vydalo čistú, nezmeniteľnú verziu v0.16.0.
• Čo škodlivý kód robil: podľa OVHcloud mal zhromažďovať tajomstvá uložené na disku. Ktoré súbory presne čítal a kam ich posielal, firma nezverejnila. Konkrétne tvrdenia o konfiguráciách Dockeru či Kubernetesu a o databázach z vývojárskych nástrojov som preto do článku nepreberal.
• Súvis s GlassWorm: niektoré správy spájajú útok s kampaňou GlassWorm. Iný zdroj upozorňuje, že kópia októbrovej binárky sa nezachovala, takže priame prepojenie nemožno potvrdiť. Podľa OVHcloud bol účet vystavený cez škodlivé rozšírenie na osobnom zariadení vývojára.

Prečo to nie je mýtus o „starej stabilnej verzii“

Bežná predstava hovorí, že staršia verzia z oficiálneho repozitára je bezpečná, lebo je preverená časom. Tento incident ukazuje opak. Ak sú vydania meniteľné, aj stará verzia môže byť odrazu iná než tá, ktorú si stiahol niekto pred rokom. Rovnaká značka verzie (tag) teda nezaručuje rovnaký obsah.

Inštalačný skript projektu navyše sťahoval archív bez kontroly odtlačku. Zasiahnutý bol ním aj ručný download.

Prečo nestačí dvojfázové overenie

Dvojfázové overenie chráni prihlásenie. Ak však útočník ukradne už vydaný token alebo kľúč, jeho použitie druhým faktorom nechránené nie je. Toto rozlíšenie je dôležité: v tomto prípade použili ukradnuté kľúče na nahratie súborov. Obrana teda musí stáť aj na tom, aby sa kompromitovaný účet nedal použiť na tichú zmenu vydaní.

Obrana 1: Zapni nezmeniteľné vydania

GitHub umožňuje označiť vydania ako nezmeniteľné. Po zverejnení sa už nedajú meniť ani mazať súbory a značka sa nedá presunúť. V nastaveniach repozitára (sekcia Releases) túto možnosť zapni. Pri nezmeniteľných vydaniach vytváraj vydanie najprv ako koncept, nahraj súbory a až potom ho zverejni. Presnú cestu v nastaveniach si over v aktuálnej dokumentácii GitHubu, lebo sa môže meniť.

Obrana 2: Podpisuj artefakty cez cosign

Cosign z projektu Sigstore umožňuje podpísať súbor bez správy dlhodobého kľúča. Takzvaný keyless podpis používa identitu GitHub Actions workflowu. Overovateľ potom nekontroluje „verejný kľúč organizácie“, ale to, že súbor podpísal konkrétny workflow konkrétneho repozitára. Útočník, ktorý má len ukradnuté prihlasovacie údaje, takýto podpis bez spustenia workflowu nevyrobí.

Verzie akcií v ukážke pripni na úplný hash commitu a nie na pohyblivú značku. Pripnutie značky je rovnaké riziko, aké sa už zneužilo pri iných útokoch na reťazec dodávok.

name: release
on:
  push:
    tags: ["v*"]

permissions:
  contents: read

jobs:
  build-sign-release:
    runs-on: ubuntu-latest
    permissions:
      contents: write      # vytvorenie vydania
      id-token: write      # keyless podpis cez OIDC
      attestations: write  # voliteľné: atestácia pôvodu
    steps:
      - uses: actions/checkout@<PLNY_HASH_COMMITU>   # v4
      - uses: actions/setup-go@<PLNY_HASH_COMMITU>    # v5
        with:
          go-version-file: go.mod

      - name: Build
        run: |
          mkdir dist
          CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -trimpath -o dist/mytool-linux-amd64 ./cmd/mytool
          (cd dist && sha256sum mytool-* > SHA256SUMS)

      - uses: sigstore/cosign-installer@<PLNY_HASH_COMMITU>   # v3

      - name: Podpis artefaktov
        run: |
          for f in $(ls dist); do
            cosign sign-blob --yes --bundle "dist/$f.bundle" "dist/$f"
          done

      - uses: actions/attest-build-provenance@<PLNY_HASH_COMMITU>   # voliteľné
        with:
          subject-path: "dist/mytool-*"

      - name: Vydanie (koncept, potom zverejnenie)
        env:
          GH_TOKEN: ${{ github.token }}
        run: |
          gh release create "$GITHUB_REF_NAME" dist/* --draft --title "$GITHUB_REF_NAME" --generate-notes
          gh release edit "$GITHUB_REF_NAME" --draft=false

Hodnoty ako mytool a cesty uprav podľa projektu.

Obrana 3: Over podpis pred spustením

Stiahnutie a spustenie nástroja z internetu bez kontroly je to isté, čo viedlo k incidentu. Nasledujúci skript stiahne binárku aj jej podpisový balík, overí ich a až potom nainštaluje:

#!/usr/bin/env bash
set -euo pipefail

REPO="${REPO:?nastav napr. REPO=moja-org/moj-nastroj}"
TAG="${1:?verzia, napr. v1.2.3}"
ASSET="${2:?názov súboru, napr. mytool-linux-amd64}"

command -v cosign >/dev/null || { echo "Chýba cosign." >&2; exit 1; }

tmp="$(mktemp -d)"
trap 'rm -rf "$tmp"' EXIT
base="https://github.com/${REPO}/releases/download/${TAG}"

curl -fsSL -o "$tmp/$ASSET" "$base/$ASSET"
curl -fsSL -o "$tmp/$ASSET.bundle" "$base/$ASSET.bundle"

cosign verify-blob 
  --bundle "$tmp/$ASSET.bundle" 
  --certificate-identity "https://github.com/${REPO}/.github/workflows/release.yml@refs/tags/${TAG}" 
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com" 
  "$tmp/$ASSET"

mkdir -p "${INSTALL_DIR:-$HOME/.local/bin}"
install -m 0755 "$tmp/$ASSET" "${INSTALL_DIR:-$HOME/.local/bin}/${ASSET%%-*}"
echo "Overené a nainštalované."

Ak overenie zlyhá, skript sa ukončí a nič sa nenainštaluje. Ide o samostatný skript, nie o git hook. Zavesiť ho môžeš do inštalačného postupu, CI alebo do správcu balíkov v tvojej organizácii.

Čo to nevyrieši

• Prispievateľ s právom zápisu do repozitára môže teoreticky spustiť workflow aj na novej značke. Obmedz to ochranou značiek (rulesets), povinnou kontrolou zmien workflowov a prostredím s povinným schválením.
• Podpis nepomôže tým, ktorí súbor nikdy nekontrolujú. Overovanie musí byť súčasťou inštalácie, nie nepovinným krokom.
• Tým, ktorí si už škodlivú binárku stiahli, nepomôže ani aktualizácia. Zbehnutá kópia kľúčov je už von.

Ak si bol zasiahnutý

• Skontroluj, či si v spomínanom okne (19. októbra 2026, 14:47 až 16:21 stredoeurópskeho letného času) nainštaloval alebo aktualizoval ovhcloud-cli a spustil ho. Platí to aj pre CI pipeline.
• Ak áno, binárku odstráň, nainštaluj čistú verziu v0.16.0 alebo novšiu a považuj všetky tajomstvá na tom stroji za kompromitované.
• Zmeň prístupové kľúče, tokeny, SSH kľúče a heslá uložené na disku. Podľa zakladateľa OVHcloud samotná aktualizácia nástroja kľúč, ktorý sa už skopíroval, neodvolá.

Čo si z toho odniesť

Útok nepotreboval prelomiť šifrovanie ani build pipeline. Stačilo, že vydania sa dali meniť a že sťahujúci nič nekontroloval. Dve opatrenia, ktoré to uzavrú, sú nezmeniteľné vydania na strane vydavateľa a overovanie podpisu na strane používateľa. Ani jedno nie je zložité. Obe treba zapnúť skôr, než niekto použije ukradnutý prístup.