# SIP (Session Initiation Protocol)
Lernen Sie AWS-Hacking von Null auf Held mit htARTE (HackTricks AWS Red Team Expert)! Andere Möglichkeiten, HackTricks zu unterstützen: * Wenn Sie Ihr **Unternehmen in HackTricks beworben sehen 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-Repositorys senden.
## Grundlegende Informationen SIP (Session Initiation Protocol) ist ein **Signalisierungs- und Anrufsteuerungsprotokoll**, das weit verbreitet für die Einrichtung, Änderung und Beendigung von Multimediasitzungen wie Sprache, Video und Sofortnachrichten über IP-Netzwerke verwendet wird. Entwickelt von der **Internet Engineering Task Force (IETF)**, ist SIP in **RFC 3261** definiert und hat sich als De-facto-Standard für VoIP und Unified Communications etabliert. Einige wichtige Merkmale von SIP sind: 1. **Textbasiertes Protokoll**: SIP ist ein textbasiertes Protokoll, das menschenlesbar ist und das Debuggen erleichtert. Es basiert auf einem Anfrage-Antwort-Modell, ähnlich wie HTTP, und verwendet Methoden wie INVITE, ACK, BYE und CANCEL zur Steuerung von Anrufsessions. 2. **Skalierbarkeit und Flexibilität**: SIP ist hoch skalierbar und kann in kleinen Bereitstellungen sowie in großen Unternehmens- und Carrier-Umgebungen eingesetzt werden. Es kann leicht um neue Funktionen erweitert werden, was es anpassungsfähig für verschiedene Anwendungsfälle und Anforderungen macht. 3. **Interoperabilität**: Die weit verbreitete Verwendung 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)** zur Beschreibung von Multimediasitzungen 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-Services bereitzustellen. 6. **Präsenz und Sofortnachrichten**: SIP ist nicht nur auf Sprach- und Videokommunikation 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, um konfiguriert und verwaltet zu werden, insbesondere bei der Bewältigung von NAT-Traversal- und Firewall-Problemen. Dennoch machen seine Vielseitigkeit, Skalierbarkeit und umfangreiche Unterstützung in der Branche es 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 (typischerweise unter Verwendung von SDP), um den Empfänger über die Details der vorgeschlagenen Sitzung zu informieren, wie Medientypen, Codecs und Transportprotokolle. 2. **ACK**: Wird gesendet, um den Empfang einer endgültigen Antwort auf eine INVITE-Anfrage 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-Anfrage zu **abbrechen**, 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 zu **abfragen**. Die OPTIONS-Methode kann gesendet werden, um Informationen über unterstützte Methoden, Medientypen oder andere Erweiterungen anzufragen, 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 **nicht notwendig ist, das REGISTER** für irgendetwas zu verwenden, um jemanden anzurufen.\ Es ist jedoch möglich, dass der Anrufer sich zuerst **authentifizieren** muss, um einen **INVITE** durchzuführen, oder er erhält eine **`401 Unauthorized`**-Antwort. {% endhint %} Neben diesen Kernmethoden gibt es **mehrere SIP-Erweiterungsmethoden**, die in anderen RFCs definiert sind, wie: 1. **SUBSCRIBE**: In RFC 6665 definiert, wird die SUBSCRIBE-Methode verwendet, um **Benachrichtigungen** über den Zustand einer bestimmten Ressource, wie die Präsenz eines Benutzers oder den Anrufstatus, anzufordern. 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 zu **fordern, dass der Empfänger einen Transfer durchführt oder auf eine dritte Partei verweist**. Dies wird typischerweise für **Anruftransfer**-Szenarien verwendet. 4. **MESSAGE**: In RFC 3428 definiert, wird die MESSAGE-Methode verwendet, um **Sofortnachrichten zwischen SIP-Benutzeragenten** zu senden, was eine textbasierte Kommunikation innerhalb des SIP-Frameworks ermöglicht. 5. **UPDATE**: In RFC 3311 definiert, ermöglicht die UPDATE-Methode das **Ändern 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. 6. **PUBLISH**: In RFC 3903 definiert, wird die PUBLISH-Methode von einem Benutzeragenten verwendet, um **Ereigniszustandsinformationen an einen Server zu veröffentlichen**, die für andere interessierte Parteien verfügbar gemacht werden. ### SIP-Antwortcodes * **1xx (Vorläufige Antworten)**: Diese Antworten zeigen an, dass die Anfrage empfangen wurde und der Server weiterhin daran arbeitet. * 100 Trying: Die Anfrage wurde empfangen, und der Server arbeitet daran. * 180 Ringing: Der Angerufene wird benachrichtigt und wird den Anruf entgegennehmen. * 183 Session Progress: Bietet Informationen über den Fortschritt des Anrufs. * **2xx (Erfolgreiche Antworten)**: Diese Antworten zeigen an, dass die Anfrage erfolgreich empfangen, verstanden und akzeptiert wurde. * 200 OK: Die Anfrage war erfolgreich, und der Server hat sie erfüllt. * 202 Accepted: Die Anfrage wurde zur Verarbeitung akzeptiert, aber noch nicht abgeschlossen. * **3xx (Umleitungsantworten)**: Diese Antworten zeigen an, dass weitere Maßnahmen erforderlich sind, um die Anfrage zu erfüllen, normalerweise durch Kontaktaufnahme mit einer alternativen Ressource. * 300 Multiple Choices: Es gibt mehrere Optionen, und der Benutzer oder Client muss eine auswählen. * 301 Moved Permanently: Die angeforderte Ressource wurde einer neuen permanenten URI zugewiesen. * 302 Moved Temporarily: Die angeforderte Ressource ist vorübergehend unter einer anderen URI verfügbar. * 305 Use Proxy: Die Anfrage muss an einen bestimmten Proxy gesendet werden. * **4xx (Clientfehlerantworten)**: Diese Antworten zeigen an, dass die Anfrage eine schlechte Syntax enthält oder vom Server nicht erfüllt werden kann. * 400 Bad Request: Die Anfrage war fehlerhaft oder ungültig. * 401 Unauthorized: Die Anfrage erfordert eine Benutzerauthentifizierung. * 403 Forbidden: Der Server hat die Anfrage verstanden, lehnt jedoch deren Erfüllung ab. * 404 Not Found: Die angeforderte Ressource wurde auf dem Server nicht gefunden. * 408 Request Timeout: Der Server hat keine vollständige Anfrage innerhalb der von ihm bereitgestellten Zeit erhalten. * 486 Busy Here: Der Angerufene ist derzeit beschäftigt und kann den Anruf nicht entgegennehmen. * **5xx (Serverfehlerantworten)**: Diese Antworten zeigen an, dass der Server eine gültige Anfrage nicht erfüllen konnte. * 500 Internal Server Error: Der Server hat einen Fehler bei der Verarbeitung der Anfrage festgestellt. * 501 Not Implemented: Der Server unterstützt die für die Erfüllung der Anfrage erforderliche Funktionalität nicht. * 503 Service Unavailable: Der Server kann die Anfrage derzeit aufgrund von Wartungsarbeiten oder Überlastung nicht bearbeiten. * **6xx (Globale Fehlerantworten)**: Diese Antworten zeigen an, dass die Anfrage von keinem Server erfüllt werden kann. * 600 Busy Everywhere: Alle möglichen Ziele für den Anruf sind besetzt. * 603 Decline: Der Angerufene möchte nicht an dem Anruf teilnehmen. * 604 Does Not Exist Anywhere: Die angeforderte Ressource ist nirgendwo im Netzwerk verfügbar. ## 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 Anforderungs-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" dient zur eindeutigen Identifizierung der Rolle des Absenders im Dialog. 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 mit Anfragen abzugleichen 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 seines Namens und seiner 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 zeigt an, dass kein Sitzungsname vorhanden ist) * `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 unter Verwendung von RTP/AVP (Real-time Transport Protocol / Audio Video Profile) und Format 0 (PCMU/8000) spezifiziert. * `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 im Session Initiation Protocol (SIP) verwendet, um einem Benutzeragenten (UA), wie einem VoIP-Telefon oder einem Softphone, zu ermöglichen, **seinen Standort bei einem SIP-Registrar-Server zu registrieren**. Dieser Prozess informiert den Server darüber, **wo eingehende SIP-Anfragen für den registrierten Benutzer geroutet werden sollen**. Der Registrar-Server ist in der Regel Teil eines SIP-Proxy-Servers oder eines dedizierten Registrierungsservers. Hier ist ein detailliertes Beispiel der SIP-Nachrichten, die an einem REGISTRIERUNGS-Authentifizierungsprozess beteiligt sind: 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 ``` Dieses erste REGISTER-Nachricht wird vom UA (Alice) an den Registrar-Server gesendet. Es 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. **Authentifizierungs-Realm, Nonce und 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 wie Benutzername, Bereich, nonce und einen Antwortwert** enthält, der unter Verwendung der bereitgestellten Informationen und des Passworts des Benutzers berechnet wird. 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 Registrierung** Antwort 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 für die 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. ### Anrufbeispiel
{% hint style="info" %} Es wird nicht erwähnt, aber Benutzer B muss eine **REGISTER-Nachricht an Proxy 2** gesendet haben, bevor er Anrufe empfangen kann. {% endhint %}