shikata ga nai

Private? There is no such things.

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

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

f:id:ThisIsOne:20200404115457p:plain