mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-27 23:20:49 +00:00
242 lines
18 KiB
Markdown
242 lines
18 KiB
Markdown
# SIP (Session Initiation Protocol)
|
|
|
|
<details>
|
|
|
|
<summary><strong>Naucz się hakować AWS od zera do bohatera z</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
|
|
|
Inne sposoby wsparcia HackTricks:
|
|
|
|
* Jeśli chcesz zobaczyć swoją **firmę reklamowaną w HackTricks** lub **pobrać HackTricks w formacie PDF**, sprawdź [**PLANY SUBSKRYPCYJNE**](https://github.com/sponsors/carlospolop)!
|
|
* Zdobądź [**oficjalne gadżety PEASS & HackTricks**](https://peass.creator-spring.com)
|
|
* Odkryj [**Rodzinę PEASS**](https://opensea.io/collection/the-peass-family), naszą kolekcję ekskluzywnych [**NFT**](https://opensea.io/collection/the-peass-family)
|
|
* **Dołącz do** 💬 [**grupy Discord**](https://discord.gg/hRep4RUj7f) lub [**grupy telegramowej**](https://t.me/peass) lub **śledź** nas na **Twitterze** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
|
|
* **Podziel się swoimi sztuczkami hakerskimi, przesyłając PR-y do** [**HackTricks**](https://github.com/carlospolop/hacktricks) i [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
|
|
|
|
</details>
|
|
|
|
## 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 komunikacji natychmiastowej, 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łatwienia routingu połączeń oraz zapewnienia zaawansowanych funkcji, takich jak przekazywanie połączeń, transfer połączeń i usługi poczty głosowej.
|
|
6. **Obecność i komunikacja natychmiastowa**: SIP nie jest ograniczony do komunikacji głosowej i wideo. Obsługuje również obecność i komunikację natychmiastową, umożliwiając szeroki zakres zastosowań w komunikacji zintegrowanej.
|
|
|
|
Mimo wielu zalet, SIP może być skomplikowany w konfiguracji i zarządzaniu, zwłaszcza przy rozwiązywaniu problemów z NAT i zapory. Jednak jego wszechstronność, skalowalność i szerokie wsparcie w całej branży 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 z końca na koniec.
|
|
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 otrzymają 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 rejestratora 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ń.
|
|
|
|
{% hint style="warning" %}
|
|
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`**.
|
|
{% endhint %}
|
|
|
|
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, zwykle 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ługi żą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:jdoe@example.com SIP/2.0
|
|
Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776asdhds
|
|
Max-Forwards: 70
|
|
To: John Doe <sip:jdoe@example.com>
|
|
From: Jane Smith <sip:jsmith@example.org>;tag=1928301774
|
|
Call-ID: a84b4c76e66710
|
|
CSeq: 314159 INVITE
|
|
Contact: <sip:jsmith@pc33.example.com>
|
|
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
|
|
```
|
|
<details>
|
|
|
|
<summary>Każdy parametr wyjaśniony</summary>
|
|
|
|
1. **Request-Line**: `INVITE sip:jdoe@example.com SIP/2.0` - Ta linia wskazuje metodę (INVITE), URI żądania (sip:[jdoe@example.com](mailto:jdoe@example.com)), i wersję SIP (SIP/2.0).
|
|
2. **Via**: `Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776asdhds` - Nagłówek Via określa protokół transportu (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:jdoe@example.com>` - Nagłówek To określa odbiorcę połączenia, włączając w to ich nazwisko (John Doe) i URI SIP (sip:[jdoe@example.com](mailto:jdoe@example.com)).
|
|
5. **From**: `From: Jane Smith <sip:jsmith@example.org>;tag=1928301774` - Nagłówek From określa nadawcę połączenia, włączając w to ich nazwisko (Jane Smith) i URI SIP (sip:[jsmith@example.org](mailto:jsmith@example.org)). 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 sekwencyjny i metodę używaną w żądaniu. Jest używany do dopasowywania odpowiedzi do żądań i wykrywania wiadomości nie w kolejności.
|
|
8. **Contact**: `Contact: <sip:jsmith@pc33.example.com>` - 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 informacje o oprogramowaniu lub sprzęcie nadawcy, włączając w to jego nazwę i wersję.
|
|
10. **Allow**: `Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO` - Nagłówek Allow wymienia obsługiwane przez nadawcę metody SIP. 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 zawiera informacje o typach medió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 mediów (typ medium, 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ść próbkowania (8000 Hz).
|
|
|
|
</details>
|
|
|
|
### 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 softphone, **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:
|
|
```yaml
|
|
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:alice@example.com>;tag=565656
|
|
To: Alice <sip:alice@example.com>
|
|
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 REGISTER jest wysyłany przez UA (Alice) do serwera rejestratora. Zawiera ważne informacje, takie jak pożądany czas rejestracji (Expires), SIP URI użytkownika (sip:[alice@example.com](mailto:alice@example.com)), oraz adres kontaktowy użytkownika (sip:alice@192.168.1.100:5060).
|
|
|
|
2. Odpowiedź **401 Unauthorized** serwera rejestratora:
|
|
```css
|
|
cssCopy codeSIP/2.0 401 Unauthorized
|
|
Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds
|
|
From: Alice <sip:alice@example.com>;tag=565656
|
|
To: Alice <sip:alice@example.com>;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 rejestratora 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**:
|
|
```vbnet
|
|
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:alice@example.com>;tag=565656
|
|
To: Alice <sip:alice@example.com>
|
|
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, strefa, nonce i wartość odpowiedzi** obliczona przy użyciu dostarczonych informacji i hasła użytkownika.
|
|
|
|
Tak jest obliczana **odpowiedź autoryzacji**:
|
|
```python
|
|
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:
|
|
```yaml
|
|
SIP/2.0 200 OK
|
|
Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds
|
|
From: Alice <sip:alice@example.com>;tag=565656
|
|
To: Alice <sip:alice@example.com>;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 danych 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
|
|
|
|
<figure><img src="../../../.gitbook/assets/image (1098).png" alt=""><figcaption></figcaption></figure>
|
|
|
|
{% hint style="info" %}
|
|
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.
|
|
{% endhint %}
|