Cos’è un Penetration Test

“Un penetration test, occasionalmente pen test, è un metodo per la valutazione della sicurezza di un sistema informatico o di una rete simulando un attacco da parte di attaccanti esterni (che non hanno di norma accesso ai sistemi informatici) e/o di attaccanti interni (che hanno un qualche livello di accesso autorizzato ai sistemi)”

Così il CREST [1] – un organizzazione no-profit di base inglese per il supporto al  mercato della sicurezza informatica definisce i penetration test. La stessa CREST mette in guardia sulla questione penetration test: spesso sui penetration test si usano molte parole “alla moda”(altrimenti “buzzword”) che possono creare confusione: per esempio ethical hacking, tiger teaming, vulnerability analysis, assessment ed assurance. Ma qual è il significato reale di questa definizione?

Il penetration test è un metodo

E per essere eseguito esistono diverse di metodologie riconosciute a livello internazionale. Tra le metodologie più utilizzate troviamo:

  • SP-800-115 del NIST (National Institute of Standards and Technology), del Governo americano [2].
  • OSSTMM dell’ISECOM (Insitute for Security and Open Methodologies), una no-profit internazionale [3]. Sviluppato da Pete Herzog [4].
  • Testing Guide di OWASP, una no-profit internazionale [5] (per la serie “italians do it better” il Project Lead è l’italianissimo Matteo Meucci 🙂 [6]).
  • PTES, di un gruppo di consulenti che hanno descritto una metodologia generica estremamente utile [7].

Tutte le metodologie sono importanti e hanno delle aree di sovrapposizione ma anche delle peculiarità. Un buon Penetration Tester sa combinarle correttamente. A livello metodologico il NIST descrive inoltre un concetto a cui spesso viene data poca importanza: il Penetration Test – per sua natura – è un processo iterativo e non ha un andamento lineare. Ogni volta che si hanno maggiori informazioni sul bersaglio queste vengono riutilizzate e si reitera su quanto già fatto. Non a caso Offensive Security [8] definisce il penetration test come:

“un ciclo continuo di ricerca e di attacco”

Ciclo tra la fase di ricerca e la fase di attacco

Fasi tecniche di un Penetration Test secondo il NIST SP-800-115

Strumenti per il penetration test

E’ estremamente importante notare come la definizione si focalizzi sul metodo e non sullo strumento, che invece è una domanda classica quando si parla di penetration test, anche durante i colloqui. Il penetration test non è un attività in cui lo strumento fa da padrone e non è un caso. Se pensiamo alle minacce “avanzate e persistenti” (meglio identificate come APT – che tratteremo nel Blog) il problema non sono solo gli strumenti  (per esempio i Remote Access Trojan, che comunque ci danno un idea di chi abbiamo di fronte) ma le persone che ci sono dietro e che comandano questi strumenti. Tendenzialmente un Penetration Test su una rete si può fare tranquillamente con netcat, e un Penetration Test su un applicazione web con curl – per non citare sempre netcat 🙂 – anche se così richiederebbe molto più tempo di quello a disposizione. Sulla questione degli strumenti Charlie Miller [9] (ex NSA, vincitore del Pwn2Own, si occupa attualmente di vulnerabilità su autoveicoli) – nella prefazione a Black Hat Python di Justin Seitz [10]- si esprime così:

“Ricordatevi, la differenza tra uno script kiddie e un professionista è la differenza tra chi meramente utilizza gli strumenti di altri e chi scrive i propri”

In generale quindi il test è un’attività più che altro artigianale che, seguendo delle metodologie flessibili, viene “cucita” ed adattata secondo l’attività specifica e il bersaglio specifico, il che comprende anche la creazione di strumenti specifici e/o di exploit per l’occasione. Non è un caso che l’ISECOM indichi che un team di penetration tester dovrebbe comprendere persone con diverse specialità, e che parte del tempo di ogni tester dovrebbe essere dedicato alla ricerca di nuovi attacchi, tecniche e procedure se non alla scrittura di strumenti.

Compliance, rischi e penetration test

Tornando alla definizione di penetration test, lo scopo è appunto la valutazione della sicurezza – quindi verificare se ci sono problemi in un sistema informatico, possibilmente prima che un attaccante malevolo li sfrutti e come indicato nella SP-800.115:

  • Quanto il sistema testato tolleri scenari di attacco reali.
  • Il livello di sofisticazione che un attaccante deve utilizzare per compromettere un sistema.
  • Trovare ulteriori misure aggiuntive di sicurezza.
  • La capacità dei difensori di individuare e reagire all’attacco.

Anche se la necessità di un penetration test può nascere da un requisito di compliance (p.e. ISO 27001, PCI-DSS) lo scopo è quello di comportarsi come un attaccante e trovare se ci sono dei modi – anche se per un incrocio astrale funzionano solo su quel sistema o per quella situazione – per poter compromettere la sicurezza del bersaglio. In generale – è più conveniente che queste problematiche vengano trovate durante una simulazione rispetto ad uno scenario di Incident Response dopo che qualcuno le ha sfruttate. Sulla compliance la CREST ci ricorda che:

“La compliance è una cosa diversa dalla sicurezza e indipendente da essa. E’ possibile essere compliant e non sicuri, ed essere relativamente sicuri e non compliant

Questo concetto ha un riscontro molto pratico nella vita della Sicurezza in particolare quella a livello “Enterprise”. Facciamo un esempio. Supponiamo che un Penetration Test abbia dimostrato la presenza di alcune vulnerabilità di severità alta/critica. Supponiamo anche che – per diverse questioni – il rischio collegato a queste vulnerabilità venga analizzato, ponderato e considerato accettabile (secondo la propensione al rischio dell’organizzazione). Il risultato è che le vulnerabilità non vengono corrette ma si  è compliant. Quindi si lascia comunque la “porta aperta” ad un attaccante “accettando” il suo potenziale attacco. Ad un attaccante infatti non importa se è stato accettato il rischio di una vulnerabilità (magari su un sistema vecchio e che è difficile da manutenere). Gli interessa se c’è, se c’è la usa e ne trae vantaggio. Punto. (tratto da una storia vera.. 🙂 ).

Quando si fanno queste analisi è prassi considerare la probabilità che la vulnerabilità venga sfruttata. Però nel panorama attuale e secondo la stessa definizione di Cyber Security di ISACA [11] nel 2017, non ci si può solo focalizzare su quei rischi ad impatto e a probabilità alta. Devono anche essere considerati rischi meno probabili ma ad impatto alto e tutte quelle vulnerabilità che un attaccante motivato trova e sfrutta (tornando al 2017, ovviamente non si può scrivere di penetration test e non usare almeno una volta la parola “Cyber” 🙂 ). Come diceva nel 2012 Robert Mueller, il direttore dell’FBI:

ci sono due tipologie di aziende [ma meglio dire organizzazioni] quelle che sono state compromesse e quelle che lo saranno

Questo succedeva 5 anni fa. Ora nel 2017 è piuttosto probabile che ci abbiano già attaccato. Ce ne siamo accorti? Altro aspetto importante: quando si accettano i rischi bisogna anche considerare che un applicazione o un sistema – di solito – non “vivono” totalmente isolati dal resto dell’organizzazione e pertanto, se vengono compromessi, posso fungere da testa di ponte per dei movimenti laterali e sfruttando le relazioni di fiducia tra quei sistemi. Per esempio: un attaccante potrebbe compromettere un applicazione esposta su internet, prendere il controllo il sistema e usarlo per attaccare, da una posizione privilegiata essendo sulla rete interna, altri sistemi non necessariamente esposti. Attività tipiche di Post-Exploitation, Privilege Escalation e Pivoting, per quanto non sempre vengano incluse in un Penetration Test, sono all’ordine del giorno degli attacchi”reali”.

I bersagli di un penetration test

Ma cos’è un sistema informatico? E quindi cosa può essere l’oggetto (detto anche bersaglio) di un Penetration Test? L’OSSTMM (Open Source Security Testing Methodology Manual) – sviluppato dall’ISECOM – ci viene in aiuto. L’OSSTMM v3 definisce una serie di canali e vettori sui quali un’attività può essere svolta:

  • COMMSEC (Sicurezza delle Comunicazioni): Data Networks e Telco,  che l’OSSTMM utilizza per indicare i test a livello di reti informatiche (di dati) e telecomunicazioni (e.g. telefonica)
  • SPECSEC (Sicurezza dello Spettro / Segnali): Wireless, che l’OSSTMM utilizza per indicare i test a livello wireless e sui segnali (come anche i test Tempest)
  • PHYSEC (Sicurezza fisica): Physical – quindi la sicurezza fisica – e Human – che comprende gli aspetti psicologici e delle persone, che l’OSSTMM utilizza per indicare i test a livello fisico e quelli relativi alla sicurezza delle persone.

Inoltre nell’OSSTMM v4 sarà probabilmente compresa l’area APPSEC con al suo interno gli aspetti Mobile, Web e IoT.

Si può o meno essere d’accordo con questa definizione di vettori e canali, ma il concetto di fondo è che tutto può essere oggetto di Penetration Test. Inoltre una problematica anche in uno solo di questi aspetti, spesso se combinata in maniera opportuna, può comportare diversi danni. Un attaccante motivato non si farà problemi nell’utilizzare il canale più semplice, efficace e conveniente per arrivare al suo obiettivo.

Se è più semplice compromettere un web server su internet si passerà da li per arrivare alla rete interna, se è tutto isolato si lasceranno delle chiavette USB nel parcheggio dell’organizzazione bersaglio, se il parcheggio dell’organizzazione è protetto allora si infetteranno le chiavette USB rivendute nei dintorni. Questa storia non è inventata: è la strategia documentata da Fred Kaplan [12] in “Dark Territory” relativamente ad un attacco alla base Americana a Kabul, nel 2008.

Commsec, Specsec, Physec e Appsec

Classi e Canali dell’ISECOM OSSTMM

Penetration test interni o esterni, bianchi o neri

L’ultima parte non meno importante della definizione riguarda un fatto: il test può essere eseguito sia dall’interno (in caso di simulazione di un attaccante che si trova all’interno dell’infrastruttura oggetto del test) che dall’esterno (per simulare un attacco dall’esterno del “perimetro” dei nostri sistemi) – definito dall’OSSTMM come vettore. Questa definizione inoltre si collega ad un altro aspetto: la quantità d’informazioni condivise tra attaccanti e bersaglio – definiti come  tipi di test dall’OSSTMM. Questo aspetto viene solitamente classificato attraverso una scala di grigi e pertanto un penetration test può white, gray e black box. All’estremo più bianco (o Tandem) si condividono le informazioni mentre all’estremo più nero non ci sono informazioni condivise fino al punto che il test potrebbe essere usato per valutare il sistema difensivo del bersaglio. Non esiste una tipologia di test migliore in assoluto, dipende sempre dall’obiettivo del test e dal budget a disposizione.

Penetration Test Black Box, Blind, Gray Box, White Box, Crystal Box, Reversal

Tipi di Test secondo l’OSSTMM

 

Riferimenti

[1] http://www.crest-approved.org/

[2] http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-115.pdf

[3] http://www.isecom.org/research/

[4] https://twitter.com/peteherzog

[5] https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents

[6] https://twitter.com/matteo_meucci

[7] http://www.pentest-standard.org/index.php/Main_Page

[8] https://www.offensive-security.com 

[9] https://twitter.com/0xcharlie

[10] https://twitter.com/jms_dot_py

[11] http://www.isaca.org/Knowledge-Center/Blog/Lists/Posts/Post.aspx?ID=296 

[12] https://twitter.com/fmkaplan 

Leave a Reply

Your email address will not be published. Required fields are marked *