Vai al contenuto
Home » Le 3 cose più brutte che si trovano dopo anni di vulnerability assessment

Le 3 cose più brutte che si trovano dopo anni di vulnerability assessment

Dopo anni di vulnerability assessment ci sono tanti di quegli aneddoti su
risultati, su vulnerabilità che il vendor pensa siano feature, su thread di
mail infiniti dove non si capisce neanche il perché di un core dump, che potrei
farci un talk. E magari me la tengo buona per una delle prossime conferenze
alle quali andrò in autunno.

Anni di vulnerability assessment fanno emergere moltissimi casi di
vulnerabilità che il vendor pensa siano feature.

Capire che un sistema accumuli vulnerabilità nel tempo, credo sia una delle
cose più difficili da comprendere per il sistemista o devops medio di italiana
fattura. Almeno, questa è l’esperienza che ho accumulato in 15 anni che predico
di sicurezza applicativa, da poco cyber o anche cibernetica.

Facciamo chiarezza. Nel mondo ci sono persone che fanno ricerca. Prendono un
software e cercano bug e modi di bucarlo. Questo permette al software di
evolvere perché, diciamocelo francamente, io non credo i vendor facciano
penetration test sui loro sistemi.

Il lavoro di questi ricercatori, porta all’emissione di numerosi bollettini
CVE. Questi bollettini, stuzzicano la mente di altri
ricercatori che pubblicano un exploit, un programma che sfrutta quella
vulnerabilità. L’exploit poi viene venduto o in alcuni casi, se ritenuto poco
profittevole, rilasciato opensource.

Questo è il sunto della storia, descritto in maniera molto semplificata. La
morale è che i vostri sistemi, nel tempo, saranno interessati da vulnerabilità
che pian piano vengono scoperte.

In un processo di gestione delle vulnerabilità, nel corso del tempo, il livello
di rischio di un server varierà in funzione delle vulnerabilità che saranno
scoperte per il sistema operativo ed il software installato.

Bene, in questi anni, all’interno di questo processo ho visto tante cose e
vissuto situazioni al limite del paradossale. La conclusione è che, per la
parte di gestione della sicurezza dei propri asset, siano pochi i sistemisti o
i devops che se ne preoccupano seriamente. E questo è stupido, perché è inutile
parlare di sviluppo sicuro, se l’applicazione è in esecuzione su un server che
si buca guardandolo.

Proviamo a riassumere le 3 migliori.

E’ una feature, non una vulnerabilità

Non troppo tempo fa, mi è capitato di essere tirato in ballo in un thread dove
mi si puntava il dito per il core dump di un processo. Da una lettura dei log
si vede che l’IP è quello di una delle mie sonde e che il software prende un
po’ male il non rivolgersi a lui con il corretto protocollo.

Parentesi. I tool di vulnerability assessment, per capire chi sta dall’altra
parte, non si basano solamente su un nmap -sC -sV ip

I vostri sistemi, nel tempo, saranno interessati da vulnerabilità che pian
piano vengono scoperte

Molto spesso, software scritto male, non gestisce correttamente l’handshake con
un protocollo applicativo diverso dal proprio. Ci sono software che vanno in
core dump se si inizia una sessione telnet sulla loro porta applicativa.

La mancata gestione di una condizione eccezionale, porta ad un potenziale
denial of service che il primo lameronzolo attestato in rete può effettuare.
telnet ip porta non è un sofisticato pattern d’attacco, è la
dimostrazione che anche i grandi nomi del software usano programmatori mediocri
e non formati, non dico su temi di security, ma su tematiche base di qualità
del software.

Tanto è un sistema di collaudo

La scusa principale per giustificare la mancata gestione delle patch è che il
sistema non è in produzione. Di solito questa la smonto con una frase: “i dati
che tratta sono una copia di quelli in esercizio, vero?”. Seguono quasi sempre
silenzi imbarazzati o escalation dal sentore politico di un cielodurismo tutto
italiano radicato in molti di noi.

Al di là, un host conquistato, anche se di collaudo ha sempre un grande valore.
Può essere usato per collezionare credenziali o per distribuire malware ad
esempio.

Se il vostro devops si giustifica in questo modo, allora sta sbagliando tutto.

Non sapevamo che quel server esistesse ancora

La situazione più paradossale è quella dove il server è attestato in rete e
dimenticato. Spesso ospita una versione obsoleta del 90% del software
installato e spesso nessuno candidamente sa perché è ancora lì ma, cosa ancora
più grave secondo me, nessuno sa se può essere spento.

Viviamo in una società dove spesso anche in azienda vige il “chi non fa non
falla”
. In quest’ottica, chi si assume il rischio di spegnere un server, che
nessuno conosce? Magari c’è qualche batch dimenticato dalla notte dei tempi che
fa un compito mission critical.

Quindi qui partono di solito scambi di mail infuocati ed escalation perché
nessuno si vuol prendere il rischio di spegnere qualcosa di critico ed
assolutamente non più mantenuto.

Off by one

Qual è la vostra storia? Quali le cose più assurde emerse durante i
vulnerability assessment? Raccontale nei commenti.

Enjoy it!

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.