Domanda Pentesting su rete di produzione

[J.A.R.V.I.S.]

Buonasera ragazzi!

Dopo i vostri consigli per iniziare la mia carriera nel campo della sicurezza informatica ho finalmente iniziato il corso di certificazione ejpt v2!
Ho solo una domanda, sento spesso che i tutor dicono di stare attenti quando si fanno privilege escalation sfruttando falle nel kernel del SO in quanto potrebbe far crashare la macchina, quindi mi sono sorte due domande
Perché puó far crashare la macchina e quali precauzioni devo prendere quando nel "mondo reale" sto facendo un penetration test a una ditta?

Per essere chiaro: non credo sia furbo effettuare un attacco invasivo al sistema di produzione, ma ovviamente non credo sia nemmeno possibile replicare l'intera rete di un'azienda in locale, qual é il giusto compromesso

Piú la spiegazione é tecnica meglio é!

Grazie in anticipo!

 

[0xbro]

Perché puó far crashare la macchina

Dipende molto dalla tipologia di exploit. Ti faccio un esempio molto ad alto livello per restare più vaghi possibile: il rischio è dovuto al fatto che i kernel exploits lavorano coi processi e con la memoria a basso livello. Basta un'imperfezione nel calcolo degli offset oppure far scrivere dei bytes o del contenuto al di fuori di una determinata area per causare il crash del sistema (crash che può essere dovuto al fatto che ci sono dei valori sporchi nei registri della CPU piuttosto che da una protezione implementata del sistema operativo o tanti altri fattori ancora).

quali precauzioni devo prendere quando nel "mondo reale" sto facendo un penetration test a una ditta?

Credo che le precauzioni principali siano:

• Testare, quando possibile, in un ambiente di pre-produzione o su un ambiente di test. La maggior parte delle aziende serie hanno un server di pre-prod o di sviluppo. Fai configurare loro lo stesso ambiente di prod (in genere dovrebbe già essere simile) e fai i test lì sopra
• Quando trovi un possibile kernel exploit o una falla con impatti critici - e sei in produzione - interfacciati col tuo responsabile e metti le cose in chiaro: hai trovato una possibile falla, potrebbe essere critica, potrebbe causare del disservizio ma non ne hai la certezza. Chiedi loro come preferiscano che tu ti muova, se sono disposti ad avere un falso positivo oppure se vogliono che validi la vulnerabilità. Lascia la scelta al tuo referente. Sarà meno eccitante per te, ma almeno ti eviti grossi guai

 

[J.A.R.V.I.S.]

Dipende molto dalla tipologia di exploit. Ti faccio un esempio molto ad alto livello per restare più vaghi possibile: il rischio è dovuto al fatto che i kernel exploits lavorano coi processi e con la memoria a basso livello. Basta un'imperfezione nel calcolo degli offset oppure far scrivere dei bytes o del contenuto al di fuori di una determinata area per causare il crash del sistema (crash che può essere dovuto al fatto che ci sono dei valori sporchi nei registri della CPU piuttosto che da una protezione implementata del sistema operativo o tanti altri fattori ancora).

Ah ora ho capito meglio, va bene, dato che non ho mai visto il codice di un exploit a livello kernel non avevo mai pensato a questo tipo di problematiche, grazie

Credo che le precauzioni principali siano:

• Testare, quando possibile, in un ambiente di pre-produzione o su un ambiente di test. La maggior parte delle aziende serie hanno un server di pre-prod o di sviluppo. Fai configurare loro lo stesso ambiente di prod (in genere dovrebbe già essere simile) e fai i test lì sopra
• Quando trovi un possibile kernel exploit o una falla con impatti critici - e sei in produzione - interfacciati col tuo responsabile e metti le cose in chiaro: hai trovato una possibile falla, potrebbe essere critica, potrebbe causare del disservizio ma non ne hai la certezza. Chiedi loro come preferiscano che tu ti muova, se sono disposti ad avere un falso positivo oppure se vogliono che validi la vulnerabilità. Lascia la scelta al tuo referente. Sarà meno eccitante per te, ma almeno ti eviti grossi guai

Ottimo, ma se stai facendo un pentest su una azienda medio piccola? So che spesso non hanno il budget per permetterselo, o non hanno interesse, nemmeno pensano a questo tipo di problematiche, ma magari potrebbero essere interessati ad un vulnerability assessment, almeno quello lo possiamo effettuare in ambito di produzione? Cioè, non credo possa essere un problema lanciare nessus o openVAS per una scansione preliminare, almeno da dare un'idea della sicurezza che hanno, mi sbaglio?

Poi per il pentest invece secendo te anche questo tipo di aziende hanno una specie di ridondanza su cui fare i test?
Perchè se non lo dovessero avere la vedo dura

 

[0xbro]

Ottimo, ma se stai facendo un pentest su una azienda medio piccola? So che spesso non hanno il budget per permetterselo, o non hanno interesse, nemmeno pensano a questo tipo di problematiche, ma magari potrebbero essere interessati ad un vulnerability assessment, almeno quello lo possiamo effettuare in ambito di produzione? Cioè, non credo possa essere un problema lanciare nessus o openVAS per una scansione preliminare, almeno da dare un'idea della sicurezza che hanno, mi sbaglio?

Personalmente lascerei sempre la decisione delicata a coloro che ti hanno ingaggiato: non hai un server di test? Scegli tu se preferisci avere un falso positivo oppure rischiare di avere disservizio. In genere la scelta è sempre la prima (per il management è meglio avere un falso positivo), ma soldoni la scelta finale è sempre loro.

Certo, si può lanciare un VA con Qualys o Nessus, ma il risultato è lo stesso di quanto detto sopra: Nessus trova una possibile falla (guardando le versioni, le signature dei files, ecc.) ma non la exploita, lasciando nuovamente aperta la porta del possibile falso positivo. Bada bene, non è un problema eh, anzi spesso molte aziende si accontentano di fare un VA senza che le varie vuln identificate vengano poi confermate o smentite. Nel mio modus-operandi ideale non è una buona prassi (resto dell'idea che le vuln debbano sempre venir validate) e infatti insisto sul validare realmente i findings identificati durante un VA, però il mercato è il mercato e spesso ci si accontenta.



Alla fine tutto dipende molto dalla qualità di lavoro che si vuole ricevere/fornire. Un VA da solo è abbastanza inutile, evidenzia solo le problematiche superficiali. Se si vuole fare un bel lavoro, che fornisca davvero del valore aggiunto, si fa in aggiunta un pentest, altrimenti si sta parlando solo di fuffa

 

[J.A.R.V.I.S.]

Ottimo, da come la esponi tu sembra chiaro che si fa quel che si puó.
Quindi dal punto di vista del mercato si puó proporre un VA giusto per dare l'idea al cliente del suo stato di rischio e poi se questo accetta gli si fa un pentest
Molto interessante in ottica commerciale, grazie!

 

[Netcat]

Giusto per curiosità l'altro giorno avevo fatto un esperimento in VM per testare gli effetti di un kernel exploit lanciato "alla script kiddie", ossia frettolosamente. Per il test ho usato CVE-2017-0144 e in VM Windows 7 (build 7600 arch x86).

Ho forzato questa VM x86 a divorare kernel shellcode x64 (overwritten) per osservarne la reazione. Nel primo stage della "bravata" il target OS ha fatto BSOD, al reboot sembrava tutto funzionare, ma il SMB è collassato permanentemente. Non è stato più possibile interagire con SMB 445 nemmeno dopo 2 reboot, e cel'ho ancora adesso invalidato, a causa della simulazione del tentativo di "hackerare" una macchina con le piante dei piedi invece che col cervello.

Quando possibile evita di toccare il kernel, soprattutto se non sai bene cosa stai facendo. Se proprio è l'unica via ti consiglio di clonare gli OS della ditta in VM e farglielo vedere davanti a loro.

 

[J.A.R.V.I.S.]

Wow, sono in bilico tra essere affascinato dalla "potenza" del codice e terrorizzato dai danni che avresti potuto fare a una ditta reale, grazie mille per l'esempio!