mirror of https://github.com/carlospolop/hacktricks synced 2024-11-26 22:52:06 +00:00

Translator 155938eb4f Translated ['macos-hardening/macos-security-and-privilege-escalation/mac

2024-07-19 11:30:53 +00:00

20 KiB

Raw Blame History

SIP (Session Initiation Protocol)

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

Check the subscription plans!
Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

{% endhint %} {% endhint %}

Grundinformationen

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.

Einige wichtige Merkmale von SIP sind:

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.
Skalierbarkeit und Flexibilität: SIP ist hochgradig 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.
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.
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 größere Flexibilität und Kompatibilität mit verschiedenen Medientypen und Codecs.
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.
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.

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.

SIP-Methoden

Die grundlegenden SIP-Methoden, die in RFC 3261 definiert sind, umfassen:

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.
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.
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.
CANCEL: Wird gesendet, um eine ausstehende INVITE-Anfrage vor der Etablierung der Sitzung zu stornieren. 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.
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.
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.

{% hint style="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-Anfrage durchzuführen, oder er erhält eine 401 Unauthorized-Antwort. {% endhint %}

Neben diesen grundlegenden Methoden gibt es mehrere SIP-Erweiterungsmethoden, die in anderen RFCs definiert sind, wie zum Beispiel:

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.
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.
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übertragungs-Szenarien verwendet.
MESSAGE: In RFC 3428 definiert, wird die MESSAGE-Methode verwendet, um Sofortnachrichten zwischen SIP-Benutzeragenten zu senden, was textbasierte Kommunikation innerhalb des SIP-Rahmens ermöglicht.
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.
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.

SIP-Antwortcodes

1xx (Provisorische 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 annehmen.
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 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.
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.
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 (Client-Fehlerantworten): Diese Antworten zeigen an, dass die Anfrage eine 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.
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.
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 ist beim Verarbeiten der Anfrage auf einen Fehler gestoßen.
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.
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.

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 <sip:jdoe@example.com>
From: Jane Smith <sip:jsmith@example.org>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:jsmith@pc33.example.com>
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

Jeder Parameter erklärt

Request-Line: INVITE sip:jdoe@example.com SIP/2.0 - Diese Zeile gibt die Methode (INVITE), die Anforderungs-URI (sip:jdoe@example.com) und die SIP-Version (SIP/2.0) an.
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.
Max-Forwards: Max-Forwards: 70 - Dieses Headerfeld begrenzt die Anzahl der Male, die die Anfrage von Proxys weitergeleitet werden kann, um unendliche Schleifen zu vermeiden.
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).
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). Der "tag"-Parameter wird verwendet, um die Rolle des Absenders im Dialog eindeutig zu identifizieren.
Call-ID: Call-ID: a84b4c76e66710 - Der Call-ID-Header identifiziert eine Anrufsession zwischen zwei Benutzeragenten eindeutig.
CSeq: CSeq: 314159 INVITE - Der CSeq-Header enthält eine Sequenznummer und die Methode, die in der Anfrage verwendet wird. Er wird verwendet, um Antworten auf Anfragen abzugleichen und außer der Reihe gesendete Nachrichten zu erkennen.
Contact: Contact: <sip:jsmith@pc33.example.com> - Der Contact-Header bietet einen direkten Weg zum Absender, der für nachfolgende Anfragen und Antworten verwendet werden kann.
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.
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.
Content-Type: Content-Type: application/sdp - Der Content-Type-Header gibt den Medientyp des Nachrichtenkörpers an, in diesem Fall SDP (Session Description Protocol).
Content-Length: Content-Length: 142 - Der Content-Length-Header gibt die Größe des Nachrichtenkörpers in Bytes an.
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.

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)
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.
a=rtpmap:0 PCMU/8000 - Attribut, das das Format (0) dem Codec (PCMU) und seiner Taktfrequenz (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, wohin eingehende SIP-Anfragen, die für den registrierten Benutzer bestimmt sind, geleitet werden sollen. Der Registrar-Server ist normalerweise Teil eines SIP-Proxy-Servers oder eines dedizierten Registrierungsservers.

Hier ist ein detailliertes Beispiel der SIP-Nachrichten, die an einem REGISTER-Authentifizierungsprozess beteiligt sind:

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:alice@example.com>;tag=565656
To: Alice <sip:alice@example.com>
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

Diese initiale REGISTER-Nachricht wird von der 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) und die Kontaktadresse des Benutzers (sip:alice@192.168.1.100:5060).

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:alice@example.com>;tag=565656
To: Alice <sip:alice@example.com>;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 erforderlich sind, damit sich der UA authentifizieren kann, wie z.B. den Authentifizierungsbereich, Nonce und Algorithmus.

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:alice@example.com>;tag=565656
To: Alice <sip:alice@example.com>
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 enthält, wie den Benutzernamen, das Realm, die Nonce und einen Antwortwert, der mit den bereitgestellten Informationen und dem Passwort des Benutzers berechnet wird.

So wird die Authorization-Antwort 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}")

Erfolgreiche Registrierung Antwort vom Registrierungsserver:

SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds
From: Alice <sip:alice@example.com>;tag=565656
To: Alice <sip:alice@example.com>;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. 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.

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 %} {% hint style="success" %} Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)