Compania Google a lansat cadrul SLSA (Supply-chain Levels for Software Artifacts), care sintetizează experiența existentă în protejarea infrastructurii de dezvoltare împotriva atacurilor care au loc în timpul scrierii codului, testării, construirii și distribuției produsului.
Procesele de dezvoltare devin din ce în ce mai complexe și depind de instrumente externe, ceea ce creează condiții favorabile pentru promovarea atacurilor care nu se concentrează pe identificarea și exploatarea vulnerabilităților în produsul final, ci pe compromiterea procesului de dezvoltare (atacuri de tip „supply chain”, de obicei țintind introducerea modificărilor malițioase în timpul scrierii codului, înlocuirea componentelor distribuite și a dependențelor).
Cadrul ia în considerare 8 tipuri de atacuri legate de amenințările de introducere a modificărilor malițioase în etapa de dezvoltare a codului, construcție, testare și distribuție a produsului.
- A. Introducerea în codul sursă a modificărilor care conțin backdoor-uri sau erori ascunse, care conduc la vulnerabilități.
Exemplul unui atac: „Hypocrite Commits” — încercarea de a promova patch-uri vulnerabile în nucleul Linux.
Metoda de protecție propusă: revizuirea independentă a fiecărei modificări de către doi dezvoltatori.
- B. Compromiterea platformei de gestionare a codului sursă.
Exemplul unui atac: introducerea de commit-uri malițioase cu backdoor în depozitul Git al proiectului PHP după scurgerea parolelor dezvoltatorilor.
Metoda de protecție propusă: creșterea securității platformei de gestionare a codului (în cazul PHP, atacul a fost realizat printr-o interfață HTTPS puțin utilizată, care permitea trimiterea modificărilor la autentificare prin parolă fără verificarea cheii SSH, având în vedere că pentru hash-ul parolilor a fost utilizat MD5 nesigur).
- C. Introducerea modificărilor în etapa de transmitere a codului către sistemul de construire sau integrarea continuă (se construiește un cod care nu corespunde cu codul din depozit).
Exemplul unui atac: introducerea unui backdoor în Webmin prin modificarea infrastructurii de construire, care a dus la utilizarea fișierelor cu cod diferite de cele din depozit.
Metoda de protecție propusă: verificarea integrității și identificarea sursei de proveniență a codului pe sistemul de construire. server.
- D. Compromiterea platformei de construire.
Exemplu de atac: atacul SolarWinds, în cadrul căruia, în etapa de construire, a fost asigurat un backdoor în produsul SolarWinds Orion.
Metoda de protecție propusă: implementarea unor măsuri extinse de securitate pentru platforma de construire.
- E. Promovarea codului malițios prin dependențe de calitate scăzută.
Exemplu de atac: inserarea unui backdoor în biblioteca populară event-stream, prin adăugarea unei dependențe inofensive, cu ulterior includerea în una dintre actualizările acestei dependențe a codului malițios (modificarea malițioasă nu a fost reflectată în depozitul git, fiind prezentă doar în pachetul MNP final).
Metoda de protecție propusă: aplicarea recursivă a cerințelor SLSA pentru toate dependențele (în cazul event-stream, verificarea ar fi evidențiat construcția codului care nu se conforma cu conținutul depozitului principal Git).
- F. Încărcarea artefactelor care nu au fost create în sistemul CI/CD.
Exemplu de atac: adăugarea codului malițios în scriptul CodeCov, care permitea atacatorilor să extragă informații stocate în mediile sistemelor de integrare continuă ale clienților.
Metoda de protecție propusă: monitorizarea sursei și integrității artefactelor (în cazul CodeCov, ar fi putut fi identificat faptul că scriptul Bash Uploader livrat de site-ul codecov.io nu corespunde codului din depozitul proiectului).
- G. Compromiterea depozitului de pachete.
Exemplu de atac: cercetătorii au reușit să desfășoare oglinzi ale unor depozite populare de pachete cu scopul de a răspândi prin acestea pachete malițioase.
Metoda de protecție propusă: verificarea că artefactele distribuite au fost construite din sursele enunțate.
- H. Introducerea în confuzie a utilizatorului pentru a instala un pachet greșit.
Exemplu de atac: utilizarea type squatting (NPM, RubyGems, PyPI) pentru a plasa în depozite pachete care seamănă în scriere cu aplicații populare (de exemplu, coffe-script în loc de coffee-script).
Pentru a bloca amenințările marcate, SLSA oferă un set de recomandări, precum și instrumente pentru automatizarea creării de metadate pentru audit. SLSA generalizează metodele tipice de atac și introduce conceptul de niveluri de protecție. Fiecare nivel impune cerințe specifice pentru infrastructură, permițând garantarea integrității artifactelor utilizate în dezvoltare. Cu cât nivelul SLSA suportat este mai ridicat, cu atât mai multe măsuri de protecție sunt implementate și cu atât infrastructura este mai bine protejată împotriva atacurilor tipice.
- SLSA 1 — cere ca procesul de construire să fie complet automatizat și să genereze metadate („provenance”) despre cum au fost construite artifactele, inclusiv informații despre codurile sursă, dependențe și procesul de construire (pentru GitHub Actions a fost propus un exemplu de generator de metadate pentru audit). SLSA 1 nu include elemente de protecție împotriva modificărilor malițioase, ci doar identifică codul într-un mod simplu și oferă metadate pentru gestionarea vulnerabilităților și analiza riscurilor.
- SLSA 2 — extinde primul nivel prin cerința de utilizare a unui sistem de gestionare a versiunilor și a serviciilor de construire care generează metadate autentificate. Aplicarea SLSA 2 permite urmărirea originii codului și previne modificările neautorizate ale codului, în cazul utilizării serviciilor de construire de încredere.
- SLSA 3 — confirmă că codurile sursă și platforma de construire respectă cerințele standardelor care garantează posibilitatea desfășurării unui audit al codului și asigurarea integrității metadatelor furnizate. Se consideră că auditorii pot certifica platformele în funcție de conformitatea cu cerințele standardelor.
- SLSA 4 — nivelul maxim, care completează nivelurile anterioare cu următoarele cerințe:
- Recenzarea obligatorie a tuturor modificărilor de către doi dezvoltatori diferiți.
- Toți pașii de construire, codul și dependențele trebuie declarate complet, toate dependențele trebuie extrase și verificate individual, iar procesul de construire trebuie să se desfășoare fără acces la rețea.
- Aplicarea procesului de construire repetabil — capacitatea de a repeta procesul de construire cu propriile resurse și de a verifica că fișierul executabil a fost construit din codurile sursă furnizate.
Sursa: opennet.ro
