Test esterno di penetrazione da parte di terzi

Non otterrai davvero buoni risultati, un approccio del genere è davvero appropriato per un pentito ma più per un test di Red Team / Tiger Team in cui sono impostate le bandiere (onestamente queste non sono appropriate se non hai mai avuto un pentest perché tu Diventerai molto demotivato e spenderai una grande quantità di budget perché è piuttosto dispendioso in termini di tempo). Per un pentest tu preferibilmente definisci o permetti loro di definire diversi scenari che devono essere testati dal punto di vista di diversi tipi di utenti:

• autenticato (può essere diverso tipo di privilegio)
• autenticato

Limiti i sistemi in ambito e descrivi il test DoS in particolare poiché questo è il tuo primo set di pentests. Richiedi una panoramica di tutte le vulnerabilità rilevate classificate e ordinate in base al loro impatto, probabilità e valutazione complessiva del rischio.

Un sistema non è considerato vulnerabile solo perché puoi diventare root, un sistema è vulnerabile alle vulnerabilità ciascuna con la propria valutazione del rischio. Si noti inoltre che un sistema che ha un basso rischio di vulnerabilità può, a causa delle informazioni raccolte, contribuire a compromettere un altro sistema.

Normalmente definisci un intervallo di tempo, a seconda delle dimensioni della tua rete o del tuo sito web, in cui dovrebbero funzionare. Normalmente puoi discutere dell'ambito e le tue diverse parti ti diranno ciò che ritengono opportuno per l'ambito. Tieni presente che poiché esegui un pentest di rete, non significa necessariamente che tutti i tuoi siti web siano inclusi nell'ambito.

Preferisci anche fornire informazioni sulla tua rete, è un pentito, significa che è limitato nel budget e nel tempo. I veri aggressori hanno più tempo e spesso non sono vincolati economicamente. Pertanto, per ottenere i risultati migliori, eseguire un test della casella grigio o bianco in cui si forniscono informazioni ai tester come gli intervalli di rete e le funzioni dei vari server.

Assicurati di limitare anche lo sfruttamento dei server di produzione. Dovresti assicurarti che nessun server di produzione sia sfruttato senza la tua previa autorizzazione. Questo per garantire che non si arrestino durante l'orario lavorativo.

La mia preferenza personale per il rapporto è la seguente:

• Ambito di applicazione
• Riepilogo gestione
• Riepilogo tecnico
• Scenari di attacco (appropriati se diverse vulnerabilità portano a compromettere un host)
• Risultati classificati per vulnerabilità con un elenco di host vulnerabili che descrivono dettagliatamente la vulnerabilità, il rischio, la raccomandazione e i riferimenti. I risultati dovrebbero essere fatti in modo tale che anche qualcuno con una conoscenza pentest limitata possa riprodurre il risultato. Dovrebbero essere fornite ampie prove, come esempi di schermate, richieste, risposte, ...

Generalmente lo "scope" non dice qualcosa come "Non puoi radicare le macchine", come cliente vuoi sapere se questo è possibile IMHO. Una volta che l'accesso alla root è stato acquisito, in pratica è fondamentalmente il gioco.

Ciò che l'ambito dovrebbe dire è la quantità di server e i relativi nomi / IP del server e che la valutazione è limitata solo a questi dispositivi. Questo per evitare che, una volta compromessa una macchina, i consulenti di sicurezza inizino a lavorare sul resto della rete.

Supponiamo che ci sia un buffer overflow in un demone o un'applicazione. Vorresti che passassero del tempo sfruttando questo buffer overflow o trovando più vulnerabilità?

Generalmente, in qualità di consulente per la sicurezza, spiegherò la situazione al client che, con un tempo sufficiente, il buffer overflow potrebbe molto probabilmente essere sfruttato. Chiederò se vogliono che continuiamo a sfruttarlo oa passare il tempo a guardare altre parti del sistema.

Inoltre, segnaliamo immediatamente vulnerabilità elevate e critiche e valutiamo quotidianamente i risultati.

Parla con il / i consulente / i su base giornaliera, la comunicazione è la chiave qui (qualcosa che i consulenti dovrebbero fare nei confronti dei loro clienti comunque IMHO).

Come tester di penetrazione, questa formulazione è esposta nella Dichiarazione di lavoro, tuttavia, come tester, non raccomando che il tester interrompa il test una volta ottenuto l'accesso. Lo scopo di un test di penetrazione è di ottenere un accesso molto simile a come un utente malintenzionato potrebbe ottenere l'accesso. Fermando il test, non si può mai sapere cos'altro è sfruttabile. Diamo un'occhiata a quanto segue:

pentest

Yournetwork 172.16.1.0/24

Indichiamo che il tester inizia a 172.16.1.0 e ha accesso a 172.16.1.10, il tester trova una macchina altamente sfruttabile, ottiene il controllo completo e interrompe il test. Di cosa hai beneficiato se 244 macchine non fossero state testate?

Uno dei maggiori ostacoli che noi (tester) affrontiamo è che a volte siamo limitati in ciò che possiamo testare e come possiamo testarlo. In generale, mirano a utilizzare exploit affidabili che non influenzano la rete di un cliente (servizi di crash, causa smentite di servizio). Molte volte le tecniche che un attaccante in buona fede userebbe sono del tavolo per me. Ad esempio, concatenare gli exploit, dove posso trovare uno script cross-site (XSS) di basso livello, ma l'unico modo per sfruttarlo è aggiungere un vettore di ingegneria sociale (inviare via e-mail al dipendente un link).

Ci sono pro e contro con i pentests, e lo standard: "Mira a uno strumento in questo blocco di rete, se non riesci ad entrare, siamo al sicuro" non funziona mai. Questo perché il test è una pistola carica. Come tester professionista, so che non posso fare qualcosa per interrompere le tue operazioni, quindi non lo avrò. Un attaccante in buona fede non ha intenzione di affermare: "beh, se eseguo questo exploit, potrei mandare in crash il suo sistema ... Meglio di no" o "beh, questo è solo un attacco XSS ... Meglio non usarlo in un messaggio di posta elettronica "o" Ho trovato la prima macchina sfruttabile ... dovrei smettere di sfruttare il resto della rete ". Al contrario, un utente malintenzionato eseguirà qualsiasi exploit desiderino, non gli interesserà se si bloccherà qualcosa e concatenerà gli exploit.

Preferisco eseguire blackbox interni (qualsiasi cosa vada) test dall'interno. Con e senza credenziali contro test remoto. Questa è una logica semplice: "Supponiamo che ce l'abbiano fatta davanti alla porta ... Cosa possono fare?" Ciò mi consente di avere il cliente a determinare la sua postura di sicurezza dall'interno verso l'esterno, dove i test esterni vengono eseguiti DOPO. Ho scoperto che questo approccio produce risultati molto migliori rispetto al licenziamento a un IP esterno.

Inoltre, a seconda della tua struttura, ho incontrato troppi provider di hosting di terze parti. Questo è il punto in cui l'infrastruttura Web del cliente viene visualizzata su Amazon o su un altro provider di hosting, a cui non è possibile eseguire il test, poiché i provider di cloud non controllano i test di penetrazione. Quindi probabilmente otterrai un rapporto distorto.

Il mio consiglio è, se hai intenzione di far testare qualcuno, dovrebbe essere tutto o niente. I tester più competenti sono consapevoli delle insidie che ho menzionato qui. La maggior parte dovrebbe già sapere: "non userete mai gli exploit che manderanno in crash qualcosa", quindi saranno loro i responsabili. Tuttavia, non smetterei di eseguire i test e otterresti un maggior numero di tentativi per eseguire test interni (ciechi e con credenziali), seguiti da test esterni.

I PenTest hanno un "ambito" ad essi associato che tu definisci come cliente. Definisci quanto vuoi che vadano e quali sono i criteri di successo.