Gebrek oan ferzje-pinning en ôfhinklikheidsbetizing

Yn softwareûntwikkeling binne wy ​​ôfhinklik fan sawol eigen as tredde-partij komponinten of artefakten. In fleksibel ôfhinklikheidsbehear is essensjeel foar moderne software. Pakketbehearders lykas NPM, Maven, pip or NuGet wurde faak brûkt om softwareôfhinklikheden oan te jaan. Dizze ark binne ûntworpen mei gemak en gebrûksfreonlikens yn gedachten, net feiligens.

 

It probleem

It probleem is dat fleksibiliteit en gebrûksgemak foar ûntwikkelders de minne jonges oansprekt, dy't software-ôfhinklikheden sjogge as ûnwjersteanbere sjarme foar har bedriuw. It resultaat: minne akteurs folgen alle mooglike oanfalspaden dy't hjir werjûn wurde. Boarne: "Backstabber's Knife Collection: A Review of Open Source Software Supply Chain Attacks"

Yn dizze post sille wy ús rjochtsje op it gebrûk fan iepen ferzjeferklearrings, yn 'e sin dat de ynladen ferzje net fêst is, mar ta in bepaald berik hearre moat. By de bou wurdt de heechste besteande ferzje dy't kompatibel is mei it oantsjutte ferzjeberik keazen en ynladen/ynstallearre troch de pakketbehearder.

Litte wy iepen ferklearrings yn ôfhinklikheidsferklearrings foar ferskate pakketbehearders yllustrearje:

• • NPM: pakket.json

{

 

   ...

   "ôfhinklikheden": {
      ...
      "akseptearret": ">=1.3.8",
      "lodash": "~4.16.0",
      ...
   },
   ...
}

De grutste besteande ferzje net leger as 1.3.8 foar it accepts-pakket sil ynstalleare wurde, lykas de grutste 'patch'-update foar lodash yn it 4.16.x-berik.

• • Maven: pom.xml

...

...

     commons-io
     commons-io
     FRIJLOPING

...

...

De lêste beskikbere ferzje foar commons-io (jar-bestân) sil tafoege wurde as ôfhinklikens.

• • Pip: setup.py

...
opsette(
    ...
    install_requires=['peppercorn', 'launchpadlib'],
    ...
)
...

Sokke iepen ferzjeskema's hawwe in goede en in minne kant. It goede is dat nijere ferzjes gewoanwei befetsje funksjonele en kwaliteitsferbetterings, bugfixes en feiligenspatches, dy't automatysk opwurdearre wurde. Tink derom dat foar de measte echte projekten, fixes net weromportearre wurde nei foarige lytse releases, útsein miskien foar katastrofale feiligenskwetsberens. Iepen ferzjes binne ek goed foar gebrûk yn bibleteken, om it oantal ferzjes te ferminderjen dat ynstalleare wurde moat as alle ôfhinklikheden oplost binne.

Mar iepen ferzjeberik hat in minne kant. Jo witte net krekt hokker ferzjes ynstalleare wurde sille by de bou, en builds binne net werhelleber. En der is ek in tsjuster kant mei iepen ferzjes. As in minne akteur deryn slagget om in kwea-aardige komponint yn 'e iepenbiere repository te publisearjen mei in hege ferzje dy't kompatibel is mei jo iepen berik, sil jo folgjende build de kwea-aardige komponint befetsje, miskien sels malware útfiere yn ynstallaasjeskripts dy't automatysk útfierd wurde kinne. It fertsjusterjen fan 'e oanfalslading is in keunst.

Dit is bekend as de Gebrek oan ferzje-pinnen útjefte.

Minne akteurs besykje altyd kweade ferzjes fan populêre iepen boarne pakketten te pleatsen. Se kinne tagong krije ta de kaaien foar pakketrepositories yn in geheime lek; se brûke faak sosjale technyk of ferbergje in nestele kweade ôfhinklikens yn in skynber nuttich pull requestSels in pear auteurs beslute op in dei sels dat de wrâld net earlik is en biten har kliïnten mei protestware yn harren eigen pakketten!

Stel jo no foar dat jo wurkje foar in organisaasje dy't ynterne komponinten plus iepen boarne komponinten brûkt.
As in minne akteur de namme fan sokke ynterne komponinten wit, kin hy/sy in komponint mei deselde namme publisearje yn 'e iepenbiere repository. In protte pakketbehearders krije earst de iepenbiere komponinten, en as de ferzje goed keazen is en de ferzje yn jo ferklearre ôfhinklikens iepen is, boem! Dit probleem wurdt neamd Ofhinklikensferwarring.

Litte wy in foarbyld sjen litte. Stel dat wy yn ús NPM-projekt in ôfhinklikens hawwe fan in privee komponint:

• • NPM: pakket.json

{
  "namme": "myn-projekt",

 

  ...
  "ôfhinklikheden": {

    ...
    "myn-privee-ôfdieling": ">=1.0.0",

    ...

   }

   ...

}

 

De oanfaller kin in hege grutte ferzje fan my-private-dep oanmeitsje (lykas 99.0.0) en publisearje yn 'e iepenbiere npm-repository, mei syn eigen falske akkount (de oanfaller hoecht neat te dwaan mei myn organisaasje). De NPM-pakketbehearder sil de kwea-aardige ôfhinklikens ynstallearje, faak mei ferneatigjende gefolgen.

De oplossing

Om dizze problemen yn ús softwarebouproses te foarkommen, moatte wy strange noarmen folgje oer hoe't wy komponintferzjes ferklearje moatte, dy't ôfhinklik binne fan 'e brûkte technology. It wichtige is dat in spesifike ferzje fan in pakket, ienris publisearre yn in repository, ûnferoarlik wêze moat (om te foarkommen dat ôfhinkliken brekke, net allinich om feiligensredenen).

It algemiene idee is om te fiksearjen (pin) ferzjes, altyd kontrolearjend dat de fêste ferzjes fan 'e komponinten (ynklusyf ALLE transitive ôfhinklikheden) frij binne fan malware, en dit is mooglik tanksij de slútbestannen dat in protte pakketbehearders oanbiede. Litte wy sjen hoe ferzje-pinnen wurket foar ferskate pakketbehearders. D'r is in delikate ôfwaging tusken faak ferzje-updates foar it reparearjen fan bekende kwetsberheden en ferzje fêstmeitsje om net-deterministyske builds en potinsjele oanfallen fan 'e supply chain te foarkommen.

• • NPM:
    De npm- of yarn-pakketbehearders brûke ferskillende lockfiles (npm-shrinkwrap.json / package-lock.json of yarn.lock, respektivelik) dy't fêste ferzjes listje foar alle ôfhinklikheden, direkt en yndirekt. De lockfiles moatte ûnder ferzjekontrôle stean, oars kinne oare ûntwikkelders / buildknooppunten einigje mei ferskillende ferzjes. Foarkom npm-ynstallaasje, útsein as jo yn ûntwikkeling de ôfhinklikheden moatte bywurkje (bygelyks om feiligensreparaasjes te ynstallearjen). Brûk de mear deterministyske npm ci (Clean Install) yn 't algemien, sadat de pakketbehearder it lockfile sil brûke of mei in flater sil einigje as der gjin lockfile is, of as it net oerienkomt mei de package.json. As de neamde ferzjes kontrolearre binne op malware, soarget it lockfile derfoar dat der neat slims bart by de boutiid.

    Foar ynterne komponinten is it oan te rieden om in NPM-berik beheard troch de organisaasje (lykas @myorg), en brûk dy scope yn 'e ôfhinklikens (lykas @myorg/my-private-dep), dy't allinich privee sichtberens hawwe kin. Dit blokkearret ôfhinklikensferwarring oanfallen, om't allinich leden fan 'e organisaasje mei skriuwtagong pakketten ûnder sa'n berik publisearje kinne.

• • Maven:
    Maven / Gradle hawwe gjin lockfiles (mar sjoch dit StackOverflow-artikel).

    Ferzjeberiken wurde net safolle brûkt mei Maven/Gradle as mei oare ekosystemen. Foarkom gewoan ferzjeberik en LÊSTE of RELEASE meta-ferzjes. Yndirekte ferzjes moatte ek kontrolearre wurde. De Ferzjes Maven Plugin is in moai ark foar ferzjekontrôle.

    Tink derom dat Maven altyd it konsept fan organisaasjeberik hie (it groupId-diel fan 'e ôfhinklikens), en ôfhinklikheidsbetizing liket hielendal gjin probleem te wêzen foar dat ekosysteem.

• • Pip:
    Yn Python binne der ferskate ark foar it omgean mei lockfiles:

    - pipenv, wat in Pipfile.lock lockfile genereart.
    - poëzij, dy't poetry.lock genereart.
    - pip befrieze, kommando dat in requirements.txt genereart dat as in lockfile fungearret. Kontrolearje oft alle ôfhinklikheden fêste ferzjes brûke mei de == operator. Dan brûkt pip install -r requirements.txt de fêste ôfhinklikheden.

Tink derom dat de hjirboppe neamde lockfiles ûnder ferzjebehear moatte stean, en dat it keazen boukommando it lockfile brûke moat.

De gewoane pakketrepository dy't brûkt wurdt mei pip (PyPI) hat gjin nammejouwingsscopes, en it is kwetsber foar oanfallen fan ôfhinklikensbetizing. Ferwarring oer ôfhinklikens yn it Python-ekosysteem foarkomme is net maklik, en guon auteurs advisearje om in ynterne repository te brûken om te fungearjen as in proxy foar iepenbiere ôfhinklikheden dy't fan PyPI ophelle binne, mar earst de privee ôfhinklikheden fan 'e ynterne repository te nimmen (-index-url moat nei de ynterne repository wize, net PyPI, en –extra-index- url moat fuorthelle wurde).

Guon echte oanfallen

Getcookies-oanfalDe akteur dustin87 hat in yndirekte ôfhinklikens tafoege oan it populêre npm mailparser-pakket fan in kwea-aardich pakket mei in RCE-efterdoar (gCOMMANDhDATAi):

JSON.stringify(req.headers).replace(/g([a-f0-9]{4})h((?:[a-f0-9]{2})+)i/gi, (o, p, v) => {})

Nettsjinsteande dat it ôfskreaun is (gjin resinsinten!), krige mailparser noch altyd sawat 64,000 wyklikse downloads. Dit wie in gefal fan in hast-misse-oanfal, om't de RCE eins net útoefene waard.cised.

NPM publisearre dit post mei details oer de getcookies-oanfal.

Ofhinklikensferwarring:

Alex Birsan ûntduts yn 2021 it probleem fan ôfhinklikheidsbetizing en publisearre in berjocht mei de titel "Hoe't ik Apple, Microsoft en tsientallen oare bedriuwen hackte".

Tink derom dat foar npm it organisaasjeberik lykas @myorg reservearre wurde moat, en ynterne pakketten moatte oanpast wurde om it berik te brûken.

Mei pip hat it mienskiplike iepenbiere register PyPI gjin scopes/nammeromten. Elk privee pakket kin in iepenbier pakket squat hawwe mei deselde namme as it ynterne pakket, mar leech, en miskien in flater generearje as it brûkt wurdt, sadat it identifisearre wurde kin as it per ongelok ophelle wurdt.

Node-ipc:

De eigener fan it pakket ynjektearre, doe't de oarloch tusken Ruslân en Oekraïne begûn, kweade koade om willekeurige bestannen te ferwiderjen, doe't it ynstalleare waard op Russyske en Wyt-Russyske hosts. It bestân ssl-geospec.js makke sa'n geografysk ûnderskied:

Nijsgjirrich genôch brûkten oare pakketten iepen ferzjes foar de node-ipc-ôfhinklikens, lykas it populêre Vue.js-raamwurk, en de ûnderhâlders krigen in driuwend berop om de node-ipc-ôfhinklikens fêst te pinnen op in feilige ferzje.

Dit berjocht befettet mear details op dizze sabotaazje, dy't in stap fierder giet as oare Protestware problemen.

 

Oanlieding Oanmerkings

Iepen ferzjes moatte nea brûkt wurde yn konsolidearre softwareprojekten. Se meitsje builds net-reprodusearber, en oanfallers kinne se eksploitearje en slagje om malware te ynjeksjearjen fia oanfallen op 'e ôfhinklikheidsbeammen lykas de neamde ôfhinklikheidsbetizing.

Miskonfiguraasjes lykas iepen ferzjes, gebrek oan ferzje-pinnen, of ynterne komponinten sûnder berik moat foarkommen wurde. It earste ding is om sokke problemen te detektearjen, miskien sels de bou te blokkearjen as se fûn wurde, en in protokol foar aksje te standerdisearjen.

Automatyske deteksje fan gebreken en ferkearde konfiguraasjes yn ôfhinklikheden, rapportaazje fan fertochte ôfhinklikheden dy't kwetsber kinne wêze foar spesifike oanfallen fan 'e supply chain lykas ôfhinklikensferwarring, allegear mei aksjebere reparaasjemiddels, is ien fan 'e wichtichste doelen fan 'e Xygeni-platfoarm.

Om mear te lêzen

Ohm M., Plate H., Sykosch A., Meier M.: “Backstabber's Knife Collection: In oersjoch fan oanfallen op supply chain fan iepen boarne software”. DIMVA 2020. Lecture Notes in Computer Science, vol 12223. Springer – 2020 (boarne fan 'e figuer fan 'e beam fan 'e ôfhinklikheidsoanfal.)

@adam-npm: “Rapportearre kweade module: getcookies". npm Blog (argyfearre) - 2 maaie 2018.

Alex Birsan: "Hoe't ik Apple, Microsoft en tsientallen oare bedriuwen hackte". Medium – 9 febrewaris 2021.

Ax Sharma: "GRUTTE sabotaazje: Ferneamd npm-pakket wisket bestannen út protest tsjin oarloch yn Oekraïne"Piepenkompjûter - 17 maart 2022"