SIP (Session Initiation Protocol)

Tip

AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを学び、実践する：HackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポートする

• サブスクリプションプランを確認してください！
• **💬 Discordグループまたはテレグラムグループに参加するか、Twitter 🐦 @hacktricks_liveをフォローしてください。
• HackTricksおよびHackTricks CloudのGitHubリポジトリにPRを提出してハッキングトリックを共有してください。

基本情報

SIP (Session Initiation Protocol) は、IPネットワーク上で音声、ビデオ、インスタントメッセージを含むマルチメディアセッションの確立、変更、終了に広く使われるシグナリングおよび通話制御プロトコルです。Internet Engineering Task Force (IETF) によって開発され、RFC 3261 で定義されており、VoIPおよび統合コミュニケーションの事実上の標準となっています。

SIPの主な特徴は次のとおりです:

1. テキストベースのプロトコル: SIPはテキストベースのプロトコルであり、人間に読みやすくデバッグもしやすいです。HTTPに似たリクエスト-レスポンスモデルに基づいており、INVITE、ACK、BYE、CANCELなどのメソッドを使用して通話セッションを制御します。
2. スケーラビリティと柔軟性: SIPは高いスケーラビリティを持ち、小規模な導入から大規模なエンタープライズやキャリアグレードの環境まで利用できます。新機能で簡単に拡張できるため、さまざまなユースケースや要件に適応可能です。
3. 相互運用性: SIPの広範な採用と標準化により、異なるデバイス、アプリケーション、サービスプロバイダ間での相互運用性が向上し、さまざまなプラットフォーム間でのシームレスな通信を促進します。
4. モジュール設計: SIPはメディア伝送にRTP (Real-time Transport Protocol)、マルチメディアセッションの記述にSDP (Session Description Protocol) などの他プロトコルと連携します。このモジュール設計により、さまざまなメディアタイプやコーデックとの柔軟性と互換性が向上します。
5. プロキシおよびリダイレクトサーバ: SIPはプロキシやリダイレクトサーバを使用して通話ルーティングを支援し、転送、転送先変更、ボイスメールなどの高度な機能を提供できます。
6. プレゼンスとインスタントメッセージ: SIPは音声やビデオに限定されず、プレゼンスやインスタントメッセージもサポートしており、幅広い統合コミュニケーションアプリケーションを可能にします。

多くの利点がある一方で、NAT越えやファイアウォールの問題を扱う際には設定や管理が複雑になることがあります。それでも、その汎用性、スケーラビリティ、および業界での広範なサポートにより、VoIPやマルチメディア通信で広く採用されています。

SIP メソッド

RFC 3261 で定義されたコアなSIPメソッドには以下が含まれます:

1. INVITE: 新しいセッション（通話）を開始するか、既存のセッションを変更するために使用されます。INVITEメソッドはセッション記述（通常はSDPを使用）を運び、提案されたセッションのメディアタイプ、コーデック、トランスポートプロトコルなどの詳細を受信者に通知します。
2. ACK: INVITEリクエストに対する最終応答の受信を確認するために送信されます。ACKメソッドはINVITEトランザクションの信頼性を確保するためにエンドツーエンドの確認を提供します。
3. BYE: 確立されたセッション（通話）を終了するために使用されます。BYEメソッドはセッションのいずれかの参加者が通信を終了したいことを示すために送信します。
4. CANCEL: セッションが確立される前に保留中のINVITEをキャンセルするために送信されます。CANCELメソッドにより、送信者は心変わりした場合や受信者から返信がない場合にINVITEトランザクションを中止できます。
5. OPTIONS: SIPサーバやユーザエージェントの機能を照会するために使用されます。OPTIONSメソッドは、セッションを実際に確立することなく、サポートされているメソッド、メディアタイプ、またはその他の拡張についての情報を要求できます。
6. REGISTER: ユーザエージェントが現在の所在地をSIPレジストラサーバに登録するために使用します。REGISTERメソッドは、ユーザのSIP URIと現在のIPアドレスとの間の最新のマッピングを維持し、通話のルーティングと配信を可能にします。

Warning

誰かに発信するのに REGISTER を必ず使う必要はない ことに注意してください。
ただし、INVITEを行うために発信者が先に認証（authenticate）する必要があり、さもなければ401 Unauthorized の応答を受け取る可能性があります。

これらのコアメソッドに加えて、他のRFCで定義されたいくつかのSIP拡張メソッドもあります。たとえば:

1. SUBSCRIBE: RFC 6665で定義され、特定のリソース（ユーザのプレゼンスや通話状態など）の状態に関する通知を要求するために使用されます。
2. NOTIFY: 同じくRFC 6665で定義され、サーバが購読しているユーザエージェントに監視対象リソースの状態変化を通知するために送信します。
3. REFER: RFC 3515で定義され、受信者に対して転送を実行するか第三者を参照することを要求するために使用されます。これは通常、通話転送のシナリオで使われます。
4. MESSAGE: RFC 3428で定義され、SIPユーザエージェント間でインスタントメッセージを送信するために使用され、SIPフレームワーク内でのテキストベース通信を可能にします。
5. UPDATE: RFC 3311で定義され、既存のダイアログの状態に影響を与えることなくセッションを変更することを可能にします。通話中にコーデックやメディアパラメータを更新する際に有用です。
6. PUBLISH: RFC 3903で定義され、ユーザエージェントがサーバにイベント状態情報を公開し、他の関係者が利用できるようにします。

SIP 応答コード

• 1xx (Provisional Responses): これらの応答はリクエストが受信され、サーバが処理を継続していることを示します。
• 100 Trying: リクエストが受信され、サーバが処理中であることを示します。
• 180 Ringing: 被呼者に着信が通知され、応答（通話の受け入れ）を待っている状態です。
• 183 Session Progress: 通話の進行状況に関する情報を提供します。
• 2xx (Successful Responses): これらの応答はリクエストが正常に受信、理解、受諾されたことを示します。
• 200 OK: リクエストは成功し、サーバがそれを履行したことを示します。
• 202 Accepted: リクエストは処理のために受け入れられましたが、まだ完了していません。
• 3xx (Redirection Responses): これらの応答はリクエストを完了するためにさらに別のアクションが必要であることを示し、通常は別のリソースに連絡することを意味します。
• 300 Multiple Choices: 複数の選択肢があり、ユーザまたはクライアントがその中から選択する必要があります。
• 301 Moved Permanently: 要求されたリソースに新しい恒久的なURIが割り当てられました。
• 302 Moved Temporarily: 要求されたリソースは一時的に別のURIで利用可能です。
• 305 Use Proxy: リクエストは指定されたプロキシへ送信する必要があります。
• 4xx (Client Error Responses): これらの応答はリクエストに文法上の誤りがあるか、サーバがそれを履行できないことを示します。
• 400 Bad Request: リクエストが不正または無効であることを示します。
• 401 Unauthorized: リクエストにはユーザ認証が必要であることを示します。
• 403 Forbidden: サーバはリクエストを理解したが、履行を拒否しました。
• 404 Not Found: 要求されたリソースがサーバ上に見つかりません。
• 408 Request Timeout: サーバが待機できる時間内に完全なリクエストを受信しませんでした。
• 486 Busy Here: 被呼者は現在通話中で、通話を受けることができません。
• 5xx (Server Error Responses): これらの応答はサーバが有効なリクエストを履行するのに失敗したことを示します。
• 500 Internal Server Error: サーバがリクエスト処理中にエラーを検出したことを示します。
• 501 Not Implemented: サーバがリクエストを履行するために必要な機能をサポートしていません。
• 503 Service Unavailable: サーバは保守中または過負荷のため、現在リクエストを処理できません。
• 6xx (Global Failure Responses): これらの応答はネットワーク上のいかなるサーバでもリクエストを履行できないことを示します。
• 600 Busy Everywhere: 通話の可能なすべての宛先がビジー状態です。
• 603 Decline: 被呼者は通話に参加したくないことを示します。
• 604 Does Not Exist Anywhere: 要求されたリソースはネットワーク上どこにも存在しません。

例

SIP INVITE の例

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/8000

SIP REGISTER の例

REGISTER メソッドは Session Initiation Protocol (SIP) において、VoIP phone や softphone のような user agent (UA) が SIP registrar server に自分の位置を登録するために使用されます。この処理によりサーバは 登録されたユーザ宛の着信 SIP リクエストをどこにルーティングするか を把握できます。registrar server は通常 SIP proxy server の一部か、専用の registration server です。

以下は REGISTER 認証プロセスでやり取りされる SIP メッセージの詳細な例です:

1. Initial REGISTER request from UA to the 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

この最初の REGISTER メッセージは UA (Alice) によって registrar サーバーに送信されます。メッセージには、希望する登録期間 (Expires)、ユーザーの SIP URI (sip:alice@example.com)、およびユーザーの連絡先アドレス (sip:alice@192.168.1.100:5060) などの重要な情報が含まれます。

2. registrar サーバーからの 401 Unauthorized レスポンス:

SIP/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

レジストラサーバは “401 Unauthorized” メッセージで応答し、“WWW-Authenticate” ヘッダを含みます。このヘッダには、UAが自身を認証するために必要な情報、例えば authentication realm、nonce、algorithm が含まれます。

3. REGISTER リクエスト 認証資格情報を含む:

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

UA は別の REGISTER リクエストを送信します。今回は、“Authorization” header with the necessary credentials, such as the username, realm, nonce, and a response value（与えられた情報とユーザーのパスワードを使用して計算される）を含めています。

これは Authorization response がどのように計算されるかです：

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. 登録成功 レジストラサーバーからのレスポンス:

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

認証が検証されると、レジストラサーバは “200 OK” を返して登録が成功したことを示します。レスポンスには登録されたコンタクト情報と登録の有効期限が含まれます。この時点でユーザーエージェント (Alice) は SIP レジストラサーバに正常に登録され、Alice 宛の着信 SIP リクエストは適切なコンタクトアドレスへルーティングできます。

Call Example

Tip

触れられていませんが、User B は着信を受け取る前に REGISTER message to Proxy 2 を送信している必要があります。

SIP Security and Pentesting Notes

このセクションでは、より広範な VoIP ガイダンスと重複しない実践的なプロトコル固有のヒントを追加します。エンドツーエンドの VoIP 攻撃手法、ツール、シナリオについては、以下を参照してください:

Pentesting VoIP

フィンガープリンティングと検出

• OPTIONS リクエストを送信し、Allow、Supported、Server、User-Agent ヘッダを確認してデバイスやスタックをフィンガープリントします:

# nmap NSE (UDP 5060 by default)
sudo nmap -sU -p 5060 --script sip-methods <target>

# Minimal raw OPTIONS over UDP
printf "OPTIONS sip:<target> SIP/2.0\r\nVia: SIP/2.0/UDP attacker;branch=z9\r\nFrom: <sip:probe@attacker>;tag=1\r\nTo: <sip:probe@<target>>\r\nCall-ID: 1@attacker\r\nCSeq: 1 OPTIONS\r\nMax-Forwards: 70\r\nContact: <sip:probe@attacker>\r\nContent-Length: 0\r\n\r\n" | nc -u -w 2 <target> 5060

ユーザー名/内線列挙の挙動

• 列挙は通常 REGISTER/INVITE に対する 401/407 と 404/403 の違いを悪用します。サーバの応答を均一化してハードニングしてください。
• Asterisk chan_sip: alwaysauthreject=yes を設定して有効なユーザの公開を避けます。新しい Asterisk (PJSIP) では、anonymous endpoint が定義されていない限り guest calling は無効化され、同様の “always auth reject” 挙動がデフォルトですが、境界でネットワーク ACL と fail2ban を適用してください。

SIP Digest Authentication: algorithms and cracking

• SIP は一般的に HTTP-Digest スタイルの認証を使用します。過去には MD5（および MD5-sess）が広く使われていましたが、新しいスタックは RFC 8760 に沿った SHA-256 や SHA-512/256 をサポートします。モダンな配備ではこれらの強いアルゴリズムを優先し、可能であれば MD5 を無効にしてください。
• pcap からのオフラインクラッキングは MD5 ダイジェストでは容易です。challenge/response を抽出した後、hashcat のモード 11400 (SIP digest, MD5) を使用できます:

# 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 は HTTP Digest（SIP でも使用される）に対して SHA-256 と SHA-512/256 を定義しています。採用状況はまちまちなので、モダンな PBX を対象にする際はツールがこれらに対応していることを確認してください。

SIP over TLS (SIPS) and over WebSockets

• シグナリングの暗号化:
• sips: URI と TCP/TLS は通常ポート 5061 を使用します。エンドポイントでの証明書検証を確認してください。多くは self-signed や wildcard certs を受け入れるため、弱い配備では MitM を許してしまう場合があります。
• WebRTC softphone は RFC 7118 に従い SIP over WebSocket (ws:// または wss://) を使うことが多いです。PBX が WSS を公開している場合は認証と CORS をテストし、HTTP フロントエンド側でもレート制限が適用されていることを確認してください。

DoS quick checks (protocol level)

• INVITE、REGISTER、または不正なメッセージのフラッディングはトランザクション処理を枯渇させる可能性があります。
• UDP/5060 に対する簡単なレート制限の例（Linux iptables hashlimit）:

# 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

注意すべき最近の関連 SIP スタック CVE (Asterisk PJSIP)

• CVE-2024-35190 (published May 17, 2024): 特定の Asterisk リリースにおいて、res_pjsip_endpoint_identifier_ip が不正な SIP リクエストをローカルエンドポイントと誤識別する可能性があり、不正な操作や情報露出を引き起こす可能性がありました。18.23.1、20.8.1、21.3.1 で修正されています。テスト時は PBX のバージョンを確認し、責任ある報告を行ってください。

ハードニングチェックリスト（SIP 固有）

• シグナリングには TLS、メディアには SRTP/DTLS-SRTP を優先し、可能な限り平文を無効にしてください。
• 強力なパスワードとダイジェストアルゴリズム（対応があれば SHA-256/512-256 を使用し、MD5 は避ける）を強制してください。
• Asterisk 向け:
  • chan_sip: alwaysauthreject=yes、allowguest=no、エンドポイントごとの permit/deny CIDR ACL を設定。
  • PJSIP: 必要でない限り anonymous endpoint を作成しないこと。endpoint の acl/media_acl を強制し、fail2ban などを有効にする。
• SIP プロキシでのトポロジーハイディング（例: outbound proxy/edge SBC）により情報漏洩を減らす。
• OPTIONS の厳格な処理とレート制限；不要なメソッド（例: MESSAGE, PUBLISH）は不要なら無効にする。

References

• 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

Tip

AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを学び、実践する：HackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポートする

• サブスクリプションプランを確認してください！
• **💬 Discordグループまたはテレグラムグループに参加するか、Twitter 🐦 @hacktricks_liveをフォローしてください。
• HackTricksおよびHackTricks CloudのGitHubリポジトリにPRを提出してハッキングトリックを共有してください。