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; provano a fare anche il fingerprint del protocollo. Provano cioè a fare l’handshake con un demone utilizzando vari protocolli applicativi, per cercare di capire se in ascolto c’è un web server, un database mysql, un demone telnet o altro.

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!