Fault Injection Finder

▄▖    ▜ ▗   ▄▖   ▘    ▗ ▘      ▄▖▘   ▌     
▙▖▀▌▌▌▐ ▜▘  ▐ ▛▌ ▌█▌▛▘▜▘▌▛▌▛▌  ▙▖▌▛▌▛▌█▌▛▘ 
▌ █▌▙▌▐▖▐▖  ▟▖▌▌ ▌▙▖▙▖▐▖▌▙▌▌▌  ▌ ▌▌▌▙▌▙▖▌  
                ▙▌                         

Geeoon Chung and Nate Snyder

Este repositório é o lado de software do nosso projeto de ataque por injeção de falhas. Para o lado do hardware, consulte este repositório.

Visão Geral do Projeto

O objetivo deste projeto é encontrar instruções na execução de um programa que, quando ignoradas/substituídas por NOP, causam problemas de segurança.

1. Pré-processamento
   1. Carregar o binário
   2. Identificar instruções que têm maior probabilidade de causar problemas de segurança quando substituídas por NOP.
2. Emulação com Unicorn
   1. Executar o programa, aplicando NOP à enésima instrução emitida.
   2. Verificar a saída do programa para ver se ocorreu uma falha de segurança.
      1. Se ocorreu uma busca inválida, inverter todos os bits da entrada do programa.
      2. Executar o programa novamente.
      3. Se ocorreu uma busca inválida em um endereço diferente, anote. Isso significa que a entrada do programa é capaz de influenciar o contador de programa (ou seja, o controle do PC).
3. Resolução SMT com Angr
   1. Se a emulação com Unicorn indicou controle do PC, executar o programa com entradas simbólicas e pular a emissão da instrução da etapa do Unicorn.
   2. Verificar se eventualmente obtemos uma variável simbólica no registrador PC.
   3. Resolver para um valor de PC personalizado para ver qual entrada precisamos para levar o PC a um endereço específico.
   4. Se for possível resolver, anote a entrada que resultou no PC especificado.
4. Exportar instruções interessantes
5. Testar as instruções no alvo usando o script targets/tooling.py e uma FPGA.

Fluxograma do software

Uma apresentação que fizemos para este projeto

Detalhes

Procuramos por problemas de segurança realizando uma ou mais das seguintes ações:

1. Verificar a saída de E/S do programa
2. Verificar o código de saída do programa
3. Adicionar manualmente gatilhos de falha nas partes "inalcançáveis" do código
4. Realizar verificação de taint para ver se o contador de programa (PC) pode ser modificado
5. Usar o angr (solucionador SMT) para resolver entradas que resultem em valores de PC especificados pelo usuário

Glitching

Para injetar falhas, escolhemos fazer crowbar glitching. Isso foi alcançado usando uma FPGA com um MOSFET de canal N SI 2302. Aqui está um link para nossas ferramentas de FPGA. Mais informações podem ser encontradas em targets.

Gatilhos

Para os gatilhos, escolhemos usar uma entrada GPIO em uma FPGA. No código de teste, alternamos um LED, embora você possa realizar análise de potência para os seus gatilhos.

Uso

Dependências

As dependências estão listadas no requirements.txt. Instale-as com pip install -r requirements.txt.

usage: main.py [-h] [-s INDEX] [-i MAX_ITERATIONS] [-o EXPECTED_OUTPUT] [-e EXPECTED_EXIT] [-d DESIRED_PC] [-v] [-n] [-t TYPES] [-b BINARY_ADDR]
               [-u OUTPUT_DIR] [-f BEGIN_ADDR] [-g END_ADDR]
               binary_path input_path

Automatically finds hardware security vulnerabilities in binaries. Only support ARM.

positional arguments:
  binary_path           The binary to examine
  input_path            The path to the input to the program

options:
  -h, --help            show this help message and exit
  -s, --simulate INDEX  Runs a Unicorn simulation with the fault at an nth instruction issue. Ignores all other flags besides --max_iterations and
                        --verbose.
  -i, --max-iterations MAX_ITERATIONS
                        The maximum number of instructions to run in the binary before ending early
  -o, --expected-output EXPECTED_OUTPUT
                        The expected output of the program on a successful security incident
  -e, --expected-exit EXPECTED_EXIT
                        The expected exit of the program on a successful security incident
  -d, --desired-pc DESIRED_PC
                        The program counter we desire to achieve if possible. In hex or decimal. Keep in mind that this is the absolute address,
                        not relative to the binary.
  -v, --verbose         Verbosity: warning, info, debug
  -n, --no-thumb        Whether or not to run in thumb mode
  -t, --types TYPES     Which types of instructions to focus on. 0) Brute force: every issue. 1) Recommended defaults. 2) Only conditional
                        branches. 3) Only compare/tests. 4) Only returns. 5) Only branches, calls, returns, and compares
  -b, --binary-addr BINARY_ADDR
                        The address to flash the binary to. Defaults to 0x1000000. Can be in hex or decimal.
  -u, --output-dir OUTPUT_DIR
                        The directory to store faults that were found.
  -f, --begin-addr BEGIN_ADDR
                        The starting address of the instructions that should be considered for skipping. (inclusive.) If set, -g must also be set.
  -g, --end-addr END_ADDR
                        The ending address of the instructions that should be considered for skipping. (inclusive.) If set, -f must also be set.

Exemplo de Uso

Verificação de Saída

python3 main.py ./binaries/sha256.bin ./inputs/sha256.bin -o ./expecteds/sha256.bin -v

Verifica a saída para ver se atingimos nossos objetivos de ataque.

Controle do Contador de Programa

python3 main.py ./binaries/aes_ecb.bin ./inputs/aes_ecb.bin -d 0x100045c -v -u outputs/aes_ecb

Testa o binário aes_ecb para saltar para uma função "inalcançável" personalizada e armazenar as entradas em um diretório.

Testando um Glitch em Simulação

python3 main.py ./binaries/aes_ecb.bin ./outputs/aes_ecb/solved_pc_188.bin -s 188

Execute a simulação com Unicorn para este ciclo de glitch e entrada específicos. Neste caso, a saída do controle do contador de programa.

Limitações

1. Por enquanto, este programa só suporta o conjunto de instruções ARM. Ele suporta os modos thumb e não-thumb.
2. Alguns binários realizam operações muito complexas na entrada (como hash), o que torna o solucionador SMT mais lento.

Notas

Executando Binários

O código incluído em binaries/sources serve apenas para testes. Ele não tem como alvo nenhum hardware real e é estritamente para testar a ferramenta.

Para executar um binário específico voltado a um dispositivo, você precisa extrair a parte relevante do binário de uma forma que não faça chamadas a periféricos fora de E/S simples. Por exemplo, se o seu binário usa UART, você pode corrigir o binário substituindo chamadas à UART por chamadas aos stubs _read e _write encontrados em binaries/stubs. Além disso, GPIO pode ser substituído por chamadas a _trigger, se desejado. Para executar seu código por meio da ferramenta, você criará um símbolo main que contém seu binário corrigido e, em seguida, o vinculará ao código binaries/startup.s. Dessa forma, a ferramenta poderá iniciar e executar seu binário.

Para um exemplo específico, veja o diretório targets, onde mostramos esse processo no TIMSPM0L2228.

Compilando a partir do Código-Fonte

Você deve ter o compilador da mesma versão e as mesmas flags/etapas de compilação para criar um binário que reflita o binário em execução no alvo. Se você está criando seus próprios programas e testando-os, isso não é problema. Mas se você tiver apenas o código-fonte do alvo que está atacando, provavelmente não conseguirá compilar até o binário exato que está em execução. Portanto, é recomendável usar o binário exato em execução no seu alvo sempre que possível.