TanStack & BANYAK paket lainnya terdampak - analisis & bedah tuntas
MMaximilian Schwarzmüller
컴퓨터/소프트웨어경제 뉴스AI/미래기술
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
Community Posts
No posts yet. Be the first to write about this video!
Write about this video