# SIP (Session Initiation Protocol)
Lernen Sie AWS-Hacking von Grund auf mit htARTE (HackTricks AWS Red Team Expert)! 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.
## 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 From: Jane Smith ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: 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 ```
Erklärung jedes Parameters 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 ` - 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 ;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: ` - 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.
### 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 ;tag=565656 To: Alice Call-ID: 1234567890@192.168.1.100 CSeq: 1 REGISTER Contact: ;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 ;tag=565656 To: Alice ;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 ;tag=565656 To: Alice Call-ID: 1234567890@192.168.1.100 CSeq: 2 REGISTER Contact: ;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 ;tag=565656 To: Alice ;tag=7878744 Call-ID: 1234567890@192.168.1.100 CSeq: 2 REGISTER Contact: ;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
{% 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 %}
Lernen Sie AWS-Hacking von Grund auf mit htARTE (HackTricks AWS Red Team Expert)! 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.