mfa bypass in private program, the abdulsec wayを訳してみた

Hello there, ('ω')ノ

プライベート プログラムでの mfa バイパスを。

脆弱性：

　MFA バイパス

記事：

　https://infosecwriteups.com/mfa-bypass-in-private-program-the-abdulsec-way-f677fea209f7

今回は、プライベート プログラムで多要素認証をバイパスするために。

使用したテクニックを共有したいと思い。

アカウントにログインして二要素認証を有効にし、ログアウトして。

次回ログインすると、二要素認証のセットアップにリダイレクトされて。

MFA（多要素認証）を完全にセットアップしたアカウントにログインすると。

チャレンジ ページにリダイレクトされ。

このページでは、６つの番号で構成される有効なコードを入力する必要があり。

SMS ベースの MFA ではないため、ブルート フォースを考えないで。

２要素認証を使用しているアカウントと。

２要素認証を有効にしているが設定していないアカウントの間の応答の違いを。

分析したところ、違いは応答ヘッダのみであることがわかり。

　X-Mfa-Redirect: mfaChallengePage

　X-Mfa-Redirect: mfaSetupPage

２要素認証をバイパスするために、応答ヘッダの X-Mfa-Redirect を変更して。

mfaChallengePage の代わりに mfaSetupPage にリダイレクトするように。

再現手順：

１．Burp Suiteで、proxy > options に移動して、match and replaceを

２．応答ヘッダで、mfaChallengePageをmfaSetupPageに置き換えて。

３．２要素認証を使用している被害者のアカウントにログインして。

４．新しい２要素認証をセットアップするためにリダイレクトして。

５．MFA のセットアップを完了すると、有効な MFA コードがなくても。

　被害者のアカウントにリダイレクトされ。

６．二要素認証を無事に回避して。

Best regards, (^^ゞ

IDOR at Login function leads to leak user’s PII dataを訳してみた

Hello there, ('ω')ノ

IDOR at Login 関数により、ユーザの PII データが漏洩するを。

脆弱性：

　IDOR

　情報開示

記事：

　https://eslam3kl.medium.com/idor-at-login-function-leads-to-leak-users-pii-data-d77e6613e9e0

今回は、脆弱な機能は、攻撃者を管理してユーザ名を置き換え。

登録ユーザの PII を漏洩させるログイン機能で。

バグの再現手順として、IDOR の簡単な定義を確認する必要がある場合は。

この悪意のあるユーザ1234 を確認して。

再現する手順：

１．脆弱なサブドメインには、最初にユーザ名を入力する必要がある。

　ログイン機能があり、それが有効な場合は。

　次のステップに進んでパスワードを入力し。

２．ランダム ユーザテストに入った後、test という名前のユーザが。

　存在することに驚き、応答で彼の PII データをすべて取得して。

　エンドポイントは以下のとおりで。

　　https://subdomain.target.com/v1.0.0/dev/userfirm/ 

３．このリクエストをIntruderに送信し、漏洩したユーザ名を。

　よりリアルなものにしてみて。

このようにして、次のようなシステムユーザのほとんどの情報を取得でき。

　ユーザ名

　姓名

　電子メールアドレス

　電話番号

　電話

　商号

　ユーザID

緩和/修正：

１．機密データが含まれないようにリポジトリを制限し。

　開発者は、これらの機密情報を別の機能に送信する必要がありますが。

　攻撃者の視界から遠く離れた場所に制限することを忘れていて。

　PII データを次のような文に置き換えることができ。

　　{"userExist":"true", "errors": null}

２．指定された API エンドポイントにスロットリング コントロールを追加して。

　ブルート フォーシングの試みを停止して。

Best regards, (^^ゞ

Found SQL Injection Vulnerability on Government Organization Website!を訳してみた

Hello there, ('ω')ノ

政府機関の Web サイトに SQL インジェクションの脆弱性が見つかったを。

脆弱性：

　SQL インジェクション

記事：

　https://mehedishakeel.medium.com/found-sql-injection-vulnerability-on-government-organization-website-3eb33c0c49a4

脆弱なウェブサイトを見つけるために Google a dork でクイック検索を行い。

興味深い結果を見つけ。

それらのウェブサイトの １つから、SQL インジェクションの脆弱性を発見し。

MySQL データベースから機密情報を悪用して取得することに成功して。

SQL インジェクション攻撃：

SQLi の脆弱性を見つけて悪用するために使用したすべてのツールを次に示して。

　Google Dork、Burp Suite、Sqlmap

詳細について説明することに。

Google 検索エンジンでdork を検索して。

    _news/news.php?id=

興味深い結果がいくつか見つかり。

それらの検索結果の １つから Web サイトを見つけ。

元の Web サイトの URL を開示することはできず。

それをexample.orgと呼ぶことに。

そのWebサイトで、SQLインジェクションに対して。

脆弱な興味深いパラメータを見つけるとシステムエラーが表示されて。

　http://example.org/news.php?id=45'

次に、Kali マシンで Burp Suiteを起動し、リクエストを取得して。

req.txt テキスト ファイルに保存して。

ここで、自動 SQL インジェクション攻撃のリクエスト ファイルを使用して。

sqlmap SQL インジェクション ツールを実行し。

すべてのデータベースと、管理者、ユーザ、電子メールや。

md5 ハッシュ パスワードなどの機密情報をダンプして。

Sqlmap の悪用とコマンド :

    sqlmap -r req.txt -dbs

    sqlmap -r req.txt -D db_name --tables

    sqlmap -r req.txt -D db_name -T table_name --columns

    sqlmap -r req.txt -D db_name -T table_name -C column_name --dump

これが、政府機関の Web サイトで重大度の高い SQL インジェクションの。

脆弱性を見つけた方法で。

Best regards, (^^ゞ

Bypassing Amazon WAF to pop an alert()を訳してみた

Hello there, ('ω')ノ

Amazon WAF をバイパスしてアラートをポップするを。

脆弱性：

　WAFファームウェア

　XSS

記事：

　https://infosecwriteups.com/bypassing-amazon-waf-to-pop-an-alert-4646ce35554e

今回は、Amazon WAF をバイパスしてターゲットで XSS を取得する方法を。

バグバウンティに興味がある場合は。

WAF をバイパスできるペイロードを作成するという考え方を作成するのに役立ち。

WAF (Web Application Firewall) は。

悪意のあるトラフィックをフィルター処理することにより。

SQL インジェクション、クロスサイト スクリプティング (XSS) などの。

一般的な攻撃から Web アプリケーションを保護するために。

使用されるファイアウォールで。

発見：

コンテンツの発見段階で、できるだけ多くのエンドポイントを集めようとし。

パッシブ スキャン拡張機能を有効にして、常に Burpsuite Proxy を。

バックグラウンドで実行してみて。

かなりの時間を費やした後、Burp Suiteが生成したサイトマップを分析して。

エンドポイントを手動で検査し。

ターゲットの Web サイト自体は機能がかなり制限されていたため。

役立つものを見つけることができず。

robots.txt ファイルに移動すると、許可されていないエンドポイント、つまり。

/index.aspx が表示され。

Web サイトは Wordpress で実行されており、.aspx エンドポイントを。

含むページは wordpressのサイトで表示されるものではないため、これは少し奇妙で。

ページ自体は空白でしたが、ソース コードを確認すると。

HTML と JavaScript がいくつかあり。

これは、このページの目的が何なのか疑問に思い。

パズルに何かが欠けているように感じて。

次に、パラメータの発見ができることを思い出し。

Arjun は、この目的に最適なツールで。

サーバへの最小限のリクエストで、パラメーター名の膨大なリストを照会できて。

https://github.com/s0md3v/Arjun

３つのパラメータのうち、パラメータacc は <script>tag 内の。

Web ページに反映され。

JavaScript は次のようになり。

　xt_multc ='&x1=0&x2=REFLECTION_POINT';

REFLECTION_POINT は、パラメータ値が反映される領域を指し。

ページに JavaScript を挿入できるようにするには。

一重引用符をエスケープする必要があり。

このパラメータを使用してページで kxss をすばやく実行し。

サニタイズ／エンコードされておらず、そのまま反映されている特殊文字を。

特定して。

kxss は、パラメータ内のフィルタ処理されていない文字を識別するための。

優れたツールで。

https://github.com/Emoe/kxss

ご覧のとおり、フィルタリングされていない特殊文字がたくさんあり。

その中の一重引用符もその 1 つで。

目標に一歩近づいたので、これは朗報で。

この時点で、「;alert(document.domain);//」などの単純なペイロードを試すと。

WAF が作動し、試行は失敗して。

WAF をバイパス：

さまざまなペイロードを試してみたところ、alert( などの有効な JavaScript 関数名を含むペイロードが含まれているという結論に達しました。アラートと開き括弧の間にコメントを挿入してバイパスしようとしましたが、それもブロックされました。

Burpsuite Intruder を使用して、このコンテキスト (Javascript 文字列内のリフレクション) に基づいてペイロードをファジングしようとし

ましたが、成果が得られませんでした。

alert() 以外の関数でファジングすると、fetch() や print() などの関数が許可されていることがわかりました。これらを使用して、レポートで概念実証を実証することもできましたが、WAF を打ち負かして alert() 関数を実行するという課題に取り組みました。

alert(document.domain) を書く代わりに、window オブジェクトを使用してアラート関数を呼び出すことができます: window["alert"](document.domain) 。

残念ながら、このペイロードもブロックされました。次に、Javascript の複数行コメント構文をペイロードの間に使用して、通常は一連のルールと正規表現に基づいて実行される WAF をだますことができることを思い出しました。

最終的なペイロードは ';window/*aabb*/['al'%2b'ert'](document./*aabb*/location);// です。 「alert」文字列を「al」と「ert」の 2 つの部分に分割して追加しました。プラス記号は URL エンコードする必要があります。そうしないと、スペース記号として解釈されます。

ついにアラートを鳴らしました！

Best regards, (^^ゞ

How I bypassed Reflected XSS in well-known platformを訳してみた

Hello there, ('ω')ノ

よく知られているプラ​​ットフォームで Reflected XSS をバイパスする方法を。

脆弱性：

　XSS

記事：

　https://moustadif.medium.com/how-i-bypassed-reflected-xss-in-well-known-platform-274c07f97674

クロスサイト スクリプティング (XSS) は。

攻撃者がコード (通常は HTML または JavaScript) を。

外部の Web サイトのコンテンツに挿入できる Web アプリケーションの脆弱性で。

被害者が Web サイトで感染したページを表示すると。

挿入されたコードが被害者のブラウザで実行され。

その結果、攻撃者はブラウザの同一オリジン ポリシーをバイパスし。

Web サイトに関連付けられた被害者から個人情報を盗むことができて。

反射型 XSS 攻撃 (非永続的攻撃とも呼ばれる) は、悪意のあるスクリプトが。

Web アプリケーションから被害者のブラウザに反射されるときに発生し。

スクリプトは、悪意のあるスクリプトの実行を可能にする脆弱性を持つ。

Web サイトにリクエストを送信するリンクを介してアクティブ化され。

この脆弱性は通常、受信リクエストが十分にサニタイズされていないために。

発生して。

これにより、Web アプリケーションの機能が操作され。

悪意のあるスクリプトが起動される可能性があり。

悪意のあるリンクを配布するために、加害者は通常、それを電子メールまたは。

サード パーティの Web サイト (コメント セクションやソーシャル メディアなど) に。

埋め込んで。

リンクはアンカー テキスト内に埋め込まれており、ユーザーにクリックを促し。

これにより、悪用された Web サイトへの XSS 要求が開始され。

攻撃がユーザに反映されて。

列挙：

メインドメインwww.redacted.comにバグが存在するため。

列挙と発見にあまり投資せず。

Google dork を実行して、param: redirect?t= のパスを見つけることに。

　site:www.redacted.com inurl:redirect

オープン リダイレクトをテストしましたが、うまくいかず。

ソース コードを確認したところ、コードが <script> </script> タグ内に。

あることがわかり。

r-XSS 脆弱性の悪用：

反映された XSS バグを悪用して、Cookie を盗んだり、パスワードを取得したり。

CSRF を実行したりでき。

最初のコードを挿入して。

　</script> alert(‘1’) <script></script>

スクリプトを閉じて悪意のあるスクリプトを開こうとしましたが。

すべてのスクリプトとタグ <script> を壊すフィルタが配置されて。

フィルターをバイパスするための適切なペイロードを見つけて。

　</</script>script> <</svg>svg/onload=alert`xss`>//

最終的な URL / POC は次のようになり。

https://www.redacted.com/iammore/redirect?t=%3C/%3C/script%3Escript%3E%20%3C%3C/svg%3Esvg/onload=alertxss%3E//

⇧

https://www.redacted.com/iammore/redirect?t=</</script>script> <</svg>svg/onload=alertxss>//

Best regards, (^^ゞ