Cara Analisis Firmware IoT untuk Menemukan Celah Keamanan — Panduan Pemula
Akhir tahun 2020, saya dikasih sebuah IP camera oleh klien — brand lokal Indonesia yang cukup populer di marketplace. Klien saya udah beli puluhan unit buat kantor cabang mereka. Masalahnya, mereka nemu indikasi kalau feed kamera bisa diakses tanpa login kalau tahu endpoint API-nya. Saya diminta investigasi. Tanpa dokumentasi, tanpa source code, tanpa akses ke vendor. Cuma dikasih satu unit kamera dan bilang “tolong dicek keamanannya”. Saya putuskan buat langsung ke jantung perangkatnya: firmware. Dan di sinilah cara analisis firmware IoT jadi skill yang nggak tergantikan.
Saya download firmware dari website vendor, ekstrak pakai binwalk, dan mulai cari-cari. Beberapa jam kemudian saya nemu sesuatu yang bikin saya geleng-geleng kepala: di dalam file konfigurasi yang ter-embedded di firmware, ada username dan password admin — lengkap, plain text, tanpa enkripsi. Bukan password default yang bisa diganti user — ini akun hardcoded yang tetep aktif meskipun user udah ganti password lewat web interface. Dan yang lebih parah? Akun ini bisa dipakai buat login SSH ke perangkat. Attacker cukup download firmware dari website vendor (yang tersedia publik), ekstrak, dapet kredensial, terus tinggal SSH ke semua unit yang terpasang. Game over.
Dari situ saya sadar bahwa kemampuan membongkar firmware IoT bukan cuma skill spesialis — tapi skill fundamental buat siapapun yang serius dengan keamanan IoT. Nah, di artikel ini saya akan ajak kamu — dari nol — belajar cara analisis firmware IoT. Tools yang dipakai, langkah-langkahnya, dan apa aja yang biasanya saya temukan di lapangan.
Firmware Itu Sebenarnya Apa?
Sebelum kita masuk ke teknis analisis, kita perlu ngerti dulu: apa itu firmware? Secara simpel, firmware adalah software yang tertanam di perangkat keras — semacam sistem operasi mini yang ngatur cara kerja perangkat. Kalau laptop kamu jalan pakai Windows atau Linux, maka perangkat IoT jalan pakai firmware.
Firmware biasanya terdiri dari beberapa komponen: bootloader (yang pertama jalan pas perangkat dinyalakan), kernel (Linux kernel, biasanya versi yang udah di-strip-down biar muat di storage kecil), root filesystem (berisi semua file binary, library, dan konfigurasi), dan aplikasi utama perangkat tersebut (misalnya web server untuk panel admin CCTV).
Firmware ini biasanya disimpan di flash memory di dalam perangkat, dan bisa di-update lewat mekanisme tertentu (kalau ada). File firmware biasanya berbentuk binary image — kadang di-compress, kadang nggak — dengan ekstensi seperti .bin, .img, .fw, atau .zip. Tugas kita sebagai analyst adalah memecah binary ini jadi komponen-komponen yang bisa kita periksa satu per satu.
Kenapa Analisis Firmware Penting untuk Keamanan IoT?
Ada beberapa alasan kenapa analisis firmware itu kritis.
Pertama, menemukan hardcoded credentials. Seperti yang saya ceritakan di awal, banyak vendor yang nge-hardcode username dan password langsung di firmware. Kadang buat debugging, kadang buat backdoor remote support. Begitu firmware-nya di-ekstrak, semua ini langsung keliatan.
Kedua, mengidentifikasi library dan komponen kedaluwarsa. Firmware sering kali pakai library open source versi lama yang punya puluhan CVE known. Misalnya OpenSSL 0.9.8 (yang udah end-of-life sejak 2015) masih banyak dipakai di perangkat IoT tahun 2023.
Ketiga, menemukan private keys dan certificates. Pernah nemu SSL private key di-hardcode dalam firmware IP camera — artinya semua komunikasi “aman” HTTPS dari kamera itu bisa di-decrypt karena kuncinya udah diketahui publik.
Keempat, mendeteksi debug interface yang tertinggal. Banyak firmware yang nyalain service debug (telnet, SSH, ADB, serial console) tanpa password. Kadang ini disengaja buat development, tapi lupa dimatikan waktu rilis ke produksi.
Kelima, memahami bagaimana perangkat bekerja — ini penting banget buat vulnerability research. Dengan ngerti arsitektur software-nya, kamu bisa identifikasi di mana kemungkinan adanya buffer overflow, command injection, atau logic flaw.
Tools yang Wajib Disiapkan
Saya akan jelaskan tools utama yang saya pakai sehari-hari untuk analisis firmware IoT. Semuanya open source dan gratis.
Binwalk — Si Pembelah Firmware
Binwalk adalah tools pertama yang saya buka setiap kali dapat firmware baru. Dibuat oleh Craig Heffner, binwalk bisa scan binary firmware dan mengidentifikasi struktur di dalamnya — filesystem, kernel image, compressed data, archive, dll. Dia bisa mendeteksi signature dari berbagai jenis filesystem (SquashFS, JFFS2, YAFFS, CramFS) dan archive (gzip, LZMA, ZIP, ARJ).
Cara install-nya simpel: sudo apt install binwalk (di Ubuntu/Debian) atau git clone untuk install dari source. Penggunaan dasarnya juga gampang: binwalk firmware.bin buat scan, atau binwalk -e firmware.bin buat scan plus otomatis ekstrak semua yang dia temukan.
Saya sering pakai flag -Me (Matryoshka mode + follow extraction) yang bikin binwalk ekstrak secara rekursif — jadi kalau di dalamnya ada arsip lagi, dia ekstrak juga.
Firmware Mod Kit (FMK)
FMK adalah toolkit yang lebih advanced untuk memodifikasi firmware. Fitur utamanya: ekstraksi firmware lengkap, modifikasi filesystem, dan build ulang firmware. Ini berguna kalau kamu pengen nambahin tool sendiri (misal strace atau gdb) ke firmware buat dynamic analysis.
Tapi jujur, FMK agak tua dan kadang nggak jalan di kernel Linux versi baru. Saya lebih sering pakai binwalk dulu, terus kalau butuh rebuild pakai tools lain atau manual. Tapi untuk belajar, FMK tetap worth buat dicoba.
QEMU untuk Emulasi — Testing Tanpa Perangkat Fisik
QEMU adalah emulator yang bisa ngejalanin binary dari arsitektur berbeda. Misalnya, firmware IoT biasanya jalan di arsitektur ARM atau MIPS, sementara laptop kamu jalan di x86. Dengan QEMU, kamu bisa ngejalanin binary ARM/MIPS di laptop x86 — sehingga bisa ngetes perangkat tanpa punya perangkat fisiknya.
Ini powerful banget. Kamu bisa ngejalanin web server-nya IP camera di laptop kamu, akses dari browser, terus nyari vulnerability-nya — semua tanpa pegang kameranya langsung. Konsepnya disebut emulated firmware testing.
Step-by-Step Ekstraksi Firmware
Oke, sekarang saya kasih contoh langkah-langkah ekstraksi firmware yang biasa saya lakukan. Anggap kita punya file firmware camera CCTV dengan nama firmware_cctv.bin.
Langkah 1: Identifikasi struktur dengan binwalk. Jalankan binwalk firmware_cctv.bin. Outputnya akan nunjukin di offset berapa ada filesystem, kernel, atau data compressed. Misal hasilnya:
DECIMAL HEXADECIMAL DESCRIPTION
0 0x0 uImage header, header size: 64 bytes
155648 0x26000 LZMA compressed data
1048576 0x100000 Squashfs filesystem
Dari sini kita tahu firmware ini punya kernel (uImage) di offset 0, data terkompresi LZMA di offset 155648, dan filesystem SquashFS di offset 1048576.
Langkah 2: Ekstrak otomatis dengan binwalk -Me firmware_cctv.bin. Binwalk akan bikin folder baru berisi hasil ekstraksinya. Di dalamnya akan ada folder filesystem (misal squashfs-root) yang isinya struktur direktori Linux lengkap: /bin, /etc, /lib, /usr, /var, dll.
Langkah 3: Masuk ke folder filesystem dan mulai eksplorasi. Di sinilah kerjaan analisis yang sebenernya dimulai. Kita akan lihat isi-isi file konfigurasi, binary executable, script shell, dan semua yang menarik.
Menemukan Hardcoded Credentials — Teknik Pencarian
Ini bagian favorit saya. Begitu filesystem udah terekstrak, saya langsung cari string-string yang berhubungan dengan autentikasi. Beberapa command yang rutin saya jalanin:
# Cari file yang mengandung kata "password"
grep -r "password" . --include="*.conf" --include="*.cfg" --include="*.ini" --include="*.xml" --include="*.json"
# Cari string "admin" di file binary dan text
grep -r "admin" . --include="*.conf" --include="*.cfg" --include="*.sh" --include="*.lua"
# Cari hash password (pola umum)
grep -rE '\$[0-9]\$.*\$.*' .
# Cari hardcoded credential di binary dengan strings
strings ./usr/sbin/camera_app | grep -iE "(username|password|login|passwd|root|admin)"
Selain grep, saya juga pakai strings buat ekstrak teks dari binary compiled, terus di-grep lagi. Kadang kredensial nggak disimpen di file teks, tapi di-hardcode langsung di binary C.
Satu tool yang sangat membantu: findcrypt atau hash-identifier — buat identifikasi jenis hash kalau nemu password yang di-hash (bukan plaintext).
Mengidentifikasi Library Kedaluwarsa dengan CVE Known
Setelah dapet filesystem, langkah berikutnya: cek versi library dan komponen apa yang dipakai. Ini penting buat identifikasi kerentanan yang udah published.
Cara paling simpel: cari file version di direktori library. Misal:
# Lihat versi OpenSSL
strings ./lib/libssl.so* | grep -E "OpenSSL [0-9]"
# Lihat versi busybox (tools Linux embedded)
./bin/busybox 2>&1 | head -1
# Cek versi dropbear (SSH server untuk embedded)
strings ./usr/sbin/dropbear | grep -E "v[0-9]+"
Begitu dapet versinya, saya tinggal cek di NVD (National Vulnerability Database) atau pakai tools kaya cve-search atau vulners buat lihat CVE apa aja yang mempengaruhi versi tersebut. Sering banget nemu OpenSSL versi 0.9.x dengan puluhan CVE critical.
Debug Interface yang Tertinggal — Jalan Masuk yang Nggak Disengaja
Banyak firmware IoT yang ninggalin service debug yang harusnya cuma ada di versi development. Ini temuan yang umum banget dan sering kali high severity karena biasanya nggak ada autentikasinya.
Yang paling sering saya temuin:
Telnet tanpa password. Coba cek file /etc/inittab atau /etc/init.d/ — kalau ada service telnetd yang dijalankan tanpa autentikasi, itu jackpot. Attacker tinggal telnet ke IP perangkat, langsung dapet shell root.
Serial console (UART). Meskipun ini nggak langsung keliatan di firmware, kadang ada konfigurasi di /etc/inittab yang nunjukin bahwa serial console nyala dengan autologin root — misal ttyS0::respawn:/sbin/getty -L ttyS0 115200 vt100.
ADB (Android Debug Bridge) tanpa autentikasi. Banyak perangkat IoT yang basisnya Android (smart TV, smart display, beberapa CCTV). Kalau ADB-nya nyala tanpa authentication, attacker bisa remote shell penuh ke perangkat.
Emulasi Firmware dengan QEMU — Testing Dinamis
Setelah analisis statis selesai, kadang kita perlu ngejalanin firmware buat testing dinamis — misalnya buat ngecek apakah service tertentu vulnerable, atau buat testing exploit yang kita develop. Nah, di sinilah QEMU berperan.
Konsep dasarnya: kita pakai QEMU user-mode buat ngejalanin binary ARM/MIPS di atas sistem x86. Caranya:
# Install QEMU user mode untuk arsitektur target (contoh: ARM)
sudo apt install qemu-user-static
# Chroot ke filesystem firmware yang udah diekstrak
sudo chroot ./squashfs-root /bin/sh
# Atau jalankan binary spesifik
qemu-arm-static -L ./squashfs-root ./squashfs-root/usr/sbin/lighttpd
Ini nggak selalu mulus — sering ada dependency issues karena mismatch kernel atau library versi. Tapi untuk kasus sederhana, biasanya jalan. Saya sering pakai ini buat ngejalanin web server embedded dan ngakses dari browser lokal.
Temuan Umum dalam Firmware IoT — Apa yang Biasanya Saya Temukan
Setelah bertahun-tahun membongkar firmware, ada beberapa temuan yang muncul berulang kali. Ini daftarnya:
Hardcoded password — ini juara bertahan nomor satu. Baik password admin, password database, password Wi-Fi, atau API keys. Semuanya di-hardcode langsung di file konfigurasi atau binary.
Private keys untuk SSL/TLS — banyak perangkat yang generate satu pasangan key di pabrik, terus dipakai di semua unit. Artinya kalau kamu dapet satu firmware, kamu bisa decrypt traffic HTTPS dari semua perangkat sejenis.
Command injection di CGI scripts — banyak web interface IoT yang pakai CGI (Common Gateway Interface) scripts, dan input user sering kali langsung di-pass ke shell command tanpa sanitasi. Classic command injection.
Default password web server — banyak perangkat yang pakai web server embedded (seperti lighttpd, mini_httpd, atau thttpd) dengan konfigurasi default yang mencakup test pages atau info disclosure.\n\nKredensial database embedded — kalau perangkat pakai SQLite atau database embedded lain, sering kali kredensialnya di-simpan plain text di file konfigurasi. Saya pernah nemu satu IP camera yang nyimpen semua password user di file SQLite tanpa enkripsi — termasuk password admin yang udah diganti user. Jadi walaupun user merasa aman karena udah ganti password, attacker yang bisa akses filesystem tetap bisa baca database-nya langsung.
Update mechanism tanpa validasi — firmware update di-download lewat HTTP tanpa checksum atau digital signature. Artinya attacker di posisi man-in-the-middle bisa modifikasi firmware sebelum sampai ke perangkat, dan perangkat akan install firmware palsu tanpa complaint. Ini termasuk kategori supply chain attack yang dampaknya permanen.
Satu Hal Penting Sebelum Kamu Mulai
Sebelum kamu semangat download firmware dan mulai membongkarnya, ingat satu hal: pastikan kamu punya izin. Firmware adalah properti intelektual vendor, dan membongkar firmware tanpa izin bisa melanggar EULA atau bahkan hukum di beberapa yurisdiksi. Untuk keperluan belajar, pakailah firmware yang memang dirilis untuk publik atau perangkat yang kamu miliki sendiri. Etika tetap nomor satu.
Penutup — Analisis Firmware Itu Pintu Masuk ke Keamanan IoT
Cara analisis firmware IoT adalah skill yang terus berkembang — tapi dasarnya simpel. Download firmware, ekstrak pakai binwalk, cari string mencurigakan pakai grep, identifikasi versi library, dan tes pakai emulasi kalau perlu. Nggak butuh lab mahal atau sertifikasi khusus. Tools-nya gratis semua. Yang dibutuhkan cuma ketekunan dan rasa penasaran.
Balik ke cerita CCTV brand Indonesia yang saya analisis di awal. Setelah nemu hardcoded SSH credential, saya langsung kontak vendor-nya dan ngasih tahu temuan saya — lengkap dengan langkah remediasi. Syukurnya mereka kooperatif. Dalam beberapa minggu, mereka rilis firmware update yang nutup backdoor tersebut. Tapi pertanyaan yang sampai sekarang mengganjal di kepala saya: berapa banyak unit yang udah terjual sebelumnya? Dan berapa banyak yang masih pakai firmware lawas dengan backdoor yang masih aktif? Itu pertanyaan yang nggak bisa saya jawab. Tapi setidaknya, dengan skill analisis firmware, saya bisa menemukan dan membantu nutup satu celah. Satu per satu.
