Response queue poisoning via H2.TE request smugglingをやってみた

Hello there, ('ω')ノ

フロントエンドサーバがHTTP/2リクエストの長さがあいまいな場合でも。

ダウングレードするため、リクエストの密輸に対して脆弱らしく。

まずは、アクセスして。

リクエストをリピータへ。

リピータを使用してHTTP/2リクエストを送信するには。

オーバーライドを許可するオプションを有効にして。

インスペクターを使用してプロトコルをHTTP/2に変更する必要があって。

チャンクエンコーディングを使用して。

HTTP/2リクエストの本文で任意のプレフィックスを密輸すると。

送信するリクエストが１秒おきに404レスポンスを受信することを確認できて。

バックエンドが密輸されたプレフィックスに後続のリクエストを。

追加したことが確認できて。

Content-Lengthのオプションを解除して。

次は、下記のリクエストで、完全なリクエストがバックエンドサーバに密輸して。

リクエストのパスが存在しないエンドポイントを指しているので。

リクエストが常に404応答を受け取ることを意味して。

応答キューをポイズニングすると、正常にキャプチャした他のユーザの応答を。

簡単に認識できるようになるので。

応答キューをポイズニングする要求を送信して。

自身の要求に対する404応答を受け取って。

その他の応答コードは、管理者ユーザ向けの応答を。

正常にキャプチャしたことを示して。

管理者の新しいログイン後のセッションCookieを含む302応答を。

キャプチャするまで、このプロセスを繰り返して。

セッションCookieをコピーして。

　sB6ehEIKcaiBZMtNXEmvkMpW3xkCn9vj

セッションCookieを使用して次のリクエストを送信して。

管理パネルを含む200の応答を受信するまで、要求を繰り返し送信して。

管理パネルで、Carlosを削除すると。

クリアできた。

Best regards, (^^ゞ

How I was able to verify any contact number for my account?を訳してみた

Hello there, ('ω')ノ

アカウントの連絡先番号を確認するにはどうすればよいかを。

脆弱性：

　OTPバイパス

　2FAバイパス

記事：

　https://parasarora06.medium.com/how-i-was-able-to-verify-any-contact-number-for-my-account-57c939dab202

目標：

　OTPを提供せずに電話番号を追加して確認することで。

ウェブサイト名：

　Redacted.com

redacted.comのサブドメイン、つまりsubdomain.redacted.comを列挙していて。

これについて登録してアカウントを作成して。

このポータルで何かを見つけるのに苦労したものの。

電話番号を追加する機能があり、さっそく追加して。

自分の電話番号を提供してOTPを確認して、応答を傍受して分析することに。

Try1：

　自分の電話番号を他の電話番号に編集すると、OTPが送信されたものの。

　正しいOTPを提供しないことにしたため、応答の操作を開始して失敗したので。

　正しいOTPと無効なOTPの応答を比較することに。

　違いは応答コードとJSONメッセージにあって。

　不正なOTP応答コード：

　　400

　失敗したJSONメッセージ：

　　{“verificationCode”:[{“Code”:”invalid.code”}]}

バイパス方法：

　応答コードを204(NO CONTENT)に変更して。

　これは、サーバが要求を正常に実行して。

　応答ペイロード本文で送信する追加のコンテンツがないことを意味して。

質問：

　応答コードを204に変更したのはなぜか？

回答：

　自分の番号を有効なOTPに登録したときに応答を分析したところ。

　コードが204で有効な応答があったため。

Best regards, (^^ゞ

別のサイトでBurp SuiteのSequencerをつかって分析してみた

Hello there, ('ω')ノ

今回は、少しやり方をかえて。

まずは、Open browserをクリックして。

起動したブラウザで下記へアクセスして。

　https://demo.testfire.net/

アクセスすると、下記のセッションIDが付与されて。

　JSESSIONID=943CCF04DDA8A8C822FB20D1FB06DDBB

例えば、他のページへ遷移すると。

付与されたセッションIDがリクエストから送信されて。

一旦、ここでSequencerへ送っておくことに。

正常に認識されていることを確認しておいて。

一方、先ほどの履歴をリピータへ。

ここでSendすると別のセッションIDが付与されて。

　JSESSIONID=C4DF3E6045B5CDD90ACDFD698C642B90

再度、Sendすると別のセッションIDが付与されて。

このようにセッションIDが個別に付与されることを確認できて。

　JSESSIONID=CFB54DD0449B98239442B2CC28A46D43

さて、SequencerへもどってStart live captureを実行すると。

分析結果が表示されて。

特に問題はなく。

念のためSave tokensをクリックして保存を。

ちなみに初めにセッションIDは、保存されたトークンファイルには含まれておらず。

Best regards, (^^ゞ

Burp SuiteのSequencerを使って手動でクエリ分析をやってみた

Hello there, ('ω')ノ

ライブのWebアプリケーションなしで。

トークンまたはセッションIDのサンプルだけがあったと仮定して。

それらのランダム性をBurp SuiteのSequencerを使って

クエリ分析または表示したい場合は。

前回、保存したセッションIDを使ってやってみると。

まずは、Manual loadでファイルをloadして。

この際、サンプルは100個以上必要らしく。

Analyze nowをクリックすると。

前回分析した結果のセッションIDを出力したファイルなので。

当然ながら、前回と同様の結果が表示されるわけで。

もし、セッションIDまたはトークンがbase64にバインドされている場合は。

Analysis optionsで、base64-decodeをオンにするだけで。

ちなみにさきほどのbase64でないファイルで試してみると。

結果は、さきほどの結果とは異なるものとなるので。

base64-decodeが機能していると考えられて。

次にさきほどのファイルをBase64にエンコードしたものを作成して。

実際にBase64にエンコードされているファイルで試してみると。

結果は、冒頭に試験した結果と同じなので。

正常に機能していることを確認できて。

Best regards, (^^ゞ

不十分なエントロピーについての診断方法についてかいてみた

Hello there, ('ω')ノ

OWASP TOP10 2021のA2には、暗号化の失敗が挙げられていて。

　https://cwe.mitre.org/data/definitions/1346.html

その中には、不十分なエントロピーがあって。

どのようなものかというと。

まずは、すべてのハッカーは、労力をかけずに使用できるツールが好きなので。

Burp Sequencerを使うことに。

これは、データ項目のサンプルのランダム性の品質を分析するためのツールで。

データ項目は次のとおりで。

　アプリケーションセッション識別子

　CSRFトークン

　パスワードトークンをリセットまたは忘れた

　アプリケーションによって生成された特定の予測不可能な識別子

Burp Sequencerは、セッションIDのランダム性または分散を。

キャプチャするツールで。

文字レベルの分析またはビットレベルの分析など。

いくつかの異なるシナリオでサンプルをテストして。

Burp Sequencerの動作の詳細については下記を。

　https://portswigger.net/burp/documentation/desktop/tools/sequencer/tests

まずは、Burp Suiteは、Intercept is onにしておいてからログインして。

キャプチャされたリクエストを確認すると。

PHPSESSIDがCookieヘッダにあることがわかるので、Send to Sequencerへ。

Sequencerがリクエストを受信するとトークンIDが直接入力されて。

また、別の値を解析したい場合は、Custom locationを選択して。

パラメータ値のみをマーキングして保存すると。

Custom locationに反映されて。

そして、Start live captureをクリックすると分析が始まるので。

今回は、リクエストが10,000を超えたところでResumeして。

Analyze nowをクリックすると。

Ovaerall resultには。

選択したパラメータ値のランダム性の全体的な品質が「excellent」と評価されて。

セッションIDが繰り返されると、ランダム性の品質が「悪い」と見なされたりと。

今回は有効なエントロピーは110bitで。

下記が適切な値で。

　最小値：64bit

　最適値：128bit

Bit-level analysisでの確認もできて。

Save tokensでトークンの保存も。

Best regards, (^^ゞ