Paolo PeregoFollowSpecialista di sicurezza applicativa e certificato OSCE e OSCP, amo spaccare e ricostruire il codice in maniera sicura. Sono cintura nera di taekwon-do, marito e papà. Ranger Caotico Neutrale, scrivo su @codiceinsicuro.
Vi ho rimandato, in un update del post,
all’articolo
originale che spiega due CVE, il
CVE-2014-7186
e il
CVE-2014-7187,
che nel mio post avevo colpevolmente omesso.
Oggi parliamo invece di come testare la vulnerabilità quando abbiamo in
gestione un gran numero di server unix.
Un passo oltre il vulnerability management
Potreste avere già in campo un processo di vulnerability management, quindi
potreste avere un software di vulnerability assessment che periodicamente
scansiona le vostre macchine per issue di security.
A seconda della schedulazione voi avrete quindi l’elenco delle macchine
vulnerabili a shellshock con tutti i CVE che ne seguono.
Questo implica anche che il vostro tool abbia già tutte le firme per i
possibili exploit legati a shellshock.
Il vostro capo però vuole una situazione aggiornata ora e non c’è tempo di
aspettare che partano tutte le scansioni schedulate. Dobbiamo quindi
arrangiarci.
Lista della spesa
Per automatizzare con successo il processo di verifica ci serve:
elenco completo dei server unix da testare
script che provi tutti i possibili exploit sulla bash
script per automatizzarne l’esecuzione
Sembra paradossale, ma forse l’elenco completo dei server unix da testare è la
cosa più complessa da recuperare. Ci sono realtà dove agenti di software di
asset inventory, provano a popolare per noi questo elenco. Ci sono realtà dove
tutto è dentro un enorme foglio di calcolo. Ci sono realtà dove non c’è nulla e
si lavora per subnet.
Qui dipende molto dalla vostra realtà. In dubbio, chiedete ai sysadmin.
L’importante è che abbiate un elenco di indirizzi IP di macchine Unix, perché
il nostro script non si metterà a fare un nmap per discovery e per riconoscere
il sistema operativo.
Lo script per fare il check locale
Lo script per testare, localmente, tutte le varianti di shellshock lo potete
trovare qui su github.com. Non fa altro
che provare a mettere i diversi pattern d’attacco in una variabile d’ambiente e
vedere come reagisce la shell.
Anche in questo caso però ho bisogno di fare qualche modifica. Lo script di
hannob è bello, usa i colori, da messaggi
completi, ma trovo l’output sia poco usabile in caso debba collezionare i dati
di 1000 server.
Ho bisogno quindi di modificare lo script per ottenere in output un YES o NO
divisi da virgole a seconda che l’exploit sia andato a buon fine o meno. Alla
fine sto costruendo un enorme file CSV che potrò importare in un foglio di
calcolo per fare un po’ di intelligence sui dati.
Provando questo script sul mio macbook, ottengo il seguente output:
Colleziono quindi la shell che ho testato, la versione e poi l’output degli
exploit. Lascio la virgola dopo l’ultimo risultato perché lo script che poi
eseguirà i tentativi, appenderà l’hostname e se è riuscito ad collegarsi sulla
macchina.
Lo script per automatizzare il tutto
Per eseguire questo script, vi servirà un utente locale sulle varie macchine
che andrete a testare. Probabilmente ne avrete già uno, sostituite quindi la
login corretta al valore ‘guest’.
Una volta lanciato lo script vi chiederà la password da utilizzare per le
connessioni ssh, proverà a copiare lo script attaccante sulla macchina, lo
eseguirà redirigendone l’output su un file, recupererà il file dalla macchina
target e poi farà pulizia.
L’output sarà quindi un file CSV contenente l’esito dei test sulla macchina.
Ecco l’output dello script eseguito sul mio portatile.
Off by one
Se avete un migliaio di indirizzi IP da scansionare, eseguire questo script vi
consentirà, non solo di verificare lo stato della macchina per la vulnerabilità
di cui tutti parlano in questi giorni, ma anche di verificare che voi abbiate
una login remota da utilizzare… ovviamente per security stuff.
Se questo post ti è piaciuto, sono abbastanza sicuro che troverai questi contenuti altrettanto interessanti. Buona lettura.
Episodio 32: Quando l'EDR fa crock
Introduzione
Ciao caro lettore. Ero come al solito in ritardo nella creazione di questo
numero della newsletter di cybersecurity più aperiodica dell’universo, quando
Internet si è rotta ancora.
Eh già… in questi mesi ho dato anima e corpo al canale YouTube ed ho trascurato un po’ il mio blog. Questa però è una delle cose che voglio prima raccontare qui, nella mia versione digitale di un Bullet Journal.