Varnost VoIP komunikacij (mala šola informacijske varnosti, 15. del)

Ker VoIP priključki oziroma VoIP telefonija v zadnjih letih čedalje bolj izpodriva klasično (PSTN in ISDN) telefonijo si bomo v tokratnem prispevku pogledali kako enostavno je mogoče prestrezati nezaščitene VoIP komunikacije.

Pri VoIP oziroma tim. IP telefoniji za prenos zvoka ne uporabljamo klasične telefonske povezave, pač pa podatkovni prenos. Gre torej za zvočno komunikacijo preko (računalniškega) omrežja, ki je v osnovi sestavljeno iz VoIP centrale in ustreznih telefonskih aparatov, ki jih povežemo v računalniško (LAN ali WAN) omrežje. Naj dodamo, da je za odjemalce namesto telefonskih aparatov mogoče uporabiti tudi ustrezne aplikacije, tim. programske telefone, ki tečejo tako na navadnih računalnikih, kot tudi na pametnih mobilnih telefonih.

VoIP telefonija najbolj pogosto poteka preko SIP ali H.323 standarda iz varnostnega stališča pa se je pomembno zavedati dejstva, da podatki pri VoIP telefoniji v osnovi niso šifrirani. VoIP promet je sicer mogoče zaščititi s šifriranjem (npr. TLS ali ZRTP), a če ponudnik VoIP telefonije zaščite ne vključi oziroma če nimamo ustreznega telefonskega aparata, ki bi šifriranje podpiral, se telefonski pogovori v VoIP omrežju prenašajo povsem nezaščiteno. In izkaže se, da je prestrezanje VoIP komunikacij v lokalnih omrežjih v pogostih primerih pravzaprav otročje lahko, kar si bomo ogledali na primeru prestrezanja SIP in H.323 prometa.

Dostop do omrežja

Prvi korak za uspešno prestrezanje VoIP prometa je (fizični) dostop do (lokalnega) telefonskega omrežja. Pridobimo ga lahko preprosto tako, da se z računalnikom fizično povežemo na omrežno stikalo (ang. switch) (ali omrežni koncetrator (ang. hub), če se še kje uporablja) VoIP omrežja ter nato v njem pridobimo lokalni IP naslov.

Proti temu sicer obstajajo nekatere zaščite. Najbolj osnovna zaščita je ta, da upravljalec VoIP omrežja iz glavnega stikala fizično izključi vse neuporabljene priključke. Ta ukrep je sicer zelo priporočljiv, vendar varnostnega problema v resnici ne rešuje, saj napadalec lahko iz VoIP omrežja odklopi obstoječo napravo (telefon) in namesto nje priklopi dodaten omrežni razdelilnik (npr. omrežni koncentrator), nakar se v omrežje poveže preko na novo vzpostavljenega priključka. Napadalec lahko v omrežje vključi tudi dodatno stikalo v tim. mostovnem načinu (ang. bridge mode) ter povsem povsem pasivno analizira omrežni promet, ali pa si v ta namen naredi poseben razdelilec. Poleg tega nekateri telefonski aparati vsebujejo dva omrežna priključka – eden je namenjen povezavi telefona v omrežje, drugi pa za povezavo dodatnih naprav v VoIP oz. LAN omrežje.

Nekatera omrežja imajo uveden dodaten varnostni ukrep, in sicer ta, da dovolijo povezavo v omrežje samo napravam z vnaprej definiranimi MAC naslovi. Na tak način izvaja avtentikacijo uporabnikov tudi večina slovenskih kabelskih ponudnikov dostopa do interneta. MAC (Media Access Control) naslovi so posebne oznake omrežne strojne opreme (nekakšne serijske številke omrežnih vmesnikov), gre za 48-bitna števila, prvi trije bajti MAC naslova pa predstavljajo identifikacijo izdelovalca strojne opreme (zakaj je to pomembno bomo videli kasneje).

Vendar pa tudi ta ukrep v resnici problema varnosti ne rešuje zadovoljivo, saj je MAC naslove omrežnih vmesnikov mogoče zelo enostavno spreminjati oz. ponarejati. V Linuxu je to mogoče storiti kar z ukazom ifconfig. Primer ukaza za spreminjanje MAC naslova omrežnega vmesnika z oznako eth0 na vrednost CA:FF:EE:BA:BE:01 je npr. naslednji:

ifconfig eth0 hw ether CA:FF:EE:BA:BE:01

Za operacijski sistem Linux obstaja tudi aplikacija macchanger, ki omogoča samodejno naključno spreminjanje MAC naslova omrežnega vmesnika, za operacijski sistem Windows pa obstaja podobna aplikacija MadMAC.

V ustrezno varnostno zasnovanih omrežjih se je sicer v omrežje mogoče povezati samo na podlagi ustrezne kriptografske overitve, s pomočjo 802.1X avtentikacije, ki je standardiziran overovitveni mehanizem za povezavo omrežnih naprav na LAN ali WLAN omrežja. Vendar pa v praksi v številnih VoIP omrežjih tovrstno overjanje ni vključeno (čeprav ga telefonski aparati podpirajo), še več, pogosto niso uporabljeni sploh nikakršni varnostni mehanizmi.

Tako v lokalnih VoIP omrežjih dodeljevanje IP naslovov pogosto poteka dinamično in povsem samodejno, preko mehanizma DHCP. Napadalec tako v praksi zgolj s fizičnim dostopom do omrežja enostavno pridobi tudi IP naslov. Od tam naprej do zlorabe pa je samo še nekaj preprostih korakov.

Pregled omrežja

Naslednji korak, ki ga bo izvedel napadalec je navadno aktiven pregled omrežja. S pomočjo le-tega napadalec hitro identificira telefonsko centralo in priključene telefone ter njihove IP naslove. Pregled omrežja je mogoče narediti s pomočjo orodja nmap, ki izvede pregled vseh aktivnih omrežnih naprav. Primer ukaza, ki preišče vse IP naslove v danem podomrežju:

nmap 192.168.1.0/24

S pomočjo stikala -O lahko napadalec ugotovi še kateri operacijski sistemi tečejo na aktivnih napravah in na podlagi tega podatka za te sisteme poizkuša poiskati ustrezne ranljivosti. Orodje nmap izpiše še katere storitve tečejo na napravah, napadalec pa se nato lahko poskuša povezati do posameznih storitev (npr. spletnih strežnikov, ssh storitve, itd.) in do naprave dostopati s pomočjo privzetih gesel ali s pomočjo napada z grobo silo (ang. bruteforce). Pri identifikaciji si lahko pomaga tudi s pregledom morebitnih SSL digitalnih potrdil, ki lahko razkrijejo tip naprave, posledično pa napadalec za to napravo poskuša poiskati privzeta gesla ali pa znane varnostne ranljivosti. Skratka, praktično katerakoli informacija, ki jo napadalec pridobi o odkriti napravi, mu lahko pomaga izvesti korak naprej v napadu.

Orodje nmap sicer z različnimi stikali omogoča uporabo številnih možnosti. Zgolj za hiter prikaz si poglejmo primera izpisov dveh skeniranj:

nmap 192.168.1.50 -A -T4

Starting Nmap 5.21 ( http://nmap.org ) at 2013-04-17 21:48 CEST
Nmap scan report for 192.168.1.50
Host is up (0.00027s latency).
Not shown: 997 filtered ports
PORT STATE SERVICE VERSION
135/tcp open msrpc Microsoft Windows RPC
139/tcp open netbios-ssn
445/tcp open netbios-ssn
MAC Address: 00:23:AE:B1:00:00 (Dell)
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: general purpose
Running: Microsoft Windows Vista|2008|7
OS details: Microsoft Windows Vista SP0 or SP1, Server 2008 SP1, or Windows 7
Network Distance: 1 hop
Service Info: OS: Windows

Host script results:
|_nbstat: NetBIOS name: MATEJ, NetBIOS user: , NetBIOS MAC: 00:23:ae:b1:00:00
| smb-os-discovery:
| OS: Windows 7 Professional 7601 Service Pack 1 (Windows 7 Professional 6.1)
| Name: TEST\MATEJ
|_ System time: 2013-04-17 21:49:49 UTC+2
|_smbv2-enabled: Server supports SMBv2 protocol

HOP RTT ADDRESS
1 0.27 ms 192.168.1.50

OS and Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 52.29 seconds

nmap 192.168.1.51 -A -T4

Starting Nmap 5.21 ( http://nmap.org ) at 2013-04-17 21:50 CEST
Nmap scan report for 192.168.1.51
Host is up (0.00025s latency).
Not shown: 996 filtered ports
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 5.5p1 Debian 4ubuntu6 (protocol 2.0)
| ssh-hostkey: 1024 08:8c:00:21:b8:e3:bb:00:7f:fd:48:35:cc:3b:b6:ca (DSA)
|_2048 c8:00:52:ff:00:e9:2a:3a:5a:d4:20:cc:44:05:99:20 (RSA)
80/tcp open http nginx 0.7.67
| html-title: 301 Moved Permanently
|_Did not follow redirect to https://192.168.1.51/
443/tcp open http nginx 0.7.67
|_html-title: 400 The plain HTTP request was sent to HTTPS port
5432/tcp open postgresql PostgreSQL DB
MAC Address: 00:22:4D:37:00:00 (Mitac International)
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: general purpose|firewall|WAP|router|specialized|webcam
Running (JUST GUESSING) : Linux 2.6.X|2.4.X (95%), Check Point Linux 2.4.X (93%), D-Link embedded (93%), Linksys embedded (93%), Peplink embedded (93%), Crestron 2-Series (90%), AXIS embedded (88%), AXIS Linux 2.6.X (88%)
Aggressive OS guesses: Linux 2.6.19 - 2.6.31 (95%), Linux 2.6.15 - 2.6.30 (94%), Check Point VPN-1 UTM appliance (93%), D-Link DSA-3100 or Linksys WRT54GL (DD-WRT v23) WAP, or Peplink Balance 30 router (93%), Linux 2.6.22 (91%), Crestron XPanel control system (90%), Linux 2.6.17 - 2.6.31 (89%), Linux 2.6.24 - 2.6.31 (89%), Linux 2.6.9 - 2.6.30 (89%), AXIS 207W Network Camera (88%)
No exact OS matches for host (test conditions non-ideal).
Network Distance: 1 hop
Service Info: OS: Linux

HOP RTT ADDRESS
1 0.25 ms 192.168.1.51

OS and Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 14.84 seconds

Preusmerjanje in prestrezanje prometa

Na tej točki ima napadalec že razmeroma dober pregled nad omrežjem. A če želi prestrezati komunikacije, mora omrežni promet ostalih uporabnikov preusmeriti tako, da bo tekel preko napadalčevega omrežnega vmesnika.

To je mogoče storiti tako, da MAC naslov omrežnega vmesnika povežemo z IP naslovom neke druge točke v omrežju. To napadalcu omogoča prestrezanje prometa, spreminjanje prometa ali izvedbo DOS napada. Postopek se imenuje ARP preusmerjanje (Address Resolution Protocol), oziroma ARP spoofing, ARP flooding, ARP poisoning ali ARP Poison Routing (APR)).

Gre za tehniko preusmerjanja ARP paketov v ethernet omrežjih. Pri tem je potrebno poudariti, da omenjeni napad ne deluje na nivoju IP protokola (tim. internet nivoju), pač pa na nivoju ARP protokola (tim. nivo povezave, ang. link layer), torej en nivo nižje. Naprave v lokalnem omrežju bodo tako še vedno obdržale svoje IP naslove, spremenila se bo le prenosna pot po kateri bodo komunikacijski paketki potovali po (ethernet) omrežju.

Proti ARP preusmerjanju sicer obstajajo nekatere zaščite, kot npr. uporaba tim. statičnih ARP tabel, uporaba programske opreme, ki zaznava poiskuse ARP preusmerjanja ali uveljavitev sprememb ARP tabele šele po določenem času. Žal pa implementacija zaščitnih mehanizmov zahteva nekoliko več potrpljenja in je tudi neprimerna za uporabo v večjih in dinamičnih omrežjih, kjer se v omrežje z visoko frekvenco priklapljajo in iz njega odklapljajo različne naprave. Zato na tovrstne zaščite naletimo le poredko. Žal na tovrstne zaščite poredko naletimo tudi v VoIP omrežjih, ki so razmeroma statična v smislu, da se število naprav v njih ne spreminja preveč pogosto.

Prvi korak s katerim napadalec lahko ugotovi ali je omrežje ranljivo na ARP preusmeritvene napade je pregled ARP paketkov s pomočjo orodja tcpdump:

sudo tcpdump -i eth0 -n arp

Če rezultat pokaže veliko število ARP paketkov je to za napadalca dober znak, ki kaže na to, da je omrežje dokaj verjetno ranljivo na ARP preusmerjanje:

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
11:51:08.068896 ARP, Request who-has 10.254.60.1 (c4:7a:81:00:c0:00) tell 10.254.60.27, length 46
11:51:25.685073 ARP, Request who-has 10.254.60.1 tell 10.254.60.45, length 46
11:52:07.346347 ARP, Request who-has 10.254.60.1 tell 10.254.60.12, length 28
11:52:07.346937 ARP, Reply 10.254.60.1 is-at 00:19:56:21:ef:80, length 46
11:52:08.478366 ARP, Request who-has 10.254.60.1 (b4:a4:81:00:c0:00) tell 10.254.60.28, length 46
11:52:16.568207 ARP, Request who-has 10.254.60.1 (13:6e:81:00:c0:00) tell 10.254.60.24, length 46
11:52:16.569510 ARP, Request who-has 10.254.60.1 (ba:ec:81:00:c0:00) tell 10.254.60.25, length 46
11:52:16.576901 ARP, Request who-has 10.254.60.1 tell 10.254.60.20, length 46
11:52:18.063650 ARP, Request who-has 10.254.60.1 tell 10.254.60.49, length 46

Sledi dejanska izvedba ARP preusmerjanja s pomočjo aplikacije arpspoof. A pred tem je potrebno poskrbeti še za to, da bo promet dejansko lahko tekel čez napadalčev računalnik, da ga torej ne bo oviral požarni zid ali na kakšen drug zaščitni mehanizem. Zato je najprej potrebno omogočiti tim. IP posredovanje (ang. IP forwarding), nato pa še onemogočiti delovanje požarnega zidu. Primer za Ubuntu Linux, ki za požarni zid uporablja ufw (in ne na primer iptables):

echo 1 > /proc/sys/net/ipv4/ip_forward
ufw disable

Če namreč ne omogočimo IP posredovanja, bodo omrežne naprave, katerih promet preusmerjamo, izgubile povezljivost v omrežje. S tem dejansko izvedemo DOS napad na napravo (onemogočanje njenega delovanja – tim. Denial of Service), oziroma povedano drugače, napravo “odklopimo” iz omrežja.

Napadalec bo nato izvedel preusmerjanje z ukazom arpspoof – primer za ARP preusmeritev komunikacijskih paketkov med napravo z IP naslovom 10.254.60.43 ter IP naslovom IP prehoda v omrežju (10.254.60.1):

sudo arpspoof -i eth0 -t 10.254.60.1 10.254.60.43
sudo arpspoof -i eth0 -t 10.254.60.43 10.254.60.1

Ukaza moramo zagnati ločeno in sočasno. Po zagonu ukaza izpisujeta naslednja obvestila:

0:11:15:cb:5:8c 0:19:56:e:ef:1c 0806 42: arp reply 10.254.60.10 is-at 0:11:15:97:aa:8c
0:11:15:cb:5:8c 0:4:d:f5:3:6b 0806 42: arp reply 10.254.60.1 is-at 0:11:15:97:aa:8c

S tem je napadalec dosegel, da se ves omrežni promet med navedenima IP naslovoma sedaj “pretaka” preko njegovega računalnika. Ta promet pa je sedaj mogoče enostavno prestreči z ukazom tcpdump ali aplikacijo Wireshark:

sudo tcpdump -i eth0 -n -vv -w telefonski_promet.pcap host 10.254.60.43

Ukaz do preklica (Ctrl-c) prestreza omrežni promet, ki izvira iz ali je namenjen na IP naslov 10.254.60.43 na omrežnem vmeniku eth0 ter ga zapisuje v datoteko telefonski_promet.pcap (za kasnejšo analizo).

Naj pri tem poudarimo, da žrtev takšnega prestrezanja brez posebne opreme nikakor ne more zaznati, saj pri tem prestrezanju ni prisotno nikakršno pokljanje ali šumenje, kot je to prikazano v kakšnih filmih… Edini način, da bi žrtev takšno prestrezanje zaznala, bi bila analiza ARP tabele na (njeni) omrežni napravi, za kar pa je potrebno uporabiti računalnik oz. ustrezno programsko opremo.

Če je promet nešifriran, je sedaj v novi ukazni vrstici z naslednjim ukazom mogoče zelo enostavno pregledovati binarnih podatkov “očiščeno” vsebino prestreženih komunikacijskih paketkov:

tail -f telefonski_promet.pcap | strings

Primer izpisa nam tako lahko že brez uporabe posebnih orodj razkrije neko osnovno dogajanje v telefonskem omrežju, med drugim tudi katera telefonska številka je bila klicana (v spodnjem primeru je 5711 interna telefonska številka):

PS_FMuvsqOM@S
gwp@10.254.255.231
5711
AVAYA_I55 VOIPSW81_rel_0339
RTCP_STOP_CONNECTION
gwp@10.254.255.231
5711
AVAYA_I55 VOIPSW81_rel_0339
RTCP_STOP_CONNECTION

Če .pcap datoteko odpremo v aplikaciji Wireshark in če VoIP omrežje uporablja SIP protokol, je prisluškovanje vsebini pogovorov otročje lahko. Wireshark ima namreč vgrajena orodja za podrobno analizo SIP protokola, ki pokažejo seznam vseh klicev, posamezen klic pa je mogoče tudi zvočno predvajati.

Preko menija Telephony preposto izberemo možnost VoIP Calls, Wireshark pa nam izpiše vse pogovore (vključno s prometnimi podatki). Nsto izberemo program in kliknemo na gumb Player, podatke deodiramo s klikom na gumb Decode, izberemo kateri zvočni kanal želimo predvajati (dohodni, odhodni ali oba) ter kliknemo gumb za predvajanje.

Da, tako preprosto je prestrezanje sodobnih digitalnih komunikacij.

Nekoliko bolj zapleteno je “izločanje” zvočnega zapisa iz prestreženih komunikacijskih paketov v primeru H.323 standarda (H.323 namreč ni protokol, pač pa standard za VoIP signalizacijo, prenos in nadzor multimedijskih vsebin ter nadzor pasovne širine, v Wiresharku pa lahko analiziramo protokola H245 in H225, ki sta del H.323). Napadalec si pri tem lahko pomaga z orodji kot npr. UCSniff, VoIPong, VideoSnarf  ter ACE VoIP Directory Tool ki podpirajo SIP, H323, Ciscotov Skinny Client Protocol, RTP, RTCP, analizo videotelefonije, omogočajo pridobitev lokalnih imenikov, itd.

Primer uporabe orodja VideoSnarf:

videosnarf -i telefonski_promet.pcap

Starting videosnarf 0.63
[+]Starting to snarf the media packets
[+] Please wait while decoding pcap file...
Protocol: Unsupported
added new stream. :10.254.255.231(20560) to 10.254.60.43(1722). codec is 08
Protocol: Unsupported
added new stream. :10.254.255.231(20560) to 10.254.60.43(1722). codec is 08
Protocol: Unsupported
added new stream. :10.254.255.231(20560) to 10.254.60.43(1722). codec is 08
Protocol: Unsupported
Protocol: Unsupported
[+]Stream saved to file G711ALAW-media-1.wav
[+]Stream saved to file G711ALAW-media-2.wav
[+]Stream saved to file G711ALAW-media-3.wav
[+]Number of streams found are 3
[+]Snarfing Completed

V danem primeru smo v datoteko telefonski_promet.pcap posneli tri telefonske pogovore, ki jih je orodje VideoSnarf zaznalo in njihove zvočne zapise shranilo v tri .wav datoteke.

Na tej točki je napadalec dejansko uspel skoraj popolnoma kompromitirati VoIP omrežje. Na podoben način je mogoče prestrezati podatke tudi v neustrezno zavarovanih računalniških lokalnih (LAN) omrežjih. Manjšo “težavo” za napadalca sicer predstavljajo med odjemalcem in strežnikom šifrirane komunikacije, vendar napadalec lahko na SSL/TLS šifrirane seje izvaja napad s posrednikom (npr. z orodjem MITMproxy).

V VoIP omrežjih je mogoče z orodjem TFTP Theft preiskati še lokalni TFTP strežnik. TFTP strežniki so večinoma namenjeni prenosu konfiguracijskih in zagonskih datotek (ang. boot file) med napravami v lokalnem omrežju s pomočjo protokola TFTP (Trivial File Transfer Protocol). V VoIP omrežjih se pogosto uporabljajo za prenos zagonskih ali konfiguracijskih datotek za telefone v VoIP omrežju – telefon ob zagonu od TFTP strežnika pridobi zagonsko datoteko s pomočjo katere se zažene (VoIP telefoni so v bistvu neke vrste namenski računalniki, na katerih teče posebej prilagojen operacijski sistem).

Glavna težava TFTP protokola iz stališča varnosti pa je, da ne omogoča nikakšne overovitve uporabnika. Zato lahko napadalec od TFTP strežnika pridobi konfiguracijsko ali zagonsko datoteko, nato pa postavi lažen TFTP strežnik in telefonom v VoIP omrežju “popravi” nastavitve. Kakšne posledice ima to na varnost VoIP omrežja pa si ni težko zamisliti.

Na voljo so še številna druga orodja za preverjanje varnosti VoIP omrežij, npr. sipcrack, Offline SIP Cracker, SIPVicious, itd. ki omogočajo tudi napade na SIP avtentikacijo. Primer uporabe orodja SIP Viciuos je prikazan na video demonstraciji.

Naj še omenimo, da napadalec lahko v primeru, da kakšna naprava namenjena administraciji omrežja ne uporablja privzetih gesel, s pomočjo omenjenega prestrezanja geslo za dostop do naprave vseeno lahko prestreže. Primer scenarija napada:

• Napadalec v prvem koraku izvede ARP preusmeritev prometa do ciljne naprave npr. lokalne telefonske centrale.
• Če ciljna naprava uporablja šifriran dostop (npr. preko protokola HTTPS) izvede napad s posrednikom. Uporabnik, ki bo skušal dostopati do naprave bo sicer dobil opozorilo, da se je spremenilo digitalno potrdilo na napravi, vendar večina omrežnih naprav uporablja samopodpisana digitalna potrdila, zato napadalec brez težav ustvari in uporabi lastno (lažno) potrdilo.
• Napadalec v omrežju sproži neko napako in počaka, da uporabniki o težavi obvestijo tehnično pomoč.
• Ko se nekdo iz tehnične pomoči poveže v omrežje in na napravo z namenom odkriti težavo, napadalec prestreže dostopno geslo. Cilj napada je s tem dosežen.

Oddaljeni dostop do lokalnega VoIP omrežja

Za konec si poglejmo še kako bi napadalec lahko pridobil oddaljeni dostop do VoIP omrežja in si s tem olajšal prestrezanje ter hkrati tudi otežil svojo izsleditev.

Kljub temu, da so VoIP omrežja v različnih organizacijah praviloma zaprta omrežja z onemogočenim zunanjim dostopom, namreč obstaja kar nekaj možnosti, s katerimi napadalec lahko pridobi oddaljeni dostop. Ena bolj elegantnih možnosti je, če napadalec odkrije, da sta VoIP in računalniško omrežje neustrezno ločeni. To pomeni, da je iz enega omrežja mogoče dostopati do drugega, ali pa, da omrežni požarni zid iz enega omrežja v drugo prepušča določene komunikacijske paketke, npr. ICMP. Protokol ICMP (Internet Control Message Protocol) se namreč uporablja za pošiljanje nadzornih sporočil in sporočil o stanju omrežja. ICMP protokol je uporabljen v ukazu ping, ki omogoča preverjanje dosegljivosti omrežnih naprav. Zato omrežni administratorji v nekaterih omrežjih v in iz VoIP omrežja prepuščajo ICMP paketke, saj na tak način najlažje preverjajo osnovno odzivnost VoIP sistemov.

Takšno bližnjico pa lahko izkoristi napadalec, ki uporabi tim. TCP tuneliranje preko ICMP, DNS ali katerega drugega protokola. Pri tem gre za “zavijanje” TCP paketkov v drug protokol oziroma za vzpostavitev posebnega tunela preko komunikacijskega protokola, ki v omrežju ni blokiran. Za to je na voljo več zanimivih rešitev, npr. aplikacija Iodine (IP-over-DNS), ki omogoča vzpostavitev IP tunela preko DNS (na voljo je celo dodatek za Linuxov Upravitelj omrežij), ICMPTX (IP-over-ICMP), ki omogoča vzpostavitev IP tunela preko ICMP protokola, na voljo je celo aplikacija za Android, ki omogoča vzpostavitev VPN tunela preko DNS protokola,…

Seveda je za poganjanje takšne aplikacije v lokalnem VoIP omrežju potrebno namestiti ustrezno napravo, na kateri bodo tekle aplikacije za prestrezanje elektronskih komunikacij ter aplikacija za posredovanje podatkov izven omrežja oziroma oddaljeni dostop. Napadalec si pri tem lahko pomaga z namestitvijo manjšega računalnika v VoIP omrežje. Uporabi lahko Raspbery PI, The PlugBot ali podobno manjšo napravo, ki jo je mogoče povezati v lokalno omrežje in z nekaj malega spretnosti skriti praktično kamorkoli v organizacijo. Nekatere naprave imajo vgrajen tudi Wi-fi ali Bluetooth vmesnik, oziroma mobilni dostop do interneta (preko 3G omrežja). Na tak način lahko napadalec pridobi oddaljeni dostop do lokalnega VoIP omrežja tudi, če je omrežje povsem fizično ločeno od zunanjega sveta.

Zaključek

V tokratnem prispevku smo videli nekaj načinov s katerimi napadalec lahko ogrozi varnost elektronskih komunikacij v VoIP omrežjih. Izkušnje kažejo, da se upravljalci VoIP omrežij problematike varnosti pogosto ne zavedajo dovolj, zlasti v lokalnih VoIP omrežjih in predvsem v tistih, ki so fizično povsem ločena od interneta.

Seveda je proti opisanim napadom mogočih nekaj zaščitnih ukrepov.

Pomembno je, da se zavedamo pomena fizične varnosti. To pomeni, da je potrebno je poskrbeti za varovanje opreme tudi znotraj internega omrežja, kontrolo dostopov v prostore, pregled in popis ožičenja ter fizično izključitev neuporabljenih omrežnih priključkov. Na nivoju omrežja je priporočljivo uporabljati statične ARP tabele na omrežnih stikalih ter 801.x overitev naprav (npr. s pomočjo FreeRADIUS strežnika), preveriti dizajn oz. segmentacijo omrežja (razdelitev omrežja na podomrežja (ang. subnet) in VLAN-e, preveriti ali se uporabljajo omrežni mostovi (ang. bridge), itd.).

Občasno je smiselno izvesti tudi varnostno preverjanje omrežja. Takšno preverjanje je smiselno zaupati neodvisnim zunanjim varnostnim strokovnjakom, saj bodo le-ti v varnostni pregled prinesli svež pogled in morda našli tisto, kar so načrtovalci omrežja spregledali. V omrežju je smisleno tudi uporabljati šifrirane povezave med telefonsko centralo in telefoni.

A najboljši ukrep za zagotovitev varnosti telefonskih komunikacij je uporaba šifriranja med končnima odjemalcema (oz. odjemalcem v našem VoIP omrežju in prehodom v druga omrežja), npr. s pomočjo ZRTP standarda, o čemer smo podrobneje že pisali v prejšnjem prispevku, s čimer z eno potezo rešimo praktično vse navedene varnostne težave. Žal tega ukrepa, pa tudi kakšnega drugega, bolj osnovnega, v večini VoIP omrežij ne srečamo prav pogosto.

Za konec pa si lahko ogledate predstavitev o varnosti VoIP telefonije z naslovom “Network busters”, ki smo jo varnostni raziskovalci Matej Kovačič, Ferdinand Šteharnik in Gorazd Žagar pripravili v letu 2011.

Predstavitev temelji na rezultatih varnostnega pregleda VoIP omrežja slovenske ustanove v letu 2010. Ustanova je imela v uporabi VoIP omrežje podjetja Avaya, ki celo vsebuje nekatere mehanizme za preprečevanje ARP zastrupljanja. Nekateri telefoni (npr. Cisco Unified IP Phones ter nekateri telefoni podjetja Avaya) namreč med vzpostavljanjem klica s pomočjo SCCP signalnega protokola svojemu RTP partnerju (ang. peer) pošljejo ARP zahtevek ter s tem popravijo svojo okvarjeno ARP tabelo. Vendar pa je v omrežju mogoče prestreči StartMediaTransmission SCCP paket, z njegovo pomočjo ugotoviti da bo telefon poslal ARP zahtevek ter ustvariti množico lažnih unicast ARP odgovorov. S tem telefon zasujemo z lažnimi paketki in “preglasimo” pravi ARP odgovor ter na ta način onesposobimo zaščito pred ARP prestrezanjem (zanimivo: opisana varnostna ranljivost je na spletni strani Internet Security Systems označena z nizko stopnjo tveganja).

Kar pa je spet samo še en dokaz, da polovične varnostne rešitve v resnici ne delujejo.