CVE-2024-37010

CVE-2024-37010 のエクスプロイト:他のユーザーの外部ストレージへのアクセス & 横展開:

https://www.cert.ssi.gouv.fr/avis/CERTFR-2024-AVI-0753/

https://owncloud.com/security-advisories/insecure-direct-object-reference-in-external-storage

はじめに

Owncloud は、Google Drive のように、サーバーをファイル保存用のクラウドに変えます。これにより、企業は例えば、第三者によって管理されることなく、従業員向けのクラウドを提供できます。

管理者がこのように設定している場合、ユーザーは他のクラウドや FTP、Google Drive などの外部ストレージを接続し、ファイルを単一のクラウドに集約して、ユーザーの利便性を高めることができます。

外部ストレージを作成したら、このフォームを更新して、例えば「フォルダ名」フィールドを変更できます。フォームが更新されると、フォーム全体が JSON 形式でリクエストとして送信されます。このフォーム内の「ID」フィールドは整数で、ストレージ作成時にサーバーによって生成された、私たちの外部ストレージの識別子です。

2. Idor Idor

Owncloud 上の別のユーザー、例えば管理者も、ID「18」の外部ストレージを持っていると仮定しましょう。

ここで、「normal_user」ユーザー（特別な権限を持たないユーザー）としてフォーム更新リクエストを再実行しますが、ID を管理者の外部ストレージである 18 に変更します。

1. 管理者のストレージ ID を入力する
2. 任意のストレージ名「storage_pwned」を設定する。
3. 念のため、任意のホスト（この場合は Burp Collaborator）も指定します。重要な注意:ホストの変更は必須ではありません。ホストを変更すると、ストレージ設定が壊れ、Owncloud サーバーは元のストレージからファイルを取得できなくなります。

リクエストを送信すると、サーバーは 404 エラー (4) を返し、指定した ID のストレージが見つからなかったことを通知します (5)。

しかし、管理者アカウントにログインすると、次のように表示されます:

管理者のストレージが更新されています。

1. ストレージ名が「storage_pwned」に変更されました。
2. ホストが Collaborator のアドレスに置き換えられました。
3. そして最も重要な点:ストレージへのアクセスを許可されたユーザーに、「normal_user」ユーザーが追加されました。

「normal_user」として再度ログインすると、管理者のストレージである「storage_pwned」にアクセスできるようになっていることがわかります。

ユーザー A は、ユーザー B のストレージを更新し、そのアクセス権を再取得することに成功しました。ユーザー A は、ユーザー B の設定を壊さず、その後ユーザー B のファイルにアクセスできるようにするために、更新リクエスト中にホストを変更してはならないことに注意してください。

以下は、外部ストレージの更新に使用されるコードです。

まず、リクエストを行ったばかりのユーザーの権限が検証されていないことがわかります。コードは、ストレージがリクエストを行ったユーザーのものであるかをチェックしていません。これが、「normal_user」が管理者のストレージを更新できた理由を説明しています。

次に、更新のたびに、コードがリクエストを行ったばかりのユーザーを、ストレージへの接続を許可されたユーザーに追加していることがわかります。これが、更新後に「normal_user」が魔法のように管理者のストレージへのアクセス権を付与された理由を説明しています。

まとめ

この例では、あるユーザーが別のユーザーの外部ストレージへの完全なアクセス権を取得し、その個人ファイルにアクセスできるようになる可能性があることを見てきました。これだけでも、かなり重大な脆弱性です。

3. さらに先へ...

この時点で、ご覧のとおり、この IDOR（Insecure Direct Object Reference、安全でない直接オブジェクト参照）はすでに重大な脆弱性です。しかし、その影響をさらに拡大するために、悪用を続けてみましょう。

そのために、Owncloud サーバーがファイルを取得する際に外部ストレージに対して実行する認証プロセスを理解しましょう。単純なログイン/パスワードの組み合わせを使用する基本的な認証システムでは、クラウドサーバーは単に

ここで、攻撃者がホストを自分が制御するアドレスに変更してこの設定を更新できると仮定しましょう。つまり、Owncloud サーバーは今後、攻撃者が制御するこの新しいアドレスに認証情報を送信することになります。

これはまさに、この脆弱性を利用して私たちができることです。

別のユーザーのストレージ ID を指定して更新リクエストをリプレイする際は、例えば Burp Collaborator を指定してホストを変更するだけで済みます。

これにより、ユーザーが再接続すると、Owncloud サーバーはユーザーの認証情報を送信して、私たちの Collaborator への認証を試みます。

すると、Collaborator は、Base64 エンコードされた認証情報を含む、Owncloud サーバーからの認証リクエストを受信します。

これで、管理者の外部ストレージの平文認証情報を入手できました。

ちょっとしたおまけ...

外部ストレージの認証には、例えば同じパスワードを使用している場合、自分の Owncloud 認証情報を使ってログインできます。外部ストレージの更新をリクエストする際、「authMechanism」フィールドに「password::sessioncredentials」を指定できます。

Owncloud サーバーは、次回接続時に私たちの認証情報を平文で保存し、認証のために外部ストレージデバイスへ転送します。

お気付きかと思います...

つまり、攻撃者は他のユーザーの外部ストレージに対してもこのメカニズムを有効化し、今私たちが行ったように、被害者の Owncloud セッションの平文認証情報を、自分が制御するホストへ転送させることができます。

4. リスクの概要

したがって、CVE-2024-37010 により、Owncloud サーバーにアカウントを持つ攻撃者は以下のことが可能になります:

• 他のユーザーの外部ストレージ内のファイルへの読み取り/書き込みアクセスを取得する。
• 接続されている外部ストレージデバイスの平文認証情報を取得する。
  • 外部ストレージへ横展開する。
• 外部ストレージを持つユーザーの、暗号化されていない Owncloud アカウント認証情報を取得する。
  • アカウント乗っ取り & privesc。

時系列

• 2024/03/11 - 脆弱性を発見
• 2024/03/12 - Owncloud にレポートを送信
• 2024/09/09 - Owncloud による公開発表 & CVE