Industrialisasi pembuatan exploit untuk peretasan berbasis LLM semakin dekat

• Agen berbasis Opus 4.5 dan GPT-5.2 memanfaatkan kerentanan zero-day QuickJS untuk menghasilkan lebih dari 40 exploit dalam 6 skenario
• GPT-5.2 menyelesaikan semua tugas, sementara Opus 4.5 menyelesaikan semua kecuali dua tugas, menunjukkan kemampuan analisis kode, debugging, dan penyusunan rantai exploit secara otonom
• Hasil eksperimen menunjukkan bahwa pengembangan exploit kemungkinan akan dibatasi oleh throughput token, bukan jumlah peretas manusia
• Deteksi kerentanan dan pembuatan exploit telah mencapai tahap di mana kinerja meningkat sebanding dengan jumlah token yang dimasukkan
• Ke depan, ditekankan perlunya otomatisasi serangan siber dan penataan ulang kerangka evaluasi keamanan

---

Gambaran eksperimen

• Eksperimen pembuatan exploit dilakukan menggunakan Opus 4.5 dan GPT-5.2 dengan target kerentanan zero-day pada interpreter JavaScript QuickJS
  • Berbagai teknik mitigasi exploit diterapkan, seperti ASLR, NX, RELRO, CFI, shadow stack, dan seccomp
  • Agen mencapai berbagai tujuan seperti membuka shell, menulis file, dan membuat koneksi C2
• GPT-5.2 menyelesaikan semua skenario, sementara Opus 4.5 menyelesaikan semua kecuali dua tugas
  • Setiap eksekusi dibatasi hingga 30 juta token, dengan biaya sekitar 30 dolar
  • Pada tugas tersulit, penyelesaian membutuhkan 50 juta token, sekitar 3 jam, dan biaya 50 dolar
• GPT-5.2 menyelesaikan exploit penulisan file di lingkungan dengan sandbox seccomp dan shadow stack aktif melalui panggilan fungsi 7 tahap yang memanfaatkan rantai exit handler glibc

Keterbatasan eksperimen

• QuickJS memiliki ukuran dan kompleksitas yang jauh lebih kecil dibanding engine browser nyata, sehingga generalisasi hasil memiliki keterbatasan
• Exploit yang dihasilkan tidak menemukan kerentanan baru pada mekanisme perlindungan itu sendiri, melainkan memanfaatkan titik lemah deployment yang sudah dikenal
• Kerentanan QuickJS sendiri baru ditemukan, dan metode penyelesaian GPT-5.2 dinilai sebagai penyusunan rantai baru yang belum pernah didokumentasikan sebelumnya

Industrialisasi intrusi

• Yang dimaksud dengan 'industrialisasi' adalah kondisi ketika kemampuan serangan sebuah organisasi ditentukan bukan oleh jumlah personel, melainkan oleh throughput token
• Ada dua syarat yang dibutuhkan untuk itu
  • Agen berbasis LLM harus mampu menjelajah secara otonom di dalam lingkungan
  • Harus ada sistem verifikasi yang akurat dan cepat
• Pengembangan exploit adalah contoh ideal yang memenuhi syarat tersebut
  • Lingkungan mudah dibangun, dan prosedur verifikasinya jelas
  • Contoh: pada exploit pembukaan shell, keberhasilan dapat diverifikasi dari sukses tidaknya koneksi melalui port listener
• Sebaliknya, intrusi yang memerlukan interaksi real-time, eskalasi hak akses, pemeliharaan akses berkelanjutan, dan eksfiltrasi data lebih sulit diindustrialisasi
  • Karena tindakan yang salah di lingkungan nyata dapat berujung pada deteksi

Tahap saat ini

• Deteksi kerentanan dan pengembangan exploit sudah menunjukkan peningkatan hasil yang sebanding dengan token yang digunakan
  • Tren yang sama juga dikonfirmasi dalam proyek Aardvark milik OpenAI
  • Dalam eksperimen ini, yang menjadi batas hanyalah anggaran, bukan kemampuan model
• Otomatisasi peretasan di jaringan nyata masih belum pasti
  • Menurut laporan Anthropic, ada kasus tim peretas Tiongkok mencoba melakukan serangan menggunakan API
  • Namun, belum ada contoh agen SRE (site reliability engineering) yang sepenuhnya otomatis dan telah dikomersialkan
• Jika otomatisasi SRE berhasil, maka kemungkinan besar peretasan otomatis di jaringan yang bersifat adversarial juga akan menjadi mungkin

Kesimpulan dan saran

• Eksperimen ini mengubah persepsi tentang cakupan dan waktu kemungkinan otomatisasi di ranah siber
• Metode evaluasi model saat ini (CTF, kerentanan lama, data sintetis) tidak memadai untuk mengukur kemampuan serangan zero-day nyata
• Laboratorium frontier dan lembaga keamanan AI perlu melakukan evaluasi terhadap target zero-day nyata, misalnya Linux kernel dan Firefox
  • Diperlukan laporan publik dalam bentuk seperti “menggunakan X miliar token untuk menghasilkan Y exploit”
• Evaluasi terhadap perangkat nyata seperti firmware IoT juga diperlukan
  • Ditunjukkan adanya kemungkinan agen berbasis Opus 4.5 atau GPT-5.2 dapat menghasilkan exploit yang benar-benar berguna dalam waktu satu minggu
• Peneliti dan insinyur dianjurkan untuk melakukan eksperimen secara langsung dan mempublikasikan hasilnya
  • Kode dan data eksperimen dipublikasikan di repositori GitHub

[GN⁺]

Komentar Hacker News

• Mereka memberi GPT‑5.2 tugas yang paling sulit: mencari cara menulis sebuah string ke jalur tertentu di disk
  Lingkungannya adalah QuickJS dengan semua perlindungan aktif, seperti ASLR, memori non-eksekusi, full RELRO, CFI yang ketat, hardware shadow-stack, dan sandbox seccomp
  GPT‑5.2 menyelesaikan masalah itu dengan memanfaatkan rantai exit handler milik glibc melalui pemanggilan fungsi 7 tahap. Hasilnya benar-benar mengejutkan

  • Ini membuatku berpikir apakah mitigasi-mitigasi seperti ini sebaiknya dihapus saja
    Eksploit nyata biasanya berjalan dengan urutan “menemukan kerentanan (sulit)” lalu “menembus banyak lapisan mitigasi yang tidak terlalu berguna (merepotkan tapi bisa dilakukan)”
    Mitigasi probabilistik efektif melawan serangan probabilistik, tetapi penyerang mencari kelemahan secara sengaja
  • Pada akhirnya, di dasar stack kode mesin ada terlalu banyak celah
    Di masa depan kita mungkin akan menyesal karena tidak beralih ke WASM lebih cepat
    Sampai saat itu, kita akan terus menambal dengan mitigasi perangkat keras sambil bergulat dengan masalah stack overwrite yang sudah usang
  • “exit handler glibc”... merinding
  • Belakangan ini kill chain kebanyakan memanfaatkan beberapa bug secara berantai
    Ini pekerjaanku jadi aku tahu betul, dan rasa tak berdaya itu makin besar
  • Kasus seperti ini menunjukkan betapa rentannya terhadap LLM QuickJS yang dibangun dengan C
    Misalnya dengan membocorkan pointer libc lewat Use-After-Free
    Dengan Rust itu akan jauh lebih sulit, tetapi kalau ada banyak pemanggilan libc, pertahanan penuh tetap sulit

• Eksploit GPT‑5.2 tidak mematahkan mitigasi baru, melainkan memanfaatkan celah implementasi yang memang sudah diketahui
  Peretas manusia juga sama, mereka tidak benar-benar memecahkan mitigasi itu sendiri dengan cara baru
  Namun, di ranah CTF sekarang makin sering ada kasus LLM yang menyelesaikan soal pwn sekali jalan
  Perkembangan ini tampaknya akan meruntuhkan implementasi mitigasi yang tidak sempurna dan mendorong riset pemodelan eksploit formal

  • Katanya “pemodelan eksploit formal” masih merupakan bidang yang belum matang; aku penasaran bahan rujukan apa yang layak dibaca

• Dari sudut pandang peneliti keamanan, API primitive read/write yang dibuat LLM hanya sebatas merangkai ulang API yang sudah ada
  Ini bukan teknik baru, lebih mirip binary mainan untuk CTF
  Hanya saja model OpenAI terbaru tampaknya cenderung enggan menghasilkan kode eksploit nyata, jadi aku penasaran apakah di sini digunakan bypass prompt

• Penulis mengangkat poin yang menarik, tetapi aku tidak terlalu khawatir
  Alat seperti ini juga bisa dimanfaatkan secara simetris oleh pihak bertahan
  Misalnya menambahkan pengujian keamanan otomatis dengan menjalankan “LLM Red Team” pada tahap CI

  • Secara matematis ini tidak simetris
    Penyerang hanya perlu berhasil sekali, sedangkan pihak bertahan harus selalu berhasil
    Model saat ini punya performa pass@x yang 20~30% lebih tinggi daripada maj@x
    Meski begitu, menjalankan loop Red vs Blue tetap akan meningkatkan tingkat keamanan
  • Dalam sistem yang kompleks, simetri seperti ini runtuh
    Penyerang hanya perlu menemukan satu kegagalan, sedangkan pihak bertahan harus menutup semuanya
  • Ini sudah dipakai secara defensif
    Contoh: proyek Big Sleep dari Google Project Zero
    Daftar kerentanan terkait bisa dilihat di sini
  • Ini tidak mungkin simetris
    Penyerang bisa mempersenjatai cukup dengan menemukan satu bug, sedangkan pihak bertahan harus menemukan semua bug
    Strukturnya asimetris: “any vs all”
  • Ada terlalu banyak perangkat lunak yang tidak dipelihara
    Pada akhirnya, perusahaan LLM saja yang menjadi pemenang sejati karena mereka menjual token ke kedua belah pihak

• Menarik bahwa Codex 5.2 menemukan eksploit yang paling kompleks
  Aku sendiri lebih sering memakai Opus 4.5, tetapi mode Extra High thinking di Codex 5.2 jelas sangat kuat
  Aku tidak percaya pada klaim bahwa perkembangan LLM melambat. Justru yang terjadi, tugasnya menjadi terlalu sulit sehingga kemajuannya terasa lebih kecil

  • Sebenarnya model itu bukan “menemukan” eksploit, melainkan menulis kode yang memanfaatkan kerentanan yang sudah diberikan
    Log-nya bisa dilihat di repositori ini
  • Model Anthropic bertipe pengguna alat, OpenAI Codex High bertipe reviewer/pengoreksi, dan Gemini bertipe seniman kreatif
    Masing-masing punya gaya berbeda
  • “Tugas yang cukup sulit” kebanyakan terkunci sebagai IP internal perusahaan
    Itu tidak akan dipublikasikan sampai nilai komersialnya hilang

• QuickJS pada dasarnya adalah proyek mainan dengan banyak kerentanan yang belum ditambal
  Eksploit pada target dunia nyata seperti curl akan jauh lebih menarik

• Klaim bahwa LLM bisa menulis eksploit hebat hidup berdampingan dengan klaim bahwa LLM menghasilkan laporan bug yang tidak berguna
  Apakah keduanya bisa sama-sama benar?

  • Keduanya sangat mungkin benar
    Kualitas LLM bergantung pada prompt pengguna dan kemampuan interpretasi
    Jika dipakai secara selektif oleh ahli, hasilnya bisa sangat bagus
  • Eksploit bisa dinilai dengan jelas dari “apakah berhasil berjalan”, tetapi laporan CVE jauh lebih sulit diverifikasi
    Laporan yang dihasilkan otomatis menjadi beban besar bagi maintainer
  • Dalam praktiknya, kualitas sangat bergantung pada cara pemakaiannya
    Jika hanya bilang “tolong cari kerentanan program ini”, omong kosongnya akan banyak,
    tetapi jika disediakan loop pengujian dan lingkungan, model bisa berulang kali membaik hingga menghasilkan sesuatu yang benar-benar bekerja
  • Eksploit punya kriteria keberhasilan yang jelas dan cocok dengan iterasi gigih LLM
    Sebaliknya, laporan bug itu ambigu dan sulit dievaluasi
  • Struktur anggarannya juga berbeda
    Misalnya, jika dari $100 ada satu isu nyata senilai $50 bercampur dengan 5000 laporan palsu senilai $0.01,
    akan sulit menemukan berlian yang asli

• Penjelasan sandbox-nya samar, jadi awalnya terasa mencurigakan
  Setelah melihat repositori penulis, ternyata tujuannya adalah “menulis string ‘PWNED’ ke /tmp/pwned”
  Jadi ini bukan sandbox escape, melainkan sekadar pembatasan penulisan file

  • Susunan keseluruhan repositori dan tulisannya memang agak mudah menimbulkan salah paham
    Bahkan permintaan untuk membuat OOB R/W primitive API pun pada dasarnya hanya mendaur ulang ribuan contoh GitHub yang sudah ada

• Kalimat “ke depan, kemampuan peretasan negara atau organisasi akan ditentukan bukan oleh jumlah peretas, melainkan oleh throughput token” terasa sangat berkesan

  • Kenyataannya, sangat mungkin organisasi-organisasi itu menganalisis pola kode ceroboh dari LLM lalu manusia menulis sendiri eksploit umum yang sesungguhnya

• Menurunnya hambatan masuk untuk membuat perangkat lunak dan hambatan masuk untuk meretas secara bersamaan adalah kombinasi yang eksplosif
  Kini kita memerlukan platform baru yang memiliki guardrail keamanan dan kemampuan verifikasi
  Terlalu berbahaya jika bergantung pada kode buatan non-ahli

  • Di paragraf ketiga sebelumnya sebenarnya disebutkan ketimpangan antara “satu eksploit vs pertahanan seluruh sistem”; aku penasaran kenapa itu dihapus