Il Penetration Test è indispensabile per valutare la sicurezza di un sistema informatico, validando e verificando metodicamente l’efficacia dei controlli di sicurezza informatica.
Indice degli argomenti
Cos’è il penetration test (o pen test)
Questa tipologia di analisi è concepita per la valutazione della sicurezza di una ‘applicazione web’ – software che si interfacciano con la rete – di conseguenza i test riguardano tutto il sistema informatico di una organizzazione. Ad esempio, l’analisi di un portale web inizia testando le diverse funzionalità, per poi concentrarsi sul meccanismo di autenticazione e l’interazione con i database. Segue l’analisi della configurazione del relativo server e tutti gli elementi che lo circondano nella rete, e quindi tutti i dati e le informazioni di proprietà di una organizzazione.
Il ‘PenTest’ è la verifica necessaria per dimostrare che il sistema informatico soddisfi i requisiti di sicurezza dei suoi stakeholder.
Come funziona e come avviene un penetration test
Il processo prevede un’analisi attiva e passiva del sistema per individuare eventuali punti deboli, difetti tecnici e vulnerabilità: queste problematiche possono derivare dalla progettazione, implementazione o gestione del sistema, e potrebbero essere sfruttate per compromettere gli obiettivi di sicurezza del sistema e quindi del business.
La finalità è evitare che un attaccante malintenzionato – esterno o interno – o una instabilità del sistema possano impattare sulla confidenzialità, integrità e disponibilità delle risorse.
I problemi di sicurezza rilevati verranno presentati al proprietario del sistema in un report, insieme a una valutazione dell’impatto, a una soluzione tecnica o, se non possibile, a un rimedio di attenuazione delle criticità.
Per effettuare un test su sistemi che non si posseggono è necessario operare previo contratto che dimostri il consenso e l’autorizzazione alle attività, regolandone gli obiettivi e la tempistica e soprattutto le sole risorse interessate.
Il contratto per il penetration test e la professione di penetration tester
Il contratto deve presentare clausole di riservatezza, gli indirizzi IP da cui partiranno i test, le persone fisiche responsabili e operative durante l’attività, e l’eventuale collaborazione con operatori e amministratori interni.
Colui che effettua un test di un sistema deve garantire la non interruzione delle attività e processi, la non modifica e perdita dei dati e informazioni del cliente.
Tutte le attività non regolamentate da un contratto devono essere da considerare illegali.
Come detto, le finalità e gli obiettivi devono essere chiariti al momento del contratto. Il proprietario del sistema decide quali informazioni condividere con l’analista.
Un’attività di test può essere effettuata condividendo come unica informazione l’indirizzo internet (del cliente proprietario): la finalità di questa tipologia di attività – in gergo ‘black box’ – è di comprendere quali risultati potrebbe raggiungere un attaccante esterno, via internet. Questa modalità generalmente non è efficace perché è direttamente vincolata alle capacità dell’analista e al tempo investito.
Generalmente è consigliato condividere maggiori informazioni e dettagli – ‘gray’ o ‘white box’ – riguardanti i singoli server e dispositivi di sicurezza: in questo caso colui che svolgerà l’attività avrà la possibilità di avere una panoramica generale del sistema, e il test sarà più efficacie e completo in quanto si concentrerà sui singoli dispositivi e non solo sul funzionamento generale. Le informazioni del sistema e dei singoli dispositivi sono facilmente individuabili, ma la raccolta richiede tempo, che potrebbe essere utilizzato per analisi più approfondite.
Il proprietario del sistema può creare un utente di sistema ad hoc per l’attività di analisi, o meglio un utente per tipologia di ‘ruoli utente’ esistenti nel sistema, e fornire le credenziali temporanee a colui che effettuerà l’analisi. Lo scopo è analizzare i rischi esterni – come in precedenza – e i rischi interni: l’attività permetterà di comprendere quali utenze possono leggere, modificare, o cancellare quali risorse, quindi comprendere il vero rischio di un dispositivo manomesso o di un utente malintenzionato, all’interno del sistema.
Come si dividono e quali sono i tipi penetration test
External Testing (Penetration Test esterni)
I pentest esterni hanno come obiettivo quello di capire se un hacker può entrare nel sistema informatico (dall’esterno appunto), e quanto in profondità può entrare nel sistema colpito. Con questi test si cerca tutto ciò che è visibile in rete (ad esempio con le Google dork) per provare a trovare punti di accesso “scoperti” (backdoor, bug ed errori nel sistema informatico, etc) che possano permettere all’hacker di entrare (o meglio, “penetrare“) nel sistema. Questi attacchi di solito vengono effettuati dal penetration tester senza conoscere l’infrastruttura dell’azienda, partendo invece dal web, da internet e dalle ricerche sui motori di ricerca. Alcune cose che possono essere analizzate e testate in questi test esterni sono: DNS (Domain Name Servers), Sito web, Web application e altri.
Internal Testing (Penetration Test interni)
Un test interno viene di solito effettuato da qualcuno all’interno dell’organizzazione. Infatti se ad esempio un malintenzionato riesce ad ottenere in qualche modo password e altri dati di accesso di un impiegato, potrebbe quindi accedere facilmente a molti sistemi interni e disponibili solo ai dipendenti dell’azienda. Un penetration test interno serve proprio ad analizzare casistiche di questo tipo, e a trovare buchi e falle del sistema interno riservato agli impiegati.
Targeted Testing
I test di penetrazione targettizzati vengono effettuati insieme da un penetration tester e dal dipartimento IT, e servono principalmente per far capire agli IT in azienda quale può essere la prospettiva di chi sta attaccando i sistemi, in modo da poterli rendere più sicuri anche con futuri sviluppi.
Blind testing
E’ l’attacco più interessante e realistico, anche se è quello più dispendioso per l’azienda che vuole provarlo, e dispendioso anche in termini di risorse e tempo da parte del tester. Infatti in questo caso di “test cieco” l’unica informazione di cui dispone il pen tester è il nome dell’azienda. Da qui dovrà trovare il modo di penetrare nei sistemi IT dell’azienda, attraverso tecniche di hacking conosciute.
Double Blind testing
Molto simile al blind test visto precedentemente, il double blind test ha come unica differenza quella che il dipartimento IT è completamente all’oscuro del fatto che si sta iniziando questo tipo di attacco / test. In questo modo viene simulato un reale attacco informatico, “di nascosto” da tutti quanti i principali attori informatici all’interno dell’azienda.
Verso cosa possono essere fatti i penetration test?
Penetration test applicazioni web
Grazie a penetration test delle web app, si può scoprire se un hacker potrebbe compromettere la propria applicazione web, sia dall’interno che dall’esterno. Un pentest delle applicazioni come un test di penetrazione in un sito web, alla ricerca delle più comuni vulnerabilità definite da OWASP (Open Web Application Security Project). Si studiano quindi le applicazioni web al fine di trovare backdoor e falle nel sistema che rendono l’app vulnerabile, create magari durante lo sviluppo o l’integrazione dell’app.
Penetration test reti wireless
I penetration test per violare le reti wireless cercano di capire quanto facilmente una rete possa essere sfruttata utilizzando il wireless. Viene anche qui simulato un attacco di un malintenzionato che si trovasse nel perimetro wireless di copertura della rete.
Penetration test protocollo VoIP
Un Penetration Test del protocollo VoIP consiste nel raccogliere più informazioni possibile dalla rete VOIP, tra la presa ethernet e il telefono. E’ possibile ad esempio penetrare nei telefoni IP, nell’intera infrastruttura telefonica VOIP, sventare frodi telefoniche e capire quindi il grado di vulnerabilità della rete VOIP aziendale.
Penetration test accesso remoto
Il pen test dell’accesso in remoto consente di scoprire eventuali vulnerabilità dovute al lavoro a distanza, proteggendo quindi il lavoro da remoto. Quindi è utile fare dei penetration test a VDI, sistemi Citrix e desktop remoti utilizzati dall’azienda, che permettono ai propri dipendenti di lavorare in mobilità e da distanza (in remoto appunto) garantendo quindi la sicurezza dell’intera struttura IT aziendale.
Quali sono le tipologie di test di penetrazione (pen test) su un sistema informatico
I test effettuabili su un sistema informatico sono di vario tipo, generalmente classificati in 11 categorie.
Information Gathering
La raccolta di informazioni del sistema target è il primo passo del PenTest: si svolge un’analisi di tutte le informazioni ottenibili tramite sito web dell’organizzazione, motori di ricerca, documenti pubblici, pagine e database dei partner, social network, e tutto quello che si può trovare online, cercando informazioni tramite telefonate in azienda o contattando ex dipendenti. Questa è la metodologia spiegata sui blog, ma in pratica bastano pochi strumenti automatici per individuare tutte le informazioni necessarie: ad esempio, un software con funzioni di ‘Vulnerability Assessment’ in pochi minuti riesce a raccogliere le versioni dei software installati, ed è già possibile sapere quali strumenti non sono aggiornati, e quindi quali vulnerabilità sono presenti.
Nota: tutti gli strumenti automatici aiutano a velocizzare le operazioni ma possono essere molto imprecisi.
Configuration and Deployment Management Testing
Il test sulla configurazione degli strumenti – specialmente quelli installati sui server – permette di comprendere il funzionamento dei singoli dispositivi e delle applicazioni installate su essi.
Generalmente è facile imbattersi in strumenti con le ‘impostazioni di default’: questo significa che gli sviluppatori hanno installato un software o dispositivo network e non hanno modificato le impostazioni create automaticamente durante l’installazione e, per esempio, potrebbe essere ancora possibile autenticarsi a un database con le credenziali d’installazione “user: admin” e “password: admin”.
E’ frequente trovare in chiaro i ‘file di installazione’ degli strumenti software, e gli appunti scritti dei sistemisti: queste informazioni danno dettagli preziosi su come lavorano gli strumenti, ed evidenziano errori e vulnerabilità sfruttabili.
Se uno strumento è mal configurato, oltre a i problemi di funzionamento e alle specifiche debolezze, è molto probabile che non siano state implementate le funzionalità di sicurezza; comprendendo le lacune tecniche dei sistemisti, con buona probabilità si raggiungono anche altre problematiche.
Authentication Testing
Testare i meccanismi di autenticazione significa comprendere il funzionamento del processo e rilevare come sia possibile aggirare i controlli.
L’autenticazione è l’atto di verificare la provenienza della comunicazione, e non solo l’identità di una persona. L’autenticazione dovrebbe dipendere da più fattori e non solo dalla combinazione ‘user e password’.
I meccanismi che garantiscono l’autenticazione sono fondamentali per preservare le informazioni. E’ quindi essenziale implementare il controllo degli accessi con gli strumenti e i protocolli più robusti sul mercato.
Uno dei principali problemi riscontrati, anche nelle aziende multinazionali, è la non adeguata gestione dei meccanismi di sicurezza e potrebbe bastare intercettare una autenticazione utente e riutilizzare il messaggio – anche se criptato – per essere autenticati.
Identity Management Testing
Le informazioni in un sistema devono essere protette, regolamentando cosa gli utenti possono leggere, modificare e/o eliminare. Il business dell’organizzazione deve essere protetto da ogni tipologia di rischio, interno ed esterno, volontario e involontario.
Nelle reti moderne è doveroso definire ’ruoli’ e ‘privilegi’ degli utenti nel sistema per la gestione delle risorse.
L’implementazione di uno strumento prevede basicamente almeno due ruoli: ‘amministratore’ e ‘utente’. Il primo rappresenta l’unico utente a cui deve essere consentito l’accesso alle funzionalità di installazione degli strumenti e modifica delle configurazioni.
Le politiche aziendali devono regolamentare i poteri sui dati di ogni utenza, che deve essere associata ad una sola persona fisica. Anche gli amministratori di sistema dovrebbero avere poteri limitati: l’accesso con i massimi privilegi dovrebbe essere un evento eccezionale. Ogni ‘regola’ deve essere riesaminata periodicamente.
I test sulla gestione delle identità devono anche analizzare il funzionamento del sistema di gestione delle credenziali: i processi devono garantire la robustezza e proteggere le password. Per esempio, nessuno strumento deve presentare la lista degli utenti associati alle relative password, anche se queste informazione sono crittografate.
Authorization Testing
L’autorizzazione è il processo che avviene dopo l’autenticazione, queste due fasi devono essere legate – non deve esistere autorizzazione su una risorsa senza autenticazione.
L’analisi delle autorizzazioni, a differenza delle precedenti analisi, ha finalità di comprendere se è possibile accedere alle risorse sfruttando intenzionalmente le vulnerabilità – effettuando veri e propri attacchi.
In questa fase si vuole comprendere l’efficacia del controllo degli accessi e delle autorizzazioni.
Il tester verificherà se è possibile raggiungere risorse che dovrebbero essere protette, ad esempio raggirando il meccanismo di controllo e o sfruttando vulnerabilità.
Session Management Testing
Uno dei componenti principali di qualsiasi applicazione basata sul web è il meccanismo di sessione: esso controlla e mantiene attivo lo stato dell’utente, ad esempio per garantire l’identità e permettere operazioni su più pagine e nel tempo. La ‘gestione della sessione’ è definita come l’insieme di controlli – dal login al logout – che regolano l’interazione tra utente e l’applicazione web, e tra utente e il suo stato.
Esistono diversi modi in cui un’applicazione web può interagire con un utente, in base agli obiettivi di business, alle tecnologie utilizzate, ai controlli di sicurezza, e ai requisiti di disponibilità del servizio. Sebbene esistano linee guida considerate efficaci per lo sviluppo di applicazioni, è importante che la sicurezza delle applicazioni sia considerata già nelle prime fasi di progettazione, oltre nel contesto dei requisiti e aspettative del fornitore.
Le attività di analisi, in questa fase, si concentrano sul comprendere l’effettiva fattibilità di attacchi, per lo più concentrati sull’intercettazione o reindirizzamento dei messaggi scambiati tra utente e sistema. Un attaccante, ad esempio, non deve avere la possibilità di analizzare e riutilizzare – interamente o in parte – i messaggi scambiati – in chiaro o criptati – al fine di raggirare i meccanismi di controllo di sessione, al fine di poter operare come un utente – in gergo ‘sfruttato’ – il quale ha già effettuato l’autenticazione e ha già ottenuto le autorizzazioni.
In alcuni sistemi è ancora possibile intercettare le comunicazioni di un utente, riutilizzare parte delle informazioni di sessione – nei ‘cookies’ – per comunicare con il sistema come un utente autorizzato; per l’attaccante sarà possibile avere visione dei progetti, informazioni, o altri segreti industriali.
Input Validation Testing
La debolezza più comune delle applicazioni web è sempre stata la mancanza di controllo e convalida dell’input – proveniente dall’utente o dall’ambiente interno ed esterno.
I dati in input non dovrebbero mai essere considerati attendibili, poiché possono essere arbitrariamente modificati da un utente malintenzionato. Le applicazioni hanno spesso un numero elevato di punti di ingresso, il che rende difficile per progettisti e sviluppatori implementare i controlli. Se il reparto IT non ha come obiettivo la sicurezza del sistema, ma solo la minimizzazione del tempo, sarà portato a tralasciare tutto ciò che non è basicamente necessario per il funzionamento. Se un utente malintenzionato può inviare porzioni di ‘codice’ tramite applicazione web e farle ‘eseguire’ dal sistema, il danno per l’organizzazione può essere ingente.
La mancanza di validazione dell’input porta alle più conosciute vulnerabilità delle applicazioni web, come ad esempio il ‘cross site scripting’, ‘SQL injection’, e ‘buffer overflow’.
Per sfruttare queste tipologie di debolezze non sono necessarie conoscenze tecniche e teoriche approfondite, ma basta una breve ricerca in internet per capire come effettuare un attacco; ciò vuol dire che anche attaccanti inesperti possono essere una vera minaccia.
Negli ultimi due anni è aumentata l’attenzione a queste vulnerabilità, e generalmente su questa analisi si concentrano principalmente le attività degli analisti, rischiando però di sottostimare l’importanza delle altre fasi.
Client Side Testing
Il test ‘lato utente’ è spesso confuso con il test di validazione dell’input. Il test ‘client-side’ verifica se è possibile far eseguire volontariamente codice dal browser web, o dai plug-in, installati sulla macchina dell’utente. L’esecuzione del codice in questo caso avverrà ‘lato client’ (ad esempio sul computer dell’utente vittima) e non eseguito dal sistema informatico – ‘lato server’.
Come esempio, l’ HTML injection è un tipo di attacco che avviene sfruttando una mancanza di validazione dell’input, ma il codice malevolo è eseguito dall’utente e non dal server – sfruttando la pagina web solamente come vettore – l’attaccante inserisce del codice HTML in una pagina web e quando la pagina è caricata dall’utente, il browser eseguirà delle operazioni. Questa specifica vulnerabilità può avere molte conseguenze, come il furto di ‘cookie di sessione’ di un utente, utilizzabili per autenticarsi con l’utenza della vittima.
Error Handling
Un aspetto importante per lo sviluppo di un sistema sicuro è quello di prevenire la perdita di informazioni. I messaggi di errore forniscono a un utente malintenzionato informazioni dettagliate sul funzionamento interno del sistema.
Lo scopo di ‘revisione del codice’ e della gestione degli errori, è assicurare che l’applicazione non fornisca dettagli sul sistema in condizioni di errore, previste e impreviste. Nessuna informazione sul funzionamento dovrebbe essere presentata all’utente quando si verifica un errore.
Ad esempio, un attaccante può cercare di provocare volontariamente errori e leggendo i messaggi restituiti dall’applicazione può comprendere quali strumenti hardware e software sono presenti nel sistema, e quindi comprendere quali attacchi – ‘exploit’ – è possibile effettuare.
La gestione degli errori ed eccezioni deve essere implementata nella fase di sviluppo: tutti i percorsi che possono generare un errore o eccezione devono essere verificati correttamente e gestiti.
Weak Cryptography
Come nel mondo reale, anche nell’informatica qualsiasi codice può essere decifrato. La robustezza della crittografia è valutata in base al tempo necessario a comprendere i messaggi, con la tecnologia a disposizione: uno strumento automatico (grazie alla potenza di calcolo disponibile) può decifrare un messaggio in pochi secondi o in milioni di anni, in base al protocollo utilizzato.
Gli algoritmi di crittografia sono oggetto di studi, e scoperta la metodologia per decifrare un ‘messaggio’ – il contenuto criptato – la decifrazione non autorizzata diventa sensibilmente più rapida.
La configurazione degli strumenti del sistema deve prevedere l’utilizzo dei soli protocolli considerati sicuri, verificando periodicamente la non obsolescenza.
Il sistema informatico di una organizzazione non deve comunicare ‘in chiaro’ – non utilizzando la crittografia – o per vie insicure.
Questa tipologia di analisi prevede principalmente il test delle comunicazioni, e il rilevamento dei protocolli di comunicazione utilizzati.
Esistono molteplici analisi crittografiche in fase di sperimentazione, le quali risultano utilizzate per la ricerca scientifica, o da enti governativi, e non abitualmente utilizzate per le attività di consulenza, per via della non diffusione di queste metodologie.
Business Logic Testing
I test sul funzionamento della logica sui processi informatici permettono di prevenire errori e difetti dei processi, e operano come i test sui processi di business (ad esempio sulla produzione).
Le ‘funzioni’ vengono testate inserendo un input ed esaminando l’output – raramente considerando la struttura dello strumento.
Conclusioni: formazione e consigli per i penetration tester
Questi tipi di test richiedono che i professionisti della sicurezza operino in modo differente rispetto alle precedenti analisi, utilizzando tecniche di ‘quality assurance’ e ‘quality control’.
L’automazione dei test non è ad oggi possibile e rimane un’attività manuale che si basa sulle capacità del tester e sulla sua conoscenza dei processi aziendali e delle relative regole. Verificare i difetti della logica di business in un’applicazione web dinamica e multi-funzionale richiede metodologie non standardizzabili. Per testare, ad esempio, un meccanismo di autenticazione è necessario comprendere i passaggi sequenziali del protocollo e verificare il comportamento del sistema; una possibilità è modificare l’ordine dei passaggi e comprendere cosa succede.
Generalmente è difficile per un consulente effettuare questa tipologia di analisi in modo completo senza che il proprietario fornisca informazioni complete del sistema. L’attività normalmente si occupa di verificare malfunzionamenti sulle singole componenti.
La sicurezza è valutata su uno specifico lasso temporale: la scoperta di una vulnerabilità o la modifica della configurazione di un singolo strumento, ad esempio, può aumentare il rischio per l’intero sistema.
Una organizzazione deve investire per incrementare l’attenzione alle tematiche di sicurezza, e inserendo il Penetration Test nel processo dell’auditing continuo è possibile rendere sicuro e stabile l’intera struttura informatica.
