HackInBoat: giorno 2 e 3

Il secondo giorno ero convinto di poter dividere a metà il tempo tra il corso Offensive e quello Forensics, mi è sembrata una pessima idea da subito  ma era l'unica opzione che avevo per raccontare entrambe le attività. Ciò che è accaduto in realtà è che ho abbandonato l'idea quando ho confermato i miei dubbi: avrei seguito male entrambe e non sarebbe stato né utile né divertente.

Ho scelto di seguire, per la maggior parte del tempo, il corso Offensive perché sarebbe stato più semplice da raccontare per me, e avrei potuto dare un giudizio leggermente più "consapevole" rispetto a una tematica vasta e complicata come la Digital Forensics che ho seguito per poche ore.

Digital Forensics

Devo ammettere che la tematica mi è sembrata molto più interessante del previsto, o di ciò che (da completo ignorante del settore) avevo idealizzato nella mia testa. Mi è piaciuto moltissimo come Paolo @forensico Dal Checco e Davide @therebus Gabrini siano riusciti a creare un clima a dir poco interattivo con i partecipanti, quasi costante, che ha reso il tutto molto coinvolgente. Per il poco tempo che ho seguito, è stato bello vedere come il "laboratorio" fosse rappresentato da un portatile oggetto/prova di un’indagine che ha permesso di toccare argomenti come: isolamento logico per non "inquinare" le prove, come estrapolare informazioni sul sistema senza modificarle o comprometterle, sia dal punto di vista dei dati che dei metadati, i tool contenuti in Bento (suite di programmi utili agli scopi di live forensics e incident response).

Offensive Security

Igor koba Falcomatà e Gianfranco Ciotti hanno avuto l'arduo compito di introdurre tecniche di offensive security a partire dal layer 2 fino allo strato applicativo sia web che mobile. Non posso che definirlo arduo perché, come potrete intuire, è praticamente impossibile approfondire tematiche di questo tipo, partendo da MiTM e arrivando all'analisi del traffico prodotto dall'applicazione su mobile phone, in circa 2 giorni.

Il sottotitolo del corso è "Offensive Security 4 noobs" ma vi assicuro che, anche se i temi possono essere ben noti a chi è del mestiere, sentirli snocciolati da Igor e Gianfranco mi è stato molto utile: primo perché siamo tutti noobs (chi più, chi meno), e secondo perché sentire parlare di qualcosa che conosci (in italiano, che nel nostro settore non è così scontato) da chi la padroneggia da molti più anni di te è, a mio avviso,  non solo utile ma fondamentale.

Il laboratorio ha accompagnato tutte (o quasi) le tematiche affrontate, con tanto di applicazione web vulnerabile dal nome leggermente riconducibile a una nota compagnia: Koba Crociere

Si ma... la/il CTF?

Riepilogo degli obiettivi:
Obiettivo #1: causare un DoS significativo all'host.
Obiettivo #2: impedire #1 con sole modifiche alla configurazione dell'host.
Obiettivo #3: evadere dal container all'host.
Obiettivo #4: impedire #3 con sole modifiche alla configurazione dell'host.
Obiettivo #5: evadere dal container all'host nonostante #4.
Obiettivo #6: sviluppare le modifiche al kernel necessarie a impedire #5. :-)

Ovviamente i primi due obiettivi si sono rivelati facilmente raggiungibili (grazie a Massimiliano per aver avuto la giusta intuizione che, come insegna Occam, è sempre la più ovvia). Premetto che non ho avuto molto tempo per tentare di evadere dal container (ammesso che sia possibile), il che vuol dire che dal punto 3 al 6 non ci ho neanche provato :)

Lo script eseguimi.sh crea automaticamente il container eseguendo subito una shell bash al suo interno:

Per causare un DoS dal container su tutto l'host che lo esegue, è bastato un ciclo while che, all'infinito, facesse il fork di sleep 1000. Per evitare di bloccare completamente la macchina (essere in mezzo al mare senza un PC di backup rende theMiddle paranoico) ho "simulato" il DoS limitando il numero di processi in questo modo:

for i in {1..100}; do $(sleep 1000 > /dev/null &); done

ci sono diversi modi per limitare il numero di processi che il container può eseguire, tra i più semplici c'è quello di inserire il parametro LimitNPROC all'interno della configurazione dell'immagine del container, in questo caso /etc/systemd/nspawn/ctf.nspawn. Per praticità, ho modificato direttamente lo script eseguimi.sh che genera il file di configurazione:

Eseguendo nuovamente il ciclo for, il risultato sarà il seguente:

Non ci giro intorno, mi sarei aspettato una CTF con una flag da catturare :) è un po' come se andassi in un ristorante italiano in Oklahoma City, ordinassi la cacio e pepe e mi servissero la cotoletta di seitan dal menù Vegan. La lacrimuccia scenderebbe a chiunque (IMHO naturalmente). Da apprezzare invece l'originalità e l'unicità di una Non-CTF basata su un container che non fosse il solito docker based da cui si evade per una misconfiguration che, nella realtà, non si verifica (sì... ho preso un pretesto a caso per una critica gratuita ad hackthebox).

HackInBoat si è concluso, le "vacanze" anche, ma non perdetevi i video che pubblicheremo sul canale YouTube a proposito di questi 3 giorni fantastici.