“If it is good, they stop making it”, il payoff stampato sui laccetti della conferenza, distribuiti a ogni partecipante, insieme a un badge über-l33t personalizzato con il nostro nickname e l'hash della chiave.

Essendo la mia prima esperienza a una conferenza di sicurezza internazionale (sono stato solo al camp ccc2k+7), ed essendo un outsider di ph dato che non avevo mai partecipato alle edizioni precedenti, il keynote di apertura tenuto da FX, staffer e frontman, è stato illuminante: “you ought to be here!”, ha urlato indicando il palco, indossando una camicia bianca col logo Phenoelit stampato su entrambe le maniche.

“Questa conferenza non è mai iniziata in orario”, ha continuato, “quindi non c'era motivo di farlo per quest'ultima”. Il programma è lineare: festa, il giorno dopo talk dalle 12:00 alle 19:30, poi festa, e l'ultimo giorno talk dalle 12:00 alle 17:30. Decisamente un setup che si sposa bene con l'alcol disponibile :-D.

Subito dopo, un altro speaker ci ha informato che le chiavi di accesso wifi ricevute alla registrazione ci permettono di usare una bestia con 6 AP/3 repeater pilotata da un box OpenBSD — vogliono che il pubblico la hacki perché, beh, “you are the Worst Case Scenario.” :-)

Poi è stato presentato il divertente video Hacker Hacker:

:-D

Dopo una prima serata fiacca e non troppo entusiasmante (per la stanchezza), vedremo cosa porta il giorno dopo.

Sniffjoke – un toolkit per eludere gli sniffer

Gli sniffer ad alta capacità usati nelle grandi aziende e sui gateway di frontiera nazionali che raccolgono traffico generato dagli utenti per trovare pattern potenzialmente “criminali” sono oggi generalmente disponibili per larghezze di banda fino a 10Gbps, e presto ci saranno appliance che elaboreranno flussi da 100Gbps. Sniffjoke, di vecna e evilaliv3, è uno strumento che può iniettare nelle connessioni TCP pacchetti estranei che ingannano lo sniffer intercettante ma senza effetti significativi sul destinatario. Questi pacchetti, per esempio, fanno credere allo sniffer che la connessione sia stata resettata anche se non è vero — iniettando un RST con checksum errato o un pacchetto con TTL inferiore di 1 rispetto al conteggio degli hop — oppure cercano di consumare la sua potenza di calcolo usando interpretazioni vendor-specific note del TCP RFC. Dettagli: sito web, slide, thread su Wireshark.

Storie horror dei router WLAN

Vi siete mai chiesti cosa succede quando la password della rete wireless è direttamente legata al MAC address del dispositivo, da cui può essere dedotta perché fa parte dell'ESSID? Storie dell'orrore, come ci hanno mostrato un ricercatore austriaco (ViBi) e uno tedesco (5M7X). Molti operatori che vendono apparecchiature wifi le spediscono con vulnerabilità simili, come ci mostrano anche mayhem e cyrax in questo video (solo in italiano).

Stiamo parlando di una tecnologia il cui potenziale non è massimizzato, e che di conseguenza porta a misure di sicurezza difettose, a causa di cattiva ingegneria e istruzioni fuorvianti: alcuni manuali di apparecchiature wifi raccomandano addirittura all'utente di non toccare mai la configurazione e lasciare le password di default. Geniale. Altri esempi di cattiva ingegneria includono l'usare gli ultimi 4 byte del MAC address ethernet interno come chiave di rete e poi trasmettere quel MAC tramite un pacchetto multicast inviato a 224.0.1.0 (Samsung G3200 / G2210 / G3220).

Altre aziende, come la Synchron che produce l'easybox, hanno un metodo brevettato per fornire un sistema di riconoscimento della chiave, con corrispondenza diretta tra il MAC e il seed della chiave. E alla fine, ci sono persino aziende che vendono i loro dispositivi con il SSHD di gestione aperto sull'interfaccia esterna, e che basano la chiave di rete interamente sul MAC interno. Aggiungici le password di default e hai il quadro completo.

Se vuoi saperne di più, dovresti procurarti un po' di armamentario e o fare reverse engineering degli algoritmi da solo, oppure partecipare a conferenze di sicurezza e chiedere le slide ai ricercatori :-). Quando l'industria sarà pronta, tutti i dettagli verranno rivelati.

Hacking TETRA

Tenuto da Harald Welte (@laf0rge), membro del crew gnumonks.de, il talk ha descritto una tecnologia di radiocomunicazione terrestre simile al GSM ma che opera su frequenze più basse dello spettro, ottenendo così una copertura più ampia con meno ripetitori. TETRA impiega metodi per autenticare e crittografare le comunicazioni, ha un canale di segnalazione su cui vengono scambiati messaggi di 140 caratteri e identifica ogni utente sulla rete usando la corrispondenza tra il numero dell'abbonato e quello del terminale.

TETRA è ampiamente diffuso nel mondo come mezzo di comunicazione per trasporto pubblico, sicurezza pubblica, vigili del fuoco, ecc. È una tecnologia adatta a questi usi, ma laforge ci ha giustamente ricordato che anche se gli strumenti ci permettono di implementare reti sicure, spesso l'implementazione di tali strumenti è inefficace e soggetta a rottura.

Ci ha mostrato come funziona la segnalazione sulla rete. Ha iniziato mostrandoci dump di pacchetti in Wireshark, grazie a hacker cinesi che hanno scritto i dissector. È anche riuscito ad associarsi a una rete TETRA usata dalla BVG, il sistema di trasporto pubblico tedesco, e ad ascoltare una chiamata tra la centrale e tutti i macchinisti: la centrale chiedeva ai macchinisti di premere un pulsante contemporaneamente. Sì, signore: nel 21° secolo serve ancora gente per farlo. Fantastico. Se vuoi costruire il tuo, dovresti prima imparare come funzionano le radiocomunicazioni, comprarti un dongle FUNcube e dare un'occhiata al progetto OsmocomTETRA. Un'introduzione è disponibile su heise.de.

Printer Hacking

Trova una vulnerabilità in un'interfaccia di gestione stampante, scrivi un'applet Java che la sfrutta, definisci degli hook per pilotarla da Javascript, e il tuo scanner di vulnerabilità stampanti via web è fatto!

Mi sono perso la prima parte del talk, quindi non ho i dettagli, ma come mi ha detto lo speaker dopo quando gli ho chiesto come il tutto si incastrasse, “è tutto scritto!” quindi basta RTFM qui :)

Chip & PIN è definitivamente rotto

Proseguendo nella lista delle tecnologie mal implementate, al giorno d'oggi le carte di credito/debito sono vulnerabili a un classico attacco di downgrade quando si tratta di validare il PIN. Ci sono diversi tipi di chip, alcuni che permettono solo l'autenticazione in chiaro tra il POS e il chip, altri che impiegano un meccanismo di challenge-response, e quasi tutti permettono la validazione del PIN online con la banca.

In ogni caso, la SIM espone un'interfaccia ai lettori di carte, che può essere interrogata e la cui comunicazione può essere intercettata da un dispositivo interposto. Dato che le carte devono essere retrocompatibili con i POS esistenti e viceversa, un tale dispositivo è in grado di alterare le capacità pubblicizzate dalla carta e forzare il POS a usare l'autenticazione in chiaro, per poi intercettare il PIN mentre l'utente lo digita.

Uno skimmer del genere è un dispositivo 4×4cm, che può essere installato dentro un POS o un ATM, passando quindi potenzialmente inosservato per un lungo periodo. E anche se ci sono assicurazioni che ti coprono contro queste frodi, se sei un viaggiatore frequente, puoi avere vita dura a dimostrare di essere stato vittima, sia perché numero di carta e PIN corrispondono, sia perché questa è ormai considerata una tecnologia “sicura” che non può essere violata.

Grazie ad Andrea Barisani e Davide Bianco per averci informato sulla falla di downgrade. Se vuoi saperne di più, ecco le loro slide pubblicate sul sito della loro azienda, inversepath.com.

Exploitation del kernel FreeBSD

Col passare degli anni, lo stack smashing è ancora vivo e potente, come argp ha spiegato durante il suo talk. CVE-2008-3531 è una vulnerabilità nota del kernel FreeBSD che permette l'esecuzione di codice nello spazio kernel, mentre l'UMA — l'allocatore di memoria di FreeBSD — ha falle note anch'esso.

Senza entrare in dettagli più profondi, il problema principale qui è l'approccio “se funziona non toccarlo” adottato da molti amministratori di sistema quando si tratta di macchine in produzione: di conseguenza, non vengono aggiornate per anni. Forse oggi non è rotto (ammesso che lo sia mai, eh, 0dayz?) ma lo sarà domani, e te la prenderai in quel posto se non ti tieni aggiornato. PAROLA.

Progressi nell'evasione di ASLR su Win32

Quando penso ai prodotti Microsoft, ho sempre la sensazione che non siano costruiti per essere usati dalle persone, perché mi sembra che i programmatori che li scrivono non si preoccupino mai di usarli in prima persona. Non mangiano il proprio cibo per cani. Provate ad usare i developer tools di IE e capirete.

Il loro software è scritto per il business, deve soddisfare qualche requisito di ordine superiore concordato da qualche manager a caso 7 livelli più su nella gerarchia, e molto spesso fallisce nell'implementarli correttamente. Così, come JF ha fatto notare durante il talk “Microsoft ha speso un sacco di soldi per risolvere il problema dell'exploitation, ma ha solo creato più problemi”. Word, dword e qword! :-)

L'ASLR è un fattore di mitigazione per gli exploit che assumono che l'indirizzo di ritorno del codice vulnerabile si trovi a un indirizzo noto in memoria. Queste locazioni vengono usate per calcolare dove scrivere lo shellcode per innescare la sua esecuzione dopo l'exploitation. Se l'indirizzo di ritorno viene randomizzato (da qui Address Space Layout Randomization), allora l'exploit farà semplicemente crashare il software vulnerabile facendogli riferire un indirizzo fuori dal suo spazio.

Il problema è che, per qualche oscuro effetto collaterale, per ogni 16 thread creati, se il loro indirizzo base è pari (0x02xxxxxx, 0x04xxxxxx), 13 di essi finiranno per essere basati a una locazione nota, rendendo così l'ASLR inefficace e bypassato. PWN!

Guardate le slide di JF qui – grazie per la condivisione @not_me!

JF si è scusato almeno 4 volte prima di finire per chiudere il portatile e concludere la presentazione con vodka e gin, perché diceva di non aver fatto un buon lavoro nello spiegare ma, come gli ho detto anche dopo, è stato più che efficace: non è per niente facile capire come tutti gli effetti collaterali giocano insieme. Solo lui che era su questa roba da mesi era in grado di vedere i pattern negli indirizzi e portare a termine una exploitation di successo di un processo protetto da ASLR. Illuminante!

Exploitation moderna dell'heap usando il low-fragmentation heap

Non sono un tipo da memory management e non ho capito la maggior parte dei concetti del talk, ma il suo abstract è molto esplicativo:

La gestione della memoria heap è maturata nel tempo, ma con nuovo codice complesso arrivano nuove opportunità di exploitation. Questa presentazione si concentrerà sulla comprensione del Low Fragmentation heap su Windows 7 (32-bit). Dopo aver posto le basi dei concetti integrali, nuove tecniche di exploitation verranno discusse approfonditamente. Infine, useremo questa nuova conoscenza per sfruttare vulnerabilità presuntamente non-exploitabili. In particolare copriremo un caso di studio che mostra come creare un exploit per il denial of service di IIS FTP 7.5 (http://blogs.technet.com/b/srd/archive/2010/12/22/assessing-an-iis-ftp-7-5-= unauthenticated-denial-of-service-vulnerability.aspx-= unauthenticated-denial-of-service-vulnerability.aspx), risultante nel pieno controllo di EIP.

La cosa interessante è che per usare un sottosistema di ottimizzazione dell'allocazione di memoria per fare quello che vuoi, devi mescolare e combinare 7 diverse primitive di attacco, capire a fondo come vengono fatte le allocazioni di blocchi e come interagiscono con la CPU host. Oltre a combattere con tutti gli effetti collaterali per scrivere nel program counter l'indirizzo che vuoi eseguire. "@You say JMP, we say what addr@", come diceva correttamente una maglietta davanti a me. :-)

Per quanto incredibilmente complicato possa sembrare, Chris Valasek è riuscito a trovare, exploitare e spiegare le vulnerabilità, con un esercizio mentale che è tanto brillante quanto ispirazionale: scava sempre più a fondo, e sarai in grado di raggiungere qualsiasi obiettivo.

Qui le slide di Chris, ma purtroppo dovrete abilitare Flash.

Exploiting the Hard-Working DWARF: Trojan senza codice eseguibile nativo

Avreste mai immaginato che in ogni binario compilato con GCC possa annidarsi un sottosistema completo di macchina virtuale, che viene invocato ad ogni call/ret e ha la capacità di leggere e scrivere l'heap e ogni registro della CPU? Ebbene sì, e si chiama DWARF, una strumentazione di debug usata da GDB per aiutare lo sviluppatore a fare debug del proprio software.

"È una storia di DWARF e ELF..." LOL! :-D.

La cosa interessante è anche che il codice DWARF non viene considerato dagli strumenti di analisi come parte del codice oggetto di un binario, rendendolo così un vettore di iniezione per attaccare trojan a un binario. Inoltre, DWARF è indipendente dalla piattaforma e dall'architettura, essendo una macchina a stati finiti a sé stante: un trojan basato su DWARF può essere usato su piattaforme multiple e attaccato a qualsiasi binario ELF.

Se il codice DWARF è presente, viene eseguito per ogni funzione chiamata e ad ogni return, mentre lo stack viene srotolato, e sì puoi leggere e scrivere la CPU e l'heap. Bello. Per tutti i dettagli, date un'occhiata al whitepaper.

Qui vediamo un esempio di hobbyismo e cattiva gestione del progetto lato GCC — senza offesa ovviamente — ma un sottosistema così elaborato e complesso finisce per essere disponibile nella stragrande maggioranza dei sistemi operativi, diventando potenzialmente un vettore di infezione.

Deduco questo perché DWARF è un pezzo di codice oscuro, non documentato, frutto di cargo cult, scritto perché in qualche modo oggi e domani gli sviluppatori di GDB avevano bisogno di strumentazioni, e gli sviluppatori di GCC hanno costruito uno strumento eccessivamente potente per supportarli, ma detto strumento può poi essere abusato e nessuno sa veramente come funzionano le prime release — a meno che non si spulcino post a caso sulla mailing list di GCC. Le release più recenti sono abbastanza documentate, comunque.

La cosa divertente è che credo che per supportare GDB, anche l'infrastruttura del compilatore LLVM, costruita con un design pulito da zero, usa DWARF! Detto ciò, la morale della storia è che gli hack sporchi di oggi ti chiameranno per guai domani — o il giorno dopo.

Festa! (Musica qui)

- “ehi amico, sei tu il tizio dietro il box OpenBSD che fa da host AP per la rete wifi del ph?”
- “sì, sono io”
- “posso chiederti una shell di root?”
- “vuoi... COSA?”
- “sì, sai, vorrei dare un ifconfig, brconfig, pfctl -s, ls -lrt /etc | tail, roba così – solo per vedere come funziona il tutto :)”

Kudos al panda OpenBSD, che non mi ha dato la shell, ma mi ha illustrato come funziona il "cluster" di access point dorepanda, creando una rete che copre tutti gli spettri 802.11b/g e n. Bilancia i client tra gli AP, usa la crittografia per verificare l'identità dell'AP e cerca di prevenire l'eavesdropping.

- “amico, sei davvero una barba grigia a una conferenza di sicurezza!”
- ”... e quindi?!”

... e poi parli con un DBA con 20 anni di esperienza che ti dice “Oracle è difettoso by design” e chiacchieri con lui di come lo scenario della sicurezza è cambiato nel corso degli anni.

- “non è cambiato veramente niente, è solo diventato più complicato lungo la strada”
- “vuoi dire che il punto è sempre che devi piazzare del shellcode in memoria e poi trovare un modo per eseguirlo?”
- “esattamente — puoi avere un NX bit, ASLR e canary, ma c'è sempre un modo per aggirarli.”

Un buon amico sysadmin mi ha detto qualcosa di simile, nei termini di “finché leggo abbastanza documentazione, sono in grado di configurare e deployare qualsiasi sistema. Niente più sfide.”

Per me, conferenze come questa ti fanno riflettere, pensare e attivare circuiti mentali che stimolano la tua passione: vedi esseri umani brillanti che risolvono problemi intricati, che si addentrano nei dettagli e che imparano cose nuove nel processo. Esseri umani il cui modello del mondo include sequenze di interazioni che avvengono dentro la macchina. Come un netadmin esperto riconosce i numeri AS dai netblock, un kernel hacker impara a riconoscere porzioni dello spazio di indirizzamento: letteralmente respira dentro il sistema operativo.

Mi stupisce come ho trovato forti corrispondenze con la teoria dell'intelligenza di Jeff Hawkins (video TED) nelle menti degli hacker. Ho parlato degli HTM paper con le persone che ho incontrato, e sono rimasto sorpreso che nessuno di loro conoscesse una tecnologia volta a costruire macchine intelligenti reimplementando l'algoritmo corticale del cervello umano in silicio. Per esempio, i talk di Chris Valasek e JF dimostrano le basi dell'expertise: più input ricevi da un contesto, più il tuo cervello sarà in grado di vedere pattern più profondi e complicati, perché vengono spostati più in basso nella gerarchia corticale, il cui compito è riconoscere i dettagli — come loro hanno fatto con l'ASLR e il low-fragmentation heap.

- “signore, lei è l'unico che indossa una cravatta in questa sala”
- ”...”
- “quindi deve sicuramente lavorare per Microsoft!”
- “ehm, no...”
- “ah, ok allora la mia ipotesi era sbagliata. scusi il disturbo! :D”

Alle 5:15, è meglio andare a letto, in attesa del prossimo buongiorno!

Giorno 3 – 98% di rilevamento virus Zero-Day

Dopo una festa del genere, sia il talk sull'ingegneria sociale che quello su Exploit Next Generation++ erano un po' nebulosi, non sono nemmeno riuscito a riconoscere il linguaggio del codice sorgente di Metasploit (ehm). :-)

Poi shirtie (@skjortan) è salito sul palco e ha illustrato come si può usare un classificatore bayesiano / MAXENT per identificare malware sconosciuto, 0-day.

Esattamente come un filtro anti-spam cattura lo spam analizzando prima un training set, identificando i pattern ricorrenti e poi confrontandoli con dati nuovi, anche il malware come lo spam ha caratteristiche tipiche che possono essere usate per trovarlo. Per esempio, la presenza di un riferimento all'API CreateProcess o l'assenza di quella <a href="http://en.wikipedia.org/wiki/Pentium_FDIV_bug">_check_fdiv</a>, oppure se il binario è compresso con UPX o meno.

La tecnologia sembra efficace, non è un sostituto di un AV basato su firme bensì un'integrazione, perché è soggetta a falsi positivi, ma è l'unica che identifica malware sconosciuto, 0-day — quello per cui non esistono firme.

XSLT offensivo

XSLT è un linguaggio usato per trasformare documenti XML in un'altra forma, ed è un linguaggio Turing-completo eseguito nel contesto del server o del client. Viene usato sia dai sistemi di content management che nelle applicazioni client-side, l'esempio più prominente essendo l'indice di un repository Subversion.

Poiché XSLT è un linguaggio di programmazione (funzionale), offre mezzi per leggere e scrivere file e per eseguire codice. Se l'input dell'utente non è sanitizzato e/o il motore XSLT è esposto, può essere usato per pwnare una macchina. Ovviamente, le funzionalità abusabili possono essere disabilitate se non servono, o in alternativa incapsulate con un'API sicura se servono. Date un'occhiata alle slide di Nicolas Gregoire qui. Utenti Liferay, siete avvisati :-)

Parole finali

Grazie @nhaima per avermi parlato della conferenza e avermi permesso di avere un accredito (grazie nobody :)

Grazie @techdoer per l'editing del post — si spera che questo sia il mio primo senza errori grammaticali :-D

Grazie @phenoelit e @41414141 per aver organizzato la festa (siete i migliori), e a tutti quelli che c'erano. Spero di vedervi presto sul palco :). Yay!

---