Mini Shai-Hulud Menyerang Lagi: 314 Paket npm Disusupi

 (safedep.io)
1 poin oleh GN⁺ 3 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • akun npm atool disusupi pada 19 Mei 2026, dan selama sekitar 22 menit 637 versi berbahaya untuk 317 paket didistribusikan secara otomatis
  • Payload berupa skrip Bun terobfuskasi berukuran 498KB, menggunakan struktur pemindai dan regex yang sama dengan Mini Shai-Hulud yang dipakai dalam kompromi SAP
  • Target pencurian meluas hingga kredensial AWS, token Kubernetes, Vault, GitHub PAT, token npm, kunci SSH, dan rahasia lokal
  • Di CI, GitHub Actions OIDC ditukar menjadi token publish npm, lalu tanda tangan Sigstore dan injeksi workflow berbahaya disalahgunakan
  • Respons memerlukan pemeriksaan apakah versi yang disusupi terpasang, penggantian semua kredensial yang mungkin sempat diakses, serta lockfile·pinning dependensi dan inspeksi sebelum instalasi

Ringkasan serangan

  • Akun npm atool (i@hust.cc) disusupi pada 19 Mei 2026, dan selama sekitar 22 menit 637 versi berbahaya didistribusikan ke 317 paket
  • Akun ini memelihara 547 paket, dan penyerang melakukan dua kali version bump pada lebih dari 314 di antaranya
  • Paket yang terdampak mencakup size-sensor (4,2 juta unduhan per bulan), echarts-for-react (3,8 juta), @antv/scale (2,2 juta), timeago.js (1,15 juta), serta banyak paket dalam scope @antv
  • Payload adalah skrip Bun terobfuskasi berukuran 498KB, dan menggunakan struktur pemindai, regex kredensial, serta pola obfuskasi yang sama dengan toolkit Mini Shai-Hulud yang dipakai dalam kompromi SAP tiga minggu sebelumnya
  • Data yang dicuri dikomit sebagai objek Git ke repositori GitHub publik, atau dikirim ke t.m-kosche[.]com melalui HTTPS POST yang dienkripsi dengan RSA+AES

Cara distribusi dan risiko semver

  • Gelombang pertama mendistribusikan sekitar 317 versi pada 19 Mei 2026 pukul 01:39~01:56 UTC, dan gelombang kedua melakukan sekitar 314 version bump pada paket yang sama pada 02:05~02:06 UTC
  • Sebanyak 309 paket menerima tepat 2 versi berbahaya, masing-masing satu per gelombang
  • Empat paket, yaitu size-sensor, echarts-for-react, jest-canvas-mock, dan jest-date-mock, menerima 3 versi dan tampaknya digunakan untuk pengujian awal
  • Penyerang tidak memindahkan dist-tag latest pada sebagian besar paket, tetapi interpretasi semver npm memilih versi tertinggi yang cocok dengan rentang, terlepas dari latest
  • Misalnya, meskipun latest untuk echarts-for-react tetap di 3.0.6, proyek dengan "echarts-for-react": "^3.0.6" bisa diresolusikan ke versi berbahaya 3.2.7 pada clean install berikutnya

Jalur eksekusi dan payload

  • Semua versi yang telah dirusak menambahkan version bump dan "preinstall": "bun run index.js" ke package.json
  • Dari 637 versi berbahaya, 630 menambahkan @antv/setup: github:antvis/G2#<commit-sha> ke optionalDependencies untuk mengambil salinan payload kedua
  • Hook preinstall berjalan sebelum instalasi dependensi dan memerlukan runtime Bun
  • Meski preinstall diblokir atau dilewati, skrip prepare dalam commit penyamaran GitHub tetap menjadi jalur eksekusi kedua
  • index.js adalah bundel Bun terobfuskasi 498KB satu baris, dan memiliki requirement Bun, obfuskasi hex-variable, struktur pemindai dengan ambang flush 100KB, serta kumpulan regex kredensial yang sama dengan payload Mini Shai-Hulud yang dipakai dalam kompromi SAP
  • Deteksi lingkungan CI memeriksa variabel lingkungan dari lebih dari 20 platform, termasuk GitHub Actions, Jenkins, GitLab CI, CircleCI, Travis, Buildkite, Drone, TeamCity, AppVeyor, Bitbucket Pipelines, CodeBuild, Azure DevOps, Netlify, dan Vercel

Target pengumpulan kredensial

  • Payload membaca lebih dari 80 variabel lingkungan dengan nama yang disamarkan, dan memindai isi file menggunakan regex
  • Target utama mencakup token GitHub, token npm, JWT GitHub Actions, key AWS, key Azure, connection string DB, key Stripe, kunci SSH, autentikasi Docker, token Vault, token Kubernetes, dan kredensial yang tertanam di URL
  • Pemindai file membaca lokasi kredensial standar di direktori home seperti .ssh, .aws/credentials, .npmrc, .docker/config.json, dan .kube/config
  • Payload menelusuri seluruh urutan resolusi kredensial AWS, mengambil kredensial IAM role dari endpoint EC2 IMDSv2 dan ECS container credential, serta mencoba mengakses AWS STS GetCallerIdentity dan Secrets Manager
  • Untuk Vault, payload memeriksa file token serta VAULT_ADDR, VAULT_TOKEN, VAULT_ROLE, dan lain-lain, lalu jika ada kredensial valid mencoba enumerasi secret serta autentikasi AWS·Kubernetes
  • Untuk Kubernetes, payload memeriksa token service account dan KUBECONFIG, serta bila ada Docker socket mencoba enumerasi kontainer host dan pelarian kontainer

C2 dan eksfiltrasi data

  • GitHub API digunakan seperti C2, dengan GET /user untuk memverifikasi token GitHub yang dicuri dan GET /user/orgs untuk mengenumerasi organisasi
  • Token dengan izin repo atau public_repo yang memadai digunakan untuk membuat repositori eksfiltrasi milik penyerang
  • Deskripsi repositori yang dibuat disimpan sebagai string terbalik niagA oG eW ereH :duluH-iahS, yang jika dibalik menjadi “Shai-Hulud: Here We Go Again”
  • Nama repositori menggabungkan dua kata bertema Dune dan angka, seperti harkonnen-melange-742, fremen-sandworm-315, dan gesserit-navigator-508
  • Data hasil eksfiltrasi disimpan melalui Git Data API dalam urutan blob, tree, commit, lalu ref update
  • Pengirim HTTPS terpisah dikonfigurasi agar terlihat seperti endpoint ingestion trace OpenTelemetry OTLP di hxxps://t.m-kosche[.]com/api/public/otel/v1/traces
  • Payload HTTPS mengenkripsi JSON gzip dengan AES-256-GCM, lalu membungkus key AES dengan RSA-OAEP menggunakan public key yang di-hardcode

Penyalahgunaan CI/CD dan rantai kepercayaan

  • Dari repositori GitHub yang dapat diakses token curian, payload mengumpulkan riwayat eksekusi workflow, artifact, nama secret, daftar branch, dan konfigurasi Claude Code
  • Nilai secret tidak dapat diakses lewat GitHub API, tetapi nama secret mengungkapkan kredensial apa yang ada
  • Workflow berbahaya disuntikkan ke .github/workflows/codeql.yml dengan nama Run Copilot dan dipicu oleh push
  • Workflow tersebut menaruh seluruh repository secrets ke variabel lingkungan dalam bentuk JSON melalui VARIABLE_STORE: ${{ toJSON(secrets) }}, menyimpannya ke format-results.txt, lalu mengunggahnya sebagai artifact
  • Setelah selesai, payload mengunduh zip artifact, lalu menghapus workflow run dan me-reset branch ref untuk mengurangi jejak injeksi
  • Di CI yang memiliki GitHub Actions OIDC, payload mencoba menukar token publish npm melalui endpoint https://registry.npmjs.org/-/npm/…;
  • Payload memiliki implementasi penandatanganan Sigstore yang mencakup format Fulcio, Rekor, dan SLSA provenance, sehingga dapat membuat artifact bertanda tangan dengan identitas CI yang telah disusupi

Infeksi lingkungan pengembangan dan agen coding AI

  • Payload menargetkan lingkungan Claude Code, Codex, dan VS Code melalui injeksi jarak jauh lewat GitHub API serta infeksi lokal lewat penulisan ke filesystem
  • Dengan token yang dicuri, penyerang meng-commit .vscode/tasks.json, .claude/index.js, .claude/settings.json, .claude/setup.mjs, dan .vscode/setup.mjs ke repositori yang dapat diakses
  • .claude/settings.json mendaftarkan hook SessionStart untuk menjalankan node .claude/setup.mjs setiap kali sesi Claude Code dimulai
  • .vscode/tasks.json memicu eksekusi saat folder proyek dibuka dengan "runOn": "folderOpen"
  • setup.mjs mengunduh Bun v1.3.14 dari rilis resmi GitHub, mengekstrak binarinya, lalu menjalankan payload
  • Jalur infeksi lokal menyalin payload ke ~/.claude/package/index.js dan ~/.codex/package/index.js, lalu memindai file konfigurasi proyek yang ada untuk menyuntikkan hook
  • Pada Mac Apple Silicon, jalur infeksi lokal ini dilewati, sedangkan pada Linux, Mac Intel, dan Windows jalur ini dijalankan

Persistensi dan GitHub dead-drop C2

  • Daemon eksekusi berkelanjutan yang menyamar sebagai kitty-monitor dipasang sebagai layanan pengguna systemd di Linux, dan sebagai ~/Library/LaunchAgents/com.user.kitty-monitor.plist di macOS
  • Installer menggunakan systemctl --user enable --now dan loginctl enable-linger agar tetap bertahan setelah logout
  • Daemon cat.py melakukan polling ke GitHub Search API setiap 1 jam dan mencari commit yang berisi kata kunci firedalazer
  • Format pesan commit adalah firedalazer <base64_url>.<base64_signature>, lalu tanda tangan RSA-PSS diverifikasi menggunakan kunci publik RSA 4096-bit yang di-hardcode sebelum mengeksekusi kode Python dari URL tersebut
  • Daemon terpisah gh-token-monitor melakukan polling token GitHub yang dicuri setiap 60 detik dengan TTL 24 jam
  • Pemindai memori proses menggunakan /proc/pid/maps+mem di Linux dan ReadProcessMemory di Windows untuk membuang area memori yang dapat dibaca dari proses worker GitHub Actions runner

Commit penyamaran antvis/G2

  • Dari 637 versi berbahaya, 630 menyertakan entri optionalDependencies yang menunjuk ke commit tertentu di repositori antvis/G2 
    {
  "optionalDependencies": {
    "@antv/setup": "github:antvis/G2#1916faa365f2788b6e193514872d51a242876569"
  }
}
  • Saat npm me-resolve dependensi github:, npm akan mengambil commit tersebut, mencari package.json, lalu menjalankan lifecycle script
  • Commit tersebut berisi deklarasi @antv/setup, package.json dengan script prepare, dan index.js 499KB yang mengobfuscasi ulang payload Shai-Hulud yang sama
  • && exit 1 dalam script prepare membuat optional dependency gagal, tetapi npm tidak memperlakukan kegagalan optional dependency sebagai fatal sehingga instalasi tetap berlanjut
  • Git API menampilkan 3 SHA commit berbeda yang di-push ke antvis/G2, dan semuanya tidak terhubung ke branch mana pun
  • Ketiga commit itu berbagi metadata yang sama: author huiyu.zjt <Alexzjt@users.noreply.github.com>, pesan commit New Package, tanpa parent, dan tanpa tanda tangan GPG
  • Tanpa hak tulis ke antvis/G2, penyerang dapat membuat payload orphan commit di fork lalu menghapus fork tersebut, sehingga tersisa commit yang masih bisa di-fetch berdasarkan SHA dalam namespace repositori induk
  • Metode ini adalah jenis yang sama dengan masalah commit penyamaran GitHub Actions yang didokumentasikan Chainguard, dan di sini diterapkan pada resolusi dependensi npm github:

Indikator kompromi

  • Paket yang dirilis oleh atool(i@hust.cc) antara 19 Mei 2026 01:44–02:06 UTC merupakan target verifikasi
  • Script preinstall adalah bun run index.js
  • SHA256 payload adalah a68dd1e6a6e35ec3771e1f94fe796f55dfe65a2b94560516ff4ac189390dfa1c
  • Commit penyamaran antvis/G2 adalah sebagai berikut
    • 1916faa365f2788b6e193514872d51a242876569 — 626 versi
    • 7cb42f57561c321ecb09b4552802ae0ac55b3a7a — 2 versi
    • dc3d62a2181beb9f326952a2d212900c94f2e13d — 1 versi, sudah garbage collected
  • IoC jaringan mencakup hxxps://t.m-kosche[.]com/api/public/otel/v1/traces, metadata EC2 169.254.169.254, dan permintaan metadata container ECS 169.254.170.2
  • IoC repositori mencakup branch chore/add-codeql-static-analysis, workflow Run Copilot, serta .github/workflows/codeql.yml yang membuang toJSON(secrets) ke format-results.txt
  • IoC lingkungan pengembangan mencakup hook SessionStart di .claude/settings.json, "runOn": "folderOpen" di .vscode/tasks.json, .claude/setup.mjs, dan .vscode/setup.mjs
  • IoC persistensi mencakup kitty-monitor.service, com.user.kitty-monitor.plist, ~/.local/bin/gh-token-monitor.sh, ~/.local/share/kitty/cat.py, dan /var/tmp/.gh_update_state

Paket representatif yang perlu diperiksa

  • Tabel compromised-packages.csv memiliki 2 kolom, yaitu Package dan Compromised Versions, dan menurut tabel tersebut ada 317 paket yang ditampilkan
  • Di lockfile, perlu diperiksa apakah paket tersebut dan versi berbahaya yang dirilis pada 2026-05-19 ada atau tidak
  • Paket @antv representatif dan versi berbahayanya
    • @antv/g2: 5.5.8, 5.6.8
    • @antv/g6: 5.2.1, 5.3.1
    • @antv/g: 6.4.1, 6.5.1
    • @antv/l7: 2.26.10, 2.27.10
    • @antv/x6: 3.2.7, 3.3.7
    • @antv/s2: 2.8.1, 2.9.1
    • @antv/f2: 5.15.0, 5.16.0
  • Paket npm umum dan versi berbahayanya
    • echarts-for-react: 3.0.7, 3.1.7, 3.2.7
    • size-sensor: 1.0.4, 1.1.4, 1.2.4
    • jest-canvas-mock: 2.5.3, 2.6.3, 2.7.3
    • jest-date-mock: 1.0.11, 1.1.11, 1.2.11
    • timeago.js: 4.1.2, 4.2.2
    • timeago-react: 3.1.7, 3.2.7
    • @lint-md/cli: 2.1.0, 2.2.0
    • @lint-md/core: 2.1.0, 2.2.0
    • @lint-md/parser: 0.1.14, 0.2.14

Respons dan pertahanan

  • Jika versi yang disusupi telah terpasang, token npm, GitHub PAT, kunci AWS, kunci SSH, kredensial cloud, kata sandi database, token Vault, token service account Kubernetes, serta rahasia di pengelola kata sandi lokal yang dapat diakses dari lingkungan build harus diganti
  • t.m-kosche[.]com harus diblokir pada level jaringan dan DNS
  • Harus diperiksa apakah ada repositori publik tidak sah yang dibuat di bawah akun GitHub dengan token yang dapat diakses dari lingkungan build
  • Log publish paket yang tidak sah dan log pertukaran token npm OIDC di pipeline CI harus ditinjau
  • Log transparansi Sigstore harus diperiksa untuk melihat apakah ada artifact bertanda tangan yang dibuat dengan CI identity yang disusupi
  • Pada proyek Node.js lokal, periksa hook .claude/settings.json, tugas auto-run .vscode/tasks.json, .claude/setup.mjs, dan .vscode/setup.mjs
  • Hapus layanan pengguna systemd kitty-monitor dan LaunchAgent com.user.kitty-monitor, lalu periksa keberadaan ~/.local/share/kitty/cat.py, /var/tmp/.gh_update_state, dan ~/.local/bin/gh-token-monitor.sh
  • Dependensi harus di-pin atau menggunakan lockfile agar interpretasi rentang semver tidak mengarah ke versi berbahaya
  • Audit eksposur Docker socket dan akses metadata EC2 di pipeline CI/CD, serta pertimbangkan pembatasan hop limit IMDSv2
  • Package Manager Guard (pmg) adalah proxy instalasi open-source yang mencocokkan paket dengan threat intelligence sebelum preinstall dijalankan
  • dependency cooldown dapat menolak versi yang dirilis dalam jendela waktu yang dapat dikonfigurasi, sehingga mengurangi gelombang deployment mendadak ketika rentang semver diinterpretasikan sebagai rilis baru yang berbahaya
  • vet dapat mendeteksi pembaruan paket yang tidak normal, seperti hook preinstall yang tidak terduga, lonjakan ukuran, atau perubahan maintainer, sebelum mencapai pipeline CI/CD
  • Cakupan dampak berupa 547 paket di bawah satu akun dan lebih dari 314 paket yang dipersenjatai dalam satu sesi menyingkap kelemahan struktural pada model kepercayaan npm

Referensi

Bacaan terkait

1 komentar

 
GN⁺ 3 jam lalu
Komentar Hacker News

  • Sekarang skrip lifecycle NPM seharusnya dinonaktifkan secara bawaan
    Ini pada dasarnya berarti eksekusi kode arbitrer ditanamkan atas nama fitur kemudahan, dan itu juga berlaku pada dependensi transitif. Semua serangan bergaya worm NPM yang menyebar luas tersebar melalui pengaturan bawaan ini. Tidak seharusnya dengan menyalakannya sekali pada perintah tertentu semua dependensi transitif bisa menjalankan skrip lifecycle; seharusnya ditandai secara eksplisit per dependensi yang benar-benar membutuhkannya
    Sebagian besar paket NPM sama sekali tidak bergantung pada skrip semacam ini, jadi kalau belum, sebaiknya dimatikan secara global

    • Ada RFC untuk ini: https://github.com/npm/rfcs/pull/868
    • Atau pakai saja pnpm
    • Betul. Atau setidaknya harus dijalankan di dalam sandbox. Kalau itu skrip pascainstal yang menjalankan perintah arbitrer dalam konteks paket yang dipasang sendiri, masih masuk akal, tetapi kombinasi skrip arbitrer dan hak akses pengguna adalah resep bencana
      Meski begitu, paket tetap bisa menjalankan sampah apa pun yang diinginkannya saat pertama kali diimpor oleh program

  • Pernyataan seperti “tidak ada cara untuk mencegahnya” hanya keluar dari package manager satu-satunya tempat hal seperti ini terjadi secara rutin

    • Selain fakta bahwa NPM adalah package manager paling populer, adakah faktor khusus yang membuatnya sangat rentan terhadap serangan seperti ini?

  • Pada titik tertentu, mungkin lebih baik mematikan Dependabot dan mengunci semua paket NPM sampai versi minor/patch daripada terus memperbarui
    Terutama untuk paket frontend, akhir-akhir ini tampaknya perbaikan keamanan yang bermakna lebih jarang daripada serangan supply chain
    Ini keadaan yang menyedihkan, tetapi jika frontend dijadikan BOM statis dan kita percaya NPM setidaknya mematuhi batasan “versi lama tidak bisa dipublikasikan ulang”, adakah alasan untuk tidak melakukannya?

    • Lalu tim compliance akan kesal karena ada satu CVE dengan CVSS 3.1 yang punya patch tetapi tetap belum diperbaiki
    • Cukup terapkan masa pematangan. Misalnya, jangan biarkan versi yang lebih baru dari 30 hari masuk ke pull request mana pun
      Versi yang memperbaiki CVE yang sudah diketahui bisa diberi pengecualian
    • Betul. Itu juga salah satu alasan serangan supply chain lebih jarang terlihat di ekosistem lain
    • Bukankah NPM membuat lockfile lengkap yang mencakup hash dan dependensi transitif yang dipatok?

  • Situasinya makin gila. Secara pribadi, saya sudah menghapus node, python, dan semua package manager dari mesin saya, lalu hanya memakainya di dalam devcontainer atau VM
    Bahkan jika komunitas developer berhasil membuat keamanan yang jauh lebih kuat, saya khawatir setahun lagi kemampuan social engineering model sudah cukup bagus sehingga ini tetap menjadi permainan yang kalah

    • Kalau model jadi sangat mahir dalam social engineering, saya tidak paham kenapa secara prinsip dampaknya akan sebesar itu. Ada diminishing returns, dan target bergerak dengan kecepatan manusia, yang tampaknya jadi bottleneck besar
      Misalnya, upaya yang masuk ke peretasan XZ sangat besar dan tidak bisa dipercepat karena bergantung pada melelahkan maintainer yang ada seiring waktu. Anda bisa membuat dan mengirim pesan jahat yang diperlukan dalam hitungan detik, tetapi kecepatan manusia membacanya tidak bertambah, dan jika semuanya datang sekaligus justru akan menimbulkan kecurigaan
      Ada batas atas pada seberapa meyakinkannya input itu. Anda mungkin bisa mengambil satu pesan jahat acak yang ditujukan ke maintainer XZ dan membuatnya lebih kejam, lebih presisi, dan lebih mencerminkan kelemahan pribadi serta ketakutannya, tetapi apakah secara keseluruhan itu akan jauh lebih efektif? Mungkin tidak, atau paling banter hanya sedikit
    • Bagaimana container menyelesaikan masalah ini? Jika terhubung ke internet, dan pada praktiknya memang begitu, selama container bisa membaca kredensial, bukankah masalah yang sama tetap ada?
    • Tanpa node, bagaimana Anda mengelola resource cloud? Cloudflare butuh wrangler, dan AWS juga punya banyak CLI berbasis node

  • Sekarang Zed sudah 1.0, saya ingin pindah total, tetapi setahu saya model keamanannya serba semua-atau-tidak-sama-sekali. Saya harus mengizinkannya mengunduh dan memasang paket NPM yang tidak saya kenal seenaknya, atau mematikan semua fitur LSP
    Lalu berita seperti ini terus muncul

  • Mungkinkah npm menjalankan program yang secara otomatis menunda upload paket sekitar 10 menit, lalu selama jeda itu mendistribusikannya ke ekosistem perusahaan audit kode pihak ketiga untuk diperiksa otomatis
    Mereka bahkan bisa membuat papan peringkat publik tentang auditor mana yang paling cepat dan andal menangkap masalah, atau memberi insentif finansial

  • Daftar ini tidak lengkap. Setidaknya ada satu paket lain, ekstensi VS Code nx-console, yang juga terinfeksi worm ini kemarin, dan unduhannya 2,2 juta
    Jika ada orang yang punya akses dan jaringan yang relevan membaca ini, mungkin layak menelusuri rantai dependensinya juga untuk melihat apakah ada lagi. Referensi di sini:
    https://github.com/nrwl/nx-console/security/advisories/GHSA-...
    PS: Saya mempostingnya ke HN untuk memberi tahu orang-orang segera setelah infeksi, tetapi sayangnya hampir tidak mendapat upvote

  • Jika melihat seluruh ekosistem, TC39 perlu mempertimbangkan menambahkan standard library yang lebih baik ke JS itu sendiri. Itu akan mengurangi jumlah paket satu-baris
    Setuju. Saat dulu bekerja dengan Deno, salah satu bagian terbaiknya adalah standard library[0] dan lingkungan pengembangan yang secara umum lebih lengkap. Adanya test runner dan assertion library yang terintegrasi dalam runtime terasa sangat masuk akal
    0 - https://docs.deno.com/runtime/reference/std/

    • Agar adil, Node juga sudah menyediakan modul node:test [0] dan node:assert/strict [1] secara bawaan sejak beberapa versi LTS lalu. node --test bisa dengan mudah menggantikan Mocha, dan node:assert/strict cukup baik, meski chai kadang lebih nyaman dipakai. Soal ergonomi seperti expect. @std milik Deno punya assertion library bergaya expect
      Masalahnya, ekosistem Node punya terlalu banyak test runner, dan banyak di antaranya tidak bisa digantikan semudah Mocha. Jadi peralihan ke test harness dan assertion library bawaan tentu akan terasa lambat dan menyakitkan. Orang-orang menyukai sifat Jest dan Vitest yang terlalu rumit karena berbagai alasan. Perusahaan besar mengira Karma adalah ide yang bagus. Saya masih tidak paham kenapa lebih banyak developer tidak jijik dengan kesan “oh, Anda suka V8 untuk unit test? Kalau begitu mari kita jalankan satu salinan V8 lagi di atas lingkungan V8 yang sudah ada”
      [0] https://nodejs.org/api/test.html
      [1] https://nodejs.org/api/assert.html#strict-assertion-mode
    • Saya tidak yakin paket mana di sini yang akan masuk ke dalam “standard library yang lebih baik”
      Bahasa mana yang punya formatter “3 jam yang lalu” di standard library-nya? Itulah yang dilakukan timeago.js
      slice.js hanya menyediakan indexing negatif ala Python. TC39 sudah membuat array.at() dan array.slice() menangani nilai negatif
    • Standard library Node.js juga terus membesar akhir-akhir ini, dan layak dicatat bahwa itu mencakup dukungan assertion dan testing yang disebut sebelumnya
      https://nodejs.org/api/

  • Katanya payload memeriksa soket Docker, dan jika ada, mencoba container escape dengan tiga metode berurutan
    Jadi meskipun dijalankan di dalam devcontainer atau VM, worm seperti ini sudah mencoba keluar
    Pastikan Anda memakai engine VM rootless. Misalnya sesuatu seperti podman alih-alih Docker

    • Meski beberapa orang, bahkan di industri keamanan, berkata sebaliknya, Docker bukan batas keamanan yang kuat dan tidak boleh diperlakukan seperti itu. Ia berbagi sistem dan kernel dengan host yang sedang berjalan
      Ini mengingatkan saya pada masa ketika orang membagikan akun Linux berprivilege rendah dan percaya kernel akan mencegah eskalasi hak akses. Docker secara harfiah adalah hal yang sama dengan lebih banyak langkah. Terutama sekarang, ketika rasanya ada kerentanan eskalasi hak akses lokal kernel baru setiap 5 menit
      Podman sedikit lebih baik karena tidak memberi root ke penyerang, tetapi mengapa sejak awal memberikan akun? Pakai saja VM yang benar-benar layak
    • Jangan mount soket Docker ke dalam container
    • Akan sangat bagus kalau kita mendapatkan sesuatu yang lebih mirip jails atau zones. Lebih bagus lagi jika container dijalankan di dalam jail atau zone
      Apakah ada sandbox komprehensif di Linux seperti yang ada di BSD?
    • Kenapa tidak memakai mesin virtual yang benar-benar layak?
    • Bukankah kebanyakan orang menjalankan Docker secara rootless sekarang, setidaknya di Linux? Apakah podman melakukan lebih dari itu?

  • Saya ingin turun dari Mr Bones' Wild Ride sekarang, tetapi saya takut hal seperti ini akan terus berlanjut. Dari yang saya lihat, banyak strategi deteksi komersial disetel ke tingkat repo/perangkat/developer ketika paket dimuat atau digunakan
    Ini tampak mirip cara kita menangani spam email atau malware umum. Jadi hampir selalu ada target yang cukup bernilai sehingga pelaku jahat akan terus mencoba. Tetapi tidak seperti email, package manager adalah otoritas terpusat, dan masalah di luar jalur utama kemungkinan besar secara default akan dilempar sebagai tanggung jawab developer
    Dari sudut pandang orang yang tidak terlalu tahu, mungkin kita perlu menjauh dari budaya rilis cepat dan versioning longgar, lalu fokus pada versi registry yang stabil dan diperiksa mendalam. Saya bisa saja salah karena efek volume dan skala, tetapi tetap terasa bermakna bahwa bahasa yang lebih volatil tampaknya lebih sering terdampak
    Saya benar-benar ingin membaca tulisan yang membahas lanskap saat ini secara menyeluruh

    • Saya sempat mencari apakah Mr Bones' Wild Ride adalah referensi ke film 1991 Nothing But Trouble, tetapi ternyata saya salah ingat
      Nama roller coaster di film itu adalah Mr Bonestripper: https://www.youtube.com/watch?v=NEZEgd8GjJc
      Ternyata asalnya dari Roller Coaster Tycoon 2: https://knowyourmeme.com/memes/mr-bones-wild-ride
      Jika dibandingkan dengan spam, kita tampaknya telah cukup menetap pada situasi di mana alamat email disedot dari hampir semua lingkungan jaringan komputer komersial dan sosial, lalu spam dipaksa untuk diterima orang sambil dibungkus dengan kesan legitimasi. Hal serupa sangat mungkin terjadi di area ini juga. Mungkin berupa kombinasi perangkat lunak ala agen pemantau lisensi Oracle dan pengelolaan dependensi otomatis, yaitu “menyelesaikan” malware supply chain dengan memasukkan malware lain ke allowlist