Nmap: usare gli script NSE per analizzare un obiettivo

Gli Nmap Scripting Engine (abbreviato NSE) sono degli script scritti nel linguaggio LUA che possono essere eseguiti da nmap durante una scansione.
Nati inizialmente per offrire molte più informazioni di quanto un banner possa dare (versione del servizio in uso, rilevazione di vulnerabilità, ecc), sono oggi usati anche per l'exploiting delle vulnerabilità. Ogni script è ordinatamente inserito dentro una categoria di appartenenza:

Categoria	Descrizione
auth	Credenziali di autenticazione al sistema (o metodi per bypassarli). Contiene ad esempio x11-access, ftp-anon o oracle-enum-users.
broadcast	Gli script in questa categoria trovano gli hosts non inclusi nei parametri di nmap che inviano messaggi in broadcast sulla rete locale.
brute	Sferrano attacchi bruteforce sui protocolli come ad esempio http, oracle o snmp.
discovery	Cercano di reperire più informazioni possibili sulla rete sottoposta ad analisi come ad esempio messaggi SNMP o enumerazione delle cartelle SMB.
dos	Attacchi di tipo Denial of Service
exploit	Sfruttano attivamente una vulnerabilità
external	Gli script in questa categoria possono inviare informazioni a sistemi di terze parti, che non centrano nulla con la scansione che si sta eseguendo. Un esempio è l'uso di whois.
fuzzer	Il fuzzing è una metodologia per scoprire bug e vulnerabilità su un servizio. Questa categoria invia dati random/malformati al server all'interno dei pacchetti.
safe	Script che reperiscono informazioni in maniera sicura, senza causare grossi problemi alla stabilità del target come ad esempio ssh-hostkey e html-title. Consumano grande quantità di banda.
intrusive	Tutti gli script che non rientrano nella categoria "safe" perché potrebbero causare crash al sistema target.
malware	Test per controllare se il target è infetto da malware o backdoors.
version	Rivela la versione del servizio in uso come ad esempio skypev2-version o iax2-version
vuln	Riportano la presenza di vulnerabilità come su realvnc-auth-bypass o afp-path-vuln

Vediamo come richiamare gli NSE da riga di comando:

nmap -sC <target(s)>

Equivale a richiamare la categoria "default" che contiene scripts che non richiedono molto tempo per il completamento e forniscono un output molto dettagliato sui servizi che sono in esecuzione sul target.

nmap –script <nome_file>|<categoria>|<cartella>|<espressione> ... <target(s)>

con il parametro –script imponiamo ad nmap di eseguire un qualcosa di specifico che può essere un file in LUA, una categoria intera (vedi sopra per maggiori dettagli) o una cartella specifica (che contiene file in LUA). Per "espressione" intendo che possiamo anche specificare una regex o comunque usufruire del carattere speciale " * ". Quindi se volessimo verificare la presenza di vulnerabilità sul computer target dovremmo eseguire:

nmap –script vuln <target(s)>

così facendo richiamiamo tutti gli script all'interno della categoria "vuln". Alcuni NSE possono richiedere dei parametri aggiuntivi, come ad esempio una credenziale d'accesso o un gruppo di lavoro. Per specificare argomenti si deve usare il parametro "--script-args"

nmap –script snmp* --script-args='snmpcommunity=admin' <target(s)>

Abbiamo passato il parametro "snmpcommunity=admin" a tutti gli NSE che si occupano del protocollo SNMP.

nmap -sC –scrpt-args='user=administrator,pass=password123' <target(s)>

Tutti gli script nella categoria default utilizzeranno le credenziali "admin:password123" per provare ad accedere ai servizi sul target. Se si specificano delle credenziali è necessario che queste siano valide, così da reperire maggiori informazioni.

Un altro parametro che ci sarà molto utile è "--script-help":

nmap –script-help "afp-* and discovery"

che ci fornirà una descrizione dettagliata di tutti gli script per afp che si trovano nella categoria "discovery":

L'ultimo parametro che andiamo ad analizzare è "--script-updatedb":

nmap –script-updatedb

che serve a ricostruire il file "scripts/script.db" (all'interno della cartella di installazione di nmap) nel caso in cui siamo andati ad aggiungere/rimuovere uno script
Analisi di un server di condivisione Samba.

Cominciamo con qualche esempio pratico. Abbiamo un server Samba (SMB) di un NAS che permette la condivisione di file e cartelle a tutta la rete LAN. Cerchiamo di ricavarne più informazioni possibili:

nmap –script-help "smb* and discovery"

Così facendo richiamo le descrizioni degli NSE che si occupano di SMB, ma solo quelli categorizzati come "discovery" (per non dare troppo fastidio con attacchi bruteforce o flooding). Una volta analizzate le descrizioni degli NSE, passiamo all'esecuzione:

nmap –script "smb* and discovery" <target(s)>

Ed ecco i risultati:

“smb-enum-domains” cerca di enumerare i domini in uso sul servizio SMB (i domini servono per differenziare la visualizzazione delle cartelle. Ad ogni dominio può corrispondere un contenuto diverso). E' generalmente necessario specificare una credenziale valida per poter reperire tutta la lista dei domini (eccetto su un server Windows). Nel nostro esempio ha scoperto “Builtin” e “NAS”

“smb-enum-sessions” cerca di enumerare gli utenti connessi all'interno del server SMB. Nel nostro esempio non c'era nessun altro utente connesso. Altrimenti avrebbe riportato l'username e da quanto tempo stava usando la risorsa.

“smb-enum-shares” cerca di mostrare più informazioni possibili sulle cartelle condivise. Nel caso in cui non siano state passate delle credenziali di accesso (attraverso –script-args) proverà ad accederci con utente anonimo. Nel nostro esempio non abbiamo passato nessuna credenziale ed ora sappiamo che:

• /Film/ è leggibile da utente anonimo, ma non scrivibile
• /IPC$/ è leggibile da utente anonimo, ma non scrivibile, ma in realtà è solo una cartella d'appoggio, non ci sono file utili
• /Volume-1/ non è accessibile anonimamente.
• /lp/ è leggibile e scrivibile da utente anonimo ed è la cartella della coda della stampante
• /web_page/ è leggibile da utente anonimo, ma non scrivibile. Contiene solo un link al pannello web del NAS

“smb-os-discovery” cerca di identificare il sistema operativo, il nome del computer, il dominio, il workgroup e l'ora locale del server. Abbiamo scoperto che il nostro target è un sistema Linux ed usa la versione 3.0.24 di Samba.

Un bel po di informazioni per una scansione che impiega solo 8 secondi! Se vogliamo poi portare ad un livello più alto la nostra scansione alla ricerca di vulnerabilità conosciute dobbiamo utilizzare lo script chiamato “smb-check-vulns”:

nmap –script smb-check-vulns –script-args=unsafe=1 <target(s)>

Il parametro “unsafe=1” forza l'esecuzione di operazioni che potrebbero causare crash o BSOD.

Un altro servizio molto comune che andremo ad analizzare è il server web.

nmap –script-help "http* and discovery" <target(s)>

Per vedere tutti gli script per HTTP e che appartengono solo alla categoria “discovery”. Una volta analizzate le descrizioni degli NSE, passiamo all'esecuzione:

nmap –script "http* and discovery" <target(s)>

E dopo circa 2 minuti ecco i risultati:

“http-affiliate-id” restituisce gli ID di affiliazione delle campagne Google Adsense, Google Analytics e Amazon Associates.

“http-default-accounts” tenta di accedere con credenziali di accesso di default su path noti. Questo script restituisce spesso falsi positivi nel caso in cui il webserver gestisca i 404 internamente.

“http-headers” esegue una richiesta “GET / “ e mostra gli Headers di risposta. Negli headers si possono trovare informazioni importanti come il server web (in questo caso nginx), la versione (che in questo esempio è stata nascosta) o l'ora locale del server.

“http-sitemap-generator” va alla ricerca della sitemap del sito e ce la mostra. Questa potrebbe essere rinominata o compressa in vari modi. Lo script, in base ad una lista di path precaricate, cerca di trovare una corrispondenza.

“http-waf-detect” è uno script che tenta di identificare la presenza di un Intrusion Detection/Prevention System o Firewall. Fra quelli per il momento supportati troviamo:

• Apache ModSecurity
• Barracuda Web Application Firewall
• PHPIDS
• dotDefender
• Imperva Web Firewall
• Blue Coat SG 400

Sappiamo che il nostro target ne utilizza uno, ma non è riuscito ad identificare quale.

“http-wordpress-plugins” va alla ricerca dei plugin wordpress installati sul target. Questo controllo verrà comunque fatto seppur non è stato rilevato un CMS di tipo wordpress. Ma nel nostro esempio lo era. Se vogliamo poi portare ad un livello più alto la nostra scansione alla ricerca di vulnerabilità conosciute dobbiamo specificare gli script http* che fanno parte della categoria “vuln”:

nmap --script "http* and vuln" –script-args=unsafe=1 <target(s)>

Questa scansione richiederà sicuramente molto più tempo perché controllerà varie vulnerabilità su diversi CMS.

Conclusioni

Dalle primissime versioni nmap è sempre stato lo strumento più utilizzato per fare port scanning. Nel corso degli anni si è evoluto a tal punto da diventare una suite di strumenti “all-in-one”. Oggi vulnerability assessment e domani?