<summary><strong>Lernen Sie AWS-Hacking von Null auf Held mit</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* 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)!
* **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.
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.
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.
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.
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.
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.
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 <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" dient zur eindeutigen Identifizierung der Rolle des Absenders im Dialog.
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: <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 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
*`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.
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.
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).
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**.
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.
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.
