22 Maret 2022
Oleh Thyaga Vasudevan - Wakil Presiden Manajemen Produk, Skyhigh Security
Beralih ke arsitektur cloud-native untuk aplikasi perusahaan Anda dapat memberikan nilai bisnis yang luar biasa, menambah skala dan kelincahan sambil mengurangi tugas-tugas berat seperti menambal dan meningkatkan infrastruktur server.
Namun, di setiap lingkungan cloud, baik Amazon Web Services (AWS), Azure, maupun Google Cloud, terdapat kategori risiko baru. Ancaman cloud-native berasal dari konteks baru dan persyaratan konfigurasi yang Anda miliki di lingkungan cloud. Secara historis, pengaturan default seperti akses publik ke objek penyimpanan telah membuat data sensitif berada di tempat terbuka, mudah dicuri oleh siapa pun yang merayapi kelemahan ini.
Sangat mudah untuk membuat kesalahan di lingkungan baru, dengan pengaturan baru yang diperkenalkan secara terus menerus seiring dengan ditambahkannya kemampuan baru oleh penyedia layanan cloud. Konfigurasi lingkungan cloud Anda selalu menjadi tanggung jawab Anda. AWS dan yang lainnya tidak memiliki kendali atas cara Anda menggunakan layanan mereka. Mereka adalah templat yang dapat Anda gunakan untuk membangun.
Tidak memahami hasil dari konfigurasi Anda dan bagaimana Anda membangun aplikasi cloud-native dapat menimbulkan konsekuensi yang sangat besar. Dan bahkan pelanggan cloud yang paling paham pun bisa mengalami konsekuensi ini.
Contoh kasusnya adalah pelanggaran yang dialami Capital One hampir tiga tahun yang lalu di mana penyerang memiliki akses ke nomor jaminan sosial dari 100 juta orang AS dan nomor asuransi sosial dari 6 juta orang Kanada. Penyerang menggunakan beberapa teknik untuk mendapatkan akses ke data, tetapi pembelajaran utama dari serangan tersebut adalah bahwa fitur keamanan yang dirancang untuk melindungi akses ke mesin virtual - Elastic Compute Cloud atau instance EC - menambahkan penyerang. Fitur ini disebut layanan Instance Metadata atau IMDS.
Serangan Metadata Instance
Versi 1 dari IMDS (IMDSv1) dirilis pada tahun 2012 untuk memungkinkan cara yang lebih aman bagi instance EC2 untuk berinteraksi dengan layanan AWS lainnya. Alih-alih meninggalkan kunci AWS pada instance, pelanggan sekarang dapat meminta instance EC2 untuk meminta layanan metadata untuk mendapatkan kredensial dan melakukan panggilan API AWS ke layanan AWS lainnya. Misalnya, jika instance EC2 mendapatkan beberapa data pelanggan, instance tersebut dapat menggunakan IMDSv1 untuk menyimpan data tersebut dalam bucket Amazon Simple Storage Service (S3). Kemampuan inilah yang digunakan penyerang untuk menarik informasi sensitif dari bucket S3 yang digunakan untuk menyimpan informasi tentang pelanggan Capital One.
Dalam pengujian kami sendiri, kami dapat menduplikasi bagaimana ekstraksi data ini dapat bekerja di aplikasi apa pun. Dalam contoh kami, tim ahli epidemiologi membangun aplikasi cloud-native di AWS dengan dasbor publik untuk merepresentasikan data secara visual yang menunjukkan kemajuan mereka dalam menganalisis genom virus.
Selama tahap pengembangan aplikasi ini, tim menghadapi tantangan. Sebagian besar sumber daya dalam Virtual Private Cloud (VPC) mereka seharusnya disembunyikan dari internet. Satu-satunya sumber daya dalam VPC mereka yang dimaksudkan untuk dilihat oleh publik adalah dasbor.
Bucket S3 yang menampung data mereka harus tetap bersifat privat. Untuk menarik data dari S3 ke dasbor publik, mereka menambahkan proksi terbalik, bertindak sebagai perantara. Yang diperlukan hanyalah pencarian cepat di Google, dan beberapa baris kode untuk menambahkannya ke aplikasi mereka.
Bagi tim ahli epidemiologi, proksi balik adalah solusi dasar dan elegan yang berfungsi sempurna untuk kasus penggunaan mereka. Yang tidak mereka sadari adalah bahwa hal ini membuat mereka siap untuk melakukan pelanggaran besar-besaran.
Instance komputasi yang menjalankan reverse proxy telah diberi peran IAM dengan izin untuk mengakses bucket S3 pribadi mereka. Kredensial untuk proxy balik untuk mengakses S3 diperoleh dari Instance Metadata.
Seorang penyerang yang mengunjungi situs tersebut dan tertarik dengan data mereka menyadari bahwa tim telah mereferensikan alamat IP proxy terbalik di dasbor. Penyerang kemudian memeriksa untuk melihat apakah mereka dapat terhubung ke sana. Setelah mengonfirmasi konektivitas mereka, penyerang kemudian memeriksa untuk melihat apakah mereka dapat mengakses Metadata Instance melalui proxy balik. Berhasil.
Melalui proxy terbalik dan dari Metadata Instance, penyerang menemukan kredensial ke bucket penyimpanan S3 pribadi tim.
Sekarang, dengan akses ke S3 bucket, penyerang dapat mencuri data yang sangat sensitif yang telah disimpan oleh tim untuk aplikasi mereka. Penyerang cukup menyinkronkan S3 bucket target ke S3 bucket mereka sendiri di akun AWS lain, dan data tersebut menjadi milik mereka.
Jenis serangan ini hanyalah salah satu dari 43 teknik yang dijelaskan oleh MITRE dalam kerangka kerja ATT&CK mereka untuk lingkungan cloud: https://attack.mitre.org/matrices/enterprise/cloud/
Bagaimana AWS Memitigasi Serangan Metadata Instance
Untuk meningkatkan keamanan layanan ini, AWS merilis IMDSv2, yang menambahkan beberapa lapisan perlindungan baru.
Pada IMDSv2, pengguna eksternal diblokir untuk menerima kredensial, sehingga hanya sumber daya aplikasi yang dapat menerimanya. Baca lebih lanjut tentang lapisan perlindungan ini dan IMDSv2 di sini: https://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/
Namun, tantangannya adalah IMDSv1 masih tetap ada. Tidak ada apa pun di AWS yang mencegah pelanggan menggunakan IMDSv1, dan Anda masih dapat menggunakannya secara default untuk semua instance EC2 Anda. Seperti yang kami sebutkan sebelumnya, bukan tanggung jawab AWS untuk memastikan Anda menggunakan cloud dengan aman. Tanggung jawab itu sepenuhnya berada di tangan pelanggan.
Dalam serangan yang baru saja kami jelaskan, proxy terbalik salah dikonfigurasi untuk memungkinkan permintaan eksternal mencapai sumber daya internal. Jika tim telah mengonfigurasi contoh komputasi mereka untuk menggunakan IMDSv2, akses yang tidak sah oleh aktor ancaman eksternal akan diblokir.
Bagaimana Perlindungan Aplikasi Asli Skyhigh Cloud Dapat Membantu
Di Skyhigh Security, kami memiliki beberapa pendekatan yang dapat membantu Anda mendeteksi dan mencegah serangan seperti ini. Skyhigh Cloud Native Application Protection Platform (CNAPP) adalah platform keamanan cloud-native kami yang memungkinkan Anda untuk memantau dan memperbarui konfigurasi di AWS, Azure, GCP, serta berbagai langkah keamanan tambahan yang dapat Anda baca di sini.
Menggunakan integrasi API langsung dengan AWS, Skyhigh CNAPP terus memantau Amazon CloudWatch - layanan pemantauan aplikasi dan infrastruktur - untuk menunjukkan versi IMDS mana yang Anda gunakan di setiap instance EC2.
Ketika CloudWatch mencatat sebuah instance yang secara aktif menggunakan IMDSv1, Skyhigh CNAPP akan membuat insiden keamanan, memberi tahu Anda untuk memperbarui konfigurasi Anda ke IMDSv2, yang akan mencegah akses tidak sah ke kredensial Anda oleh pengguna eksternal.
Insiden kebijakan CNAPP Skyhigh untuk konfigurasi versi IMDS
Praktik terbaik adalah menerapkan IMDSv2 pada instans EC2 Anda untuk semua kode dan pengguna lokal. Setelah Anda menetapkan bahwa IMDSv2 harus digunakan, IMDSv1 tidak akan berfungsi lagi. AWS memiliki petunjuk langkah demi langkah tentang cara mengonfigurasi instans Anda untuk menggunakan IMDSv2 di sini.
Di luar contoh serangan ini, Skyhigh CNAPP memungkinkan Anda menerapkan serangkaian praktik terbaik untuk melindungi aplikasi cloud-native Anda:
- Mengaudit konfigurasi Anda secara terus menerus. Dengan Skyhigh CNAPP, Anda dapat memindai template AWS CloudFormation sebelum masuk ke produksi, dan kemudian mendeteksi "penyimpangan" apa pun dalam konfigurasi Anda dari waktu ke waktu. Hal ini memungkinkan Anda untuk mendeteksi kesalahan konfigurasi dan menerapkan model hak akses paling sedikit untuk izin sumber daya.
- Terapkan Zero-Trust. Gunakan zero-trust sebagai metodologi, di mana hanya sumber daya tertentu yang diizinkan untuk berjalan dan berkomunikasi satu sama lain. Segala sesuatu yang lain diblokir.
- Memindai kerentanan kode. Khususnya dengan model distribusi perangkat lunak terbuka seperti Docker, penting untuk memantau sumber daya aplikasi Anda untuk mengetahui kerentanan secara terus-menerus.
- Mendeteksi anomali dan ancaman. Dengan Analisis Perilaku Pengguna dan Entitas (UEBA), Anda bisa menilai jutaan peristiwa cloud untuk mengungkap aktivitas anomali dan ancaman nyata seperti pencurian kredensial.
- Jalankan DLP pada objek penyimpanan. Sama seperti layanan cloud lain yang Anda beri sanksi, jaringan, atau titik akhir, dalam AWS Anda dapat dan harus mengklasifikasikan data Anda dalam S3 dan menjalankan data loss prevention untuk menghentikan upaya eksfiltrasi.
Hubungi kami untuk membicarakan penerapan langkah-langkah ini di organisasi Anda.
Kembali ke Blog