Bug RCE Tingkat Tinggi Ditemukan di Basis Data Apache Cassandra Populer

Researchers telah membagikan detail tentang bug keamanan tingkat tinggi yang sekarang telah ditambal di basis data terdistribusi NoSQL sumber terbuka Apache Cassandra yang mudah dieksploitasi dan, jika dibiarkan tidak ditambal, dapat memungkinkan penyerang mendapatkan eksekusi kode jarak jauh (RCE).

Bug, yang melibatkan bagaimana Cassandra membuat fungsi yang ditentukan pengguna (UDF) untuk melakukan pemrosesan data kustom, dilacak sebagai CVE-2021-44521, dengan peringkat tingkat keparahan tinggi 8.4.

Kerentanan ditemukan oleh tim Riset Keamanan JFrog. Dalam artikel hari Selasa, peneliti keamanan JFrog Omer Kaspi mengatakan bahwa di sisi positifnya, satu-satunya sistem Cassandra yang rentan terhadap cacat adalah sistem dengan konfigurasi tertentu, non-standar dan, khususnya, tidak direkomendasikan. untuk dieksploitasi, JFrog telah membuat eksploitasi proof-of-concept (PoC). Kelemahan lain: Basis data ini ada di mana-mana.

“Kerentanan keamanan Apache ini mudah dieksploitasi dan berpotensi mendatangkan malapetaka pada sistem, tetapi untungnya hanya bermanifestasi dalam konfigurasi non-default Cassandra,” kata Kaspi dalam tulisannya.

What, dan Di mana tepatnya Cassandra?

Cassandra adalah basis data terdistribusi yang sangat skalabel dan banyak digunakan yang dikenal efisien dan sangat tersedia, mengingat basis data tersebut tidak memiliki satu titik kegagalan: nilai tambah yang besar untuk bisnis yang tidak dapat kehilangan data atau menanggung downtime sistem. Ia juga dikenal mampu menangani volume data yang sangat besar di beberapa server, dengan penulisan cepat dari sejumlah besar data yang tidak menghambat efisiensi bacanya.

“Cassandra adalah basis data NoSQL terdistribusi yang sangat skalabel dan sangat populer karena untuk manfaat dari sifatnya yang terdistribusi,” kata Kaspi.

Dengan demikian, ini digunakan oleh perusahaan dengan nama besar dan besar, kata Kaspi, termasuk Netflix, Twitter, Urban Airship, Constant Contact, Reddit, Cisco, OpenX, Digg, CloudKick, Ooyala dan banyak lagi. Peneliti menambahkan bahwa Cassandra juga sangat populer di DevOps dan lingkaran pengembangan cloud-native, “seperti yang dapat dilihat dari dukungannya dalam proyek-proyek CNCF [cloud native Computing Foundation] (seperti Jaeger).”

(Jaeger adalah open-source , platform pelacakan terdistribusi ujung ke ujung yang dirancang untuk memantau dan memecahkan masalah transaksi dalam sistem terdistribusi yang kompleks.)

“Beberapa perusahaan bahkan menyediakan solusi turnkey berbasis cloud berdasarkan Cassandra, seperti DataStax (DBaaS multi-cloud tanpa server),” Kaspi menunjukkan.

Menggali Risiko Akan Menjadi Kesulitan Besar

Mengingat popularitas Cassandra, fakta bahwa cacat memerlukan pengaturan konfigurasi pengguna non-default untuk dieksploitasi mungkin tidak terlalu menghibur, pakar keamanan mengatakan kepada Threatpost.

John Bambenek, pemburu ancaman utama di perusahaan operasi keamanan dan TI digital Netenrich, mengatakan kepada Threatpost pada hari Rabu bahwa ia mencurigai bahwa pengaturan non-default adalah “umum di banyak aplikasi di seluruh dunia.”n bsp
Situasinya tidak terlihat seburuk Log4j, tetapi masih berpotensi meluas, dan itu akan menjadi tugas untuk menggali instalasi yang rentan, kata Bambenek melalui email. “Sayangnya, tidak ada cara untuk mengetahui secara pasti berapa banyak instalasi yang rentan, dan kemungkinan jenis kerentanan ini akan dilewatkan oleh pemindai kerentanan otomatis,” katanya. “Perusahaan harus masuk ke file konfigurasi setiap instance Cassandra untuk menentukan apa risikonya.”

Casey Bisson, kepala hubungan produk dan pengembang di penyedia solusi keamanan kode BluBracket, mengatakan kepada Threatpost bahwa masalah ini dapat memiliki “dampak yang luas. dengan konsekuensi yang sangat serius”, seperti dalam, “Aktor ancaman mungkin dapat membaca atau memanipulasi data sensitif dalam konfigurasi yang rentan.”

Bisson menyarankan potensi bahaya lain: Jika aktor ancaman mendapatkan akses tulis ke konfigurasi instans database, mereka dapat mengaktifkan kerentanan tanpa disadari oleh operator.

Inti Masalah: Penggunaan JavaScript atas Mesin Nashorn

Saat membuat UDF untuk pemrosesan data khusus, Cassandra dapat menulisnya secara default di Java dan JavaScript. Ketika ditulis dalam JavaScript, Cassandra menggunakan mesin Nashorn di Java Runtime Environment (JRE): mesin JavaScript yang berjalan di atas Java Virtual Machine (JVM).

Di sinilah letak masalahnya: “Nashorn tidak dijamin akan aman saat menerima kode yang tidak dipercaya. Oleh karena itu, layanan apa pun yang memungkinkan perilaku seperti itu harus selalu membungkus eksekusi Nashorn di kotak pasir, ”menurut artikel JFrog. “Misalnya, menjalankan kode JavaScript Nashorn berikut memungkinkan eksekusi perintah shell arbitrer – java.lang.Runtime.getRuntime().exec(“touch hacked”).

Beberapa proyek, seperti NashornEscape, mengimplementasikan sandbox untuk mengamankan kode Nashorn eksekusi, Kaspi menjelaskan.

“Mesin Nashorn memberikan akses ke kelas Java arbitrer dengan menggunakan Java.type. Misalnya: var System = Java.type(“java.lang.System”) akan memungkinkan kita untuk mengakses paket java.lang.System dengan menggunakan variabel System,” lanjutnya.

Pengguna dengan izin yang memadai dapat membuat fungsi arbitrer dengan menggunakan fungsi create query.

Saat meneliti implementasi kotak pasir Cassandra UDF, para peneliti menyadari bahwa campuran opsi konfigurasi tertentu (non-default) dapat memungkinkan mereka untuk menyalahgunakan mesin Nashorn, keluar dari kotak pasir dan mencapai RCE: kerentanan yang dilaporkan sebagai CVE-2021 -44521.

Mitigation dan Fix

JFrog sangat menyarankan agar semua pengguna Apache Cassandra meningkatkan ke salah satu versi berikut, yang menyelesaikan bug: pengguna

3.0.x harus meningkatkan ke 3.0.26

3.11.x pengguna harus meningkatkan ke 3.11.12

4. Pengguna 0.x harus meningkatkan ke 4.0.2

Untuk pengguna yang tidak dapat memperbarui instans mereka, JFrog merekomendasikan mitigasi berikut:

<

ul>