SIP (Session Initiation Protocol)

Naucz się hakować AWS od zera do bohatera z htARTE (HackTricks AWS Red Team Expert)!

Inne sposoby wsparcia HackTricks:

• Jeśli chcesz zobaczyć swoją firmę reklamowaną w HackTricks lub pobrać HackTricks w formacie PDF, sprawdź PLANY SUBSKRYPCYJNE!

• Zdobądź oficjalne gadżety PEASS & HackTricks

• Odkryj Rodzinę PEASS, naszą kolekcję ekskluzywnych NFT

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

• Podziel się swoimi sztuczkami hakerskimi, przesyłając PR-y do HackTricks i HackTricks Cloud github repos.

Podstawowe informacje

SIP (Session Initiation Protocol) to protokół sygnalizacyjny i kontroli połączeń powszechnie używany do ustanawiania, modyfikowania i zamykania sesji multimedialnych, w tym głosowych, wideo i komunikatów natychmiastowych, w sieciach IP. Opracowany przez Internet Engineering Task Force (IETF), SIP jest zdefiniowany w RFC 3261 i stał się standardem de facto dla VoIP i komunikacji zintegrowanej.

Niektóre kluczowe cechy SIP to:

1. Protokół oparty na tekście: SIP to protokół oparty na tekście, co sprawia, że jest czytelny dla ludzi i łatwiejszy do debugowania. Jest oparty na modelu żądanie-odpowiedź, podobnie jak HTTP, i używa metod takich jak INVITE, ACK, BYE i CANCEL do kontroli sesji połączenia.

2. Skalowalność i elastyczność: SIP jest bardzo skalowalny i może być używany zarówno w małych implementacjach, jak i w dużych środowiskach przedsiębiorstwowych i operatorskich. Może być łatwo rozszerzany o nowe funkcje, co sprawia, że jest dostosowywalny do różnych przypadków użycia i wymagań.

3. Interoperacyjność: Powszechne 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. Modularna konstrukcja: SIP współpracuje z innymi protokołami, takimi jak RTP (Real-time Transport Protocol) do transmisji multimediów i SDP (Session Description Protocol) do opisu sesji multimedialnych. Ta modułowa konstrukcja pozwala na większą elastyczność i kompatybilność z różnymi typami mediów i kodekami.

5. Serwery proxy i przekierowań: SIP może korzystać z serwerów proxy i przekierowań do ułatwiania routingu połączeń oraz zapewniania zaawansowanych funkcji, takich jak przekazywanie połączeń, transfer połączeń i usługi poczty głosowej.

6. Obecność i komunikaty natychmiastowe: SIP nie jest ograniczony do komunikacji głosowej i wideo. Obsługuje również obecność i komunikaty natychmiastowe, umożliwiając szeroki zakres zastosowań zintegrowanej komunikacji.

Mimo wielu zalet SIP może być skomplikowany w konfiguracji i zarządzaniu, zwłaszcza przy rozwiązywaniu problemów z przekraczaniem NAT i zaporami. Jednak jego wszechstronność, skalowalność i wsparcie w całym przemyśle sprawiają, że jest popularnym wyborem dla VoIP i komunikacji multimedialnej.

Metody SIP

Podstawowe metody SIP zdefiniowane w RFC 3261 obejmują:

1. INVITE: Używane do inicjowania nowej sesji (połączenia) lub modyfikowania istniejącej. Metoda INVITE przenosi opis sesji (zwykle za pomocą SDP), informując odbiorcę o szczegółach proponowanej sesji, takich jak typy mediów, kodeki i protokoły transportu.

2. ACK: Wysyłane w celu potwierdzenia odbioru ostatecznej odpowiedzi na żądanie INVITE. Metoda ACK zapewnia niezawodność transakcji INVITE poprzez dostarczenie potwierdzenia końcowego.

3. BYE: Używane do zakończenia ustanowionej sesji (połączenia). Metoda BYE jest wysyłana przez jedną ze stron w sesji, aby wskazać, że chcą zakończyć komunikację.

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

5. OPTIONS: Używane do zapytania o możliwości serwera SIP lub agenta użytkownika. Metoda OPTIONS może być wysłana, aby poprosić o informacje na temat obsługiwanych metod, typów mediów lub innych rozszerzeń bez faktycznego ustanawiania sesji.

6. REGISTER: Używane przez agenta użytkownika do zarejestrowania swojej bieżącej lokalizacji w serwerze rejestrującym SIP. Metoda REGISTER pomaga w utrzymaniu aktualnego odwzorowania między SIP URI użytkownika a jego bieżącym adresem IP, umożliwiając routowanie i dostarczanie połączeń.

Zauważ, że aby zadzwonić do kogoś, nie jest konieczne użycie REGISTER do niczego. Jednakże, możliwe jest, że w celu wykonania INVITE dzwoniący musi się uwierzytelnić najpierw, w przeciwnym razie otrzyma odpowiedź 401 Unauthorized.

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

1. SUBSCRIBE: Zdefiniowana w RFC 6665, metoda SUBSCRIBE służy do żądania powiadomień o stanie określonego 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ć zarejestrowany agent użytkownika o zmianach w stanie monitorowanego zasobu.

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

4. MESSAGE: Zdefiniowana w RFC 3428, metoda MESSAGE służy do wysyłania komunikatów natychmiastowych między agentami użytkownika SIP, umożliwiając komunikację opartą na tekście w ramach struktury SIP.

5. UPDATE: Zdefiniowana w RFC 3311, metoda UPDATE umożliwia 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 zdarzenia 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 nadal je przetwarza.

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

• 180 Ringing: Odbiorca jest powiadamiany i odejmie połączenie.

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

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

• 200 OK: Żądanie było udane, a serwer je zrealizował.

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

• 3xx (Odpowiedzi przekierowania): Te odpowiedzi wskazują, że konieczne jest podjęcie dalszych działań w celu zrealizowania żądania, zazwyczaj poprzez skontaktowanie się z alternatywnym zasobem.

• 300 Multiple Choices: Dostępne są różne opcje, i 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 tymczasowo jest dostępny pod innym URI.

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

• 4xx (Odpowiedzi błędów klienta): Te odpowiedzi wskazują, że żądanie zawiera złą składnię lub nie może zostać 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 realizacji.

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

• 408 Request Timeout: Serwer nie otrzymał kompletnego żądania w ciągu czasu, na jaki 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 zdołał zrealizować prawidłowego żądania.

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

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

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

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

• 600 Busy Everywhere: Wszystkie możliwe miejsca docelowe 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 - Ta linia wskazuje metodę (INVITE), URI żądania (sip:[e-mail]) i 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) i adres klienta (pc33.example.com). Parametr "branch" służy do wykrywania pętli i dopasowywania transakcji.

3. Max-Forwards: Max-Forwards: 70 - To pole nagłówka ogranicza liczbę przekierowań żądania przez serwery pośredniczące, 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 nazwisko (John Doe) i 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 nazwisko (Jane Smith) i URI SIP (sip:[e-mail]). Parametr "tag" służy do jednoznacznego zidentyfikowania roli nadawcy w dialogu.

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

7. CSeq: CSeq: 314159 INVITE - Nagłówek CSeq zawiera numer sekwencji i metodę używaną w żądaniu. Służy do dopasowywania odpowiedzi do żądań i wykrywania wiadomości przekazanych w niewłaściwej 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 zawiera informacje o oprogramowaniu lub sprzęcie nadawcy, w tym jego nazwę i wersję.

10. Allow: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO - Nagłówek Allow wymienia obsługiwane metody SIP 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 nośnika treści wiadomości, w tym przypadku SDP (Session Description Protocol).

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

13. Treść wiadomości: Treść wiadomości zawiera opis sesji SDP, który obejmuje informacje o typach nośników, kodekach i protokołach transportowych 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 nośnika (typ nośnika, numer portu, protokół transportowy i lista formatów). W tym przypadku określa strumień audio za pomocą RTP/AVP (Real-time Transport Protocol / Audio Video Profile) i format 0 (PCMU/8000).

• a=rtpmap:0 PCMU/8000 - Atrybut mapujący format (0) na kodek (PCMU) i jego częstotliwość taktowania (8000 Hz).

Przykład rejestracji SIP

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

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

1. Początkowe żądanie REGISTER 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

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

2. Odpowiedź 401 Nieautoryzowane od serwera rejestratora:

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

Rejestrator serwera odpowiada wiadomością "401 Unauthorized", która zawiera nagłówek "WWW-Authenticate". Ten nagłówek zawiera informacje wymagane do uwierzytelnienia UA, takie jak obszar uwierzytelniania, nonce i algorytm.

3. Żądanie REJESTRACJI 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 REJESTRACJI, tym razem zawierające nagłówek "Autoryzacja" z niezbędnymi danymi uwierzytelniającymi, takimi jak nazwa użytkownika, obszar, nonce i wartość odpowiedzi obliczona przy użyciu dostarczonych informacji i hasła użytkownika.

Tak jest obliczana odpowiedź autoryzacji:

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}")

4. Pomyślna rejestracja odpowiedź 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 zatwierdzeniu dostarczonych poświadczeń przez serwer rejestratora, wysyła on odpowiedź "200 OK" w celu potwierdzenia udanej rejestracji. Odpowiedź zawiera zarejestrowane informacje kontaktowe oraz czas wygaśnięcia rejestracji. W tym momencie agent użytkownika (Alice) jest pomyślnie zarejestrowany w serwerze rejestratora SIP, a przychodzące żądania SIP dla Alice mogą być kierowane pod odpowiedni adres kontaktowy.

Przykład Połączenia

Nie wspomniano o tym, ale Użytkownik B musi wysłać wiadomość REJESTRUJĄCĄ do Proxy 2 zanim będzie mógł odbierać połączenia.