hacktricks/network-services-pentesting/pentesting-voip/basic-voip-protocols/sip-session-initiation-protocol.md
2024-02-10 15:36:32 +00:00

225 lines
17 KiB
Markdown

# SIP (Session Initiation Protocol)
<details>
<summary><strong>Lernen Sie AWS-Hacking von Grund auf mit</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
Andere Möglichkeiten, HackTricks zu unterstützen:
* Wenn Sie Ihr **Unternehmen in HackTricks bewerben möchten** oder **HackTricks als PDF herunterladen möchten**, überprüfen Sie die [**ABONNEMENTPLÄNE**](https://github.com/sponsors/carlospolop)!
* Holen Sie sich das [**offizielle PEASS & HackTricks-Merchandise**](https://peass.creator-spring.com)
* Entdecken Sie [**The PEASS Family**](https://opensea.io/collection/the-peass-family), unsere Sammlung exklusiver [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Treten Sie der** 💬 [**Discord-Gruppe**](https://discord.gg/hRep4RUj7f) oder der [**Telegramm-Gruppe**](https://t.me/peass) bei oder **folgen** Sie uns auf **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an die** [**HackTricks**](https://github.com/carlospolop/hacktricks) und [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) Github-Repositories senden.
</details>
## Grundlegende Informationen
SIP (Session Initiation Protocol) ist ein **Signalisierungs- und Anrufsteuerungsprotokoll**, das weit verbreitet für die Einrichtung, Änderung und Beendigung von Multimedia-Sitzungen verwendet wird, einschließlich Sprache, Video und Sofortnachrichten, über IP-Netzwerke. Entwickelt von der **Internet Engineering Task Force (IETF)**, wird SIP in **RFC 3261** definiert und ist zum De-facto-Standard für VoIP und Unified Communications geworden.
Einige wichtige Merkmale von SIP sind:
1. **Textbasiertes Protokoll**: SIP ist ein textbasiertes Protokoll, das es lesbar und einfacher zu debuggen macht. Es basiert auf einem Anforderungs-Antwort-Modell, ähnlich wie HTTP, und verwendet Methoden wie INVITE, ACK, BYE und CANCEL zur Steuerung von Anruf-Sitzungen.
2. **Skalierbarkeit und Flexibilität**: SIP ist hoch skalierbar und kann in kleinen Bereitstellungen sowie in großen Unternehmens- und Carrier-Umgebungen verwendet werden. Es kann leicht mit neuen Funktionen erweitert werden, was es anpassungsfähig für verschiedene Anwendungsfälle und Anforderungen macht.
3. **Interoperabilität**: Die weite Verbreitung und Standardisierung von SIP gewährleisten eine bessere Interoperabilität zwischen verschiedenen Geräten, Anwendungen und Dienstanbietern und fördern eine nahtlose Kommunikation über verschiedene Plattformen hinweg.
4. **Modulares Design**: SIP arbeitet mit anderen Protokollen wie **RTP (Real-time Transport Protocol)** für die Medienübertragung und **SDP (Session Description Protocol)** für die Beschreibung von Multimedia-Sitzungen zusammen. Dieses modulare Design ermöglicht eine größere Flexibilität und Kompatibilität mit verschiedenen Medientypen und Codecs.
5. **Proxy- und Umleitungs-Server**: SIP kann Proxy- und Umleitungs-Server verwenden, um die Anrufweiterleitung zu erleichtern und erweiterte Funktionen wie Anrufweiterleitung, Anrufumleitung und Voicemail-Dienste bereitzustellen.
6. **Präsenz und Sofortnachrichten**: SIP ist nicht nur auf Sprach- und Video-Kommunikation beschränkt. Es unterstützt auch Präsenz und Sofortnachrichten, was eine Vielzahl von Unified Communication-Anwendungen ermöglicht.
Trotz seiner vielen Vorteile kann SIP komplex sein, wenn es um die Konfiguration und Verwaltung geht, insbesondere bei der Bewältigung von NAT-Traversal- und Firewall-Problemen. Seine Vielseitigkeit, Skalierbarkeit und umfangreiche Unterstützung in der Branche machen es jedoch zu einer beliebten Wahl für VoIP und Multimedia-Kommunikation.
### SIP-Methoden
Die Kern-SIP-Methoden, die in **RFC 3261** definiert sind, umfassen:
1. **INVITE**: Wird verwendet, um eine neue Sitzung (Anruf) zu initiieren oder eine bestehende zu ändern. Die INVITE-Methode enthält die Sitzungsbeschreibung (in der Regel mit SDP), um den Empfänger über die Details der vorgeschlagenen Sitzung zu informieren, wie z.B. Medientypen, Codecs und Transportprotokolle.
2. **ACK**: Wird gesendet, um den Empfang einer endgültigen Antwort auf eine INVITE-Anforderung zu bestätigen. Die ACK-Methode gewährleistet die Zuverlässigkeit von INVITE-Transaktionen durch Bereitstellung einer End-to-End-Bestätigung.
3. **BYE**: Wird verwendet, um eine etablierte Sitzung (Anruf) zu beenden. Die BYE-Methode wird von einer der Parteien in der Sitzung gesendet, um anzuzeigen, dass sie die Kommunikation beenden möchten.
4. **CANCEL**: Wird gesendet, um eine ausstehende INVITE-Anforderung abzubrechen, bevor die Sitzung hergestellt wird. Die CANCEL-Methode ermöglicht es dem Absender, eine INVITE-Transaktion abzubrechen, wenn er seine Meinung ändert oder keine Antwort vom Empfänger erhält.
5. **OPTIONS**: Wird verwendet, um die Fähigkeiten eines SIP-Servers oder Benutzeragenten abzufragen. Die OPTIONS-Methode kann gesendet werden, um Informationen über unterstützte Methoden, Medientypen oder andere Erweiterungen anzufordern, ohne tatsächlich eine Sitzung herzustellen.
6. **REGISTER**: Wird von einem Benutzeragenten verwendet, um seinen aktuellen Standort bei einem SIP-Registrar-Server zu registrieren. Die REGISTER-Methode hilft dabei, eine aktuelle Zuordnung zwischen der SIP-URI eines Benutzers und seiner aktuellen IP-Adresse aufrechtzuerhalten, was die Anrufweiterleitung und Zustellung ermöglicht.
{% hint style="warning" %}
Beachten Sie, dass es zum Anrufen einer Person **nicht erforderlich ist, das REGISTER** für irgendetwas zu verwenden.\
Es ist jedoch möglich, dass der Anrufer zur Durchführung eines **INVITE** zuerst **authentifiziert** werden muss, oder er erhält eine **`401 Unauthorized`**-Antwort.
{% endhint %}
Neben diesen Kernmethoden gibt es **mehrere SIP-Erweiterungsmethoden**, die in anderen RFCs definiert sind, wie z.B.:
1. **SUBSCRIBE**: In RFC 6665 definiert, wird die SUBSCRIBE-Methode verwendet, um Benachrichtigungen über den Zustand einer bestimmten Ressource anzufordern, z.B. die Präsenz oder den Anrufstatus eines Benutzers.
2. **NOTIFY**: Auch in RFC 6665 definiert, wird die NOTIFY-Methode von einem Server gesendet, um einen abonnierten Benutzeragenten über Änderungen im Zustand einer überwachten Ressource zu informieren.
3. **REFER**: In RFC 3515 definiert, wird die REFER-Methode verwendet, um den Empfänger zur Durchführung eines Transfers oder zur Weiterleitung an eine dritte Partei aufzufordern. Dies wird in der Regel für Szenarien der **Anrufweiterleitung** verwendet.
4. **MESSAGE**: In RFC 3428 definiert, wird die MESSAGE-Methode verwendet, um Sofortnachrichten zwischen SIP-Benutzeragenten zu senden und eine textbasierte Kommunikation im SIP-Framework zu ermöglichen.
5. **UPDATE**: In RFC 3311 definiert, ermöglicht die UPDATE-Methode die Änderung einer Sitzung, ohne den Zustand des bestehenden Dialogs zu beeinflussen. Dies ist nützlich für die Aktualisierung von Sitzungsparametern wie Codecs oder Medientypen während eines laufenden Anrufs
## Beispiele
### SIP INVITE Beispiel
```
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>Erklärung jedes Parameters</summary>
1. **Request-Line**: `INVITE sip:jdoe@example.com SIP/2.0` - Diese Zeile gibt die Methode (INVITE), die Anfrage-URI (sip:[jdoe@example.com](mailto:jdoe@example.com)) und die SIP-Version (SIP/2.0) an.
2. **Via**: `Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776asdhds` - Der Via-Header gibt das Transportprotokoll (UDP) und die Adresse des Clients (pc33.example.com) an. Der Parameter "branch" wird zur Schleifenerkennung und Transaktionszuordnung verwendet.
3. **Max-Forwards**: `Max-Forwards: 70` - Dieses Header-Feld begrenzt die Anzahl der Weiterleitungen der Anfrage durch Proxies, um Endlosschleifen zu vermeiden.
4. **To**: `To: John Doe <sip:jdoe@example.com>` - Der To-Header gibt den Empfänger des Anrufs an, einschließlich seines Anzeigenamens (John Doe) und der SIP-URI (sip:[jdoe@example.com](mailto:jdoe@example.com)).
5. **From**: `From: Jane Smith <sip:jsmith@example.org>;tag=1928301774` - Der From-Header gibt den Absender des Anrufs an, einschließlich seines Anzeigenamens (Jane Smith) und der SIP-URI (sip:[jsmith@example.org](mailto:jsmith@example.org)). Der Parameter "tag" wird verwendet, um die Rolle des Absenders im Dialog eindeutig zu identifizieren.
6. **Call-ID**: `Call-ID: a84b4c76e66710` - Der Call-ID-Header identifiziert eindeutig eine Anrufsession zwischen zwei Benutzeragenten.
7. **CSeq**: `CSeq: 314159 INVITE` - Der CSeq-Header enthält eine Sequenznummer und die verwendete Methode in der Anfrage. Er wird verwendet, um Antworten den Anfragen zuzuordnen und Nachrichten in falscher Reihenfolge zu erkennen.
8. **Contact**: `Contact: <sip:jsmith@pc33.example.com>` - Der Contact-Header bietet eine direkte Route zum Absender, die für nachfolgende Anfragen und Antworten verwendet werden kann.
9. **User-Agent**: `User-Agent: ExampleSIPClient/1.0` - Der User-Agent-Header enthält Informationen über die Software oder Hardware des Absenders, einschließlich des Namens und der Version.
10. **Allow**: `Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO` - Der Allow-Header listet die vom Absender unterstützten SIP-Methoden auf. Dies hilft dem Empfänger zu verstehen, welche Methoden während der Kommunikation verwendet werden können.
11. **Content-Type**: `Content-Type: application/sdp` - Der Content-Type-Header gibt den Medientyp des Nachrichtenrumpfs an, in diesem Fall SDP (Session Description Protocol).
12. **Content-Length**: `Content-Length: 142` - Der Content-Length-Header gibt die Größe des Nachrichtenrumpfs in Bytes an.
13. **Nachrichtenrumpf**: Der Nachrichtenrumpf enthält die SDP-Sitzungsbeschreibung, die Informationen über die Medientypen, Codecs und Transportprotokolle für die vorgeschlagene Sitzung enthält.
* `v=0` - Protokollversion (0 für SDP)
* `o=jsmith 2890844526 2890842807 IN IP4 pc33.example.com` - Ursprung und Sitzungsidentifikator
* `s=-` - Sitzungsname (ein einzelner Bindestrich gibt keinen Sitzungsnamen an)
* `c=IN IP4 pc33.example.com` - Verbindungsinformationen (Netzwerktyp, Adresstyp und Adresse)
* `t=0 0` - Zeitinformationen (Start- und Endzeiten, 0 0 bedeutet, dass die Sitzung nicht begrenzt ist)
* `m=audio 49170 RTP/AVP 0` - Medienbeschreibung (Medientyp, Portnummer, Transportprotokoll und Formatliste). In diesem Fall wird ein Audio-Stream mit RTP/AVP (Real-time Transport Protocol / Audio Video Profile) und Format 0 (PCMU/8000) angegeben.
* `a=rtpmap:0 PCMU/8000` - Attribut, das das Format (0) dem Codec (PCMU) und seiner Taktrate (8000 Hz) zuordnet.
</details>
### SIP REGISTER Beispiel
Die REGISTER-Methode wird in Session Initiation Protocol (SIP) verwendet, um einem Benutzeragenten (UA), wie einem VoIP-Telefon oder einem Softphone, das **seinen Standort bei einem SIP-Registrar-Server registrieren** möchte, dies zu ermöglichen. Dieser Prozess informiert den Server darüber, **wohin eingehende SIP-Anfragen für den registrierten Benutzer weitergeleitet werden sollen**. Der Registrar-Server ist normalerweise Teil eines SIP-Proxy-Servers oder eines dedizierten Registrierungsservers.
Hier ist ein detailliertes Beispiel für die SIP-Nachrichten, die in einem REGISTER-Authentifizierungsprozess verwendet werden:
1. Erste **REGISTER**-Anfrage vom UA an den Registrar-Server:
```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
```
Diese erste REGISTER-Nachricht wird vom UA (Alice) an den Registrar-Server gesendet. Sie enthält wichtige Informationen wie die gewünschte Registrierungsdauer (Expires), die SIP-URI des Benutzers (sip:[alice@example.com](mailto:alice@example.com)) und die Kontaktadresse des Benutzers (sip:alice@192.168.1.100:5060).
2. **401 Unauthorized** Antwort vom Registrar-Server:
```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
```
Der Registrar-Server antwortet mit einer "401 Unauthorized"-Nachricht, die einen "WWW-Authenticate"-Header enthält. Dieser Header enthält Informationen, die für die Authentifizierung des UA erforderlich sind, wie z.B. den **Authentifizierungsbereich, die Nonce und den Algorithmus**.
3. REGISTER-Anforderung **mit Authentifizierungsanmeldeinformationen**:
```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
```
Der UA sendet eine weitere REGISTER-Anfrage, diesmal mit dem **"Authorization"-Header, der die erforderlichen Anmeldeinformationen enthält, wie Benutzername, Bereich, nonce und einen berechneten Antwortwert** unter Verwendung der bereitgestellten Informationen und des Benutzerpassworts.
So wird die **Autorisierungsantwort** berechnet:
```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. Erfolgreiche Registrierungsantwort vom Registrar-Server:
```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
```
Nachdem der Registrar-Server die bereitgestellten Anmeldeinformationen überprüft hat, **sendet er eine "200 OK"-Antwort, um anzuzeigen, dass die Registrierung erfolgreich war**. Die Antwort enthält die registrierten Kontaktdaten und die Ablaufzeit der Registrierung. Zu diesem Zeitpunkt ist der Benutzeragent (Alice) erfolgreich beim SIP-Registrar-Server registriert, und eingehende SIP-Anfragen für Alice können an die entsprechende Kontaktadresse weitergeleitet werden.
### Beispielanruf
<figure><img src="../../../.gitbook/assets/image (666).png" alt=""><figcaption></figcaption></figure>
{% hint style="info" %}
Es wird nicht erwähnt, aber Benutzer B muss zuerst eine **REGISTER-Nachricht an Proxy 2** gesendet haben, bevor er Anrufe empfangen kann.
{% endhint %}
<details>
<summary><strong>Lernen Sie AWS-Hacking von Grund auf mit</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
Andere Möglichkeiten, HackTricks zu unterstützen:
* Wenn Sie Ihr **Unternehmen in HackTricks bewerben möchten** oder **HackTricks als PDF herunterladen möchten**, überprüfen Sie die [**ABONNEMENTPLÄNE**](https://github.com/sponsors/carlospolop)!
* Holen Sie sich das [**offizielle PEASS & HackTricks-Merchandise**](https://peass.creator-spring.com)
* Entdecken Sie [**The PEASS Family**](https://opensea.io/collection/the-peass-family), unsere Sammlung exklusiver [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Treten Sie der** 💬 [**Discord-Gruppe**](https://discord.gg/hRep4RUj7f) oder der [**Telegram-Gruppe**](https://t.me/peass) bei oder **folgen** Sie uns auf **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an die** [**HackTricks**](https://github.com/carlospolop/hacktricks) und [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) GitHub-Repositories senden.
</details>