Il vincitore del Cyber Grand Challenge di DARPA ha scoperto vulnerabilità precedentemente sconosciute?

Question

Il vincitore del Cyber Grand Challenge di DARPA ha scoperto vulnerabilità precedentemente sconosciute?

#1 da (8 voti)

11

DARPA ha annunciato un vincitore il 4 agosto 2016 della sua Cyber Grand Challenge DARPA Cyber Grand Challenge . Il concorso è stato descritto come

designed to accelerate the development of advanced, autonomous systems that can detect, evaluate, and patch software vulnerabilities before adversaries have a chance to exploit them. The seven competing teams in today’s final event were composed of whitehat hackers, academics, and private sector cyber systems experts.

Hanno descritto la sfida attuale come:

For almost 10 hours, competitors played the classic cybersecurity exercise of Capture the Flag in a specially created computer testbed laden with an array of bugs hidden inside custom, never-before-analyzed software. The machines were challenged to find and patch within seconds—not the usual months—flawed code that was vulnerable to being hacked, and find their opponents’ weaknesses before the defending systems did.

Il sistema vincente, Mayhem, doveva essere formalmente invitato a partecipare al concorso DEF CON Capture the Flag, "che segna la prima volta in cui una macchina potrà giocare in quel torneo storicamente tutto umano."

Ho letto e riletto il materiale su DARPA e ancora non riesco a credere che un sistema automatizzato abbia trovato qualcosa a livello di aprile 2014 Heartbleed . Mi chiedo se le vulnerabilità siano più sul livello delle notifiche di sicurezza o degli aggiornamenti raccomandati di Microsoft o simili (in altre parole, il "bug finder" più di un programma di installazione automatico di patch in pratica).

Qualcuno sa qual è il livello tecnico del banco di prova della sfida DARPA in relazione a Heartbleed o vulnerabilità reali simili? Credo che scoprirò quando Mayhem competerà effettivamente contro gli umani nella competizione CTF, ma al momento sono dubbioso.

ctf automated-testing vulnerability-scanners

posta Dalton Bentley 07.08.2016 - 20:56

fonte

1 risposta

Leggi altre domande sui tag ctf automated-testing vulnerability-scanners

Come contrastare l'attacco sslstrip? Confronto tra Firefox password manager e chrome password manager

score 8 · Answer 1

Il banco di prova DARPA, CGC (Cyber Grand Challenge), era una piattaforma Linux modificata (DECREE). I suoi binari (il codice elaborato per il sistema) contenevano solo 7 chiamate di sistema (ad esempio, terminare, ricevere, fdwait, allocare, ecc.). All'interno del codice di sistema nel suo complesso, i DARPA sono stati creati con Challenge Binaries (CB) con una o più vulnerabilità alla fuzzing, cioè vulnerabili all'input di alcuni caratteri.

Uno dei primi esempi di test fuzz è stato "Monkey" di Steve Capps per verificare i bug in MacPaint alimentando eventi casuali nel codice. "Monkey" allude a "un migliaio di scimmie su un migliaio di macchine da scrivere finirà per scrivere l'intero lavoro di Shakespeare", cioè, se invii un input casuale o protocollo a un programma, alla fine troverai un modo per bloccarlo. Generalmente, i test fuzz non trovano minacce alla sicurezza che non causano arresti anomali del programma, ad es. Spyware, molti virus, worm, trojan e keylogger. Tuttavia, troverà exploit basati su input di programma inattesi (o errori di codice relativi all'input del programma), quindi potrebbe essere stato in grado di trovare il bug Heartbleed, che era un bug causato da una errata validazione dell'input nell'implementazione del TLS (Transport Layer Sicurezza) (in OpenSSL).

La squadra vincente, Mayhem, ha usato un esecutore simbolico (Mayhem) in congiunzione con un fuzzer diretto (Murphy). Un esecutore simbolico è familiare a coloro che hanno lavorato con debugger simbolici in ambienti di sviluppo integrati, cioè, fondamentalmente è un interprete che passa attraverso il codice e consente l'assegnazione e il tracciamento di valori simbolici per gli input in varie parti del codice in esecuzione. In altre parole, il team di Mayhem è stato in grado di analizzare staticamente le porzioni dei CB (Challenge Binaries) con Mayhem per rilevare (o analizzare i suggerimenti di Murphy) le vulnerabilità del codice. Questo era un requisito della sfida DARPA, cioè trovare una vulnerabilità e dimostrarla, ad esempio POV (Proof of Vulnerability). Sfortunatamente, l'esecuzione simbolica non si adatta molto bene poiché il numero di percorsi in un programma cresce in modo esponenziale e può andare all'infinito con iterazioni di loop illimitate, così l'euristica o il path-finding (entra in Murphy fuzzer) per risolvere parzialmente questo problema di esplosione del percorso (metodi di calcolo come aiuto per il parallelismo).

Il DARPA CGC (la sfida) richiedeva ai team non solo di individuare le vulnerabilità negli CB (binari di sfida), ma di documentare quelli con un POV (prova di vulnerabilità) e riparare la vulnerabilità con una patch di riparazione binaria (RB) . Tale patch sarebbe stata testata per le prestazioni, sia per il corretto funzionamento senza la vulnerabilità, sia per l'impatto letterale sulle prestazioni del codice rilevante (tempo di esecuzione). Tutto ciò è abbastanza sorprendente considerando che a un essere umano non è stato permesso di contribuire a nulla di ciò che ho appena descritto.

Puoi leggere di più sul blog del team Mayhem vincente qui Scatenare il caos! , ottieni le regole della Grande sfida del DARPA e altri documenti qui documenti relativi a Darpa Grand Challenge , leggi sul tema della fuzzing Fuzz Test e l'esecuzione simbolica qui Esecuzione simbolica .