Questo argomento è stato trattato in penTestEthicaHacking

Metodologie e framework

Esistono diversi framework che possono essere usati per svolgere un penetration testing ma, nel mondo reale, nessuno viene utilizzato in maniera esclusiva o nella sua totalità, favorendo l’utilizzo di una combinazione di metodi e framework.

CKC: Cyber Kill Chain

CKC è una metodologia sviluppata da Lockheed Martin per descrivere gli step necessari ad un threat actor per compromettere un sistema:

reconnaissance;
weaponization;
delivery;
exploitation;
installation;
command & control (C2);
actions on objectives.

Reconnaissance

Si tratta della fase in cui si spende la maggior parte del tempo nella fase di ingaggio del penetration testing; più tempo viene speso in questa fase, maggiore è la possibilità che il penetration testing abbia successo.

Questa fase include attività quali:

OSINT;
creazione dell’impronta (footprinting) delle reti e dei sistemi target;
identificazione dei meccanismi di protezione;
sorveglianza fisica delle infrastrutture;
identificazione di vulnerabilità potenzialmente sfruttabili.

Alla fine di questa fase sarà possibile creare una scaletta dei tipi di attacchi che si possono voler condurre.

È una fase essenziale in cui investire del tempo poiché, se condotta in modo frettoloso e con scarsa precisione, comporta uno spreco di risorse che deriva dal dover - eventualmente - sospendere la fase di attacco per tornare indietro e condurre nuovamente information gathering.

Weaponization

Dopo aver studiato il target e individuato potenziali vulnerabilità sfruttabili, si può passare alla fase di weaponization.

Si crea un payload progettato in modo specifico per attaccare una vulnerabilità specifica su uno specifico server con una specifica applicazione o servizio.

Possono esservi più vulnerabilità: in questo caso, non è necessario creare payload per ogni possibile exploit individuato nella fase di ricognizione.

Delivery

È la fase di “consegna” del payload al target. Si tratta di una fase complessa poiché si devono affrontare le contromisure in atto.

È possibile condurre questa fase con diversi mezzi, come email, stick USB e servizi e protocolli di rete.

Exploit

È un processo automatizzato nel penetration testing e riguarda l’esecuzione del payload sul sistema target. Se prodotto in maniera corretta, la vulnerabilità sarà automaticamente sfruttata.

Nel caso di penetration testing fisico, potrebbe essere richiesto l’accesso non autorizzato.

Installation

Un ulteriore processo automatizzato in cui il payload esegue dei comandi. È la fase in cui si installa il malware con lo scopo di creare un modo per comunicare e mantenere l’accesso al sistema attaccato.

La connessione eventualmente creata deve essere persistente rispetto ai riavvi; inoltre, un’altra sfida è quella di nascondere il malware da sistemi antivirus e antimalware.

Tool a supporto di questa fase sono Metasploit e MSFVenom.

Command and Control

In questa fase, ci si collega al canale di creazione creato durante la fase di installation.

È necessario assicurarsi di poter mantenere un accesso persistente al sistema violato.

Attraverso questo step, si può controllare remotamente il sistema con lo scopo di elevare i permessi e muoversi nella rete target.

Actions on Objectives

Questa fase dipende fortemente dalle abilità e dalla conoscenza del pentester affinché possa avere successo, in particolare dell’OS e di come l’exploit può essere usato da un utente locale per elevare i privilegi e sottrarre informazioni sensibili dai sistemi compromessi.

Raggiunta questa fase, è possibile tornare alla ricognizione e iniziare nuovamente l’attacco, contro lo stesso sistema o contro altri target raggiungibili.

Security Team Response

La metodologia CKC è concentrata sul personale di sicurezza e non sul penetester, suggerendo sei layer di controllo che possono essere implementati:

detect: determinare i tentativi di penetrazione di un’organizzazione;
deny: arrestare l’attacco mentre avviene;
disrupt: agire sulla comunicazione svolta dall’attaccante;
degrade: limitare l’efficacia di un attacco per minimizzare i suoi effetti;
deceive: fuorviare l’attaccante fornendo informazioni non corrette o reindirizzarli in maniera errata;
contain: contenere e limitare l’ambito dell’attacco in modo che sia ristretto solo ad alcune parti dell’organizzazione.

MITRE ATT&CK

ATT&CK è una matrice di tecniche e tattiche che riflette una natura non lineare e adattiva del comportamento di un avversario, senza un ordine operativo predefinito.

Si contrappone a CKC in quanto, quest’ultimo, pone l’enfasi su una progressione strutturata lineare e basata su un modello a fasi successive, in cui un attacco segue delle fasi predefinite.

PTES: Penetration Testing Execution Standard

Penetration Testing Execution Standard framework è una metodologia per il pentesting che include 7 settori:

pre-engagement;
intelligence gathering;
threat modeling;
vulnerability analysis;
exploitation;
post-explotition;
reporting.

Nist 800-115

Lo scopo di Nist 800-115 è quello di fornire linee guida per le organizzazioni sulla pianificazione e sullo svolgimento di test e valutazione tecniche sulla sicurezza delle informazioni, analizzando i risultati e sviluppando strategie di mitigazione.

Il penetration testing è una tecnica di validazione per la vulnerabilità del target (Target Vulnerability Validation Techniques) citata nel documento.

Macrofase 0: Planning

Pre-engagement

Nella fase di pre-engagement è selezionato il personale chiave, cioè quegli individui che sono cruciali nel fornire informazioni, coordinare le risorse e aiutare i penetration tester a comprendere l’ambito, la portata e le regole dell’ingaggio nella valutazione.

Questa fase include anche i requisiti legali, che tipicamente includono un Non-Disclosure Agreement (NDA) e un Consulting Services Agreement (CSA).

L’ambito di un penetration test (cioè le regole di ingaggio) definisce i sistemi che i tester possono o non possono attaccare, rimanendo nei confini del legale.

Vengono anche definiti i sistemi sensibili e gli indirizzi IP, così come gli orari di testing e quali sistemi necessitano di speciali finestre di testing.

Alcune domande possono aiutare nella definizione dell’ambito di un penetration test:

qual è la dimensione della rete esterna? (network penetration testing)
qual è la dimensione della rete interna? (network penetration testing)
qual è lo scopo del penetration testing? (qualsiasi forma di penetration testing)
quante pagine ha la web application? (web application penetration testing)
quanti input utente o form ha la web application? Questa lista non è esaustiva e tutti gli ingaggi dovrebbero essere stabiliti in modo rigoroso per essere certi che non si sottostimi o sottoprezzi l’ingaggio. Un template delle regole di ingaggio è fornito nell’appendice B del documento.

Macrofase I: Discovery

La fase di discovery del penetration testing include due parti:

la prima parte è l’inizio del test reale e include information gathering e scanning;
la seconda parte è l’analisi delle vulnerabilità, che comprende la comparazione di servizi, applicazioni, sistemi operativi degli host scansionati contro i database sulle vulnerabilità e la conoscenza del tester delle stesse vulnerabilità.

Information Gathering

Il penetration test include una fase di information gathering, che è fondamentale per garantire che i penetration tester abbiano accesso a informazioni chiave che possano assisterli nel condurre la valutazione. Tipicamente, si impiega un giorno o due per condurre una ricognizione estesa del target.

Maggiore è la conoscenza del target, più è possibile individuare superficie di attacco e punti di ingresso nelle reti e nei sistemi target.

L’information gathering è il primo step nel condurre un penetration test ed è la più importante. Alla conclusione di questa fase, si ottiene una mappa dettagliata della rete target e si comprende il quantitativo di sforzo richiesto per condurre una valutazione completa.

In più, in questa fase bisogna essere in grado di identificare i tipi di sistemi nella rete, incluso il sistema operativo, poiché è utile per rifinire lo staff e la selezione dei tool per il progetto. È uno step da condurre anche se il cliente fornisce informazioni a riguardo dei sistemi, anche se spesse volte sono errate.

L’information gathering può essere attivo o passivo. In modalità passiva, si cerca di ottenere quante più informazioni possibili sulla rete e sui sistemi target, senza connettersi direttamente (è anche utile ottenere informazioni aziendali, inclusa proprietà, localizzazione dell’azienda e dei target). In modalità attiva, ci si collega al target ed è pensata per meglio comprendere la portata dello sforzo, del tipo e del numero dei sistemi all’interno del progetto. Non è necessariamente vero che la modalità attiva sia più utile, poiché non è inusuale che si trovino archiviate fughe di informazioni, anche se corrette. Questo tipo di errori può essere beneficiale al test, specialmente se l’informazione è correlata alla rete.

La passive information gathering include la ricerca di informazioni quali: identificare la presenza sul web del target, ottenere informazioni da motori di ricerca sul target, cercare gruppi web che contengono commenti dell’organizzazione o di impiegati etc. Alla fine di questa fase, il penetration tester avrà una grande quantità di informazioni riguardo il target senza essere entrato nella rete del target, incluse informazioni che non dovrebbero essere disponibili. OSSTMM non suggerisce alcun sito per condurre questa indagine, mentre ISSAF raccomanda alcuni siti web.

La active information gathering troverà informazioni simili a quelle individuate mediante l’attività passiva. Il vantaggio di includere l’attività passiva è duplice: identificare informazioni storiche e confermare le scoperte con metodi attivi. L’ingegneria sociale è un modo molto efficace per ottenere informazioni su un target, anche più di condurre scansioni e tentare di sfruttare vulnerabilità. Le attività incluse in questa fase sono: interrogazione del DNS, identificazione del perimetro di rete e mappatura, ottenimento di credenziali potenzialmente utili.

Macrofase II: Attack

L’esecuzione dell’attacco è al cuore di ogni penetration test. La fase di attack è il processo di verifica di potenziali vulnerabilità identificata in precedente e il tentativo di sfruttarle. Se un attacco ha successo, la vulnerabilità è verificata e vengono identificate delle misure di sicurezza per mitigare l’esposizione associata.

Mentre gli scanner delle vulnerabilità controllano solo per la possibile esistenza di una vulnerabilità, la fase di attack di un penetration test sfrutta la vulnerabilità per confermarne l’esistenza.

Vulnerability identification: intro

In questa fase si sfruttano le informazioni raccolte per modellare le indagini e comunicare direttamente con i target, con lo scopo di individuare potenziali minacce e vulnerabilità. La vulnerability identification tipicamente prevede che i tester eseguano scansioni di rete (porte) o vulnerabilità per comprendere meglio quali servizi sono sulla rete o le applicazioni in esecuzione su un sistema e se ci sono vulnerabilità nei sistemi inclusi nell’ambito della valutazione. Questo processo incluse spesso la scoperta e il testing manuale di vulnerabilità, che è la più precisa forma di analisi e valutazione delle vulnerabilità. Esistono comunque degli strumenti per semplificare l’identificazione di vulnerabilità su una rete o sistema target.

Per comprendere quali tipi di vulnerabilità esistono su un sistema, è necessario conoscere specifiche sul sistema operativo, servizi disponibili sul server e informazioni sulla versione delle applicazioni. Ottenuti questi dati, si possono interrogare database che contengono vulnerabilità note per stabilire se il sistema target può essere vulnerabile ad attacchi, ma non si sfruttano exploit: si è solo in una fase di ispezione e quindi si verifica solo quali rischi possono esistere, ma non di provare la loro esistenza. Si possono anche esplorare diverse tecniche utilizzate per ottenere informazioni di sistema, come scansioni attive e passive (queste ultime evitano il rilevamento della scansione in corso, ma le scansioni attive forniscono informazioni più profonde, più velocemente).

Vulnerability identification: Port scanning

Quando si effettua un port scan, ci sono due obiettivi:

verifica dell’esistenza di un sistema target;
ottenimento di una lista di canali di comunicazione (le porte) che accettano connessioni.

Si desidera unicamente elencare quali porte sono aperte.

Prima di iniziare una scansione per le porte, è più prudente iniziare con la verifica dell’esistenza di un target. Il primo tentativo è l’uso di ping, che sfrutta ICMP.

Per il port scanning, si può usare nmap.

Su TCP sono basate la maggior parte delle applicazioni, dunque un penetration tester spesso utilizzerà TCP per la comunicazione. Il metodo più affidabile per verificare l’attività di una porta è il TCP connect scan (nmap -sT) che completa un three-way handshake TCP in modo completo. È possibile, però, che il firewall alteri i pacchetti, fornendo informazioni errate.

Lo svantaggio di usare una scansione basata su connessione TCP è che l’ammontare di traffico richiesto per confermare l’esistenza di un’applicazione è molto alto e può essere notato dagli IDS, mentre il vantaggio è che, al termine di uno scan TCP connect, si sa per certo se un’applicazione è presente o meno.

Un’alternativa è l’utilizzo di TCP SYN stealth scan (nmap -sS), che è la scansione di default per nmap. Diversamente da TCP connect scan, una scansione mediante SYN stealth crea una connessione aperta a metà, nel senso che, dopo aver ricevuto il SYN/ACK dal target, l’attaccante chiude la connessione con un RST. Si ottiene così una riduzione del traffico e, anche se aiuta contro gli IDS, il vero vantaggio sta nella velocità più alta nel caso bisogna scansionare più target.

Vulnerability identification: Perimeter Avoidance Scanning

Oltre al TCP connection scan e al TCP SYN stealth scan, esistono altri metodi per scansionare segmenti di sistema o di rete, evitando eventuali firewall, che sfruttano i bit di controllo:

ACK scan (nmap -sA): setta il bit ACK su 1, dunque invia un ACK al sistema target, con l’obiettivo di far credere al firewall che esista già un canale di comunicazione tra l’attaccante e il target;
FIN scan (nmap -sF): setta il but FIN su 1, condizione che accade solo alla fine di una connessione TCP stateful. Si cerca di far credere al firewall che un canale di comunicazione tra attaccante e target esista già, superando anche firewall stateless che tipicamente filtrano solo i pacchetti SYN ignorando i FIN;
Null scan (nmap -sN): un attacco “null” è quando tutti i bit di controllo del pacchetto TCP sono impostati a zero. L’obiettivo è quello di scavalcare firewall stateless (che filtrano solo pacchetti SYN e ignorano il resto) e cercare una risposta al pacchetto, preferibilmente, dal sistema target;
Xmas tree scan (nmap - sX): un tipo di attacco in cui tutti i bit di controllo sono impostati a 1, con l’obiettivo di scavalcare i firewall stateless che considerano solo i pacchetti SYN e ignorano questa anomalia poiché un pacchetto del genere per TCP non ha senso.

Una scansione simile può essere condotta anche sfruttando UDP, ma è più lenta e i servizi basati su UDP potrebbero rispondere a richieste di connessione solo quando il pacchetto in arrivo corrisponde con il protocollo atteso; dunque, una scansione UDP deve essere seguita da tentativi di connessione. Nonostante gli svantaggi, la scansione UDP è un componente essenziale, che può avere 1 tra 4 esiti:

open: è attiva una porta UDP;
open/filtered: nessuna risposta è stata ricevuta per la scansione;
closed: viene restituito il messaggio ICMP port unreachable;
filtered: viene restituita un messaggio ICMP diverso da port unreachable.

In particolare, con lo stato open o closed, si assume che il sistema target è attivo e ci si può comunicare direttamente; diversamente, c’è un’alta probabilità che un firewall o un IDS stia intercettando le probes.

Siccome le regole del firewall sono spesso scritte per prevenire attacchi TCP, le scansioni UDP sono qualcosa a cui gli amministratore di rete non pensano e, dunque, non filtrano. Se la scansione TCP non trova il sistema target, si può utilizzare una scansione UDP come metodo di follow-up per il rilevamento.

L’identificazione può avvenire anche passivamente, spostandosi sullo stesso segmento di rete del target e ascoltando i messaggi di rete che i sistemi si scambiano per rilevarli. Il vantaggio è che non bisogna inviare nessun pacchetto, consentendo di mascherare le reali intenzioni. Una volta determinato che il sistema sia attivo, si può procedere col passo successivo (quello di scoprire quali porte sono aperte, chiuse e filtrate sul target). Strumenti comodi per questa fase sono tcpdump e wireshark.

Vulnerability identification: System Identification

L’operazione di fingerprinting dell’OS può essere attiva o passiva:

active OS fingerprinting: strumenti come nmap possono scansionare un sistema e identificarne il relativo OS su diverse scoperte (incluso osservare quali applicazioni sono in esecuzione su un determinato OS);
passive OS fingerprinting: richiede pazienza poiché necessita della cattura di pacchetti TCP che contengono la lunghezza della finestra e informazioni sul TTL. Un’ulteriore tecnica è quella dell’ARP poisoning, che consiste nel forzare il sistema target a parlare con l’attaccante e inviargli il MAC, ma è una tecnica aggressiva che può causare denial of service.

Vulnerability identification: Services identification

Esistono due modi per identificare i servizi in esecuzione, col fine di ricavare informazioni sulla versione in uso e controllare la presenza di vulnerabilità note:

connessione con un servizio non noto su una data porta, con la speranza che l’applicazione risponda con informazioni sul servizio stesso^[Non è insolito che gli sviluppatori includano versioni dettagliate sull’applicazione, incluse informazioni sulla versione.];
cattura del traffico di rete in uscita dalla porta e analisi (implica lettura dello stack TCP/IP).

Exploitation

La fase di exploitation è la fase tipicamente più ignorata e trascurata del penetration testing, poiché ai clienti e ai dirigenti non interessa una vulnerabilità finché non capiscono perché dovrebbe importar loro; questo avviene mediante l’exploitation, che è l’evidenza che dimostra l’importanza della vulnerabilità e l’impatto che può avere sull’organizzazione. Senza l’exploitation, la valutazione non è un penetration test (si riduce ad una valutazione delle vulnerabilità) che un’organizzazione potrebbe condurre in-house e meglio di consulenti terzi.

In questa fase, si usa un exploit (codice malevolo, malicious code) per far leva su una vulnerabilità o debolezza in un sistema che consente di eseguire codice arbitrario sul target e ottenerne il controllo.

Vulenrability Verification

Uno dei principali problemi nella comprensione dello stato della sicurezza è determinare quali vulnerabilità sono reali e quali sono falsi positivi. Questa fase, in alcune metodologie, è chiamata Pen Test.

L’ISSAF prevedere 4 passi in questa fase:

trovare una proof of concept, in forma di codice o strumento;
testarla;
scrivere la propria proof of concept;
usare la proof of concept contro il target.

È fondamentale che il testing della proof of concept avvenga su un server di test prima di essere usata contro il target. Anche se si ottiene l’exploit da una fonte affidabile, non è possibile sapere cosa accade quando si lancia l’exploit, poiché due sistemi sono raramente identici (e si possono avere dei crash, perdita di dati e funzionalità etc).

OSSTMM include una sezione, titolata Controls Verification , in cui si elencano e si verificano le funzionalità operative delle misure di sicurezza sia del sistema che delle applicazioni sul sistema. L’attenzione viene rivolta a quattro aree di controllo:

non ripudiabilità: porre l’attenzione su problemi come metodi per l’identificazione e l’autenticazione, gestione della sessione e attività di logging;
confidenzialità: la verifica della confidenzialità riguarda i canali di comunicazione, la crittografia, l’offuscamento dei dati sul sistema, estesa anche alla connessione tra server e client;
privacy: l’esposizione dei dati riservati può danneggiare gravemente un’organizzazione e la sua credibilità. Quando si testano i controlli sulla privacy, si fa attenzione ai canali di comunicazione e l’uso di protocolli privati proprietari;
integrità: controlli sul sistema che includono manipolazione di database e modifica dei file.

Può succedere anche che non ci siano exploit noti per una certa vulnerabilità (semplicemente, si va oltre annotando la vulnerabilità e riconoscendo il lavoro svolto, mancando il tempo per creare un exploit dedicato) oppure un exploit già pronto non funziona, poiché scritto in maniera tale da non funzionare contro il target.

Strumenti che aiutano nella ricerca di exploit sono Nessun e Metasploit Framework.

Privilege escalation

Secondo ISSAF, la fase di privilege escalation contiene 4 possibili step:

gain least privilege;
gain intermediate privilige;
compromise;
final compromise.

Nonostante si possa logicamente assumere che, dato abbastanza tempo, ogni sistema possa essere compromesso, il tempo è una risorsa preziosa in un penetration testing professionale. È possibile che il sistema sia lasciato non compromesso alla conclusione di un penetration testing, poiché è troppo costoso trovare tutti i modi di exploitare un sistema.

Gli strumenti usati per ottenere privilegi addizionali su un sistema non sono ben definiti, rendendo più complicato sapere cos’altro si può fare contro un sistema target. La privilege escalation è un task troppo vasto perché ottenere l’accesso root può essere ottenuto usando una serie di approcci.

Una tattica per elevare i privilegi consiste nel cercare vulnerabilità aggiuntive in un sistema da una prospettiva interna: se si ottiene un qualsiasi accesso a un sistema, anche con autorizzazioni limitate, si potrebbero sfruttare vulnerabilità che sono accessibili solo come utenti loggati. In più, le difese per l’esterno sono spesso più robuste di quelle per l’interno, dunque, ottenendo un accesso a un sistema, anche a un livello ridotto di privilegi, può rendere possibile la compromissione dall’interno.

Un’altra tecnica per ottenere privilegi elevati può essere quella di ascoltare sulla rete dati sensibili, inclusi username e password. Se si può ascoltare tutto il traffico da e verso il target, si potrebbero ottenere dei dati che permetterebbero di accedere a un sistema con privilegi più alti: un esempio molto efficace è dato dall’ingegneria sociale.

Post-exploitation

Spesso, dopo aver exploitato un sistema target, si può pensare che il compito sia finito, ma non è così. Ci sono obiettivi da realizzare dopo essere entrati nel sistema e ciò costituisce la fase di post-exploitation.

L’exploitation è il processo con cui si ottiene accesso a sistemi che contengono informazioni sensibili. Il processo di post-exploitation è la prosecuzione di questo step, in cui l’appoggio ottenuto viene sfruttato per accedere a dati o diffondersi ad altri sistemi mediante movimento laterale (lateral movement) nella rete target.

Nella fase di post-exploitation, l’obiettivo principale è quello di dimostrare l’impatto che la vulnerabilità e l’accesso ottenuto possono avere sull’azienda.

Monitoring access

Una volta che si ottiene l’accesso a un sistema, bisogna fare in modo che l’accesso sia mantenuto. Non è raro avere delle finestre di manutenzione durante i penetration test: se parte della manutenzione programmata risolve le vulnerabilità sfruttate, l’accesso può essere terminato; questo può essere vero anche in caso di riavvio del sistema o perdita della connessione di rete.

In questo contesto, l’uso di backdoor è molto comune. Tuttavia, spesso c’è la necessità di aggirare gli ostacoli a difesa, come firewall e access control list. Le backdoor possono eludere queste difese, lasciando al professionista accesso non ristretto al sistema compromesso. Un altro vantaggio nell’avere accesso rapido alla macchina della vittima è che, una volta dentro la rete, l’ingegnere ha più libertà di scansionare e attaccare sistemi, poiché le difese di rete spesso controllano solo attacchi dall’esterno; in particolare, un attacco proveniente dall’interno della rete potrebbe non essere notato e, con l’uso della crittografia, l’attività potrebbe essere ulteriormente offuscata.

Macrofase III: Post testing activities

mitigation recommendations: per ogni scoperta dovrebbero essere sviluppate delle raccomandazioni di sicurezza per ogni causa. Le raccomandazioni possono essere tecniche e non tecniche, volte a migliorare i processi dell’organizzazione (modifiche ai processi dell’organizzazione, cambiamenti all’architettura di sicurezza, utilizzo di nuove tecnologie di sicurezza… fanno tutti parte delle raccomandazioni);
reporting: dopo aver completato l’analisi, è opportuo generare un report che identifichi i sistemi, le reti e le vulnerabilità delle organizzazioni e le possibili mitigazioni raccomandate. I test di sicurezza dovrebbero essere documentati e resi disponibili allo staff dedicato. Con questo in mente, potrebbe essere opportuno adottare più formati per il report, in modo che ciascuna parte coinvolta possa comprendere e risolvere il problema.

Covering tracks

Per avere successo nell’exploitare un sistema in modo completo, bisogna evitare il rilevamento. A questo punto del test si sono evitati con successo il rilevamento di apparecchiature difensive come firewall e IDS; ora serve evitare il rilevamento mentre si è all’interno del sistema expoitato.

Gli amministratori di sistema possono esaminare file di log, installare applicazioni che controllano la presenza di software malevolo e configurano dei monitor per flussi di dati non autorizzati; inoltre, possono controllare i processi in esecuzione per controllare che non vi sia niente di inappropriato in esecuzione e rinforzare i sistemi in modo che cambiamenti essenziali ai file di sistema siano prevenuti e notificati.

Ci sono due tipologie di log: system-generated logs e application-generated logs. Esistono due tipologie per manipolare i dati: cancellare l’interno log o modifcarne il contenuto.

Eliminare i log garantisce che l’attività sia non tracciabile e renderebbe estremamente complicato tentare di ricostruire l’attacco sul sistema ed è un buon approccio se si ha bisogno di nascondere tutte le tracce su chi si è e da dove si viene. Tuttavia, eliminando un file di log, specialmente di sistema, si hanno delle ottime possibilità che gli amministratori lo notino: sparizione improvvisa o dimensione inesatta sono dei campanelli dall’allarme della presenza di un utente malevolo.

La seconda opzione è quella di alterare i log cambiandone i dati all’interno. Se si cerca di nascondere il tentativo di aumentare i privilegi su un server, una volta avuto successo, si possono rimuovere tutti i dati nel log relativi all’attacco. Tuttavia si può non cancellare tutto oppure cancellare troppo e creare dei buchi nel log che possono essere notati.

Un ulteriore spunto viene dato dalla necessità potenziale di aggiungere file e script nel sistema da sfruttare: se non fatto con attenzione, un amministratore di sistema potrebbe trovare gli script e arrestare l’attacco. Si possono nascondere i file a vista oppure lasciare operare la struttura del sistema operativo.

Report writing

La fase di report writing è autodescrittiva. Il penetration testing è il servizio, il report è il deliverable che il cliente vede ed è l’unico elemento tangibile dato al cliente alla fine del compito; dunque, i report devono ricevere la stessa attenzione del testing.

L’attività di report non consiste semplicemente nel listare le vulnerabilità individuate nella valutazione, ma è un mezzo attraverso il quale si comunicano i rischi e l’impatto sul business, si riassumono le scoperte e degli step di rimedio. Un buon penetration tester deve saper scrivere i report, altrimenti i problemi trovati possono andare persi e mai compresi dal cliente.

I report dettagliano le scoperte sia ad alto livello, sia fornendo spiegazioni di basso livello per ripetere gli exploit. Entrambi includono sia i falsi positivi che le vere scoperte; tuttavia, occorre essere totalmente sicuri che ciò che viene scritto nel report sia corretto. Inoltre, anche se una minaccia viene mitigata prima del report finale, la sua scoperta deve essere comunque annotata nel report. Vanno inclusi nel report anche tutte le falle sistemiche nell’architettura in generale (dove per falla sistemica nell’architettura si intende più una supposizione che qualcosa basato sui fatti^[L’esempio può essere rappresentato dall’uso di password deboli: magari solo la macchina attaccata ne utilizzava una.]).

Nel report va incluso anche quello che non è stato trovato (discussione dei falsi positivi che possono comunque preoccupare il cliente); si tratta di una considerazione (quella di riportare ogni cosa) che rende il cliente in grado di comprendere la totalità delle difese e della sicurezza e non solo le sue debolezze.

È bene ricordare anche che si possono includere delle informazioni sensibili nel report finale; dunque, considerando che molte persone avranno accesso al report, le informazioni sensibili debbano essere pulite e sanificate prima di essere incluse nei report.

Report writing: initial report

Completato il penetration test e raccolte le informazioni pertinenti, si crea un report iniziale, che deve essere trattato come se fosse il report finale (e non una bozza). Tipicamente si adottano delle linee guida professionali.

È opportuno che tutte le vulnerabilità e gli exploit discussi siano ripetibili e che il metodo usato per fare l’exploit di un sistema sia molto dettagliato, siccome gli amministratori di sistema ripeteranno gli step del test per validare da parte loro gli exploit.

Report writing: Peer Reviews e Fact Checking

Prima di rilasciare il report al cliente, potrebbe essere opportuno svolgere della peer review. Se alcuni fatti sull’architettura, sistema o applicazioni non sono chiari per la mancanza di dati dal cliente, il passo successivo nel report iniziale chiarisce ogni confusione. Una volta che il report iniziale è scritto e revisionato (peer reviewed), può essere offerta al cliente la possibilità di verificare l’accuratezza dele informazioni (ogni valutazione deve includere i rappresentanti del cliente, come dirigenti di alto livello, rappresentanti dell’area funzionale, senior system managers e senior Information Security (INFOSEC) managers).

Si può creare una lista di domande sul report cui bisogna rispondere e si può inviare una copia del report iniziale al client, in modo che possano verificare tutte le affermazioni nel documento. Poiché è ancora in una fase iniziale, rilasciare il documento subito può essere rischio, poiché le conclusioni e le raccomandazioni possono cambiare su input del cliente in merito al fact checking. Il vantaggio di inviare l’intero report iniziale è che il cliente può revisionare l’accuratezza di tutte le scoperte e non solo quelle dove non è chiaro qualcosa.

Report Writing: Final Report

Per la stesura del report finale si può ripetere il processo di peer review, ma il compito più grande sarà quello di preparare il report da consegnare al cliente.

Gli amministratori di sistema possono migliorare la sicurezza del sistema esaminando i file di log dal sistema exploitato che corrispondono agli eventi sfruttati elencati nel report finale.

Quando si crea un documento che dettaglia i sistemi vulnerabili bisogna garantire la confidenzialità e l’integrità del report finale.

Non c’è un metodo accettato dal settore per presentare le scoperte al cliente, dunque si è liberi di creare il report nel formato che si ritiene opportuno; tuttavia, ciò che si preferisce potrebbe non essere quello che il cliente si aspetta.

Occorre conservare i dati?

Durante un progetto di penetration testing, molta documentazione viene salvata dagli ingegneri, la cui maggior parte non deve essere conservata alla fine del test se non per motivi specifici. Se la decisione è di conservare dati del penetration testing (anche solo il report finale), ci sono dei problemi alla sicurezza che devono essere risolti, come il controllo dell’accesso, modalità di conservazione, luogo dei dati conservati e politiche per la distruzione.

Esistono due scuole di pensiero: conservare tutto o conservare niente. Se un ingegnere trova evidenze di attività illegali nel corso di un penetration test, ci sono possibilità che l’ingegnere sarà chiamato come testimone se il caso dovesse finire in tribunale. Avere documentazione dettagliata su tutti gli step compiti dall’ingegnere nel corso del test riduce la possibilità di errore.

Se si usa la full-disk encryption per mettere in sicurezza i dati di un test, si può usare il meccanismo di controllo degli accessi disponibile nel sistema operativo host per ridurre l’accesso ai dati. Ogni procedura di conservazione deve verificare che i dati siano trasferiti in modo consono e possano essere ripristinati. La distruzione dei dati dovrebbe rispettare linee guida governative, a seconda del dato e da dove è stato ottenuto.

Se un laboratorio solitamente identifica e sfrutta vulnerabilità zero-day, allora avrà requisiti di conservazione diversi rispetto a quelli che identificano exploit pubblicamente disponibili. Se si conservasse una virtual machine, si può semplicemente salvare lo stato corrente del sistema con poco sforzo; la stessa cosa non può essere detta per gli ambienti non virtuali, per cui potrebbe essere necessario conservare l’interno sistema poiché non si può essere sicuri su cosa abbia modificato il malware.

Prima di creare una macchina virtuale o immagine è necessario includere le questioni relative alle licenze nelle decisioni su come archiviare il nostro laboratorio (inteso come “playground”, ambiente di test). Malware più avanzati provano a rilevare l’ambiente di sistema prima dell’esecuzione e non venire eseguite in macchine virtuali. In questo contesto, l’uso di ghost images consente di risparmiare tempo per la creazione dell’ambiente.

Se non si sanifica il laboratorio alla fine del penetration test possono rimanere delle informazioni sensibili del cliente sul sistema. È difficile distinguere immagini virtuali tra di loro; se si usano le immagini di server, si devono generare i nostri valori hash e aggiungerli alla lista degli hash usati nel laboratorio di test.

(╯°□°)╯︵ 💻

Esplora

2. Eseguire un Penetration Testing