Bagaimana pelaku ancaman akan menyerang dan memanfaatkan kontainer? Ini adalah pertanyaan yang selalu saya pikirkan. Saya telah bekerja di bidang ini selama lebih dari dua dekade, dan saya merasa saya harus mendapatkan jawabannya. Tapi aku tidak melakukannya.
Sebaliknya, saya punya banyak ide berbeda, tidak satu pun yang bisa saya anggap benar. Sebagian dari keragu-raguan ini disebabkan oleh banyaknya waktu yang saya habiskan untuk mempelajari keamanan di dunia “warisan”. Wadah sebenarnya tidak memiliki analog. Tentu saja, mesin virtual (VM) sering kali digabungkan dengan container, tetapi mesin virtual tersebut tidak pernah dapat diskalakan seperti container. Mereka juga digunakan untuk tujuan yang sangat berbeda dari wadah. Butuh beberapa saat untuk menyesuaikan pemikiran saya dan memahami di mana kontainer sebenarnya cocok dengan permukaan serangan.
Contoh umum serangan terhadap lingkungan dalam container sangat terbatas. Pelanggaran yang terjadi hampir selalu terkait dengan penambangan kripto, yang merupakan serangan serius, namun respon insiden dalam diri saya menganggapnya mengecewakan. Kesamaan lainnya adalah sebagian besar disebabkan oleh kesalahan konfigurasi, baik di Kubernetes atau akun cloud. Kombinasi motif dan taktik sejauh ini belum terlalu menginspirasi.
Jalan Lama
Kerentanan eksekusi kode jarak jauh (RCE) telah menjadi perhatian utama dalam keamanan komputer sejak lama. Memang masih demikian, tetapi bagaimana cara berpikir seperti ini diterapkan pada kontainer? Sangat mudah untuk langsung menganggap RCE sebagai ancaman utama, namun tampaknya ini bukan cara yang tepat untuk mendekati kontainer. Salah satu alasannya adalah kontainer seringkali hanya berumur pendek – 44% kontainer hanya bertahan kurang dari lima menit – jadi penyusup harus cepat.
Pendekatan ini juga mengasumsikan bahwa container tersebut terekspos ke Internet. Tentu saja beberapa container diatur dengan cara ini, namun seringkali sangat sederhana dan menggunakan teknologi yang telah teruji, seperti NGINX. Mungkin tidak ada hari libur untuk aplikasi ini, tapi aplikasi ini akan sangat berharga dan sulit didapat. Pengalaman saya menunjukkan bahwa banyak container digunakan secara internal dan tidak terhubung langsung ke Internet. Skenario RCE menjadi lebih sulit dalam kasus ini. Saya harus menyebutkan log4j, meskipun kerentanan semacam ini berpotensi dieksploitasi dari jarak jauh meskipun sistem yang rentan tidak berada dalam kondisi yang rentan.
Jalan Baru
Jika RCE bukan ancaman terbesar yang dihadapi kontainer, lalu apa lagi? Apakah kontainer bahkan masuk dalam radar pelaku ancaman? Ya, kontainer dan infrastruktur pendukungnya terlalu penting untuk diabaikan. Perangkat lunak orkestrasi container telah memungkinkan beban kerja dalam container ditingkatkan ke angka yang tidak terbayangkan. Tren penggunaannya pun semakin meningkat, sehingga bisa dipastikan mereka akan menjadi incaran. Mereka tidak bisa dianggap seperti server yang Anda gunakan karena kerentanan RCE.
Sebaliknya, yang terjadi justru sebaliknya. Daripada menyerang kontainer dari luar ke dalam, mereka harus diserang dari dalam ke luar. Pada dasarnya inilah yang dilakukan oleh serangan rantai pasokan. Rantai pasokan adalah vektor serangan yang sangat efektif terhadap kontainer ketika Anda mulai memahami cara pembuatannya. Sebuah container dimulai dengan file definisi, seperti Dockerfile, yang mendefinisikan segala sesuatu yang akan ada di dalam container saat dijalankan. Ia diubah menjadi sebuah gambar setelah dibuat, dan gambar itulah yang dapat diubah menjadi beban kerja berkali-kali. Jika ada sesuatu dalam file definisi tersebut yang disusupi, maka setiap beban kerja yang berjalan akan disusupi.
Kontainer sering kali, namun tidak selalu, dibuat khusus dengan aplikasi yang melakukan sesuatu dan keluar. Aplikasi ini bisa apa saja — yang penting untuk dipahami adalah seberapa banyak yang dibangun menggunakan perpustakaan, baik sumber tertutup atau sumber terbuka, yang ditulis oleh orang lain. GitHub memiliki jutaan proyek, dan itu bukan satu-satunya gudang kode yang ada. Seperti yang kita lihat pada SolarWinds, sumber tertutup juga rentan terhadap serangan rantai pasokan.
Serangan rantai pasokan adalah cara terbaik bagi pelaku ancaman untuk masuk ke lingkungan kontainer target. Mereka bahkan dapat membiarkan infrastruktur pelanggan mengukur serangannya jika kompromi tersebut tidak diketahui. Skenario seperti ini sudah berjalan dengan sendirinya, seperti yang kita lihat pada Pelanggaran codecov. Namun sulit untuk dideteksi karena semua ini masih baru dan pemikiran kita masih berakar pada permasalahan masa lalu.
Sebuah Langkah ke Depan
Seperti halnya memperbaiki sebagian besar masalah, visibilitas biasanya merupakan awal yang baik. Sulit untuk memperbaiki apa yang tidak dapat Anda lihat. Untuk mengamankan kontainer Anda, Anda perlu memiliki visibilitas ke dalam kontainer itu sendiri, serta keseluruhan jalur pipa yang membangunnya. Manajemen kerentanan adalah salah satu jenis visibilitas yang harus diintegrasikan ke dalam jalur pembangunan. Saya juga akan menyertakan alat analisis statis lainnya, seperti alat yang juga mencari bocoran rahasia. Karena serangan rantai pasokan tidak dapat diprediksi, pemantauan runtime menjadi penting sehingga Anda tahu persis apa yang dilakukan kontainer Anda.
