Uwaga na ataki na telefonię IP (VoIP)

Data publikacji: 29/11/2010, TomaszG.

Telefonia VoIP (Voice over IP) cieszy się coraz większą popularnością dlatego jest coraz powszechniej wykorzystywana. Niestety, wzrostowi popularności ze strony użytkowników towarzyszy wzrost popularności ze strony cyberprzestępców. Źle zabezpieczone centralki mogą być m.in. źródłem poważnych strat finansowych, ponieważ przestępcy mogą wykorzystywać je do wykonywania połączeń telefonicznych w dowolne miejsce na świecie. Tego typu ataki opisywaliśmy już w roku 2008 (Phreaking w erze telefonii VoIP). Innym zagrożeniem jest dzwonienie do końcowego numeru z niezamówionymi ofertami handlowymi (tzw. SPIT: Spam over Internet Telephony)1. Najprostszą formą ataku jest atak odmowy usługi (DoS), który może sparaliżować sieć telefoniczną np. w całej firmie2. Ostatnio informowaliśmy poprzez serwis Twitter o znaczącym wzroście skanowań poszukujących urządzeń VoIP wykorzystujących protokół SIP.

Dane zbierane przez rozproszoną sieć sond systemu ARAKIS potwierdzają, że problem ataków na telefonię IP w polskiej przestrzeni Internetu jest bardzo realny i ciągle się pogłębia. Poniżej postaramy się nieco przybliżyć obserwacje prób ataków, których świadkiem był system ARAKIS.

Protokół SIP w telefonii IP

Jednym z najpowszechniej używanych protokołów w technologii VoIP jest SIP (Session Initiation Protocol) opisany w RFC 3261. Służy on do kontrolowania sesji pomiędzy klientami VoIP, w szczególności do nawiązywania, modyfikowania oraz kończenia połączeń głosowych, a także wideo. Protokół SIP ma zdefiniowany zestaw metod (żądań). Przyjrzyjmy się bliżej czterem z nich, które wykorzystywane były w obserwowanych przez nas atakach.

  • OPTIONS – zapytanie o możliwości/funkcjonalności; serwer SIP na tego typu żądanie powinien zwrócić informacje o dostępnych usługach. Często wykorzystywane w masowych skanowaniach do szukania urządzeń VoIP SIP.
  • REGISTER – tym poleceniem klient rejestruje się w serwerze rejestrującym SIP (tzw. SIP Registrar), który dodaje jego dane do bazy obsługiwanych adresów. SIP Registrar działa podobnie jak serwer DNS: mapuje nazwy SIP-owe (tzw. SIP URI) na adresy IP klientów. Dzięki temu użytkownik zyskuje możliwość odbierania połączeń w konkretnej podsieci (konieczne, gdy telefonia IP pracuje w trybie kient-serwer, a nie peer-to-peer, oraz gdy adres IP klienta jest zmienny lub pochodzi z puli prywatnej a chce on przyjmować rozmowy spoza sieci lokalnej). Nierzadko zdarza się łączenie różnych funkcji serwerowych SIP w obszarze jednego serwera, przez co dany serwer może pełnić jednocześnie funkcje SIP Registrara oraz SIP Proxy czy SIP Redirecta
  • INVITE – zaproszenie do nawiązania sesji (lub dołączenia do już istniejącej), skutkuje np. rozpoczęciem połączenia bezpośrednio do klienta VoIP lub przez serwer SIP Proxy.
  • CANCEL – anulowanie poprzedniego żądania.

Urządzenia korzystające z tego protokołu domyślnie komunikują się na porcie 5060/UDP. Dlatego wszystkie ataki z wykorzystaniem SIP widziane przez system ARAKIS kierowane były tylko na ten port. Poniżej wykres przedstawiający liczbę unikalnych adresów IP łączących się na port 5060/UDP do honeypotów ARAKIS-a.

ARAKIS-5060udp-scan

Dane (w sensie warstwy wyższej niż czwarta – transportowa) były przesyłane od razu w pierwszym pakiecie. Nie odbywało się żadne wcześniejsze skanowanie sprawdzające czy port jest otwarty, co więcej, atakowany adres IP nie był nawet sprawdzany pingiem, czy odpowiada (przynajmniej nie z adresu, z którego dokonano ataku).

Głębszej analizie, którą prezentujemy poniżej, poddane zostały dane tylko z okresu pięciu dni. Nie oznacza to, że dopiero niedawno pojawiły się te ataki – wzmożony ruch widziany jest na mniej więcej na stałym poziomie cały czas od lipca 2010. W ciągu pięciu dni ruch ten:

  • widziany był na wszystkich sondach systemu ARAKIS (oznacza to, że celem nie jest konkretna sieć/dostawca usług, ale cała przestrzeń polskiego Internetu)
  • odbyło się ok. 45 000 połączeń
  • połączenia były nawiązywane z ok. 440 unikalnych adresów IP
  • źródła połączeń należały do ok. 200 różnych systemów autonomicznych (AS) (dane uzyskane na podstawie API serwisu IP to ASN Mapping udostępnionego przez Team Cymru)
  • źródłowe adresy IP były rozmieszczone w ok. 50. różnych krajach na całym świecie
  • najbardziej aktywnymi krajami były (w kolejności malejącej):

Source of VoIP SIP scans

Istnieje prawdopodobieństwo, że źródłowe adresy IP mogą być sfałszowane (UDP spoofing), lecz to nie miałoby sensu, gdyż atakujący nie mógłby poznać odpowiedzi na żądanie SIP. Bardziej realne wydaje się użycie tych adresów IP jako ostatnich spośród łańcuszka kolejnych pośredników (pośrednicy działają jak proxy), by ukryć rzeczywiste źródło ataku. Wobec tego nie możemy postawić tezy, że inicjatorzy ataków znajdują się w większości w krajach wymienionych w powyższej tabeli.

Skanowania SIP OPTIONS

Najczęściej widziane żądania SIP w systemie ARAKIS to OPTIONS. W tym wypadku atakujący, jeżeli trafi na serwer SIP który obsłuży to żądanie, pozna jego możliwości. Jest to więc typowe skanowanie będące rekonesansem. Pozyskane w ten sposób informacje najprawdopodobniej służą do stworzenia listy potencjalnych dostępnych publicznie serwerów SIP wraz z ich możliwościami. Taka lista może posłużyć do dalszych ataków, niosących już konkretne zagrożenie. De facto to żądanie jest obecnie powszechnie wykorzystywane przy masowych poszukiwaniach „na ślepo” urządzeń VoIP – coś jak ping na poziomie protokołu SIP (odpowie tylko aktywne urządzenie). Takie skanowanie jest w miarę dyskretne – nie powoduje na docelowym urządzeniu efektu dzwonienia, w przeciwieństwie do np. skanowań SIP INVITE. Dodatkowo na podstawie odpowiedzi łatwo poznać z jakim oprogramowaniem/producentem urządzenia atakujący ma do czynienia (tzw. fingerprinting), a jak wiadomo każda aplikacja posiada luki (tylko nie zawsze są one odkryte). Poniżej zanonimizowany przykładowy pakiet SIP (żądanie OPTIONS) przechwycony przez honeypot ARAKIS-a:

Session Initiation Protocol
    Request-Line: OPTIONS sip:[email protected] SIP/2.0
        Method: OPTIONS
        [Resent Packet: False]
    Message Header
        Via: SIP/2.0/UDP 10.x.x.203:5064;branch=z9hG4bK-4143939552;rport
            Transport: UDP
            Sent-by Address: 10.x.x.203
            Sent-by port: 5064
            Branch: z9hG4bK-4143939552
            RPort: rport
        Content-Length: 0
        From: "sipvicious"<sip:[email protected]>; tag=3531303662623139313363340133393439363734343739
            SIP Display info: "sipvicious"
            SIP from address: sip:[email protected]
            SIP tag: 3531303662623139313363340133393439363734343739
        Accept: application/sdp
        User-Agent: friendly-scanner
        To: "sipvicious"<sip:[email protected]>
            SIP Display info: "sipvicious"
            SIP to address: sip:[email protected]
        Contact: sip:[email protected]:5064
            Contact Binding: sip:[email protected]:5064
                URI: sip:[email protected]:5064r
                    SIP contact address: sip:[email protected]:5064r
        CSeq: 1 OPTIONS
            Sequence Number: 1
            Method: OPTIONS
        Call-ID: 693404165087465926103669
        Max-Forwards: 70

Wolumen skanowań SIP OPTIONS obesrwowany przez ARAKIS-a cały czas utrzymuje się na mniej więcej stałym poziomie – w zależności od konfiguracji sondy średnio dziennie widzianych jest od kilkudziesięciu do kilkuset tego typu ataków. Każde żądanie miało ustawiony ten sam numer CSeq (numer sekwencyjny identyfikujący kolejne wiadomości/żądania) równy 1. W polach User-Agent protokołu SIP pojawiały się tylko dwie nazwy: friendly-scanner oraz sundayddr, z czego ta pierwsza ok. pięć razy częściej. Powyższe ciągi znaków oznaczają odpowiednio dwa narzędzia Sipvicious oraz sundayddr (zwany także sipsscuser, ponieważ dodatkowo taka nazwa pojawia się w polu From). Sipvicious jest jednym z najbardziej popularnych narzędzi do audytu urządzeń VoIP opartych na protokole SIP. Sundayddr/sipsscuser wygląda na bardzo podobne narzędzie – specjaliści głąbiej zajmujący się tym tematem sugerują, że bardzo mocno bazuje on na Sipvivious (jest to po prostu zmodyfikowany kod Sipvicious)3. Reguły Snort, które mogą wykryć tego typu skanowanie, to:
ET SCAN Sipvicious Scan
ET SCAN Sipvicious User-Agent Detected (friendly-scanner)
ET SCAN Sipvicious User-Agent Detected (sundayddr).
Są to reguły dostarczane przez społeczność zrzeszoną w ramach projektu Emerging Threats. Poniżej przedstawiamy tabelę najczęściej dopasowanych reguł Snortowych w ciągu ostatnich 24 godzin w systemie ARAKIS.

ARAKIS Snort ranking

Skanowania SIP REGISTER

W sierpniu tego roku w honeypotach kilku sond zostały zaobserwowane żądania REGISTER. Atakujący szukał na ślepo serwerów typu SIP registrar i próbował się zarejestrować. Nie wiemy do końca co miał na celu ten atak. Prawdopodobnie – gdyby rejestracja się powiodła – mógł w ten sposób uzyskać dostęp do pozostałych klientów zarejestrowanych w tym rejestratorze (atak typu rekonesans). To z kolei pozwala na przeprowadzenie dalszych ataków. Za pomocą odpowiednio spreparowanych żądań REGISTER można także przejmować rejestracje innych klientów (tzw. registration hijacking) co skutkuje przejmowaniem połączeń telefonicznych4. Znane są też przypadki „zalewania” rejestratora SIP dużą ilością żądań REGISTER, co skutkuje paraliżem sieci telefonicznej (tzw. REGISTER flooding należący do ataków typu DoS5). Poniżej zanonimizowany przykładowy pakiet SIP (żądanie REGISTER) przechwycony przez honeypot ARAKIS-a:

Session Initiation Protocol
    Request-Line: REGISTER sip:82.x.x.121 SIP/2.0
        Method: REGISTER
        [Resent Packet: True]
        [Suspected resend of frame: 1]
    Message Header
        To: <sip:[email protected]>
            SIP to address: sip:[email protected]
        From: <sip:[email protected]>;tag=33742674
            SIP from address: sip:[email protected]
            SIP tag: 33742674
        Via: SIP/2.0/UDP 192.x.x.3:6021;branch=z9hG4bK-d87543-944197934-1--d87543-;rport
            Transport: UDP
            Sent-by Address: 192.x.x.3
            Sent-by port: 6021
            Branch: z9hG4bK-d87543-944197934-1--d87543-
            RPort: rport
        Call-ID: 562d2c461a1f4626
        CSeq: 1 REGISTER
            Sequence Number: 1
            Method: REGISTER
        Contact: <sip:[email protected]:6021>
            Contact Binding: <sip:[email protected]:6021>
                URI: <sip:[email protected]:6021>
                    SIP contact address: sip:[email protected]:6021
        Expires: 3600
        Max-Forwards: 70
        Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
        User-Agent: eyeBeam release 3006o stamp 17551
        Content-Length: 0

Wszystkie zaobserwowane połączenia SIP REGISTER miały w polu User-Agent ciąg eyeBeam release 3006o stamp 17551. Sugeruje on, że do przeprowadzonego skanowania użyto aplikacji eyeBeam, która jest komunikatorem VoIP. Należy jednak pamiętać, że taki nagłówek łatwo można spreparować. Warto nadmienić, że zarówno pole Call-ID jak i Branch było w każdym pakiecie inne – a więc tak, jak przewiduje RFC. Nigdy nie była użyta autoryzacja, więc atak był skierowany na niezabezpieczone rejestratory SIP.

Ciekawostką jest fakt, że do tego ataku została dopasowana reguła Snort ET CURRENT_EVENTS Possible Cisco ASA 5500 Series Adaptive Security Appliance Remote SIP Inspection Device Reload Denial of Service Attempt wykrywająca atak z wykorzystaniem luki o symbolu CVE-2010-0569 w urządzeniu Cisco ASA 5500 Series Adaptive Security Appliances umożliwiającą przeprowadzenie ataku typu DoS6.

Skanowania SIP INVITE + CANCEL

W poprzednim tygodniu w systemie ARAKIS zaobserwowany został znaczący, ponad kilkuset procentowy, wzrost żądań INVITE oraz CANCEL. Poprzez polecenia INVITE atakujący próbował nawiązać połączenie VoIP do docelowego adresu IP (ARAKIS-owego honeypota). W rzeczywistym środowisku telefonii IP, gdy taki pakiet trafi do telefonu VoIP, ten powinien zacząć dzwonić. Żądania INVITE mogą być także kierowane do centralek VoIP – gdy urządzenie będzie odpowiednio skonfigurowane (a właściwie błędnie skonfigurowane), połączenie zostanie przekazane dalej (w ten sposób można na czyjś koszt dzwonić na płatne numery). Honeypoty ARAKIS-owe należą do grupy nisko-interaktywnych, przez co żaden nie wszedł w dalszą interakcję z atakującym. Najprawdopodobniej w wyniku braku wspomnianej interakcji atakujący po pewnym czasie przerwał próbę ustanowienia połączenia telefonicznego wysyłając żądanie CANCEL. Poniżej zanonimizowany przykładowy pakiet SIP (żądanie INVITE) przechwycony przez honeypot ARAKIS-a:

Session Initiation Protocol
    Request-Line: INVITE sip:[email protected] SIP/2.0
        Method: INVITE
        [Resent Packet: False]
    Message Header
        Via: SIP/2.0/UDP 188.x.x.46:5060;branch=z9hG4bK277d8087;rport
            Transport: UDP
            Sent-by Address: 188.x.x.46
            Sent-by port: 5060
            Branch: z9hG4bK277d8087
            RPort: rport
        From: "Shenzhou Morokoshi" <sip:[email protected]>;tag=as7047c7fe
            SIP Display info: "Shenzhou Morokoshi"
            SIP from address: sip:[email protected]
            SIP tag: as7047c7fe
        To: <sip:[email protected]>
            SIP to address: sip:[email protected]
        Contact: <sip:[email protected]>
            Contact Binding: <sip:[email protected]>
                URI: <sip:[email protected]>
                    SIP contact address: sip:[email protected]
        Call-ID: [email protected]
        CSeq: 102 INVITE
            Sequence Number: 102
            Method: INVITE
        User-Agent: Asterisk PBX
        Max-Forwards: 70
        Date: Thu, 18 Nov 2010 22:35:43 GMT
        Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
        Supported: replaces
        Content-Type: application/sdp
        Content-Length: 264
    Message body
        Session Description Protocol
            Session Description Protocol Version (v): 0
            Owner/Creator, Session Id (o): root 3506 3506 IN IP4 188.x.x.46
                Owner Username: root
                Session ID: 3506
                Session Version: 3506
                Owner Network Type: IN
                Owner Address Type: IP4
                Owner Address: 188.x.x.46
            Session Name (s): session
            Connection Information (c): IN IP4 188.x.x.46
                Connection Network Type: IN
                Connection Address Type: IP4
                Connection Address: 188.x.x.46
            Time Description, active time (t): 0 0
                Session Start Time: 0
                Session Stop Time: 0
            Media Description, name and address (m): audio 17928 RTP/AVP 8 0 101
                Media Type: audio
                Media Port: 17928
                Media Proto: RTP/AVP
                Media Format: ITU-T G.711 PCMA
                Media Format: ITU-T G.711 PCMU
                Media Format: 101
            Media Attribute (a): rtpmap:8 PCMA/8000
                Media Attribute Fieldname: rtpmap
                Media Format: 8
                MIME Type: PCMA
            Media Attribute (a): rtpmap:0 PCMU/8000
                Media Attribute Fieldname: rtpmap
                Media Format: 0
                MIME Type: PCMU
            Media Attribute (a): rtpmap:101 telephone-event/8000
                Media Attribute Fieldname: rtpmap
                Media Format: 101
                MIME Type: telephone-event
            Media Attribute (a): fmtp:101 0-16
                Media Attribute Fieldname: fmtp
                Media Format: 101 [telephone-event]
                Media format specific parameters: 0-16
            Media Attribute (a): silenceSupp:off - - - -
                Media Attribute Fieldname: silenceSupp
                Media Attribute Value: off - - - -
            Media Attribute (a): ptime:20
                Media Attribute Fieldname: ptime
                Media Attribute Value: 20
            Media Attribute (a): sendrecv

Najprawdopodobniej użyte było rzeczywiste narzędzie, jakim jest centrala telefoniczna oparta na bardzo popularnym open source-owym oprogramowaniu Asterisk. Można tak wywnioskować na podstawie następujących przesłanek: w polu User-Agent pojawiała się za każdym razem ta sama nazwa: Asterisk PBX, a w polu From był tag zaczynający się na as* (jest to charakterystyczne dla Asteriska). Ponadto w polu From widniał Shenzhou Morokoshi. Nie konieczne jest to prawdziwe imię i nazwisko dzwoniącego. Jeżeli wierzyć serwisowi Ask.com oba słowa to nazwy Chin w różnych językach (chińskim i japońskim). Ale być może to tylko zbieg okoliczności ;). We wszystkich połączeniach widniał także ten sam CSeq równy 102.

Zagłębiając się dalej w analizę pakietu SIP docieramy do protokołu SDP (Session Description Protocol), który jest wymagany do ustanowienia połączenia. Pełen opis SDP znajduje się w RFC-2327, oraz w RFC-4566 w którym to został zaktualizowany. Protokół SDP jest wykorzystywany przez końcowe punkty połączenia do wymiany informacji o strumieniu RTP (Real Time Protocol, RFC-3551) w którym przesyłany jest sygnał audio oraz opcjonalnie wideo. Negocjowane są np. numery portów, użyte kodeki, itp. We wszystkich próbach połączeń użyty był tylko strumień audio (bez wideo), zakodowany w standarcie G.711 w odmianach zarówno G.711U (PCMU) oraz G.711A (PCMA). Negocjowane numery portów dla protokołu RTP wahały się między 10000 a 20000.

Próby wywołania połączenia (INVITE) trwały raptem jeden dzień, lecz było ich bardzo dużo – pojedyncza sonda zarejestrowała ich ok. 4 800. Do przepływów dopasowana została reguła Snort ET VOIP INVITE Message Flood UDP. Nie były widziane na wszystkich sondach, lecz jedynie na kilku. Być może sukcesywnie skanowana jest po kolei cała przestrzeń publicznych adresów IPv4 więc nie wykluczone, że atak dotrze kiedyś do reszty sond. Oznaczać to może także, że dowolna sieć publiczna w polskiej przestrzeni Internetu była lub dopiero może być przeskanowana w ten sposób.

Jak się bronić?

W sytuacji wysokiego stanu zagrożenia zabezpieczenie własnej infrastruktury VoIP jest bardzo ważne. Najlepiej w tym celu zajrzeć do dokumentacji i zaleceń producenta rozwiązań używanych we własnej sieci. Na poziomie ogólnym użytkownikom telefonii IP opartej na SIP możemy zasugerować:

  • blokować na firewallu dostęp na port 5060/UDP z adresów niepowołanych (w szczególności z Internetu)
  • podczas rejestracji urządzeń VoIP w registrarze SIP używać autoryzacji i uwierzytelniania (wprawdzie nie jest to metoda gwarantująca w stu procentach bezpieczeństwo – przesyłane są skróty MD5 z haseł – jednak lepsze to niż nic)
  • skonfigurować centralki i proxy VoIP-owe tak, by nie obsługiwały połączeń telefonicznych inicjowanych przez nieuprawnione adresy IP
  • jeżeli to możliwe używać narzędzi, które będą wykrywać i blokować urządzenia, które będą wykazywać cechy skanerów (np. wiele prób wysłania żądań SIP w krótkim przedziale czasu)

W powyższym tekście opisane zostały ataki na VoIP z wykorzystaniem tylko protokołu SIP. Ostatnio po raz pierwszy w systemie ARAKIS pojawiły się ataki mające cechy skanowań wykorzystujące protokół H.225.0 należący do rodziny H.323. Ten temat będzie opisany niebawem w osobnym artykule.


Przypisy:

1 Developing a Legally Compliant Reachability Management System as a Countermeasure against SPIT: https://tepin.aiki.de/blog/uploads/spit-al.pdf
2 Evaluating DoS Attacks Against SIP-Based VoIP Systems: http://nexginrc.org/nexginrcAdmin/PublicationsFiles/globecom09-zubair.pdf
3 Australian Honeynet Project blog: Sunday (sundayddr) SIP scanning worm. When printers turn bad.. http://honeynet.org.au/?q=sunday_scanner
4 VoIP Vulnerabilities – Registration Hijacking http://download.securelogix.com/library/Registration_hijacking_060105.pdf
5 A VoIP Traffic Monitoring System based on NetFlow v9 http://www.sersc.org/journals/IJAST/vol4/1.pdf
6 Cisco Security Advisory ID 111485 http://www.cisco.com/en/US/products/products_security_advisory09186a0080b1910c.shtml