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, (^^ゞ

Cross Domain Referrer Leakageを訳してみた

Hello there, ('ω')ノ

 

クロスドメインリファラーリークを。

 

脆弱性:

 クロスドメインリファラーリーク

 

記事:

 https://mohsinalibukc.medium.com/cross-domain-referrer-leakage-7873ada102ad

 

ツール:

 Burp Suite

 

今回のターゲットサイトを「target」と呼ぶことに。

IDOR、CSRF、XSSなどを見つけるためにすべてのスキルを試したものの問題はなく。

次に、パスワードリセット領域に移動して。

ユーザの列挙と被害者のフラッディングは範囲外なので。

最後に、クロスドメインリファラーリークに。

 

クロスドメインリファラーリークとは、Webブラウザがリソースを要求すると。

通常は「Referer」ヘッダと呼ばれるHTTPヘッダが追加されて。

詳しくは、下記を。

 https://portswigger.net/kb/issues/00500400_cross-domain-referer-leakage

 

f:id:ThisIsOne:20210927183259p:plain

 

再現手順:

1.パスワードリセットエリアに移動して。

 パスワードを忘れた場合のリンクをメールアドレスに送信して。

2.Burp Suiteに設定されているパスワードリセットリンクをコピーして。

 ブラウザに貼り付けて。

3.次にインターセプトをオンにして、リクエストをキャプチャして。

4.最初にリファラーヘッダを確認して。

 次にそのヘッダのパスワードリセットリンクを確認して。

 リファラーヘッダにリンクが見つかった場合は、ホストを確認して。

5.トークンを含む完全なパスワードリセットリンクがって。

 ホストがサードパーティのWebサイトである場合は脆弱性で。

 

リクエストは、下記のようになって。

 

f:id:ThisIsOne:20210927183402p:plain

 

Best regards, (^^ゞ

Each and every request make sense…を訳してみた

Hello there, ('ω')ノ

 

すべてのリクエストは理にかなっているを。

 

脆弱性:

 権限昇格

 公開されたJWT生成エンドポイント

 

記事:

 https://akshartank.medium.com/each-and-every-request-make-sense-4572b3205382


今回は、同じ組織内および組織間ですべての管理者アカウントに。

アクセスする方法について説明することに。

これは、開発者のコ​​ミュニティで非常によく知られている会社で行われて。

誰でも他人に署名するためのドキュメントを送信できるデジタル署名Webサイトで。

アプリケーションは、適切な役割を区別して。

役割間のリーク(特権昇格)を行わないことで、アクセス制御を適切に管理して。

 

通常のユーザには従来のCookieを使用して。

X-admin-token」ヘッダで送信されたJWTを使用して管理者を識別して。

これは、正しく実装されている場合、ロールを管理するためのより良い方法で。

ただ、管理者が通常のユーザになることもできるという点が1つあって。

これがどのように起こっているのかという一連の疑問を引き起こしたので。

 

Burpを起動した後、管理者ユーザがCookieを使用しているにもかかわらず。

JWTを取得する方法に関するすべてのリクエストを読んだものの。

下記のようにユーザから管理者へのリクエストは。

組織に公開されているIDを提供するだけで、Cookieをチェックせずに。

管理者にJWTを提供していて。

f:id:ThisIsOne:20210927161901p:plain

 

したがって、どのユーザも自分のセッションでURLを実行するだけで。

JWTを取得できるので、ユーザはこのトークンを交換して。

X-admin-token」を取得できて。

 

f:id:ThisIsOne:20210927161928p:plain

 

管理APIにアクセスできるかどうかを確認するために。

このトークンを確認しましたものの、アクセス制御ポリシーが添付されているので。

トークンは、ほとんどのAPIで機能せず。

 

さら、このトークンを使用できるいくつかのAPIを検索し始めると。

会社のドキュメントから多くのAPIを見つけて。

そのうちの1つが組織の請求の詳細を漏らしていて。

影響:

    組織内の特権の昇格。

 アカウントIDを知る必要がある組織間での特権の昇格。

 これは、別会社の人間が署名するドキュメントを送信した際に知ることができて。

 

Best regards, (^^ゞ

Open Redirect vulnerability found using link parameterを訳してみた

Hello there, ('ω')ノ

 

リンクパラメータを使用して見つかったオープンリダイレクトの脆弱性を。

 

脆弱性:

 オープンリダイレクト

 

記事:

 https://muhammad-aamir.medium.com/open-redirect-vulnerability-found-using-link-parameter-5fc43e2ea8fd

 

今回は、Bugcrowdのプログラムにおけるオープンリダイレクトの脆弱性に関する。

最近の興味深い発見を紹介することに。


ターゲットのウェブサイトは、redact.comで。

ログインページには、下記が含まれていて。

https://redact.com/login?redirect=https://anysubdomain.redact.com

 

これは、ユーザがログインするとすぐに下記へ移動することを意味して。

 https://anysubdomain.redact.com

 

ここで、「anysubdomain」は、https://redact.comのサブドメインで。

アプリケーションは、リダイレクトURLの最後に。

「redact.com」があることを確認して、特定のWebサイトを読み込もうとして。

有効で機能しているサブドメインの場合だと。

それぞれのウェブサイトが読み込まれて。

 

一方、下記のような無効なサブドメインの場合だと。

そのウェブサイトを読み込もうとすると、エラーメッセージが表示されて。

 https://mysite.redact.com

 

f:id:ThisIsOne:20210927115247p:plain



オープンリダイレクトのために、いくつかのクールな回避策を試すのに。

下記のさまざまなサブドメインを探し始すことに。

 https://redact.com


しばらくして、下記ようなアドレスを指しているリンクを見つけて。

 https://link.redact.com

 

幸い、https://redact.comの環境ではリンクが無効だったので。

それに焦点を当てて調査を開始すると。

すぐに、「link」とも呼ばれるパラメータが添付されているのを見つけたので。

このパラメータは、自分の指定したhttps://mysite.comにリダイレクトして。

 https://link.redact.com?link=https://mysite.com


しかし、https://link.redact.comはスコープの範囲外なので。

https://redact.com/loginで使用することに。

したがって、オープンリダイレクトのペイロードを含むURLは下記のとおりで。

 https://redact.com/login?redirect=https://link.redact.com?link=https://mysite.com

 

すると、すでにログインしているユーザをhttps://mysite.comに誘導して。

まだログインしていないユーザに表示された場合は。

最初にユーザにアプリケーションのログイン画面が表示されて。

ログインしている場合は、https://mysite.comに移動して。


影響は明らかでログインしたユーザは、資格情報などの機密情報を盗むために。

フィッシングWebページに移動する可能性があって。

 

Best regards, (^^ゞ

How I Gain Access to the Server Administration of a Million-Dollar Companyを訳してみた

Hello there, ('ω')ノ

 

何百万ものサーバ管理にアクセスする方法を。

 

脆弱性:

 特権の昇格

 一括割り当て

 

記事:

 https://marxchryz.medium.com/how-i-gain-access-to-the-server-administration-of-a-million-dollar-company-14da68c7a9dd

 

ツール:

 BurpSuite

 

下記が、OWASPジュースショップで。

 

f:id:ThisIsOne:20210927075623p:plain

 

OWASP Juice Shopの「Improper Input Validation」に。

「管理者権限を持つユーザとして登録する」という説明のあるタスクがあって。

これがどのように機能するかは、登録時にあって。

タスクを完了するには、「role」という名前と「admin」の値を持つパラメータを。

推測して渡す必要があって。

このタスクを完了すると。

「これを実際のシナリオに実際に適用できるか」と思ったものの。

答えは、「No」で。

 

序章:

プログラムには、サインアップ/ログインが必要なサブドメインがあるので。

すぐにアカウントを作成して。

アカウント登録中は、すべてが正常で。

簡単にするためにデモンストレーションの目的で。

下記が、リクエストとすると。


POST /register HTTP/1.1
Host: www.redacted.com
Content-Type: application/json
{“email”: “user@tld.xyz”, “password”: “password123”}

 

上記のリクエストは、ホームページへの302リダイレクトを返して。

疑わしいことは何もないと思うので、サイトの探索を続けると。

サイトを探索する際に、「My Account」機能を確認して。

そこにCSRFとIDORの脆弱性があることを期待したものの、何もなくて。

userIDに結合されているCSRFトークンがあるため。

IDORとCSRFを悪用することはできず。


その後、Burp SuiteでHTTPログを確認すると。

自分のアカウントを更新するリクエストは、下記のとおりで。

 

POST /updateUserInfo HTTP/1.1
Host: www.redacted.com
CSRF-Token: XXXXXXXXXXXXXXXXXXXXXXX
Content-Type: application/json
{
“User”: {“id”: “123”, “email”: “user@tld.xyz”, “fullName”: “User A”},
“Address”: {“city”: “Some City”}
}

 

応答は非常に長いコンテンツを返して。

下記は、その一部で。

 

HTTP/1.1 200 OK

{
“response”: “success”,
“info”: {
“id”: “123”,
“email”: “user@tld.xyz”,
“fullName”: “User A”,

}
}

 

応答に表示されている中には、要求に応じていないフィールドがたくさんあって。

中でも目を引いたのは「companyUser」という値が「0」のフィールドがあることで。

その値を変更するのにどこに配置すればよいのやら。

そこで、上記のリクエストを変更して、下記のように変更してみると。

 

POST /updateUserInfo HTTP/1.1
Host: www.redacted.com
CSRF-Token: XXXXXXXXXXXXXXXXXXXXXXX
Content-Type: application/json
{
“User”: {“id”: “123”, “email”: “user@tld.xyz”, “fullName”: “User A”, “companyUser”: “1”},
“Address”: {“city”: “Some City”}
}

 

何も起こることはなく。

companyUser」は「User」フィールド内にあるべきではないと思ったので。

どうあるべきかを推測した後、下記のように変更することに。

 {“companyUser”: { “companyUser”: “1” }} 


それでも、何も起こらず。
そこで、私は彼らの命名規則(最初の文字は大文字)に従おうとおもって。

下記のように変更することに。
 {“CompanyUser”: { “companyUser”: “1” }}


すると、リクエストが「1」の値で「companyUser」を返したで。

ログアウトしてログインして、確認しましたものの機能せずに。

2FAピンコードでプロンプトが表示されて。

この2FAの長さと組み合わせがわからないので、ブルートフォース攻撃はできず。

他のアカウントで上記の手順を繰り返した後、応答をもう一度確認すると。

2FAに関連するものに気づいて。

それは「companyUser2FA」フィールドで。

このフィールドをリクエストに追加した最終的なリクエストは下記のとおりで。

 {“CompanyUser”: { “companyUser”: “1”, “companyUser2FA”: “1234” }}

 

2FAフィールドが応答に表示されるので、それが機能したことを意味して。

なので、ログアウトして再びログインしたところ。

IPがホワイトリストに登録されていないことを確認するメッセージが表示されて。

 

なので、3番目のアカウントで上記の手順を繰り返して、応答も確認しすると。

IPに関連するものがあって、それは「companyUserIP」というフィールドで。

IP制限をバイパスすることを期待して、このパラメータをリクエストに追加して。

最終的なリクエストは下記のとおりで。

 {“CompanyUser”: { “companyUser”: “1”, “companyUser2FA”: “1234” , “companyUserIP”: “<My Public IP>” }}

 

引き続き、ログアウトして再度ログインすると。

管理者のみがアクセスできるWebサイト内のルートにリダイレクトされて。

管理者だけが見ることができるすべてを見れて。

さらには、管理者アクセス権を取得するのはそのサブドメインだけではなくて。

他のサブドメインのすべての管理パネルも含まれて。

その中で、サブドメインの列挙に表示されなかったサブドメインもたくさんあって。

 

Best regards, (^^ゞ

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

f:id:ThisIsOne:20200404115457p:plain