Shikata Ga Nai

Private? There is no such things.

robotsの利用方法についてシンプルにかいてみた

Hello there, ('ω')ノ

 

robots.txtは、攻撃者に見せたくない場所を伝えて。

つまり、「ここには何も見えない」と言うことで攻撃者は興味を持つわけで。

 

robots.txtファイルが、攻撃者に所有者が。

保護しようとしているディレクトリに関する手がかりを与えることで。

ターゲットに関する潜在的な貴重な情報を提供できるわけで。

 

robots.txtファイルは、検索エンジンにWebサーバ上のどのディレクトリを。

読み取ることができるか、または読み取れないかを通知して。

攻撃者は、所有者が隠したいものを持っていると言っているようなもので。

システム管理者が機密資産をどこに保存するかについての手がかりを。

提供すると考えていて。


最も単純なケースでは、robots.txtは。

制限されたパスとサーバで使用されているテクノロジーを明らかにするわけで。

 

f:id:ThisIsOne:20211011171705p:plain

 

多くの場合、脆弱性と不十分なセキュリティを含む管理ポータルは。

資産を不明瞭にするために robots.txtの禁止リストに定期的に含まれていて。

これらのポータルを特定することは、robots.txtファイルを収集して。

サブディレクトリの詳細なリストを更新するペネトレーションテスターの。

標準的な方法で。

robots.txtファイルは、将来の攻撃や侵入テストで機密資産の発見を。

スピードアップするのに役立つわけで。

 

ペネトレーションテスターは通常、Webアプリケーションテストの偵察段階では。

既知のサブディレクトリのリストを使用して。

サーバをブルートフォース攻撃し、隠されたリソースを見つけたりと。

ただ、特定のWebテクノロジーの採用に応じて。

サブディレクトリのリストは定期的な更新が必要で。

 

disallow文は、攻撃者に何を見る価値があるかについての貴重な知識を与えて。

さらには、それが1つのサイトに当てはまる場合は。

別のサイトでも確認する価値もあって。

 

Best regards, (^^ゞ

Exploiting API with AuthTokenを訳してみた

Hello there, ('ω')ノ

 

AuthTokenを使用したAPIの活用を。

 

脆弱性:

 トークンリーク

 情報開示

 

記事:

 https://rafi-ahamed.medium.com/exploiting-api-with-authtoken-3bea7b1fb6a9

 

ツール:

 Burp Suite

 

今回は、AuthTokenを使用したAPIエンドポイントの活用に関するもので。

偵察プロセスで、AuthTokenを見つけましたものの。

影響を示すことができず。

 

APIとは:

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

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

 Facebookなどのアプリを使用したり、インスタントメッセージを送信したり。

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

 

仮に偵察プロセスで任意のユーザのAuthToken、またはAPIトークンが見つかっても。

ほとんどの場合、該当しないと報告するだけで。

 

AuthTokenを介したAPIの活用:

最近、Bugcrowdでプライベートプログラムをテストしていると。

偵察プロセスで、常に手に入るAuthTokenを見つけたものの。

難しいのは、それを悪用することで。

 

まず第一に、プログラムはテスト用のクレデンシャルを提供せず。

サインアップする方法もないので。

インフラストラクチャが実際にどのように機能するのかわからず。

 

偵察で見つけたトークンは、APIが認証に使用するAuthentication Bearerトークンの。

代わりになる可能性のあるAuthToken(コードで記述された)で。

これで、トークンがAPIトークンに似ているというヒントが得られて。

しかしながら、ユーザアカウントなどにアクセスできなかったために。

APIインフラストラクチャがどのように機能するのかわからなかったので。

あきらめることに。

 

次に別のWebアプリケーションをテストしているときに。

ユーザ情報を更新するときにAPI呼び出しが表示されて。

このAPI呼び出しを使用することで。

昨日のAPI呼び出しを悪用できるのではないかと思ったので。

Burpを使用してそのリクエストをRepeaterに送信して。

ホストとリクエストのエンドポイントを。

偵察プロセスで見つけたものに変更すると。

 POST /v3/xxxxx

 Host: api.xxxxx

 

下記のような403 forbiddenの応答が。

 

f:id:ThisIsOne:20211011115933p:plain


これにより、どのヘッダが欠落しているかについての情報が得られて。

 xxxxxAuth

 

次に、応答が示したヘッダー名を使用して取得したトークンを追加すると。

500 Internal Server Error応答が。

つまり、APIに接続できたということで。

下記のとおり、リクエストはPOSTであってリクエストにPOSTデータはなくて。

そのため、アプリケーションで500 Internal Server Errorが表示されていて。

 

さらに偵察して、エンドポイントのテストに使用できるPOSTデータを取得して。

POSTデータを追加してリクエストを再度送信してみると。

100人のクライアントのデータにアクセスできて。

 

f:id:ThisIsOne:20211011115952p:plain

 

Best regards, (^^ゞ

XSSの基本的な診断手順をなるべく詳細にかいてみた②

Hello there, ('ω')ノ

 

前回と同じような内容になってしまうかもですが。

今回は、反射型ではなく保存型のクロスサイトスクリプティングについて。

まずは、PortSwiggerのアカデミーへ移動して。

まずは、データを入力してクリックを。

 

f:id:ThisIsOne:20211009164759p:plain

 

リクエストで入力したパラメータを確認して。

送信後は、ステータス302でリダイレクトされて。

 

f:id:ThisIsOne:20211009164837p:plain

 

下記が、リダイレクトされたページで。

 

f:id:ThisIsOne:20211009164853p:plain

 

入力したデータがどこに反映されたかを確認して。

 

f:id:ThisIsOne:20211009164940p:plain

 

Burp Suiteでレスポンスを確認すると。

入力したデータをみつけることができて。

メールアドレスだけは、どこにも見当たらず。

まずは、この表示を壊すことができるか。

 

<p>
<img src="/resources/images/avatarDefault.svg" class="avatar">

<a id="author" href="https://test.com">namae</a> | 09 October 2021
</p>
<p>mes</p>

 

f:id:ThisIsOne:20211009165200p:plain

 

データを入力したリクエストをリピータへ。

まずは、パラメータにHTMLタグを入力して、どのように反映されるかを。

 

f:id:ThisIsOne:20211009170124p:plain

 

素直に反映されたようなので。


f:id:ThisIsOne:20211009170054p:plain

 

今度は、スクリプトを挿入して送信すると。

 

f:id:ThisIsOne:20211009170444p:plain

 

スクリプトが保存されて、表示されるページを開くとポップアップが。

 

f:id:ThisIsOne:20211009170245p:plain

 

ちなみにレスポンスには下記のように表示されて。

 

f:id:ThisIsOne:20211009170416p:plain

 

一方、アクティブスキャンを下記のエンドポイントで実行すると。

 /post/comment

 

f:id:ThisIsOne:20211009170553p:plain

 

結果として、なにも検出されなかったり。

 

f:id:ThisIsOne:20211009182917p:plain

 

そのようなときはログを確認する必要がありますが。

パラメータにペイロードは挿入しているものの。

クロスサイトスクリプティングのペイロードは見当たらないような。

 

f:id:ThisIsOne:20211009183303p:plain

 

再度、実行してみると検出されたりと。

これまで、あまりアクティブスキャンの機能を使ったことがないので。

正直なところ、よくわかっていないところもあるので、今後の課題で。

もしかしたらサイトのタイムアウトと関連するのかと。

それにしてもこのような複雑なペイロードを挿入しなくてもよさそうなのですが。

 

f:id:ThisIsOne:20211010182553p:plain

 

ちなみにTargetタブにも新たに脆弱性は追加されるようで。

 

f:id:ThisIsOne:20211009183618p:plain

 

さらには、TargetタブのSite map上の右クリックする場所によって。

Acrively scan this hostとでたり。

 

f:id:ThisIsOne:20211010072941p:plain

 

Acrively scan this branchとでたりの違いがあって。

この機能を中心に使ったことがないので、今頃ごろになって違いに気づいたりと。

個人的には、ペイロードリストを作成しておいて。

エンドポイントとパラメータに対して。

Intruderで回して検証したほうが、リクエストも少なくて負荷をかけないような。

 

f:id:ThisIsOne:20211010081246p:plain

 

Best regards, (^^ゞ

Weak Cryptography to Account Takeover’sを訳してみた

Hello there, ('ω')ノ

 

アカウントの乗っ取りを説明するための弱い暗号化を。

 

脆弱性:

 暗号化の問題

 アカウントの乗っ取り

 IDOR

 

記事:

 https://vasuyadav0786.medium.com/weak-cryptography-to-account-takeovers-87782224ed0d

 

ツール:

 Burp Suite

 

今回は、弱い暗号化によって可能になって。

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


最初に、暗号化とは何か。

 暗号化は、通常のプレーンテキストを理解できないテキストに(またはその逆に)。

 変換するプロセスに関連付けられていて。

 これは、特定の形式でデータを保存および送信する方法で。

 対象のユーザのみがデータを読み取って処理できるようにして。

 

さて、弱い暗号化とは何か。

 弱い暗号は、長さが不十分なキーを使用する暗号化/復号化アルゴリズムとして。

 定義されて。

 暗号化/復号化アルゴリズムで、キーに不十分な長さを使用すると。

 暗号化スキームが破られる(つまりクラックされる)可能性(または確率)が。

 広がって。

 

今回のターゲットを「cantdisclose.com」と呼ぶことに。

アカウントのパスワードのリセットをリクエストしたところ。

下記のようにメールにリンクがあって。

 

f:id:ThisIsOne:20211009104510p:plain

 

最後に「==」が表示されたらすぐにBase64である可能性があると思ったので。

それをコピーしてデコーダに移動して、トークンを貼り付けたところ。

結果は、下記のようになって。

 

f:id:ThisIsOne:20211009104531p:plain

 

再現手順:

1.この目的のために2つのアカウントを使用して。

   vasuyadav1@gmail.com ⇦ 攻撃者のアカウント

   vasuyadav2@gmail.com ⇦ 被害者のアカウント

 

2.1つのアカウントのパスワードのリセットをリクエストして。

 Burp Suiteでキャプチャして。

 

3.Intruderに送信して、電子メールパラメータを選択して。

 被害者の電子メールを追加して。

 サーバにリクエストを非常に高速で送信すると。

 送信時間が両方のアカウントでほぼ同じになるためで、これを使用して。

 

4.攻撃者のアカウントを確認して、リンクをコピーして。

 

5. index/の後の文字列をBase64としてデコードして。

 

6.例:「senttime/15935586556/token/vasuyadav1@gmail.com

 

7.被害者のメールアドレスvasuyadav2@gmail.comでこれを変更して。

 送信時刻を同じにして。

 「senttime/15935586556/tokenvasuyadav2@gmail.com」を。

 Base64にエンコードして。

 

 タイムスタンプ=1593558655
 ⇩
 日時(Tokyo)=2020/07/01 08:10:55

 

8.エンコードされた文字列は、下記のようになって。

 

9.https://www.cantdisclose.com/resetpassword/index/c2VudHRpbWUvMTU5MzU4NjU1Ny90b2tlbi92YXN1eWFkYXYxOTg0QGdtYWlsLmNvbQ==。

 

f:id:ThisIsOne:20211009110344p:plain

 

10.これが機能しない場合は、送信時刻を1または2変更して。

 同じプロセスを実行してみて。

 

11.私の場合、送信時間を1変更すると機能し、ブームはメールで送信されたリンクを確認せずに他のアカウントのパスワードを変更することができました。

 

それでは、OAUTHの実装にあった2番目の発見について。

OAUTHの使用中に送信されたリクエストと。

認証がどのように行われているかを確認していたところ。

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

 

f:id:ThisIsOne:20211009104607p:plain

 

リクエストには、Authorizationヘッダが含まれいて。

Base64も使用しているので、簡単に復号化できて。

ここでも同じことを行うことに。

つまり、メールを他のアカウントのメールに変更して。

Base64にエンコードしてから、そのリクエストを転送するだけで。

他のアカウントにログインできて。

 

f:id:ThisIsOne:20211009104632p:plain

 

Best regards, (^^ゞ

Port SwiggerにExploiting cross-site scripting to steal cookiesのバグを報告してみた

Hello there, ('ω')ノ

 

Exploiting cross-site scripting to steal cookiesを。

 

f:id:ThisIsOne:20211009091156p:plain

 

さっそくペイロードを挿入して書き込むと。

 <Script>alert(/script>

 

f:id:ThisIsOne:20211009093113p:plain

 

メッセージを書き込むエリアが表示されなくなって。

当ページだけは、何度アクセスしても表示されず。

 

f:id:ThisIsOne:20211009091235p:plain

 

Port Swiggerへバグレポートを提出することに。

 

f:id:ThisIsOne:20211009090251p:plain

 

Best regards, (^^ゞ