SIP (Session Initiation Protocol)

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Check the subscription plans!

• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.

• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

Podstawowe informacje

SIP (Session Initiation Protocol) to protokół sygnalizacji i kontroli połączeń, szeroko stosowany do nawiązywania, modyfikowania i kończenia sesji multimedialnych, w tym głosu, wideo i wiadomości błyskawicznych, w sieciach IP. Opracowany przez Internet Engineering Task Force (IETF), SIP jest zdefiniowany w RFC 3261 i stał się de facto standardem dla VoIP i zintegrowanej komunikacji.

Niektóre kluczowe cechy SIP to:

1. Protokół oparty na tekście: SIP jest protokołem opartym na tekście, co czyni go czytelnym dla ludzi i łatwiejszym do debugowania. Opiera się na modelu żądanie-odpowiedź, podobnym do HTTP, i używa metod takich jak INVITE, ACK, BYE i CANCEL do kontrolowania sesji połączeń.

2. Skalowalność i elastyczność: SIP jest wysoce skalowalny i może być używany w małych wdrożeniach, jak i w dużych środowiskach korporacyjnych i operatorów. Może być łatwo rozszerzany o nowe funkcje, co czyni go dostosowującym się do różnych przypadków użycia i wymagań.

3. Interoperacyjność: Szerokie przyjęcie i standaryzacja SIP zapewniają lepszą interoperacyjność między różnymi urządzeniami, aplikacjami i dostawcami usług, promując płynną komunikację na różnych platformach.

4. Modularny design: SIP współpracuje z innymi protokołami, takimi jak RTP (Real-time Transport Protocol) do transmisji mediów i SDP (Session Description Protocol) do opisywania sesji multimedialnych. Ten modularny design pozwala na większą elastyczność i kompatybilność z różnymi typami mediów i kodekami.

5. Serwery proxy i przekierowujące: SIP może używać serwerów proxy i przekierowujących do ułatwienia routingu połączeń i zapewnienia zaawansowanych funkcji, takich jak przekazywanie połączeń, transfer połączeń i usługi poczty głosowej.

6. Obecność i wiadomości błyskawiczne: SIP nie ogranicza się tylko do komunikacji głosowej i wideo. Obsługuje również obecność i wiadomości błyskawiczne, umożliwiając szeroki zakres aplikacji zintegrowanej komunikacji.

Pomimo wielu zalet, SIP może być skomplikowany do skonfigurowania i zarządzania, szczególnie w przypadku problemów z przechodzeniem przez NAT i zapory sieciowe. Jednak jego wszechstronność, skalowalność i szerokie wsparcie w branży czynią go popularnym wyborem dla komunikacji VoIP i multimedialnej.

Metody SIP

Podstawowe metody SIP zdefiniowane w RFC 3261 obejmują:

1. INVITE: Używana do inicjowania nowej sesji (połączenia) lub modyfikowania istniejącej. Metoda INVITE przenosi opis sesji (zwykle przy użyciu SDP), aby poinformować odbiorcę o szczegółach proponowanej sesji, takich jak typy mediów, kodeki i protokoły transportowe.

2. ACK: Wysyłana w celu potwierdzenia otrzymania ostatecznej odpowiedzi na żądanie INVITE. Metoda ACK zapewnia niezawodność transakcji INVITE, dostarczając potwierdzenie end-to-end.

3. BYE: Używana do kończenia nawiązanej sesji (połączenia). Metoda BYE jest wysyłana przez którąkolwiek ze stron w sesji, aby wskazać, że chce zakończyć komunikację.

4. CANCEL: Wysyłana w celu anulowania oczekującego żądania INVITE przed nawiązaniem sesji. Metoda CANCEL pozwala nadawcy przerwać transakcję INVITE, jeśli zmieni zdanie lub jeśli nie ma odpowiedzi od odbiorcy.

5. OPTIONS: Używana do zapytania o możliwości serwera SIP lub agenta użytkownika. Metoda OPTIONS może być wysyłana w celu uzyskania informacji o obsługiwanych metodach, typach mediów lub innych rozszerzeniach bez faktycznego nawiązywania sesji.

6. REGISTER: Używana przez agenta użytkownika do rejestrowania swojej bieżącej lokalizacji w serwerze rejestracyjnym SIP. Metoda REGISTER pomaga w utrzymaniu aktualnej mapy między URI SIP użytkownika a jego bieżącym adresem IP, umożliwiając routing i dostarczanie połączeń.

Należy pamiętać, że aby zadzwonić do kogoś, nie jest konieczne używanie REGISTER do czegokolwiek. Jednak możliwe jest, że aby wykonać INVITE, dzwoniący musi najpierw uwierzytelnić się, inaczej otrzyma odpowiedź 401 Unauthorized.

Oprócz tych podstawowych metod istnieje kilka rozszerzeń metod SIP zdefiniowanych w innych RFC, takich jak:

1. SUBSCRIBE: Zdefiniowana w RFC 6665, metoda SUBSCRIBE jest używana do żądania powiadomień o stanie konkretnego zasobu, takiego jak obecność użytkownika lub status połączenia.

2. NOTIFY: Również zdefiniowana w RFC 6665, metoda NOTIFY jest wysyłana przez serwer, aby poinformować subskrybowanego agenta użytkownika o zmianach w stanie monitorowanego zasobu.

3. REFER: Zdefiniowana w RFC 3515, metoda REFER jest używana do żądania, aby odbiorca wykonał transfer lub odniósł się do strony trzeciej. Jest to zazwyczaj używane w scenariuszach transferu połączeń.

4. MESSAGE: Zdefiniowana w RFC 3428, metoda MESSAGE jest używana do wysyłania wiadomości błyskawicznych między agentami użytkownika SIP, umożliwiając komunikację opartą na tekście w ramach SIP.

5. UPDATE: Zdefiniowana w RFC 3311, metoda UPDATE pozwala na modyfikację sesji bez wpływu na stan istniejącego dialogu. Jest to przydatne do aktualizacji parametrów sesji, takich jak kodeki lub typy mediów, podczas trwającego połączenia.

6. PUBLISH: Zdefiniowana w RFC 3903, metoda PUBLISH jest używana przez agenta użytkownika do publikowania informacji o stanie zdarzeń na serwerze, udostępniając je innym zainteresowanym stronom.

Kody odpowiedzi SIP

• 1xx (Odpowiedzi tymczasowe): Te odpowiedzi wskazują, że żądanie zostało odebrane, a serwer kontynuuje jego przetwarzanie.

• 100 Trying: Żądanie zostało odebrane, a serwer nad tym pracuje.

• 180 Ringing: Odbiorca jest informowany i odbierze połączenie.

• 183 Session Progress: Dostarcza informacje o postępie połączenia.

• 2xx (Odpowiedzi pomyślne): Te odpowiedzi wskazują, że żądanie zostało pomyślnie odebrane, zrozumiane i zaakceptowane.

• 200 OK: Żądanie zostało pomyślnie zrealizowane, a serwer je zrealizował.

• 202 Accepted: Żądanie zostało zaakceptowane do przetwarzania, ale jeszcze nie zostało zakończone.

• 3xx (Odpowiedzi przekierowujące): Te odpowiedzi wskazują, że dalsze działania są wymagane do zrealizowania żądania, zazwyczaj poprzez skontaktowanie się z alternatywnym zasobem.

• 300 Multiple Choices: Istnieje wiele dostępnych opcji, a użytkownik lub klient musi wybrać jedną.

• 301 Moved Permanently: Żądany zasób został przypisany nowemu stałemu URI.

• 302 Moved Temporarily: Żądany zasób jest tymczasowo dostępny pod innym URI.

• 305 Use Proxy: Żądanie musi być wysłane do określonego proxy.

• 4xx (Odpowiedzi błędów klienta): Te odpowiedzi wskazują, że żądanie zawiera błędną składnię lub nie może być zrealizowane przez serwer.

• 400 Bad Request: Żądanie było źle sformułowane lub nieprawidłowe.

• 401 Unauthorized: Żądanie wymaga uwierzytelnienia użytkownika.

• 403 Forbidden: Serwer zrozumiał żądanie, ale odmawia jego zrealizowania.

• 404 Not Found: Żądany zasób nie został znaleziony na serwerze.

• 408 Request Timeout: Serwer nie otrzymał pełnego żądania w czasie, w którym był gotowy czekać.

• 486 Busy Here: Odbiorca jest obecnie zajęty i nie może odebrać połączenia.

• 5xx (Odpowiedzi błędów serwera): Te odpowiedzi wskazują, że serwer nie zrealizował ważnego żądania.

• 500 Internal Server Error: Serwer napotkał błąd podczas przetwarzania żądania.

• 501 Not Implemented: Serwer nie obsługuje funkcjonalności wymaganej do zrealizowania żądania.

• 503 Service Unavailable: Serwer jest obecnie niezdolny do obsługi żądania z powodu konserwacji lub przeciążenia.

• 6xx (Odpowiedzi globalne): Te odpowiedzi wskazują, że żądanie nie może być zrealizowane przez żaden serwer.

• 600 Busy Everywhere: Wszystkie możliwe miejsca docelowe dla połączenia są zajęte.

• 603 Decline: Odbiorca nie chce uczestniczyć w połączeniu.

• 604 Does Not Exist Anywhere: Żądany zasób nie jest dostępny nigdzie w sieci.

Przykłady

Przykład SIP INVITE

INVITE sip:[e-mail] SIP/2.0
Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: John Doe <sip:[e-mail]>
From: Jane Smith <sip:[e-mail]>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:[e-mail]>
User-Agent: ExampleSIPClient/1.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
Content-Type: application/sdp
Content-Length: 142

v=0
o=jsmith 2890844526 2890842807 IN IP4 pc33.example.com
s=-
c=IN IP4 pc33.example.com
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000te

Każdy parametr wyjaśniony

1. Request-Line: INVITE sip:[e-mail] SIP/2.0 - Ten wiersz wskazuje metodę (INVITE), URI żądania (sip:[e-mail]) oraz wersję SIP (SIP/2.0).

2. Via: Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776asdhds - Nagłówek Via określa protokół transportowy (UDP) oraz adres klienta (pc33.example.com). Parametr "branch" jest używany do wykrywania pętli i dopasowywania transakcji.

3. Max-Forwards: Max-Forwards: 70 - To pole nagłówka ogranicza liczbę razy, które żądanie może być przekazywane przez serwery proxy, aby uniknąć nieskończonych pętli.

4. To: To: John Doe <sip:[e-mail]> - Nagłówek To określa odbiorcę połączenia, w tym jego nazwę wyświetlaną (John Doe) oraz URI SIP (sip:[e-mail]).

5. From: From: Jane Smith <sip:[e-mail]>;tag=1928301774 - Nagłówek From określa nadawcę połączenia, w tym jego nazwę wyświetlaną (Jane Smith) oraz URI SIP (sip:[e-mail]). Parametr "tag" jest używany do unikalnej identyfikacji roli nadawcy w dialogu.

6. Call-ID: Call-ID: a84b4c76e66710 - Nagłówek Call-ID unikalnie identyfikuje sesję połączenia między dwoma agentami użytkownika.

7. CSeq: CSeq: 314159 INVITE - Nagłówek CSeq zawiera numer sekwencyjny oraz metodę używaną w żądaniu. Jest używany do dopasowywania odpowiedzi do żądań i wykrywania wiadomości w złej kolejności.

8. Contact: Contact: <sip:[e-mail]> - Nagłówek Contact zapewnia bezpośrednią trasę do nadawcy, która może być używana do kolejnych żądań i odpowiedzi.

9. User-Agent: User-Agent: ExampleSIPClient/1.0 - Nagłówek User-Agent dostarcza informacji o oprogramowaniu lub sprzęcie nadawcy, w tym jego nazwie i wersji.

10. Allow: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO - Nagłówek Allow wymienia metody SIP obsługiwane przez nadawcę. Pomaga to odbiorcy zrozumieć, które metody mogą być używane podczas komunikacji.

11. Content-Type: Content-Type: application/sdp - Nagłówek Content-Type określa typ mediów ciała wiadomości, w tym przypadku SDP (Session Description Protocol).

12. Content-Length: Content-Length: 142 - Nagłówek Content-Length wskazuje rozmiar ciała wiadomości w bajtach.

13. Message Body: Ciało wiadomości zawiera opis sesji SDP, który zawiera informacje o typach mediów, kodekach i protokołach transportowych dla proponowanej sesji.

• v=0 - Wersja protokołu (0 dla SDP)

• o=jsmith 2890844526 2890842807 IN IP4 pc33.example.com - Inicjator i identyfikator sesji

• s=- - Nazwa sesji (pojedynczy myślnik oznacza brak nazwy sesji)

• c=IN IP4 pc33.example.com - Informacje o połączeniu (typ sieci, typ adresu i adres)

• t=0 0 - Informacje o czasie (czasy rozpoczęcia i zakończenia, 0 0 oznacza, że sesja nie jest ograniczona)

• m=audio 49170 RTP/AVP 0 - Opis mediów (typ mediów, numer portu, protokół transportowy i lista formatów). W tym przypadku określa strumień audio używający RTP/AVP (Real-time Transport Protocol / Audio Video Profile) i format 0 (PCMU/8000).

• a=rtpmap:0 PCMU/8000 - Atrybut mapujący format (0) do kodeka (PCMU) i jego częstotliwości zegara (8000 Hz).

Przykład SIP REGISTER

Metoda REGISTER jest używana w protokole inicjowania sesji (SIP), aby umożliwić agentowi użytkownika (UA), takiemu jak telefon VoIP lub softphone, zarejestrowanie swojej lokalizacji w serwerze rejestracyjnym SIP. Proces ten informuje serwer gdzie kierować przychodzące żądania SIP przeznaczone dla zarejestrowanego użytkownika. Serwer rejestracyjny jest zazwyczaj częścią serwera proxy SIP lub dedykowanego serwera rejestracyjnego.

Oto szczegółowy przykład wiadomości SIP zaangażowanych w proces uwierzytelniania REGISTER:

1. Początkowe REGISTER żądanie od UA do serwera rejestracyjnego:

REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds
Max-Forwards: 70
From: Alice <sip:[e-mail]>;tag=565656
To: Alice <sip:[e-mail]>
Call-ID: 1234567890@192.168.1.100
CSeq: 1 REGISTER
Contact: <sip:alice@192.168.1.100:5060>;expires=3600
Expires: 3600
Content-Length: 0

Ten początkowy komunikat REGISTER jest wysyłany przez UA (Alice) do serwera rejestracji. Zawiera ważne informacje, takie jak pożądany czas rejestracji (Expires), URI SIP użytkownika (sip:[e-mail]) oraz adres kontaktowy użytkownika (sip:alice@192.168.1.100:5060).

1. 401 Unauthorized odpowiedź od serwera rejestracji:

cssCopy codeSIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds
From: Alice <sip:[e-mail]>;tag=565656
To: Alice <sip:[e-mail]>;tag=7878744
Call-ID: 1234567890@192.168.1.100
CSeq: 1 REGISTER
WWW-Authenticate: Digest realm="example.com", nonce="abcdefghijk", algorithm=MD5, qop="auth"
Content-Length: 0

Serwer rejestracyjny odpowiada komunikatem "401 Unauthorized", który zawiera nagłówek "WWW-Authenticate". Ten nagłówek zawiera informacje wymagane do uwierzytelnienia UA, takie jak realm uwierzytelnienia, nonce i algorytm.

1. Żądanie REGISTER z danymi uwierzytelniającymi:

REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds
Max-Forwards: 70
From: Alice <sip:[e-mail]>;tag=565656
To: Alice <sip:[e-mail]>
Call-ID: 1234567890@192.168.1.100
CSeq: 2 REGISTER
Contact: <sip:alice@192.168.1.100:5060>;expires=3600
Expires: 3600
Authorization: Digest username="alice", realm="example.com", nonce="abcdefghijk", uri="sip:example.com", response="65a8e2285879283831b664bd8b7f14d4", algorithm=MD5, cnonce="lmnopqrst", qop=auth, nc=00000001
Content-Length: 0

UA wysyła kolejne żądanie REGISTER, tym razem zawierające nagłówek "Authorization" z niezbędnymi poświadczeniami, takimi jak nazwa użytkownika, realm, nonce i wartość odpowiedzi obliczoną na podstawie podanych informacji i hasła użytkownika.

W ten sposób obliczana jest odpowiedź Authorization:

import hashlib

def calculate_sip_md5_response(username, password, realm, method, uri, nonce, nc, cnonce, qop):
# 1. Calculate HA1 (concatenation of username, realm, and password)
ha1_input = f"{username}:{realm}:{password}"
ha1 = hashlib.md5(ha1_input.encode()).hexdigest()

# 2. Calculate HA2 (concatenation of method and uri)
ha2_input = f"{method}:{uri}"
ha2 = hashlib.md5(ha2_input.encode()).hexdigest()

# 3. Calculate the final response value (concatenation of h1, stuff and h2)
response_input = f"{ha1}:{nonce}:{nc}:{cnonce}:{qop}:{ha2}"
response = hashlib.md5(response_input.encode()).hexdigest()

return response

# Example usage
username = "alice"
password = "mysecretpassword"
realm = "example.com"
method = "REGISTER"
uri = "sip:example.com"
nonce = "abcdefghijk"
nc = "00000001"
cnonce = "lmnopqrst"
qop = "auth"

response = calculate_sip_md5_response(username, password, realm, method, uri, nonce, nc, cnonce, qop)
print(f"MD5 response value: {response}")

1. Udana rejestracja odpowiedź z serwera rejestratora:

SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds
From: Alice <sip:[e-mail]>;tag=565656
To: Alice <sip:[e-mail]>;tag=7878744
Call-ID: 1234567890@192.168.1.100
CSeq: 2 REGISTER
Contact: <sip:alice@192.168.1.100:5060>;expires=3600
Expires: 3600
Content-Length: 0

Po tym, jak serwer rejestracyjny zweryfikuje podane dane uwierzytelniające, wysyła odpowiedź "200 OK", aby wskazać, że rejestracja była udana. Odpowiedź zawiera zarejestrowane informacje kontaktowe oraz czas wygaśnięcia rejestracji. W tym momencie agent użytkownika (Alice) jest pomyślnie zarejestrowany na serwerze rejestracyjnym SIP, a przychodzące żądania SIP dla Alice mogą być kierowane do odpowiedniego adresu kontaktowego.

Przykład połączenia

Nie jest to wspomniane, ale Użytkownik B musi wysłać wiadomość REGISTER do Proxy 2, zanim będzie mógł odbierać połączenia.

Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)

Wsparcie HackTricks

• Sprawdź plany subskrypcyjne!

• Dołącz do 💬 grupy Discord lub grupy telegram lub śledź nas na Twitterze 🐦 @hacktricks_live.

• Podziel się sztuczkami hackingowymi, przesyłając PR-y do HackTricks i HackTricks Cloud repozytoriów github.