エジプトで商用監視業者が悪用した0-day脆弱性
(blog.google)- Google TAGとThe Citizen Labは、iPhoneを標的にした0-dayエクスプロイトチェーンを実際の攻撃で発見し、Intellexaがこれを使ってPredatorスパイウェアを密かにインストールしていた
- AppleはiOS 16.7とiOS 17.0.1でCVE-2023-41991・41992・41993を修正し、GoogleはiOSユーザーに直ちにアップデートするよう推奨している
- 攻撃は、標的がHTTPサイトに接続した際にMITM注入でトラフィックを傍受し、c.betly[.]meとsec-flare[.]comへリダイレクトする方式で、別途クリックや通話への応答は不要だった
- iOSチェーンはSafariのリモートコード実行、証明書検証の問題、XNU Kernelのローカル権限昇格へとつながり、その後小さなバイナリがPredatorフルインプラントをインストールするかどうかを判断した
- Androidを標的にした攻撃もエジプトで観測され、ChromeのCVE-2023-4762を利用する初期レンダラーのリモートコード実行脆弱性は9月5日に修正された
IntellexaのPredatorインストール用エクスプロイトチェーン
- Google Threat Analysis Group(TAG)は、The Citizen Labとともに、実際の攻撃で使われていたiPhone向け0-dayエクスプロイトチェーンを発見した
- 商用監視業者Intellexaが開発したこのチェーンは、端末にPredatorスパイウェアをひそかにインストールするために使われた
- AppleはiOS 16.7とiOS 17.0.1で次の脆弱性を修正した
- CVE-2023-41991
- CVE-2023-41992
- CVE-2023-41993
- 迅速な修正によってユーザー保護は強化されており、すべてのiOSユーザーはできるだけ早くインストールすることが推奨される
MITMによる配信方式
- Intellexaのエクスプロイトチェーンは**man-in-the-middle(MITM)**攻撃で配信された
- MITM攻撃では、攻撃者が標的と標的が接続しようとしているWebサイトの間に割り込み、トラフィックを傍受する
- 標的が
httpサイトに接続すると、攻撃者は偽のデータを返して別のWebサイトへ移動させることができる httpsサイトではトラフィックが暗号化され、受信したデータが意図したWebサイトから来たものかを証明書で検証できる- 今回のキャンペーンでは、標的がどの
httpサイトに接続しても、トラフィック注入によってc.betly[.]meのIntellexaサイトへ静かにリダイレクトされた- ユーザーが想定された標的であれば、さらにsec-flare[.]comのエクスプロイトサーバーへ移動した
- 文書を開く、特定のリンクをクリックする、通話に応答するといったユーザー操作は不要だった
iOSエクスプロイトチェーンの構成
- 標的がエクスプロイトサーバーへリダイレクトされると、iOSエクスプロイトチェーンが実行される
- チェーンは3つの脆弱性で構成される
- CVE-2023-41993: Safariの初期リモートコード実行(RCE)
- CVE-2023-41991: 証明書検証の問題
- CVE-2023-41992: XNU Kernelのローカル権限昇格(LPE)
- その後、小さなバイナリが実行され、Predatorフルインプラントをインストールするかどうかを判断する
- TAGはPredatorフルインプラント全体は確保できなかった
- GoogleはGoogle vulnerability disclosure policyに従い、このエクスプロイトの技術的な詳細分析を公開する予定だ
Androidを標的にした攻撃とChrome脆弱性
- 攻撃者は、エジプトのAndroid端末にPredatorをインストールするためのエクスプロイトチェーンも保有していた
- TAGはAndroidエクスプロイトが配信された2つの方式を観測した
- MITM注入
- 標的に直接送られた使い捨てリンク
- TAGが確保したのはChromeの初期レンダラーのリモートコード実行脆弱性のみで、この脆弱性はCVE-2023-4762を悪用していた
- このバグは別のセキュリティ研究者がすでにChrome Vulnerability Rewards Programへ報告しており、9月5日に修正された
- Googleは、Intellexaがこの脆弱性を以前0-dayとして使用していたと評価している
ChromeのMITM防御とGoogleの対応
- Chromeは長年にわたり、Web全体でのHTTPS普及を推進してきた
- Chromeの「HTTPS-First Mode」は、MITMネットワーク注入によるエクスプロイト配信の可能性を減らせる
- すべてのページをまずHTTPSで読み込もうと試みる
- HTTPリクエストへ戻る前に大きな警告を表示する
- この設定はAdvanced Protection Programに登録し、Chromeにログインしているユーザーにはデフォルトで有効化されている
- Googleはすべてのユーザーに対し、MITM攻撃への防御のため「HTTPS-First Mode」の有効化を推奨している
- 今回のキャンペーンは、商用監視業者の拡散がオンラインユーザーの安全に深刻なリスクをもたらし得ることを示している
- TAGは商用スパイウェア業界に対する対策と研究公開を継続し、官民両部門と協力して関連対応を続ける予定だ
1件のコメント
Hacker News のコメント
追加情報が出たのはよいが、Chrome のパッチだけに触れている点が少し不安。Android でのサンドボックス脱出が何だったのか気になる。
Android の Chrome プロセス内でコード実行が可能になったとしても、永続化まで可能であってはならないので、明らかに別の脆弱性がさらにある。
今回の攻撃ベクトルは標的型キャンペーンにおける HTTP の中間者攻撃と使い捨てリンクだったが、誰かがこれを広告キャンペーンや SMS/Discord/Matrix のようなスパムに仕込んで大量散布し、ボットネットを作ったりユーザーの認証情報を盗んだりするのを妨げる理由もなさそう。
つまりサンドボックス脱出と権限昇格のバグが欠けているということ。
また、ここでは合法的傍受機能を使った ISP レベルの中間者攻撃で配信されたようだが、フィッシングリンク経由のワンクリック方式でこのエクスプロイトを配信できない理由はない。
Android 版もかなり似ていたが、Linux カーネルの緩和策を回避するには、さらに 2 つのエクスプロイトが必要だったようだ。
PZ に良い技術分析記事がある。
HTTPS がないよりはましで、この攻撃は初期ペイロードの注入に HTTP を使っているが、一部の国の国家支援攻撃者はCA や CDN インフラを単に迂回・掌握することもできそう。
必要なのは、クライアントを c.betly[.]me に送る HTTP 302/307 リダイレクト応答だけのようだ。HTML リダイレクトのペイロード、あるいは DNS でも可能かもしれない。
Predator スパイウェアを扱った Darknet Diaries の最近の関連エピソードがある: https://darknetdiaries.com/episode/137/
こうした 0-day が教えてくれるのは、強力な敵対者の標的になった人は極度に疑り深く振る舞い、攻撃対象領域を最大限減らすべきだということ。
James Bond が M と安全に通信するには、その機能だけを行うカスタムのハードウェア型モバイル端末を使うほうがよい。匿名の第三者のプリペイド端末で、ランダムな掲示板に、事前に合意したローテーション式の地理ロック付きコードブック順序で暗号化メッセージを残すべきだ。それより少しでも運用上のセキュリティが弱ければ終わり。
普通の人が接続されたデジタル機器を普通に使うなら、その機器に入れたものはすでに盗まれたと考えるべきだ。本当に私的に保ちたいならデジタルには載せず、紙や昔ながらのアナログテープのような場所に置くべきだ。そうすれば少なくとも物理的に盗む必要があり、状況によってははるかに難しいこともあるが、必ずしもより安全という意味ではない。結局どちらにしても失うことになる。
唯一の現実的な逃げ道は、透明性と抑制・均衡が強く機能する民主政府、強力に執行されるプライバシー保護法、そして Citizen Lab のような活動への強い支援を備えること。
この脆弱性は、現大統領 Abdel Fatah El Sisi と大統領選で争うAhmed El Tantawy候補の携帯電話をハッキングするために、エジプト当局が使った可能性が高い。
https://x.com/jsrailton/status/1705271600868692416?s=46&t=Kq...
記事には出てこないが、iOS のLockdown Modeはこのエクスプロイトチェーンを防いだ。
理解できない点がある。スパイウェア企業も 0-day 販売企業も、0-day を見つける専任人材を抱えている。なぜ Google と Apple は単にこの人材をスカウトしないのだろう？
Google と Apple なら非常に競争力のある給与を提示できるはずなのに、なぜそうしないのか気になる。熟練した 0-day ハンターを事実上全員引き抜くコストが、単にパッチを出すコストより大きいと判断しているのだろうか？
従業員の立場では、賃金は似たようなもの。Big Tech の仕事はあまり面白くない。大量のバグを見つける大規模なバグ検出マシンを作り、見つけたバグをバグトラッカーに上げておけば、3か月後にようやく直るかもしれない。攻撃的セキュリティ側の仕事のほうが面白い。浅い脆弱性は Big Tech が見つけるので、必要なのは少数だけで、研究対象システムを深く理解している必要がある。脆弱性からコード実行までつなげる知識も必要。エクスプロイトを書くのは簡単なことではない。私が非倫理的だと見る会社でなぜエンジニアが働くのかを説明するのは難しいが、おそらく彼らは私と同じ感じ方をしていないのだろう。
雇用主の立場では、「年間 X 個の脆弱性を見つける割合にいくら払うか」の問題。コードにバグがあっても市場で最も安全なコードだと見なされるなら、セキュリティ予算を増やすことが会社の利益にならない場合がある。セキュリティ予算を増やすなら、どの部門の予算を削るのか、会社の健全性への純効果は何かを考えなければならない。
脆弱性を直したいなら、脆弱性を見つけてエクスプロイトする価格を、買い手が負担できないほど高くしなければならない。そして攻撃的セキュリティの進歩が発見・エクスプロイトのコストを下げる分だけ、その価格をさらに高く保ち続ける必要がある。防御企業は主にバグ予防で稼いでいるわけではなく、攻撃企業は主にバグを見つけて稼いでいるため、ミスマッチが生じる。企業であれどんな組織であれ、究極の脆弱性は有限なリソースだ。
世界中の独立研究者との協業も素晴らしい。それでも、毎日書かれるソフトウェアの量を考えれば、一部の問題を見逃すことはまだあり得る。
今日彼らをスカウトしても、明日にはそういう会社で働く新しい人たちが大量に出てくるので、終わりのない循環になる。
不可能な理由は多いが、結局は世界と人類が大きく複雑すぎて、一つの主体がすべて、いや大部分すら持つことはできないという話に行き着く。あらゆるものに非常に多様な異質性が組み込まれている。お金を超える世界観や忠誠心も多い。
Firefox にも Https First があるが、
dom.security.https_first設定を有効にする必要があるようだ。可能なら「HTTPS-Only Mode」が確実に最善。
プロンプトが極端に怪しく見えない限り、たとえば HTTPS をサポートしていると分かっている Google.com のようなサイトで出る場合でない限り、これは何も解決しない。
この記事からリンクされている Citizen Lab の投稿に中間者攻撃の詳細がある。ほとんど攻撃と呼ぶのも微妙なくらいで、ネットワークが必要に応じてコンテンツ注入を行うよう設計されている。