VoIP (in)security - La situazione Italiana ESC 2K7 - San Donà - Paolo Ruggero [Jeky_99] (info@ruggero.ws) - PR4300-RIPE # Cenni storici [BFi numero 10, anno 4 - 30/09/2001] - i0 FASTWEB E TU? (by naif) Mi piace riprendere questo che, a mia memoria, è il primo articolo che abbia letto dove si trasmetteva la convinzione di una decisa svolta al mondo del phreaking verso il VoIP. Nell'articolo già dall'indice si legge "La nuova frontiera del phreaking: Voice Over IP" e "phreaking in rete Fastweb". Siamo nel settembra del 2001, si narra di eventi di Luglio ed essendo passati 6 anni penso questo sia degno di nota. Già allora le falle erano molteplici... d'accordo si trattava della prima società che desse VoIP all'utenza residenziale ma comunque a tecnologia nuova le insicurezze rimanevano le più banali. Parlando di quelli che comunemente chiamiamo HUG, si legge: <<[...] via web e' possibile visualizzarne la configurazione e, meraviglia delle meraviglie, "resettarli". AGGIORNAMENTO: ho notato che nel nuovo firmware chiede una password per resettarli, ma ovviamente avrete gia' capito quale e'.>> Il più irresistibile errore è mettere come password il nome della società, cosa purtroppo non così infrequente. <> Il buon naif esortava dunque tutti noi ad esplorare questo grande nuovo mondo, mostrandoci come in fastweb le cose fossero sufficientemente "messe li" per fondare l'autenticazione solo sulla username (che corrispondeva al numero di telefono) senza password ne autenticazioni di ogni genere. << root@somewhere:~# ./ohphone_1.1pl1 -r -u OsamaBinLaden -t -g IP.DEL.GATE.KEEPER NUMERO_DA_CHIAMARE. Gatekeeper set: nome_del_gatekeeper@IP.DEL.GATE.KEEPER OsamaBinLaden is calling host NUMERO_DA_CHIAMARE >> Riflessione: perchè proprio solo e sempre il numero di telefono come userid? non una email? Chi pensa e sviluppa i sistemi telefoni il più delle volte proviene da un ambiente che ha sempre lavorato su centrali IDSN e SS7... la segnalazione di questi protocolli si basa univocamente sul callerID delle telefonate sia per l'instradamento che per il billing. La questione è stata efficace dal momento che ogni singolo flusso ISDN parte da casa del cliente per arrivare in centrale... ma ora che il trasporto della nostra voce è affidato ad internet? chi garantisce che il "Doppino" che arriva in centrale siamo noi? Tutto ciò per dire che le cose sono ingiro da anni, ma a quanto pare il problema della sicurezza del VoIP non è largamente sentito come non lo era la sicurezza di internet poco dopo l'introduzione del protocollo http (O volendo essere meno retrogradi ai tempi dei primi ssh e wu-ftpd). Oggi anche in italia ci sono CENTINAIA di aziende con offerte voip + disparate. In una sommaria lista stilata l'estate del 2006 (dunque un anno fa) ne contavo 40 diverse (escludendo eventuali reseller) con le offerte + disparate, con o senza ADSL obbliata, flat o non flat.. ma tutte all'insegna della convenienza. Gestori presi in esame: www.tiscali.it - www.vira.it - www.panservice.it - www.cheapnet.it - www.squillo.it (by NGI) www.mclink.it - www.messagenet.it - www.kpnquest.it - www.skypho.net - www.infinito.it Un po di numeri.. sono 10 su 40 elencati, i gestori (eccetto tiscali) che permettono servizi voce senza la loro adsl, che hanno fee d'ingresso sufficientemente basse per registrarsi tanto per provare e che non prevedono canoni mensili. Per continuare con i numeri, 6 di questi 10 gestori hanno qualche "problemino"... Sistemi diversi e vulnerabilità diverse: Tiscali -> Gatekeeper H323 su una sete ATM SEPARATA dalla ADSL dati Vira -> Protocollo SIP utilizzando Asterisk Panservice -> Protocollo SIP utilizzando Asterisk Cheapnet -> Protocollo SIP utilizzando Asterisk Squillo -> Protocollo SIP utilizzando Asterisk McLink -> Protocollo SIP Messagenet -> Sip Express router su Linux + Asterisk KPNQuest -> Sip Express router su Linux + Asterisk Skypho -> SPS01 (Probabile Sip Express router con banner alterato) su Linux Infinito -> Sip Express router su Freebsd Tiscali analisys: Tiscali utilizza un proprio router per la fornitura di servizi VoIP prodotto dalla Pirelli. Questo router viene inviato a casa di ogni cliente privo di configurazione. Non appena il router viene collegato alla linea, esso si collega con delle credenziali di registrazione ed invita ad inserire user e password per procedere alla configurazione remota. Una volta configurato, il router sarà accessibile con user e password "user" per la sola configurazione dei Virtual server (P-NAT) e niente più. La questione si manifesta alquanto noiosa e rende impossibile ogni approccio post-configurazione. Con un rapido port scan scopriamo che l'unica porta in ascolto è la 8081 a cui risponde una consolle telnet. Anche qui non serve che sia io dirvi quale mai potrebbe essere la password ! Usate la "fantasia". E' la storia che si ripete, tecnologia dopo tecnologia senza scampo! Ma lo diceva anche Einstein: "Solo due cose sono infinite, l'universo e la stupidità umana, e non sono sicuro della prima." Ovviamente ci pensa la configurazione remota a cambiare la password, peccato che a qul punto la configurazione del router potrebbe essere stata completamente compromessa per permetterci di acquisire la password intercettando i comandi remoti. Ma in cuori nostro tutti immaginiamo che non sia così grave... la password sarà diversa da utente ad utente! Mi dispiace disilludervi, ho la ragionevole certezza che non sia così! Chi riesca in qualche modo ad ottenere questa password ha la possibilità di accedere remotamente a qualsiasi router Tiscali voce dalla rete pubblica! (he si, grazie all'autoconfigurazione il router è in ascolto anche verso internet) Approfondiamo ora però l'analisi, come trasmette tiscali la nostra voce? Con "estrema attenzione alla sicurezza ed alla qualità", tiscali non trasmette la nostra voce in VoIP sul canale ADSL, ma crea un secondo circuito virtuale ATM collegato ad una rete privata. Trasmettendo da remoto la configurazione ed inibendo l'accesso contava di ricrearsi un canale sicuro tra l'utente e il gestore... qualcuno alla sicurezza forse c'aveva pensato. C'ha pensato troppo poco forse però... basta infatti un traceroute per notare che verso la rete 10.x.x.x esiste un gateway diverso da quello di internet, qualche ping per capire il nostro indirizzo e qualche prova con un'altro router per scoprire che la connessione alla rete voce avviene tramite il circuito virtuale 9/35. Non è richiesta alcuna username o password! Il tutto senza toccare il router tiscali che possiamo lasciare in scatola. La "sicurezza" di tiscali è giunta al termine, siete pregati di sguazzare nella rete! Questa belle ed ordinata rete privata tiscali voce, racchiude chiunque come me abbia un pirelli voce... con il suo IP privato, con la stessa passowrd, con le impostazioni del gatekeeper h323! Ma ora, provate a concentrarvi ed immaginare, quale sarà la username per la nostra autenticazione? E la password? Non ho voluto provare ad usare il numero di qualche altro cliente, ma con numeri o nomi a caso il gatekeeper non permette di telefonare al difuori della rete tiscali... Al contrario è possibile chiamare gli altri clienti tiscali voce con i callerID più fantasiosi, dal gogliardico 666 al preoccupante +39117 !!! E se per ora ci siamo divertiti, cosa pensate succeda impostando come gatekeeper del router del nostro "amico" il nostro IP locale dove abbiamo installato un gatekeeper oh323 per l'occasione? cosa succede se giocherellando con il routing le nostre chiamate venissero nattate dal router del malcapitato amico? (Ammesso che avvenga un controllo sull'associazione IP-numero di telefono). Ci conviene staccare la spina e sperare che mai nessuno abbia interessi a mettere mani alla nostra linea! Per carità, non siamo meno sicuri che su una linea tradizionale, dove tra casa nostra e la centrale c'è la statistica certezza di trovare una centralina aperta, ma l'attacco, a differenza che con coccodrilli e fili, può essere portato a termine comodamente dal divano! Riflessione: Ancora sto benedetto/maledetto CallerID, possibile che usino solo quello? Bisogna svegliare chi di dovere e raccontargli la triste verità, l'ISDN sta muorendo ! Fargli pensare che per avere un canale diretto in una rete dati da cliente a centrale è forse il caso di usare una vpn (magari non con la solita chiave e password diversa per ogni cliente !). Vira - Panservice - CheapNet - Squillo - McLink analisys: Tanti operatori, gli stessi bachi.. Riflessione: La stessa AGI? Lo stesso approccio? Lo stesso chan_sip? Non ho una risposta completa, ma dicerto, avendo collaborato con vira, posso dirvi che Vira (come MOLTi altri gestori VoIP, ha affidato la sua struttura ad una serie di server Asterisk, che curano, chi l'interconnessione con i flussi (ISDN o SS7), chi le conversioni di codec, chi l'autenticazione dei clienti, chi i dialplan ed il billing. Per la gestione di accounting e billing Vira ha utilizzato una AGI (Asterisk Gateway Interface) acquistata da panservice e scritta in PHP (con l'ovvio sussidio di un db mysql). Le cose gustose iniziano analizzando prima da fuori (e poi da dentro) il funzionamento del servizio VoIP. Digitare un numero parlare e riagganciare ovviamente non ci da ne soddisfazione ne divertimento, iniziano ad essere divertenti i trasferimenti di chiamata, ed i servizi evoluti (vedi conference call ecc). Dovete sapere che quasi tutti questi provider, forniscono sia un numero di telefono "interno" al proprio gestore, e sia un numero di rete pubblica.. in questo modo abbiamo due tipi di numeri che possono essere chiamati, che sono gesiti in maniera diversa. Chiamare un numero interno è gratuito, chiamare quello pubblico si paga. Ma come mai avranno pensato di applicare la tariffazione? In tutte le comuni centrali ISDN, chi chiama ha un CallerID, chiama un certo numero ad una certa tariffa, vengono calcolati i secondi della chiamata ed a fine chiamata vengono addebitati sul conto del chiamante. Come funzionano i trasferimenti? Se A chiama il cliente B e B trasferisce A al cliente C succede pressochè così: A effettua chiamata a B e parte il suo contatore. B effettua chiamata a C e parte il suo contatore. B dice ad A di parlare direttamente con C. I contatori si fermano quando A riaggancia. Risultato: A paga per tutto il tempo che è stato in linea, la sua tariffa verso B B paga per tutto il tempo che ha trasferito A verso C con la sua tariffa verso C. PERFETTO.... ma il protocollo SIP ? Se A chiama il cliente B e B trasferisce A al cliente C succede pressochè così: A effettua chiamata a B e parte il suo contatore. B dice ad A che non deve più rivolgersi a lui ma a C. Il contatore di A verso B si stoppa e ricomincia a contare da quando C risponde. Non notate una fastidiosa differenza? Se in ISDN chi trasferisce in pratica è chi FA la nuova chiamata (e se ne accolla il costo) con il SIP chi trasferisce fa fare tutto a chi rimane e si leva d'impiccio. E' una scelta intelligente dal punto di vista del traffico dati, si pensa che tutti i telefoni sono connessi (in qualche modo) ad internet e quindi possono parlarsi direttamente! Bisogna tenerne conto però. In questo modo io posso chiamarti ad un numero interno voip, te mi puoi trasferire al tuo telefonino, e chi paga sono io.. completamente ignaro che tu sia al cellulare! Ma ancora più bello, cosa succede se io chiamo al cellulare e lo trasferisco al mio interno voip? La mia comunicazione si chiude (smetto di pagare), mi scquilla il mio interno, rispondo ed è che mentre mi chiede cosa diavolo sto combinando capisce che mai e poi mai potrà addebitare la chiamata che io sto "ricevendo" al suo cellulare!!! Fantascienza? Imperfezioni di questo tipo su CheapNet - Squillo - McLink sono (?? erano spero ??) all'ordine del giorno. Molto gustosi anche i servizi avvanzati... Tanti si affidano alle implementazioni base di asterisk, che non tratta in maniera diversa rete pubblica e rete voip (che invece ha un costo un bel po diverso). Succede che chiamato un cellulare, inserito in una conferenza, e lasciato "solo", il centralino ci richiami se dopo un certo tempo nessun'altro si unisce alla conferenza. Il nosto amico al cellulare non si sentirà più solo, ma noi non siamo + pagando per tenergli compagnia! Un'altra questione che ci sta a cuore e che esula la sicurezza ECONOMINA è la veridicità del callerID... Come usando un cellulare, anche facendo trasferimenti di chiamata tramite i carrier voip, succede spesso questa condizione: Dal mio telefonino chiamo il numero geografico VoIP di , l'utente VoIP mi trasferisce al telefonino di . vede il MIO numero di telefonino come callerID perchè la chiamata sta arrivando da ME (no.. non compare il simbolo di chiamata trasferta!!!). Ma fino a qui ancora bene... se non fosse che molti provider per chiamate interne, non forzino come callerID il numero di abbonamento, ma permettano al cliente di scegliere il proprio nickname, niente di male sulle chiamate interne, verrà visualizzato nickname e numero... E' triste vedere come trasferendo la chiamata (proveniente da un'interno) al telefonino di il callerID a lui inoltrato sia il nickname e non il numero... nickname che in questo caso non può che essere +3931337 :P E' finita? Un'ultima chicca per la vostra depressione serale, un piccolo stralcio di come suppongo molti gestori facciano il parse dei numeri: Mettiamo che $exten sia il numero da digitare, a cosa serve questo codice ? if(substr($exten,0,4)=="0039"){ $exten=substr($exten,4); } Ve lo dico io, a NULLA !!! Nel caso il dialplan presenti qualche incongruenza (succede visto che il gestore non si aspetta di avere numeri con lo 0039 iniziale), si ha un billing errato! Personalmente avrei preferito qualcosa del tipo... while(substr($exten,0,4)=="0039"){ $exten=substr($exten,4); } ...che ne dite? Non è così difficile sbagliare con i numeri... Da quando ci sono ingiro prefissi di telefonini con il "393"... succede che un +39 393 4712345 venga considerato vodafone o ancora peggio numero di rete fissa... poichè si tolgono troppi 39 ! (Chissà che succede con il numero +39 393 9021234 !!!) La cosa gustosa è che H3G al costo di 10 Euro ci lascia scegliere il nostro numero :D Un Grazie a: - Tutti voi per l'attenzione - Mayhem per la collaborazione - naif per avermi illuminato