Fra i vari feed che leggo, ovviamente che ne sono alcuni che riguardano le nuove vulnerabilità. Dato che al momento non sono impegnato in attività da sistemista, leggere questi interminabili elenchi di vulnerabilità mi fa l’effetto di ascoltare isoradio stando a casa: una serie di notizie sostanzialmente uguali tutti i giorni, cambiano i posti e i chilometri delle code, ma le cause sono sempre le stesse e in alcuni tratti a certe ore c’è sempre coda. Ha ragione (come sempre) Spafford, quando dice che passiamo il tempo a risolvere i problemi sbagliati.
Comunque, ci sono un paio di vulnerabilità che hanno risvegliato un po’ di curiosità. La prima è la vulnerabilità nella gestione delle URI di Explorer 7. La cosa è anche discussa sul blog di Feliciano Intini, che dice una cosa sacrosanta: un programma si deve preoccupare di validare il proprio input, non supporre che lo abbia validato un componente sul quale non ha controllo. Sul resto della marmellata del problema non mi esprimo (la ShellExecute() che interpreta i dati non destinati a lei…. mah!)
Un’altra vulnerabilità che mi ha dato da pensare è la vulnerabilità del server lpd nel Cisco IOS. Riesco ancora a stupirmi di quanta roba è dove non dovrebbe essere. Un server di stampa su un router… mah! E non consola sapere che è disabilitato di default. Questo mi ricorda un “nanetto” relativo alle aziende che fanno “vulnerability assessment” comprando un paio di tool di scanning e mandando direttamente i report al cliente, magari un po’ ritoccati nella grafica. Una volta sono stato chiamato a rifare un assessment, dato che la “ditta specializzata” che lo aveva fatto prima non sembrava aver prodotto un report credibile… in effetti, avevano segnalato un server Oracle vulnerabile su un router.
Il motivo per cui è successo (a parte la totale incomprensione di quello che stava facendo da parte di chi ha prodotto il report) è il modo in cui funzionano questi tool. Se gli si dice di cercare una vulnerabilità di un certo prodotto su un certo indirizzo IP, questi si connettono alla porta del servizio da verificare su quel certo indirizzo IP. Se la connessione viene accettata, non si pongono il problema se a rispondere sia veramente il prodotto da verificare o qualcos’altro, anche perché non è sempre facile capirlo. Il tool invece invia le sue stringhe che dovrebbero evidenziare le risposte. Se le risposte sono di un certo tipo, il sistema non è vulnerabile. Se sono di un altro tipo, il sistema forse è vulnerabile. Se arriva una stringa inaspettata, secondo una logica di fail safe di solito segnalano il sistema come “forse vulnerabile” e lasciano all’analista gli approfondimenti. Insomma, sono giustamente propensi al falso positivo anziché al falso negativo, dato che si suppone che poi l’analista che ci sta lavorando valuti in modo critico i risultati. È chiaro che se a rispondere non è il prodotto di interesse ma un’altro, magari per tutt’altro tipo di servizio, le risposte quasi sempre sono inaspettate e cadono quindi nella categoria falsi positivi. È chiaro che se l’analista non distingue un router da un server Oracle, poi fa le figuracce…
