hasan-khalil/cve-2020-6514CVE-2020-6514のエクスプロイトで、AndroidアプリケーションにおけるWebRTC SCTPメモリ破損を標的とします。Fridaを使用してネイティブ関数をフックし、SCTPパケットを改変してリモートコード実行を実現します。
このエクスプロイト エクスプロイトを作成する際、当初はWebRTCのソースを変更して再コンパイルし、ターゲットデバイスに送信するSCTPパケットを改変していました。しかし、これはクローズドソースのアプリケーションに対して攻撃するには現実的ではなかったため、最終的にはFridaを使って攻撃側デバイスのバイナリをフックする方法に切り替えました。Fridaのフック機能により、特定のネイティブ関数が呼び出される前後にコードを実行できるため、私のエクスプロイトは送信されるSCTPパケットの改変と、受信するパケットの検査の両方を可能にしました。機能的には攻撃側クライアントのソースを変更するのと同等ですが、コンパイル時にソース内で変更を行うのではなく、実行時にFridaによって動的に変更を行う点が異なります。エクスプロイトのソースはこちらで入手できます。
攻撃側デバイスがフックする必要がある関数は、以下の7つです。
usrsctp_conninput // 受信したSCTPを受け取る DtlsTransport::SendPacket // 送信するSCTPを送信する cricket::SctpTransport::SctpTransport // SCTPトランスポートの準備ができたことを検出する calculate_crc32c // SCTPパケットのチェックサムを計算する sctp_hmac // HMACを実行して秘密鍵を推測する sctp_hmac_m // SCTPパケットに署名する SrtpTransport::ProtectRtp // ヒープノイズを減らすためにRTPを抑制する
これらの関数はシンボルとして、またはバイナリ内のオフセットとしてフックできます。
また、エクスプロイトを動作させるために必要な、ターゲットデバイスのバイナリからのアドレスオフセットが3つあります。system関数とmalloc関数の間のオフセット、および前回の投稿で説明したgadgetとmalloc関数の間のオフセットは、そのうちの2つです。これらのオフセットはAndroidシステムライブラリであるlibc内にあるため、ターゲットデバイスのAndroidのバージョンに基づいて決定する必要があります。cricket::SctpTransport vtableの位置からグローバルオフセットテーブル内のmallocの位置までのオフセットも必要です。これは、攻撃対象のアプリケーション内のWebRTCを含むバイナリから決定する必要があります。
提供されているエクスプロイトスクリプトには深刻な制限があることに注意してください。メモリを読み取るたびに、ポインタのビット31が設定されている場合にのみ機能します。この理由についてはパート2で説明します。エクスプロイトスクリプトには、FWD_TSNチャンクを使用して任意のポインタを読み取るための修正方法の例がありますが、これはすべての読み取りに実装されているわけではありません。テスト目的で、WebRTCライブラリが都合の良い場所にマッピングされるまでデバイスをリセットしました。
Androidアプリケーション WebRTCを統合している人気のあるAndroidアプリケーションのリストは、Google PlayのAPKファイルをusrsctp内の特定の文字列で検索することによって決定しました。500万人以上のユーザーを持つ約200のアプリケーションがWebRTCを使用しているようです。私はこれらのアプリケーションを評価し、エクスプロイトの脆弱性の影響を受ける可能性があるかどうか、またその影響がどのようなものかを判断しました。
アプリケーションによるWebRTCの使用方法は非常に多様であることがわかりましたが、大きく4つのカテゴリに分類できます。
エクスプロイトで使用される脆弱性の影響は、これらのカテゴリごとに異なります。プロジェクションは、WebRTC接続を確立するために多くのユーザー操作が必要であり、そもそもユーザーは接続の両側にアクセスできるため、相手側を危険にさらしても得るものはほとんどありません。したがって、リスクは低いです。
ストリーミングもリスクはかなり低いです。視聴者数が少ないストリームの場合にピアツーピア接続を使用するアプリケーションもあるかもしれませんが、通常は送信ピアからのWebRTC接続を終端し、受信ピアとの新しい接続を開始する仲介サーバーを使用します。これは、攻撃者が通常、ピアに直接不正なパケットを送信できないことを意味します。ピアツーピアでストリーミングが行われる設定であっても、ターゲットがストリームを視聴するにはユーザー操作が必要であり、ストリームにアクセスできる人を制限する方法がないことがよくあります。このため、WebRTCを使用するストリーミングアプリケーションは、標的型攻撃にはおそらく役に立ちません。もちろん、これらの脆弱性がストリーミングサービスで使用されるサーバーに影響を与える可能性はありますが、この研究では調査されていません。
ブラウザは、WebRTCの設定方法を大幅に制御できるため、WebRTCのほとんどのバグに対してほぼ確実に脆弱です。ブラウザでこのようなバグを悪用するには、攻撃者はピアツーピア接続で他方のピアのように動作するホストをセットアップし、ターゲットにそのホストへの通話を開始するWebページへのアクセスを促す必要があります。この場合、脆弱性の影響はJavaScriptの他のメモリ破壊の脆弱性と同様になります。
会議はWebRTCの使用において最もリスクが高いものですが、脆弱性の実際の影響は、アプリケーションのユーザーが互いに連絡を取り合う方法に大きく依存します。最もリスクの高い設計は、識別子に基づいて任意のユーザーが他の任意のユーザーに連絡できるアプリケーションです。一部のアプリケーションでは、通話を行う前に、着信側が発信側と特定の方法でやり取りしている必要があり、そのためユーザーがターゲットに連絡することが難しくなり、一般的にリスクが低減されます。一部のアプリケーションでは、通話を開始するためにユーザーがコードを入力するかリンクにアクセスする必要があり、これも同様の効果があります。また、特定のユーザーに通話することが困難または不可能なアプリケーションの大きなグループもあります。たとえば、チャットルーレットアプリケーションや、ユーザーがカスタマーサポートへの通話を開始できる機能を持つアプリケーションなどです。
この研究では、特定の他のユーザーに連絡できる会議アプリケーションに焦点を当てました。これにより、200のアプリケーションのリストは以下の14のアプリケーションに絞り込まれました。
