Shikata Ga Nai

Private? There is no such things.

How i was able to get Appreciation from the organization of a website just by changing a sign..!!!を訳してみた

Hello there, ('ω')ノ

 

看板を変えるだけで、どうやってウェブサイトの構成から感謝を得られるかを。

 

脆弱性:

 情報開示

 ソースコード開示

 

記事:

 https://fardeen-ahmed.medium.com/how-i-was-able-to-get-appreciation-from-the-organization-of-a-website-just-by-changing-a-sign-661042c97a98

 

脆弱なWebサイトは、例として次のとおりで。

 https://example.com/index.html/

 

Webサイトにアクセスし、Burp Suiteで傍受して「スパイダリング」機能を。

使用すると。

下記のようにウェブページが読み込まれているのを発見して。

この文字(/記号)は、区切り文字として知られていて。

 https://example.com/hello.txt~/

 

そこで、「拡張子を記号に置き換える」ことに。

hello.txt~」を「hello~.txt」に置き換えたものの何も起こらず。

さらに、「hello.txt」を「hello~」に変更しても何も起こらず。

 

次に、Webサイトを閉じる前に、「Wappalyzer」を使用して。

Webサイトで使用されているテクノロジーを確認することに。

 https://www.wappalyzer.com/

 

f:id:ThisIsOne:20210922111949p:plain

 

調べてみると、「https://example.com/index.html」が。

ページソースコードの「https://example.com/index.html~/」として。

読み込まれていることがわったので、これはソースコードの開示で。

index.htmlを削除して「index~」だけで、Enterキーを押して。

Webサイトのソースコード開示を入手して。

SQLクエリが後ろで機能していることを知ることができたので。

それは完全な「機密情報開示」で。

 

ヒント:

特別な記号(~, !, @, #, $, %など)は。

ページのソースコードで受け入れられる場合にのみ使用して。

受け入れられない場合は、時間の無駄になるので。

 

Best regards, (^^ゞ

Pre-Denial Of Service (set-up 2FA on unverified account)を訳してみた

サービス拒否前(未確認のアカウントに2FAを設定)を。

 

脆弱性:

 アプリケーションレベルのDoS

 

記事:

 https://medium.com/@kalvik/pre-denial-of-service-set-up-2fa-on-unverified-account-8399af52ea2d

 

今回は、未確認のアカウントで2FAを設定して。

その電子メールの実際のユーザのサービス拒否を。

引き起こす方法について説明することに。

被害者が、まだ自分のアカウントを登録していないと仮定して。

 

セットアップフローは、次のとおりで。

 ・アカウントのサインアップ

 ・電子メールの確認

 ・2FAのセットアップ

 

電子メールを確認しないと、セキュリティ標準に従って2FAを設定できず。

ただ、この制限をうまく回避して、電子メールを確認せずに。

2FAをセットアップすることができて。

 

Webサイトは、websocketを使用していて。

確認済みのアカウントで2FAを設定すると。

最初のWebSocketリクエストは、下記のとおりで。

 [“{\”msg\”:\”method\”,\”method\”:\”2fa/generateMFA\”,\”params\”:,\”id\”:\”XXXX\”}”]

 

それで、下記のリクエストだと認証システムアプリで。

2FAを設定するために使用される秘密鍵が返されたので。

 [“{\”msg\”:\”method\”,\”method\”:\”2fa/getSecretKey\”,\”params\”: ,\”id\”:\”XXXX\”}”]

 

未確認のアカウントから上記のリクエストを送信してみようと思って。

被害者のアカウントにログインして、下記のリクエストを送信すると。

残念ながら、「アカウントが確認されていません」という返信があって。

 [“{\”msg\”:\”method\”,\”method\”:\”mfa/getSecretKey\”,\”params\”:,\”id\”:\”24\”}”]

 

その後、いくつかのヒットと試行の後に。

下記が、2FAを設定する最初のリクエストだと気づいたので。

被害者のアカウントから下記のリクエストを再度送信すると空白の応答を受け取って。

 [“{\”msg\”:\”method\”,\”method\”:\”mfa/generateMFA\”,\”params\”:,\”id\”:\”XXXX\”}”]

 

再度、下記のリクエストを送ってみると秘密鍵を取得することに成功できて。

秘密鍵は、10〜12文字の長さで。

 [“{\”msg\”:\”method\”,\”method\”:\”mfa/generateMFA\”,\”params\”:[],\”id\”:\”24\”}”]

 

Google Authenticatorを開いて、その秘密のコードを使用して。

2FAをセットアップすると成功して。

 

このようにして、未確認のアカウントで2FAを設定して。

その電子メールの実際のユーザが将来、Webサイトにアクセスするのを。

ブロックすることができて。

 

Best regards, (^^ゞ

Trick to bypass rate limit of password reset functionalityを訳してみた

Hello there, ('ω')ノ

 

パスワードリセット機能のレート制限を回避するためのトリックを。

 

脆弱性:

 レート制限バイパス

 

記事:

 https://4bdoz.medium.com/trick-to-bypass-rate-limit-of-password-reset-functionality-a9923d3d7c4b

 

今回は、ターゲットをexample.comと呼つことに。

 

サーバの動作:

多数のリクエストを送信すると、パスワードのリセットによって。

レスポンスコード 429、およびレスポンスメッセージ「Too many requests」で。

ブロックされて。

 

f:id:ThisIsOne:20210921110833p:plain

 

テストの試行:

1.リクエストごとにユーザエージェントヘッダの値を。

 ランダムに変更してみると失敗して。

 

2.以下のようないくつかのヘッダを追加してみても失敗して。

 X-Forwarded-For : 127.0.0.1
 X-Forwarded-Host : 127.0.0.1
 X-Client-IP : 127.0.0.1
 X-Remote-IP : 127.0.0.1
 X-Remote-Addr : 127.0.0.1
 X-Host : 127.0.0.1


3.メールのリクエスト本文に下記のようなヌルバイトを追加しても失敗して。

 %00, %09, %0d, %0a

 

4.スペース、数字、role:adminなどを追加するなどしても失敗して。


5.パスにパラメータを追加するとバイパスされて成功して。

 https://dashboard.example.io/password-reset ⇦ ブロック

 https://dashboard.example.io/password-reset?anyCharacter=1 ⇦ バイパス成功

 下記のようにブロックせずに100件以上のリクエストを送信できて。

 

f:id:ThisIsOne:20210921110558p:plain

 

f:id:ThisIsOne:20210921110622p:plain

 

問題を段階的に再現:

下記のエンドポイントにアクセスして。

 https://dashboard.example.io/password-reset

 

パスワードをリセットして、Burpプロキシでリクエストをキャプチャして。

リクエストのエンドポイントにパラメータを追加して。

Intruderに送信するか、手動で多くの下記のリクエストを送信して。

 https://dashboard.example.io/password-reset?anyCharacter=1

 

Best regards, (^^ゞ

How i was able to bypass Cloudflare for XSS!を訳してみた

Hello there, ('ω')ノ

 

XSS用のCloudflareをバイパスすることができた方法を。

 

脆弱性:

 XSS

 

記事:

 https://infosecwriteups.com/how-i-was-able-to-bypass-cloudflare-for-xss-e94cd827a5d6


まずは、ログインページに「rurl」というパラメータがあったので。

オープンリダイレクトを試すと成功して。

オープンリダイレクトの脆弱性がある場合は、「a」タグ内の。

「href」属性に挿入されているので、xssを試すことができるので。

xssペイロード「javascript:alert(1)」を試すと。

下記のCloudflareという応答を得ることができて。

 

f:id:ThisIsOne:20210920170451p:plain


バイパス時間:

このような状況に対処するためのお気に入りの方法の1つは。

すべての仮定を1つずつ試すことで。

なので「javascript:」を試すことに。

 ■JavaScriptキーワード全体が削除されましたか?
 ■「:」の部分は削除されましたか?

 

これで200の応答を得たので、「javascript:alert」について進めることに。

 ■alertキーワードは削除されましたか?
 ■alert(1)の括弧が削除されている場合は?

 

なので、主な問題は括弧にあるので。

alert`1`」で括弧をバイパスしようとすると成功せず。

 

しかしながら、throwのような他のテクニックがあって。

多くのフィルタは、関数の呼び出しとパラメーターの受け渡しに不可欠なので。

括弧をブロックするので。

フィルタが挿入されたベクトルの括弧を削除する場合は。

それをバイパスする方法がいくつかあって。

Gareth Heyesが見つけた従来の方法を見ることに。

 https://portswigger.net/research/xss-without-parentheses-and-semi-colons

 

f:id:ThisIsOne:20210920171008p:plain

 

throwテクニックを使用して、括弧を使用せずに関数に引数を渡すメソッドで。

throwテクニックは、エラーがトリガーされると。

関数呼び出しを割り当てるためにonerrorイベントハンドラーを悪用するので。

throwを使用したXSSペイロードは、下記のようになって。

 javascript:window.onerror=alert;throw 1


このペイロードを試すと、再びcloudflareの応答が。

したがって、ここでは、「base64」、「UrlEncoding」、「Htmlencoding」などの。

他のエンコード手法を使用してさまざまなペイロードを試して。

下記が、最終的なペイロードで。

 javascript%3avar{a%3aonerror}%3d{a%3aalert}%3bthrow%2520document.cookie

 

Best regards, (^^ゞ

Logical Flaw Resulting Path Hijackingを訳してみた

パスハイジャックに起因する論理的欠陥を。

 

脆弱性:

 ネームスペース攻撃

 

記事:

 https://infosecwriteups.com/logical-flaw-resulting-path-hijacking-dd4d1e1e832f


今回は、パスのハイジャックにつながる1つのターゲットで。

見つかった論理的な欠陥について説明することに。

 

redracted.comでテストしているときに。

ユーザ名の適格性を適切にチェックおよび検証していないことがわかって。

誰かが既存のパス名を使用してサインアップして。

パスの結果を引き継ぐ可能性があるので。

その結果、アクセスしたときにパスが上書きされて。

 

どのように見つけたかというと。

ユーザ名(takeover)でサインアップした後に。

下記で、自分のプロファイルにアクセスすると。

 retracted.com/index.php

 

プロファイルがポップアップ表示されていることに気付いたので。

index.phpとユーザ名(takeover)をPOCとしてすぐに通知して。

 

f:id:ThisIsOne:20210920154001p:plain

 

影響:

このバグの影響は非常に大きくて。

悪意のある攻撃者がsignup.php、signin.php、および同様の多くのユーザー名を。

使用してサインアップするだけで、パスを引き継ぐ可能性があって。

それらのサインアップ、サインページは利用できず。

 

テイクアウト:

index.php、signup.php、signin.phpなどの一般的なパス名を使用して。

サインアップして、それらのパスにアクセスして。

プロファイルが表示されるかどうかを確認して。

もし表示されたら、それは脆弱かもしれなくて。

 

Best regards, (^^ゞ