“Vibe coding” — menggunakan model AI untuk membantu menulis kode — telah menjadi bagian dari pengembangan sehari-hari bagi banyak tim. Ini bisa sangat menghemat waktu, tetapi juga bisa menyebabkan terlalu percaya pada kode yang dihasilkan AI, sehingga menciptakan ruang untuk menimbulkan kerentanan keamanan.
milik penyusup Pengalaman ini berfungsi sebagai studi kasus dunia nyata tentang bagaimana kode yang dihasilkan AI dapat memengaruhi keamanan. Inilah yang terjadi dan apa yang harus diwaspadai oleh organisasi lain.
Saat Kita Membiarkan AI Membantu Membangun Honeypot
Untuk menyampaikan kami Respon Cepat layanan, kami menyiapkan honeypot yang dirancang untuk mengumpulkan upaya eksploitasi tahap awal. Salah satunya, kami tidak dapat menemukan opsi sumber terbuka yang sesuai dengan keinginan kami, jadi kami melakukan apa yang dilakukan banyak tim saat ini: kami menggunakan AI untuk membantu menyusun pembuktian konsep.
Kode ini sengaja diterapkan sebagai infrastruktur yang rentan di lingkungan yang terisolasi, namun kami masih memeriksa kewarasan kode tersebut sebelum meluncurkannya.
Beberapa minggu kemudian, sesuatu yang aneh mulai muncul di log. File yang seharusnya disimpan di bawah alamat IP penyerang malah muncul dengan string payload, yang memperjelas bahwa input pengguna berakhir di tempat yang tidak kami inginkan.
Kerentanan yang Tidak Kami Saksikan Akan Terjadi
Pemeriksaan lebih dekat terhadap kode tersebut menunjukkan apa yang sedang terjadi: AI telah menambahkan logika untuk menarik header IP yang disediakan klien dan memperlakukannya sebagai IP pengunjung.
Ini hanya akan aman jika header berasal dari proxy yang Anda kendalikan; jika tidak, mereka secara efektif berada di bawah kendali klien.
Ini berarti pengunjung situs dapat dengan mudah memalsukan alamat IP mereka atau menggunakan header untuk memasukkan muatan, yang merupakan kerentanan yang sering kita temukan dalam pengujian penetrasi.
Dalam kasus kami, penyerang hanya menempatkan payload mereka ke dalam header, yang menjelaskan nama direktori yang tidak biasa. Dampaknya rendah dan tidak ada tanda-tanda rantai eksploitasi penuh, namun hal ini memberikan penyerang pengaruh terhadap perilaku program.
Hal ini bisa menjadi jauh lebih buruk: jika kami menggunakan alamat IP dengan cara lain, kesalahan yang sama dapat dengan mudah menyebabkan Pengungkapan File Lokal atau Pemalsuan Permintaan Sisi Server.
Mengapa SAST Melewatkannya
Kami berlari Semgrip AS Dan Gosek pada kode. Tidak ada yang menandai kerentanannya, meskipun Semgrep melaporkan beberapa perbaikan yang tidak terkait. Ini bukan kegagalan alat-alat tersebut — ini adalah keterbatasan analisis statis.
Mendeteksi kelemahan khusus ini memerlukan pemahaman kontekstual bahwa header IP yang disediakan klien digunakan tanpa validasi, dan tidak ada batasan kepercayaan yang diterapkan.
Ini adalah nuansa yang terlihat jelas bagi pentester manusia, tetapi mudah terlewatkan ketika pengulas terlalu percaya pada kode yang dihasilkan AI.
Kepuasan Otomatisasi AI
Ada gagasan yang terdokumentasi dengan baik dari bidang penerbangan bahwa pengawasan otomatisasi membutuhkan lebih banyak upaya kognitif daripada melakukan tugas secara manual. Efek yang sama sepertinya juga terlihat di sini.
Karena kode tersebut bukan milik kami dalam arti sebenarnya – kami tidak menulis barisnya sendiri – model mental tentang cara kerjanya tidak begitu kuat, dan peninjauan menjadi buruk.
Namun, perbandingannya dengan penerbangan berakhir di situ. Sistem autopilot memiliki rekayasa keselamatan selama puluhan tahun, sedangkan kode yang dihasilkan AI tidak. Belum ada margin keamanan yang dapat diandalkan.
Ini Bukan Kasus Terisolasi
Ini bukan satu-satunya kasus di mana AI dengan percaya diri memberikan hasil yang tidak aman. Kami menggunakan model penalaran Gemini untuk membantu menghasilkan peran IAM khusus untuk AWS, yang ternyata rentan terhadap peningkatan hak istimewa. Bahkan setelah kami menunjukkan masalahnya, model tersebut dengan sopan menyetujuinya dan kemudian memunculkan peran rentan lainnya.
Butuh empat putaran iterasi untuk sampai pada konfigurasi yang aman. Model ini tidak pernah bisa mengenali masalah keamanan secara mandiri – model ini memerlukan pengawasan manusia sepenuhnya.
Insinyur berpengalaman biasanya akan mengatasi masalah ini. Namun alat pengembangan yang dibantu AI memudahkan orang-orang yang tidak memiliki latar belakang keamanan untuk menghasilkan kode, dan penelitian terbaru telah menemukan ribuan kerentanan yang ditimbulkan oleh platform tersebut.
Namun seperti yang telah kami tunjukkan, bahkan pengembang dan profesional keamanan berpengalaman pun dapat mengabaikan kelemahan ketika kode tersebut berasal dari model AI yang terlihat percaya diri dan berperilaku benar pada pandangan pertama. Dan bagi pengguna akhir, tidak ada cara untuk mengetahui apakah perangkat lunak yang mereka andalkan berisi kode yang dihasilkan AI, sehingga tanggung jawab sepenuhnya ada pada organisasi yang mengirimkan kode tersebut.
Kesimpulan untuk Tim yang Menggunakan AI
Setidaknya, kami tidak menyarankan membiarkan staf non-pengembang atau non-keamanan mengandalkan AI untuk menulis kode.
Dan jika organisasi Anda mengizinkan para ahli untuk menggunakan alat ini, ada baiknya meninjau kembali proses peninjauan kode dan kemampuan deteksi CI/CD untuk memastikan masalah baru ini tidak lolos.
Kami memperkirakan kerentanan yang disebabkan oleh AI akan menjadi lebih umum seiring berjalannya waktu.
Hanya sedikit organisasi yang secara terbuka mengakui bahwa masalah tersebut berasal dari penggunaan AI, sehingga skala masalahnya mungkin lebih besar dari apa yang dilaporkan. Ini bukanlah contoh terakhir – dan kami ragu ini adalah contoh yang terisolasi.
Pesan demo untuk melihat bagaimana Penyusup mengungkap paparan sebelum menjadi pelanggaran.
Pengarang
Sam Pizzey adalah Insinyur Keamanan di Intruder. Sebelumnya seorang pentester terlalu terobsesi dengan rekayasa balik, saat ini berfokus pada cara mendeteksi kerentanan aplikasi dari jarak jauh dalam skala besar.
Disponsori dan ditulis oleh Pengacau.
