TanStack & BANYAK paket lainnya terdampak - analisis & bedah tuntas

Bahasa IndonesiaالعربيةDeutschEnglishEspañolFrançaisहिन्दी日本語한국어PortuguêsРусский中文
MMaximilian Schwarzmüller
Computing/SoftwareBusiness NewsInternet Technology

Transcript

00:00:00Ada serangan rantai pasokan besar lainnya, serangan yang sangat besar sedang terjadi saat ini dan masih berlangsung
00:00:06dan telah menyebar dari NPM ke ekosistem Python juga, jadi mungkin saat ini jangan instal paket
00:00:12NPM atau Python apa pun. Dan pastikan sistem Anda diatur dengan aman secara umum. Saya punya video lain
00:00:19tentang itu, saya akan bagikan tautannya di bawah dan saya akan membahasnya kembali di sini, tapi pertama-tama
00:00:23saya ingin memberi Anda detail tentang apa yang terdampak dan cara mengetahui apakah Anda terdampak. Ini dimulai dengan
00:00:30paket-paket TanStack: TanStack query, TanStack router, TanStack start, dan sebagainya. Kemarin, 11 Mei,
00:00:36dalam jangka waktu yang cukup singkat, beberapa paket berbahaya atau sebenarnya semua paket TanStack
00:00:43diterbitkan dengan versi berbahaya dan itu berhasil diatasi dengan cepat dalam waktu 20 menit. Pada akhirnya,
00:00:50serangan itu terdeteksi dan diatasi dengan cepat, tetapi semua paket berbahaya ini telah diterbitkan
00:00:57dalam jangka waktu tersebut atau dalam jangka waktu singkat ini. Dan kemudian terus menyebar dan masih
00:01:03terus menyebar. Ini menyebar ke paket-paket Mistral yang haha hanya punya empat pengguna, tetapi tetap saja itu
00:01:09terdampak karena malware ini bertindak sebagai worm dan mencuri data, mencuri kredensial, juga berpotensi
00:01:16milik Anda jika terinstal di sistem Anda. Saya akan kembali ke cara mengetahui apakah Anda terdampak dalam
00:01:20sekejap, tetapi serangan ini terus menyebar ke lebih banyak paket NPM karena itulah idenya, dan
00:01:26bahkan merambah ke ekosistem Python dan itu sedang terjadi sekarang. Ini baru berumur beberapa jam saja,
00:01:32dua jam pada saat saya merekam ini. Sekarang, bagaimana cara mengetahui apakah Anda
00:01:39terdampak? Jika Anda menginstal paket TanStack apa pun kemarin malam dalam kasus saya di zona waktu
00:01:45Jerman, Anda harus menganggap diri Anda terdampak. Jika Anda menginstalnya sekitar waktu itu, ingatlah
00:01:54bahwa itu adalah waktu UTC, jadi Anda harus menerjemahkannya ke zona waktu Anda. Pada waktu itu, Anda harus menganggap
00:02:00diri Anda terdampak. Namun karena ini menyebar ke paket Mistral, ke lebih banyak lagi paket JavaScript,
00:02:06lebih banyak daripada yang bisa saya sebutkan di sini, Anda juga harus menganggap diri Anda atau mesin Anda terdampak dan terkompromi.
00:02:13Dan saya akan membagikan tautan ke postingan ini di bawah agar Anda bisa mendalami lebih jauh dan melihat daftar lengkap
00:02:18semua paket yang terdampak saat diterbitkan. Tapi seperti yang disebutkan, ini masih berlangsung,
00:02:22jadi mungkin jangan instal apa pun dulu sekarang. Ada juga indikator kompromi. Anda perlu
00:02:31mencari hash file tertentu, hash SHA, untuk router dalam file JS. Saya juga akan menautkan postingan ini di bawah.
00:02:38Dan jika Anda memiliki cara untuk memantau permintaan jaringan mana yang terjadi di mesin Anda,
00:02:42Anda perlu mencari lalu lintas keluar ke URL ini, yang akan menjadi indikator jelas lainnya
00:02:48bahwa data telah dieksfiltrasi dari sistem Anda. Apa arti kompromi secara detail? Itu berarti
00:02:55malware ini melakukan dua hal utama. Hal penting pertama yang dilakukannya adalah memanen data. Ia
00:03:03mencari token NPM, token GitHub, kredensial AWS, dan rahasia lainnya. Jadi ia memindai sistem Anda untuk
00:03:12mencari lokasi umum tempat Anda menyimpan kredensial dan rahasia, lalu mengumpulkannya dan mengirimkannya ke
00:03:18URL yang saya tunjukkan tadi. Jadi ia mencuri rahasia-rahasia ini. Tapi tidak hanya itu. Seperti yang saya sebutkan,
00:03:26ia bertindak sebagai worm, jadi ia juga menggunakan token GitHub yang dicuri tersebut. Misalnya,
00:03:33ia menggunakannya beserta token NPM untuk menerbitkan lebih banyak paket yang terkompromi. Jika Anda adalah pengelola
00:03:40paket lain, atau jika mungkin Anda memiliki alur kerja CI/CD yang berjalan dalam jangka waktu tersebut dan
00:03:46bergantung pada beberapa paket TanStack, maka dalam alur kerja CI/CD tersebut, paket TanStack
00:03:53yang berbahaya dan terkompromi telah ditarik masuk. Kode berbahaya itu mungkin telah dieksekusi di sana. Dan kemudian di
00:04:00alur kerja tersebut, jadi bukan di mesin Anda, melainkan di alur kerja tersebut, ia juga bisa mencuri kredensial tertentu
00:04:06untuk menerbitkan versi berbahaya, versi yang terkompromi dari paket yang coba dibangun
00:04:14oleh alur kerja CI/CD Anda. Jadi begitulah cara ia menyebar. Seperti yang saya sebutkan, ia bertindak sebagai worm. Ia menggunakan
00:04:20kredensial dan token yang dicuri untuk menerbitkan lebih banyak paket yang terkompromi. Dan begitulah cara ia menyebar
00:04:26ke Mistral dan kemudian ke paket JavaScript lainnya, dan bahkan ke ekosistem Python. Dan di sinilah
00:04:32posisi kita sekarang. Dan sejauh yang saya tahu, ini masih terus menyebar. Sekarang, bagaimana Anda bisa melindungi diri dari
00:04:39hal itu? Saya membuat video tentang itu di saluran saya yang lain, AkataMind. Saya juga akan menautkannya di bawah.
00:04:44Singkat cerita, Anda harus memastikan bahwa Anda menjalankan kode atau melakukan pengembangan Anda,
00:04:51tidak langsung di mesin utama Anda jika memungkinkan, melainkan di dalam mesin virtual dalam dev container,
00:04:57semacam itu. Anda sebaiknya tidak menyimpan rahasia mentah di mesin Anda. Maksud saya, untuk AWS,
00:05:03misalnya, Anda sebaiknya menggunakan pendekatan single sign-on daripada menyimpan kredensial IAM di
00:05:10mesin Anda, misalnya, dan menggunakan teknik serupa untuk layanan lain yang mungkin Anda gunakan. Selain itu,
00:05:16Anda juga bisa mempertimbangkan untuk menggunakan layanan seperti Infisical atau Doppler untuk menyimpan rahasia Anda
00:05:25di cloud dan bukan di hard drive Anda, bukan di file .env. Itu adalah sesuatu yang mungkin ingin Anda lakukan.
00:05:30Dan sekali lagi, saya membahas hal-hal seperti itu di video tersebut. Anda juga sebaiknya menggunakan manajer paket
00:05:38dan konfigurasi yang memungkinkan Anda mengatur hal-hal seperti usia rilis minimum, seperti yang dimungkinkan
00:05:44oleh Bun. Dalam file bunfig.toml, Anda bisa mengatur usia rilis minimum, yang memastikan bahwa meskipun
00:05:49Anda menjalankan bun install, Anda hanya menginstal paket yang setidaknya berusia X detik, X hari dalam
00:05:56kasus ini di contoh ini. Sekarang, pnpm memiliki fitur serupa. Versi terbaru npm juga memiliki fitur
00:06:02serupa. Sekali lagi, saya sudah membahasnya di video lainnya. Dan jika Anda menggunakan sesuatu seperti Bun atau jika Anda memiliki
00:06:09konfigurasi yang tepat untuk npm, tetapi Bun melakukannya secara default, misalnya, maka ia juga memblokir
00:06:15eksekusi, misalnya, skrip post install, jadi skrip siklus hidup dari paket-paket yang Anda
00:06:21instal, yang memberi Anda mekanisme keamanan lain karena malware tersebut biasanya mengandalkan
00:06:28skrip semacam itu yang dieksekusi di sistem Anda. Jadi menggunakan manajer paket yang aman dan atau
00:06:36konfigurasi yang aman untuk manajer paket tersebut, menjalankan kode Anda dalam mesin virtual atau dev container
00:06:41dan tidak menyimpan rahasia polos di sistem Anda. Itulah yang ingin Anda lakukan secara umum, tetapi sekarang mungkin
00:06:46bahkan lebih lagi karena serangan-serangan, serangan seperti ini di sini akan menjadi lebih serius dan kita akan mendalami
00:06:52bagaimana serangan itu bekerja karena itu sangat menarik. Tapi tentu saja, kita akan menghadapi lebih banyak lagi
00:06:58serangan semacam ini. Saya membuat video seperti ini hampir setiap bulan sekarang atau bahkan mungkin lebih sering, karena pertama,
00:07:04saya percaya serangan ini lebih mudah dilakukan sekarang. Di era AI, lebih mudah untuk menganalisis paket atau
00:07:12dependensi yang ingin Anda pengaruhi dan menganalisis kode sumbernya atau pengaturan CICD mereka untuk potensi
00:07:22vektor serangan. Itulah yang terjadi di sini untuk TanStack. Ini bukan berarti mesin pengelola
00:07:28yang terdampak, melainkan alur kerja CICD TanStack yang telah diserang. Dan saya akan
00:07:34kembali ke situ. Jadi lebih mudah untuk mencari kerentanan dengan AI. Lebih mudah untuk menulis kode,
00:07:40termasuk kode berbahaya, tentu saja. Dan pada saat yang sama, kita mengalami ledakan perangkat lunak. Kita melihat
00:07:45lebih banyak perangkat lunak yang ditulis daripada sebelumnya. Jadi ada lebih banyak target di luar sana, termasuk banyak target
00:07:51yang mungkin tidak terlalu peduli dengan keamanan. Jadi itu membuat serangan tersebut lebih menarik juga.
00:07:57Sekarang, bagaimana ini semua bermula? Ini sangat menarik. Seperti yang saya sebutkan, ini bukan pendekatan baru,
00:08:03bukan pendekatan yang belum pernah kita lihat sebelumnya, tapi tetap saja cukup rumit. Tim TanStack menerbitkan sebuah post-mortem,
00:08:09sebuah artikel di mana mereka menjelaskan bagaimana serangan itu terjadi. Dan saya akan menautkan itu di bawah juga.
00:08:15Tapi tentu saja, saya akan memberikan ringkasannya di sini karena pada akhirnya, serangan ini mengandalkan
00:08:22tiga langkah utama, yang akan saya jelaskan secara detail. Pola pull request target pwn request. Saya akan
00:08:30menjelaskan apa itu. Kemudian keracunan cache GitHub actions melintasi batas kepercayaan berbasis fork
00:08:38dan ekstraksi memori runtime dari token OIDC. Oke, apa artinya semua itu? Sekali lagi,
00:08:45Anda bisa membaca artikelnya untuk semua detailnya, tetapi izinkan saya memberikan ringkasannya. Dan mari kita mulai dengan
00:08:50pola pull request pwn request. Apa itu? Untuk memahami itu kita harus memahami
00:08:58bahwa GitHub actions tentu saja adalah solusi CI/CD, produk CI/CD dari GitHub. Dan saya
00:09:05memiliki kursus tentang GitHub actions juga, ngomong-ngomong, jika Anda ingin belajar cara mengatur GitHub actions,
00:09:10cara menggunakan produk tersebut untuk tugas-tugas CI/CD, cara menerbitkan paket atau situs web Anda dan sebagainya.
00:09:16Sekarang, seperti semua alat alur kerja CI/CD, GitHub actions mengandalkan peristiwa yang memicu alur kerja karena
00:09:24tentu saja CI/CD adalah tentang melakukan sesuatu secara otomatis. Misalnya, merilis situs web Anda,
00:09:29menerbitkan, menyebarkan situs web Anda secara otomatis saat Anda melakukan push ke cabang utama, misalnya.
00:09:34Jadi Anda memiliki berbagai peristiwa yang bisa memicu alur kerja dan push adalah salah satu peristiwa, misalnya,
00:09:40sehingga Anda bisa mengatakan, oke, jika saya melakukan push ke cabang utama, misalnya, Anda bisa memfilter untuk
00:09:44cabang yang berbeda. Kemudian saya ingin melakukan tugas-tugas tertentu. Saya ingin menginstal dependensi saya. Saya ingin
00:09:49membangun proyeknya. Saya ingin mengunggahnya ke server saya. Itulah yang bisa Anda lakukan. Sekarang, pemicu lainnya
00:09:56adalah pull request target. Pemicu ini aktif jika ada pull request yang dibuka untuk
00:10:05repositori Anda. Dan itu tentu saja berarti siapa pun bisa melakukan fork pada repositori Anda, melakukan sesuatu di sana, melakukan push
00:10:14sesuatu di fork mereka, lalu membuka pull request dengan repositori Anda. Dan itu akan memicu
00:10:19alur kerja ini. Kedengarannya berbahaya? Ya, memang begitu. Dan itulah yang memulai serangan ini.
00:10:25Ada juga pemicu pull request. Jadi saya sudah bicara tentang pull request target sebelumnya,
00:10:31tapi kita juga punya pull request, yang bekerja dengan cara yang sama, tapi pull request kemudian menjalankan alur kerja
00:10:38CI/CD dalam konteks repositori yang di-fork. Jadi apa pun yang berbahaya yang mungkin terjadi di sana,
00:10:45itu terjadi di repositori yang di-fork, bukan di repositori dasar. Jadi ini bukan masalah.
00:10:52Pull request target di sisi lain berjalan dalam konteks repositori dasar. Dan itu tentu saja
00:10:58berpotensi berbahaya. Ini berpotensi berbahaya karena siapa pun bisa membuka pull request. Dan tentu saja,
00:11:04apa yang terjadi dalam kasus ini untuk serangan TanStack, dalam pull request tersebut, dalam
00:11:10fork tersebut, penyerang menyertakan kode berbahaya, kode worm, malware dalam repositori TanStack,
00:11:20dalam fork-nya, tapi ia menyertakannya di sana. Kemudian penyerang membuka pull request,
00:11:26dan itu menyebabkan pull request target dieksekusi. Dan kemudian seperti yang disebutkan, itu kemudian menjalankan runner GitHub
00:11:33actions, dan kemudian berjalan dalam konteks repositori dasar. Apa artinya ini?
00:11:40Ini tidak berarti bahwa penyerang mendapatkan akses ke kode dasar atau bisa menggabungkan kode berbahaya
00:11:46ke dalam repositori, tetapi itu berarti bahwa, misalnya, cache yang digunakan di sana
00:11:53akan dibagikan dengan eksekusi GitHub actions berikutnya yang berasal dari repositori dasar,
00:12:00berpotensi dari hook atau pemicu peristiwa yang sama sekali berbeda seperti pemicu push.
00:12:05Hal berikutnya yang terjadi adalah keracunan cache. Tapi apa artinya ini? Nah,
00:12:11penyerang menambahkan kode ke fork mereka yang akan memastikan bahwa saat GitHub action
00:12:17berjalan untuk pemicu pull request target, ia akan menjalankan sebuah perintah, perintah hash files,
00:12:23yang didukung oleh GitHub actions, untuk menyimpan sesuatu di cache GitHub actions. Sekarang,
00:12:28tentang apa cache itu? Ide di balik cache GitHub actions sebenarnya sederhana, yaitu untuk mempercepat
00:12:33alur kerja GitHub action tersebut. Jadi Anda bisa, misalnya, melakukan hash pada dependensi. Idenya adalah
00:12:39jika dependensi yang diandalkan oleh paket Anda tidak berubah, mengapa Anda harus melalui seluruh
00:12:46proses instalasi lagi? Itu hanya membuang waktu, dan waktu adalah uang karena Anda ditagih berdasarkan
00:12:52waktu proses alur kerja GitHub action Anda. Dan tentu saja, Anda tidak ingin memiliki alur kerja yang
00:12:56memakan waktu lama. Jadi di sebagian besar alur kerja, tentu saja, misalnya, saat membangun paket TanStack,
00:13:00Anda menginstal dependensi dari paket TanStack, dan kemudian Anda melakukan langkah pembangunan dan membangun
00:13:06paket TanStack Anda. Sekali lagi, jika dependensi TanStack tersebut tidak berubah,
00:13:12mengapa harus diinstal ulang? Itulah ide di balik caching. Dan itu masuk akal. Tentu saja masalahnya adalah,
00:13:18karena eksekusi GitHub actions pull request target dan eksekusi GitHub action lainnya,
00:13:24seperti yang untuk pemicu push, berbagi konteks yang sama, mereka berbagi cache yang sama. Dan di situlah
00:13:31keracunan cache terjadi, karena penyerang dapat menyimpan versi berbahaya dalam cache atau memasukkan
00:13:39kode berbahaya tersebut ke dalam dependensi TanStack, bisa dikatakan begitu, dan menyimpannya di cache. Jadi kemudian penyerang
00:13:46hanya perlu menunggu alur kerja GitHub actions normal berjalan untuk paket-paket TanStack.
00:13:53Jadi menunggu pengelola untuk melakukan push beberapa kode, dan kemudian eksekusi GitHub actions lainnya itu akan menggunakan kembali
00:14:01cache yang sama yang telah diatur oleh eksekusi berbahaya sebelumnya, dan sekarang akan menarik masuk
00:14:08cache beracun yang telah disiapkan, yang menyertakan kode berbahaya. Jadi begitulah cara kode berbahaya itu
00:14:13berpindah dari fork ke eksekusi GitHub actions normal untuk push normal oleh pengelola normal
00:14:21yang tidak terpengaruh oleh kode berbahaya apa pun. Begitulah cara cache digunakan sebagai kendaraan transportasi
00:14:28antara kedua eksekusi GitHub action ini pada akhirnya. Dan kemudian sebagai langkah ketiga, setelah
00:14:35kode berbahaya itu masuk ke dalam eksekusi reguler alur kerja CI/CD TanStack, karena peristiwa push
00:14:44tersebut, ia mencuri token NPM yang berumur pendek, yang pada akhirnya adalah token OIDC, untuk menerbitkan versi berbahaya
00:14:54dari paket TanStack. Sekarang, apa yang saya maksud di sini? NPM memiliki fitur tersebut, yang disebut
00:15:00trusted publishing, yang secara teori membuat penerbitan paket NPM lebih aman, karena
00:15:04ada kira-kira dua cara untuk menerbitkan paket ke NPM, bisa dikatakan begitu. Salah satunya adalah Anda membuat
00:15:11sebuah token dengan akun NPM Anda dan Anda menggunakannya untuk menerbitkan versi baru paket Anda. Masalahnya
00:15:19adalah jika token itu dicuri, siapa pun bisa menerbitkan versi baru dari paket tersebut. Untuk meningkatkan
00:15:26keamanan, ada proses trusted publishing ini di mana NPM mengatakan tidak, Anda tidak bisa menerbitkan paket dari
00:15:33mesin Anda, Anda harus melalui salah satu penyedia tepercaya ini, GitHub actions adalah salah
00:15:37satu darinya, dan ada integrasi trusted publishing untuk GitHub actions yang bisa Anda atur. Dan kemudian
00:15:44sebagai bagian dari proses trusted publishing tersebut, sebuah token penerbitan yang berumur pendek akan diambil
00:15:50atau akan diminta. Dan kemudian token berumur pendek itu akan digunakan untuk menandatangani versi paket baru
00:15:57yang sedang diterbitkan. Jadi secara teori, idenya adalah token itu sulit untuk dicuri karena
00:16:03ia tidak berada di mesin pengelola mana pun. Dan sebagai tambahan, ia berumur pendek. Bahkan jika ia dicuri,
00:16:08ia tidak akan aktif untuk waktu yang lama. Masalahnya, tentu saja, adalah jika kode yang berjalan di dalam alur kerja
00:16:15CICD yang meminta token tepercaya tersebut, jika kode itu telah terdampak, maka kode
00:16:21berbahaya tersebut memiliki akses ke token trusted publishing yang baru dan berumur pendek ini. Dan itulah yang terjadi
00:16:27di sini. Jadi kode berbahaya itu menyalahgunakan token ini atau menggunakan token ini untuk kemudian menerbitkan versi baru
00:16:36dari paket TanStack. Sekarang, yang cukup menarik, serangan ini sebenarnya agak gagal karena ia
00:16:44memang mendapatkan token tepercaya itu dan ia memang menggunakannya untuk kemudian menghubungi API NPM guna menerbitkan versi baru
00:16:52dari paket TanStack yang menyertakan worm ini, yang menyertakan kode berbahaya. Tapi itu sebenarnya
00:16:58berakhir dalam alur kerja GitHub actions yang gagal diselesaikan karena ada sesuatu yang salah dalam
00:17:06kode yang di-push ke CICD. Jadi jika para penyerang memperhatikan untuk menjalankan
00:17:12serangan mereka pada saat kode yang valid sedang di-push, maka tentu saja alur kerja ini akan
00:17:19selesai dan mereka tidak perlu mengandalkan penerbitan paket berbahaya secara manual dengan cara
00:17:26menghubungi API NPM, melainkan mereka bisa menyisipkan kode berbahaya ke dalam alur kerja ini seperti
00:17:32yang mereka lakukan, membiarkan alur kerja ini selesai dengan sukses dan kemudian versi TanStack yang terkompromi akan
00:17:38diterbitkan sambil terlihat sangat valid karena itu adalah push normal oleh pengelola dan alur kerjanya
00:17:45selesai dengan sukses. Cara serangan ini bekerja karena alur kerja itu tidak selesai dengan sukses
00:17:51membuatnya sedikit lebih mudah untuk menangkap apa yang sedang terjadi oleh kontributor luar di sini pada akhirnya
00:18:00karena Anda bisa melihat bahwa versi baru dari paket TanStack diterbitkan meskipun
00:18:05alur kerja GitHub actions gagal, jadi seharusnya tidak ada versi baru yang diterbitkan. Jadi Anda bisa melihat ada
00:18:12ketidaksesuaian di sana yang membuatnya sedikit lebih mudah untuk mendeteksi serangan ini yang merupakan salah satu bagian di mana
00:18:19pengelola TanStack dan kita semua merasa beruntung. Meskipun demikian, ini adalah serangan yang cukup rumit sebagaimana Anda
00:18:26mungkin bisa tahu bahwa itu bekerja sepenuhnya tanpa mengompromikan mesin siapa pun dan meskipun itu tertangkap
00:18:32dengan cepat, ia melakukan kerusakan serius karena seperti yang saya sebutkan, ia masih terus menyebar dan itu tadi adalah episode yang
00:18:41panjang tentang semua itu, saya tahu, tapi saya benar-benar ingin menekankan bahwa Anda harus berupaya membuat sistem Anda
00:18:49aman sebagaimana yang saya bagikan sebelumnya, sebagaimana yang saya bagikan di video ini Anda ingin memastikan bahwa Anda
00:18:56mengurangi bahaya terdampak. Serangan ini sekali lagi tertangkap dengan cepat namun tetap saja ia masih terus menyebar
00:19:05jadi ini belum berakhir dan ada kemungkinan tidak semua serangan akan tertangkap secepat itu
00:19:11di masa depan sebagaimana yang disebutkan mereka sedikit beruntung di sini karena bisa saja lebih sulit untuk mendeteksi
00:19:18serangan ini, maka mungkin kerusakannya akan lebih besar lagi tetapi di sini pun sudah cukup besar dan
00:19:24ini belum berakhir dan kita akan melihat lebih banyak serangan semacam itu saya yakin karena saya sebutkan permukaan serangan
00:19:31menjadi lebih besar dan lebih menarik ada lebih banyak orang yang menulis kode banyak orang yang
00:19:36tidak tahu apa yang mereka lakukan dan AI membantu menjalankan serangan semacam itu jadi ya inilah yang sedang terjadi
00:19:42saat ini jika Anda tidak harus melakukannya mungkin jangan instal apa pun dulu periksa kembali pengaturan Anda dan Anda
00:19:48bisa menemukan semua tautan di bawah jika Anda ingin mendalami lebih jauh jika Anda ingin melihat daftar lengkap
00:19:51paket-paket yang terdampak dan sebagainya

Key Takeaway

Serangan worm pada ekosistem NPM dan Python ini menggunakan teknik keracunan cache GitHub Actions untuk mencuri rahasia sistem dan menerbitkan versi paket berbahaya secara otomatis melalui identitas pengelola yang sah.

Highlights

  • Serangan rantai pasokan (supply chain attack) pada 11 Mei 2026 menargetkan seluruh ekosistem TanStack termasuk query, router, dan start dalam waktu singkat.

  • Malware ini berfungsi sebagai worm yang secara otomatis mencuri token NPM, token GitHub, dan kredensial AWS untuk menyebarkan paket berbahaya lebih lanjut.

  • Infeksi telah menyebar melampaui ekosistem JavaScript (NPM) hingga mencapai paket-paket di ekosistem Python dalam hitungan jam.

  • Fitur 'Age Release Minimum' pada manajer paket seperti Bun dapat mencegah instalasi paket berbahaya yang baru saja diterbitkan secara otomatis.

  • Serangan ini memanfaatkan celah keamanan pada alur kerja CI/CD (GitHub Actions) melalui pola 'pull request target' tanpa perlu mengompromikan mesin pengelola secara langsung.

Timeline

Skala dan Dampak Awal Serangan Rantai Pasokan

  • Paket TanStack diterbitkan dalam versi berbahaya selama jendela waktu 20 menit pada 11 Mei.
  • Malware ini mengeksfiltrasi data sensitif dan kredensial pengguna ke URL eksternal segera setelah terinstal.
  • Serangan meluas dari ekosistem NPM ke Python hanya dalam waktu dua jam setelah deteksi awal.

Serangan ini dikategorikan sebagai ancaman besar karena sifatnya yang menyebar dengan cepat seperti worm. Selain TanStack, paket lain seperti Mistral juga teridentifikasi membawa kode berbahaya tersebut. Pengguna disarankan untuk menunda instalasi paket baru hingga situasi benar-benar terkendali.

Identifikasi Infeksi dan Indikator Kompromi

  • Instalasi paket TanStack pada malam 11 Mei waktu UTC dianggap sebagai indikator utama kompromi sistem.
  • Pemeriksaan hash SHA pada file JavaScript router menjadi metode verifikasi teknis untuk mendeteksi infeksi.
  • Lalu lintas keluar ke URL tertentu dari mesin lokal menandakan data sistem telah dicuri oleh penyerang.

Pengguna yang melakukan instalasi atau pembaruan paket dalam periode serangan harus mengasumsikan mesin mereka telah terkompromi. Selain pengecekan manual pada file, pemantauan jaringan adalah cara efektif untuk melihat apakah malware sedang mengirimkan data ke server penyerang. Daftar paket yang terdampak terus bertambah seiring berjalannya waktu.

Mekanisme Pencurian Data dan Penyebaran Worm

  • Malware memindai lokasi umum di sistem untuk menemukan token GitHub, token NPM, dan rahasia AWS.
  • Kredensial yang dicuri digunakan kembali oleh worm untuk menerbitkan versi berbahaya dari paket lain yang dikelola korban.
  • Alur kerja CI/CD yang menarik dependensi terinfeksi akan mengeksekusi kode berbahaya dan menyebarkannya ke tahap produksi.

Cara kerja utama malware ini adalah pemanenan rahasia (secret harvesting) yang kemudian digunakan untuk eskalasi serangan. Jika seorang pengelola paket terinfeksi, worm akan menggunakan token mereka untuk menyisipkan kode berbahaya ke dalam paket yang mereka kelola. Hal ini menciptakan siklus infeksi yang sulit diputus tanpa pencabutan token secara menyeluruh.

Strategi Perlindungan dan Pengamanan Lingkungan Pengembangan

  • Pengembangan di dalam Virtual Machine atau Dev Container mencegah malware mengakses sistem utama dan rahasia lokal.
  • Layanan manajemen rahasia berbasis cloud seperti Infisical atau Doppler lebih aman dibandingkan menyimpan file .env di hard drive.
  • Pengaturan 'Minimum Release Age' di bunfig.toml memblokir instalasi paket yang belum melewati batas usia keamanan tertentu.

Keamanan sistem dapat ditingkatkan dengan beralih dari kredensial IAM statis ke pendekatan Single Sign-On (SSO) untuk layanan AWS. Penggunaan manajer paket modern seperti Bun atau pnpm juga memberikan perlindungan tambahan melalui pemblokiran skrip post-install secara default. AI kini mempercepat pembuatan kode berbahaya, sehingga metode isolasi lingkungan kerja menjadi sangat krusial.

Analisis Teknis Eksploitasi GitHub Actions

  • Pola 'pull request target' menjalankan alur kerja dalam konteks repositori dasar yang memiliki izin lebih tinggi.
  • Penyerang meracuni cache GitHub Actions dengan menyisipkan dependensi berbahaya melalui perintah 'hash files'.
  • Eksekusi alur kerja normal oleh pengelola secara tidak sengaja memuat cache beracun yang disiapkan oleh penyerang.

Masalah utama terletak pada pembagian konteks cache antara pemicu pull request dari fork dan pemicu push internal. Penyerang membuka pull request berbahaya yang memicu penyimpanan kode jahat ke dalam cache bersama. Saat pengelola melakukan push kode valid, sistem CI/CD menggunakan cache tersebut untuk mempercepat proses, yang justru memasukkan malware ke dalam paket akhir.

Penyalahgunaan Trusted Publishing dan Deteksi Kegagalan

  • Malware mengakses token OIDC berumur pendek dari fitur Trusted Publishing NPM untuk menandatangani paket berbahaya.
  • Ketidaksesuaian antara kegagalan alur kerja GitHub Actions dan terbitnya versi baru paket menjadi kunci deteksi serangan ini.
  • Permukaan serangan perangkat lunak terus meluas seiring meningkatnya volume kode yang dihasilkan secara global.

Meskipun Trusted Publishing dirancang untuk keamanan tinggi, ia tetap rentan jika kode di dalam alur kerja CI/CD itu sendiri sudah terinfeksi. Dalam kasus TanStack, serangan terdeteksi lebih cepat karena adanya anomali teknis di mana paket baru muncul meskipun proses otomatisnya dilaporkan gagal. Keberuntungan dalam deteksi dini ini menekankan perlunya kewaspadaan berkelanjutan terhadap keamanan rantai pasokan.

Community Posts

No posts yet. Be the first to write about this video!

Write about this video