Embedded CTF Challenge

Abstract

La challenge e' pensata in tre step, necessariamente consecutivi, che implicano tre vulnerabilita' concettualmente semplici ma di difficolta' facilmente variabile a seconda delle limitazioni imposte. Tecnicamente sono:

1. Generazione di password prevedibile
2. Command Injection
3. Race Condition

Documentazione

La documentazione, che include un preventivo della spesa, una presentazione e un documento tecnico e' disponibile qui.

Struttura

Ad ogni squadra partecipante verra' consegnato un dispositivo gia' attivo, che sara' identificato da un numero seriale inizialmente noto solo agli organizzatori. Ogni dispositivo, sara' collegato all'alimentazione e via ethernet alla rete di monitoring, ed esporra' una rete WiFi di nome CyberChallenge-ABCD, dove ABCD sono la rappresentazione esadecimale degli ultimi due byte del seriale.

Verra' quindi comunicato ad ogni squadra il seriale del dispositivo ad essi assegnato, e verra' pubblicato per tutte le squadre il binario di generazione delle chiavi WPA, cioe' il keygen. Per le considerazioni sulla distruzione del keygen leggere la documentazione relativa.

A questo punto, ogni squadra avra' il necessario per poter trovare la chiave WPA solo del proprio dispositivo ed iniziare quindi la challenge. In uno scenario attacco-difesa, dopo la prima fase sara' possibile rilasciare i seriali di tutte le squadre e quindi permettere a tutti quelli che abbiano risolto il primo step di eventualmente collegarsi ai dispositivi altrui.

Gestione delle informazioni

Al momento lo script di build produce una immagino ISO uguale per tutti i dispositivi. E' il keygen che al primo boot genera un seriale di 16 byte csuale che viene scritto nel filesystem. Se il keygen rileva che e' gia' presente un seriale, non ne generera' un altro a tutte le operazioni successive (generazione del nome della rete e della chiave) saranno sempre uguali. Sara' compito del sistema di monitoring oppure di chi si occupa di preparare i dispositivi raccogliere i seriali e indicizzarli. Ovviamente e' un procedimento che conviene fare prima della gara per verificare che funzioni tutto correttamente.

Considreazioni di sicurezza

Benche' la challenge si possa proteggere in qualche modo, ad esempio bloccando l'ordine di boot in Coreboot e disabilitando il boot da periferiche esterne, rendendo quindi inutile anche l'eventuale utilizzo di un cavo seriale, si presuppone che i partecipanti non possano smontare il case e leggere direttamente il disco mSata. In quel caso qualsiasi protezione sarebbe inutile essendo l'immagine che viene scritta nei dispositivi non cifrata. Inoltre prevenire un attacco di questo tipo risulterebbe particolarmente oneroso in quanto:

• Se si sceglie di cifrare il disco risulta poi necessario decifrarlo, inserendo gli organizzatori una chiave all'inizio e ad ogni reboot (umanamente oneroso) oppure facendo si che il bootloader (ed esempio grub) abbia la chiave perimpostata e sblocchi autonomamente il disco (piu' difficile che senza cifratura, ma comunque inerentemente insicuro)
• L'unico modo per prevenire questo scenario sarebbe l'utilizzo del TPM, da comprare in aggiunta alle board, e poi l'implementazione parzialmente manuale delle misure di protezione necessarie

Considreazioni pratiche

A seconda del numero di partecipanti e delle dimensioni dell'arena di gioco, occorre verificare che tutte le squadre abbiano segnale sufficiente per effettuare una connessione a tutti i dispositivi in gioco, tenendo presente che piu' che un problema di distanza potrebbero verificarsi problemi di interferenze. Occorre quindi integrare un meccanismo che scelga automaticamente il canale su cui esporre la rete wifi in modo da ottimizzare il segnale per tutti.

Inoltre, nello scenario di una gara di tipo attacco-difesa occorre implementare un forte sistema di monitoring che verifichi che i dispositivi continuino a funzionare correttamente e che l'exploitation non venga bloccata semplicemendo spegnendo le funzioni del dispositivo. Allo stesso tempo, se si vuole che che ogni team sia in grado di patchare solo il proprio dispositivo e non quello altrui occorre occorre pensare a delle misure aggiuntive che qui non sono descritte. Complessivamente, prevenire qualsiasi tipo di comportamento scorretto in un contesto dove le vulnerabilita' permettono di arrivare al livello di root e' un problema molto complesso, al punto che nel caso attacco difesa si potrebbe valutare una rimodulazione dei privilegi dell'ultimo step.

Testing

E' consigliabile trovare almeno due beta tester per la challenge che sperimentino personalmente che le assunzioni fatte nello sviluppo siano vere e che valutino ls fattibilita' complessiva nei tempi stabiliti.

Build

Per Debian 10, installare

sudo apt install -t build-essential libncurses-dev bison flex libssl-dev libelf-dev

Per la cross compilazioen del keygen su ARM installare

sudo apt install crossbuild-essential-arm64 

Eseguire da utente normale

./build.sh

La iso risultante sara' in target/buildroot/output/images/rootfs.iso9660.

Firmware

Vedere il readme di buildroot.

Keygen

Per un esempio di backdoor reale di questo tipo vedere qui.

Vedere il readme del keygen.

Pannello web

Per un esempio di command injection reale con blacklist vedere qui.

Vedere il readme del pannello web.

Update

Vedere il readme dello script di update.