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)¹. Najprostszą formą ataku jest atak odmowy usługi (DoS), który może sparaliżować sieć telefoniczną np. w całej firmie². 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.

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):

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:

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)³. 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.

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ń telefonicznych⁴. 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 DoS⁵). Poniżej zanonimizowany przykładowy pakiet SIP (żądanie REGISTER) przechwycony przez honeypot ARAKIS-a:

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 DoS⁶.

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:

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:

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