Mengapa repot dan menghabiskan uang dan sumber daya untuk keamanan? Mengapa repot-repot mengadakan Siklus Hidup Pengembangan Keamanan (SDL)? Mengapa mengintegrasikan fuzzing ke dalam proses pengembangan? Mengapa repot-repot dengan pengetahuan tentang berbagai fuzzer seperti AFL, libfuzz, dll? Lagi pula, Anda dapat "secara sederhana" mengubah pencarian kerentanan dalam produk Anda menjadi siksaan terus menerus dan menjadikan kehidupan "manis" bagi para peneliti dan penyerang. Ingin tahu cara melakukan ini? Kalau begitu selamat datang di kat!
Penafian: Artikel ini harus diambil dengan humor dan ironi dalam jumlah tertentu!Baru-baru ini, semakin banyak karya yang dikhususkan untuk topik AntiFuzzing. AntiFuzzing adalah tindakan yang mengurangi efektivitas dan penggunaan fuzzing untuk mencari kerentanan dalam solusi pengembang.
Artikel ini akan fokus pada fuzzing aplikasi biner yang ditulis dalam C \ C ++ yang dapat digunakan secara lokal dan mencoba untuk menemukan kerentanan yang berkaitan dengan kerusakan memori di dalamnya.
Saat ini, sejumlah besar tindakan ditujukan terhadap fuzzer AFL, sebagai perwakilan yang paling mencolok, terkenal dan terkenal dari pendekatan fuzzing berbasis umpan balik.
Setelah mempelajari masalahnya, kami mengidentifikasi kemungkinan teknik AntiFuzzing:
- Mengacaukan hasil pekerjaan fuzzer adalah teknik paling eksentrik yang diadopsi beberapa pengembang tanpa disadari) Ini terdiri dari menambahkan lebih banyak bug untuk membuat program lebih aman ... Ya, sayangnya, kami, tidak dapat menjawab pertanyaannya adalah berapa banyak bug kita yang sudah ada dalam program dan seberapa berbahaya mereka, tetapi kita dapat melarutkan mereka dengan banyak kesalahan yang tidak berguna bagi penyerang!
- Mendeteksi proses fuzzing semuanya dari ruang lingkup jailbreak_detect, root_detect. Aplikasi secara independen menentukan (dan pengembang menulis serangkaian pemeriksaan) bahwa itu tidak hanya berfungsi, tetapi secara bertahap dan sebagai hasilnya menolak untuk bekerja. Industri keamanan informasi telah melalui ini jutaan kali. Kode ini dicari dan dikecualikan dari aplikasi dengan cukup mudah, dan teknik ini mengarah pada judul "yang paling tidak berguna dan tidak canggih."
- Memperlambat proses fuzzing - di dalam perusahaan kami, kami menyebutnya "sembunyikan bug di overhead". Bahkan sekarang, beberapa perangkat lunak bekerja buruk tidak hanya di bawah fuzzing, sehingga mencari kerentanan di dalamnya menjadi tugas yang sulit secara psikologis bagi para peneliti)
- Penciptaan zona blindspot adalah arah yang paling menarik, yang, menurut pendapat kami, akan mendorong evolusi fuzzers. Jadi, dalam karya yang disajikan di BlackHat 2018, masalah tabrakan di shared_mem dimunculkan oleh AFL, yang menggunakannya untuk menentukan bagian kode yang dibahas. Artinya, area dibuat di mana fuzzer tidak jatuh selama operasinya.
Dengan demikian, AntiFuzzing memiliki kelebihan dan kekurangan yang jelas:
- "-" Mungkin keruh pikiran pengembang perangkat lunak yang kurang berpengalaman dalam beberapa aspek keamanan informasi dan proses fuzzing.
- "+" Evolusi fuzzers, yang di masa depan akan mulai mengatasi mekanisme AntiFuzzing yang diterapkan dan akan memberikan cakupan yang lebih besar terlebih dahulu, jika ada mekanisme AntiFuzzing yang diterapkan; kedua, ketika ada elemen dalam perangkat lunak yang mensimulasikan fungsi AntiFuzzing.
Mengapa menggunakan pendekatan ini untuk memastikan keamanan bodoh dan berbahaya? Pengembangan pendekatan AntiFuzzing berkualitas tinggi dan aplikasinya pada perangkat lunak nyata sebanding dalam kompleksitasnya dengan pengembangan algoritma itu sendiri untuk meningkatkan cakupan kode dengan fuzzing berbasis umpan balik. Kesulitannya adalah bahwa selain memasukkan struktur penghambat fase ke tempat yang tepat, perlu untuk memastikan bahwa mereka tidak memiliki pola yang jelas yang dapat dibedakan, dan kemudian dikeluarkan begitu saja. AntiFuzzing tidak meningkatkan keamanan aplikasi itu sendiri ... Ada baiknya bahwa sementara penelitian AntiFuzzing dilakukan hanya dalam lingkungan akademik. Pada saat yang sama, ada perusahaan yang, sebaliknya, berfokus pada penyederhanaan pencarian bug. Sebagai contoh, Mozilla menyediakan versi khusus browser mereka untuk
blog ini.mozilla.org/security/2018/07/19/introducing-the-asan-nightly-project !
Lonjakan minat AntiFuzzing terutama disebabkan oleh DARPA Cyber Grand Challenge 2016. Ini adalah kompetisi di mana komputer tanpa bantuan manusia mencari kerentanan, mengeksploitasi dan menambalnya. Sebagian besar sistem pencarian, Anda mungkin menebak, didasarkan pada fuzzer AFL, dan semua tujuan dalam kompetisi adalah aplikasi biner. Semua ini dapat ditujukan untuk menangkal sistem otomatis, dan bukan orang.
Artikel ini didasarkan pada karya-karya yang dapat Anda pelajari sendiri:
- "Lolos dari Fuzz Mengevaluasi Teknik Fuzzing dan Menipu mereka dengan AntiFuzzing" , tesis Master dalam Sistem Komputer dan Jaringan
2016 - Chaff Bugs: Menangkal Penyerang dengan Membuat Perangkat Lunak Buggier , 2018
- “Blindspot AFL dan Cara Menolak Fuzzing AFL untuk Binari ELF Sewenang-wenang” , BlackHat USA 2018
- Kami juga menyarankan Anda untuk membaca artikel oleh orang-orang dari NCC Group "Pengantar Anti-Fuzzing: A Defense in Depth Aid" mulai 2014 (rilis AFL pertama baru saja muncul dan belum memenangkan cinta besar komunitas, dan 2 tahun lagi sebelum final DARPA CGC).
PS: Kami sering bekerja dengan AFL (+ libfuzz) dan modifikasinya ketika meneliti perangkat lunak dan mengimplementasikan SDL untuk klien kami. Oleh karena itu, dalam salah satu artikel berikut ini, kita akan berbicara lebih banyak tentang fuzzing menggunakan AFL dan mengapa semakin banyak orang menggunakannya dalam program pengujian dan bagaimana meningkatkan tingkat keamanan pengembangan.