Firmware Analysis

tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Вивчайте та практикуйте Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримайте HackTricks

Introduction

{{#ref}} synology-encrypted-archive-decryption.md {{#endref}}

Прошивка є основним програмним забезпеченням, яке дозволяє пристроям працювати правильно, керуючи та полегшуючи зв'язок між апаратними компонентами та програмним забезпеченням, з яким взаємодіють користувачі. Вона зберігається в постійній пам'яті, що забезпечує доступ пристрою до важливих інструкцій з моменту його ввімкнення, що призводить до запуску операційної системи. Аналіз та потенційне модифікування прошивки є критичним кроком у виявленні вразливостей безпеки.

Gathering Information

Збір інформації є критично важливим початковим кроком у розумінні складу пристрою та технологій, які він використовує. Цей процес включає збір даних про:

  • Архітектуру ЦП та операційну систему, на якій він працює
  • Специфікації завантажувача
  • Схему апаратного забезпечення та технічні характеристики
  • Метрики кодової бази та місця розташування виходу
  • Зовнішні бібліотеки та типи ліцензій
  • Історії оновлень та регуляторні сертифікати
  • Архітектурні та потокові діаграми
  • Оцінки безпеки та виявлені вразливості

Для цієї мети інструменти відкритої інформації (OSINT) є безцінними, як і аналіз будь-яких доступних компонентів відкритого програмного забезпечення через ручні та автоматизовані процеси перевірки. Інструменти, такі як Coverity Scan та Semmle’s LGTM, пропонують безкоштовний статичний аналіз, який можна використовувати для виявлення потенційних проблем.

Acquiring the Firmware

Отримання прошивки можна здійснити різними способами, кожен з яких має свій рівень складності:

  • Безпосередньо від джерела (розробників, виробників)
  • Створення її з наданих інструкцій
  • Завантаження з офіційних сайтів підтримки
  • Використання Google dork запитів для знаходження розміщених файлів прошивки
  • Доступ до хмарного сховища безпосередньо, за допомогою інструментів, таких як S3Scanner
  • Перехоплення оновлень за допомогою технік "людина посередині"
  • Витягування з пристрою через з'єднання, такі як UART, JTAG або PICit
  • Перехоплення запитів на оновлення в межах зв'язку пристрою
  • Виявлення та використання жорстко закодованих кінцевих точок оновлень
  • Скидання з завантажувача або мережі
  • Видалення та читання чіпа пам'яті, коли всі інші способи не спрацювали, використовуючи відповідні апаратні інструменти

Analyzing the firmware

Тепер, коли ви маєте прошивку, вам потрібно витягти інформацію про неї, щоб знати, як з нею працювати. Різні інструменти, які ви можете використовувати для цього:

bash
file <bin>
strings -n8 <bin>
strings -tx <bin> #print offsets in hex
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 -E <bin>, якщо ентропія низька, то, ймовірно, воно не зашифроване. Якщо ентропія висока, ймовірно, воно зашифроване (або стиснуте якимось чином).

Більше того, ви можете використовувати ці інструменти для витягування файлів, вбудованих у прошивку:

{{#ref}} ../../generic-methodologies-and-resources/basic-forensic-methodology/partitions-file-systems-carving/file-data-carving-recovery-tools.md {{#endref}}

Або binvis.io (code), щоб перевірити файл.

Отримання файлової системи

З попередніми коментованими інструментами, такими як binwalk -ev <bin>, ви повинні були змогти витягти файлову систему.
Binwalk зазвичай витягує її в папку, названу на честь типу файлової системи, яка зазвичай є однією з наступних: squashfs, ubifs, romfs, rootfs, jffs2, yaffs2, cramfs, initramfs.

Ручне витягування файлової системи

Іноді 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

Запустіть наступну 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

  • Для squashfs (використовується в наведеному вище прикладі)

$ unsquashfs dir.squashfs

Файли будуть у директорії "squashfs-root" після цього.

  • Файли архіву CPIO

$ cpio -ivd --no-absolute-filenames -F <bin>

  • Для файлових систем jffs2

$ jefferson rootfsfile.jffs2

  • Для файлових систем ubifs з NAND флеш-пам'яттю

$ ubireader_extract_images -u UBI -s <start_offset> <bin>

$ ubidump.py <bin>

Аналіз ПЗ

Після отримання ПЗ важливо розібрати його для розуміння його структури та потенційних вразливостей. Цей процес передбачає використання різних інструментів для аналізу та витягування цінних даних з образу ПЗ.

Інструменти початкового аналізу

Набір команд надається для початкової перевірки бінарного файлу (який називається <bin>). Ці команди допомагають у визначенні типів файлів, витягуванні рядків, аналізі бінарних даних та розумінні деталей розділів і файлової системи:

bash
file <bin>
strings -n8 <bin>
strings -tx <bin> #prints offsets in hexadecimal
hexdump -C -n 512 <bin> > hexdump.out
hexdump -C <bin> | head #useful for finding signatures in the header
fdisk -lu <bin> #lists partitions and filesystems, if there are multiple

Щоб оцінити статус шифрування зображення, перевіряється ентропія за допомогою binwalk -E <bin>. Низька ентропія вказує на відсутність шифрування, тоді як висока ентропія свідчить про можливе шифрування або стиснення.

Для витягування вбудованих файлів рекомендуються інструменти та ресурси, такі як документація file-data-carving-recovery-tools та binvis.io для перевірки файлів.

Витягування файлової системи

Використовуючи binwalk -ev <bin>, зазвичай можна витягти файлову систему, часто в каталог, названий на честь типу файлової системи (наприклад, squashfs, ubifs). Однак, коли binwalk не може розпізнати тип файлової системи через відсутні магічні байти, необхідно виконати ручне витягування. Це передбачає використання binwalk для визначення зсуву файлової системи, а потім команди dd для вирізання файлової системи:

bash
$ binwalk DIR850L_REVB.bin

$ dd if=DIR850L_REVB.bin bs=1 skip=1704084 of=dir.squashfs

Після цього, в залежності від типу файлової системи (наприклад, squashfs, cpio, jffs2, ubifs), використовуються різні команди для ручного витягування вмісту.

Аналіз файлової системи

Після витягування файлової системи починається пошук вразливостей безпеки. Увага приділяється небезпечним мережевим демонів, жорстко закодованим обліковим даним, API-інтерфейсам, функціональності серверів оновлень, некомпільованому коду, скриптам запуску та скомпільованим двійковим файлам для офлайн-аналізу.

Ключові місця та елементи для перевірки включають:

  • etc/shadow та etc/passwd для облікових даних користувачів
  • SSL сертифікати та ключі в etc/ssl
  • Конфігураційні та скриптові файли на предмет потенційних вразливостей
  • Вбудовані двійкові файли для подальшого аналізу
  • Загальні веб-сервери та двійкові файли IoT пристроїв

Кілька інструментів допомагають виявити чутливу інформацію та вразливості в файловій системі:

Перевірки безпеки скомпільованих двійкових файлів

Як вихідний код, так і скомпільовані двійкові файли, знайдені у файловій системі, повинні бути ретельно перевірені на вразливості. Інструменти, такі як checksec.sh для Unix двійкових файлів та PESecurity для Windows двійкових файлів, допомагають виявити незахищені двійкові файли, які можуть бути використані в атаках.

Емуляція прошивки для динамічного аналізу

Процес емулювання прошивки дозволяє динамічний аналіз або роботи пристрою, або окремої програми. Цей підхід може стикатися з проблемами залежностей апаратного забезпечення або архітектури, але перенесення кореневої файлової системи або конкретних двійкових файлів на пристрій з відповідною архітектурою та порядком байтів, наприклад, Raspberry Pi, або на попередньо зібрану віртуальну машину, може полегшити подальше тестування.

Емуляція окремих двійкових файлів

Для аналізу окремих програм важливо визначити порядок байтів програми та архітектуру ЦП.

Приклад з архітектурою MIPS

Щоб емулювати двійковий файл архітектури MIPS, можна використовувати команду:

bash
file ./squashfs-root/bin/busybox

І щоб встановити необхідні інструменти емуляції:

bash
sudo apt-get install qemu qemu-user qemu-user-static qemu-system-arm qemu-system-mips qemu-system-x86 qemu-utils

Для MIPS (big-endian) використовується qemu-mips, а для little-endian бінарних файлів вибирається qemu-mipsel.

Емуляція архітектури ARM

Для ARM бінарних файлів процес подібний, з використанням емулятора qemu-arm.

Емуляція повної системи

Інструменти, такі як Firmadyne, Firmware Analysis Toolkit та інші, полегшують повну емуляцію прошивки, автоматизуючи процес і допомагаючи в динамічному аналізі.

Динамічний аналіз на практиці

На цьому етапі використовується реальне або емульоване середовище пристрою для аналізу. Важливо підтримувати доступ до оболонки ОС та файлової системи. Емуляція може не ідеально відтворювати взаємодію з апаратним забезпеченням, що потребує періодичних перезапусків емуляції. Аналіз має повторно перевіряти файлову систему, експлуатувати відкриті веб-сторінки та мережеві сервіси, а також досліджувати вразливості завантажувача. Тести цілісності прошивки є критично важливими для виявлення потенційних вразливостей бекдорів.

Техніки аналізу в реальному часі

Аналіз в реальному часі передбачає взаємодію з процесом або бінарним файлом у його операційному середовищі, використовуючи інструменти, такі як gdb-multiarch, Frida та Ghidra для встановлення точок зупинки та виявлення вразливостей через фуззинг та інші техніки.

Експлуатація бінарних файлів та доказ концепції

Розробка PoC для виявлених вразливостей вимагає глибокого розуміння цільової архітектури та програмування на мовах нижчого рівня. Захисти бінарного виконання в вбудованих системах рідкісні, але коли вони присутні, можуть знадобитися такі техніки, як Return Oriented Programming (ROP).

Підготовлені операційні системи для аналізу прошивки

Операційні системи, такі як AttifyOS та EmbedOS, надають попередньо налаштовані середовища для тестування безпеки прошивки, оснащені необхідними інструментами.

Підготовлені ОС для аналізу прошивки

  • AttifyOS: AttifyOS - це дистрибутив, призначений для допомоги у проведенні оцінки безпеки та тестування на проникнення пристроїв Інтернету речей (IoT). Він економить ваш час, надаючи попередньо налаштоване середовище з усіма необхідними інструментами.
  • EmbedOS: Операційна система для тестування безпеки вбудованих систем на базі Ubuntu 18.04, попередньо завантажена з інструментами для тестування безпеки прошивки.

Атаки на зниження версії прошивки та небезпечні механізми оновлення

Навіть коли постачальник реалізує перевірки криптографічного підпису для образів прошивки, захист від зниження версії (downgrade) часто пропускається. Коли завантажувач або відновлювальний завантажувач лише перевіряє підпис з вбудованим відкритим ключем, але не порівнює версію (або монотонний лічильник) образу, що записується, зловмисник може легітимно встановити стару, вразливу прошивку, яка все ще має дійсний підпис і таким чином повторно ввести виправлені вразливості.

Типовий робочий процес атаки:

  1. Отримати старий підписаний образ
  • Завантажити його з публічного порталу завантаження постачальника, CDN або сайту підтримки.
  • Витягти його з супутніх мобільних/десктопних додатків (наприклад, всередині Android APK під assets/firmware/).
  • Отримати його з сторонніх репозиторіїв, таких як VirusTotal, архіви Інтернету, форуми тощо.
  1. Завантажити або надати образ пристрою через будь-який відкритий канал оновлення:
  • Веб-інтерфейс, API мобільного додатку, USB, TFTP, MQTT тощо.
  • Багато споживчих IoT-пристроїв відкривають неаутентифіковані HTTP(S) кінцеві точки, які приймають Base64-кодовані бінарні файли прошивки, декодують їх на сервері та запускають відновлення/оновлення.
  1. Після зниження версії експлуатувати вразливість, яка була виправлена в новішому випуску (наприклад, фільтр ін'єкції команд, який був доданий пізніше).
  2. За бажанням перепрошити останній образ або вимкнути оновлення, щоб уникнути виявлення після отримання стійкості.

Приклад: Ін'єкція команд після зниження версії

http
POST /check_image_and_trigger_recovery?md5=1; echo 'ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC...' >> /root/.ssh/authorized_keys HTTP/1.1
Host: 192.168.0.1
Content-Type: application/octet-stream
Content-Length: 0

У вразливому (зниженому) прошивці параметр md5 безпосередньо конкатенується в команду оболонки без санітизації, що дозволяє ін'єкцію довільних команд (тут – увімкнення доступу до root через SSH з використанням ключа). Пізніші версії прошивки впровадили базовий фільтр символів, але відсутність захисту від зниження версії робить виправлення недійсним.

Витягування прошивки з мобільних додатків

Багато постачальників об'єднують повні образи прошивки всередині своїх супутніх мобільних додатків, щоб додаток міг оновлювати пристрій через Bluetooth/Wi-Fi. Ці пакети зазвичай зберігаються нешифрованими в APK/APEX під шляхами, такими як assets/fw/ або res/raw/. Інструменти, такі як apktool, ghidra або навіть простий unzip, дозволяють вам витягувати підписані образи, не торкаючись фізичного обладнання.

$ apktool d vendor-app.apk -o vendor-app
$ ls vendor-app/assets/firmware
firmware_v1.3.11.490_signed.bin

Чек-лист для оцінки логіки оновлення

  • Чи адекватно захищений транспорт/автентифікація кінцевої точки оновлення (TLS + автентифікація)?
  • Чи порівнює пристрій номери версій або монотонний анти-ролбек лічильник перед прошивкою?
  • Чи перевіряється образ у безпечному ланцюзі завантаження (наприклад, підписи перевіряються кодом ROM)?
  • Чи виконує код користувацького простору додаткові перевірки (наприклад, дозволена карта розділів, номер моделі)?
  • Чи використовують часткові або резервні потоки оновлення ту ж саму логіку валідації?

💡 Якщо щось із вищезазначеного відсутнє, платформа, ймовірно, вразлива до атак на відкат.

Вразливе ПЗ для практики

Щоб практикуватися у виявленні вразливостей у прошивці, використовуйте наступні вразливі проекти прошивки як відправну точку.

Посилання

Тренінг та сертифікація

tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Вивчайте та практикуйте Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримайте HackTricks