Mirrors/hacktricks

Fork 0

mirror of https://github.com/carlospolop/hacktricks synced 2024-12-19 09:34:03 +00:00

Translator workflow 6af5d4e1a0 Translated to German

2024-02-10 15:36:32 +00:00

17 KiB

Raw Blame History

SIP (Session Initiation Protocol)

Lernen Sie AWS-Hacking von Grund auf mit htARTE (HackTricks AWS Red Team Expert)!

Andere Möglichkeiten, HackTricks zu unterstützen:

Wenn Sie Ihr Unternehmen in HackTricks bewerben 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-Repositories senden.

Grundlegende Informationen

SIP (Session Initiation Protocol) ist ein Signalisierungs- und Anrufsteuerungsprotokoll, das weit verbreitet für die Einrichtung, Änderung und Beendigung von Multimedia-Sitzungen verwendet wird, einschließlich Sprache, Video und Sofortnachrichten, über IP-Netzwerke. Entwickelt von der Internet Engineering Task Force (IETF), wird SIP in RFC 3261 definiert und ist zum De-facto-Standard für VoIP und Unified Communications geworden.

Einige wichtige Merkmale von SIP sind:

Textbasiertes Protokoll: SIP ist ein textbasiertes Protokoll, das es lesbar und einfacher zu debuggen macht. Es basiert auf einem Anforderungs-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 hoch skalierbar und kann in kleinen Bereitstellungen sowie in großen Unternehmens- und Carrier-Umgebungen verwendet werden. Es kann leicht mit neuen Funktionen erweitert werden, was es anpassungsfähig für verschiedene Anwendungsfälle und Anforderungen macht.
Interoperabilität: Die weite Verbreitung 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.
Modulares Design: SIP arbeitet mit anderen Protokollen wie RTP (Real-time Transport Protocol) für die Medienübertragung und SDP (Session Description Protocol) für die Beschreibung von Multimedia-Sitzungen zusammen. Dieses modulare Design ermöglicht eine größere Flexibilität und Kompatibilität mit verschiedenen Medientypen und Codecs.
Proxy- und Umleitungs-Server: SIP kann Proxy- und Umleitungs-Server verwenden, um die Anrufweiterleitung zu erleichtern und erweiterte Funktionen wie Anrufweiterleitung, Anrufumleitung und Voicemail-Dienste bereitzustellen.
Präsenz und Sofortnachrichten: SIP ist nicht nur auf Sprach- und Video-Kommunikation 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, wenn es um die Konfiguration und Verwaltung geht, insbesondere bei der Bewältigung von NAT-Traversal- und Firewall-Problemen. Seine Vielseitigkeit, Skalierbarkeit und umfangreiche Unterstützung in der Branche machen es jedoch zu einer beliebten Wahl für VoIP und Multimedia-Kommunikation.

SIP-Methoden

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

INVITE: Wird verwendet, um eine neue Sitzung (Anruf) zu initiieren oder eine bestehende zu ändern. Die INVITE-Methode enthält die Sitzungsbeschreibung (in der Regel mit SDP), um den Empfänger über die Details der vorgeschlagenen Sitzung zu informieren, wie z.B. Medientypen, Codecs und Transportprotokolle.
ACK: Wird gesendet, um den Empfang einer endgültigen Antwort auf eine INVITE-Anforderung zu bestätigen. Die ACK-Methode gewährleistet die Zuverlässigkeit von INVITE-Transaktionen durch Bereitstellung einer End-to-End-Bestätigung.
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.
CANCEL: Wird gesendet, um eine ausstehende INVITE-Anforderung abzubrechen, 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.
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 herzustellen.
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 zum Anrufen einer Person nicht erforderlich ist, das REGISTER für irgendetwas zu verwenden.
Es ist jedoch möglich, dass der Anrufer zur Durchführung eines INVITE zuerst authentifiziert werden muss, oder er erhält eine 401 Unauthorized-Antwort. {% endhint %}

Neben diesen Kernmethoden gibt es mehrere SIP-Erweiterungsmethoden, die in anderen RFCs definiert sind, wie z.B.:

SUBSCRIBE: In RFC 6665 definiert, wird die SUBSCRIBE-Methode verwendet, um Benachrichtigungen über den Zustand einer bestimmten Ressource anzufordern, z.B. die Präsenz oder den Anrufstatus eines Benutzers.
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.
REFER: In RFC 3515 definiert, wird die REFER-Methode verwendet, um den Empfänger zur Durchführung eines Transfers oder zur Weiterleitung an eine dritte Partei aufzufordern. Dies wird in der Regel für Szenarien der Anrufweiterleitung verwendet.
MESSAGE: In RFC 3428 definiert, wird die MESSAGE-Methode verwendet, um Sofortnachrichten zwischen SIP-Benutzeragenten zu senden und eine textbasierte Kommunikation im SIP-Framework zu ermöglichen.
UPDATE: In RFC 3311 definiert, ermöglicht die UPDATE-Methode die Änderung 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

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

Erklärung jedes Parameters

Request-Line: INVITE sip:jdoe@example.com SIP/2.0 - Diese Zeile gibt die Methode (INVITE), die Anfrage-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 Parameter "branch" wird zur Schleifenerkennung und Transaktionszuordnung verwendet.
Max-Forwards: Max-Forwards: 70 - Dieses Header-Feld begrenzt die Anzahl der Weiterleitungen der Anfrage durch Proxies, um Endlosschleifen 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 Parameter "tag" wird verwendet, um die Rolle des Absenders im Dialog eindeutig zu identifizieren.
Call-ID: Call-ID: a84b4c76e66710 - Der Call-ID-Header identifiziert eindeutig eine Anrufsession zwischen zwei Benutzeragenten.
CSeq: CSeq: 314159 INVITE - Der CSeq-Header enthält eine Sequenznummer und die verwendete Methode in der Anfrage. Er wird verwendet, um Antworten den Anfragen zuzuordnen und Nachrichten in falscher Reihenfolge zu erkennen.
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.
User-Agent: User-Agent: ExampleSIPClient/1.0 - Der User-Agent-Header enthält Informationen über die Software oder Hardware des Absenders, einschließlich des Namens und der 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 Nachrichtenrumpfs an, in diesem Fall SDP (Session Description Protocol).
Content-Length: Content-Length: 142 - Der Content-Length-Header gibt die Größe des Nachrichtenrumpfs in Bytes an.
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 gibt keinen Sitzungsnamen an)
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 mit 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 Taktrate (8000 Hz) zuordnet.

SIP REGISTER Beispiel

Die REGISTER-Methode wird in Session Initiation Protocol (SIP) verwendet, um einem Benutzeragenten (UA), wie einem VoIP-Telefon oder einem Softphone, das seinen Standort bei einem SIP-Registrar-Server registrieren möchte, dies zu ermöglichen. Dieser Prozess informiert den Server darüber, wohin eingehende SIP-Anfragen für den registrierten Benutzer weitergeleitet werden sollen. Der Registrar-Server ist normalerweise Teil eines SIP-Proxy-Servers oder eines dedizierten Registrierungsservers.

Hier ist ein detailliertes Beispiel für die SIP-Nachrichten, die in einem REGISTER-Authentifizierungsprozess verwendet werden:

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 erste 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) 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 für die Authentifizierung des UA erforderlich sind, wie z.B. den Authentifizierungsbereich, die Nonce und den 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 Benutzername, Bereich, nonce und einen berechneten Antwortwert unter Verwendung der bereitgestellten Informationen und des Benutzerpassworts.

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}")

Erfolgreiche Registrierungsantwort vom Registrar-Server:

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 der 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.

Beispielanruf

{% hint style="info" %} Es wird nicht erwähnt, aber Benutzer B muss zuerst eine REGISTER-Nachricht an Proxy 2 gesendet haben, bevor er Anrufe empfangen kann. {% endhint %}