Bagaimana pengujian fuzz memperkuat keamanan perangkat IoT
Pengujian Fuzz merupakan tempat penting yang tersedia bagi para insinyur untuk menemukan kelemahan dalam tertanam perangkat dan harus dipertimbangkan untuk pengerasan antarmuka perangkat IoT.
Dengan proliferasi perangkat IoT datang peningkatan serangan keamanan tertanam. Secara historis, insinyur sistem tertanam telah mengabaikan keamanan lapisan perangkat meskipun banyak area perangkat tertanam yang rentan terhadap bug. Port serial, antarmuka radio, dan bahkan antarmuka pemrograman/debugging semuanya dapat dieksploitasi oleh peretas. Pengujian Fuzz merupakan tempat penting yang tersedia bagi para insinyur untuk menemukan kelemahan pada perangkat yang disematkan, dan harus dipertimbangkan untuk memperkuat antarmuka perangkat IoT.
Apa itu pengujian fuzzy?
Pengujian fuzzy seperti sejuta monyet mitos yang mengetik secara acak untuk menulis Shakespeare. Dalam praktiknya, karya fiksi membutuhkan banyak kombinasi acak untuk menghasilkan frasa sederhana, tetapi untuk sistem tertanam, kita hanya perlu mengubah beberapa huruf dari kalimat yang dikenal baik.
Banyak alat komersial dan sumber terbuka tersedia untuk mengimplementasikan serangan fuzz. Alat ini menghasilkan string byte acak, juga disebut vektor fuzz atau vektor serangan, dan mengirimkannya ke antarmuka yang sedang diuji, melacak perilaku yang dihasilkan yang dapat menandakan bug.
Pengujian fuzzy adalah permainan angka, tetapi kami tidak dapat mencoba input yang mungkin dalam jumlah tak terbatas. Sebagai gantinya, kami berfokus pada pengoptimalan waktu pengujian dengan memaksimalkan laju pengiriman vektor fuzz, efektivitas vektor fuzz, dan algoritme deteksi bug.
Konsep pengujian Fuzz
Karena banyak alat pengujian fuzz dirancang untuk menguji aplikasi PC, lebih mudah untuk mengadaptasinya jika Anda menjalankan kode yang disematkan sebagai aplikasi PC yang dikompilasi secara asli. Menjalankan kode yang disematkan pada PC menghasilkan keuntungan kinerja yang besar, tetapi memiliki dua kelemahan. Pertama, mikroprosesor PC tidak bereaksi sama seperti mikrokontroler tertanam. Kedua, kita harus menulis ulang kode apa pun yang menyentuh perangkat keras. Namun, dalam praktiknya, keuntungan menjalankan PC lebih besar daripada kerugiannya. Hambatan sebenarnya adalah kesulitan dalam mem-porting kode untuk dikompilasi secara native di PC.
Bagaimana kita tahu kapan vektor bulu halus memicu bug? Kerusakan mudah dikenali, tetapi lebih sulit untuk mengidentifikasi vektor fuzz yang menyebabkan reset. Bug overflow memori atau penulisan penunjuk nyasar—jenis bug yang paling berharga bagi peretas—hampir tidak mungkin dikenali dari luar sistem karena biasanya tidak mengakibatkan crash atau reset.
Banyak kompiler modern, seperti GCC dan Dentang, memiliki fitur yang disebut sanitasi memori. Ini menandai blok memori sebagai bersih atau kotor, tergantung pada apakah mereka sedang digunakan, dan menandai setiap upaya untuk mengakses memori kotor. Namun, sanitasi memori menghabiskan flash, RAM, dan siklus CPU, sehingga sulit untuk dijalankan pada perangkat yang disematkan. Jadi, sebagai gantinya, kami dapat menguji subset kode, membuat versi perangkat dengan lebih banyak sumber daya, atau menggunakan PC.
Efektivitas tes dapat dievaluasi dengan jumlah kode yang digunakan. Di sini juga, kompiler dapat melacak penggunaan memori dengan menggunakan panggilan subrutin remah roti. Pustaka cakupan kode mempertahankan tabel nilai penggunaan untuk setiap jalur kode, menambahnya saat remah roti dijalankan.
Namun, nomor cakupan kode sulit untuk ditafsirkan untuk pengujian fuzz tertanam karena sebagian besar kode tidak dapat diakses oleh vektor fuzz; misalnya, driver perangkat untuk periferal yang berjalan secara independen dari antarmuka. Oleh karena itu, sulit untuk mendefinisikan "cakupan kode lengkap" untuk sistem yang disematkan—mungkin hanya 20% dari kode yang disematkan yang dapat diakses. Cakupan kode juga menghabiskan banyak siklus flash, RAM, dan CPU dan akan membutuhkan perangkat keras khusus atau target PC untuk dijalankan.
Pelaporan bug
Ketika uji fuzz menemukan vektor yang menyebabkan perilaku yang tidak diinginkan, kita membutuhkan informasi yang detail. Di mana bug itu terjadi? Bagaimana status tumpukan panggilan? Apa jenis bug tertentu? Semua informasi ini membantu untuk melakukan triase dan akhirnya memperbaiki bug.
Triase bug sangat penting dalam pengujian fuzz. Proyek fuzz baru sering menemukan banyak bug, dan kami membutuhkan cara otomatis untuk menentukan tingkat keparahannya. Juga, bug fuzz cenderung memblokir bug karena mereka sering menutupi bug tambahan lebih jauh di jalur kode. Kami membutuhkan solusi cepat untuk masalah yang muncul selama pengujian fuzzy.
Klien yang disematkan tidak bersedia mengungkapkan informasi mereka seperti halnya PC. Biasanya, kerusakan hanya akan menyebabkan perangkat mengatur ulang dan memulai ulang. Meskipun ini diinginkan di lapangan, ini menghapus status perangkat, sehingga sulit untuk mempelajari apakah terjadi crash, di mana atau mengapa hal itu terjadi, atau jalur kode yang diambil. Engineer harus menemukan vektor reproduksi yang konsisten dan kemudian menggunakan debugger untuk melacak perilaku buruk dan menemukan bug.
Dalam pengujian fuzz, pengujian dapat menghasilkan ribuan vektor crash untuk beberapa bug, memberikan kesan yang salah dari sistem buggy. Sangat penting untuk menentukan dengan cepat vektor mana yang terkait dengan bug dasar yang sama. Untuk perangkat yang disematkan, lokasi error itu sendiri biasanya unik untuk bug tersebut, dan biasanya tidak diperlukan untuk menemukan pelacakan tumpukan panggilan lengkap.
Pengujian fuzzy berkelanjutan
Karena sifat stokastik dari tes fuzz, menjalankannya untuk waktu yang lebih lama meningkatkan peluang mereka untuk menemukan masalah. Namun tidak ada rencana proyek yang dapat menyerap penundaan dari siklus pengujian kabur yang panjang di akhir pengembangan.
Dalam praktiknya, pengujian fuzz akan dimulai pada cabangnya sendiri setelah proses rilis. Setiap bug yang baru ditemukan akan diperbaiki di cabang lokal, sehingga pengujian dapat dilanjutkan tanpa bug baru yang menghalangi penemuan bug tambahan. Sebagai bagian dari siklus rilis, bug yang ditemukan dari pengujian fuzz rilis sebelumnya akan dievaluasi untuk dimasukkan dalam rilis baru. Terakhir, vektor fuzz yang telah menemukan bug harus ditambahkan ke proses jaminan kualitas normal untuk memverifikasi perbaikan dan untuk memastikan bug ini tidak secara tidak sengaja dimasukkan kembali ke dalam kode.
Kita harus menjalankan tes fuzz perangkat dalam skenario yang berbeda; misalnya, perangkat merespons permintaan koneksi secara berbeda jika terhubung ke jaringan. Tidak praktis untuk menjalankan pengujian fuzz pada setiap skenario yang memungkinkan, tetapi kami dapat menyertakan pengujian fuzz untuk setiap nilai status yang memungkinkan. Misalnya, jalankan tes fuzz dengan setiap jenis perangkat yang berbeda sambil menjaga variabel lain tetap sama. Kemudian jalankan nilai yang berbeda untuk variabel lain, seperti status konektivitas jaringan, untuk satu jenis perangkat.
Arsitektur pengujian Fuzz
Dua arsitektur pengujian fuzz terkemuka adalah fuzzing terarah, di mana vektor fuzz ditentukan oleh seorang insinyur sebelum pengujian, dan pengujian fuzz yang dipandu cakupan, di mana alat fuzz dimulai dengan set vektor uji awal dan secara otomatis mengubahnya berdasarkan seberapa baik paket menembus kodenya.
Selain itu, tidak semua kode akan berjalan di PC, dan mengembangkan simulator PC untuk aplikasi yang disematkan mungkin tidak praktis, tergantung pada apa yang sedang diuji.
Di bawah ini adalah ringkasan dari empat arsitektur pengujian fuzz:
Pengujian antarmuka langsung pada perangkat keras tersemat—menjalankan citra produksi normal pada perangkat tersemat dengan paket fuzz yang disuntikkan melalui antarmuka
Pengujian injeksi paket (tumpukan)—memanggil rutin paket yang masuk secara langsung tanpa harus menjalankan antarmuka melalui udara
Mengarahkan fuzzing dengan simulator—menggunakan teknik simulasi berbasis PC untuk mengembangkan dan menguji kode yang disematkan
Penyimpangan yang dipandu oleh liputan dengan simulator (ditampilkan sebagai Libfuzz di bawah)
Beberapa penguji bulu halus
Setelah mengunci perangkat tertanam dengan kunci antarmuka debug dan boot aman, kita perlu mempertimbangkan pengujian fuzz antarmuka perangkat. Banyak alat dan konsep yang sama yang digunakan untuk mengamankan server web dapat diadaptasi untuk digunakan dengan perangkat yang disematkan.
Gunakan alat yang tepat untuk pekerjaan itu. Fuzzing yang dipandu cakupan diperlukan untuk pengujian fuzz yang berkelanjutan, tetapi jika kode Anda hanya dijalankan pada perangkat keras yang disematkan, fuzzer yang diarahkan dapat menjadi pilihan yang baik untuk menyediakan beberapa tingkat cakupan pengujian fuzz.
Terakhir, Anda harus menggunakan beberapa penguji fuzz dalam sebanyak mungkin skenario, karena masing-masing akan menguji perangkat dengan sedikit berbeda, memaksimalkan cakupan dan karenanya keamanan perangkat yang disematkan.
>> Artikel ini awalnya diterbitkan pada situs saudara kami, EDN.
