103
【 項目14. 認証機能の不十分な実装の問題 】
104
SIPリクエストに対して、401/407レスポンスで認証要求を受けたSIP端末(UAC)は認証 情報を追加したSIPリクエストを再送する。
Authorization: Digest username="bob", realm="biloxi.com",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", uri="sip:[email protected]",
qop=auth, nc=00000001,
cnonce="0a4f113b",
response="6629fae49393a05397450978507c4ef1", opaque="5ccc069c403ebaf9f0171e9517f40e41"
このとき、cnonceやncなどのデータを追加して、ハッシュ値(response)を計算する。
nonce,opaqueは認証要求が生成される都度、サーバやUASが新たに生成する値である。
cnonce は認証要求に対してUAC が生成するランダムなトークンで、任意のタイミングで
新しいcnonceに変更できる値である。cnは同じcnonceを使い続ける場合のカウントで1
から始まりで1ずつ増えていく値である。
認証情報をチェックする側は自分が生成した認証要求や最新の認証情報のパラメータを 記憶し、チェックする必要がある。例えば、自分が生成していない nonce パラメータを許 容してしまうと、偽装メッセージの生成時に本来は認証要求をキャプチャしなければなら ないパラメータを、ランダムに生成するだけでよくなり、偽装の難易度が下がってしまう。
また、nc の増加をチェックしないようなサーバは、キャプチャしたリクエストのリプレイ 攻撃を受け付けてしまうことになる。
14.3 対策
【運用ガイド】
1) IPsec、SSL-VPNなどの暗号化トンネルを使ってSIP通信を保護する 2) SIP/RTPネットワークを隔離する、閉じたネットワークを利用する
3) ファイアウォールや侵入検知システムなど、製品とネットワークとの間で、この脆弱性を狙った パケットを遮断、制限する装置を挿入する
【実装ガイド】
1) データのチェックを徹底する
ダイジェスト認証を実装する際には、変化すべきでないデータと、変化していなければならない データをしっかりチェックしなければならない。
サーバ/UASでの認証情報に関するヘッダレベルのチェック項目は以下のようになる。
① Call-IDヘッダが同じか
② Fromヘッダが同じか(IP電話で非通知の場合は除く)
③ CSeqが増えているか
④ SIPリクエストの種類(SIPメソッド)が同じか
⑤ Toヘッダが同じか
105
また、サーバ/UASでの認証ヘッダのチェック項目は以下のようになる。
① usernameの登録チェック
② uriの登録チェック
③ realmが認証要求と同じか
④ nonceが認証要求と同じか
⑤ opaqueが認証要求と同じか
⑥ ncは前回から増えているか(初回なら次回に備えて記憶)
⑦ cnonceが新しい(初回:nc=1)なら次回に備えて記憶、古い(2回目以降)なら前回と同じか
⑧ responseは正しいハッシュ値か 2) クライアントはcnonceを定期的に変更する
3) サーバからも認証要求のパラメータを定期的に更新(nonce,opaque)する
クライアントはサーバからのパラメータ変更に対応できるように実装する必要がある 4) Secure SIP (SIP over TLS)の実装
【 項目14. 認証機能の不十分な実装の問題 】
106
14.4 参考情報
公開年月 情報源
1999年6月 RFC2617 HTTP Authentication: Basic and Digest Access Authentication http://tools.ietf.org/html/rfc2617
2002年 6月 RFC3261 SIP: Session Initiation Protocol 22 Usage of HTTP Authentication
http://tools.ietf.org/html/rfc3261#section-22 2007年 3月 Siperaへの報告
Insufficient integrity checks on SIP digest authentication messages http://www.sipera.com/index.php?action=resources,threat_advisory&tid=
179&
2007年 3月 Siperaへの報告
Absence of server authentication during SIP digest authentication http://www.sipera.com/index.php?action=resources,threat_advisory&tid=
180&
2007年 3月 Siperaへの報告
Registrar honors replayed authentication parameters
http://www.sipera.com/index.php?action=resources,threat_advisory&tid=
181&
2007年 3月 Siperaへの報告
No cross-check performed between username of user requesting authentication and username used in credentials during SIP digest authentication
http://www.sipera.com/index.php?action=resources,threat_advisory&tid=
182&
2007年 3月 Siperaへの報告
Some implementations of SIP Proxy may honor replayed authentication credentials
http://www.sipera.com/index.php?action=resources,threat_advisory&tid=
183&
2007年 3月 Siperaへの報告
Service provider call feature servers may be vulnerable to service theft when sent a replayed and spoofed feature invocation message
http://www.sipera.com/index.php?action=resources,threat_advisory&tid=
188&
2007年 3月 Siperaへの報告
Service provider call feature servers may be vulnerable to call hijacking http://www.sipera.com/index.php?action=resources,threat_advisory&tid=
189&
2008年10月 Analysis of a VoIP Attack (Klaus Darilion, IPCom)
http://www.ipcom.at/fileadmin/public/2008-10-22_Analysis_of_a_VoIP_At tack.pdf
2008年10月、ドイツのVoIPユーザ向けの大量着信事件は、「インターネット上の IP電話から一般電話網への無料の中継を可能にするプロキシを探すものだった」
とする指摘。
SIPサーバ、SIP proxy、SIPゲートウェイは、特定のレルムや、認証済みのユー ザからの発信呼以外は中継しないよう、注意喚起している。
107
14.5 CVSS 深刻度評価(参考値)
【評価結果】
本脆弱性の深刻度 □Ⅰ（注意） ■Ⅱ（警告） □Ⅲ（危険）
本脆弱性のCVSS基本値 5.1
【CVSS基本値の評価内容】
攻撃元区分 □ローカル □ 隣接 ■ネットワー ク
攻撃条件の複雑さ ■高 □中 □低 攻撃前の認証要否 □複数 □単一 ■不要 機密性への影響 □なし ■部分的 □全面的 完全性への影響 □なし ■部分的 □全面的 可用性への影響 □なし ■部分的 □全面的