3.0 KiB
{{#include ../../banners/hacktricks-training.md}}
Integridade do Firmware
O firmware personalizado e/ou binários compilados podem ser carregados para explorar falhas de verificação de integridade ou assinatura. Os seguintes passos podem ser seguidos para a compilação de um shell bind de backdoor:
- O firmware pode ser extraído usando firmware-mod-kit (FMK).
- A arquitetura do firmware alvo e a ordem de bytes devem ser identificadas.
- Um compilador cruzado pode ser construído usando Buildroot ou outros métodos adequados para o ambiente.
- A backdoor pode ser construída usando o compilador cruzado.
- A backdoor pode ser copiada para o diretório /usr/bin do firmware extraído.
- O binário QEMU apropriado pode ser copiado para o rootfs do firmware extraído.
- A backdoor pode ser emulada usando chroot e QEMU.
- A backdoor pode ser acessada via netcat.
- O binário QEMU deve ser removido do rootfs do firmware extraído.
- O firmware modificado pode ser reempacotado usando FMK.
- O firmware com backdoor pode ser testado emulando-o com a ferramenta de análise de firmware (FAT) e conectando-se ao IP e porta da backdoor alvo usando netcat.
Se um shell root já foi obtido através de análise dinâmica, manipulação do bootloader ou testes de segurança de hardware, binários maliciosos pré-compilados, como implantes ou shells reversos, podem ser executados. Ferramentas automatizadas de payload/implante, como o framework Metasploit e 'msfvenom', podem ser aproveitadas usando os seguintes passos:
- A arquitetura do firmware alvo e a ordem de bytes devem ser identificadas.
- Msfvenom pode ser usado para especificar o payload alvo, IP do host atacante, número da porta de escuta, tipo de arquivo, arquitetura, plataforma e o arquivo de saída.
- O payload pode ser transferido para o dispositivo comprometido e garantir que ele tenha permissões de execução.
- O Metasploit pode ser preparado para lidar com solicitações recebidas iniciando o msfconsole e configurando as configurações de acordo com o payload.
- O shell reverso meterpreter pode ser executado no dispositivo comprometido.
- As sessões meterpreter podem ser monitoradas à medida que se abrem.
- Atividades pós-exploração podem ser realizadas.
Se possível, vulnerabilidades dentro de scripts de inicialização podem ser exploradas para obter acesso persistente a um dispositivo durante reinicializações. Essas vulnerabilidades surgem quando scripts de inicialização referenciam, link simbolicamente, ou dependem de código localizado em locais montados não confiáveis, como cartões SD e volumes flash usados para armazenar dados fora dos sistemas de arquivos raiz.
Referências
- Para mais informações, consulte https://scriptingxss.gitbook.io/firmware-security-testing-methodology/
{{#include ../../banners/hacktricks-training.md}}