Teku dan Besu telah memperbarui masing-masing gambar Docker mereka setelah insiden eMudhra, karena kunci sertifikat yang lemah membawa risiko bagi perangkat lunak yang terhubung ke layanan eksternal, termasuk beberapa penyebaran validator Ethereum.
- Teku 26.10.3 dan Besu 26.10.2 telah menghapus kepercayaan sertifikat yang terdampak di image Docker karena insiden eMudhra.
- Teku menyatakan, node jaringan utama default tidak terpengaruh, dan tingkat eksposur sebenarnya tergantung pada koneksi HTTPS serta runtime Java yang digunakan oleh operator.
- Risiko yang diungkapkan melibatkan layanan dan operator validator yang ditiru, tanpa laporan eksploitasi dalam pemberitahuan Teku.
Untuk operator, masalah paling langsung saat ini adalah: apakah perangkat lunak mereka akan menerima sertifikat palsu saat menghubungkan ke layanan lain. Jawabannya tergantung pada koneksi yang digunakan dan instalasi Java, sehingga pembaruan klien tidak berarti setiap validator menghadapi risiko yang sama.
Perbarui gambar Docker Teku dan Besu
Tim klien Ethereum telah merilis pembaruan untuk memperbaiki masalah sertifikat yang berasal dari luar blockchain. Perubahan terkait mencakup cara perangkat lunak menentukan keaslian layanan jarak jauh.
Teku 26.10.3 dan Besu 26.10.2 telah menghapus kepercayaan terhadap akar sertifikat yang terpengaruh dari gambar Docker mereka. Rilis ini muncul karena ditemukannya kunci lemah terkait otoritas sertifikat eMudhra.
Bagi operator validator, masalahnya adalah penyerang menyamar sebagai layanan yang terhubung oleh perangkat lunak. Bergantung pada peran layanan tersebut, respons palsu dapat mengganggu tanggung jawab, atau memengaruhi tujuan pembayaran biaya blok tertentu.
Namun, ini tidak berarti setiap validator Ethereum terpapar risiko. Pemberitahuan keamanan Teku menyatakan bahwa node jaringan utama default tidak terpengaruh, dan saat ini tidak ada laporan eksploitasi.
Perbedaannya terletak pada cara pemasangan. Operator yang menggunakan layanan HTTPS eksternal perlu memeriksa koneksi yang mungkin tidak ada dalam deploy komponen sepenuhnya lokal.
Pembaruan ini berlaku untuk lingkungan instalasi tertentu. Gambar Docker setelah patch mencakup modifikasi runtime yang dikemas dalam kontainer, sedangkan perangkat lunak yang diinstal dari arsip mungkin menggunakan Java yang disediakan secara terpisah oleh operator.
Peristiwa ini memengaruhi infrastruktur di sekitar validator, sedangkan aturan konsensus Ethereum tidak berubah.
Mengapa masalah sertifikat bisa berubah menjadi risiko keamanan?
Sertifikat membantu perangkat lunak menentukan apakah ia terhubung ke layanan yang diharapkan. Lembaga penerbit sertifikat terpercaya memberikan jaminan atas identitas yang sesuai dengan sertifikat server.
Mekanisme ini umum ditemukan di situs HTTPS, tetapi juga berlaku untuk aplikasi yang tidak berkomunikasi melalui browser. Layanan latar belakang juga mungkin bergantung pada verifikasi identitas ini.
Lembaga sertifikasi mungkin menggunakan sertifikat perantara di bawah sertifikat akar yang dipercaya. Kunci pribadi yang terkait dengan sertifikat perantara ini harus tetap aman, karena dapat digunakan untuk menerbitkan lebih banyak sertifikat.
Dalam kejadian ini, masalahnya bukan hanya seseorang mendapatkan informasi login biasa ke server. Kunci tengah yang terpengaruh dapat dipulihkan dari informasi yang sudah dipublikasikan.
Tim keamanan Go menyatakan bahwa kelemahan ini memungkinkan pemulihan kunci pribadi pada tingkat mikrodetik. Deskripsi tersebut juga menunjukkan bahwa penyerang kemudian dapat membuat sertifikat untuk domain yang tidak mereka kendalikan.
Jika sebuah aplikasi yang rentan terhadap serangan menganggap sertifikat tersebut akhirnya masih dapat dilacak kembali ke otoritas yang dipercayainya, maka ia mungkin menerimanya. Dengan demikian, pemalsuan identitas dapat melewati pemeriksaan yang seharusnya menolak peniru.
Namun, penyerang masih memerlukan cara tertentu untuk mengintersepsi atau mengalihkan koneksi korban. Kunci lemah tidak secara otomatis membuat mereka muncul di antara setiap pengguna dan setiap server.
Kondisi ini mempersempit cara serangan terjadi, tetapi tidak membuat pencabutan sertifikat menjadi tidak berbahaya. Selama perangkat lunak menganggap peniru sebagai titik akhir yang sah, intersepsi jaringan akan menjadi lebih berbahaya.
Penelitian dari Kudelski Security meninjau tingkat sertifikat yang terdampak. Masalahnya adalah, perangkat lunak mungkin menerima sertifikat yang dikeluarkan oleh kunci yang dapat direproduksi oleh penyerang.
eMudhra menyalahkan kunci lemah pada kesalahan pemrosesan
Pernyataan insiden eMudhra menyatakan bahwa seorang peneliti melaporkan 8 kunci tengah lemah pada 17 Oktober. Perusahaan mencabut 8 kunci tersebut pada hari berikutnya.
Perusahaan menyatakan bahwa sertifikat perantara ini dihasilkan dalam upacara kunci pada 30 April 2025. Menurut perusahaan, langkah wrap dan unwrap yang cacat menghasilkan salinan lemah di luar kunci kuat aslinya.
Perusahaan menyatakan menggunakan hardware security module yang telah bersertifikat. Penjelasannya menyalahkan kegagalan pada salah satu langkah proses pendukung, bukan karena kurangnya perangkat semacam itu.
Perusahaan juga menyatakan bahwa 7 sertifikat perantara tersebut tidak pernah digunakan di lingkungan produksi, dan 1 sertifikat sisanya juga belum diterbitkan. Perusahaan menegaskan bahwa insiden ini tidak menyebabkan infrastruktur disusupi atau kebocoran data.
Pernyataan-pernyataan ini menjelaskan deskripsi eMudhra tentang operasi internalnya. Namun, pemasok perangkat lunak masih harus menghadapi kemungkinan lain: pihak lain dapat memanfaatkan kunci yang dapat dipulihkan.
Sistem sertifikat tidak dapat bergantung hanya pada janji dari pihak operasional asli untuk tidak menerbitkan konten apa pun lagi. Begitu pihak lain juga dapat mereproduksi kunci tanda tangan tertentu, jaminan tersebut tidak lagi dapat mengendalikan semua sertifikat yang mungkin dibuat.
Oleh karena itu, tindakan respons telah melampaui perusahaan yang menghasilkan kunci. Produsen browser, pemasok sistem operasi, dan tim bahasa pemrograman perlu mempertimbangkan perangkat lunak apa yang akan diterima oleh pengguna mereka.
Perbaikan ini akan disampaikan kepada pengguna melalui pembaruan yang berbeda. Browser mungkin menerima daftar blokir, sementara aplikasi Java independen lainnya mungkin masih menggunakan kumpulan sertifikat tepercaya lama.
Kunci lemah dan aplikasi yang menerima kunci tersebut adalah dua bagian berbeda dari masalah yang sama. Revokasi sertifikat menyelesaikan masalah pada tingkat catatan institusi, sementara klien masih memerlukan cara yang andal untuk mengenali jalur kepercayaan yang terdampak yang harus ditolak.
Layanan eksternal membawa berbagai risiko bagi validator
Node Ethereum terdiri dari perangkat lunak yang menjalankan berbagai tugas. Dokumentasi klien Ethereum membedakan antara execution client dan consensus client: yang pertama menangani eksekusi transaksi dan status, sedangkan yang kedua mengikuti konsensus proof-of-stake.
Perangkat lunak validator menambahkan tanggung jawab untuk mengusulkan blok dan membuktikan rantai. Operator dapat menjalankan komponen-komponen ini secara lokal, atau menghubungkan sebagian melalui layanan eksternal.
Teku adalah klien konsensus, Besu adalah klien eksekusi. Keduanya menggunakan Java, yang merupakan alasan mengapa kepercayaan sertifikat runtime terkait dengan rilis mereka.
Layanan di luar mesin lokal akan menambahkan verifikasi identitas untuk pengaturan ini. Perangkat lunak perlu memastikan bahwa endpoint yang merespons permintaan adalah penyedia yang diharapkan.
Misalnya, operator mungkin menggunakan layanan tanda tangan jarak jauh, bukan menyimpan operasi tanda tangan dalam proses yang sama. Ada juga yang mengandalkan endpoint eksternal untuk menyediakan data atau layanan pembangunan blok.
Seberapa besar kerusakan yang dapat disebabkan oleh peniru tergantung pada apa yang diizinkan dilakukan oleh layanan tersebut. Layanan yang hanya menerima data pemantauan memiliki risiko yang berbeda dibandingkan layanan penyedia informasi yang terlibat dalam keputusan tanda tangan.
Jalur jaringan juga penting. Koneksi yang melewati infrastruktur publik memiliki peluang penyadapan yang berbeda dibandingkan dengan komponen yang hanya berada di dalam satu host atau jaringan pribadi yang dikendalikan ketat.
Jaringan pribadi tidak dapat mencegah semua kegagalan, tetapi dapat mengurangi peluang penyerang mendapatkan posisi yang diperlukan untuk mengganggu lalu lintas.
Oleh karena itu, nama klien saja tidak dapat menentukan apakah terpapar atau tidak. Perangkat lunak yang sama dapat dideploy di lingkungan yang menggunakan endpoint, trust store, dan kontrol akses yang berbeda.
Pertanyaan yang benar-benar perlu dijawab adalah: koneksi mana yang melewati jalur yang terdampak untuk menerima sertifikat. Setelah hal ini jelas, operator dapat mengevaluasi seberapa besar otoritas yang seharusnya dimiliki oleh layanan yang disaingkan dalam operasi verifikator.
Mengapa gambar Docker dan instalasi arsip berbeda?
Docker image mengemas aplikasi bersama dengan lingkungan yang diperlukan untuk menjalankannya, yang mungkin mencakup Java runtime dan sertifikat yang dipercaya oleh runtime tersebut.
Memperbarui Java di host tidak akan secara otomatis mengganti Java yang ada di dalam image. Container masih mungkin terus menggunakan file yang dikemas sendiri.
Ini adalah alasan mengapa rilis klien secara khusus menyebutkan perubahan Docker. Dokumentasi Teku menyatakan bahwa basis gambar Eclipse Temurin saat itu belum mencakup penghapusan terkait, sehingga gambar klien dimodifikasi secara langsung.
Rilisan Besu juga menyatakan bahwa penghapusan sertifikat berlaku untuk gambar Docker, dan secara jelas meminta pengguna yang menginstal secara manual untuk memeriksa distribusi Java yang mereka sediakan.
Arsip instalasi akan menyerahkan tanggung jawab ini kepada operator. Klien Ethereum mungkin telah diperbarui, tetapi runtime terpisahnya mungkin masih berisi penyimpanan sertifikat lama.
Sebaliknya, selama pemeliharaan, perbedaan serupa juga dapat terjadi. Mengganti runtime host akan memengaruhi proses yang menggunakan runtime tersebut, tetapi tidak akan memengaruhi instalasi lain yang menggunakan jalur Java berbeda.
Peristiwa Oracle merekomendasikan pengguna untuk memperbarui runtime yang terdampak, atau mengikuti alternatif yang diberikan dalam dokumentasinya. Ini juga meminta untuk me-restart instance yang sedang berjalan, serta mempertimbangkan setiap instalasi independen secara terpisah.
Ini membuat proses yang sedang berjalan lebih penting daripada versi yang diunduh. Server dapat berisi file yang telah diperbaiki, tetapi proses lama akan terus berjalan hingga diganti atau di-restart.
Penyimpanan sertifikat khusus juga menambahkan variasi lain. Sebuah organisasi mungkin menggunakan repositori sertifikat yang dipelihara sendiri untuk layanan mereka, bukan hanya repositori sertifikat bawaan Java.
Tugas sebenarnya adalah menentukan apa yang sebenarnya digunakan oleh klien. Cara instalasi, lokasi runtime, dan konfigurasi kepercayaan secara bersama-sama menentukan apakah perbaikan yang dirilis telah sampai ke koneksi yang membutuhkannya.
Perbedaan pemeriksaan pencabutan di berbagai aplikasi
Revokasi berarti sertifikat tidak boleh lagi diterima. Namun, ini tidak menjamin setiap aplikasi akan memeriksa informasi revokasi terbaru sebelum membangun koneksi.
Cara berbagai aplikasi memperoleh informasi ini juga berbeda. Beberapa akan meng查询 layanan online, beberapa menggunakan daftar blokir yang disediakan oleh pemasok, dan beberapa lainnya terutama bergantung pada sertifikat di lokal trust store.
Respons tim Go menjelaskan mengapa pemasok runtime mungkin perlu terlibat langsung. Tim tersebut meluncurkan rilis keamanan darurat pada 19 Oktober dan menyatakan bahwa versi perbaikan telah disediakan sekitar 7,5 jam setelah menerima pemberitahuan.
Tindakan ini memblokir jalur sertifikat yang terpengaruh yang terlibat dalam aplikasi yang menggunakan verifikasi Go terkait. Pengguna Java perlu mendapatkan perlindungan melalui runtime dan pengaturan kepercayaan mereka sendiri.
Pemberitahuan Teku menyatakan bahwa Java secara default tidak memeriksa revokasi. Ini juga alasan mengapa meskipun eMudhra telah mencabut sertifikat menengah ini, tetap diperlukan untuk menghapus kepercayaan secara lokal.
Penghapusan sertifikat akar dan pemblokiran sertifikat perantara juga dapat berlaku pada tingkat yang berbeda. Yang pertama menolak satu jalur yang rusak tertentu, sedangkan yang kedua dapat menolak rantai sertifikat yang lebih luas yang menuju ke sertifikat akar yang dihapus.
Implementasi yang benar menjadi tanggung jawab pemasok dan organisasi yang memelihara aplikasi. Mengambil tindakan sementara untuk menonaktifkan verifikasi identitas hanya akan menghilangkan perlindungan, bukan menyelesaikan masalah kepercayaan.
Layanan sah juga mungkin perlu disesuaikan. Jika sertifikat mereka bergantung pada jalur yang sekarang ditolak oleh klien, maka penyedia layanan harus menyediakan alternatif yang dapat diterima, bukan mengandalkan pengguna untuk memulihkan kepercayaan yang tidak aman.
Ini juga menjelaskan mengapa insiden sertifikat dapat berlangsung selama beberapa hari. Deteksi mungkin segera terjadi, tetapi perlindungan akan diterapkan secara bertahap melalui proses rilis dan pemeliharaan yang berbeda pada browser, aplikasi terkemas, dan infrastruktur pribadi.
Bagi operator validator, hasil kunci adalah apakah koneksi terkait telah menolak identitas yang tidak dipercaya. Pemberitahuan revokasi di tempat lain dalam ekosistem perangkat lunak tidak membuktikan bahwa proses node telah mencapai hasil ini.
Apakah hadiah dan staking validator terpapar dengan cara yang sama?
Staking, tugas penandatanganan, dan pembayaran biaya validator saling terkait, tetapi mereka diatur oleh mekanisme yang berbeda. Masalah yang memengaruhi salah satu aspek tidak boleh secara otomatis dianggap sebagai kendali atas semua aspek tersebut.
Dokumentasi staking Ethereum menjelaskan bahwa validator mendapatkan reward dengan memenuhi tanggung jawabnya, dan akan dikenai sanksi karena offline atau perilaku tidak tepat yang dapat dibuktikan. Otoritas tanda tangan dan otoritas penarikan memiliki peran berbeda dalam sistem.
Kunci sertifikat termasuk dalam sistem identitas yang digunakan untuk koneksi. Ini bukan kunci tanda tangan pribadi validator, dan tidak secara langsung mengungkapkan kredensial untuk menarik ETH yang telah di-stake.
Namun, layanan yang ditiru tetap dapat memengaruhi perilaku validator. Dampaknya tergantung pada permintaan atau respons apa yang ditangani oleh layanan tersebut, serta pemeriksaan tambahan apa yang masih dipertahankan.
Proposal blok mencakup penerima biaya untuk pembayaran terkait. Jika suatu jalur dapat memodifikasi proposal atau konfigurasi, hal itu dapat menimbulkan konsekuensi tanpa perlu mengendalikan seluruh penjaminan.
Layanan tanda tangan juga menghadirkan sejumlah masalah lain karena terlibat dalam otorisasi perilaku validator. Langkah-langkah perlindungannya sendiri, termasuk pembatasan terhadap permintaan dan jaminan untuk mencegah tanda tangan yang bertentangan, akan memengaruhi sejauh mana penyerang dapat bertindak.
Kegagalan tugas akibat gangguan layanan juga merupakan konsekuensi yang mungkin terjadi. Bahkan tanpa berhasil memindahkan pembayaran apa pun, penyerang dapat mengurangi hadiah dengan hanya mencegah respons yang benar.
Dampak keuangan dari hasil-hasil ini tidak sama. Kehilangan kesempatan untuk mengusulkan blok, hukuman offline biasa, dan hukuman slashing tidak dapat disamakan.
Deskripsi pengumuman klien menjelaskan kemungkinan konsekuensi yang dapat terjadi di bawah konfigurasi yang terdampak, tetapi tidak membuktikan bahwa setiap operator mengalami konsekuensi tersebut, maupun bahwa jumlah ETH tertentu telah dicuri.
Bagi pemegang yang menggunakan layanan staking, yang benar-benar relevan adalah implementasi nyata dari layanan tersebut. Jumlah ETH yang dikelola tidak menunjukkan layanan jarak jauh atau repositori sertifikat apa yang digunakan oleh operatornya.
Validator juga bergantung pada perangkat lunak di luar Ethereum
Aturan jaringan Ethereum hanyalah salah satu bagian yang bergantung oleh operator. Perangkat keras, runtime, hosting, konfigurasi, dan layanan eksternal akan memengaruhi apakah validator dapat memenuhi tanggung jawabnya dengan benar.
Otoritas sertifikat berada di luar protokol Ethereum, tetapi kegagalannya menjadi relevan ketika perangkat lunak validator bergantung padanya untuk mengidentifikasi layanan. Hanya dengan ini saja, sudah cukup untuk membawa masalah keamanan internet umum ke dalam infrastruktur staking.
Keragaman klien masih bernilai karena implementasi berbeda dapat mengurangi ketergantungan pada satu kode sumber. Namun, ini tidak berarti setiap dependensi bersifat independen.
Dua klien dapat menjalankan runtime bahasa pemrograman yang sama. Operator yang berbeda juga mungkin menggunakan penyedia hosting, layanan tanda tangan, atau infrastruktur pembangunan blok yang sama.
Komponen bersama ini akan membentuk permukaan serangan yang sama, meskipun perangkat lunak Ethereum berbeda. Oleh karena itu, untuk memahami situasi penyebaran, tidak cukup hanya melihat jumlah merek klien.
Outsourcing juga membawa trade-off. Layanan tanda tangan khusus mungkin meningkatkan cara perlindungan kunci, tetapi juga membuat koneksi otentikasi dengan layanan tersebut menjadi lebih penting.
Menjalankan secara lokal juga memiliki persyaratan pemeliharaan sendiri. Menempatkan komponen pada mesin yang sama dapat mengurangi sebagian paparan jaringan, tetapi operator tetap perlu mengelola pembaruan perangkat lunak dan akses ke mesin tersebut.
Kejadian ini tidak secara otomatis memberikan arsitektur paling aman dalam semua situasi. Ini menunjukkan bahwa harus memahami dan memelihara tanggung jawab di sekitar setiap koneksi.
Perbedaan ini juga penting bagi pengguna ETH biasa. Pembaruan sertifikat pada infrastruktur node tidak berarti setiap dompet harus memindahkan dana, atau bahwa saldo akun Ethereum telah berubah.
Tindakan terkait merupakan tanggung jawab operator perangkat lunak yang terdampak. Hanya mereka yang memiliki kemampuan untuk mengidentifikasi runtime, endpoint, dan pengaturan kepercayaan yang terlibat, lalu menerapkan panduan terkait dari pemasok ke sistem yang sedang membangun koneksi tersebut.
Operator perlu menerapkan dan memeriksa pembaruan
Pembaruan ini memberi operator cara untuk menghapus jalur kepercayaan yang terdampak dari gambar Docker yang didukung. Pengguna arsip perlu menangani runtime terpisah sesuai panduan pemasok Java masing-masing.
Patch yang tersedia hanyalah langkah pertama. Lingkungan yang diperbarui masih perlu dijalankan secara nyata dan memastikan konfigurasi serta layanan berfungsi sesuai harapan.
Bagi penyedia layanan, gangguan yang disebabkan oleh sertifikat yang baru ditolak mungkin memerlukan penggantian sertifikat pada endpoint. Saat memulihkan layanan, verifikasi identitas harus tetap dipertahankan, bukan diabaikan.
Pengungkapan selanjutnya mungkin akan memperjelas dampak lebih lanjut. Operator mungkin akan mengidentifikasi konfigurasi yang menerima rantai sertifikat yang terdampak, atau melaporkan insiden yang melibatkan layanan tertentu.
Saat ini, laporan notifikasi Teku tidak dimanfaatkan dan membedakan penggunaan jaringan utama default dari koneksi eksternal yang terpengaruh. Ini adalah dasar paling jelas untuk menggambarkan permukaan serangan Ethereum saat ini.
Operator yang terdampak memiliki alasan untuk memperbarui. Kerugian finansial apa pun tergantung pada layanan mana yang ditiru oleh penyerang, apakah lalu lintas diintersepsi, dan apa yang diizinkan oleh validator untuk layanan tersebut.
Apa yang perlu diperhatikan
- Pembaruan klien: Pantau rilis Teku dan Besu, serta pastikan Anda menjalankan versi yang telah diperbaiki.
- Sertifikat Java: Lihat panduan pemasok untuk runtime Java dan perpustakaan sertifikat yang digunakan pada setiap instalasi.
- Tautan eksternal: Tinjau tautan HTTPS yang mengarah ke layanan tanda tangan jarak jauh, data, dan pembangunan blok.
- Pemberitahuan keamanan: Perhatikan konfirmasi serangan atau penjelasan lebih lanjut yang dikeluarkan oleh tim klien dan pemasok Java.
Pertanyaan Umum
Apa itu peristiwa eMudhra?
Insiden ini melibatkan kunci pribadi lemah yang terkait dengan sertifikat perantara dari otoritas sertifikat eMudhra. Para peneliti menemukan bahwa kunci-kunci ini dapat dipulihkan dari informasi publik, sehingga memungkinkan pihak lain membuat sertifikat domain yang tidak mereka kendalikan. Perangkat lunak yang mempercayai jalur sertifikat yang terpengaruh mungkin menerima identitas palsu tersebut. Namun, penyerang masih memerlukan cara tertentu untuk mengintersepsi atau mengalihkan koneksi agar dapat menyamar sebagai layanan target.
Apakah konsensus Ethereum gagal?
Tidak. Masalah dalam laporan berkaitan dengan cara perangkat lunak memeriksa identitas layanan eksternal, bukan aturan konsensus Ethereum di blockchain. Pembaruan klien mengubah kepercayaan sertifikat dalam lingkungan perangkat lunak yang terdampak. Beberapa deploy validator masih dapat menghadapi risiko operasional jika layanan eksternal disamar. Kemungkinan ini bergantung pada koneksi dan peran layanan, dan tidak berarti aturan konsensus Ethereum telah dilanggar.
Klien mana yang diperbarui?
Teku 26.10.3 dan Besu 26.10.2 telah memperbarui gambar Docker mereka untuk menghapus sertifikat yang terpengaruh. Teku adalah klien konsensus, sedangkan Besu adalah klien eksekusi, keduanya menggunakan Java. Cara instalasi penting karena perubahan ini berlaku untuk lingkungan yang disediakan dalam gambar-gambar tersebut. Operator yang menginstal arsip klien dan menyediakan runtime Java sendiri perlu memeriksa panduan untuk runtime tersebut secara terpisah.
Apakah semua validator akan terdampak?
Tidak. Pemberitahuan Teku menyatakan bahwa node jaringan utama default tidak terpengaruh. Risiko tergantung pada apakah suatu deploy melakukan koneksi HTTPS eksternal terkait, dan apakah pemeriksaan sertifikatnya menerima jalur kepercayaan yang terpengaruh. Operator yang berbeda dapat menjalankan klien yang sama di layanan, versi Java, dan perpustakaan sertifikat yang berbeda. Oleh karena itu, nama klien atau jumlah ETH yang di-stake tidak dapat menunjukkan apakah validator tertentu terpapar.
Apakah pembaruan Docker dapat mencakup semua metode instalasi?
Tidak. Gambar Docker yang telah dipatch akan memperbarui lingkungan yang dikemas di dalam gambar tersebut, tetapi instalasi arsip mungkin menggunakan Java yang disediakan secara terpisah oleh operator. Kontainer atau layanan lain juga mungkin memiliki runtime sendiri. Operator perlu mengidentifikasi metode instalasi apa yang digunakan oleh proses yang sedang berjalan, dan mengikuti petunjuk pemasoknya. File yang telah dipatch di server tidak dapat melindungi proses yang masih berjalan di lingkungan lama.
Apakah telah dikonfirmasi dimanfaatkan?
Pada titik waktu yang disebutkan dalam artikel ini, notifikasi Teku tidak melaporkan adanya eksploitasi. Pengungkapan terkait menggambarkan sebuah kelemahan dan kemungkinan konsekuensinya, bukan bukti bahwa penyerang telah menggunakannya untuk validator. Perbedaan ini penting saat membahas kerugian. Adanya jalur potensial untuk peniruan layanan tidak sama dengan tanggung jawab tanda tangan dimanipulasi, pembayaran biaya dialihkan, atau ETH yang di-stake dicuri.
Will validator deposits be automatically exposed?
Tidak. Kunci tanda tangan sertifikat berbeda dari kunci tanda tangan validator, dan juga berbeda dari kredensial yang mengontrol penarikan. Pemulihan kunci sertifikat yang terdampak tidak akan secara otomatis mengungkapkan kunci yang diperlukan untuk menarik ETH yang di-stake. Layanan yang disalahgunakan masih dapat mengganggu tanggung jawab atau memengaruhi informasi yang digunakan oleh validator, tergantung pada cara penyebarannya. Konsekuensi potensial terhadap layanan ini harus dievaluasi, bukan dianggap sebagai akses otomatis terhadap seluruh deposit.
Apa yang harus dilakukan oleh operator?
Operator harus mengikuti rilis Teku atau Besu yang relevan, serta panduan dari versi Java mereka. Perlu mengidentifikasi runtime dan repositori sertifikat yang digunakan oleh setiap proses yang terdampak, termasuk bagian yang disediakan dalam kontainer. Setelah menerapkan pembaruan yang disarankan, pastikan layanan yang diperbarui sedang berjalan dan koneksi yang diperlukan masih berfungsi dengan baik. Menonaktifkan pemeriksaan sertifikat untuk memulihkan koneksi yang gagal akan menghilangkan perlindungan yang seharusnya disediakan oleh pemeriksaan tersebut.