今回から,数回に分けて実際のぜい弱性やリスクについて解説していく。主に攻撃手法の観点から,SIP,RTP(RTCP),その他のプロトコルの順に進める予定だ。少々技術的に深い内容になるがご了承いただきたい。

SIPスタックの実装の未熟さを突く攻撃

 プロトコル・スタックの実装の弱点を突く攻撃のことを「Malformed Method」と呼ぶ。試験手法の観点から「Fuzzy Test」,「Torture Test」といった言い方をすることもある。この攻撃は,SIPのプロトコル・フォーマットにおける例外処理が甘いシステムにおいて,バッファ・オーバーフローや再起動を引き起こす。

 この問題はSIP/VoIPシステム上のぜい弱性として最も早くから指摘されており (CERT Advisory CA-2003-06),また他のネットワーク上のシステムに比べ,一番対応の遅れているぜい弱性の一つである。IETFでもRFC4475(Session Initiation Protocol (SIP) Torture Test Messages)としてまとめられている。また,IPv6上のSIPに特有の問題がRFC5118 (Session Initiation Protocol (SIP) Torture Test Messages for Internet Protocol Version 6 (IPv6))としてまとめられており,関心が高まっている。

問題の発現状況及び影響

 我々が試験してきた各ベンダーのSIPエンティティ(SIPサーバー/端末などの機器)は,ゲートウエイ,端末,サーバーといった種類に関係なく,約3分の2のエンティティで1カ所~数カ所の問題が見つかっている。また,CERTなどぜい弱性データベースを見てもSIPエンティティにおいて最も多いのがSIPスタックのぜい弱性に起因する問題である。

 このぜい弱性が突かれると,システムの再起動や通話中の呼が切断されるなどの事象が発生する。システムがダウンしなくても,メモリー・エリアが破壊されたり,バッファが“汚されたり”してしまい,その後の呼処理がおかしくなるケースがある。

 問題が起こるプロセスはSIPスタック部分だけとは限らない。受信したSIPメッセージを解析し接続ポリシーを決定する上位のアプリケーション部分や,SIPメッセージから必要部分を抽出し,課金データを生成するためのソフトウエアといった個所でプロセスダウンに陥るケースがある。どちらもSIPスタックとその他のアプリケーションの許容範囲が異なることから起こる。

SIPのぜい弱性を突く攻撃の影響範囲

 この問題は,全てのエンティティ種別で起こる可能性がある。さらに,やっかいなのは,ファイアウォールやSBC(セッション・ボーダー・コントローラ)で守られているエンティティでも起こるケースがあることだ。ファイヤウォールは基本的には未使用のポートへの接続や許可されているIP以外からの接続を遮断するためのシステムである。

 しかし,この種の攻撃はサービスで使用しているSIPのポートに対し行われるため,ファイヤウォールをくぐり抜けてくる。また,RTPで使用するポートは一意ではなくランダムなため,UDP全体をファイヤウォールの監視対象から外しているケースもある。一方,SBCのようなSIPメッセージ内容を認識するエンティティを使っていたとしても,例えば発信者情報の扱いを定義する「Privacy」や「P-Asserted-Identity」といったヘッダはそのままコピーしてメッセージを送出する。そのため,ルーティング先のSIPサーバーがダウンする,といったケースが実際にある。

SIPプロトコル・フォーマット違反でないケースでも発生

 SIPのプロトコル・フォーマットに違反するメッセージだけでなく,通常使用されないだろうと設計者が考える文字列でも頻繁に問題が起こっている。

 ISUP(ISDN user part)のように,フィールド長がほぼ固定で16進で表すプロトコルと異なり,SIPはプレーン・テキストのプロトコルである。そのため使用可能な文字の幅が広く,またフィールドで使用可能な文字列が少しずつ異なっていることが実装を難しくしている。

 さらに,RFCが各ヘッダーやパラメータ長について言及することはほとんどない。だが,実際のSIPスタックは,限られたリソースの中で実装する必要があるため,ヘッダー長やパラメータ長,あるいはメッセージ全体のサイズに何らかのリミットを設けていることが多い。

ダイアログ内リクエストやレスポンスでも発生する

 この問題は必ずしも「INVITE」のようなダイアログを生成するリクエストで起こるとは限らない。「CANCEL」,「BYE」といったリクエストを受信した際や,レスポンスを受信した場合も発生する。

 SIPスタックは待ち受けポートで受信したメッセージを,種別を問わず解釈しようとする。例えば,セッションが生成されていない状態でBYEリクエストを受信すると,ほとんどのSIPエンティティは481レスポンスを返送する。これは,BYEを受信した際,順番の違いはあれ,BYEリクエストであること,同一セッションがあるかを確認するためにFromやToのタグ,「Call-ID」,「CSeq」,「Request-URI」といった個所を確認している結果である。こうして確認をしようとしたメッセージが不正なもので,かつ受信したエンティティにぜい弱性があると問題が出現する。

 さらに意図的な攻撃でなくても問題は発生する。単にバグを持つSIPエンティティが不正なメッセージを送信してきたり,SIPメッセージを何段も転送していくことでViaヘッダなどが長くなることで問題となるケースもある。

 次回は具体的にどのようなメッセージが問題を引き起こすかを具体例を参照しながら見ていこう。

杉岡弘毅 (すぎおかこうき)
ネクストジェン ネットワークセキュリティ本部長
ネクストジェン起業時から参加し,SIP関連のシステム検証やSEなどに従事した後,現在はセキュリティ関連調査や技術開発に従事している。