[Informazioni tratte da wikipedia.it, siforge.net –appunti per aspiranti pentester e clusit.it- OWASP Web Application Penetration Checklist]

Il penetration test è la metodologia di valutazione della sicurezza di un sistema o di una rete. L'analisi comprende più fasi ed ha come obiettivo evidenziare le debolezze della piattaforma fornendo il maggior numero di informazioni sulle vulnerabilità che ne hanno permesso l'accesso non autorizzato. L'analisi è condotta dal punto di vista di un potenziale attaccante e consiste nello sfruttamento delle vulnerabilità rilevate al fine di ottenere più informazioni possibili per accedere indebitamente al sistema. Un pen-test consiste nel testare la sicurezza di un sistema cercando di violarlo sottoponendolo ad una grande varietà di attacchi informatici e non. L'obiettivo è quello di individuare eventuali vulnerabilità sfruttabili da terzi per ottenere accessi non autorizzati ai servizi e ai sistemi analizzati.

Oltre ai problemi di sicurezza, devono essere rilevati, quali possibili punti deboli, i problemi relativi alla configurazione, che incidono sulla robustezza e le performance del sistema, e gli errori di progettazione della rete. A volte una cattiva configurazione è più pericolosa di un bug.

Schematicamente i test devono individuare:

• bug, vulnerabilità e security hole nel software presente;
• punti deboli nella progettazione della rete;
• punti deboli di firewall e router;
• punti deboli negli script dei web-server;
• errori nella configurazione dei principali servizi in esecuzione;
• problemi relativi l'accesso fisico alle macchine.

Tutti i problemi di sicurezza rilevati vengono quindi presentati al cliente assieme ad una valutazione del loro impatto nel sistema e nello scenario del business aziendale, fornendo inoltre una soluzione tecnica o proposta di migrazione e mitigazione del sistema.

Il penetration test fornisce una stima chiara sulle capacità di difesa e del livello di penetrazione raggiunto nei confronti:

• delle vulnerabilità interne al sistema;
• delle vulnerabilità esterna al sistema;
• della sicurezza fisica.

L'analisi viene svolta a fronte di un accordo commerciale/tecnico. Chi svolge questa attività è chiamato penetration tester o auditor.
I processi di penetration test possono essere effettuati in diverse modalità. La differenza consiste sulla quantità e qualità delle informazioni disponibili agli analisti riguardo i sistemi analizzati. I processi di analisi che vengono condotti in un penetration test hanno diversi tempi di azione in cui sono alternate fasi manuali e fasi automatiche. Vengono acquisite inizialmente le informazioni principali sull'architettura della piattaforma e sui servizi offerti. Dall'analisi di questi dati deriva la scelta di come condurre il passo successivo, consistente in una enumerazione dei principali errori e problemi. Software automatizzati uniti all'esperienza manuale dell'analista permettono quindi di evidenziare tutte le possibili vulnerabilità, incluse quelle più recenti e alcune ancora non di pubblico dominio. I problemi riscontrati sono quindi manualmente verificati e sono prese le evidenze, o prove, che certificano l'esistenza delle problematiche stesse.
L'attività si conclude nello sviluppo della reportistica composta dal report di analisi sommaria dedicato al management o executive summary, contenente l'analisi dell'impatto di rischio di quanto riscontrato e tempistiche per l'azione di rientro o mitigazione delle problematiche riscontrate, e dal report tecnico, contenente l'analisi dettagliata dei problemi e la soluzione tecnica. Il penetration test va effettuato su sistemi esposti su Internet e comunque sulle piattaforme sensibili collegate a grosse reti, prima di entrare in esercizio, per avere una prova pratica della sicurezza di ciò che si espone.
Ogni aspetto del pen-test ne determina una particolare tipologia. In base al punto di partenza dell'attacco un pen-test può essere effettuato esternamente e/o internamente alla rete da valutare.
Un pen-test dall'esterno è condotto da una macchina remota per rilevare eventuali vulnerabilità sfruttabili attraverso internet.
I test condotti dall'interno hanno tra l'altro lo scopo di rilevare le possibilità di accedere a file e a dispositivi in modo inappropriato, ovvero migliorando i propri permessi.

Si distinguono vari livelli tecnici dei test. A grandi linee si possono delineare tre grandi categorie:

• livello basso: questo è il test che in genere fanno i tool di auditing automatici, a la Nessus per intenderci. Si controlla solo se ci sono servizi in esecuzione con vulnerabilità note, in genere vengono rilevate solo grosse falle e misconfigurazioni macroscopiche.
• livello medio: oltre a controllare i servizi in esecuzione, viene testata, come illustrato in precedenza, la rete, i firewall, i router, etc. Si fa spesso ricorso anche a tecniche di social engineering.
• livello alto: qui siamo a livelli paranoici, si può arrivare a controllare i sorgenti (se disponibili) dei programmi alla ricerca di nuove vulnerabilità, o ad esercitare la "nobile arte" del trashing.

In base alle informazioni preliminari ricevute dal committente si distinguono tre tipi di pen-test:

• zero knowledge (black box): si fa il test senza conoscere niente dell'host bersaglio, il tester si mette in pratica nelle stesse condizioni dell'attaccante. In questo caso il primo passo è la raccolta di informazioni.
• partial knowledge: vengono fornite dal committente alcune informazioni per indirizzare l'attacco verso un bersaglio preciso o anche per diminuire i tempi di testing e quindi le spese. Le informazioni fornite riguardano in genere la topologia della rete, le politiche di sicurezza adottate, etc.
• full knowledge (white box): in questo caso chi esegue il pen-test ha a disposizione tutte, o quasi, le informazioni possibili. In questo caso, in genere, si simula il comportamento di un "attaccante interno", ad esempio un dipendente.

Oltre a testare le macchine un pen-test può essere utile anche per valutare le persone addette a tali macchine. Avremo di conseguenza un test di tipo overt e uno di tipo covert:

• evidente: gli impiegati dell'organizzazione, e in particolare lo staff IT, sono a conoscenza del pen-test. Ovviamente in queste circostanze non ha senso usare metodi riconducibili al social engineering.
• nascosto: si esegue il pen-test con il permesso delle "alte cariche", e all'insaputa dello staff IT. Questo tipo di test è utile per testare, oltre alla sicurezza della rete, anche le capacità e l'affidabilità degli addetti alla sicurezza durante una emergenza e la reale validità delle politiche di sicurezza dell'azienda.

Il pen-test per sua natura non passa inosservato, le macchine che lo subiscono sono sottoposte ad uno stress non indifferente, e non è remota la possibilità di causare danni anche gravi ai sistemi testati.
In genere è preferibile usare metodi non-distruttivi in modo da non compromettere, nei limiti del possibile, il normale funzionamento della macchina.
In un pen-test non distruttivo il tester non deve usare metodi e tecniche che potrebbero portare alla perdita o al danneggiamento dei dati, e all'interruzione dei servizi forniti dalle macchine esaminate. Ad esempio in questo tipo di pen-test è sconsigliato portare attacchi di tipo DoS e simili.

La metodologia dipende dal livello di dettaglio che si vuole raggiungere. Durante le fasi di attacco si opera essenzialmente su due livelli, uno passivo e uno attivo. Diremo attacco passivo quello che non interagisce direttamente con il bersaglio, e quindi tutta la fase di raccolta delle informazioni. Mentre un attacco è attivo quando si eseguono azioni dirette contro il bersaglio.

Di seguito è illustrata a grandi linee una tipologia d'attacco:

• Ricognizione di base: informazioni dal sito, informazioni sul dominio e sull'amministratore. A volte basta visitare il sito per raccogliere importanti notizie sul software presente sul server, spesso infatti in fondo all'home page i webmaster inseriscono notizie sul sistema operativo, webserver, etc. (Ad esempio Powered by Apache, Linux Inside...).
• Ricostruzione della struttura interna della rete.
• Una volta identificata la struttura della rete e il numero di macchine bisogna raccogliere il maggior numero di informazioni su ognuna di esse. Quindi occorre ricercare i servizi in esecuzione, identificare i sistemi operativi, la versione dei servizi, il tipo di processore, i nomi utente (standard e non), le risorse condivise, etc.
• Ricerca di eventuali misconfigurazioni.
• Dopo aver determinato i tipi di servizi attivi sull'host bersaglio si deve tracciare una mappa delle vulnerabilità, e occorre ricercare (o scrivere) gli exploit applicabili contro i servizi bersaglio.
• Analisi della topologia della rete.
• Applicazione degli exploit.
• Verifica della possibilità di sniffing e tentativi di DOS.
• Test su router e firewall.
• Pulizia delle tracce dell'attacco.
• Stesura del report.

Un sistema può dirsi vulnerabile se è possibile:

• accedere a risorse interne;
• leggere e modificare file riservati;
• controllare il traffico in entrata e/o uscita;
• eseguire programmi senza averne i permessi;
• accedere alla macchina con i permessi di amministratore (root) da parte di utenti non privilegiati;
• controllare la configurazione della rete e dei servizi.

Il valore di un pen-test è strettamente legato alle capacità del tester. Inoltre perde di validità non appena si apportano modifiche (anche minime) alla configurazione di una macchina interessata al test, quindi è consigliabile eseguire un pen-test poco prima di mettere in produzione la rete. Inoltre anche lasciando inalterate le macchine testate, il pen-test dovrebbe essere ripetuto periodicamente, poiché vengono trovate quotidianamente nuove vulnerabilità e nuovi exploit.

Il report è il documento che il team che esegue il test presenta al committente alla fine della valutazione.

Il report deve indicare per ogni vulnerabilità riscontrata:

• Software/dispositivo affetto dalla vulnerabilità (Nome e versione);
• Tipo di vulnerabilità riscontrata;
• Gravità del bug (Bassa, Media, Alta);
• Esistenza, diffusione e applicabilità dell'exploit relativo alla vulnerabilità;
• Causa (bug, configurazione, etc.);
• Macchine/dispositivi interessati;
• Conseguenze;
• Esistenza e complessità della soluzione del problema;
• Descrizione dettagliata del problema e dei metodi utilizzati per individuarlo;
• Suggerimenti e note.

Bisogna anche fornire una descrizione dettagliata dell'intero processo di auditing effettuato. È consigliabile tenere durante i lavori un dettagliato "diario di bordo", dove riportare scrupolosamente ogni azione intrapresa e ogni effetto prodotto. Tale diario risulterà utile sia in fase di stesura del report finale sia per distinguere le attività del tester da eventuali anomalie verificatesi durante i lavori.

Questo paragrafo tratta di tutti quegli aspetti, qui definiti "punti critici", che hanno pesanti risvolti legali e che di conseguenza devono essere previsti e trattati adeguatamente in fase di stipula del contratto-liberatoria.

Punti critici

I punti critici da prendere in considerazioni sono: trattamento dei dati raccolti, salvaguardia dei sistemi e dei dati, riservatezza riguardo le vulnerabilità emerse durante il pen-test. Durante il penetration test potrebbero verificarsi dei disagi dovuti al lavoro del tester, si potrebbero avere perdite o danni ai dati o ancora una momentanea perdita di accessibilità. Ad esempio una macchina dedicata all'e-commerce potrebbe rimanere inaccessibile a causa di una simulazione di DoS, con conseguenze economiche dirette. O ancora, una azienda che fornisce servizi a terzi, potrebbe vedere i propri servizi interrotti con evidente disagio per i clienti.
Prima di cominciare il test bisogna concordare quale livello di rischio il committente è disposto a correre, invitandolo anche a fare un backup dei dati prima di effettuare il pen-test. Bisogna prevedere tali evenienze in fase di stipula del contratto, declinando per quanto possibile le responsabilità e garantendo però, allo stesso tempo, adeguate misure per il recupero del sistema.

Contratto (Regole di comportamento)

Il contratto deve indicare l'elenco dei test che verranno effettuati, lo scopo del penetration test e i rischi. Può tornare utile indicare anche i limiti entro i quali il tester deve muoversi, per limiti si intende: range di IP da testare, metodi e tool da usare, i tempi e le condizioni di avvio e completamento dei test. In alcuni casi, e per le tecniche che lo permettono, è utile indicare anche gli indirizzi IP delle macchine dalle quali partiranno gli attacchi, per isolare eventuali intrusioni da parte di terzi. È fondamentale, inoltre, regolare il trattamento delle informazioni raccolte durante il pen-test. La società esecutrice deve impegnarsi a a non divulgare a terzi le informazioni raccolte durante le attività relative ai test.
Da parte sua il committente deve dare pieno assenso alle attività di testing. Deve garantire inoltre il proprio impegno a mantenere la società esecutrice del test sollevata da tutte le responsabilità legali, nel caso in cui terzi dovessero considerarsi danneggiati dalle attività svolte durante i test. Prima di eseguire le operazioni viene comunque richiesto al committente una lettera di incarico in cui si autorizza Incipit a procedere con le operazioni di analisi. In questo testo sono chiaramente indicati gli indirizzi IP coinvolti nell'operazione e l'ampiezza dell'analisi. Questo documento tutela il cliente e autorizza Incipit ad eseguire le operazioni di controllo. Nella lettera di incarico deve essere unicamente indicato l'indirizzo IP o la sottorete che si intende controllare. Non devono essere forniti altri dettagli tecnici. L'analisi non deve infatti essere in alcun modo favorita da informazioni preliminari.
L'eventuale determinazione del sistema operativo installato sulla macchina target fa parte dei test eseguiti. Questa è infatti una delle informazioni più importanti in fase di attacco. Il test eseguito da Incipit cerca di ottenere questa informazione attraverso varie tecniche.
Una volta completati i test viene rilasciata una relazione dettagliata sullo stato dei sistemi e sulle modifiche necessarie per incrementare la sicurezza. In caso di falle di sicurezza vengono segnalate in un documento tecnico le patch e gli aggiornamenti che è necessario installare per mettere il sistema in sicurezza.Il controllo può essere eseguito una sola volta ma si consiglia di ripetere l'operazione con regolarità in quanto il database delle vulnerabilità note aumenta costantemente. Un controllo isolato può rendere un sistema più sicuro solo per un periodo di tempo limitato.

ControlloDegliAccessi
Tipo di problema che può consentire a determinati utenti di accedere a risorse o servizi, per i quali non dispongono di autorizzazione. Non di rado capita di non ritrovare alcun meccanismo di controllo degli accessi, dove invece dovrebbe essere implementato. Un meccanismo di controllo degli accessi valido deve rispettare i requisiti tipici di un “reference monitor”: ovvero dovrebbe essere tamperproof e dovrebbe essere verificabile.

DOSApplicativo
Difetti nel software che possono condurre gli utenti a non utilizzare appropriamente un applicazione o a renderla completamente inutilizzabile.

DOSApplicativo.Flood
Utilizzato negli attacchi di tipo “denial of service” che prevedono la saturazione di una risorsa condivisa tra più utenti, per esempio: CPU, banda, connessioni ad un database, memoria, ecc.

DOSApplicativo.Blocco
Utilizzato negli attachi di tipo “denial of service”,che prevedono l’utilizzo di una risorsa o di un limite allocato a un utente, come i tentativi falliti di login, i messaggi o le transazioni.

Autenticazione
Problemi che possono insorgere durante la procedura di identificazione degli utenti o di generiche entità (es: server), e nel processo di autenticazione.

Autenticazione.Entità
Utilizzato per problemi con sistemi automatici di autenticazione, come servizi web, database, directory ed altro. Alcuni esempi includono la memorizzazione sicura di credenziali, la messa in sicurezza del trasporto, il cambio delle credenziali e la chiusura d’accesso.

Autenticazione.GestioneSessioni
Utilizzato per problemi di creazione, d’uso protezione, cambio e terminazione di identificatori di sessioni di tutti i generi. Gli identificatori di sessione rimpiazzano le credenziali di autenticazione, ma sono ancora protetti in maniera adeguata.

Autenticazione.Utente
Utilizzato per problemi relativi all’identificazione ed all’autenticazione di persone che possono usare un’applicazione. Sono degli esempi i problemi con nomi utenti, password, token, smartcard, sensori biometrici, ed altre credenziali.

Autenticazione.GestioneUtenti
Termine usato per riferirsi a problemi collegati alla gestione degli utenti, specificatamente per le informazioni critiche da un punto di vista della sicurezzza, quali ruoli, autorizzazioni, privilegi, gruppi, codice fiscale, numeri di carte di credito, e altre informazioni sensibili; comprende anche le problematiche inerenti la creazione di nuovi utenti, di registrazioni a servizi, assegnazione di privilegi e accesso alle risorse.

BufferOverflow
Bug del software che può permettere ad un attaccante di sovrascrivere spazi di memoria allocata dai processi software, utilizzando ad esempio stringhe opportunamente formattate, e che può portare a modifiche nei dati , nel flusso del programma o anche a crash dell’applicazione.

BufferOverflow.Format
Errore dell’applicazione che può consente ad un attaccante di sovrascrivere spazi di memoria allocata dai processi software, tramite l’utilizzo di stringhe opportunamente formattate, consentendogli di modificare i dati , il flusso del programma o causare un crash dell’applicazione.

BufferOverflow.Heap
Errore del software che può permettere ad un attaccante di causare un overflow dallo spazio di memoria riservato per l’allocazione dinamica.

BufferOverflow.Stack
Errore dell’applicazione che può consentire ad un attaccante di scrivere dei dati nello stack di memoria, causando il crash dell’applicazione o il trasferimento del flusso di programma.

Concorrenza
Si presenta a causa di errori di progettazione degli ambienti multithread, e può portare alla condivisione non voluta o all’alterazione dei dati. Un caso comune è quello di variabili condivise tra più thread che causano problemi di time-of-check-time-of-use (TOCTOU) , violazione del pattern singletone, e errata gestione della cache.

GestioneConfigurazione
Termine usato quando ci si riferisce ai problemi collegati alle interfacce di configurazione delle applicazioni o degli ambienti applicativi.

GestioneConfigurazione.Amministrazione
Termine usato in riferimento a problemi collegati alle interfacce remote per le funzioni di amministrazione quali: gestione utenti, gestione delle credenziali, gestione dei database, ecc..

GestioneConfigurazione.Applicazione
Termine usato per riferirsi a problematiche relative alla configurazione delle applicazioni, ad esempio errate configurazioni delle funzionalità di sicurezza, , dei programmi di base, del codice non utilizzato e di funzionalità presenti ma non necessarie.

GestioneConfigurazione.Infrastruttura
Termine usato per riferirsi ai problemi connessi alla configurazione dell’infrastruttura applicativa, quali ad esempio webserver, application server, componenti di filtering, e strumenti per la sicurezza

Crittografia
Termine usato per riferirsi a problematiche connesse alla cifratura, decifratura, firma digitale e verifica della firma.

Crittografia.Algoritmo
Termine utilizzato in un contesto di selezione degli algoritmi crittografici ed di questioni di implementazione/analisi degli algoritmi.

Crittografia.GestioneChiavi
Usato in riferimento a questioni inerenti lo storage di certificati digitali e delle relative chiavi private, token crittografici, revoca dei certificati, key storage ed emissione delle chiavi..

ProtezioneDati
Termine usato per riferirsi ad una non appropriata divulgazione di dati.

ProtezioneDati.Memorizzazione
Termine usato per questioni inerenti il salvataggio in sicurezza di dati, comprendenti la memorizzazione di credenziali, chiavi crittografiche ed altre informazioni sensibili. Malfunzionamenti legati ai meccanismi crittografici consistono in sorgenti con randomicità non sufficiente, scelta errata di algoritmi, e cattiva implementazione.

ProtezioneDati.Trasporto
Termine usato ad indicare problemi nel trasferimento in sicurezza di informazioni. Generalmente si fa riferimento a problemi di configurazione di SSL e TLS, ma può anche riferirsi a generici protocolli di comunicazione aventi funzionalità di sicurezza.

GestioneErrori
Termine usato per riferirsi ad una cattiva gestione degli errori. In particolare la visualizzazione a schermo dello stack, fallimenti nell’attivazione di meccanismi di sicurezza o nel consentire che il verificarsi di determinati errori puntuali abbiano ripercusioni sul funzionamento globale dell’applicazione; infine nel divulgare a seguito di una condizione di errore informazioni non necessarie.

ValidazioneDatiInIngresso
Termine usato in contesti in cui viene a fallire il meccanismo di validazione dei messaggi di input provenienti da una fonte non fidata, con successivo processamento degli stessi da parte dell’applicazione a cui sono destinati.

ValidazioneDatiInIngresso.File
Si riferisce ai problemi nella fase di input validation, in cui l’input dell’applicazione è costituito da un file: file di configurazione, file batch, tracciati di database su flat-file o altri tipi di dati codificati su file.

ValidazioneDatiInIngresso.Utente
Utilizzato per riferirsi a problemi di input validation, ove l’input viene inserito da parte dell’utente: parametri di un richiesta HTTP, input a linea di comando o interazione tramite un interfaccia grafica.

ValidazioneDatiInIngresso.Rete
Termine utilizzato per riferirsi a problemi di input validation, in cui l’input proviene dai parametri di un protocollo di rete: header HTTP, numeri progressivi di protocollo o altri campi di protocollo.

Injection
Criticità in cui è possibile che un attaccante inserisca dei comandi non leggittimi nascosti all’interno di dati legittimamente destinati ad un sistema, che li eseguirà al ricevimento degli stessi.

Injection.HTML
Vulnerabilità che può permettere ad un attaccante di inserire dell’HTML in un’applicazione e di modificare l’apparenza dell’HTML generato da essa. Per esempio un attaccante potrebbe inserire un tag IMG non voluto in un guest book, ed offendere gli altri utenti.

Injection.ComandiAlSistemaOperativo
Vulnerabilità che può permettere ad un attaccante di inserire caratteri speciali e comandi nella shell di comando del sistema operativo e di modificarne il comando stesso. L’attacco può cercare di modificare come un programma viene richiamato o può tentare di concatenare comandi addizionali.

Injection.LDAP
Debolezza che può permettere ad un attaccante di inserire caratteri speciali e termini di ricerca in un server LDAP e modificare la query.

Injection.SQL
Vulnerabilità che può permettere ad un attaccante di inserire caratteri speciali e comandi in un database SQL e di modificarne la query. L’attacco può tentare di cambiare il significato della query o può tentare di concatenare comandi addizionali.

Injection.XSS
Vulnerabilità che può permettere ad un attaccante di inviare ed eseguire script nocivi attraverso applicazioni web. Gli attacchi XSS memorizzati registrano gli script nelle applicazioni web. Reflected XSS utilizzano un’applicazione web come “ponte” in tempo reale e richiedono che un’utente invii la richiesta contenente l’attacco

Monitoring
Utilizzato per problemi relativi al controllo delle policy di sicurezza di un’applicazione web.

Monitoring.Logging
Usato per problemi riguardanti il corretto log degli eventi, incluso ciò che dovrebbe essere “loggato”, come i log dovrebbero essere rivisti ed altri problemi relativi all’accounting.

Monitoring.Detenzione
Usato per problemi relativi al rilevamento di attacchi su di una applicazione, a come gli attacchi dovrebbero essere trattati, le informazioni che dovrebbero essere raccolte, e chi dovrebbe essere notificato.