blog

May 21, 2024

Como usar engenharia reversa dinâmica para dispositivos embarcados

A proliferação da IoT foi acompanhada por uma proliferação de vulnerabilidades de segurança. Se não forem controlados, os invasores mal-intencionados podem usar essas fraquezas para se infiltrar nos sistemas das organizações. Regular

A proliferação da IoT foi acompanhada por uma proliferação de vulnerabilidades de segurança. Se não forem controlados, os invasores mal-intencionados podem usar essas fraquezas para se infiltrar nos sistemas das organizações.

Os testes de penetração regulares, há muito reconhecidos como uma prática recomendada de segurança, ajudam as equipes de segurança a identificar e mitigar vulnerabilidades e pontos fracos em dispositivos incorporados. Muitas organizações, no entanto, limitam os testes de penetração à investigação de redes e infraestruturas – os dispositivos IoT são frequentemente ignorados.

Para que as equipes de segurança se atualizem nos testes de penetração de dispositivos incorporados, Jean-Georges Valle, vice-presidente sênior da Kroll, uma consultoria de risco cibernético e serviços financeiros, escreveu Practical Hardware Pentesting: Aprenda técnicas de ataque e defesa para sistemas embarcados em IoT e outros dispositivos .

No trecho a seguir do Capítulo 10, Valle detalha como os pen testers podem usar engenharia reversa dinâmica para ver como o código se comporta durante a execução em dispositivos incorporados. Valle fornece um exemplo de engenharia reversa dinâmica para mostrar aos testadores os desafios que podem surgir ao observar como o código se comporta.

Leia uma entrevista com Valle sobre testes de penetração incorporados, incluindo etapas de teste comuns que ele usa, as dificuldades dos testes de penetração incorporados e sua opinião sobre o quão bem as organizações hoje protegem os dispositivos incorporados.

Nota do editor: O trecho a seguir é de uma versão de acesso antecipado do Practical Hardware Pentesting, Second Edition e está sujeito a alterações.

Preparei uma variante do exemplo anterior que nos colocará alguns desafios. Mostrarei como superar esses desafios de forma estática e dinâmica para que você possa comparar a quantidade de esforço necessária em ambos os casos.

A regra geral ao comparar abordagens dinâmicas e estáticas é que 99% das vezes, as abordagens dinâmicas são apenas mais fáceis e devem receber prioridade, se possível (não se esqueça de que talvez você não consiga obter acesso ao JTAG/SWD ou outro protocolos de depuração no chip).

Nesta seção também aprenderemos como quebrar onde quisermos, inspecionar a memória com GDB e todas essas coisas boas!

O programa alvo está localizado aqui na pasta que você clonou, na pasta ch12.

Primeiro, vamos começar carregando-o no Ghidra e inspecionando-o superficialmente. Preste atenção ao definir a arquitetura correta e o endereço base na janela de carregamento do Ghidra (consulte o capítulo anterior se você não se lembra de como fazer isso ou do valor do endereço base).

À primeira vista, a função principal é muito semelhante à função principal do capítulo anterior. Podemos encontrar a referência à função principal pesquisando uma string PASSWORD como no capítulo anterior e analisando sua estrutura.

Vou deixar você trabalhar nas habilidades adquiridas no capítulo anterior para encontrar as diferentes funções. Neste executável, você encontrará novamente o seguinte:

A semelhança da estrutura é intencional, pois esta é a sua primeira vez. Se eu repetisse exatamente os mesmos passos do capítulo anterior, não daria nada de novo para você aprender, certo?

Agora, vamos examinar vários métodos para contornar essa validação de senha por meio da interação dinâmica com o sistema. Iremos do mais complexo ao mais simples para mantê-lo focado e adquirindo know-how (se você é como eu, se existe uma maneira fácil de contornar algo, por que optar pelo caminho mais difícil?).

A primeira coisa que vamos fazer é tentar ver como a senha é validada para entender como gerar uma senha que passe nos testes.

Vamos dar uma olhada no código C equivalente da função de validação gerado pelo Ghidra:

Humm... isso não faz nada diretamente com os parâmetros. Isso está copiando o conteúdo de uma matriz estática de bytes de 0x47 (71) para a RAM (e NÃO) e, em seguida, chama-o como uma função.

Isto é estranho.

Ou é?

Esta é uma técnica muito comum para camuflar código (é claro, uma versão muito simples dela). Se uma versão clara do opcode não estiver presente no arquivo .bin (e, portanto, não no flash do MCU), uma ferramenta de engenharia reversa como o Ghidra não poderá detectar que se trata de um código! Aqui, temos duas abordagens possíveis: