Kekurangan Penyematan Versi dan Kekeliruan Kebergantungan

Dalam pembangunan perisian, kita bergantung pada komponen atau artifak sendiri dan pihak ketiga. Pengurusan Kebergantungan yang fleksibel adalah penting untuk perisian moden. Pengurus pakej seperti NPM, Maven, pip or NuGet sering digunakan untuk menentukan kebergantungan perisian. Alatan ini direka bentuk dengan mengutamakan kemudahan dan kemudahan penggunaan, bukan keselamatan.

Masalahnya

Masalahnya ialah fleksibiliti dan kemudahan penggunaan untuk pembangun memanggil penjahat, yang melihat kebergantungan perisian sebagai daya tarikan yang tidak dapat ditolak untuk perniagaan mereka. Hasilnya: pelaku jahat mengikuti semua kemungkinan laluan serangan yang ditunjukkan di sini. Sumber: “Koleksi Pisau Backstabber: Ulasan Serangan Rantaian Bekalan Perisian Sumber Terbuka”

Dalam catatan ini, kami akan menumpukan pada penggunaan deklarasi versi terbuka, dalam erti kata versi yang dimuat turun tidak tetap tetapi mesti tergolong dalam julat tertentu. Pada masa binaan, versi sedia ada tertinggi yang serasi dengan julat versi yang dinyatakan dipilih dan dimuat turun/dipasang oleh pengurus pakej.

Mari kita gambarkan pengisytiharan terbuka dalam pengisytiharan kebergantungan untuk pengurus pakej yang berbeza:

• • NPM: package.json

{

 

   ...

   "kebergantungan": {
      ...
      "menerima": ">=1.3.8",
      “lodash”: “~4.16.0”,
      ...
   },
   ...
}

Versi sedia ada terbesar yang tidak kurang daripada 1.3.8 untuk pakej accepts akan dipasang, serta kemas kini 'tampalan' terbesar untuk lodash dalam julat 4.16.x.

• • Maven: pom.xml

...

...

     umum-io
     umum-io
     PELEPASAN

...

...

Keluaran terakhir yang tersedia untuk commons-io (fail jar) akan ditambah sebagai kebergantungan.

• • Pip: persediaan.py

...
persediaan (
    ...
    install_requires=['lada hitam', 'launchpadlib'],
    ...
)
...

Skema versi terbuka sedemikian mempunyai sisi baik dan buruk. Yang baiknya ialah versi yang lebih baharu biasanya mengandungi penambahbaikan fungsi dan kualiti, pembetulan pepijat dan tampalan keselamatan, yang dinaik taraf secara automatik. Sila ambil perhatian bahawa untuk kebanyakan projek dunia sebenar, pembetulan tidak disandarkan kepada keluaran kecil sebelumnya, kecuali mungkin untuk kelemahan keselamatan yang dahsyat. Versi terbuka juga sesuai untuk digunakan dalam pustaka, bagi mengurangkan bilangan versi yang perlu dipasang apabila semua kebergantungan diselesaikan.

Tetapi julat versi terbuka mempunyai sisi buruknya. Anda tidak tahu dengan tepat versi mana yang akan dipasang pada masa binaan, dan binaan tidak boleh diulang. Dan terdapat juga gelap menyebelahi versi terbuka. Jika pelaku jahat berjaya menerbitkan komponen berniat jahat dalam repositori awam dengan versi tinggi yang serasi dengan julat terbuka anda, binaan anda yang seterusnya akan merangkumi komponen berniat jahat tersebut, mungkin juga melaksanakan perisian hasad dalam skrip pemasangan yang mungkin dilaksanakan secara automatik. Mengaburkan muatan serangan adalah sebahagian daripada seni.

Ini dikenali sebagai Kekurangan Penyematan Versi isu.

Pelakon jahat sentiasa cuba meletakkan versi berniat jahat bagi pakej sumber terbuka yang popular. Mereka mungkin mendapat akses kepada kunci untuk repositori pakej dalam kebocoran rahsia; mereka sering menggunakan kejuruteraan sosial atau menyembunyikan kebergantungan berniat jahat bersarang dalam aplikasi yang nampaknya berguna. pull requestMalah beberapa penulis sendiri suatu hari nanti memutuskan bahawa dunia ini tidak adil dan menggigit pelanggan mereka dengan protes dalam pakej mereka sendiri!

Sekarang bayangkan anda bekerja untuk sebuah organisasi yang menggunakan komponen dalaman dan komponen sumber terbuka.
Jika pelaku yang tidak baik mengetahui nama komponen dalaman tersebut, dia boleh menerbitkan komponen dengan nama yang sama dalam repositori awam. Ramai pengurus pakej mendapatkan komponen awam terlebih dahulu, dan jika versi dipilih dengan betul dan versi dalam kebergantungan yang diisytiharkan terbuka, boom! Isu ini dinamakan Kekeliruan Kebergantungan.

Mari kita tunjukkan satu contoh. Katakan dalam projek NPM kita, kita mempunyai kebergantungan pada komponen persendirian:

• • NPM: package.json

{
  "nama": "projek-saya",

 

  ...
  "kebergantungan": {

    ...
    “my-private-dep”: “>=1.0.0”,

    ...

   }

   ...

}

 

Penyerang mungkin mencipta versi utama my-private-dep yang tinggi (seperti 99.0.0) dan menerbitkannya dalam repositori npm awam, dengan akaun palsunya sendiri (penyerang tidak perlu melakukan apa-apa dengan organisasi saya). Pengurus pakej NPM akan memasang pergantungan berniat jahat, selalunya dengan hasil yang buruk.

Penyelesaian

Untuk mengelakkan isu-isu ini dalam proses pembinaan perisian kita, kita harus mematuhi norma-norma ketat tentang cara mengisytiharkan versi komponen, yang bergantung pada teknologi yang digunakan. Perkara penting ialah versi pakej tertentu, setelah diterbitkan dalam repositori, haruslah tidak berubah (untuk mengelakkan pemecahan dependen, bukan sahaja atas sebab keselamatan).

Idea umum adalah untuk memfiksasi (pin) versi, sentiasa menyemak bahawa versi tetap komponen (termasuk SEMUA kebergantungan transitif) bebas daripada perisian hasad, dan ini boleh dilakukan terima kasih kepada fail kunci yang ditawarkan oleh banyak pengurus pakej. Mari kita lihat bagaimana penyematan versi berfungsi untuk pengurus pakej yang berbeza. Terdapat pertukaran yang halus antara kemas kini versi yang kerap untuk membetulkan kelemahan yang diketahui dan penyematan versi untuk mengelakkan binaan bukan deterministik dan potensi serangan rantaian bekalan.

• • NPM:
    Pengurus pakej npm atau yarn menggunakan fail kunci yang berbeza (npm-shrinkwrap.json / package-lock.json atau yarn.lock, masing-masing) yang menyenaraikan versi tetap untuk semua kebergantungan, langsung dan tidak langsung. Fail kunci harus berada di bawah kawalan versi, jika tidak, pembangun/nod binaan lain mungkin berakhir dengan versi yang berbeza. Elakkan pemasangan npm melainkan semasa dalam pembangunan anda perlu mengemas kini kebergantungan (cth. untuk memasang pembetulan keselamatan). Gunakan npm ci (Pemasangan Bersih) yang lebih deterministik secara umum, jadi pengurus pakej akan menggunakan fail kunci atau menamatkan dengan ralat jika tiada fail kunci, atau ia tidak sepadan dengan package.json. Jika versi yang disenaraikan telah disemak untuk perisian hasad, fail kunci memastikan bahawa tiada perkara buruk akan berlaku pada masa binaan.

    Untuk komponen dalaman, adalah disyorkan untuk mencipta Skop NPM diuruskan oleh organisasi (seperti @myorg), dan menggunakan skop tersebut dalam kebergantungan (seperti @myorg/my-private-dep), yang hanya boleh mempunyai keterlihatan peribadi. Ini menyekat kekeliruan kebergantungan serangan, kerana hanya ahli organisasi yang mempunyai akses tulis sahaja yang boleh menerbitkan pakej di bawah skop tersebut.

• • Maven:
    Maven / Gradle tidak mempunyai fail kunci (tetapi lihat artikel StackOverflow ini).

    Julat versi tidak digunakan dengan Maven/Gradle seperti ekosistem lain. Elakkan sahaja julat versi dan meta-versi TERKINI atau SIARAN. Versi tidak langsung juga harus disemak. Versi Plugin Maven merupakan alat yang bagus untuk kawalan versi.

    Sila ambil perhatian bahawa Maven sentiasa mempunyai konsep skop organisasi (bahagian groupId daripada kebergantungan), dan kekeliruan kebergantungan nampaknya tidak menjadi masalah sama sekali untuk ekosistem itu.

• • Pip:
    Dalam Python terdapat pelbagai alat untuk mengendalikan fail kunci:

    - pipenv, yang menjana fail kunci Pipfile.lock.
    - puisi, yang menghasilkan puisi.lock.
    - pip beku, arahan yang menjana requirements.txt yang bertindak sebagai fail kunci. Periksa sama ada semua kebergantungan menggunakan versi tetap dengan operator ==. Kemudian pip install -r requirements.txt menggunakan kebergantungan tetap.

Ingatkan bahawa fail kunci di atas harus berada di bawah kawalan versi, dan arahan binaan yang dipilih harus menggunakan fail kunci.

Repositori pakej biasa yang digunakan dengan pip (PyPI) tidak mempunyai skop penamaan, dan ia terdedah kepada serangan kekeliruan kebergantungan. Mengelakkan kekeliruan kebergantungan dalam ekosistem python bukanlah mudah, dan sesetengah penulis mengesyorkan penggunaan repositori dalaman untuk bertindak sebagai proksi bagi kebergantungan awam yang diambil daripada PyPI, tetapi mengambil kebergantungan peribadi terlebih dahulu daripada repositori dalaman (-index-url harus menunjuk ke repositori dalaman, bukan PyPI, dan –extra-index-url harus dialih keluar).

Beberapa serangan sebenar

Serangan GetcookiesPelakon dustin87 telah menambah kebergantungan tidak langsung ke dalam pakej mailparser npm yang popular kepada pakej berniat jahat dengan pintu belakang RCE (gCOMMANDhDATAi):

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

Walaupun tidak lagi digunakan (tiada pengulas!), mailparser masih menerima kira-kira 64,000 muat turun mingguan. Ini merupakan kes serangan hampir gagal, kerana RCE sebenarnya tidak berfungsi.cised.

NPM diterbitkan catatan ini dengan butiran tentang serangan getcookies.

Kekeliruan Kebergantungan:

Alex Birsan menemui pada tahun 2021 isu kekeliruan kebergantungan dan menerbitkan catatan bertajuk "Bagaimana Saya Menggodam Apple, Microsoft dan Berpuluh-puluh Syarikat Lain".

Ingat bahawa untuk npm, skop organisasi seperti @myorg harus dikhaskan, dan pakej dalaman harus diubah suai untuk menggunakan skop tersebut.

Dengan pip, PyPI pendaftaran awam biasa tidak mempunyai skop/ruang nama. Setiap pakej persendirian mungkin mempunyai pakej awam yang diletakkan bersebelahan dengan nama yang sama dengan pakej dalaman, tetapi kosong, dan mungkin menghasilkan ralat apabila digunakan, jadi ia boleh dikenal pasti jika ia diambil secara tidak sengaja.

Nod-ipc:

Pemilik pakej, ketika perang Rusia-Ukraine bermula, menyuntik kod berniat jahat untuk mengalih keluar fail rawak, ketika dipasang pada hos Rusia dan Belarus. Fail ssl-geospec.js melakukan perbezaan geografi seperti berikut:

Menariknya, pakej lain menggunakan versi terbuka untuk kebergantungan nod-ipc, seperti rangka kerja Vue.js yang popular, dan penyelenggaranya menerima rayuan segera untuk menyematkan kebergantungan node-ipc pada versi yang selamat.

ini catatan mengandungi butiran lanjut mengenai sabotaj ini, yang melangkah lebih jauh daripada yang lain Protestware isu.

Mengakhiri ucapan

Versi terbuka sepatutnya pernah boleh digunakan dalam projek perisian yang disatukan. Ia menjadikan binaan tidak boleh dihasilkan semula, dan penyerang mungkin mengeksploitasinya dan berjaya menyuntik perisian hasad melalui serangan ke pokok kebergantungan seperti kekeliruan kebergantungan yang dinyatakan di atas.

Konfigurasi yang salah seperti versi terbuka, kekurangan penyematan versi atau komponen dalaman yang tidak berskop harus dielakkan. Perkara pertama adalah untuk mengesan isu sedemikian, mungkin juga menyekat binaan apabila ia ditemui, dan telah menyeragamkan protokol untuk tindakan.

Pengesanan automatik kecacatan dan salah konfigurasi dalam kebergantungan, melaporkan kebergantungan yang disyaki yang mungkin terdedah kepada serangan rantaian bekalan tertentu seperti kekeliruan kebergantungan, semuanya dengan alat pembaikan yang boleh diambil tindakan, merupakan salah satu matlamat utama Platform Xygeni.