How I was able to Regain access to account deleted by Admin leading to $$$を訳してみた

Hello there, ('ω')ノ

管理者によって削除されたアカウントへのアクセスを取り戻すことができた方法を。

脆弱性：

　論理の欠陥

　承認の欠陥

記事：

　https://rajeshranjan457.medium.com/how-i-was-able-to-regain-access-to-account-deleted-by-admin-leading-to-a2c29025f8cd

今回は、管理者によって削除されたアカウントにアクセスできたことについて。

Bugcrowdのプライベートプログラムで、example.comと仮定することに。

このアプリケーションには多くの機能があって。

ユーザを招待するオプションがあり、エンドポイントは下記のとおりで。

　example.com/dashboard/setup/user-accounts

だから、下記の自分のメールアドレスに招待状を送信すると。

　rajesh_ranjan+invite1@bugcrowdninja.com

下記の応答を受け取って。

　201 created

次にメールの受信トレイに移動して招待を受け入れて。

ユーザ名とパスワードを作成してから下記にアクセスして資格情報を入力すると。

　example.com/dashboard/login

下記の要求と応答が生成されて。

上記の応答をコピーしたあとに、再度、管理ダッシュボードに移動して。

アプリケーションからユーザアクセスを削除して。

その後、下記へアクセスして同じ古いクレデンシャルでログインしようとすると。

ログインに失敗しましたというエラーが表示されて。

　example.com/dashboard/login

そこで、インターセプトをオンにして下記のメニューを。

　Do intercepted ⇨ Response to this request 

そして、下記の応答を。

下記の応答に変更して。

リクエストを転送すると、そのアカウントでログインできて。

再現する手順：

・管理者側

    　下記にアクセスし、ユーザの電子メールを入力して招待状を送信して。

　　　example.com/dashboard/setup/user-accounts

・ユーザ側

    受信トレイを確認し招待リンクを開いて、アカウントのパスワードを設定して。

    設定した資格情報を使用して下記にログインして。

　　example.com/dashboard

    応答をコピーして、メモ帳に保存して。

・管理者側

    　管理者側で、その招待されたユーザを削除して。

・ユーザ側

    　クレデンシャルを使用して再度ログインしようとするとログイン失敗するので。

　    応答を傍受し、以前の応答（有効な応答）に変更すると正常にログインできて。

Best regards, (^^ゞ

Information Disclosure through Signup Endpointを訳してみた

Hello there, ('ω')ノ

サインアップエンドポイントを介した情報開示を。

脆弱性：

　情報開示

記事：

　https://sunilyedla.medium.com/information-disclosure-through-signup-endpoint-86d2d66dfef1

今回は、適切な検証が行われていない場合。

攻撃者がすでに登録されている被害者の電子メールに。

新しいパスワードを入力してサインアップすると。

既存の被害者アカウントのパスワードが変更されて。

完全なアカウントの乗っ取りにつながることについて説明することに。

今回のドメインを、<redacted>.comとすると。

まず、サインアップして新しいアカウントを作成して。

ダッシュボードページにアクセスして。

すぐにアカウントからログアウトして、新しいアカウントページの作成を。

新しいアカウントを作成するには。

ユーザは、最初にメールアドレスを指定する必要があって。

バックグラウンドのウェブサイトでは、指定されたメールアドレスが。

登録されているかどうかを分析して。

登録済みのメールアドレスを入力した後、下記のエラーメッセージが。

　「あなたはすでに<redacted>のアカウントを持っています。

　　以下に<redacted>パスワードを入力して続行してください。」

そこで、Burp Suiteをセットアップして。

同じメールアドレスで再度サインアップして、ランダムパスワードを入力すると。

リクエストの本文は下記のようになっていて。

{“email”:”<Victims_Email>”,”password”:”Randompas”,”verifyPassword”:”Randompas”,”firstName”:”<firstname of victim>”,”lastName”:”<lastname of victim>”,”phoneNumber”:”<victims phonenumber>”}

ここでの影響は、攻撃者が登録ユーザの名、姓、電話番号の詳細を取得できることで。

Webサイトのワークフローによれば、これは発生しないはずで。

ステップ：

１．ブラウザ１で、被害者メールアドレスを作成して。

　email: <redacted>@gmail.com、Pass: Pass123!

２．ブラウザ２で、攻撃者のサインアップフォームに移動して。

　登録済みの電子メールIDを入力して。

　email: <redacted>@gmail.com

３．攻撃者は、下記のようなエラーメッセージが表示されて。

　「あなたはすでに<redacted>のアカウントを持っています。

　　以下に<redacted>パスワードを入力して続行してください。」

４．攻撃者は、パスワードがわからないのでランダムにパスワードを入力して。

　Burp Suiteでリクエストをキャプチャして。

５．攻撃者のリクエスト本文を確認して。

Best regards, (^^ゞ

Stored XSS on Product Description [HIGH] — $400を訳してみた

Hello there, ('ω')ノ

製品説明に保存されたXSSを。

脆弱性：

　保存されたXSS

記事：

　https://emanuel-beni.medium.com/stored-xss-on-product-description-high-400-2f078fd70fd2

保存されたクロスサイトスクリプティングは。

アプリケーションがユーザからの信頼できない悪意のあるコードを保存する脆弱性で。

攻撃の複雑さが低くて、致命的であるという組み合わせで。

ほとんどのeコマースWebサイトでは。

売り手が商品ページに独自の商品説明を追加できて。

これはStoredXSSの攻撃ベクトルの1つであるため。

簡単なテスト用に下記のXSSペイロードを入力することに。

１．Polyglot Payload

　“ onclick=alert(1)//<button ‘ onclick=alert(1)//> */ alert(1)//

２．Polyglot Payload

　‘“>><marquee><img src=x onerror=confirm(1)></marquee>”></plaintext\></|\><plaintext/onmouseover=prompt(1)><script>prompt(1)</script>@gmail.com<isindex formaction=javascript:alert(/XSS/) type=submit>’ →”></script><script>alert(1)</script>”><img/id=”confirm&lpar;1)”/alt=”/”src=”/”onerror=eval(id&%23x29;>’”><img src=”http://i.imgur.com/P8mL8.jpg">

３．URL Encoded

　%7d%29%3b%7d%29%3balert%60xss%60;%3c%2f%73%63%72%69%70%74%3e

　⇩

　});});alert`xss`;</script>

４．HTML Injection Check

　‘“><a href=’www.anything.com’>Click Here</a>

基本的に利用可能なすべてのペイロードを使用して確認することはしなくて。

通常は、上記のXSSペイロードで反射の可能性をチェックしていて。

ペイロードを入力した後、最初にHTMLインジェクション。

つまり、実行されたHTMLタグをチェックして。

WebアプリケーションがHTMLタグを実行する場合は。

XSSに利用できる可能性が高くなるものの。

残念ながら、スクリプトタグが実行されず。

その結果、下記の結論に。

Webアプリは、WAF（Webアプリケーションファイアウォール）を実装していて。

WAFは、下記のような機密性の高いキーワードを削除していて。

　「javascript」と「alert」

製品の説明では、Markdownを使用してユーザの入力を解析しているようで。

Markdownは、プレーンテキストのテキストドキュメントに。

フォーマット要素を追加するために使用できる軽量のマークアップ言語で。

Markdownはユーザに高いカスタマイズ性を提供するため。

設定ミスが頻繁に発生して。

そこで、上記の条件を回避できる可能性のあるペイロードを探すことに。

最も一般的なバイパスの1つがUnicodeエンコーディングを使用することで。

下記のペイロードを入力すると。

　<a href=j&#97v&#97script:&#97lert(document.cookie)>ClickMe</a>

　⇩

　<a href=javascript:alert(document.cookie)>ClickMe</a>

　https://www.gadgety.net/shin/trivia/translate.html

XSSとHTMLインジェクションが成功して。

Webアプリケーションは、Unicodeをプレーンテキストにデコードして。

アンカータグがクリックされたときにペイロードを実行して。

アンカータグをクリックすると、document.cookieが表示されて。

Best regards, (^^ゞ

Privilege Escalation: From being a normal user to adminを訳してみた

Hello there, ('ω')ノ

権限昇格：通常のユーザから管理者へを。

脆弱性：

　特権の昇格

　アクセス制御の破損

記事：

　https://parasarora06.medium.com/privilege-escalation-from-being-a-normal-user-to-admin-3f86896f1c93

特権の昇格：

　特権の昇格は、攻撃者がアプリケーションまたはオペレーティングシステムの。

　バグ、設計上の欠陥、または構成エラーを悪用して。

　通常は権限のないユーザーが利用できないシステムリソースへのアクセスを。

　昇格させた場合に発生して。

Subfinderを使用したサブドメインの列挙から始めることに。

　subfinder -d domain.com | httpx -o /output_file.txt

その後、output_file.txtでWaybackurlsを実行して。

　cat output_file.txt | waybackurls > /wayback.txt

wayback.txtファイルでさまざまなキーワードを検索していると。

「admin」というキーワードで非常に興味深いものが見つかって。

　https://www.domain.com/xxx/xxxx/page/login/?redirect_uri=https%3A%2F%2Fwww.domain.com%2Fadmin%2F&app_id=xx

domain.com/registerでアカウントにサインアップして。

wayback.txtで見つけた上記のURLを監視しながら。

アプリケーションを探索して、機能を調べても管理者に関連するものは何もなくて。

そこで、ログインしている現在のタブの隣の新しいタブで。

通常のユーザアカウントで開き、上記のURLを貼り付けて。

しばらくの間、結果のWebページを分析することに。

すると、「admin」キーワードとadminのapp_idで構成されるURLに。

リダイレクトした後、通常のユーザーアカウントがadminに変更されて。

最初は許可されていなかった機能にアクセスできて。

このようにして、すべての管理機能にアクセスして。

Webアプリケーションでより高い特権の役割を実現することができて。

要点

・アプリケーションを徹底的に調査する

・admin、api_key、tokenなどの機密性の高いキーワードを常に探す。

・「admin」キーワードが含まれているURLを探す。

・通常のユーザがログインしているタブに隣接する新しいタブで。

　より高い特権のアカウントリクエストを直接開くと。

　ユーザに許可されていない機能にアクセスできる場合がある。

Best regards, (^^ゞ

API based IDOR to leaking Private IP address of 6000 businessesを訳してみた

Hello there, ('ω')ノ

6000の企業のプライベートIPアドレスをリークするAPIベースのIDORを。

脆弱性：

　IDOR

記事：

　https://rafi-ahamed.medium.com/api-based-idor-to-leaking-private-ip-address-of-6000-businesses-6bc085ac6a6f

IDORとは？

安全でない直接オブジェクト参照（IDOR）は。

アプリケーションがユーザ指定の入力を使用して。

オブジェクトに直接アクセスするときに発生するアクセス制御の脆弱性の一種で。

APIとは？

APIは、Application Programming Interfaceの頭字語で。

2つのアプリケーションが相互に通信できるようにするソフトウェア仲介役で。

Facebookなどのアプリを使用したり。

インスタントメッセージを送信したり。

スマートフォンで天気を確認したりするたびにAPIを使用していて。

今回、NDA（Non-disclosure Agreement）プログラムをテストしていて。

Webアプリケーションにユーザのアクセスログを表示する。

オプションがあることに気付いて。

さっそく、インターセプトをオンにして。

Webアプリケーションの閲覧中にブラウザが。

サーバに送信するすべてのリクエストを確認することに。

すると、同じページに再度アクセスすると。

ページの他のコンテンツが既に読み込まれているにもかかわらず。

アクセスログが表示されていないことに気付いて。

原因は、インターセプトがオンになっていて。

ユーザのアクセスログを取得しようとしているAPIリクエストが。

インターセプトされていることに気付いて。

さらにPOSTデータを見ると、UserIDが含まれていることが確認できて。

次に、Intruderにリクエストを送信して。

ユーザIDをブルートフォース攻撃して、6000の企業のアクセスログを取得できて。

Best regards, (^^ゞ