PENETRATION TEST

Penetration Test

Penetration Test

 

Oggi giorno tutto e’ e sara’ sempre piu’ connesso o interconnesso in rete, dalle nostre vite sociali, ai dati aziendali fino all’ultima frontiera rappresentata dall’Internet delle Cose IoT, che è un neologismo riferito all’estensione di Internet al mondo degli oggetti e dei luoghi concreti.

Tutto questo scambio continuo di dati (foto, login, codici…) richiede che le aziende incaricate di mantenere al sicuro i nostri dati piu’ importanti debbano essere sempre preparati dal pericolo sempre maggiore di un’intrusione, in effetti il comportamento non sarebbe diverso da una squadra di vigili del fuoco che si allenano costantemente simulando ogni tipologia di situazione cosi da sapere sempre cosa fare, come risolvere e se possibile come prevenire un disastro.

Una delle metodologie a cui dovrebbero affidarsi i team di sicurezza interni, o tramite specifiche consulenze, sono i cosidetti PENETRATION TEST.
Che cosa s’intende quando si usa questo termine? 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 in modo fraudolento al sistema. Un pen-test dunque 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, il cosidetto “tuning“, che incidono sulla robustezza e le performance del sistema, e gli errori di progettazione della rete. Non a caso, a volte una cattiva configurazione è più pericolosa di un bug.

Questa e’ una lista sintetica che descrive cio che un pen-tet cerca d’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.

Una volta portato a termine il test, tutti i problemi di sicurezza rilevati vengono presentati al cliente o alla propria direzione informatica 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 ci fornisce quindi una stima chiara sulle capacità di difesa e del livello di penetrazione raggiunto nei confronti di problematiche quali:

  • vulnerabilità interne al sistema;
  • vulnerabilità esterna al sistema;
  • difetti sicurezza fisica

Quali sono le modalita’ in cui i Penetration Tester svolgono il loro ruolo ??
I processi di penetration test possono essere effettuati in diverse modalità. La differenza consiste sulla quantità e qualità delle informazioni disponibili a coloro che devono effettuare l’analisi riguardo ai sistemi analizzati. I processi di analisi che vengono condotti in un penetration test hanno diversi tempi di azione in cui vengono 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. Subentrano cosi nell’equazione i Penetration Tools che, uniti all’esperienza manuale dell’analista permettono quindi di evidenziare tutte le possibili vulnerabilità, incluse quelle più recenti e, a volte, alcune ancora non di pubblico dominio. I problemi riscontrati sono quindi manualmente verificati.

L’attività si considera conclusa una volta portata a termine la 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.

Va aggiunto per maggiore chiarezza che il penetration test va effettuato su sistemi esposti su Internet e comunque sulle piattaforme sensibili collegate a grosse reti, testando le vulnerabilita’ sia con attacchi esterni alla rete che con attacchi dall’interno della stessa e, possibilmente gia prima prima che esse entrino nella fase di completo esercizio.
Possiamo distinguere vari livelli tecnici dei test, piu’ 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 la rete, i firewall, i router, etc…, e 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à (quindi meglio optare per software open source e li dove e’ possibile per far sviluppare internamente cio di cui si ha bisogno), o ad esercitare la tecnica denominata del trashing detto anche information diving, che è la pratica di risalire ad informazioni riservate attraverso il setacciamento dei rifiuti della vittima, come resoconti, bollette, corrispondenza. Una delle tecniche preferite dal famoso Kevin Mitnick.

Mettendo insieme tutte queste metodologie ed informazioni possiamo darvi un piccolo scenario di cio che viene eseguito, a grandi linee, durante un’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…., come ad esempio trovare indicazioni come queste “Powered by Apache, Linux Inside…” , mettono a rischio i sistemi.
  • Ricostruzione della struttura interna della rete
  • Raccolta Info: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.
  • Tracciamento vulnerabilita‘: 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 & DDoS.
  • Test su router e firewall.
  • Pulizia delle tracce dell’attacco.
  • Stesura del report.

Al termine degli attacchi e della valutazione dei log raccolti un sistema potra’ 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.

Punti critici:
cerchiamo ora di evidenziare i lati negativi del preparare un pen-test che purtroppo e’ un po come fare i lavori di casa mentre voi ci abitate dentro……
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 un 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.

Per ultimare questa carellata sul valore di un Pen-test aggiungo che il suo valore è strettamente legato alle capacità del tester, dunque affidiamoci soltanto a persone preparate che possono dimostrare esperienza pratica svolta su clienti tracciabili; inoltre esso 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è oggi giorno vengono trovate quotidianamente nuove vulnerabilità e nuovi exploit.

Shellshock Bug verifichiamo il nostro sistema

Shellshock Bug

Shellshock Bug

I ricercatori di Red Hat hanno recentemente segnalato un particolare bug denominato “Shellshock” presente nella Shell che potrebbe mettere in serio pericolo milioni di sistemi Linux. A quanto pare questo bug potrebbe essere utilizzato da utenti malintenzionati per poter operare sul sistema operativo.

Shellshock pare sia un exploit molto più pericoloso di Heartbleed, che avrebbe potuto mettere letteralmente in ginocchio la maggioranza dei web server esistenti, perché permette di prendere il pieno controllo della macchina, non importa quale, ed eseguire del codice (ottenendo tutti i permessi d’amministrazione).

Cos’è e come funziona Shellshock?  In pratica, è una vulnerabilità del terminale, che gli utenti di Windows conoscono meglio come Prompt dei comandi,  che espone all’attacco una serie di servizi, da Apache al DHCP dei router ecc… Se la versione di BASH installata è afflitta dal bug, un malintenzionato potrebbe eseguire da remoto una serie d’operazioni, che spaziano dai comandi CGI ai demoni avviati in automatico dal sistema operativo. Significa che, senza una patch ad hoc chiunque potrebbe prendere possesso dei server.

Non è però ben chiaro come questi possano accederne dato che effettuare modifiche nel sistema, installazione di software ecc vengono richiesti i permessi di root. Da notare inoltre che Red Hat e le principali distribuzioni Linux hanno già risolto il bug, basterà quindi aggiornare la distribuzione o server Linux per risolvere questo problema.

Possiamo facilmente verificare se il nostro sistema operativo è o meno  “infetto” da Shellshock.

Basta semplicemente avviare il terminale e digitare:

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

se avremo come risultato:

vulnerable
this is a test

vuol dire che nel nostro sistema è presente il bug Shellshock in bash

se invece abbiamo come risultato

this is a test

possiamo star tranquilli.

Per risolvere il problema bastera’ semplicemente aggiornare la Bash digitando da terminale:

Per Debian, Ubuntu e derivate:

sudo apt-get update
sudo apt-get install bash

Per Fedora, CentOS, Red Hat e derivate:

sudo yum install bash

Per openSUSE e derivate:

sudo zypper install bash

Per Arch Linux e derivate, Chakra, Manjaro ecc:

sudo pacman -Sy bash

Al termine bastera’ rilanciare il comando di verifica, ed ecco risolto il problema di Shellshock.

 

#ShellshockBugVerifichiamo

Metasploit Framework

metasploit_logoTestiamo la nostra Sicurezza

Oggi giorno sempre piu’ servizi sono online e tra questi troviamo anche cose importanti come la gestione del conto bancario oppure il nostro profilo INPS ecc….; tutto cio’ e’ molto comodo ma e’ anche piu’ facile che una falla sui sistemi che usiamo possa rendere facile a persone poco raccomandabili di intercettare qualche nostro dato “sensibile” per poi servirsene a piacimento.

Certamente molti di noi si affidano al fatto che confidiamo nell’alto livello di sicurezza dei gestori di questi servizi, ma pochi pensano che in ogni conversazione, compresa quella tra computer in un luogo pubblico come Internet, deve avere entrambi i soggetti SICURI , quindi come fare per essere certi il piu’ possibile (dato che sicuro e’ morto) che noi per primi siamo esenti da bug ???? Un buon metodo e’ tenersi sempre aggiornati sui bug piu’ noti e pericolosi e poi testare la propria macchina. Il metodo migliore per farlo e’ quello di usare un Framework come Metasploit.

I metodi per usare Metasploit sono tanti e disparati , dall’usare un Live-CD, installarlo su di una Pen-Drive, creare una VM apposita ecc…
Stessa cosa si puo’ dire per i metodi d’installazione del Framework in questione quindi vi descrivero’ quello che preferisco e che trovo piu’ funzionale.

INSTALLAZIONE

mkdir git
cd git
git clone https://github.com/mcfakepants/metasploit-framework.git

…..a questo punto potete verificare cosa e’ stato scaricato nella DIR entrandoci e lanciando un ls -L
il risultato dovrebbe essere una lista come questa

git/metasploit-framework$ ls -L
config           external      modules     msfencode    msfrpcd    scripts
CONTRIBUTING.md  Gemfile       msfbinscan  msfmachscan  msfupdate  spec
COPYING          Gemfile.lock  msfcli      msfpayload   msfvenom   test
data             HACKING       msfconsole  msfpescan    plugins    tools
db               lib           msfd        msfrop       Rakefile
documentation    LICENSE       msfelfscan  msfrpc       README.md

a questo punto prima di lanciare la console di Metasploit per l’installazione conviene assicurarci di avere tutti i pacchetti per gli script in Ruby installati, per completare questa operazione possiamo lanciare il seguente comando :

gem install bundler

ora non ci rimane che lanciare l’installazione del Framework in questione tramite

sudo ./msfconsole -L

se dovessimo riscontrare un errore come questo: Could not find rake-10.0.4 in any of the sources potremo risolvere fermando l’installazione in corso con un Ctrl+C , ed eseguire, dalla stessa posizione in cui ci troviamo, il comando bundle install che installaera’ tutte le “GEMME” mancanti; rilanciamo pure l’installazione come prima con : # sudo ./msfconsole -L

Ci vorra’ qualche minuto per ultimare questa fase in quanto i pacchetti da scaricare sono diversi; al termine dell’installazione ci ritroveremo catapultati all’interno della console amministrativa di Metasploit, con una schermata di questo tipo

< metasploit >
 ------------
       \   ,__,
        \  (oo)____
           (__)    )\
              ||--|| *

=[ metasploit v4.9.0-dev [core:4.9 api:1.0] ]
+ -- --=[ 1288 exploits - 705 auxiliary - 203 post ]
+ -- --=[ 334 payloads - 35 encoders - 8 nops      ]

msf >

Ora tutto quello che ci rimane da fare e’ testare quelle criticita’ che ci sembrano piu’ rischiose e capire cosi’ se il nostro PC ne e’ affetto.

Una di quelle da verificare, per fare il nostro primo test, e’ quella relativa ad un bug nel parsing dei font presenti nei file SWF (i file Flash) di Adobe, grazie al quale un malintenzionato potrebbe essere in grado di eseguire codice malevolo sulla macchina della vittima fino ad arrivare ad ottenere il controllo di una shell remota, senza necessita’ di inserire una password. Questo bug e’ molto problematico in quanto colpisce tutti i sistemi operativi e tutti i PC che abbiamo installata una versione di Flash precedente alla 11.3

Per verificare se il vostro PC e’ affetto tornate nella console di metasploit ed eseguite il test lanciando la seguente stringa :

msf  > use exploit/windows/browser/adobe_flash_otf_font

Eseguendo questo exploit , metasploit costruira’ in pratica un falso webserver sulla vostra macchina locale, ed un finto client che va a leggere  una pagina HTML contenente un file SWF (che si trova nella cartella metasploit-framework/data/exploits/CVE-2012-1535), in modo da eseguire il test automaticamente.

In generale per avere più informazioni sull’utilizzo di qualsiasi comando basta invocare l’help dedicato:

msf > nomecomando -h

Vediamo adesso i comandi per interagire con le librerie di exploit e payload. Il primo da conoscere è show che serve per mostrare il contenuto delle librerie, ad esempio:

msf > show exploits

Con questo comando verrà stampata la lista di tutti gli exploit presenti.

Per visualizzare i payload similmente useremo:

msf > show payloads

Per cercare un elemento specifico possiamo servirci del comando search:

msf > search cve:2012 type:exploit app:client

Search utilizza keyword (type, app, platform, name, etc) per affinare la ricerca. Al solito è buona norma consultare l’help del comando per avere un’idea di tutte le sue funzionalità:

msf > search -h

Prossimamente verranno aggiunti su questo Blog altri articoli relativi ai Bug piu’ pericoli da testare grazie a Metasploit, fino ad allora buona pratica e buon divertimento.

Vedi anche precedente articolo KaliLinux