Salt Typhoon後に露呈した通信スタックの不安定性
(soatok.blog)- Salt Typhoonによる侵害の後、通信系オープンソースを確認する過程で、FreeSWITCHにバンドルされたXMLRPCライブラリから認証不要のバッファオーバーフローが発見された
- この脆弱性は、攻撃者が与えるRequest URIを4096バイトのスタック変数に
sprintf()で書き込むコードで発生し、ブラウザの制限とは別に4096文字を超えるリクエストが可能な場合がある - SignalWireは、2025年2月に修正用PR 3件がGitHubで公開されたと回答したが、FreeSWITCH Communityの新しいリリースは2025年夏まで予定がないと明らかにした
- ShodanにはFreeSWITCHの検索結果が約8,300件あり、リリースタグのない運用者はソースビルドやファイアウォール遮断で自力対応しなければならない状況だった
- この事例は、通信セキュリティのリスクが脆弱性そのものだけでなく、脆弱性管理とリリース対応でも拡大することを示しており、2025年4月30日にCVE-2025-44087が割り当てられた後もFreeSWITCHのリリースはなかった
Salt Typhoon後にFreeSWITCHを調べることになったきっかけ
- 2024年末、中国政府との関連があるとされるSalt TyphoonグループがT-Mobileや他の通信事業者を侵害したという報道が出発点になった
- 移動通信事業者のネットワークを直接調査することはできなかったが、GitHubには通信関連のオープンソースプロジェクトが数多くあった
- 過去にAsteriskやFreeSWITCHを使う企業と仕事をした経験はあったが、PBX、SIP、音声エンコーディングを深く分析した経験はなかった
- 通信分野には優れたCプログラマー、古参のハッカーコミュニティ、Bell Labs出身エンジニアの伝統があり、単純な脆弱性はすでに発見されているだろうと予想していた
- しかし、FreeSWITCHのソースコードを開いてすぐに脆弱性が見つかった
XMLRPC HTTPリクエストハンドラのバッファオーバーフロー
- FreeSWITCHにバンドルされたXMLRPCライブラリのHTTPリクエストハンドラは、固定長スタックバッファ
z[4096]にURIを書き込む - 問題のコードは
sprintf(z, "Index of %s" CRLF, uri);という形で、uriはRequest URIのpath部分に由来するため、攻撃者が制御できる - 一般的なブラウザは2048文字を超えるURLを十分にサポートしないことが多いが、関連RFCの多くはおよそ8KBまで許容しており、Cloudflareは32KBまで対応している
- 攻撃者が4096文字を超えるRequest URIを送れると考えるのは合理的であり、この条件がXMLRPCライブラリの認証不要バッファオーバーフローにつながる
- リモートコード実行へ拡張する過程は扱わない
修正方法と公開されたパッチ
- 修正の方向性は、
sprintf()の代わりに**snprintf()**を使うことだった - これは基本的な防御的Cプログラミングの慣行にあたる
- SignalWireは、問題は最近修正されたとして次のPRを示した
- パッチはすでにGitHub上で公開されていたため、公開記事を書けると判断した
脆弱性開示の流れとリリースの空白
- 2025年1月27日、FreeSWITCHのセキュリティポリシーに記載されたメールアドレスへ脆弱性の詳細を送った
- 2025年2月7日、報告を受け取ったか確認するフォローアップメールを送った
- 同日、Andrey Volkから、その脆弱性は最近修正されており関連PRを見てほしいとの返信があった
- 新しいセキュリティ修正を含むリリースタグの予定を尋ねると、FreeSWITCH Communityのリリースは2025年夏まで予定がないとの回答を受けた
- このため、FreeSWITCH Advantageに料金を支払っていないユーザーは、正式リリース時点まで脆弱なまま残る可能性がある
露出規模と運用者への影響
- 当時、ShodanでのFreeSWITCH検索結果は約8,300件だった
- これらのインスタンスがすべてエンタープライズサポートに支払いをしているとは考えにくく、世界中の数千の通信スタックが夏まで脆弱なまま残る可能性があると見られる
- パッチがGitHubで公開されていても、リリースタグがなければ一般の運用者が容易に更新するのは難しい
- FreeSWITCH運用者は、SignalWireのリリースを待つ代わりに次の対応を検討すべきだ
- ソースから直接再ビルドする
- ファイアウォールレベルでFreeSWITCHスタックの公開HTTPアクセスを遮断する
通信セキュリティの構造的問題
- 通信業界の知人との会話では、FreeSWITCHの対応速度ですら速いほうだという反応があった
- 2024年12月にも、電話網に17年間存在してきたSS7脆弱性への警告が再び出されていた
- この経験の後、Asteriskや他のソフトウェアを追加で調べることはしなかった
- 結論として、今日の通信セキュリティは良い状態ではないと評価される
- こうしたシステムを安全にすることで利益を得るインセンティブがほとんどないことが大きな原因に見える
その後の状況
- 2025年4月30日の更新で、報告されたバッファオーバーフローにCVE-2025-44087が割り当てられた
- その時点でもFreeSWITCHのタグやリリースはなかった
1件のコメント
Hacker News の意見
投稿者は通信事業者グレードのインフラ経験がまったくないと認めているが、疑念そのものはおおむね正しい
実際に複数の主要通信事業者を対象に 4G/5G のペネトレーションテストやセキュリティ研究をかなり行ってきたが、通信事業者や機器ベンダーによって差はあるものの、今でもほとんど完全な恐怖ショーに近い
ごく最近まで、セキュリティは実質的に隠蔽によるセキュリティだけで、4G/5G 標準がこれに取り組み始めたものの、今なお深刻に懸念すべき大きな穴が残っている
通信事業者内に足場を築こうとする中級以上の脅威アクターなら実現可能だと見ても誇張ではなく、職業上、何度も実演してきた
特定の東アジア諸国の機器ベンダーはソフトウェアスタックの品質があまりに低く、ほとんど APT に分類してもよいほどで、セキュリティは実質的に存在しない
西側諸国が彼らを禁止したのには妥当な理由があり、西側機器ベンダーのソフトウェアははるかに成熟しているが、それでも私たちが現代的なセキュリティのベストプラクティスと考える水準からは何年も遅れている
GCHQ は、コード品質がレビュー不可能なレベルであり、提供されたソースコードが実際の機器で動いているコードなのかさえ保証できないと見ていた
Huawei が自らアップデートできたためで、その機器は 2020年以降禁止されたと理解している: https://www.washingtonpost.com/world/national-security/brita...
AliExpress で1台買って調べてみたいのだが、このリンクは出発点としてよさそうだろうか？
https://vulners.com/search/types/huawei
2025年になっても移動通信標準で事前共有鍵を使っている理由が本当に理解できない
RSA と Diffie-Hellman[1] は何十年も前からあり、認証局の仕組みも古くからあるのに、SIM カードはいまだにカードと通信事業者だけが知る事前共有鍵で発行され、その後の認証と暗号化はすべてその鍵に基づいている
通信事業者がハッキングされて鍵が流出したら、できることはない
さらに悪いことに、その鍵は SIM カードメーカーが通信事業者へ送らなければならず、メーカーが別の国にあって外国政府の要求を受ける可能性もあるため、メーカーへのハッキングや転送中の窃取の機会はいくらでも生じる
これは NOBUS 脆弱性のように感じられ、SIM メーカーやコアネットワーク機器ベンダーが NSA と結託して鍵を渡せば、世界中の移動通信トラフィックを潜在的に盗聴できる
[1] これらのアルゴリズムが今ではベストプラクティスではなく、楕円曲線のほうが優れていることは分かっているが、現状よりは RSA でもましだ
[2] https://nickvsnetworking.com/hss-usim-authentication-in-lte-...
「Edward Snowden が提供した NSA の最高機密文書によれば、米英のスパイは世界最大の SIM カードメーカーの内部コンピュータネットワークに侵入し、世界中の携帯電話通信のプライバシー保護に使われる暗号鍵を盗んだ」
https://theintercept.com/2015/02/19/great-sim-heist/
今もそうなのかは分からないが、昔は携帯電話を安全な通信手段とは見なしにくかった
おそらく端末間で暗号化されたデータ通信を使って会話する必要があるだろう
対称鍵アルゴリズムには量子安全であるという利点もある
それでも 2025年なら、少なくとも ECC はサポートしてほしいし、今ではほとんどのスマートカードが標準で対応できるはずだ
SIM カードベンダーを信頼できないなら、実質的に答えはない
非対称方式でも攻撃経路が少し変わるだけで、カード上で動くソフトウェアを信頼できないなら、非決定的アルゴリズムの乱数選択を通じて平文を漏らしていないとどうやって分かるのか
対称システムに RSA を入れればより安全になるという考えは根拠が弱く、むしろ逆に近い
「NOBUS 脆弱性」という表現も特に妙で、こうしたシステムの信頼のルートは通信事業者だからだ
米国の通信事業者が米国の情報機関と「結託」しているのかを問う必要すらなく、すでにそうだと見るべきだ
詐欺師は通信事業者にとって大口顧客であり、捕まって遮断されるとまた戻ってきて新しい回線加入料を払い、同じことを繰り返す
詐欺師のおかげで付加機能のアップセルも可能になり、問題を解決しない側でさらに利益が出る
ブログ記事の結論にあるように、Freeswitch がコミュニティ向けリリースのスケジュールを変えないという点は、まったく驚くことではない
以前の Freeswitch には強いコミュニティ精神があったが、数年前により積極的に商業化されてから雰囲気が変わった
それ以降、本来公開されるべきものにアクセスするには「登録」手続きを経る必要があり、記憶では APT リポジトリのようなものが登録の壁の後ろに隠されたように思う
フリーソフトウェアコミュニティのコンテンツにアクセスするために、営利企業に登録したくはない
テクノロジー業界では、営利企業に情報を渡すと営業担当者がアップセルやクロスセルで煩わせ、望んでいないメーリングリストに入れられることを皆知っているからだ
VoIP コミュニティの他の部分でも、オープンソースへの寛大さを見直しているのを見てきたし、正直なところ責めるのは難しい
Matrix.org チームも FOSDEM’25 の発表の一つで同様に、商用ベンダーが開発にただ乗りしている問題について話していた
APT リポジトリまで無料で更新してくれるなら本当にありがたいが、それはあくまでその程度の「ありがたいこと」にすぎない
彼らのコードに依存しながらサポート費用を払いたくないなら、APT パッケージを自分でビルドすればよい
このように単一企業が保守しているプロジェクトに、どのようなコミュニティ精神を期待すべきなのかはよく分からない
外国の脅威アクター、Five Eyes のような西側同盟、そして数字を上げ続けなければならない圧力を考えると、オンラインに本当の匿名性はないと見るのが妥当だ
彼らがあなたを狙うなら、捕まえる手段も持っている
実際には、インターネット以前の時代と大きく変わらない
傍受されたくないなら、大規模なセキュリティ機関が電子的に容易にアクセスできない方法で暗号化する必要がある
物理的なメモ、口伝、身振りのような方法のことだ
また、国家主体が実際にデータを活用するリソースを割り当てたとき、オンラインで言ったことや行ったことの結果を引き受ける覚悟も必要だ
記事だけを見る限り、「今日の通信セキュリティはめちゃくちゃだ」という結論に完全には納得できない
Freeswitch を任意に選んでバッファオーバーフローを見つけた、という話に近いからだ
「通信スタック」が脆弱かもしれないし、そうでないかもしれないが、ここで示された根拠は非常に弱い
Salt Typhoon の攻撃は Cisco の脆弱性を悪用したとされているが、分析者は攻撃者が正規の資格情報を使った可能性も示している: https://cyberscoop.com/cisco-talos-salt-typhoon-initial-acce...
だから Freeswitch とは無関係だ
Oracle SBC は基本動作だけでもしばしば不安定で、Teams が今週出してくる TRouter 実装の混乱にも、きちんと切り分けられていないサービス拒否バグが間違いなくあるだろう
MF Tandem の混乱や、ほぼすべての通信事業者が生の暗号化されていない UDP SIP トラフィックをそのままインターネットに流していることについては、言うまでもない
この分野で安全なシステムを作ることは可能だが、現実には主要通信事業者の大半が、Nortel や Metaswitch のようなとうに消えた企業やプロジェクトの独占的で修正不能なプラットフォームと、ネットワークを構成する古くてパッチ未適用の機器よりさらに悪い技術的負債の山を運用している状態だ
「すべてがめちゃくちゃで、直す動機がない」という表現は要約にすぎない
正直なところ、それらの会話は専門用語を知らないとついていくのが非常に難しく、私自身もこの分野を十分に理解していないので、下手に説明しようとはしたくなくて、そう書いただけだ
自分のブログが Hacker News に載るとはまったく予想していなかった
何世代ものレガシーを抱えた複雑なネットワークプロトコルをパースするコードであり、しばしば秘密裏に書かれ、たいてい C/C++ だ
これが脆弱なはずがない。もちろん
SS7 のようなプロトコルは、ハッカーや悪意ある行為者という概念なしに設計された
その上にファイアウォールを載せることはできるが、望まれる機能と衝突するし、そうでなくても追加投資が必要になる
DIAMETER はましだが、それでも穴は多い
近年、通信セキュリティが優先事項になったことで改善は進んでいるが、数十年分のレガシーなハードウェア、ソフトウェア、ファームウェア、ネットワーク設計を包み込まなければならない
通信網で標準の Freeswitch をそのまま動かしているところはないと思うが、古い通信製品として、期待されるほどセキュリティが探られてこなかった Freeswitch に見られるタイプの問題は、あちこちに転がっている
筆者が余暇にコードを見てバグを見つけて報告したのは素晴らしいことで、まったく妨げたいとは思わない
しかし、あるソフトウェアの保守担当者の一人が、セキュリティ業界のベストプラクティスに合わせて著者にへりくだらなかったという事実だけで、「今日の通信セキュリティはめちゃくちゃだ」と言うには根拠が弱い
誰かがあなたのコードのバグを持ってきたが、実際に悪用されているとは主張せず、悪用可能性を確認する PoC も提供していないなら、単なる通常のバグとして扱ってはいけない理由があるだろうか？
今直して、次のリリースに入れればよい
変更点を人々が見られるって？ その通り、他の変更点もすべて見られる
exploit を見つけられるなら幸運を祈るだけで、報告者は見つけられなかった
Linux ディストリビューションでも同じことが起きる
セキュリティバグが報告され、時にはアップストリームの作者が頑固どころか、文字通り亡くなっていることもある
自分のスケジュールに合わせて変えたいなら、自分でリリースすればよい
Freeswitch がかなりよく使われていそうな領域は、学校や大学の BigBlueButton インストールだ
仮想教室システムで、サポート契約なしで使っている場合も多いだろうから、通信事業者よりもこちらの方が心配だ
XML RPCモジュールを実際に使っている人がどれくらいいるのか気になる
デフォルトではロードされない
修正: Shodan基準で468件
XML RPCモジュールで
senddirectorydocumentが実際に使われているのかも気になるcurl --show-error --get --request GET --user freeswitch:works "http://localhost:8080/${SIXTEEN_THOUSAND_RANDOM_CHARACTERS}";トリガーする方法について何かアイデアはある？
少なくともセグフォを起こすPoCでも出れば、セキュリティリリースが行われる可能性が高くなりそう
本当に面白いハッキングは CAMEL MAPインジェクション で起きている
SMS、USSD、そして至宝とも言える位置情報サービスまで、あらゆるおいしいものを制御する
カリブ海の裕福な島々やインドネシアのような場所にある多くの「大量SMS」業者は、スパム送信よりもはるかに多くのことをしている
だから古く、2Gは1990年代に設計された
人々が何を期待しているのかよく分からない
正直、動くだけでもありがたい
大手通信事業者がコアで FreeSwitchやAsterisk を動かしているわけではない
もちろんMotorolaはその製品を終了しつつあるが、現場には存在している
自分が面倒を見ているものは強固にファイアウォールで守られているが、全部がそうとは限らないと思う
基本的な通話ルーティングとPSTN接続以上のことをしようとするPBX保有企業の大半は、サードパーティ製ツールを使っているはず
そしてそうしたツールの相当数がFreeSWITCH、Asterisk、または類似のものの上に構築されている
モバイル通信セキュリティに関する P1 Securityの発表 を強くおすすめする: https://www.slideshare.net/slideshow/day1-hacking-telcoequip...
古い資料だが、改善されたと信じる理由はない
改善するインセンティブがまったくないからだ
そのうえソフトウェアのセキュリティ脆弱性は問題の一部にすぎず、もう一方では、通信事業者が制御権と中核アクセス権を最安値の入札者へ喜んで外部委託している点がある: https://berthub.eu/articles/posts/5g-elephant-in-the-room/