From 38aa15ffad7317dfa50abe104c94177db93cf601 Mon Sep 17 00:00:00 2001 From: Giulio Date: Sun, 19 Jul 2020 11:59:13 +0200 Subject: [PATCH] Documentation update --- Readme.md | 28 ++++++++++++++++++++++++++++ keygen/Readme.md | 5 +++++ 2 files changed, 33 insertions(+) diff --git a/Readme.md b/Readme.md index 7ca2d97..a468e92 100644 --- a/Readme.md +++ b/Readme.md @@ -9,6 +9,34 @@ La challenge e' pensata in tre step, necessariamente consecutivi, che implicano ## Documentazione La documentazione, che include un preventivo della spesa, una presentazione e un documento tecnico e' [disponibile qui](document). +## 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 diff --git a/keygen/Readme.md b/keygen/Readme.md index 46caa3d..6bfe74e 100644 --- a/keygen/Readme.md +++ b/keygen/Readme.md @@ -2,6 +2,11 @@ Il codice responsabile per la generazione della chiave WPA di ogni dispostivo. Scrive il seriale in `/etc/serial`, il nome della rete in `/etc/ssid` e ila chiave WPA in `/etc/wpa`. E' poi uno script bash a inserirli nella conf di Hostapd. +Per ottenere una chiave i partecipanti hanno due opzioni: + + 1. Effettuare il reverse engineering dell'algoritmo e reimplementarlo di nuovo. Non essendo il codice ne' offuscato ne' particolarmente lungo, premesso che riconoscano la funzione di md5 dovrebbe essere fattibile in un tempo ragionevole. + 2. Nel caso che il binario sia per un target `x86` occorre danneggiarlo (ad esempio rimuoverne gli header) in modo che non sia direttamente eseguibile. Allo stesso tempo per altre architetture, occorre introdurre qualche limitazione per cui non sia semplicemente eseguibile con `qemu-static` (ad esempio verificare gli hash di alcuni file nel filesystem, o aggiungere dipendenze a cui l'attaccante non ha accesso). + ### Pseudocode ```