Hacktive Security Blog

Quando il "tool" non basta...

Se sei “del mestiere” e le Code Review e i Penetration Test sono il tuo pane quotidiano, il titolo di questo articolo suonerà familiare; per molti altri probabilmente lo strumento automatico può essere ancora considerato un rimedio per mettere una "pezza" dove il processo di SSDLC ha fallito (ammesso ce ne sia uno). Nell’analisi proposta in queste poche righe, eviterò di tener conto del rapporto qualità prezzo tra un’analisi effettuata manualmente e una effettuata esclusivamente con uno strumento automatico (sia in ambito Code Review che Penetration Test) e mi focalizzerò esclusivamente su quegli aspetti che difficilmente uno strumento automatico è in grado di identificare durante l’analisi di un’applicazione. E’ evidente che un’analisi manuale supportata da uno strumento automatico dovrebbe fornire un risultato di qualità superiore cercando di mantenere i tempi di analisi comunque accettabili. Proprio a tal proposito ci sono numerosi casi in cui l’analisi automatica non consente di sviscerare alcune tipologie di vulnerabilità con impatto particolarmente elevato sull’intera infrastruttura applicativa. Molto spesso, ho la sfortuna di trovarmi nella spiacevole circostanza di non poter essere supportato come vorrei da uno strumento automatico in fase di analisi. Perché? Il perché è facilmente individuabile nell’impossibilità per i software attualmente in circolazione di identificare vulnerabilità di sicurezza che dipendono dal contesto operativo, dalla tipologia di dato gestito, dalla mancata implementazione di un meccanismo di autorizzazione o che impattano sulla business logic applicativa. Vediamo di seguito alcune di queste vulnerabilità.

Credenziali di accesso o altre informazioni sensibili “hardcoded” nel codice 

Durante un’attività di code review può capitare d’imbattersi in credenziali di accesso applicative inserite staticamente nel codice, probabilmente introdotte in fase di collaudo; Molti potrebbero affermare che gli strumenti di analisi statica del codice in circolazione prevedono anche una ricerca per parole chiave. Ma cosa succede se lo sviluppatore decide di chiamare le variabili contenenti le credenziali di accesso con nomi assolutamente non attinenti alla tipologia del dato trattato? Questo è il primo dei casi in cui uno strumento automatico fallisce nel tentativo d’individuare una criticità di sicurezza. E’ facile immaginare come l'anomalia di sicurezza in oggetto abbia un impatto notevolmente elevato sui dati gestiti dall’applicazione. Ovviamente una problematica del genere potrebbe ricadere su qualsiasi tipo di dato inserito staticamente all’interno del codice, ma se uno strumento di analisi automatica non è in grado di rilevare delle credenziali di accesso risulta difficile pensare possa essere in grado di rilevare, correttamente, altri tipi di dati altrettanto importanti per l’utente e/o per l’applicazione (fatta eccezione ad esempio per i numeri PAN).

Utilizzo di “Clear-Text Protocols” 

Ovviamente uno strumento automatico dovrebbe essere in grado di riconoscere la presenza di URL in HTTP piuttosto che in HTTPS; Quello che sicuramente (ad oggi) non è in grado di fare è contestualizzare con un’elevata certezza, l’utilizzo di una determinata URL all’interno di un definito blocco di codice e quindi di valutarne l’effettiva criticità. Chiaramente durante un’analisi statica del codice, è inverosimile che un’analista segnali l’utilizzo di richieste HTTP se queste non vengono utilizzate per l’invio di dati sensibili e/o critici per l’applicazione e/o per l’utente. Ma se all’interno della richiesta GET o POST viaggiassero credenziali di accesso, dati di pagamento o dati sensibili riconducibili a un determinato account? Certo, questa è una di quelle vulnerabilità facilmente identificabili durante un Penetration Test applicativo, ma il motivo per cui risulta importante identificarlo anche in fase di Code Review è che troppo spesso ci si affida a solo uno di questi servizi di sicurezza. Una Code Review, come anche un Penetration Test di qualità non può evidenziare false criticità ma soprattutto deve essere in grado di identificare problematiche di sicurezza non esclusivamente dipendenti dal codice applicativo.

Dati sensibili trasmessi nell’URL

Questa tipologia di vulnerabilità riassume entrambe le problematiche precedentemente descritte; poniamo il caso che l’applicazione oggetto di verifica utilizzi richieste HTTPS tramite metodo GET e preveda dei parametri. Di per se quanto appena descritto non è classificabile come una vulnerabilità, eppure l’occhio attento di un Security Analyst potrebbe essere in grado di contestualizzare la richiesta e intuire la tipologia di dati che verrano utilizzati per il corretto funzionamento del processo applicativo. Nel caso specifico sopra descritto, l’invio di dati di sessione e/o di pagamento risulta particolarmente critico poiché i dati saranno chiaramente visibili all’interno dei log del web server.

Mancata o errata implementazione di meccanismi di autorizzazione 

Per continuare con le criticità a elevato impatto, nella lista delle vulnerabilità che molto poco probabilmente troverete in un report generato automaticamente, è necessario inserire quelle legate a una mancata o errata gestione delle autorizzazioni applicative. E’ difficile immaginare che un software utilizzato per le verifiche di sicurezza sia in grado di rilevare con assoluta certezza la presenza o meno di un meccanismo di verifica delle autorizzazioni all’interno del codice. Anche in questo caso l’intervento di un’analisi manuale risulta essere fondamentale. Insomma, nulla che non si sappia già (o almeno così dovrebbe essere), ma per sottolineare quanto sia importante svolgere verifiche manuali supportate da quelle automatiche e continuare a sensibilizzare i non addetti ai lavori sull'importanza di non affidarsi ciecamente ai prodotti ma di affiancarvi soprattutto dei professionisti qualificati.

(Carlo Pelliccioni)

Welcome to Hacktive Security Blog

So here we are

our first blog post, we hope to let you read on these pages interesting stuff, of course here we will handle mainly information security related subjects but besides sharing our news and researches we will try to use this space even to improve the communication experience with our customers, suppliers and/or just friendy followers. Stay tuned, we will come up with some cool stuff soon:)

Home