WOJCIECH MAZURCZYK Instytut Telekomunikacji Politechnika Warszawska, Warszawa E-mail: W.Mazurczyk@elka.pw.edu.pl http://security.tele.pw.edu.pl Bezpieczestwo SIP jako protokołu sygnalizacyjnego VoIP STRESZCZENIE W referacie przedstawiono zagadnienia zwizane z bezpieczestwem protokołu SIP (Session Initiation Protocol) jako najbardziej obiecujcego protokołu sygnalizacyjnego dla realizacji usługi VoIP (Voice over IP). Skupiono si przede wszystkim na zagadnieniach zwizanych z bezpieczestwem wiadomoci sygnalizacyjnych wymienianych pomidzy stronami komunikujcymi si. Szczególny nacisk połoono na analiz mechanizmów bezpieczestwa zastosowanych w dwóch zaleceniach organizacji IETF dla SIP: RFC 2543 (dot. pierwszej wersji SIP z 1999 r.) oraz RFC 3261 (dot. drugiej wersji SIP z 2002 r.). Dodatkowo przedstawiono równie wyniki przeprowadzonych bada praktycznych wybranych aplikacji, bdcych implementacjami Agenta Uytkownika SIP (bdcych interfejsem pomidzy uytkownikiem a telefoni internetow). 1. Wstp Niniejszy artykuł powicony jest bezpieczestwu usługi Voice over IP (VoIP) bazujcej na protokole SIP (Session Initiation Protocol). Protokół SIP jest najbardziej obiecujcym protokołem sygnalizacyjnym dla realizacji usługi VoIP w sieciach TCP/IP. W artykule przedstawiono zagadnienia zwizane z bezpieczestwem wiadomoci sygnalizacyjnych wymienianych pomidzy komunikujcymi si stronami, w szczególnoci przeanalizowane zostan mechanizmy bezpieczestwa zastosowane w dwóch zaleceniach organizacji IETF (The Internet Engineering Task Force) dla SIP: RFC 2543 (dot. pierwszej wersji SIP z 1999 r.) oraz RFC 3261 (dot. drugiej wersji SIP z 2002 r.). 2. Bezpieczestwo połcze VoIP Usługa VoIP nazywana równie telefoni internetow lub telefoni IP oznacza przesyłanie głosu w czasie rzeczywistym wykorzystujc do tego celu pakietow sie transmisji danych z protokołem IP. Zagwarantowanie bezpiecznych połcze dla tej usługi jest spraw złoon. Nie ogranicza si ono jedynie do zapewnienia bezpiecznego transportu strumieni danych zawierajcych głos, waniejsz spraw s warunki, w których nastpuje przesyłanie wiadomoci protokołu sygnalizacyjnego, na którym bazuje VoIP. Problemy bezpieczestwa dla usługi telefonii IP w wietle powyszych stwierdze mona podzieli na: a. Bezpieczestwo wiadomoci sygnalizacyjnych wymienianych pomidzy stronami komunikujcymi si, b. Bezpieczestwo pakietów przenoszcych głos (pakiety RTP), c. Problemy zwizane z przesyłaniem pakietów przez ciany przeciwogniowe (Firewalls) oraz urzdzenia NAT (Network Address Translators). Niniejszy artykuł skupia si wyłcznie na tematyce zawartej w punkcie a.
3. Protokoły sygnalizacyjne dla usługi VoIP Protokoły tej grupy nazywane s sercem telefonii internetowej, poniewa od niej zaley zarówno architektura sieci, realizacja zaawansowanych usług jak i współdziałanie z tradycyjnymi sieciami telefonicznymi. Obecnie nie ma jednego standardu protokołu sygnalizacyjnego dla realizacji usługi VoIP obserwujemy współistnienie czterech protokoły tego rodzaju: SIP (Session Initiation Protocol), H.323, MGCP (Media Gateway Control Protocol) oraz H.248/Megaco. Z wszystkich wymienionych powyej protokołów sygnalizacyjnych dla telefonii IP to włanie SIP jest najbardziej perspektywiczny i z nim wie si najwiksze nadzieje. 4. Bezpieczestwo SIP - techniki ataków Dla usługi VoIP cało połczenia mona podzieli na dwie podstawowe fazy: sygnalizacyjn (kontrolujc sesj) oraz transportujc strumie danych. W czasie fazy sygnalizacyjnej okrelone parametry sesji s wymieniane pomidzy uytkownikami kocowymi w celu poprawnej realizacji danego połczenia. Mog one zawiera informacje, które uytkownik wolałby pozostawi niedostpne dla osób trzecich (np. jego lokalizacj, czy nazwisko). Wane jest równie, aby uytkownicy, którzy nie zostali uwierzytelnieni nie mieli moliwoci zmiany, wstawiania oraz usuwania wiadomoci wysyłanych w czasie fazy sygnalizacyjnej. Dlatego te najwaniejszym celem przy zapewnianiu bezpieczestwa usługi VoIP jest odpowiednie zabezpieczenie sygnalizacji protokołu SIP. Natomiast głównymi technikami ataków na wymian wiadomoci sygnalizacyjnych dla Session Initiation Protocol s: Podszycie si (Spoofing) Podsłuchiwanie (Sniffing) Blokowanie działania (Denial of Service) Podane powyej techniki mog zosta wykorzystane do rónego rodzaju ataków. Dla przykładu technika podszycia moe słuy do podszycia si pod czyj tosamo lub do przekierowania połczenia; technika podsłuchiwania moe zaowocowa zarówno podsłuchiwaniem wiadomoci sygnalizacyjnych jak równie penetracj ciała wiadomoci natomiast blokowanie działania opiera si głównie na wyłczeniu funkcjonalnoci serwerów sieciowych. Istnienie wymienionych powyej rodzajów technik i ataków powoduje konieczno istnienia okrelonych rodzajów mechanizmów bezpieczestwa koniecznych, aby im przeciwdziała. 5. Problem doboru kryterium oceny bezpieczestwa dla SIP Aby usystematyzowa przegld mechanizmów bezpieczestwa protokołu SIP, jak i nastpnie by w stanie umiejtnie je ocenia naley ustali kryterium, według którego nastpi ich analiza. Przy jego wyborze naley kierowa si zarówno specyfik samego protokołu sygnalizacyjnego i opisywanej usługi jak i charakterem potencjalnych zagroe, technik oraz ataków. W artykule zdecydowano si na wybór rozwizania bdcego modyfikacj podziału zawartego w normie ISO 7498-2, według którego bezpieczestwo w systemach otwartych naley rozpatrywa w kontekcie moliwoci zapewnienia piciu podstawowych usług ochrony informacji: (kontroli dostpu (access control), uwierzytelnienia (authentication), integralnoci danych (data integrity), poufnoci danych (confidentiality) oraz niezaprzeczalnoci (non-repudation). Po uwzgldnieniu zarówno specyfiki protokołu SIP jak i charakteru potencjalnych ataków przyjte zostało kryterium oceny mechanizmów bezpieczestwa zdefiniowane jako umiejtno zapewnienia dwóch głównych usług ochrony informacji oraz komunikacji w sieci tzn.: Poufnoci dajcej ochron przed atakami pasywnymi oraz zabezpieczajcej wiadomoci sygnalizacyjne, wymieniane pomidzy komunikujcymi si jednostkami, przed ich nieuprawnionym uzyskaniem przez strony do tego nieupowanione; Uwierzytelnienia (zawierajcego integralno) gwarantujcego ochron przed atakami aktywnymi oraz kontrol tosamoci stron i wiadomoci sygnalizacyjnych wymienianych pomidzy nimi.
Dlatego te przy omawianiu mechanizmów bezpieczestwa protokołu SIP główny nacisk połoono na sposób zapewnienia włanie tych dwóch usług. Mechanizmy bezpieczestwa opisane w zaleceniach: RFC 2543 oraz RFC 3261 podzielono równie w ramach kadej z usług ze wzgldu na obszar realizacji omawianej usługi w odniesieniu do drogi komunikacyjnej na mechanizmy typu End-to-End (obsługa bezporednia ródło->cel) oraz Hop-by-Hop (obsługa tranzytowa tylko pojedyncze połczenie, której z warstw niszych ni w. aplikacji). Z oboma rodzajami typów mechanizmów wi si pewne wtpliwoci natury bezpieczestwa. Hop-by-Hop wymaga zaufania uytkownika dla wszystkich elementów funkcjonalnych znajdujcych si na drodze przesyłanej wiadomoci. Natomiast End-to-End uniemoliwia zabezpieczenie całej wiadomoci, gdy cz jej nagłówków jest niezbdna do poprawnego przesłania. 6. Realizacja usługi uwierzytelnienia wg RFC 2543 Wyszczególnienie konkretnych mechanizmów dla realizacji omawianej usługi dla SIP opisanego w zaleceniu RFC 2543 zostało umieszczone na rysunku numer 1: Rys. 1. Realizacja usługi uwierzytelnienia w SIP wg RFC 2543 6.1. Uwierzytelnienie typu Hop-by-Hop Mechanizmy tej grupy bazuj na protokołach: TLS (Transport Layer Security) - operujcym pomidzy warstw aplikacji i transportow oraz IPSec (Internet Protocol Security) działajcym w warstwie sieciowej modelu odniesienia TCP/IP. Mechanizmy te nie zostały obowizkowo narzucone w RFC 2543 zakłada si tam tylko, e jeli trzeba bdzie zapewnia uwierzytelnienie Hop-by-Hop to mona uy jednego z tych dwóch protokołów. Naley równie wspomnie, i oba te mechanizmy realizuj pełn usług integralnoci wiadomoci. 6.2. Uwierzytelnienie typu End-to-End W protokole SIP realizacja usługi uwierzytelnienia typu End-to-End jest realizowana poprzez implementacj dwóch mechanizmów: Basic i Digest. Oba zostały zaczerpnite w prawie niezmienionej formie z protokołu HTTP i oba bazuj na schemacie współdzielonego sekretu (shared secret) - uyty klucz w czasie procedury uwierzytelniajcej jest znany przez obie strony, pomidzy którymi zachodzi wymiana uwierzytelniajca (serwer i klient). Mechanizm Basic Jest to bardzo prymitywny mechanizm nie gwarantujcy wystarczajcego poziomu bezpieczestwa, gdy dane uwierzytelniajce uytkownika s przesyłane jako tekst jawny, co czyni ten mechanizm całkowicie nieodpornym na atak typu powtórka.
Mechanizm SIP Digest Jest on lepiej zabezpieczony od poprzednika (zapewnia ochron przed defektami mechanizmu Basic), lecz nadal w konfrontacji z nowoczesnymi standardami kryptograficznymi jest stosunkowo słaby. Oprócz schematu współdzielonego sekretu wykorzystuje on dodatkowo metod wyzwanie/odpowied (challenge / response) oraz funkcj skrótu (hash function) - MD5 (Message Digest 5). Przebieg realizacji omawianej usługi dla mechanizmu SIP Digest został przedstawiony na rysunku numer 2: Rys. 2. Przebieg uwierzytelnienia mechanizmu SIP Digest Gdy serwer, który wymaga uwierzytelnienia otrzyma od jednostki inicjujcej danie (1), które nie jest uwierzytelnione, to zwracana jest odpowied 401 Authentication Required (2), która zawiera w nagłówku wiadomoci pole WWW-Authenticate parametry charakterystyczne zarówno dla samego serwera, ale i trwajcej procedury uwierzytelnienia. Klient uzyskane w ten sposób parametry łczy ze swoimi danymi uwierzytelniajcymi i wylicza skrót, który jest nastpnie umieszczany w nagłówku pola Authorization w ponownie wysyłanym do serwera daniu (3). Po swojej stronie serwer dokonuje wyliczenia skrótu na tej samej zasadzie. Uwierzytelnienie nastpuje po uzyskaniu zgodnoci obu skrótów (4). SIP Digest oferuje równie prymitywn form wsparcia usługi integralnoci danych poprzez moliwo dodania do informacji poddanych obliczaniu skrótu, ciała wiadomoci lub jej okrelonych nagłówków. Zapewniana jednak w ten sposób integralno wiadomoci jest szcztkowa, poniewa skrótowi nie mog podlega nagłówki, do których wymagany jest dostp w czasie transportu wiadomoci przez sie. 7. Realizacja usługi uwierzytelnienia wg RFC 3261 Mechanizmy, które definiuje zalecenie RFC 3261 dla protokołu SIP w wersji drugiej przy realizacji usługi uwierzytelnienia, zostały zamieszczone na rysunku numer 3: Rys. 3. Realizacja usługi uwierzytelnienia wg RFC 3261
7.1. Uwierzytelnienie typu Hop-by-Hop W przypadku tego rodzaju mechanizmów pozostawiono sprawdzone z pierwszej wersji SIP rozwizania wykorzystujce protokoły warstw niszych modelu TCP/IP: TLS oraz IPsec. Jedyn nowoci dodan w RFC 3261 jest mechanizm o nazwie SIPS URI. Mechanizm SIPS URI Jeli zwykły adres URI (Uniform Resource Identifier) postaci np. sip://jkowalski@pw.edu.pl zamienimy na sips://jkowalski@pw.edu.pl bdzie to oznacza fakt, i cel wyszczególniony w adresie ma zosta osignity w sposób bezpieczny, co oznacza, kady odcinek drogi komunikacyjnej powinien by zabezpieczony z wykorzystaniem mechanizmu TLS. Jeli taki warunek nie moe zosta spełniony - nie dochodzi do nawizania połczenia. Innymi słowy, jeli jako mechanizm gwarantujcy uwierzytelnienie został wybrany SIPS URI oznacza to, e musi zosta zaimplementowany w całej sieci protokół TLS, gdy jest on niezbdny do prawidłowego jego funkcjonowania. 7.2. Uwierzytelnienie typu End-to-End W stosunku do poprzedniej wersji protokołu SIP w drugiej wersji całkowicie zrezygnowano ze stosowania mechanizmu Basic, natomiast obligatoryjne staje si implementowanie mechanizmu SIP Digest. Dodatkowo rozszerzono moliwo realizacji tej usługi z wykorzystaniem nowego rozwizania nazwanego S/MIME (Secure / Multipurpose Internet Mail Extension). Mechanizm S/MIME Usługa uwierzytelnienia realizowana za pomoc S/MIME wykorzystuje do tego celu tunelowanie oraz podpis cyfrowy. Mechanizm ten działa nastpujco: wykonywana jest pełna lub czciowa kopia nagłówków wiadomoci SIP i umieszcza wraz z oryginalnym ciałem w jednostce MIME, która reprezentuje ciało nowej wiadomoci. Nastpnie jest ona podpisywana cyfrowo z wykorzystaniem funkcji skrótu SHA-1. Dodatkowo wykorzystuje si algorytm klucza publicznego RSA do wymiany kluczy, a w konsekwencji do bezpiecznego przesłania obliczonego skrótu do właciwego odbiorcy. Po osigniciu celu adresat wiadomoci weryfikuje dostarczony podpis cyfrowy. Jeli jest on prawidłowy to dodatkowo dokonuje si porównania tych nagłówków, które nie były wykorzystywane przez urzdzenia znajdujce si na drodze komunikacyjnej w celu zapewnienia podstawowej integralnoci wiadomoci. 8. Realizacja usługi poufnoci wg RFC 2543 oraz RFC 3261 Jeli chodzi o realizacj drugiej usługi zdefiniowanej w wybranym przez nas kryterium to osiga si j w SIP poprzez zastosowanie mechanizmu szyfrowania. Dla obu wersji protokołu SIP mechanizmy Hop-by-Hop oraz End-to-End s nastpujce: Rys. 4. Realizacja usługi poufnoci wg RFC 2543 oraz RFC 3261
8.1. Poufno typu Hop-by-Hop W tej grupie mechanizmów, zarówno dla protokołu SIP w wersji pierwszej jak i drugiej, szyfrowanie zapewniane jest z wykorzystaniem wspomnianych ju mechanizmów realizacji usługi uwierzytelnienia tzn. IPSec lub TLS. 8.2. Poufno typu End-to-End Szyfrowaniu w przypadku tego typu mechanizmów podlega całe ciało wiadomoci oraz istotne z punktu widzenia bezpieczestwa pola nagłówka. dania i odpowiedzi nie mog by w ten sposób szyfrowane w całoci, poniewa wymagana jest dostpno niektórych pól po to, by zapewni poprawne jej przesłanie. RFC 2543 wyznacza dla realizacji mechanizmu szyfrowania wykorzystanie kryptosystemu PGP (Pretty Good Privacy), który jako szyfr symetryczny stosuje szyfr IDEA, natomiast jako algorytm klucza publicznego RSA. W przypadku drugiej wersji protokołu SIP nastpiła całkowita rezygnacja z szyfrowania za pomoc PGP. Została ona zastpiona opcjonalnym wykorzystaniem do tego celu mechnizmu S/MIME. Mechanizm S/MIME Realizacja usługi poufnoci przebiega podobnie jak w przypadku realizacji usługi uwierzytelnienia (równie wykorzystywana jest enkapsulacja czci wiadomoci w jednostce MIME) z t rónic, e zamiast funkcji skrótu stosuje si szyfrowanie 3DES. Równie algorytm klucza publicznego pozostał ten sam RSA. 9. Słabe punkty w architekturze bezpieczestwa SIP w zaleceniu RFC 2543 Jasn spraw jest fakt, e skoro powstała druga wersja protokołu SIP to pierwsza nie spełniała oczekiwa twórców oraz uytkowników. Głównie chodziło tu włanie o aspekty bezpieczestwa (wykazano wiele słabych punktów i niedocigni SIP wg zalecenia RFC 2543). Zastosowane tu mechanizmy wywodzce si z samego protokołu SIP (czyli bez grupy mechanizmów Hop-by-Hop) s niewystarczajce, a zastosowane systemy kryptograficzne w duej mierze przestarzałe w porównaniu z tymi uwaanymi za nalece do nowoczesnej kryptografii. Głównymi mankamentami architektury bezpieczestwa zdefiniowanej w zaleceniu RFC 2543 jest: Zbyt dua opcjonalno w wyborze mechanizmów gwarantujcych wymagane usługi oraz brak jasnego narzucenia i przypisania konkretnych mechanizmów bezpieczestwa poszczególnym czciom drogi komunikacyjnej zawartej pomidzy elementami funkcjonalnymi, Brak gwarancji całkowitej integralnoci wiadomoci przy uwierzytelnieniu typu End-to-End (mechanizmy Basic oraz SIP Digest) oraz wykorzystywanie schematu współdzielonego sekretu, Zastosowanie do realizacji uwierzytelnienia mechanizmu Basic (całkowita nie odporno na atak typu powtórka), Dla realizacji usługi poufnoci wykorzystanie szyfrowania PGP. Obecnie nie zaleca si uywania szyfrowania tym systemem kryptograficznym szczególnie w starszych wersjach głównie, dlatego i brak mu dobrego systemu certyfikacji oraz gdy uywane długoci kluczy kryptograficznych s zbyt krótkie. 10. Słabe punkty w architekturze bezpieczestwa SIP w zaleceniu RFC 3261 Zalecenie RFC 3261 definiuje architektur bezpieczestwa, która jest poprawna i minimalizuje prawdopodobiestwo przeprowadzenia udanego ataku. Przypomnijmy: w RFC 3261 nie ma uwierzytelnienia typu Basic, ale za to SIP Digest jest obowizkowe. Dodatkowo opcjonalne jest wykorzystanie S/MIME do realizacji uwierzytelnienia wzajemnego.
W przypadku mechanizmów typu Hop-by-Hop protokół TLS musi by obowizkowo implementowany (ale działa on niestety jedynie na TCP) lub IP Sec (wybór opcjonalny). Pomimo, e architektura bezpieczestwa zapewniana w SIP w omawianym zaleceniu redukuje ryzyko ataku posiada ona klika słaboci. S one nastpujce: SIP Digest te same mankamenty jak w przypadku protokołu SIP w wersji pierwszej, S/MIME główna słabo: brak infrastruktury wymiany kluczy publicznych - zdefiniowany w wersji drugiej SIP system wymiany kluczy jest nieodporny na atak typu man-in-the-middle (podobnie jak w innych systemach np. w SSH). W sytuacji, gdy atakujcy przechwyci pierwsz wymian kluczy pomidzy komunikujcymi si i bdzie miał szans przechwytywania całego dialogu midzy stronami komunikujcymi si przeprowadzony atak mona bdzie uzna za udany. Druga sprawa wykorzystanie S/MIME moe owocowa duymi (w sensie objtoci) wiadomociami. Ostatnim problemem jest fakt, i jeli na drodze wiadomoci znajdzie si jaki rzadki typ serwera sieciowego, którego prawidłowe działanie zaley od moliwoci dostpu i modyfikowaniu ciała wiadomoci SIP, to wtedy protokół S/MIME uniemoliwi prawidłowe funkcjonowanie takiego elementu sieciowego. Dla obu wersji SIP typem ataku, przed którym nie ma całkowitej ochrony jest atak typu blokowanie działania (Denial of Service). Bez wzgldu na rodzaj zaimplementowanych mechanizmów bezpieczestwa zawsze moliwe jest zalanie serwera (głównie chodzi tu o serwery proxy) poprzez wysyłanie nadmiernej iloci zwykle niepoprawnych wiadomoci, w ten sposób powodujc odmow wiadczenia usług, dla których dana jednostka została stworzona. Niestety tego typu ataku nie da si wyeliminowa całkowicie, poniewa wizałoby si to z ograniczeniem podstawowych funkcji serwerów sieciowych. Jedynym rozwizaniem, które moe w sposób satysfakcjonujcy ograniczy prawdopodobiestwo wystpienia takiego ataku jest przeprowadzanie wzajemnego uwierzytelnienie serwerów proxy z wykorzystaniem protokołu TLS. 11. Dowiadczenia praktyczne W ramach potwierdzenia wyników przeprowadzonej analizy mechanizmów bezpieczestwa, dla protokołu SIP w obu wersjach, przeprowadzono badania praktyczne. Ich przebieg, wykorzystane aplikacje oraz testy zostan zaprezentowane poniej. 11.1. Przebieg bada Cało przeprowadzonych działa praktycznych polegała na wykonaniu szeregu testów na aplikacjach bdcych implementacjami Agenta Uytkownika SIP. Pierwotnym celem takiego postpowania była próba zbadania praktycznej przydatnoci mechanizmów bezpieczestwa zdefiniowanych w dwóch wersjach SIP. W zamierzeniu miała by to po prostu symulacja potencjalnych, celowych prób działa atakujcego i na tej podstawie ocena umiejtnoci radzenia sobie w przypadku ich wystpienia. Ilo i rónorodno ataków na protokół SIP jest znaczna i testujc sam aplikacj Agenta Uytkownika SIP nie odda si całego spektrum potencjalnych zagroe dla systemu VIP bazujcego na tym protokole. Jednake uznajc, e w praktyce uytkownik nie ma zbyt wielkiego wpływu na bezpieczestwo innych komponentów architektury funkcjonalnej SIP innych ni SIP UA, włanie na testowanie tego elementu funkcjonalnego połoono nacisk. 11.2. Testowane aplikacje SIP UA W Internecie dostpnych było około dziesiciu darmowych aplikacji bdcych implementacjami Agenta Uytkownika SIP. Przy doborze programów do testowania kierowano si głównie ich dostpnoci oraz tym, by kady z nich był firmowany przez innych twórców. Do celów badawczych wybrano nastpujce darmowe programy:
Helmsman User Agent 3.0.6 firmy Helmsman, estara SoftPHONE 3.0 firmy estara, Siemens Communication System Client v.1.0 firmy Siemens, Magellan 4.0 opracowany w IT PW, Hughes SIP User Agent (E-Z Phone) firmy Hughes Software Systems, Vovida SIP UA 1.0.2 - Columbia University. 11.3. Konieczno modyfikacji celu pierwotnego bada Niestety po zapoznaniu si z aplikacjami bdcymi implementacjami Agenta Uytkownika pierwotny cel testowania musiał zosta zmodyfikowany. Stało si tak z dwóch powodów: adna z testowanych aplikacji (prócz jednej) nie miała zaimplementowanego, cho najprostszego mechanizmu bezpieczestwa. Wszystkie aplikacje bazowały wyłcznie na starym zaleceniu SIP (RFC 2543). W zwizku z faktami, które przytoczono powyej testowanie Agentów Uytkownika ograniczyło si do osignicia dwóch celów: Zbadania zgodnoci implementacji wybranych aplikacji z zaleceniem, na którym bazuje (w przypadku testowanych aplikacji jest to RFC 2543), Wykazanie wyszoci programu, w którym został zaimplementowany, cho prosty mechanizm bezpieczestwa opisany w zaleceniu, nad aplikacj nie posiadajc adnych wspomnianych mechanizmów. 11.4. Opis dowiadcze i wykorzystanych testów Do przeprowadzenia dowiadcze wykorzystana została autorska, pomocnicza aplikacja S2C (SIP Security Call Checker). Jej głównym zadaniem jest wysłanie okrelonego testu do wskazanego Agenta Uytkownika SIP, a nastpnie zbadanie jego reakcji w danym dowiadczeniu. Natomiast, jeli chodzi o posta treci samych testów to składaj si na nie wiadomoci sygnalizacyjne protokołu SIP (zarówno dania jak i odpowiedzi) skonstruowane tak (czasem niepoprawne), aby odda spektrum moliwych zagroe i ataków na wymian wiadomoci sygnalizacyjnych pomidzy Agentami Uytkownika SIP. Dodatkowo szczególny nacisk kładziono na ataki najłatwiejsze do wykonania, a tym samym najbardziej prawdopodobne. Przy ich opracowaniu bazowano na testach, stworzonych przez twórców SIP a: Neila Deasona, Andersa Kristensena, Jonathana Rosenberga oraz Henninga Schulzrinna. Cało testów była przeprowadzana w trzech konfiguracjach testowych, a na kadej z testowanej aplikacji przeprowadzono 25 rónych testów. Konfiguracja1 Konfiguracja ta ma na celu zarówno sprawdzenie zgodnoci zachowa testowanych aplikacji z zaleceniem RFC 2543 na którym bazuj oraz symulacj ataku, w którym intruz moe si podszy pod czyj tosamo. Rys. 5. Konfiguracja testowa pierwsza
Konfiguracja2 W tym przypadku nawizywane było połczenie pomidzy dwoma wybranymi aplikacjami Agenta Uytkownika SIP, a nastpnie za pomoc aplikacji S2C oraz poprzez okrelone testy próbowano wpłyn w negatywny sposób na wymian wiadomoci sygnalizacyjnych/pakietów RTP (wiadomoci-testy były raz wysyłane do jednej, raz do drugiej testowanej aplikacji). Była to próba symulacji ataku aktywnego, w którym intruz nie podsłuchuje komunikujcych si midzy sob agentów, jednak moe wysyła odpowiednio zaadresowane i sporzdzone wiadomoci w celu uniemoliwienia nawizania lub przerwania trwajcego połczenia. Rys. 6. Konfiguracja testowa druga Konfiguracja3 Sytuacja charakteryzowana w tej konfiguracji jest podobna do przypadku opisanego w poprzedniej. Badana była tu równie odporno połczenia na przeprowadzane na nim prób ataków. Główn rónic pomidzy konfiguracjami drug i trzeci było załoenie, i atakujcy ma moliwo podsłuchiwania wiadomoci sygnalizacyjnych (ja do tego celu wykorzystano popularn aplikacj Ethereal) oraz odpowiedni ich modyfikacj. Rys. 7. Konfiguracja testowa trzecia
Testy mechanizmu SIP Digest Do przeprowadzenia dowiadcze w tym punkcie wykorzystamy konfiguracj trzeci (tam gdzie wykorzystuje si aplikacj Ethereal) oraz odpowiednio ułoone testy, które bd odpowiadały sytuacji: a) Podobnej jak w Konfiguracji2, gdy intruz przeprowadza ataki na lepo znajc tylko adres SIP Agenta Uytkownika. b) Podobnej jak w Konfiguracji3, gdy atakujcy za pomoc aplikacji podsłuchujcej pakiety jest wstanie odkry zawarto przesyłanych wiadomoci. 12. Analiza wyników przeprowadzonych testów 12.1. Wyniki testów aplikacji bez mechanizmów bezpieczestwa Na podstawie przeprowadzonych bada uzyskano nastpujce wyniki: Suma zaliczonych testów dla aplikacji, które wypadły najlepiej kształtuje si na poziomie 16 testów. Natomiast liczba testów nie zaliczonych rednio dla wszystkich aplikacji wyniosła ok. 6, czyli 25% prób ataków zakoczyło si sukcesem. Jest to do wysoki wskanik, bo oznacza, i jeden na cztery ataki koczył si powodzeniem. adna z aplikacji nie zaliczyła wszystkich testów, co dowodzi jak łatwo prostymi rodkami osign udany atak na tego rodzaju program. Wielu Agentów Uytkownika w ogóle nie reagowało na wiadomo testujc, mimo tego, e działajc zgodnie z zaleceniem, na którym bazuj powinny zasygnalizowa wystpienie błdu, bd zareagowa okrelonym zachowaniem. 12.2. Wyniki i analiza testów mechanizmu SIP Digest Poprzez analiz wyników dowiadcze przeprowadzonych na mechanizmie SIP Digest wykazano, i jego zaimplementowanie w testowanej aplikacji w wydatny sposób poprawiło jej bezpieczestwo. Okazało si, e z wykorzystaniem tych samych rodków oraz narzdzi wykorzystanych we wczeniejszych dowiadczeniach nie jest moliwe przeprowadzenie udanego ataku na takiego Agenta Uytkownika SIP. 13. Podsumowanie i wnioski W niniejszym artykule zostały zebrane, przeanalizowane oraz ocenione mechanizmy bezpieczestwa tworzce architektur bezpieczestwa SIP zdefiniowan w dwóch zaleceniach: RFC 2543 oraz RFC 3261. Wykazano potencjalne zagroenia, techniki oraz ataki, które mog wystpi dla obu tych architektur. Głównym wnioskiem z tej czci jest moliwo utworzenia potencjalnie bezpiecznej architektury SIP nowe zalecenie (RFC 3261) okrela mechanizmy, które powinny umoliwi bezpieczn wymian wiadomoci sygnalizacyjnych. Wszystko pozostaje teraz w rkach implementujcych, poniewa nawet najlepsze plany s niczym w przypadku, gdy nie zostan one poprawnie zrealizowane. Sprawdzenie za pomoc odpowiednio dobranych testów-wiadomoci szeciu dostpnych, darmowych Agentów Uytkownika SIP bazujcych na RFC 2543 nie dostarczyło niestety optymistycznych wyników. Na cztery przeprowadzone ataki jeden był udany. Niestety z szeciu testowanych aplikacji tylko jedna miała zaimplementowany jakikolwiek mechanizm bezpieczestwa (SIP Digest). To jednak wystarczyło, aby odpowiednio utrudni domowy atak na sygnalizacj SIP. Reszta aplikacji niestety nie została zabezpieczona w sposób naleyty. Cz winy za taki stan rzeczy ponosz sami twórcy zalecenia RFC 2543, gdy mechanizmy bezpieczestwa tam zdefiniowane s opcjonalne. Drug przyczyn takiego stanu rzeczy jest fakt, i wiksz cz z tych aplikacji stanowi wersje testowe programów lub takie, które maj zachci do kupna jego pełnej wersji. Moliwe, e kupujc pełn wersj produktu otrzymuje si program,
razem z zaimplementowanymi mechanizmami bezpieczestwa naley, wic to bezwzgldnie sprawdzi przed zakupem. Z kolei, aby prawidłowo zabezpieczy wymian wiadomoci sygnalizacyjnych z wykorzystaniem protokołu SIP naley umiejtnie dobiera dostpne mechanizmy bezpieczestwa. A ucilajc naley zdefiniowa jak jednostki funkcjonalne tego protokołu mog dokonywa wyboru pomidzy odpowiednimi mechanizmami podczas komunikacji tak, aby by w stanie zagwarantowa obie usługi ochrony informacji i komunikacji okrelone w przyjtym kryterium. Podsumowujc, jeli usługa VoIP oparta na protokole sygnalizacyjnym SIP ma sta si powszechna i atrakcyjna dla przecitnego uytkownika to musi oferowa podobny poziom jakoci usług jak w przypadku telefonii klasycznej, a dodatkowo jeszcze zachci uytkowników czym wicej. Biorc pod uwag, e informacja, wymieniana w czasie rozmowy, a przede wszystkim podczas inicjacji połczenia w obecnych czasach staje si towarem i ma swoj cen, wic zapewnienie jej bezpiecznego przesyłania wpływa bezporednio na wzrost atrakcyjnoci tej usługi. Reasumujc zapewnienie bezpieczestwa wymiany wiadomoci sygnalizacyjnych w SIP moe by istotnym czynnikiem wpływajcym zarówno na jego popularno jako protokołu sygnalizacyjnego dla realizacji VoIP jak i popularnoci samej usługi. Literatura 1. M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg SIP: Session Initiation Protocol Request for Comments nr 3261 lipiec 2002 2. M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg SIP: Session Initiation Protocol Request for Comments nr 2543 marzec 1999 3. S. Salsano, L. Veltri, D. Papalilo SIP Security Issues: The SIP Authentication Procedure and its Processing Load IEEE Network, vol. 16, vol. 6, November 2002 4. W. Stallings - Cryptography and Network Security : Principles and Practice, Second Edition. Prentice-Hall, June 1998. 5. J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, A. Luotonen, L. Stewart. HTTP Authentication : Basic and Digest Access Authentication. Request For Comments 2617. Internet Engineering Task Force, June 1999. 6. T. Dierks, C. Allen. The TLS protocol version 1.0. Request For Comments 2246. Internet Engineering Task Force, January 1999. 7. R. Rivest. The MD5 Message-Digest Algorithm. Request For Comments 1321. Internet Engineering Task Force, April 1992. 8. T. Berners-Lee, R. Fielding, H. Frystyk. Hypertext Transfer Protocol -- HTTP/1.0. Request For Comments 1945. Internet Engineering Task Force, May 1996. 9. N. Borenstein, N. Freed. MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies. Request For Comments 1341. Internet Engineering Task Force, June 1992. 10. B. Ramsdell. S/MIME Version 3 Message Specification. Request For Comments 2633. Internet Engineering Task Force, June 1999. 11. J. Callas, L. Donnerhacke, H. Finney, R. Thayer, Open PGP Message Format. Request For Comments 2440. Internet Engineering Task Force, November 1998. 12. P. Gajowniczek, M. redniawa - Voice over IP Wykorzystanie techniki IP do przesyłania głosu - CITCOM-PW padziernik 1999 13. H. Sinnreich, A. Johnston Internet Communications Using SIP Wiley Computer Publishing 14. W. Mazurczyk Bezpieczestwo Voice over IP opartego na SIP VII Krajowa Konferencja Zastosowa Kryptografii Enigma 2003, Warszawa, maj 2003