Shikata Ga Nai

Private? There is no such things.

Unsubscribe any user’s e-mail notifications via IDORを訳してみた

Hello there, ('ω')ノ

 

IDOR を介してユーザーの電子メール通知の登録を解除するを。

 

脆弱性:

 IDOR

 

記事:

 https://sagarsajeev.medium.com/unsubscribe-any-users-e-mail-notifications-via-idor-2c2e05b79dac

 

今回は、Target Web サイトのメール通知サービスから任意のユーザを。

登録解除する方法を。

 

これは、購読解除機能 (メールのフッタ近くにあることが多い) が。

IDOR に対して脆弱であったために可能になり。

このようなオプションは、多くの場合、すべてのメールのフッタセクションで。

利用できて。

 

 

登録解除リンクは次のようになり。

    https://target.com/unsubscribe?u=9x0xxx98xx5cxx5xx71&id=123456

 

?u = Lolは、base64 でエンコードされた単なるタイムスタンプで。

このパラメータが何に使用されるのかはわからず。

おそらく、このアクションが開始された時刻を記録するためで。

しかし、このパラメータを操作しても、大きな影響はないようで。

しかし、req にこのパラメータが存在することが必要で。

さもないと、ステータス コード 400 が返され。


?id = ユーザ IDで。

ユーザID をリークする API 呼び出しがあったため。

ユーザID を取得するのは簡単で。

ターゲット ユーザのプロファイルにアクセスするだけで。

API によってユーザID が漏洩して。

 

変更されたリンクは次のようになり。

    https://target.com/unsubscribe?u=9x0xxx98xx5cxx5xx71&id=654321

 

Id パラメータを Victim UserID に変更し、req を転送して。

ユーザは、Web サイトの電子メール通知サービスから登録解除されて。

 

Best regards, (^^ゞ

SSRF leads to access AWS metadata.を訳してみた

Hello there, ('ω')ノ

 

SSRF は、AWS メタデータへのアクセスにつながるを。

 

脆弱性:

 SSRF

 

記事:

 https://infosecwriteups.com/ssrf-leads-to-access-aws-metadata-21952c220ae

 

サーバサイド リクエスト フォージェリ (SSRF) 攻撃では。

攻撃者はサーバ上の機能を誘導して。

内部リソースの読み取りまたは更新を行うことができ。

攻撃者は、AWS メタデータなどのサーバ構成を読み取ったり。

http 対応データベースなどの内部サービスに接続したり。

公開を意図していない内部サービスに対して。

ポスト リクエストを実行したりできる可能性があり。

 

https://portswigger.net/web-security/ssrf

 

プログラム名をreducted.comとして。

Burp SuiteのHTTP履歴ですべてのリクエストをチェックして。

Burp Searchを使用して、次のような可能なパラメータを見つけて。

 

url={target}
file={target}
filename={target}


top 25 params

https://github.com/lutfumertceylan/top25-parameter/blob/master/ssrf-parameters.txt

 

そして、このような url= を見つけて。

 reducted.com/gadgets/proxy/?url=


1.オープンリダイレクトを試みて

URL は https://reducted.com/gadgets/proxy/?url=https://evil.com のようなもので。

しかしエラーをスローして失敗して。

 


2.XSSを試して

URLはこんな感じで。

 https://reducted.com/gadgets/proxy/?url=javascript:alert(1);

 https://reducted.com/gadgets/proxy/?url=http://14.rs

 https://reducted.com/gadgets/proxy?url=http://brutelogic.com.br/poc.svg

 

しかしメソッドが許可されていないというエラーがスローされ失敗して。

 


3.LFI を試して。

URL は https://reducted.com/gadgets/proxy/?url=file:///etc/passwd のようなもので。

しかしurlスキーマはHTTPまたはHTTPSのみで失敗して。

 

 

内部を読み取ってサーバにアクション[file:///、dict://、ftp://、gopher://]を。

実行させるURLスキーマを試しましたが失敗して。

 

 

 

URLにアクセスしましたが、単純なテキストファイルが反映されて。

ダウンロードされたコンテンツをロードしておらず。

 

AWS メタデータの読み取り:

他の多くのことを行った後、結果が得られなかったので。

ヒットのためだけに AWS のマジック IP を思い出して。

URL パラメータを AWS が使用するマジック IP である以下の IP に置き換えてみて。

 

https://gist.github.com/mechcozmo/c41c3a8dff2e909f1c0b0c0b0586f67c

 

次のように URL を作成して。

https://reducted.com/gadgets/proxy/?url=http://169.254.169.254/latest/meta-data

 

 

これはreducted.txtファイルをダウンロードし、それを開くと以下の情報が表示されて。

 


下記が、AWS メタデータで。

 


緩和:

1.ホワイトリストと DNS 解決

2.入力検証

3.応答処理

4.未使用の URL スキーマを無効に

5.内部サービスの認証

 

Best regards, (^^ゞ

Improper Input Validation Leads To Email Spammingを訳してみた

Hello there, ('ω')ノ

 

不適切な入力検証は電子メールスパムにつながるを。

 

脆弱性:

 メールコンテンツインジェクション

 

記事:

 https://akshayravic09yc47.medium.com/improper-input-validation-leads-to-email-spamming-5d1a53b2a579

 

今回は、不適切な入力検証がターゲット (redacted.com) で。

電子メールスパムにつながることをどのように発見したかを。

 

いつものようにターゲットでテストしているときに。

プロファイルの姓名を編集するオプションがあり。

そのため、その機能をテストしたとき、入力文字数の制限がないことに気付き。

DOS よりも何ができるかを考えて。

 

 

そこで、他の興味深いエンドポイントを探し始めたところ。

突然機能の 1つに追いつき。

メールで他のユーザを招待するオプションがあったので。

他のユーザを招待しようとすると、このようなメールが届き。

 

 

招待メールを確認したところ、ユーザ名の代わりに姓と名が表示されていたので。

姓と名を他のスパムメッセージに変更したらどうなるか考えて。

最初と最後を編集して。

 

 

名前を変えて再度招待機能を使ったらこんなメールが届いて。

 

 

公式サポートセンターのメールIDからメールが届き。

そして興味深いのは、既存のユーザを招待することもできるということで。

ドメインはユーザが存在するかどうかを検証しておらず。

このようにして、サポート メール ID を介して。

スパムやフィッシングなどを行うことができて。

 

Best regards, (^^ゞ

Break the Logic: 5 Different Perspectives in Single Page (€1500)を訳してみた

Hello there, ('ω')ノ

 

論理を破る: 1ページに 5つの異なる視点を。

 

脆弱性:

 サーバ側のセキュリティ

 IDOR

 承認の欠陥のクライアント側の実施

 

記事:

 https://infosecwriteups.com/break-the-logic-5-different-perspectives-in-single-page-1500-5aa09da0fe7a

 

今回は、1つのページで見つけた 5つの異なる脆弱性について。

いつものように、「redacted」と呼ぶことに。

 

始める前に、アプリに関する情報を。

これは基本的に学校/学生向けのアプリで。

教師、生徒、保護者の 3 種類のユーザモデルがあり。

保護者は、生徒のプロフィールで自分の情報のみを編集できるので・

親ユーザとしての権限は制限されていて。

すべてのレポートは、単一の連絡先ページでこの観点から進められ。

 

1.ユーザは、アクセス権がなくても学生の主な住所を変更できて。

親ユーザとして学生のプロフィールにアクセスしたとき。

編集権限のないアドレス セクションを見つけて。

編集ボタンはアクティブでしたが。

クリックするとすべてのフィールドが無効になって。

 

 

ただし、保存ボタンがアクティブであることは引き続き確認でき。

そこで、かなり単純な方法として、フィールドから無効化された属性を削除して。

 

 

フィールドに自分の情報を入力しましたが、保存ボタンがまだアクティブだったので。

リクエストを送信するのは非常に簡単で。

 

 

リクエストを送信したところ。

ターゲット情報が実際に変更されていることがわかって。

保護はアプリケーションのフロントエンドのみにあり。

同様に、これらの情報は Burp Suite を使用して変更できて。

 

2.ユーザはアクセス権がなくてもすべてのセクションを編集できて。

親ユーザは、生徒のプロフィールに連絡先情報をいくつか持っていて。

ただし、この情報をすべて編集することはできず。

そのため、一部のフィールドを編集する権限しかなく。

 

 

たとえば、名前や住所などの情報もありますが、編集ボタンをクリックすると。

連絡先フィールドのみを変更できて。

 

 

この方法でリクエストを送信すると、次の PUT リクエストに遭遇して。

ご覧のとおり、名前、住所など、変更できないフィールドが他にもあり。

 

 

名前、住所、関係などの一部情報を変更してリクエストを送信すると。

 

 

情報が正常に変更され、ページに表示されて。

 

3.アクセス権がなくても、ユーザは新しい保護者の連絡先フィールドを作成できて。

親ユーザは自分の情報しか編集できないので。

新しい親連絡先フィールドを追加することはできず。

 

 

しかし、contact テーブルの編集リクエストを送信したところ。

パラメータの ID 値をすべて変更し。

新しい Contact テーブルを作成することができて。

 

 

写真のリクエストは、第2報のPUTリクエストと同じもので。

ご覧のとおり、リクエストにはさまざまな ID 値が含まれていて。

すべての ID 値の最後の桁をランダムな値に置き換え。

learnerPersonalid はすべての要求の最初にあり。

ページ固有ではなかったため除いて。

 

 

アプリがこのアクションにどのように反応するのか、実際には疑問に思っていて。

おそらく 500 件または 403 件の回答を期待していたのですが。

代わりにアプリが新しい連絡先フィールドを作成してくれて。

 

4.ユーザはアクセスしなくてもアドレスの種類を変更できて。

ユーザは、学生の定義済み住所タイプを変更できず。

たとえば、下の図では、学生用に2つのアドレスが定義されており。

親ユーザはそのタイプを変更できず。

 

 

居住地の住所を正式な住所に変更しようとすると。

アプリケーションでエラーが発生し、リクエストが実行されず。

 

 

最初のレポートの [保存] ボタンがまだアドレスに対して。

アクティブであることを思い出して。

そこで、住所を編集して送信したところ、次のリクエストに出会い。

 

 

「postalTitle」パラメータを公式に変更して。

同様に、正式な住所の住宅に変更することもできて。

 

 

アプリでは、正式な住所にできる住所は 1つだけですが。

両方の住所がメインの住所に変更されていることがわかり。

 

5.ユーザは、アクセスせずに学生の正式なアドレスを削除できて。 (基本 IDOR)

アドレスの種類を調べていると、違いがわかって。

居住地の住所には削除ボタンがアクティブでしたが。

正式な住所には削除ボタンがなく。

 

 

「削除」ボタンは居住地の住所には有効ですが。

正式な住所にはそのようなボタンはなく。


 

ということで、学生の正式住所編集ボタンをクリックして。

Burp Suite を実行し、保存ボタンをクリックしすると。

また次のリクエストに出会い、「household」の値をコピーして。

 

 

次に、自宅の住所に戻って削除ボタンをクリックし、リクエストを取得して。

「household:」の値を正式な住所 ID に置き換えて。

 

 

その結果、アクセスしなくても公式アドレスを削除することができて。

 

Best regards, (^^ゞ

Break the Logic: Insecure Parameters (€300)を訳してみた

Hello there, ('ω')ノ

 

論理を破る: 安全でないパラメータを。

 

脆弱性:

 パラメータ操作

 ロジック欠陥

 質量割り当て

 

記事:

 https://infosecwriteups.com/break-the-logic-insecure-parameters-300-e655cc4fcc42

 

今回は、同じプログラムで発見した安全でないパラメータに基づく 2 つの。

マイナーな脆弱性について。

これを「redacted.com」と呼ぶことに。

 

Ⅰ.安全でないパラメータを使用したメール検証のバイパス

redacted.com には、プライマリ メールと追加メールの 2 つのメール機能があり。

プライマリ メールを持つユーザは、追加のメールを追加でき。

ただし、追加のメールをプライマリ メールにするには。

アプリが確認コードを追加のメールに送信する必要があって。

そのため、追加のメールを確認なしにプライマリ メールに変換することはできず。

まず、このプロセスが通常の条件下でどのように行われるかを分析することに。

 

1.追加のメール セクションにメールを入力しましたが。

  そのメールには確認が必要であることに気付いて。

 

 

写真でわかるように、確認メールが送信され。

フィールドの横にある 2 つのオプションはメールの「再送信」または「削除」で。

 

2.Burp Suite を実行し、ページに戻り。

  再度メールを入力し、リクエストを受け取り。

 

 

3.「activated」と「for student verification」という2の安全でないパラメータは。

  falseを返すため、両方をtrueに変更してリクエストを送信して。

 

4.redacted.com に戻ると、メール フィールドの横に。

  チェックボタンが表示されていて。

  チェックボタンをクリックして、ページを更新して。

 

 

最後に、追加メールはプライマリ メール セクションに移動し。

古いプライマリ メールは追加メールになって。

 

Ⅱ.隠れた安全でないパラメータを使用したスタディ検証のバイパス

redacted.com では、ユーザはカスタムの「調査」情報を追加でき。

ただし、このためには、最初に管理者によって研究情報が検証および。

承認されなければならず。

つまり、ユーザが独自の調査情報を追加する際に検証プロセスがあり。

検証は、redacted.com の管理者によって直接行われ。

しかし、隠れた安全でないパラメータにより、ユーザのカスタム調査情報が。

承認済みのように見え、最終的に実際に承認される可能性があって。

分析することに。

 

1.「I study」フィールドで、独自の特別な学習情報を追加することができて。

  たとえば、「admin」と入力してリクエストを送信してみると。

 

 

2.Burp Suite を実行し、「admin」と入力してリクエストを再送信して。

 

 

3.リクエストは上記のとおりで。

  興味のあるものは何も見当たらなかったので、リクエストを送信して。

  レスポンスを確認して。

  それに応じて、パラメータ「isVisible:」が false に設定されていることが。

  わかって。

 

4.リクエストを再送信し、パラメータ「isVisible:true」をリクエストの末尾に。

  追加して。

 

 

ページを更新すると、追加した情報がプロファイルに直接表示されていることが。

わかって。

 

 

このようにして、攻撃者は検証をバイパスして、必要な情報を追加できて。

 

Best regards, (^^ゞ