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!

• Holen Sie sich das offizielle PEASS & HackTricks-Merchandise

• Entdecken Sie The PEASS Family, unsere Sammlung exklusiver NFTs

• Treten Sie der 💬 Discord-Gruppe oder der Telegramm-Gruppe bei oder folgen Sie uns auf Twitter 🐦 @carlospolopm.

• Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an die HackTricks und 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.

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.

Beispiele

SIP INVITE Beispiel

INVITE sip:[e-mail] SIP/2.0
Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: John Doe <sip:[e-mail]>
From: Jane Smith <sip:[e-mail]>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:[e-mail]>
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:[e-mail] SIP/2.0 - Diese Zeile gibt die Methode (INVITE), die Anforderungs-URI (sip:[e-mail]) 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:[e-mail]> - Der To-Header gibt den Empfänger des Anrufs an, einschließlich seines Anzeigenamens (John Doe) und der SIP-URI (sip:[e-mail]).

5. From: From: Jane Smith <sip:[e-mail]>;tag=1928301774 - Der From-Header gibt den Absender des Anrufs an, einschließlich seines Anzeigenamens (Jane Smith) und der SIP-URI (sip:[e-mail]). 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: <sip:[e-mail]> - 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:

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:[e-mail]>;tag=565656
To: Alice <sip:[e-mail]>
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

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:[e-mail]) und die Kontaktadresse des Benutzers (sip:alice@192.168.1.100:5060).

2. 401 Unauthorized Antwort vom Registrar-Server:

cssCopy codeSIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds
From: Alice <sip:[e-mail]>;tag=565656
To: Alice <sip:[e-mail]>;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:

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:[e-mail]>;tag=565656
To: Alice <sip:[e-mail]>
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 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:

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:

SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds
From: Alice <sip:[e-mail]>;tag=565656
To: Alice <sip:[e-mail]>;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 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

Es wird nicht erwähnt, aber Benutzer B muss eine REGISTER-Nachricht an Proxy 2 gesendet haben, bevor er Anrufe empfangen kann.