NTTひかり電話ルータ:SIPのクレデンシャルを取得可能な脆弱性

はじめに

IPAに2年前くらいに脆弱性として報告した事象について書きます。
報告は2021年9月頃に実施し、2022年5月頃に取り扱いを開始した案件です。
2023年7月に非開示請求取り下げの手続きを完了したものです。
NTTは、「本件は脆弱性ではない」と言っているようでIPAは対応に苦慮している様子でした。
IPAの対応の邪魔にならないように公開していこうと思います。

ゼロデイ脆弱性です。

つまり？

取扱開始して1年以上経ったから、公開させてーって言ったら公開していいよーってIPAから正式に言われたので詳細を書いていくねって言うことです。
公開した情報については、自宅のネットワークのセキュリティ強化に使ってください。
受け取りようによっては「本件は脆弱性ではない」ではありますが
普通にゼロデイ脆弱性なのでネットワークに侵入さえできれば悪用は可能です。

三行で説明すると

• 本来、SIPサーバには認証するためのIDとパスワードが必要だよ。
• NTTの設計した脆弱なWebAPIのせいで、SIPクライアントが使うIDとパスワードを未認証で取れるよ。
• NTT「仕様なのでヨシッ」←良くないんだが？？？？

影響を受けるルータは？

多分このあたり全般

どんな脆弱性なの？

NTTのホームゲートウェイにSIPの未使用アカウントを外部から未認証でリスティングできる脆弱性です。
PoCはこちらから取得できます。

もちろん使用中のアカウントもMACアドレスを適切に設定することで取得できます。
PoCなので、そこまではやってませんが。

問題点は？

ルータに対してHTTPでアクセスできれば無認証でSIPアカウントを取得できてしまうことが問題です。
せめて何らかの認証プロトコルによる認証を掛けていれば話は別だったんですが。

表現を変えると、ルータの管理コンソールのトップ画面にはBasic認証掛かっています。ですが、本脆弱性に関するWebAPIには認証が一切かかっていません。

影響は？

最近流行りの家庭用ルータを悪用できるような雰囲気の脆弱性です。
SIPアカウントさえ取れれば国際電話を "無料"で、かけ放題！
とか、色々です。

認証が掛かってないので、ネットワークに侵入できればやりたい放題です。

友達の家のWi-Fiを使うことができればできちゃうやつです。
不正アクセス禁止法に問われるのは、あくまでもWi-Fiへの侵入の部分なのでここさえ合法的（許可を取って）にやってしまえばあとはやりたい放題、好き放題です。

攻撃者視点のいろいろ

攻撃の例

• 普通に犯罪に使う
  • 足の付きづらい連絡網として。
  • 特殊詐欺の発信元として。
• 緊急通報にイタ電しまくろうぜ！
  • 公共インフラに対する業務妨害が発生する
  • おまけで、最近の警察のレベルだと誤認逮捕もして頂けるのでお得感が満載です。
  • 攻撃者にとっては一石二鳥！（「お前の家の電話番号やぞ！」みたいな。）
    • 特定の地方警察には正しい攻撃者的な知識がないので責任を被害者になすりつけられる可能性は高い。（マジでしっかりしてくれ。）
• あいつムカつくから、SIPで電話かけて経済的に破綻させようぜ！
  • 個人に対して金銭的な被害を生じさせられる。2～3桁万単位の請求とかマジで洒落にならない。
• あいつの家の電話使えなくしようぜ！
  • 個人宅の電話に対するサービス拒否攻撃、経済的にもやばい。
    • どこかに電話をかけ続けていれば使えなくなる。時報？

攻撃ベクタの例

• マルウェアを使う例
  • オープンソースのAndroidアプリにSIPダイヤラを混入し、Google Playで公開する
  • オープンソースのWindowsアプリにSIPダイヤラを混入し、任意のサイトで公開する
• WiFiに侵入する例
  • WEPの脆弱性を攻撃しパスワードクラックを行う
  • 管理者からパスワードを聞き出し、正規のルートで侵入する
  • デフォルトパスワードで侵入する
• ソーシャルハック
  • （ゲーム仲間の場合）「マイクラサーバなどのサーバツールを立てておいてほしい」と頼み、そのモジュールにSIPダイヤラ・外部から指示を出せるRATを混入しておく

など。

個人でできる対策は？

• WEP使わない。（WEP使うのだけは本当にやめてほしい）
• （部外者が家のLAN使う時は）ゲスト用VLANとホームゲートウェイのポートにはアクセスさせないパケットフィルタルールを作って、そこを使ってもらう。（アクセス制御を行ってルータのWeb管理コンソールにアクセスできないようにする）
• 無線LANは簡単なパスワードにしない

NTTさんへ

SIPアカウントを取得するAPIに対して、専用の認証・認可ロジックを作ってほしいです。
例えば、これらのAPIを発行する前段で auth_sip みたいなエンドポイントを呼び出して
トークンを発行したあとに、それぞれのAPIにトークンを渡して呼べるようにするとか。
もちろんそのトークンはすぐ失効できるようにしてほしかったりします。

ユーザは、初期設定でSIPのアカウントを取得するためのマスタークレデンシャル（以下の文脈では特に断りがない限り「パスワード」と表記します）を設定する。
それをAGEPhoneとかのアクセス情報を自動構成するクライアントにも設定するプレシェアードキー方式みたいなのにするでも全然強化できると思うので。

できれば、パスワードを生で送らずに、チャレンジを生成してチャレンジとパスワードをHMAC256でハッシュして返してもらって認証するという感じにしてほしい。（サーバは生のパスワードを保持してはいけないのでKDF使うか、ストレッチングして保管してほしいのでクライアント側もこれに合わせて認証時にストレッチングしてほしいけど。詳しくはNISTのガイドラインに載ってるのでそちらへ。）

Sをストレッチング関数（KDFでもいいし、ハッシュをストレッチング10000回する動作でも良い）
　S(パスワード)
とします。

HMAC_SHA256(チャレンジ,S(パスワード))
HMAC_SHA256: チャレンジをストレッチングしたマスターパスワードでメッセージダイジェスト化する

これをクライアントとサーバで計算したらいいんじゃないか？
と思った次第です。
もちろん、チャレンジはCSPRNGで生成した160bit以上の推測不能値であることが必要ですが。
（推測不能であることが保証できれば良いので256bit以上の強度でもいいです。）

今は、攻撃者が任意のタイミングでAPIを叩くだけで良いという、攻撃ハードルが非常に低い状態です。
せめて通信を常に監視してないと出来ない、位には難易度をあげるべきかなと思ったりしています。

ただし、経路を暗号化したり、サーバ証明をしているわけではないので一番いいのは経路をTLSのトンネル作って欲しいです。

疑問

なんのためのSIPアカウント（パスワード）なのか？
これが仕様だとしたら、SIPのパスワードは固定で良くないか？
（少なくとも設定画面で変えられるようなプロンプトである必要性がないし、ランダムっぽい文字列でなくても良いはず）

以上！