Versiuni ale OVHcloud CLI, deturnate pentru a livra un program care fură secrete

Luni, 19 octombrie, timp de aproximativ o oră și jumătate, oricine a instalat sau actualizat de pe GitHub utilitarul în linie de comandă OVHcloud poate să fi primit un binar malițios în locul celui legitim. Un atacator care controla contul de GitHub al unui contribuitor a înlocuit arhivele de descărcare din cinci versiuni mai vechi. Noile fișiere conțineau un build conceput să colecteze secretele de pe mașina pe care rulează. Codul sursă, tag-urile de versiune și pipeline-ul de build al OVHcloud nu au fost atinse, ci doar fișierele atașate versiunilor.

Ce s-a întâmplat

Între 12:47 și 14:21 UTC, arhivele atașate versiunilor v0.11.0 – v0.15.0 ale proiectului ovhcloud-cli au fost înlocuite. Platformele afectate: macOS (x86_64 și arm64), Linux (x86_64 și arm64) și Windows (x86_64). Atacatorul a înlocuit și fișierul checksums.txt al fiecărei versiuni, astfel încât hash-urile publicate se potriveau cu fișierele malițioase. Asta anulează orice verificare care se bazează pe fișierul de checksum livrat lângă binar.

Build-ul fals pare să fi fost compilat dintr-un commit ulterior, fără tag, și încărcat manual. Nu a trecut niciodată prin workflow-ul oficial de release al OVHcloud. Build-urile Linux i386, Windows i386, Windows arm64 și WebAssembly nu au fost modificate, iar v0.10.0 este considerată curată.

Înlocuirea a fost descoperită de un client al cărui job de CI fixa (pin) hash-ul SHA-256 al arhivei Linux arm64 și a început brusc să eșueze. Clientul a deschis un issue public pe GitHub. OVHcloud a șters fișierele înlocuite după aproximativ jumătate de oră, iar în aceeași seară a publicat versiunea curată v0.16.0, ca release imutabil, cu tag semnat și atestare de release.

Ați fost expus?

Este posibil să fi primit un fișier compromis dacă, în acel interval și pe una dintre platformele afectate:

• ați rulat scriptul oficial de instalare curl … | sh, care descarcă ultima arhivă fără să verifice hash-ul;
• ați descărcat manual o arhivă din pagina de release a versiunilor v0.11.0–v0.15.0;
• ați rulat un job de CI sau un pas de build care descarcă arhiva de pe GitHub fără un hash fixat;
• ați rulat comanda de upgrade integrată în CLI, de pe v0.12.0–v0.14.0, pe macOS sau Linux, unde utilitarul fusese instalat prin script sau manual.

Nu ați fost expus dacă ați instalat prin Homebrew (cask-ul fixează hash-ul SHA-256 original și ar fi refuzat fișierul înlocuit), ați folosit go install sau ați compilat din sursă, ați folosit imaginea Docker (actualizată ultima dată în septembrie) ori ați instalat înainte de 12:47 UTC și nu ați actualizat în acel interval.

Cum recunoașteți build-ul compromis

Fără a-l executa, rulați go version -m pe binar. Build-ul înlocuit afișează:

• o pseudo-versiune în linia de modul: v0.15.1-0.20261013083505-5ead8ef9b43d+dirty;
• commit-ul înregistrat 5ead8ef în loc de 760fd72, commit-ul la care indică tag-ul v0.15.0;
• o linie -ldflags="-s -w", care nu apare în release-urile autentice OVHcloud.

Atenție: +dirty sau vcs.modified=true singure nu indică o compromitere, pentru că și build-ul curat v0.16.0 le afișează.

Singurul hash publicat pentru un fișier înlocuit este cel al arhivei v0.15.0 Linux arm64:

• Malițios: 3833daffcaaaab27e4e0e0833240ffcb1df8df648f4ec0bc4a75c176e28933cb
• Original: 5c2beb56e6d83a4b426565a1557791ef759316abcc4effb38dd627c90aeb80e0

Nu rulați un binar suspect doar ca să vedeți ce versiune raportează.

De ce contează

Nu a fost compromis un server de build și nici codul sursă, ci stratul de fișiere atașate release-urilor. Pe GitHub, oricine are drept de scriere poate șterge și reîncărca fișierele unui release cu aceleași nume, iar URL-ul de descărcare rămâne neschimbat, cu excepția cazului în care este activată opțiunea release immutability. Funcția este disponibilă general din octombrie 2025, dar protejează doar release-urile create după activare. Pe acest repository nu era activată. OVHcloud a activat-o între timp.

Incidentul arată cât de fragile sunt instalările de tip curl | sh și descărcările nefixate din CI. Singurul control care a funcționat a fost hash-ul fixat de un client.

Rămân necunoscute importante. OVHcloud nu a spus ce citește binarul malițios, unde trimite datele sau câte copii au fost descărcate. Nicio arhivă înlocuită nu a fost analizată public, iar compania a promis un raport post-incident detaliat. Cercetătorii de la OpenSourceMalware au legat contul deturnat de campania GlassWorm, care ascunde cod în caractere Unicode invizibile și își descarcă etapa următoare din câmpul memo al tranzacțiilor Solana. Totuși, ei descriu această legătură drept o deducție proprie. Nimic din binarul din octombrie nu a fost legat direct de GlassWorm, așa că atribuirea trebuie tratată ca neconfirmată.

Ce trebuie făcut

1. Rotiți întâi secretele. Dacă o mașină a rulat un build compromis sau nu puteți exclude asta, tratați toate secretele accesibile pe acea mașină ca fiind expuse. Asta include cheile API OVHcloud din ~/.ovh.conf și variabilele de mediu, dar și token-urile cloud, cheile SSH, credențialele Git și orice altceva de pe disc. Faceți rotirea de pe o altă mașină, curată.
2. Înlocuiți binarul cu v0.16.0. Actualizarea nu revocă o cheie deja copiată, de aceea rotirea vine prima.
3. Verificați descărcările cu atestarea release-ului: gh release verify-asset v0.16.0 <FIȘIER>.
4. Fixați hash-urile în CI. Descărcați binarele terțe după un SHA-256 cunoscut, stocat de voi, nu după un fișier de checksum aflat lângă descărcare.
5. Activați release immutability pe propriile repository-uri GitHub și revizuiți cine are drept de scriere, inclusiv contribuitorii externi.

Descărcările nefixate, instalatoarele curl | sh și pașii de CI care acceptă orice returnează un URL sunt ușor de ratat într-un codebase mare. Code review-ul asistat de AI realizat de echipa noastră semnalează aceste tipare în pipeline-uri și scripturi de build, astfel încât un singur fișier înlocuit să nu ajungă neobservat pe mașinile dezvoltatorilor voștri.

Credit: subiectul a fost relatat inițial de The Hacker News. Acesta este rezumatul și analiza noastră.