インパクトの大きなXSS PoCの模索

侵入テスト担当者なら重大な脆弱性に対して必ずしも素晴らしいPoC（実証概念）があるわけではないことをご存じでしょう。そしてセキュリティ専門家なら脆弱性の重大性を理解するために派手なPoCは必要ないでしょう。

しかしサイバーセキュリティに精通していない相手に調査結果の重要性を伝えようとする場合、明確でわかりやすいプレゼンテーションが何よりも重要です。

ここではWAFで保護された環境におけるXSSのPoCとしてどのようなものが最大のインパクトがあるのかを示すケーススタディを紹介します。

最初にXSSとは何か、あるいはどのように出現するのかがよくわからない場合は、https://www.ultrared.ai/from-simple-xss-to-one-click-account-takeoverに投稿されているEddieのブログ記事をお読みください。とてもわかりやすく説明されています。

最初に自動XSSスキャナーの限界を把握：

あるクライアントのサイトで反射型XSSの兆候が見られました。

検知したのは弊社の自動ツールだったため、手作業でのテストは不要でした。GETリクエストにパラメータ“id”が含まれていることがわかりました。

https://github.com/hahwul/dalfox)– これにより、以下の出力が得られます。

‍

‍

出力のデコーディング中のPoCペイロードは以下です。

これは確認用のアラートがポップアップ表示されるはずです。

しかし検出した脆弱性（そして対応するPoC）の通知をクライアントが受信した際、なぜアラートが表示されないのか？という疑問が生じました。

Big Bad WAF(W00f)のケース：

手作業でPoCをチェックすると、JSコードの起動が確認できません。

このサイトはXSSに対する脆弱性がないということでしょうか？どこで問題が発生したのかを確認しましょう。

もちろん最初のステップは、リクエスト結果として不正なHTMLがサイトに追加されたかどうかを確認することです。

上記のスニペットからもわかるように、“confirm”というワードがコード内に侵入し、“dalfox”クラスの追加に成功しています。驚いたことに“on mouse leave”というワードが消えてしまったようです。

on mouseleaveなどのイベントがなければ、JScodeを実行するためにスクリプトタグを開始しなければならないため、これは重要です。

他のイベント（eg.on error、onloadなど）の入力を試みましたが、同じ結果になりました。イベントを表すワードが削除されるのです。そのため、唯一の方法としてスクリプトタグを使用するしかないようです。

ではペイロードを試してみましょう。

‍

するとここでも何らかの反射が戻されたようでしたが、確認のポップアップウィンドウは表示されませんでした。

そこで古い開発ツールに戻って確認したところ、

何と“script”というワードも消えてしまったようです。誰がこんなことを行っているのかを調べる必要があります。

telnetを使ってサーバーにアクセスすると、AkamaiGHostというサーバーからレスポンスがありました。つまりwww.example.comに何かを送信するたびに、Akamaiが使用している何らかのWAF（Web Application Firewall）が最初に確認してユーザーが提供したすべての入力内容をサニタイズしているのです。

WAFの迂回を何度も試行（そして失敗）：

WAFを迂回する方法は無数にあり、その多くが以下のいずれかのアプローチに分類できます。

●       特殊文字の使用やペイロードの一部または全部のエンコーディングによって、WAFによる悪意のあるペイロードの識別を阻止しようとする方法。

●       WAFにペイロードの処理を行わせるが、特殊文字（‘{‘や‘\’など）を使って内部ロジックを迂回しようとする方法。

これらの方法はいずれも機能しませんでした。WAFの詳細な研究を開始して将来的には迂回する方法を見付けられるかもしれません。あるいは通過できるものを使用することもできます。

専門家としての自負

この時点でJSは実行できないものの、XSSのPoCが機能しているということが重要です。

ブラックリストに含まれていないタグを作成することや、現行のタグをやめることもできます。

サイバーセキュリティの専門家にこの問題を相談する場合は、以下のPoCを見せるだけでよいでしょう。

このPoCでは“XSS”というワードを含むソースを使ったimageタグを作成しました。

しかしもう少し脅威を感じさせるような内容にしたいと思います。

JSコード実行をトリガーさせるイベントが使用できないことが判明していますので、現時点では通常のようなimageタグでは効果がありません。

何度も試行錯誤を繰り返した結果、視覚的に最も違いが出るタグはmarqueeであることがわかりました。

結論

脆弱性のプレゼンテーションではクライアントの視点を理解することが重要です。場合によっては手作業が必要になるかもしれませんが常に賢く戦うことを心がけましょう。

‍