diff --git a/src/network-services-pentesting/pentesting-voip/basic-voip-protocols/sip-session-initiation-protocol.md b/src/network-services-pentesting/pentesting-voip/basic-voip-protocols/sip-session-initiation-protocol.md index 487c53468..cc5fd8ff2 100644 --- a/src/network-services-pentesting/pentesting-voip/basic-voip-protocols/sip-session-initiation-protocol.md +++ b/src/network-services-pentesting/pentesting-voip/basic-voip-protocols/sip-session-initiation-protocol.md @@ -2,74 +2,74 @@ {{#include ../../../banners/hacktricks-training.md}} -## Grundinformationen +## Grundlegende Informationen -SIP (Session Initiation Protocol) ist ein **Signalisierungs- und Anrufsteuerungsprotokoll**, das weit verbreitet ist, um Multimedia-Sitzungen, einschließlich Sprache, Video und Instant Messaging, über IP-Netzwerke zu etablieren, zu modifizieren und zu beenden. Entwickelt von der **Internet Engineering Task Force (IETF)**, ist SIP in **RFC 3261** definiert und hat sich zum De-facto-Standard für VoIP und einheitliche Kommunikation entwickelt. +SIP (Session Initiation Protocol) ist ein **Signalisierungs- und Anrufsteuerungsprotokoll**, das weit verbreitet für das Einrichten, Ändern und Beenden von Multimedia-Sitzungen, einschließlich Sprache, Video und Instant Messaging, über IP-Netzwerke verwendet wird. Entwickelt von der **Internet Engineering Task Force (IETF)**, ist SIP in **RFC 3261** definiert und zum de-facto Standard für VoIP und Unified Communications geworden. -Einige wichtige Merkmale von SIP sind: +Zu den wichtigsten Merkmalen von SIP gehören: -1. **Textbasiertes Protokoll**: SIP ist ein textbasiertes Protokoll, das es menschenlesbar und einfacher zu debuggen macht. Es basiert auf einem Anfrage-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 sowohl in kleinen als auch in großen Unternehmens- und Carrier-Umgebungen eingesetzt 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 weit verbreitete Annahme und Standardisierung von SIP gewährleisten eine bessere Interoperabilität zwischen verschiedenen Geräten, Anwendungen und Dienstanbietern und fördern 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 Multimedia-Sitzungen. Dieses modulare Design ermöglicht eine größere Flexibilität und Kompatibilität mit verschiedenen Medientypen und Codecs. -5. **Proxy- und Weiterleitungsserver**: SIP kann Proxy- und Weiterleitungsserver verwenden, um die Anrufweiterleitung zu erleichtern und erweiterte Funktionen wie Anrufweiterleitung, Anrufübertragung und Voicemail-Dienste bereitzustellen. -6. **Präsenz und Instant Messaging**: SIP ist nicht auf Sprach- und Video-Kommunikation beschränkt. Es unterstützt auch Präsenz und Instant Messaging, was eine breite Palette von Anwendungen für einheitliche Kommunikation ermöglicht. +1. **Text-based Protocol**: SIP ist ein textbasiertes Protokoll, wodurch es menschenlesbar und leichter zu debuggen ist. Es basiert auf einem Request-Response-Modell, ähnlich HTTP, und verwendet Methoden wie INVITE, ACK, BYE und CANCEL zur Steuerung von Anruf-Sitzungen. +2. **Scalability and Flexibility**: SIP ist hoch skalierbar und kann in kleinen Installationen ebenso wie in großen Unternehmens- und Carrier-Umgebungen eingesetzt werden. Es lässt sich leicht mit neuen Funktionen erweitern, was es an verschiedene Anwendungsfälle und Anforderungen anpassbar macht. +3. **Interoperability**: Die weit verbreitete Nutzung und Standardisierung von SIP sorgt für bessere Interoperabilität zwischen verschiedenen Geräten, Anwendungen und Dienstanbietern und fördert nahtlose Kommunikation über unterschiedliche Plattformen. +4. **Modular 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 Multimedia-Sitzungen. Dieses modulare Design ermöglicht größere Flexibilität und Kompatibilität mit verschiedenen Medientypen und Codecs. +5. **Proxy and Redirect Servers**: SIP kann Proxy- und Redirect-Server verwenden, um die Anrufweiterleitung zu erleichtern und erweiterte Funktionen wie Call Forwarding, Call Transfer und Voicemail-Dienste bereitzustellen. +6. **Presence and Instant Messaging**: SIP ist nicht auf Sprach- und Videokommunikation beschränkt. Es unterstützt auch Presence und Instant Messaging und ermöglicht eine breite Palette von Unified-Communication-Anwendungen. -Trotz seiner vielen Vorteile kann SIP komplex zu konfigurieren und zu verwalten sein, insbesondere bei der Behandlung von NAT-Traversal und Firewall-Problemen. Dennoch machen seine Vielseitigkeit, Skalierbarkeit und umfassende Unterstützung in der Branche es zu einer beliebten Wahl für VoIP und Multimedia-Kommunikation. +Obwohl SIP viele Vorteile bietet, kann es komplex zu konfigurieren und zu verwalten sein, insbesondere beim Umgang mit NAT-Traversal und Firewall-Problemen. Dennoch machen seine Vielseitigkeit, Skalierbarkeit und die breite Unterstützung in der Branche SIP zu einer beliebten Wahl für VoIP- und Multimedia-Kommunikation. ### SIP-Methoden -Die grundlegenden SIP-Methoden, die in **RFC 3261** definiert sind, umfassen: +Die Kern-SIP-Methoden, definiert in **RFC 3261**, umfassen: -1. **INVITE**: Wird verwendet, um eine **neue Sitzung (Anruf)** zu initiieren oder eine bestehende zu modifizieren. Die INVITE-Methode trägt die Sitzungsbeschreibung (typischerweise unter Verwendung von SDP), um den Empfänger über die Einzelheiten der vorgeschlagenen Sitzung zu informieren, wie Medientypen, Codecs und Transportprotokolle. -2. **ACK**: Wird gesendet, um den **Erhalt** einer endgültigen Antwort auf eine INVITE-Anfrage zu **bestätigen**. Die ACK-Methode gewährleistet die Zuverlässigkeit von INVITE-Transaktionen, indem sie eine End-to-End-Bestätigung bereitstellt. -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öchte. -4. **CANCEL**: Wird gesendet, um eine **ausstehende INVITE**-Anfrage abzubrechen, bevor die Sitzung etabliert wird. Die CANCEL-Methode ermöglicht es dem Absender, eine INVITE-Transaktion abzubrechen, wenn er seine Meinung ändert oder wenn keine Antwort vom Empfänger erfolgt. -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 zu etablieren. -6. **REGISTER**: Wird von einem Benutzeragenten verwendet, um seinen aktuellen Standort bei einem SIP-Registrar-Server zu **registrieren**. Die REGISTER-Methode hilft, eine aktuelle Zuordnung zwischen der SIP-URI eines Benutzers und seiner aktuellen IP-Adresse aufrechtzuerhalten, was die Anrufweiterleitung und -zustellung ermöglicht. +1. **INVITE**: Wird verwendet, um eine **neue Sitzung (Anruf) zu initiieren** oder eine bestehende zu ändern. Die INVITE-Methode trägt die Sitzungsbeschreibung (typischerweise mit SDP), um den Empfänger über die Details der vorgeschlagenen Sitzung zu informieren, wie Medientypen, Codecs und Transportprotokolle. +2. **ACK**: Wird gesendet, um den Erhalt einer endgültigen Antwort auf eine INVITE-Anfrage zu **bestätigen**. Die ACK-Methode stellt die Zuverlässigkeit von INVITE-Transaktionen sicher, indem sie eine Ende-zu-Ende-Bestätigung liefert. +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öchte. +4. **CANCEL**: Wird gesendet, um eine **ausstehende INVITE**-Anfrage zu stornieren, bevor die Sitzung etabliert ist. Die CANCEL-Methode ermöglicht dem Sender, eine INVITE-Transaktion abzubrechen, wenn er seine Meinung ändert oder keine Antwort vom Empfänger erfolgt. +5. **OPTIONS**: Wird verwendet, um die **Fähigkeiten eines SIP-Servers oder User Agents abzufragen**. Die OPTIONS-Methode kann gesendet werden, um Informationen über unterstützte Methoden, Medientypen oder andere Erweiterungen anzufordern, ohne tatsächlich eine Sitzung zu etablieren. +6. **REGISTER**: Wird von einem User Agent 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 zu pflegen, was Anrufweiterleitung und Zustellung ermöglicht. > [!WARNING] -> Beachten Sie, dass es **nicht notwendig ist, die REGISTER**-Methode zu verwenden, um jemanden anzurufen.\ -> Es ist jedoch möglich, dass der Anrufer sich zuerst **authentifizieren** muss, um eine **INVITE** durchzuführen, oder er erhält eine **`401 Unauthorized`**-Antwort. +> Beachte, dass es **nicht notwendig ist, REGISTER für einen Anruf zu verwenden**.\ +> Es ist jedoch möglich, dass der Anrufer sich vor einem **INVITE** zuerst **authentifizieren** muss, sonst erhält er eine **`401 Unauthorized`**-Antwort. -Neben diesen Kernmethoden gibt es **mehrere SIP-Erweiterungsmethoden**, die in anderen RFCs definiert sind, wie zum Beispiel: +Zusätzlich zu diesen Kernmethoden gibt es **mehrere SIP-Erweiterungsmethoden**, die in anderen RFCs definiert sind, wie zum Beispiel: -1. **SUBSCRIBE**: In RFC 6665 definiert, wird die SUBSCRIBE-Methode verwendet, um **Benachrichtigungen** über den Status einer bestimmten Ressource, wie z.B. die Präsenz oder den Anrufstatus eines Benutzers, anzufordern. -2. **NOTIFY**: Ebenfalls in RFC 6665 definiert, wird die NOTIFY-Methode von einem Server gesendet, um einen **abonnierten Benutzeragenten** über Änderungen im Status einer überwachten Ressource zu informieren. -3. **REFER**: In RFC 3515 definiert, wird die REFER-Methode verwendet, um **anzufordern, dass der Empfänger eine Übertragung durchführt oder an eine dritte Partei verweist**. Dies wird typischerweise für **Anrufübertragung**-Szenarien verwendet. -4. **MESSAGE**: In RFC 3428 definiert, wird die MESSAGE-Methode verwendet, um **Instant Messages zwischen SIP-Benutzeragenten** zu senden, was textbasierte Kommunikation innerhalb des SIP-Rahmens ermöglicht. -5. **UPDATE**: In RFC 3311 definiert, ermöglicht die UPDATE-Methode, eine **Sitzung zu modifizieren, ohne den Status des bestehenden Dialogs zu beeinflussen**. Dies ist nützlich, um Sitzungsparameter wie Codecs oder Medientypen während eines laufenden Anrufs zu aktualisieren. -6. **PUBLISH**: In RFC 3903 definiert, wird die PUBLISH-Methode von einem Benutzeragenten verwendet, um **Ereignisstatusinformationen an einen Server zu veröffentlichen**, die anderen interessierten Parteien zur Verfügung stehen. +1. **SUBSCRIBE**: In RFC 6665 definiert, wird die SUBSCRIBE-Methode verwendet, um **Benachrichtigungen anzufordern** über den Zustand einer bestimmten Ressource, wie z. B. die Presence oder den Anrufstatus eines Benutzers. +2. **NOTIFY**: Ebenfalls in RFC 6665 definiert, wird die NOTIFY-Methode von einem Server gesendet, um einen abonnierten User Agent über Änderungen im Zustand einer überwachten Ressource **zu informieren**. +3. **REFER**: In RFC 3515 definiert, wird die REFER-Methode verwendet, um zu **verlangen, dass der Empfänger eine Weiterleitung durchführt oder an eine Drittpartei verweist**. Dies wird typischerweise für Call-Transfer-Szenarien verwendet. +4. **MESSAGE**: In RFC 3428 definiert, wird die MESSAGE-Methode verwendet, um **Instant Messages zwischen SIP-User Agents zu senden**, wodurch textbasierte Kommunikation innerhalb des SIP-Frameworks ermöglicht wird. +5. **UPDATE**: In RFC 3311 definiert, erlaubt die UPDATE-Methode, eine Sitzung zu **ändern, ohne den Zustand des bestehenden Dialogs zu beeinflussen**. Dies ist nützlich, um Sitzungsparameter wie Codecs oder Medientypen während eines laufenden Anrufs zu aktualisieren. +6. **PUBLISH**: In RFC 3903 definiert, wird die PUBLISH-Methode von einem User Agent verwendet, um Ereignisstatusinformationen an einen Server zu **veröffentlichen**, die anderen interessierten Parteien zur Verfügung gestellt werden. ### SIP-Antwortcodes -- **1xx (Provisorische Antworten)**: Diese Antworten zeigen an, dass die Anfrage empfangen wurde und der Server weiterhin daran arbeitet. +- **1xx (Vorläufige Antworten)**: Diese Antworten zeigen an, dass die Anfrage empfangen wurde und der Server die Verarbeitung fortsetzt. - 100 Trying: Die Anfrage wurde empfangen, und der Server arbeitet daran. -- 180 Ringing: Der Angerufene wird benachrichtigt und wird den Anruf annehmen. -- 183 Session Progress: Bietet Informationen über den Fortschritt des Anrufs. +- 180 Ringing: Der Angerufene wird benachrichtigt und wird den Anruf entgegennehmen. +- 183 Session Progress: Liefert 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 Bearbeitung angenommen, aber noch nicht abgeschlossen. -- **3xx (Umleitungsantworten)**: Diese Antworten zeigen an, dass weitere Maßnahmen erforderlich sind, um die Anfrage zu erfüllen, typischerweise durch Kontaktaufnahme mit einer alternativen Ressource. +- 200 OK: Die Anfrage war erfolgreich und der Server hat sie erfüllt. +- 202 Accepted: Die Anfrage wurde zur Verarbeitung akzeptiert, wurde aber noch nicht abgeschlossen. +- **3xx (Umleitungsantworten)**: Diese Antworten zeigen an, dass weitere Aktionen erforderlich sind, um die Anfrage zu erfüllen, typischerweise durch Kontaktaufnahme mit einer alternativen Ressource. - 300 Multiple Choices: Es stehen mehrere Optionen zur Verfügung, und der Benutzer oder Client muss eine auswählen. -- 301 Moved Permanently: Die angeforderte Ressource hat eine neue permanente URI erhalten. +- 301 Moved Permanently: Die angeforderte Ressource wurde dauerhaft einer neuen 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. +- 305 Use Proxy: Die Anfrage muss an einen angegebenen Proxy gesendet werden. - **4xx (Client-Fehlerantworten)**: Diese Antworten zeigen an, dass die Anfrage fehlerhafte 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 Benutzer-Authentifizierung. -- 403 Forbidden: Der Server hat die Anfrage verstanden, lehnt jedoch die Erfüllung ab. +- 403 Forbidden: Der Server hat die Anfrage verstanden, weigert sich jedoch, sie zu erfüllen. - 404 Not Found: Die angeforderte Ressource wurde auf dem Server nicht gefunden. -- 408 Request Timeout: Der Server hat innerhalb der Zeit, die er bereit war zu warten, keine vollständige Anfrage erhalten. +- 408 Request Timeout: Der Server hat innerhalb der vorgesehenen Zeit keine vollständige Anfrage erhalten. - 486 Busy Here: Der Angerufene ist derzeit beschäftigt und kann den Anruf nicht annehmen. -- **5xx (Server-Fehlerantworten)**: Diese Antworten zeigen an, dass der Server nicht in der Lage war, eine gültige Anfrage zu erfüllen. -- 500 Internal Server Error: Der Server hat einen Fehler bei der Bearbeitung der Anfrage festgestellt. -- 501 Not Implemented: Der Server unterstützt die Funktionalität, die zur Erfüllung der Anfrage erforderlich ist, nicht. -- 503 Service Unavailable: Der Server kann die Anfrage aufgrund von Wartungsarbeiten oder Überlastung derzeit nicht bearbeiten. +- **5xx (Server-Fehlerantworten)**: Diese Antworten zeigen an, dass der Server eine gültige Anfrage nicht erfüllen konnte. +- 500 Internal Server Error: Der Server ist beim Verarbeiten der Anfrage auf einen Fehler gestoßen. +- 501 Not Implemented: Der Server unterstützt die erforderliche Funktionalität zur Erfüllung der Anfrage nicht. +- 503 Service Unavailable: Der Server kann die Anfrage derzeit aufgrund von Wartung 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 beschäftigt. -- 603 Decline: Der Angerufene möchte nicht am Anruf teilnehmen. -- 604 Does Not Exist Anywhere: Die angeforderte Ressource ist im Netzwerk nirgendwo verfügbar. +- 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 @@ -94,43 +94,43 @@ s=- c=IN IP4 pc33.example.com t=0 0 m=audio 49170 RTP/AVP 0 -a=rtpmap:0 PCMU/8000te +a=rtpmap:0 PCMU/8000 ```
Jeder Parameter erklärt -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 "branch"-Parameter wird zur Schleifenvermeidung und Transaktionszuordnung verwendet. -3. **Max-Forwards**: `Max-Forwards: 70` - Dieses Header-Feld begrenzt die Anzahl der Weiterleitungen der Anfrage durch Proxys, um unendliche Schleifen zu vermeiden. +1. **Request-Line**: `INVITE sip:jdoe@example.com SIP/2.0` - Diese Zeile gibt die Methode (INVITE), die Request-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 legt das Transportprotokoll (UDP) und die Adresse des Clients (pc33.example.com) fest. Der "branch"-Parameter wird zur Schleifenerkennung und zur Zuordnung von Transaktionen verwendet. +3. **Max-Forwards**: `Max-Forwards: 70` - Dieses Header-Feld begrenzt, wie oft die Anfrage von Proxies weitergeleitet werden kann, 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 "tag"-Parameter wird verwendet, um die Rolle des Absenders im Dialog eindeutig zu identifizieren. -6. **Call-ID**: `Call-ID: a84b4c76e66710` - Der Call-ID-Header identifiziert eine Anrufsession zwischen zwei Benutzeragenten eindeutig. -7. **CSeq**: `CSeq: 314159 INVITE` - Der CSeq-Header enthält eine Sequenznummer und die in der Anfrage verwendete Methode. Er wird verwendet, um Antworten auf 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. +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 "tag"-Parameter dient zur eindeutigen Identifizierung der Rolle des Absenders im Dialog. +6. **Call-ID**: `Call-ID: a84b4c76e66710` - Der Call-ID-Header identifiziert eine Gesprächssitzung zwischen zwei User Agents eindeutig. +7. **CSeq**: `CSeq: 314159 INVITE` - Der CSeq-Header enthält eine Sequenznummer und die im Request verwendete Methode. Er wird verwendet, um Antworten Requests zuzuordnen und Nachrichten außerhalb der Reihenfolge zu erkennen. +8. **Contact**: `Contact: ` - Der Contact-Header bietet eine direkte Route zum Absender, die für nachfolgende Requests und Antworten genutzt werden kann. 9. **User-Agent**: `User-Agent: ExampleSIPClient/1.0` - Der User-Agent-Header liefert Informationen über die Software oder Hardware des Absenders, einschließlich Name und 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. +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. Das 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 Nachrichtenkörpers an, in diesem Fall SDP (Session Description Protocol). -12. **Content-Length**: `Content-Length: 142` - Der Content-Length-Header gibt die Größe des Nachrichtenkörpers in Bytes an. -13. **Message Body**: Der Nachrichtenkörper enthält die SDP-Sitzungsbeschreibung, die Informationen über die Medientypen, Codecs und Transportprotokolle für die vorgeschlagene Sitzung enthält. +12. **Content-Length**: `Content-Length: 142` - Der Content-Length-Header zeigt die Größe des Nachrichtenkörpers in Bytes an. +13. **Message Body**: Der Nachrichtenkörper enthält die SDP-Session-Beschreibung, die Informationen über 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 bedeutet keinen Sitzungsnamen) +- `o=jsmith 2890844526 2890842807 IN IP4 pc33.example.com` - Originator und Sitzungskennzeichner +- `s=-` - Sitzungsname (ein einzelner Bindestrich bedeutet kein Sitzungsname) - `c=IN IP4 pc33.example.com` - Verbindungsinformationen (Netzwerktyp, Adresstyp und Adresse) -- `t=0 0` - Zeitinformationen (Start- und Stoppzeiten, 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 Audiostream unter Verwendung von RTP/AVP (Real-time Transport Protocol / Audio Video Profile) und Format 0 (PCMU/8000) angegeben. +- `t=0 0` - Zeitinformationen (Start- und Stoppzeiten, 0 0 bedeutet, die Sitzung ist nicht begrenzt) +- `m=audio 49170 RTP/AVP 0` - Mediabeschreibung (Medientyp, Portnummer, Transportprotokoll und Formatliste). In diesem Fall spezifiziert es einen Audiostream über RTP/AVP (Real-time Transport Protocol / Audio Video Profile) und Format 0 (PCMU/8000). - `a=rtpmap:0 PCMU/8000` - Attribut, das das Format (0) dem Codec (PCMU) und seiner Abtastrate (8000 Hz) zuordnet.
-### SIP REGISTER Beispiel +### 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, **wo eingehende SIP-Anfragen, die an den registrierten Benutzer gerichtet sind, weitergeleitet werden sollen**. Der Registrar-Server ist normalerweise Teil eines SIP-Proxy-Servers oder eines dedizierten Registrierungsservers. +Die REGISTER-Methode wird im Session Initiation Protocol (SIP) verwendet, damit ein User Agent (UA), wie z. B. ein VoIP-Telefon oder ein Softphone, **seinen Standort bei einem SIP-Registrar-Server registrieren** kann. Dieser Vorgang teilt dem Server **mit, wohin eingehende SIP-Anfragen für den registrierten Benutzer geroutet werden sollen**. Der Registrar-Server ist normalerweise Teil eines SIP-Proxy-Servers oder ein dedizierter Registrierungsserver. -Hier ist ein detailliertes Beispiel der SIP-Nachrichten, die an einem REGISTER-Authentifizierungsprozess beteiligt sind: +Hier ein detailliertes Beispiel der SIP-Nachrichten, die an einem REGISTER-Authentifizierungsprozess beteiligt sind: -1. Erste **REGISTER**-Anfrage vom UA an den Registrar-Server: +1. Initiale **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 @@ -143,11 +143,11 @@ Contact: ;expires=3600 Expires: 3600 Content-Length: 0 ``` -Diese anfängliche REGISTER-Nachricht wird vom UA (Alice) an den Registrierungsserver 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). +Diese initiale 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 Registrierungsserver: -```css -cssCopy codeSIP/2.0 401 Unauthorized +2. **401 Unauthorized**-Antwort vom Registrar-Server: +``` +SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds From: Alice ;tag=565656 To: Alice ;tag=7878744 @@ -156,7 +156,7 @@ 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 erforderlich sind, damit sich der UA authentifizieren kann, wie z.B. den **Authentifizierungsbereich, Nonce und Algorithmus**. +Der Registrar-Server antwortet mit einer "401 Unauthorized"-Nachricht, die einen "WWW-Authenticate"-Header enthält. Dieser Header enthält Informationen, die der UA benötigt, um sich zu authentifizieren, wie z. B. den **Authentifizierungs-Realm, Nonce und Algorithmus**. 3. REGISTER-Anfrage **mit Authentifizierungsdaten**: ```vbnet @@ -172,9 +172,9 @@ 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 den Benutzernamen, das Realm, die Nonce und einen Antwortwert** enthält, der mit den bereitgestellten Informationen und dem Passwort des Benutzers berechnet wurde. +Der UA sendet eine weitere REGISTER-Anfrage, diesmal inklusive des **"Authorization" header mit den notwendigen Anmeldeinformationen, wie username, realm, nonce und einem response value**, der mithilfe der bereitgestellten Informationen und des Passworts des Benutzers berechnet wird. -So wird die **Authorization-Antwort** berechnet: +So wird die **Authorization response** berechnet: ```python import hashlib @@ -207,7 +207,7 @@ 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 Registrierungsserver: +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 @@ -219,13 +219,98 @@ 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 Kontaktinformationen und die Ablaufzeit für die Registrierung. An diesem Punkt 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. +Nachdem der Registrar-Server die angegebenen Zugangsdaten überprüft hat, **sendet er eine "200 OK"-Antwort, um anzuzeigen, dass die Registrierung erfolgreich war**. Die Antwort enthält die registrierten Kontaktinformationen und die Ablaufzeit der Registrierung. Zu diesem Zeitpunkt ist der User Agent (Alice) erfolgreich beim SIP-Registrar-Server registriert, und eingehende SIP-Anfragen für Alice können an die passende Kontaktadresse weitergeleitet werden. -### Anrufbeispiel +### Call Example
-> [!NOTE] -> Es wird nicht erwähnt, aber Benutzer B muss eine **REGISTER-Nachricht an Proxy 2** gesendet haben, bevor er Anrufe empfangen kann. +> [!TIP] +> Es wird nicht erwähnt, aber User B muss eine **REGISTER message to Proxy 2** gesendet haben, bevor er Anrufe empfangen kann. + + +--- + +## SIP-Sicherheit und Pentesting-Hinweise + +Dieser Abschnitt fügt praktische, protokoll-spezifische Tipps hinzu, ohne die allgemeine VoIP-Anleitung zu duplizieren. Für End-to-End-VoIP-Angriffs-Methodik, Tools und Szenarien siehe: + +{{#ref}} +../README.md +{{#endref}} + +### Fingerprinting und Discovery + +- Sende eine OPTIONS-Anfrage und prüfe die Header `Allow`, `Supported`, `Server` und `User-Agent`, um Geräte und Stacks zu fingerprinten: + +```bash +# nmap NSE (UDP 5060 by default) +sudo nmap -sU -p 5060 --script sip-methods + +# Minimal raw OPTIONS over UDP +printf "OPTIONS sip: SIP/2.0\r\nVia: SIP/2.0/UDP attacker;branch=z9\r\nFrom: ;tag=1\r\nTo: >\r\nCall-ID: 1@attacker\r\nCSeq: 1 OPTIONS\r\nMax-Forwards: 70\r\nContact: \r\nContent-Length: 0\r\n\r\n" | nc -u -w 2 5060 +``` + +### Username/Extension-Enumeration-Verhalten + +- Enumeration nutzt typischerweise Unterschiede zwischen `401/407` vs `404/403` bei `REGISTER`/`INVITE` aus. Härte Server so ab, dass sie einheitlich antworten. +- Asterisk chan_sip: setze `alwaysauthreject=yes` (global), um die Offenlegung gültiger Benutzer zu vermeiden. In neueren Asterisk-Versionen (PJSIP) ist Guest-Calling deaktiviert, sofern kein `anonymous`-Endpoint definiert ist, und ein ähnliches "always auth reject"-Verhalten ist standardmäßig aktiv; trotzdem Netzwer k-ACLs und fail2ban am Perimeter durchsetzen. + +### SIP Digest Authentication: Algorithmen und cracking + +- SIP verwendet häufig HTTP-Digest-artige Authentifizierung. Historisch sind MD5 (und MD5-sess) verbreitet; neuere Stacks unterstützen SHA-256 und SHA-512/256 gemäß RFC 8760. Bevorzuge diese stärkeren Algorithmen in modernen Deployments und deaktiviere MD5, wenn möglich. +- Offline-cracking aus einem pcap ist für MD5-Digests trivial. Nach dem Extrahieren von Challenge/Response kannst du hashcat Mode 11400 (SIP digest, MD5) verwenden: + +```bash +# Example hash format (single line) +# username:realm:method:uri:nonce:cnonce:nc:qop:response +echo 'alice:example.com:REGISTER:sip:example.com:abcdef:11223344:00000001:auth:65a8e2285879283831b664bd8b7f14d4' > sip.hash + +# Crack with a wordlist +hashcat -a 0 -m 11400 sip.hash /path/to/wordlist.txt +``` + +> [!NOTE] +> RFC 8760 definiert SHA-256 und SHA-512/256 für HTTP Digest (wird auch von SIP Digest verwendet). Die Adoption ist uneinheitlich; stelle sicher, dass deine Tools diese unterstützen, wenn du moderne PBX-Systeme anvisierst. + +### SIP über TLS (SIPS) und über WebSockets + +- Signalisierungsverschlüsselung: +- `sips:`-URIs und TCP/TLS typischerweise auf Port 5061. Überprüfe die Zertifikatsvalidierung an den Endpunkten; viele akzeptieren self-signed- oder wildcard-Zertifikate, was in schwachen Deployments MitM ermöglicht. +- WebRTC-Softphones verwenden oft SIP über WebSocket gemäß RFC 7118 (`ws://` oder `wss://`). Wenn die PBX WSS exposiert, teste Authentifizierung und CORS und stelle sicher, dass Rate-Limits auch am HTTP-Frontend durchgesetzt werden. + +### DoS-Schnellchecks (Protokollebene) + +- Flooding mit INVITE, REGISTER oder fehlerhaften Nachrichten kann die Transaktionsverarbeitung erschöpfen. +- Einfaches Rate-Limiting-Beispiel für UDP/5060 (Linux iptables hashlimit): + +```bash +# Limit new SIP packets from a single IP to 20/s with burst 40 +iptables -A INPUT -p udp --dport 5060 -m hashlimit \ +--hashlimit-name SIP --hashlimit 20/second --hashlimit-burst 40 \ +--hashlimit-mode srcip -j ACCEPT +iptables -A INPUT -p udp --dport 5060 -j DROP +``` + +### Kürzliche, relevante SIP-Stack-CVEs (Asterisk PJSIP) + +- CVE-2024-35190 (veröffentlicht 17. Mai 2024): In bestimmten Asterisk-Releases konnte `res_pjsip_endpoint_identifier_ip` unautorisierte SIP-Anfragen fälschlich als lokalen Endpoint identifizieren, was möglicherweise unautorisierte Aktionen oder Informationsausgabe ermöglichte. Behoben in 18.23.1, 20.8.1 und 21.3.1. Validieren Sie Ihre PBX-Version beim Testen und melden Sie verantwortungsvoll. + +### Härtungs-Checkliste (SIP-spezifisch) + +- Bevorzuge TLS für Signalisierung und SRTP/DTLS-SRTP für Media; deaktivere Cleartext, wo möglich. +- Erzwinge starke Passwörter und Digest-Algorithmen (SHA-256/512-256 wo unterstützt; vermeide MD5). +- Für Asterisk: +- chan_sip: `alwaysauthreject=yes`, `allowguest=no`, per-endpoint `permit`/`deny` CIDR-ACLs. +- PJSIP: Erstelle keinen `anonymous`-Endpoint, wenn nicht erforderlich; erzwinge Endpoint-`acl`/`media_acl`; aktiviere fail2ban oder ein Äquivalent. +- Topology hiding auf SIP-Proxys (z. B. outbound proxy/edge SBC), um information leak zu reduzieren. +- Striktes `OPTIONS`-Handling und Rate-Limits; deaktiviere ungenutzte Methoden (z. B. `MESSAGE`, `PUBLISH`), wenn sie nicht benötigt werden. + + + +## Referenzen + +- RFC 8760 – Using SHA-256 and SHA-512/256 for HTTP Digest (applies to SIP Digest too): https://www.rfc-editor.org/rfc/rfc8760 +- Asterisk GHSA advisory for CVE-2024-35190: https://github.com/asterisk/asterisk/security/advisories/GHSA-qqxj-v78h-hrf9 {{#include ../../../banners/hacktricks-training.md}}