Fault Injection Finder

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

Geeoon Chung e Nate Snyder

Questo repository è il lato software del nostro progetto di attacco tramite iniezione di guasti. Per il lato hardware, dai un'occhiata a questo repo.

Progetto Generale

L'obiettivo di questo progetto è trovare istruzioni nell'esecuzione di un programma che, quando saltate/NOPate, causano problemi di sicurezza.

1. Pre-elaborazione
   1. Caricare il binario
   2. Identificare le istruzioni che hanno maggiori probabilità di causare problemi di sicurezza quando vengono NOPate.
2. Emulazione Unicorn
   1. Eseguire il programma, NOPando l'n-esima istruzione emessa.
   2. Controllare l'output del programma per vedere se si è verificato un guasto di sicurezza.
      1. Se si è verificato un fetch non valido, invertire tutti i bit dell'input del programma.
      2. Eseguire di nuovo il programma.
      3. Se si è verificato un fetch non valido a un indirizzo diverso, prenderne nota. Ciò significa che l'input del programma è in grado di influenzare il program counter (cioè il controllo del PC).
3. Risoluzione SMT con Angr
   1. Se l'emulazione Unicorn ha indicato il controllo del PC, eseguire il programma con input simbolici e saltare l'emissione dell'istruzione dal passo Unicorn.
   2. Verificare se alla fine otteniamo una variabile simbolica nel registro PC.
   3. Risolvere per un valore PC personalizzato per vedere quale input serve per portare il PC a un indirizzo specifico.
   4. Se è risolvibile, annotare l'input che ha portato al PC specificato.
4. Esportare le istruzioni interessanti
5. Testare le istruzioni sul target usando lo script targets/tooling.py e un FPGA.

Flow chart for the software

A presentation we gave for this project

Dettagli

Cerchiamo problemi di sicurezza eseguendo una o più delle seguenti operazioni:

1. Controllare l'output IO del programma
2. Controllare il codice di uscita del programma
3. Aggiungere manualmente trigger di guasto nelle parti "irraggiungibili" del codice
4. Eseguire un taint checking per vedere se il program counter (PC) può essere modificato
5. Usare angr (risolutore SMT) per risolvere input che portano a valori PC specificati dall'utente

Glitching

Per iniettare guasti, abbiamo scelto di fare crowbar glitching. Questo è stato realizzato usando un FPGA con un MOSFET a canale N SI 2302. Ecco un link ai nostri strumenti FPGA. Maggiori informazioni si trovano in targets.

Trigger

Per i trigger, abbiamo scelto di usare un input GPIO su un FPGA. Nel codice di test, attiviamo un LED, anche se si potrebbe eseguire un'analisi di potenza per i propri trigger.

Utilizzo

Dipendenze

Le dipendenze sono elencate in requirements.txt. Installarle con 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.

Esempio di Utilizzo

Controllo Output

python3 main.py ./binaries/sha256.bin ./inputs/sha256.bin -o ./expecteds/sha256.bin -v Controlla l'output per vedere se abbiamo raggiunto i nostri obiettivi di attacco.

Controllo del Program Counter

python3 main.py ./binaries/aes_ecb.bin ./inputs/aes_ecb.bin -d 0x100045c -v -u outputs/aes_ecb Testa il binario aes_ecb per saltare a una funzione "irraggiungibile" personalizzata e memorizzare gli input in una directory.

Testare un Glitch in Simulazione

python3 main.py ./binaries/aes_ecb.bin ./outputs/aes_ecb/solved_pc_188.bin -s 188 Esegue la simulazione Unicorn per questo specifico ciclo di glitch e input. In questo caso, l'output dal controllo del program counter.

Limitazioni

1. Per ora, questo programma supporta solo il set di istruzioni ARM. Supporta sia la modalità thumb che non-thumb.
2. Alcuni binari eseguono operazioni molto complesse sull'input (come l'hashing), che rallentano il risolutore SMT.

Note

Esecuzione dei Binari

Il codice incluso in binaries/sources è semplicemente a scopo di test. Non è mirato a hardware reale ed è strettamente per testare lo strumento.

Per eseguire un binario specifico mirato a un dispositivo, è necessario estrarre la parte rilevante del binario in modo che non effettui chiamate a periferiche al di fuori di semplici IO. Ad esempio, se il tuo binario utilizza UART, puoi patchare il binario sostituendo le chiamate a UART con chiamate agli stub _read e _write presenti in binaries/stubs. Inoltre, GPIO può essere sostituito con chiamate a _trigger se desiderato. Per eseguire il tuo codice tramite lo strumento, creerai un simbolo main che contiene il tuo binario patchato, poi lo linkerai con il codice binaries/startup.s. In questo modo, lo strumento sarà in grado di avviarsi ed eseguire il tuo binario.

Per un esempio specifico, dai un'occhiata alla directory targets dove mostriamo questo processo sul TIMSPM0L2228.

Compilazione dal Sorgente

Devi avere lo stesso compilatore di versione e gli stessi flag/passi di compilazione per creare un binario che rifletta il binario in esecuzione sul target. Se stai creando i tuoi programmi e li testi, va bene. Ma se hai solo il codice sorgente del target che stai attaccando, è improbabile che tu possa compilare fino al binario esatto in esecuzione. Quindi si consiglia di utilizzare il binario esatto in esecuzione sul tuo target quando possibile.