Google pakkus välja SLSA, et kaitsta arendusprotsessi pahatahtlike muudatuste eest

Google esitles SLSA (Supply-chain Levels for Software Artifacts) raamistikku, mis üldistab olemasolevaid kogemusi arendusinfrastruktuuri kaitsmisel rünnakute eest, mis toimuvad koodi kirjutamise, testimise, koostamise ja toote levitamise etappidel.

Arendusprotsessid muutuvad üha keerukamaks ja sõltuvamaks kolmandate osapoolte tööriistadest, mis loob soodsa keskkonna rünnakute edendamiseks, mis ei keskendu lõpp-produkti haavatavuste avastamisele ja ärakasutamisele, vaid arendusprotsessi enda kompromiteerimisele (supply chain rünnakud, mis on tavaliselt suunatud pahatahtlike muudatuste sisestamisele koodi kirjutamise etappides, levitatavate komponentide ja sõltuvuste asendamisele).

Raamistik arvestab 8 tüüpi rünnakutega, mis on seotud pahatahtlike muudatuste tegemise ohtudega koodi arendamise, koostamise, testimise ja toote levitamise etappidel.

• A. Muudatuste lisamine lähtekoodile, mis sisaldavad tagavarasid või varjatud vigu, mis viivad haavatavusteni.

  Rünnaku näide: 'Hypocrite Commits' — katse edastada Linuxi tuumale haavatavustega patše.

  Pakutav kaitsemeetod: iga muudatuse sõltumatu ülevaatus kahe arendaja poolt.

• B. Allika koodihalduse platformi kompromiteerimine.

  Rünnakute näide: pahatahtlike commit'ide sisestamine PHP projekti Git-repositooriumisse tagauksega pärast arendajate paroolide leket.

  Pakutav kaitsemeetod: koodihalduse platvormi kaitse suurendamine (PHP puhul toimus rünnak vähe kasutatud HTTPS-liidese kaudu, mis lubas muudatusi saata parooliga sisselogimisel ilma SSH-võtme kontrollita, samas kui paroolide hash'imiseks kasutati usaldusväärset MD5-d).

• C. Muudatuste tegemine koodi edastamisel koostamis- või pideva integreerimise süsteemi (täidab koodi, mis ei vasta repositooriumi koodile).

  Rünnakute näide: tagaukse sisestamine Webmin'i, tehes muudatusi koostamisstruktuuris, mis viis sisse failide kasutamiseni, mis erinevad repositooriumi failidest.

  Pakutav kaitsemeetod: Koodi terviklikkuse kontrollimine ja allika tuvastamine, kust kood on saadud koostamise käigus. serveril.

• D. Koostamisplatvormi kompromiteerimine.

  Rünnaku näide: SolarWinds'i rünnak, mille käigus tagati ründe ajal tagaukse sisestamine tootes SolarWinds Orion.

  Ettepanek kaitsemeetod: täiustatud turvameetmete rakendamine ehitusplatvormil.

• E. Kahjuliku koodi levitamine halva kvaliteediga sõltuvuste kaudu.

  Rünnaku näide: tagaukse sisestamine populaarsetesse event-stream teekidesse, lisades kahjutuna näiva sõltuvuse, mis sisaldas hiljem selle sõltuvuse ühes uuenduses kahjulikku koodi (kahjulik muudatus ei kajastunud git-repositooriumis ning oli olemas vaid valmis MNP-pakendis).

  Ettepanek kaitsemeetod: SLSA nõuete retsidiivne rakendamine kõikidele sõltuvustele (event-stream'i puhul oleks kontroll tuvastanud, et koodi ehitus ei vasta põhigiti-repositooriumi sisule).

• F. Artefaktide laadimine, mida ei ole loodud CI/CD süsteemis.

  Rünnaku näide: kahjuliku koodi lisamine CodeCov skripti, mis võimaldas ründajatel hankida teavet, mis on salvestatud klientide pideva integratsiooni keskkondades.

  Pakutud kaitsemeetod: allika ja artefaktide terviklikkuse kontroll (CodeCov puhul võib olla avastatud, et codecov.io veebisaidilt edastatav Bash Uploader skript ei vasta projekti hoidla koodile).

• G. Paki hoidla kompromiteerimine.

  Rünnakute näide: teadlased suutsid välja tuua peegeldusi mõnest populaarsemast pakihoidlast, et levitada nende kaudu pahavara pakette.

  Pakutud kaitsemeetod: kontroll, et levitatavad artefaktid on kokku pandud deklareeritud lähtekoodidest.

• H. Kasutaja segadusse ajamine vale paketi installimiseks.

  Rünnakute näide: tüüpide naljakas kirjutamine (NPM, RubyGems, PyPI) pakihoidlates, et paigutada sinna paketid, mis sarnanevad kirjutamise poolest populaarsetele rakendustele (näiteks coffe-script asemel coffee-script).

Ahnub SLSA pakub soovituste komplekti ja tööriistu, et automatiseerida auditiks vajalike metaandmete loomist, et blokeerida tuvastatud ohud. SLSA kogub kokku ründeviisid ja tutvustab kaitsetasemeid. Iga tase esitab kindlad nõuded infrastruktuurile, mis tagab arendusprotsessis kasutatavate artefaktide terviklikkuse. Mida kõrgem on toetatav SLSA tase, seda rohkem kaitsemeetmeid on rakendatud ja seda paremini on infrastruktuur kaitstud tüüpiliste rünnakute eest.

• SLSA 1 — nõuab, et ehitusprotsess oleks täielikult automatiseeritud ja genereeriks metaandmed („provenance”) selle kohta, kuidas artefakte koguti, sealhulgas teavet lähtekoodide, sõltuvuste ja ehitamisprotsessi kohta (GitHubi tegevuste jaoks on ette nähtud näidis auditingu metaandmete generaator). SLSA 1 ei sisalda kaitserežiimide elemente, et vältida pahatahtlikke muudatusi, vaid võimaldab lihtsalt tuvastada koodi ja esitab metaandmed haavatavuste haldamiseks ja riskide analüüsiks.
• SLSA 2 — laiendab esimest taset nõudega kasutada versioonihaldussüsteeme ja ehitusteenuseid, mis genereerivad autentitud metaandmeid. SLSA 2 rakendamine võimaldab jälgida koodi päritolu ja takistab volitamata muudatuste tegemist koodis, kui kasutatakse usaldusväärseid ehitusteenuseid.
• SLSA 3 — kinnitab, et allikakoodid ja ehitusplatvorm vastavad standardite nõuetele, mis tagavad koodi auditi võimaluse ja tagavad esitatud metaandmete terviklikkuse. Eeldatakse, et auditeerijad saavad sertifitseerida platvorme standardite nõuetele vastavuse osas.
• SLSA 4 — kõrgeim tase, mis täiendavad eelnevaid tasemeid järgmiste nõuetega:
  • Kõigi muudatuste kohustuslik ülevaatus kahe erineva arendaja poolt.
  • Kõik ehitusetapid, kood ja sõltuvused peavad olema täielikult deklareeritud, kõik sõltuvused peavad olema eraldi välja tõmmatud ja kontrollitud, ning ehitusprotsess peab toimuma ilma võrgu ligipääsuta.
  • Kordusprotsessi rakendamine — võimalus korrata koostamisprotsessi iseseisvalt ja veenduda, et täitmisfail on loodud esitatud lähtekoodidest.
  
  
  Allikas: opennet.ru