AI mengubah cara penelitian kerentanan dilakukan, namun sebagian besar pembahasannya masih bersifat teoretis: apa yang mungkin mampu dilakukan suatu model pada akhirnya, bukan apa yang sebenarnya dapat ditemukan saat ini.
Kami ingin menjawab pertanyaan yang lebih praktis: dengan menggunakan model yang sudah tersedia saat ini, seberapa jauh AI dapat membawa kita dalam menemukan kerentanan nyata yang dapat dieksploitasi dalam perangkat lunak produksi?
Bagian ini merinci bagaimana tim berada Pengacau menggunakan LLM untuk menemukan kerentanan baru menggunakan kerangka pemindaian kode bersama dengan model pra-Mythos saat ini.
Kami menelusuri zero-day injeksi SQL multi-tahap jarak jauh yang kami temukan di plugin WordPress dengan lebih dari 300.000 pengguna — sepenuhnya otomatis mulai dari penemuan hingga eksploitasi, tanpa ada manusia yang terlibat.
Masalah fokus: mengapa mengarahkan AI ke seluruh basis kode tidak berhasil
Masalah besar saat memasangkan AI dengan pemindai kode adalah fokus. LLM sangat baik dalam mengambil segmen kecil kode, atau deskripsi masalah tertentu, dan menemukan solusi yang menarik. Tapi arahkan satu ke basis kode yang besar dan minta untuk menemukan masalah keamanan, dan itu akan mencoba menyerap setiap file di repo.
Hal ini memerlukan token yang mahal, dan akurasinya lebih buruk: saat model sudah setengah jalan, konteksnya sudah penuh dengan kode yang tidak relevan, dan bug yang sebenarnya Anda inginkan sudah terkubur dalam kebisingan.
Untuk bug yang lebih kompleks yang memerlukan rangkaian beberapa langkah secara bersamaan, Anda kemudian mengandalkan kerangka kerja untuk menyimpan konteks yang tepat di memori, atau mengambilnya dengan cerdas saat diperlukan. Berdasarkan pengalaman kami, hal ini menghasilkan keluaran yang buruk dibandingkan bug yang nyata dan menarik.
Kerangka kerja pemindaian kode tradisional telah menyelesaikan masalah ini. Kami menggunakan teknik yang kami sebut potongan program, yang mirip dengan saat alat IDE atau LSP menggunakan fitur seperti “temukan implementasi” atau grafik panggilan untuk menemukan semua fungsi yang dipanggil oleh fungsi saat ini. Ini adalah alat yang matang dan telah teruji dengan baik, dan sepenuhnya menghindari masalah konteks yang lemah.
Saluran kami: dari basis kode hingga eksploitasi yang berfungsi
Kami membangun pipeline yang mengambil basis kode, menjalankannya melalui mesin pemindaian kode (kami menggunakan Joern), menghasilkan potongan kode yang relevan dengan setiap temuan, dan menggunakan LLM untuk melakukan triase dan mengeksploitasi masalah tersebut. Desainnya terinspirasi oleh pekerjaan nooperator di Slicemeskipun kami menggunakan Joern daripada CodeQL dan merancang algoritme pemotongan dengan cara yang sangat berbeda untuk menangani kelas kerentanan spesifik yang kami cari.
Kami mengarahkannya ke 200 plugin WordPress teratas — kode yang sudah banyak dipilih oleh peneliti bug bounty, jadi menemukan sesuatu yang nyata di sana berarti prosesnya dapat bersaing dengan manusia yang terampil.
Pertama, Joern menentang basis kode dengan aturan yang dirancang untuk menandai pola yang “menarik” secara luas — aturan ini sengaja dibuat longgar untuk menghindari pembuatan aturan yang terlalu spesifik dan mungkin melewatkan bug. Karena kita memiliki agen triase yang memfilter nanti, kita bisa melakukan kesalahan dalam hal positif palsu.
Untuk percobaan ini, kami mengincar permukaan serangan plugin WordPress yang tidak diautentikasi, jadi kami meminta Joern mengidentifikasi setiap tempat yang dapat dipengaruhi oleh input pengguna: rute REST, kait templat, panggilan AJAX nopriv, dan sebagainya.
Untuk setiap hook WordPress, Joern menghasilkan sebuah irisan: fungsi yang dipanggil oleh hook, setiap metode yang dipanggil oleh fungsi, dan seterusnya dalam rantai. Pelacakan noda dasar mengesampingkan fungsi yang jelas-jelas aman, seperti input SQL dan XSS yang melewati pembersih yang dikenal aman. Jika kami dapat memverifikasi secara statis bahwa kode tersebut aman untuk dijalankan, kami membuang kode tersebut ke LLM.
Setiap irisan masuk ke model triase ringan (Sonnet, dalam pengujian kami) untuk menyaring yang jelas-jelas tidak menarik: kait yang dimaksudkan untuk umum dan tidak memiliki efek samping, misalnya.
Yang tersisa adalah model yang lebih berat (Opus) untuk menilai kemampuan eksploitasi, dengan seluruh konteks panggilan yang relevan di memori sehingga tidak menelusuri sumber yang tidak terkait.
Apa pun yang dinilai dapat dieksploitasi akan dikirim ke agen eksploitasi akhir untuk mencoba dan menulis eksploitasi. Agen ini memiliki akses ke sumber penuh lagi (jika diperlukan) karena sekarang dapat menggunakan pencarian yang ditargetkan untuk menemukan kode yang relevan, dan agen ini juga akan menjalankan container Docker yang menjalankan perangkat lunak untuk diuji sambil dikembangkan.
Kerentanan pertama: injeksi SQL buta di plugin WordPress yang populer
Bug pertama yang dijual oleh saluran pipa adalah CVE-2026-3985kerentanan injeksi SQL di plugin Creative Mail. Hal ini menonjol bagi kami karena beberapa alasan:
-
Dampaknya tinggi, memberikan penyerang akses baca ke database (termasuk hash admin dan token rahasia!)
-
Hal ini memerlukan beberapa permintaan berantai untuk dapat dieksploitasi, sehingga kecil kemungkinannya untuk terdeteksi oleh alat tradisional
-
Akar permasalahan disembunyikan dari alat analisis statis milik pengembang karena kesalahan dalam kode mereka
Eksploitasi memang mengharuskan WooCommerce dipasang bersama Creative Mail, namun karena WooCommerce adalah alasan umum orang menjalankan WordPress (lebih dari 7 juta pemasangan aktif), kombinasi ini biasa terjadi.
Agen eksploitasi mengambil bukti konsep yang berfungsi, menghasilkan pemeriksaan untuk mengonfirmasi adanya masalah dan metode ekstraksi penuh yang mampu menarik hash kata sandi dari database.
Kerentanan ini juga ditemukan secara independen oleh Dmitrii Ignatyev dari CleanTalk Inc., yang melaporkannya ke Wordfence.
Plugin telah ditarik dari toko WordPress sambil menunggu peninjauan; jika Anda menjalankan Creative Mail bersama WooCommerce, nonaktifkan hingga patch tersedia.
Untuk detail teknis selengkapnya, lihat tulisan kami.
Penemuan menjadi lebih cepat. Deteksi harus tetap berjalan
Ini hanyalah kerentanan pertama yang berhasil diatasi oleh saluran pipa tersebut. Kami telah menemukan lebih banyak lagi dan melaporkannya ke vendor yang terkena dampak (yang masih dalam pengungkapan).
AI jelas memiliki peran yang semakin besar dalam penelitian kerentanan, dan pekerjaan yang dilakukan saat ini adalah membangun kerangka kerja untuk mendapatkan hasil maksimal dari model yang ada saat ini. Penyerang sudah menggunakan peralatan serupa untuk memberikan masukan sinyal tinggi kepada AI, yang berarti keunggulan kecepatan yang sama seperti yang kami tunjukkan di sini tidak hanya dimiliki oleh pembela HAM.
Kerentanan yang muncul oleh mesin penjual otomatis kami menjadi pemeriksaan deteksi di platform Penyusup, sehingga pemindaian Anda berikutnya akan menemukan dan melaporkannya.
Mulai menggunakan Intruder secara gratis.
Pengarang:
Sam Pizzey, Insinyur Keamanan, Penyusup
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.
