Mangel u Versiounspinning a Verwirrung iwwer Ofhängegkeeten

An der Softwareentwécklung si mir souwuel vun eegenen wéi och vun Drëttubidder Komponenten oder Artefakten ofhängeg. E flexibelt Ofhängegkeetsmanagement ass essentiell fir modern Software. Package Manager wéi NPM, Maven, Pip or NuGet ginn dacks benotzt fir Softwareofhängegkeeten ze spezifizéieren. Dës Tools goufen mat Komfort a Benotzerfrëndlechkeet am Kapp entwéckelt, net mat Sécherheet.

De Problem

De Problem ass, datt Flexibilitéit a Benotzerfrëndlechkeet fir Entwéckler déi Béiser uspriechen, déi Softwareofhängegkeeten als onwiderstehlech Charme fir hiert Geschäft gesinn. D'Resultat: Béis Akteuren hunn all méiglech Attackweeër gefollegt, déi hei gewisen sinn. Quell: "Backstabber's Knife Collection: A Review of Open Source Software Supply Chain Attacks"

An dësem Beitrag konzentréiere mir eis op d'Benotzung vun oppene Versiounsdeklaratiounen, am Sënn datt déi erofgeluede Versioun net fix ass, mä zu engem bestëmmte Beräich gehéiere muss. Beim Build gëtt déi héchst existent Versioun, déi mat dem spezifizéierte Versiounsberäich kompatibel ass, vum Package Manager ausgewielt an erofgelueden/installéiert.

Loosst eis oppen Deklaratiounen an Ofhängegkeetsdeklaratioune fir verschidde Paketmanager illustréieren:

• • NPM: Package.json

{

 

   ...

   „Ofhängegkeeten“: {
      ...
      „akzeptéiert“: „>=1.3.8“,
      „lodash“: „~4.16.0“,
      ...
   },
   ...
}

Déi gréisst existent Versioun, net méi jonk wéi 1.3.8, fir den accepts-Pak gëtt installéiert, souwéi de gréissten 'Patch'-Update fir Lodash am 4.16.x-Beräich.

• • Maven: pom.xml

...

...

     commons-io
     commons-io
     FRËSCHATTUNG

...

...

Déi lescht verfügbar Versioun fir commons-io (jar-Datei) gëtt als Ofhängegkeet bäigefüügt.

• • Pip: setup.py

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

Sou oppe Versiounsschemae hunn eng gutt an eng schlecht Säit. Déi gutt Säit ass, datt méi nei Versiounen normalerweis enthalen funktionell a Qualitéitsverbesserungen, Bugfixes a Sécherheetspatches, déi automatesch aktualiséiert ginn. W.e.g. notéiert datt fir déi meescht Projeten an der realer Welt d'Fixes net op fréier kleng Versioune zréckportéiert ginn, ausser vläicht fir katastrophal Sécherheetslücken. Oppe Versioune si gutt fir a Bibliothéiken ze benotzen, fir d'Zuel vun de Versiounen ze reduzéieren, déi installéiert musse ginn, wann all Ofhängegkeete geléist sinn.

Mee oppe Versiounsberäicher hunn eng schlecht Säit. Dir wësst net genee, wéi eng Versiounen zum Zäitpunkt vun der Buildinstallatioun installéiert ginn, a Builds sinn net widderhuelbar. An et gëtt och eng däischter Säit mat oppene Versiounen. Wann et engem béiswëllege Akteur geléngt, eng béiswëlleg Komponent am ëffentleche Repository mat enger héijer Versioun ze publizéieren, déi mat Ärem oppene Range kompatibel ass, da wäert Äre nächste Build déi béiswëlleg Komponent enthalen, vläicht souguer Malware an Installatiounsskripten ausféieren, déi automatesch ausgeführt kéinte ginn. D'Attack-Notzlaascht ze verschleieren ass eng Konscht.

Dëst ass bekannt als de Mangel u Versiounspinning Thema.

Béiswëlleg Akteuren probéieren ëmmer béiswëlleg Versioune vu populäre Open-Source-Paketen ze placéieren. Si kënnen Zougang zu de Schlëssele fir Paketrepositories an engem geheime Leak kréien; si benotzen dacks Social Engineering oder verstoppen eng verschachtelt béiswëlleg Ofhängegkeet an engem scheinbar nëtzlechen pull requestOch e puer Autoren decidéieren iergendwann selwer, datt d'Welt net fair ass a bäissen hir Clienten domat. Protestware an hiren eegenen Packagen!

Stellt Iech elo vir, Dir schafft fir eng Organisatioun, déi intern Komponenten plus Open-Source Komponenten benotzt.
Wann e schlechten Akteur den Numm vun esou internen Komponenten kennt, kann hien/si et fäerdeg bréngen, eng Komponent mam selwechten Numm am ëffentleche Repository ze publizéieren. Vill Paketmanager kréien als éischt déi ëffentlech Komponenten, a wann d'Versioun richteg gewielt ass an d'Versioun an Ärer deklaréierter Ofhängegkeet op ass, boom! Dëst Thema huet den Numm ... Ofhängegkeetsverwirrung.

Loosst eis e Beispill weisen. Sot mir, datt mir an eisem NPM-Projet eng Ofhängegkeet vun enger privater Komponent hunn:

• • NPM: Package.json

{
  "Numm": "mäi-Projet",

 

  ...
  „Ofhängegkeeten“: {

    ...
    „meng-privat-Ofdeelung“: „>=1.0.0“,

    ...

   }

   ...

}

 

Den Ugräifer kéint eng héich Major Versioun vu my-private-dep erstellen (wéi 99.0.0) a se am ëffentleche npm Repository publizéieren, mat sengem eegene gefälschten Account (den Ugräifer brauch näischt mat menger Organisatioun ze maachen). Den NPM Package Manager installéiert déi béiswëlleg Ofhängegkeet, dacks mat zerstéierende Resultater.

D 'Léisung

Fir dës Problemer an eisem Software-Entwécklungsprozess ze vermeiden, solle mir eis un strikt Norme halen, wéi Komponentversioune deklaréiert ginn, déi vun der benotzter Technologie ofhänken. Déi wichteg Saach ass, datt eng spezifesch Versioun vun engem Pak, nodeems se an engem Repository publizéiert gouf, onverännerlech soll sinn (fir ze vermeiden, datt Ofhängeger gebrach ginn, net nëmmen aus Sécherheetsgrënn).

Déi allgemeng Iddi ass et ze fixéieren (PIN) Versiounen, ëmmer kontrolléieren ob déi fix Versioune vun de Komponenten (inklusiv ALL transitiv Ofhängegkeeten) fräi vu Malware sinn, an dëst ass méiglech dank der Spärdateien déi vill Paketmanager ubidden. Kucke mer emol wéi Versiounspinning fir verschidde Paketmanager funktionéiert. Et gëtt e delikate Kompromëss tëscht reegelméisseg Versiounsupdates fir bekannt Schwachstelle ze behiewen an Versiounspinnen fir net-deterministesch Builds a potenziell Attacken an der Versuergungskette ze vermeiden.

• • NPM:
    D'npm- oder yarn-Packagemanager benotzen ënnerschiddlech Lockdateien (npm-shrinkwrap.json / package-lock.json oder yarn.lock), déi fix Versioune fir all Ofhängegkeeten, direkt an indirekt, oplëschten. D'Lockdateien sollten ënner Versiounskontroll sinn, soss kéinten aner Entwéckler / Build-Knoten mat anere Versioune ophalen. Vermeit npm-Installatioun, ausser wann Dir während der Entwécklung d'Ofhängegkeeten aktualiséiere musst (z.B. fir Sécherheetsfixes z'installéieren). Benotzt am Allgemengen déi méi deterministesch npm ci (Clean Install), sou datt de Packagemanager d'Lockdatei benotzt oder mat engem Fehlermeldung ofschléisst, wann kee Lockdatei gëtt oder et net mam package.json iwwereneestëmmt. Wann déi opgezielt Versiounen op Malware iwwerpréift goufen, garantéiert d'Lockdatei, datt näischt Schlechtes beim Build geschitt.

    Fir intern Komponenten ass et recommandéiert, eng NPM-Ëmfang vun der Organisatioun geréiert (wéi @myorg), an dee Scope an der Ofhängegkeet benotzen (wéi @myorg/my-private-dep), déi nëmme privat Visibilitéit kéint hunn. Dëst blockéiert Ofhängegkeetsverwirrung Attacken, well nëmme Memberen vun der Organisatioun mat Schreifzougang Pakete ënner sou engem Ëmfang publizéiere kënnen.

• • Maven:
    Maven / Gradle hunn keng Sperrdateien (kuckt awer dësen StackOverflow Artikel).

    Versiounsberäicher ginn net sou vill mat Maven/Gradle benotzt wéi mat aneren Ökosystemer. Vermeit einfach Versiounsberäicher an déi NEIST oder VERËFFENTLECHT Meta-Versiounen. Indirekt Versioune sollten och iwwerpréift ginn. Den Versiounen Maven Plugin ass e gutt Tool fir Versiounskontroll.

    W.e.g. notéiert datt Maven ëmmer de Konzept vum Organisatiounsëmfang hat (den groupId-Deel vun der Ofhängegkeet), an d'Duercherneen tëscht Ofhängegkeeten schéngt fir dësen Ökosystem guer kee Problem ze sinn.

• • Pip:
    A Python ginn et verschidden Tools fir mat Lockfiles ëmzegoen:

    - pipenv, wat eng Pipfile.lock Lockdatei generéiert.
    - Poesie, wat poetry.lock generéiert.
    - Pip Afréieren, e Kommando, deen eng requirements.txt generéiert, déi als Lockdatei déngt. Iwwerpréift ob all Ofhängegkeeten fix Versioune mam == Operator benotzen. Dann benotzt pip install -r requirements.txt déi fix Ofhängegkeeten.

Denkt drun, datt d'Lockdateien uewen ënner Versiounskontroll solle sinn, an datt de gewielte Build-Kommando d'Lockdatei benotze soll.

De gewinntene Package-Repository, deen mat Pip (PyPI) benotzt gëtt, huet keng Naming-Scopes an ass ufälleg fir Dependency-Confused-Attacken. Vermeiden vun Ofhängegkeetsduercherneen am Python-Ökosystem ass net einfach, an e puer Autoren empfeelen en internt Repository ze benotzen als Proxy fir ëffentlech Ofhängegkeeten, déi vu PyPI ofgeruff ginn, awer als éischt déi privat Ofhängegkeeten aus dem internen Repository ze huelen (-index-url soll op den internen Repository weisen, net op PyPI, an –extra-index- url soll ewechgeholl ginn).

E puer richteg Attacken

Getcookies AttackDen Akteur dustin87 huet eng indirekt Ofhängegkeet an de populäre npm mailparser Package vun engem béiswëllege Package mat enger RCE-Backdoor (gCOMMANDhDATAi) bäigefüügt:

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

Obwuel et ofgeschaaft gouf (keng Rezensenten!), huet Mailparser ëmmer nach ongeféier 64,000 Downloads pro Woch kritt. Dëst war e Fall vun engem bal-ongewollten Ugrëff, well den RCE net wierklech ausgeübt gouf.cised.

NPM publizéiert dësem Beitrag mat Detailer iwwer den getcookies Attack.

Ofhängegkeetsverwirrung:

Den Alex Birsan huet am Joer 2021 d'Problem vun der Ofhängegkeetsduercherneen entdeckt an e Post mam Titel " publizéiert.Wéi ech mech an Apple, Microsoft an Dosende vun anere Firmen gehackt hunn".

Denkt drun datt fir npm den Organisatiounsscope wéi @myorg reservéiert soll ginn, an intern Pakete solle geännert ginn fir de Scope ze benotzen.

Mat PIP huet de gemeinsame ëffentleche Registrierungsprogramm PyPI keng Scopes/Namespaces. All privat Pakett kéint e ëffentleche Pakett-Squat mam selwechten Numm wéi deen internen Pakett hunn, awer eidel, a vläicht e Feeler generéieren wann et benotzt gëtt, sou datt et identifizéiert ka ginn wann et zoufälleg ofgeruff gëtt.

Node-ipc:

De Besëtzer vum Pak huet, wéi de Krich tëscht Russland an der Ukrain ugefaangen huet, béiswëlleg Code agefouert fir zoufälleg Dateien ze läschen, wann en op russeschen a wäissrusseschen Hoster installéiert ass. D'Datei ssl-geospec.js huet sou eng geographesch Ënnerscheedung gemaach:

Interessanterweis hunn aner Paketen oppe Versioune fir d'Node-IPC-Ofhängegkeet benotzt, wéi de populäre Vue.js Framework, an seng Maintainer kruten en dréngend Appel fir d'Node-IPC-Ofhängegkeet op eng sécher Versioun ze pinnen.

dëst de Post enthält méi Detailer op dës Sabotage, déi nach ee Schrëtt méi wäit geet wéi aner Protestware befaasst.

Concluding Remarks

Oppe Versioune sollten ni a konsolidéierte Softwareprojeten benotzt kënne ginn. Si maachen d'Builds net reproduzéierbar, an Attacker kënnen se ausnotzen a schaffe Malware iwwer Attacken op d'Ofhängegkeetsbeem ze injizéieren, wéi déi uewe genannte Ofhängegkeetsduercherneen.

Feelerkonfiguratiounen ewéi oppe Versiounen, feelend Versiounspinning oder intern Komponenten ouni Scope sollt vermeit ginn. Déi éischt Saach ass, sou Problemer z'entdecken, vläicht souguer de Build ze blockéieren, wa se fonnt ginn, an e Protokoll fir d'Handlung ze standardiséieren.

Automatesch Detektioun vu Feeler a Fehlkonfiguratiounen an Ofhängegkeeten, Meldung vu verdächtege Ofhängegkeeten, déi ufälleg fir spezifesch Attacken an der Supply Chain kéinte sinn, wéi z.B. Ofhängegkeetsverwirrung, all mat aktionsfäege Reparaturinstrumenter, ass ee vun den Haaptziler vun der Xygeni Plattform.