shikata ga nai

Private? There is no such things.

Sensitive data leak using IDOR in integration serviceを訳してみた

Hello there, ('ω')ノ

 

統合サービスでIDORを使用した機密データの漏洩を。

 

脆弱性:

 IDOR

 

記事:

 https://ronak-9889.medium.com/sensitive-data-leak-using-idor-in-integration-service-d9301be9c91e

 

ツール:

 Burp Suite

 Google Dorks


このブログ投稿全体を通して、Redacted.comとすることに。

理解を深めるために、調査やクイズなどのフォームを生成して。

それらのフォームから回答を収集して。

他のサービスと統合するためのアプリであることをお伝えしておいて。

 

ほとんどの場合、ハンティング中にビジネスロジック、IDOR、および。

サーバ側のバグを探して。

事前に定義された方法や固定された方法には従わず、基本的な調整を行って。

通常のアプリケーションの流れを理解してから、ハンティングに進むことに。

 

このバグは統合機能にあって。

最初にこの機能の基本的なフローについて説明して。

次にこのバグをどのように見つけたかを段階的に説明するこに。

まずは、フォームの応答をGoogle analytics、Facebook Pixelsなどの。

さまざまなプラットフォームに接続するセクションがあって。

所有者は、この機能を使用して自分のフォームをこのアプリの1つに統合して。

統合されたアプリでフォームの応答を受け取ることができて。

 

統合に利用できるすべてのプラットフォームを調べているときに。

Zendesk Sellと統合するオプションに出くわすことに。

Zendesk Sellは、連絡先などの販売データを分析するためのアプリケーションで。

したがって、この機能のフローは統合プロセスが開始されると。

フォームIDを受け取って、リクエストフローを。

サードパーティのアプリケーションに転送して。

サードパーティアプリケーションでは。

Zendesk Sellアカウントの設定、承認の付与、フォームの質問のマップを。

Zendesk Sellのフィールドに要求して。

これが正常に行われると。

フォームの応答は、Zendesk Sellのフィールドにマッピングされて。

 https://www.zendesk.com/

 

f:id:ThisIsOne:20210928110437p:plain

 

リクエストフローを確認したところ。

統合を開始するための最初のGETリクエストが生成されて。

次にサードパーティに認証とマッピングを構成するリクエストが生成されて。

最後に統合を有効にするための。

PATCH要求が生成されていることがわかって。

 

GET要求とPATCH要求はどちらも、form_idパラメータのIDORに対して脆弱だったので。

アプリケーションをテストするために2つのアカウントを作成して。

1つは攻撃者として、もう1つは被害者として作成しまして。

下記のように、統合を開始してGETリクエストを傍受して。

form_idを被害者のform_idに置き換えることに。

 form_id=o310DG

 

f:id:ThisIsOne:20210928092932p:plain

 

form_idを被害者のform_idに置き換えた後に傍受をオフにして。

認証とマッピングのページに移動して。

Zendesk Sellアカウントを攻撃者として構成して、権限を付与して。

 

f:id:ThisIsOne:20210928093016p:plain

 

下記は、被害者フォームの質問を。

攻撃者のZendesk Sellアカウントフィールドにマッピングされたところで。

 

f:id:ThisIsOne:20210928093035p:plain

 

この構成を完了した後に、統合を有効にするための。

PATCH要求である次の要求をインターセプトして。

form_idを被害者のform_idに置き換えて。

攻撃者のアカウントでこの統合プロセスを完了した後に。

動作するかどうかを確認するために、被害者のアカウントにログインしたところ。

統合が有効になっていることがわかって。

 form_id=o310DG

 

f:id:ThisIsOne:20210928093101p:plain

 

さらにテストするために、私は訪問者としてフォームに記入して。

被害者のアカウントと攻撃者のZendesk Sellアカウントで。

受け取った応答を確認すると。

下記のように、攻撃者はZendesk Sellアカウントでフォーム応答を受け取って。

連絡先は、攻撃者のZendesk Sellアカウントに対する被害者フォームの。

受信応答で作成されていて。

 

f:id:ThisIsOne:20210928093136p:plain

 

問題は、form_idを列挙してフォームをZendeskアカウントと統合する方法で。

このフォームを共有するためのリンクには、Zendeskアカウントと統合して。

これらのフォームに入力されたすべての機密データを。

受信するために使用できるform_id値が含まれていたため。

列挙は非常に単純なタスクで。

下記のように、シンプルなgoogle dorkでform_idを公開して。

 

f:id:ThisIsOne:20210928093156p:plain

 

要約すると、この統合プロセスでIDORを使用すると。

攻撃者は、ユーザの操作なしでZendesk Sellアカウントを。

任意のフォームと統合して、フォーム応答として。

受信したすべての機密データをフェッチできて。

 

Best regards, (^^ゞ

ひとりひとりの自覚をもった行動で、医療従事者と保健所職員を助けよう。

f:id:ThisIsOne:20200404115457p:plain