Bezpecnost VoIP
Pavel Troller
patrol@sinus.cz
Úterý Listopad 3 15:46:21 CET 2009
> http://www.novinky.cz/ekonomika/183254-ucet-jeden-a-pul-milionu-za-tri-dny-telefonovani-zpusobil-majitelce-sok.html
>
> .... me tak napada, jestli jde odchytit nejakou VoIP komunikaci prostym
> snifovanim. ( nemyslim zrovna odposlech) Jak je zabezpecena autentizace?
> Děkuji za vyjadreni odborniku.
Zdravím,
bohužel, kvalita příspěvku byla tak špatná, že skutečně nelze přesně
stanovit, co se vlastně stalo. Zejména pojem "hovory byly přesměrovány"
je naprosto vágní a nevypovídá o ničem, co se skutečně mohlo stát.
Každopádně, pohovořme si tedy o zabezpečení VoIP protokolů, zjednodušme
si to pro začátek uvažováním protokolu SIP, který je dnes asi nejrozšířenější
(pomineme-li mor zvaný Skype :-) ).
V SIPu může být zabezpečena jak signalizace (SIPS), tak i přenos médií
(SRTP). Bohužel, ani jedno se v praxi zatím moc nepoužívá. To znamená, že
signalizační relace je běžně odposlouchávatelná (je to plaintext) a média se
dají přehrát a tedy hovor také odposlouchávat.
Autentikace SIPového účastníka vůči jeho mateřské ústředně (proxy) se
obvykle děje ve dvou případech: Během registrace a během volání (užití proxy).
Obojí bývá na sobě nezávislé, tj. mohu volat a nemusím být přitom registrován,
nebo naopak. Proces spočívá v tom, že "na blint" vyšlu patřičný příkaz
(metodu), např. INVITE nebo REGISTER, a pokud je třeba autentikace, dostanu
zpět 401 Unauthorized a v té odpovědi bude autentikační challenge (výzva)
v podobě pseudonáhodného stringu "nonce". Na tuto odpověď reaguje klient
zopakováním svého požadavku (INVITE/REGISTER) s tím, že do něj zahrne řetězec
"Response", vytvořený na základě přijatého "nonce" a uživatelských
kredenciálií (username/password). Souhlasí-li response, je patřičná akce
účastníka shledána platnou a požadavek (na registraci/volání) je přijat.
Tímto také končí platnost patřičné "nonce" a další autentikační odpovědi,
které by ji případně použily, jsou zamítnuty.
Z toho vyplývá, že ani odposlechem relace nelze zjistit kredenciálie klienta
ani uspořádat replay attack - nonce už není platná a slušný systém začne
alertit, že na něj někdo zkouší replay.
Systém je samozřejmě napadnutelný bruteforce attacky, kdy prostě a jednoduše
začnu bombardovat proxy např. registračními požadavky a budu při tom hádat
hesla a vytvářet response na dodané nonce. Problém je v tom, že ty
kredenciálie u VoIP bývají tradičně hodně slabé. Username bývá shodný s číslem
pobočky (což vůbec nemusí být, ale takto se to často zjednodušuje) a heslo bývá
také třeba jen numerické (aby se dobře zadávalo třeba do IP telefonů) a už jsem
viděl případy, kdy to bylo třeba číslo pozpátku nebo nějaký opravdu triviální
řetězec, jako "1234" nebo "VOIP", nadto pro všechny účastníky jedné ústředny
stejné.
Na závěr malý příklad ze života: Onehdy (během prázdnin) jsem si volal z
chalupy přes WiFi (jeden ze severočeských ISP) na svoji proxy v Praze. Volal
jsem z určitého čísla pobočky, ale na chalupě mám gateway v trunkovém režimu,
tj. vůbec se neregistruje ani neautorizuje, vše je na základě statických IP
adres. Po uskutečnění pár volání jsem se chvíli věnoval rodině a pak chtěl zase
volat, ale nešlo to, moje proxy byla úplně neresponsivní, ani přes ssh jsem se
do ní nemohl dostat. Nakonec se to podařilo a zjistil jsem, že je pod brutálním
útokem odkudsi z USA, dostává cca 450 register requestů za sekundu a nedělá nic
jiného, než že do logu píše o neautorizovaném pokusu o přístup k trunku z jiné
než definované IP adresy. Zajímavé bylo, že v útoku bylo použito přesně to
číslo pobočky, ze kterého jsem volal. Jediné vysvětlení je, že to někdo
odsnifoval nejspíše na WiFi (ten ISP má i své páteřní spoje na 5G nijak
nezabezpečené) a zřejmě měl konexe na nějaký "hackerský site" v USA. Tu útočící
IP adresu jsem pak dohledal na Google a zjistil jsem, že na útoky z ní už si
stěžovalo dost VoIP operátorů po celém světě. Od té doby mám své spojení
na chalupu tunelované přes IPSEC a přes něj i telefonuji a je klid :-).
Zdraví Pavel Troller
More information about the Hw-list
mailing list