Awan Publik & Tanggung Jawab Bersama: Pelajaran dari Pengungkapan Kerentanan

Pergerakan data dan aplikasi yang tak terhindarkan ke cloud yang dimulai beberapa tahun lalu dan dipercepat selama pandemi tidak menunjukkan tanda-tanda melambat. Alasan transformasi ini didorong oleh keinginan untuk melakukan outsourcing fungsi non-kritis (membangun dan memelihara pusat data, menjalankan dan menambal paket perangkat lunak standar) dan untuk mencapai kelincahan bisnis (meningkatkan skala, kemampuan untuk mengalihkan fokus dengan cepat sesuai dengan kondisi pasar ).

Beberapa migrasi ini adalah ke cloud publik seperti Amazon Web Services (AWS) dan Microsoft Azure. Platform ini telah membawa gagasan “model tanggung jawab bersama” ke depan, terkait dengan keamanan dan kepatuhan dari solusi keseluruhan. Dalam artikel ini, saya mempertimbangkan model tanggung jawab bersama cloud publik melalui perspektif beberapa kerentanan keamanan baru-baru ini yang ditemukan di platform cloud publik, dan konsekuensinya terhadap pengguna. hebat dalam memperkuat gambar perangkat lunak yang mereka suplai ke perusahaan.

Model Tanggung Jawab Bersama

Sebagai gambar bernilai seribu kata, jadi inilah infografis untuk model tanggung jawab bersama AWS; dan ini untuk Microsoft Azure. Kedua model mencoba untuk berkomunikasi bahwa “kami mengurus dasar-dasar sementara Anda mengurus apa yang di bawah kendali Anda.” Dengan kata lain, AWS akan memastikan bahwa bucket S3 hanya dapat diakses sesuai dengan kebijakan yang mengatur penggunaannya – dan pelanggan bertanggung jawab untuk menetapkan kebijakan yang sesuai dengan data yang disimpan di sana. Saat memberikan layanan platform-as-a-service (PaaS) di Azure, tanggung jawab Microsoft adalah memastikan bahwa OS yang digunakan untuk memberikan layanan ditambal dan dikeraskan.

Sekarang mari kita pertimbangkan bagaimana model ini bekerja dalam kehidupan nyata dengan melihat tiga bug keamanan dan bagaimana hal itu memengaruhi pelanggan, yang dapat kita cirikan sebagai yang baik, yang buruk, dan yang jelek.

Kebaikan…

Kerentanan pelarian wadah memungkinkan eksploitasi untuk bergerak melampaui wadah yang sebelumnya telah dibobol penyerang. Ini mirip dengan penyerang yang membuat exploit untuk melarikan diri dari mesin virtual (VM) dan masuk ke hypervisor – sehingga mendapatkan akses ke konten OS yang mendasarinya dan VM lain yang berjalan di bawah hypervisor.

yang sama Contohnya adalah CVE-2019-5736 , bug di RunC, proyek blok bangunan untuk teknologi kontainer yang digunakan oleh banyak perusahaan serta penyedia cloud publik. Pada tahun 2019, ini menambal kerentanan yang memungkinkan eksekusi kode tingkat root, pelepasan kontainer, dan akses ke sistem file host.

Meskipun masalah ini dilaporkan lebih dari dua tahun lalu, ini adalah ilustrasi kasus di mana model tanggung jawab bersama bekerja untuk keuntungan pelanggan cloud publik. Kerentanan dan eksploitasi yang menyertainya diungkapkan pada 11 Februari 2019, bertepatan dengan semua penyedia layanan cloud utama menambal kerentanan. Organisasi yang menjalankan container di pusat data mereka sendiri harus berjuang untuk menambal gambar OS container mereka.

Yang Buruk…

Baru-baru ini, pada bulan Agustus, Microsoft mengumumkan kerentanan yang dilaporkan di Azure Cosmos DB, database NoSQL yang dapat diskalakan yang dikirimkan dalam model PaaS. Kerentanan ada di fitur Jupyter Notebook dari Cosmos DB dan dengan demikian hanya memengaruhi pelanggan yang mengaktifkan fitur tersebut. Sayangnya, fitur Notebook Jupyter telah diaktifkan secara otomatis untuk semua DB Cosmos yang dibuat setelah Februari tahun ini, sehingga bahkan membuat pelanggan yang tidak menggunakan fitur tersebut terkena potensi serangan.

Layanan Cosmos DB secara efektif multi-penyewa. Dengan demikian, data dari beberapa pelanggan digabungkan bersama dalam contoh layanan yang sama. Akses ke data tertentu dibatasi oleh konstruksi perangkat lunak sederhana, yang ditumbangkan dalam kasus ini. Ini berarti penyerang dapat mendaftar untuk akun Azure, menjalankan instans DB Cosmos, dan mengeksploitasinya untuk mengakses data dari semua instans pelanggan lainnya.

Ini adalah contoh kerentanan yang hanya ditemukan di cloud, sebagaimana adanya dalam layanan Azure PaaS yang dipesan lebih dahulu. Dan itu menyoroti fakta bahwa hanya karena perusahaan tidak secara aktif menggunakan fitur tertentu (Jupyter Notebooks), itu tidak berarti itu tidak terkena kerentanan dalam fitur itu.

…dan Ugly

Pada bulan September, Microsoft mengungkapkan serangkaian kerentanan terkait dengan agen Open Management Infrastructure (OMI) yang disertakan dalam image mesin virtual Linux tertentu yang dipasoknya ke pelanggan.

Agen OMI disertakan dalam image VM yang dipasok ke pelanggan berdasarkan layanan Azure yang ingin digunakan pelanggan. Namun Microsoft tidak mendokumentasikan keberadaan agen — meskipun agen berjalan pada tingkat hak istimewa setinggi mungkin. Dalam beberapa kasus (dengan layanan Azure tertentu diaktifkan), ia menerima koneksi melalui HTTPS di internet.

Secara kolektif dijuluki “OMIGOD,” kelompok empat kerentanan termasuk satu kritis yang dinilai 9,8 dari kemungkinan 10 pada skala keparahan bug CVSS ; itu memungkinkan eksekusi kode jarak jauh.

Ini adalah kasus di mana kurangnya transparansi dalam jenis rantai pasokan perangkat lunak yang berbeda (gambar VM stok yang disediakan oleh penyedia layanan cloud) membuka VM yang digunakan oleh pelanggan ke serangan yang sangat konsekuensial. Seolah-olah untuk memperkuat poin itu, serangan terhadap kerentanan ini dimulai segera setelah pengungkapan kerentanan dan mitigasi/penambalan harus menjadi urusan yang terkoordinasi – dengan Microsoft menambal gambar Linux yang disediakannya dan pelanggan perlu menambal versi gambar lama yang sudah berjalan .

Takeaways

Berada di cloud publik adalah hal yang baik ketika kerentanan luas seperti pelarian kontainer ditemukan. Penyedia layanan cloud umumnya hebat dalam mengurangi masalah seperti itu dalam skala besar dan mitigasi sering kali melibatkan sedikit pekerjaan oleh pelanggan mereka. Namun, ada juga risiko keamanan yang signifikan saat menjalankan beban kerja di cloud publik.

Tidak ada jaminan bahwa layanan yang diberikan dalam model PaaS diimplementasikan dengan cara yang keras dan aman. Ada juga insentif besar bagi penyerang untuk mengeluarkan energi untuk mencoba masuk ke layanan seperti kerentanan yang ditemukan dengan mudah dimanfaatkan di sejumlah besar target.

Selanjutnya, insentif dari penyedia layanan cloud (untuk menghilangkan hambatan yang menghalangi penggunaan lebih banyak ) dan pengguna (untuk mengaktifkan set fitur minimal) tidak selaras. Dengan demikian, bahkan pelanggan Cosmos DB yang tidak pernah menggunakan atau bermaksud menggunakan fitur Notebook Jupyter terkena potensi serangan karena ketidaksesuaian dalam tujuan ini.

Meskipun mungkin mudah untuk memercayai mereka untuk mendapatkan model tanggung jawab bersama dengan benar, ada contoh terbaru di mana kepercayaan telah salah tempat. Perlakukan semua perangkat lunak yang Anda terima dari penyedia layanan cloud dengan dosis skeptisisme yang sehat – pindai dan perhitungkan setiap port yang terbuka dan semua paket perangkat lunak yang ada.

Oliver Tavakoli adalah CTO di Vectra AI.

Nikmati wawasan tambahan dari komunitas Infosec Insider Threatpost dengan mengunjungi situs mikro kami .
Tulis komentar
Bagikan artikel ini:

  • Cloud Securityliu

    <

    ul>iInfoSec Insiderliu

      iKerentanan