アルゴリズム弱太郎

Twitter @01futabato10

Feature Squeezing: Detecting Adversarial Examples in Deep Neural Networks

こんにちは、futabatoです。

今回は、Feature Squeezing: Detecting Adversarial Examples in Deep Neural Networks (Xu, Weilin, David Evans, and Yanjun Qi., 2017)の論文に目を通したので、論文メモとしてBlogに残しておきます。

arxiv.org


Feature Squeezing: Detecting Adversarial Examples in Deep Neural Networks

論文の概要

  • 著者: Xu, Weilin, David Evans, and Yanjun Qi.
  • 年度: 2017
  • 論文URL: https://arxiv.org/abs/1704.01155
  • 被引用数: 1167
  • タグ: Preprocess, Supplementing the Network

本論文の手法に代表されるように、モデルに入力されるデータに対して前処理を行うことで誤分類を防ぐ手法があります。

特徴量の入力空間が不必要に大きく、その広大さがAdversarial Examples構築する機会を提供してしまっているということに注目して、不要な入力を絞り込む(squeezing)することで攻撃者が利用できる自由度を減らそうとしています。

Fig. 1: Feature-squeezing framework for detecting adversarial examples.

Abstract

Although deep neural networks (DNNs) have achieved great success in many tasks, they can often be fooled by adversarial examples that are generated by adding small but purposeful distortions to natural examples. Previous studies to defend against adversarial examples mostly focused on refining the DNN models, but have either shown limited success or required expensive computation. We propose a new strategy, feature squeezing, that can be used to harden DNN models by detecting adversarial examples. Feature squeezing reduces the search space available to an adversary by coalescing samples that correspond to many different feature vectors in the original space into a single sample. By comparing a DNN model’s prediction on the original input with that on squeezed inputs, feature squeezing detects adversarial examples with high accuracy and few false positives. This paper explores two feature squeezing methods: reducing the color bit depth of each pixel and spatial smoothing. These simple strategies are inexpensive and complementary to other defenses, and can be combined in a joint detection framework to achieve high detection rates against state-of-the-art attacks.

既存研究と比べてどこが凄い?

これまでの研究ではDNNモデルを改良することが中心で、その効果は限定的で、しかも高度な計算が必要になるものだった。本論文で紹介されているfeature squeezingは比較的安価で他の防御手法と補完的であるため、他の検出フレームワークと組み合わせて多層防御することで最先端の攻撃に対して高い検出率を達成できた。

技術や手法のキモはどこ?

Color Depth

Fig. 2: Image examples with bit depth reduction.

上記Figure 2を見ると、中断と下段の画像は、8bitの原画像と4bitに絞った画像の違いを見極めるのは困難である一方で、上段の画像と違い4bit以下の色深度では人間が観察可能な損失が発生している。これは1channelあたりのbit数が同じでもRGBの3channel分の情報が失われるからである。

とはいえ、8bitから4bitへの圧縮は、Legitimate Examplesに対する精度を維持しながら、多くの敵対的な例を軽減するのに十分強力であることがわかった。

Spatial Smoothing

画像処理で登場する空間フィルタリングは画像のノイズ低減のために広く使われている手法である。

以下のようなフィルタ処理を適用することで、エッジを維持しつつ画像全体(あるいは局所的に)ぼかすことができる。

  • Gaussian Filter
  • Median Filter
  • Averaging Filter
  • binary Filter

Fig. 3: Examples of adversarial attacks and feature squeezing methods extracted from the MNIST dataset.

どうやって有効だと検証した?

静的な敵対的入力に複数のsqueezersを組み合わせた検出器を利用して、MNISTで98%、CIFAR-10で85%、ImageNetで85%の検出率を出した。False Positive rateも5%程度と低く、Adversarial Examplesをうまく検出できていることがわかった。

TABLE 5: Summary results for the best joint detectors.

TABLE 6: Comparison with MagNet

議論はある?

色深度と平滑化以外にも、JPEG画像の品質や次元削減に着目してAdversarial Examplesを弾く研究がされている。

legitimate inputsに対する潜在的な損失が評価されていなかったり、固有顔による画像復元は、顔認識タスクにおける敵対的摂動を緩和する有用な手法である可能性があるため、まだ開拓の余地が見受けられる。

次に読むべき論文は?

MagNetというAdversarial Examplesに対する防御手法が存在するらしい。MagNetパイプラインはend-to-endで微分可能なため、trivial white-box adversaryには脆弱らしい。

arxiv.org


最後までご覧いただきありがとうございました。

Adversarial T-shirt! Evading Person Detectors in A Physical World

こんにちは、futabatoです。

今回は、Adversarial T-shirt! Evading Person Detectors in A Physical World (Xu, Kaidi, et al., 2020)の論文に目を通したので、論文メモとしてBlogに残しておきます。

arxiv.org


Adversarial T-shirt! Evading Person Detectors in A Physical World

論文の概要


移動する人物の姿勢変化により非剛体変形する可能性がある場合でも、人物検出器を回避できるRobustなAdversarial Exampleとして、Adversarial Tシャツを提案しています。

Figure 7: The person who wear our adversarial T-shirt generate by TPS in three complex scenes: office, parking lot and crossroad.

Adversarial TシャツはREDBUBBLEというオンラインストアで購入することができます。意外に着て外を歩けそうです。

www.redbubble.com

Abstract

It is known that deep neural networks (DNNs) are vulnerable to adversarial attacks. The so-called physical adversarial examples deceive DNN-based decisionmakers by attaching adversarial patches to real objects. However, most of the existing works on physical adversarial attacks focus on static objects such as glass frames, stop signs and images attached to cardboard. In this work, we proposed adversarial T-shirts, a robust physical adversarial example for evading person detectors even if it could undergo non-rigid deformation due to a moving person's pose changes. To the best of our knowledge, this is the first work that models the effect of deformation for designing physical adversarial examples with respect to-rigid objects such as T-shirts. We show that the proposed method achieves74% and 57% attack success rates in the digital and physical worlds respectively against YOLOv2. In contrast, the state-of-the-art physical attack method to fool a person detector only achieves 18% attack success rate. Furthermore, by leveraging min-max optimization, we extend our method to the ensemble attack setting against two object detectors YOLO-v2 and Faster R-CNN simultaneously.

既存研究と比べてどこがすごい?

Tシャツのような非剛体物体に対して変形の影響をモデル化した初めての研究。

Thys, Simen, Wiebe Van Ranst, and Toon Goedemé.)ではTシャツにAdversarial パッチを貼ってかつ人が動いてしまうと効果が無かった。

技術や手法のキモはどこ?

  • TPS(Thin Plate Spline)マッピングを用いて人間の体の動きによって生じる布の変形をモデル化している。
    Affine変換では対応しきれないらしい。
  • 以下の流れに沿ってAdversarial Tシャツを生成する。
    最適化手順はbackpropagationを通じた閉ループとして実行される。
    1. 市松模様柄のTシャツを着ている人物を撮影したビデオフレームを学習させる
    2. 様々な変形を考慮した不変的な摂動をTシャツに適用する
    3. Person Classに属する最大のBounding Boxの確率を最小化する

Figure 3: Overview of the pipeline to generate adversarial T-shirts.

  • 複数の物体検出器を騙すためのmin-max最適化手法 ensemble攻撃はmin-max最適化の観点から設計することができて、平均を取るアプローチよりもはるかに高いASRをもたらす。

どうやって有効だと検証した?

YOLOv2とFaster R-CNNがターゲット。
提案アルゴリズムの収束挙動とASR(Attack Success Rate)をデジタル世界と物理世界の両方において検証した。

ASR(Attack Success Rate)はテストフレームの総数に対する攻撃に成功したテストフレームの比率で与えられる。

議論はある?

  • YOLOv2よりFaster R-CNNのほうがややRobustだった。いわゆるsingle detectorはすべての場合において脆弱だったと言っているが、今のYOLOv5やYOLOXのようなアルゴリズムでも同じことが言える?(速さと精度のトレードオフはもうほぼないと思ってるので)

    github.com

    github.com

次に読むべき論文は?


最後までご覧いただきありがとうございました。

Physical Adversarial Examples for Object Detectors

こんにちは、futabatoです。

今回は、Physical Adversarial Examples for Object Detectors (Song, Dawn, et al., 2018 )の論文に目を通したので、論文メモとしてBlogに残しておきます。

arxiv.org


Physical Adversarial Examples for Object Detectors

論文の概要

  • 著者: Song, Dawn, et al.
  • 年度: 2018
  • 論文URL: https://arxiv.org/abs/1807.07769
  • 被引用数: 261
  • タグ: Physical, Object Detection, Targeted Attack, Disappearance Attack

画像認識モデルを騙す摂動は物理的なオブジェクトによっても作り出すことができます。

自動運転に代表されるようなリアルワールドで使用されるディープラーニングモデルにこういったセキュリティのリスクがあるのはとても興味深いですよね。

Figure 7: Sample frames from our attack videos after being processed by YOLO v2. In the majority of frames, the detector fails to recognize the Stop sign.

Abstract

Deep neural networks (DNNs) are vulnerable to adversarial examples-maliciously crafted inputs that cause DNNs to make incorrect predictions. Recent work has shown that these attacks generalize to the physical domain, to create perturbations on physical objects that fool image classifiers under a variety of real-world conditions. Such attacks pose a risk to deep learning models used in safety-critical cyber-physical systems. In this work, we extend physical attacks to more challenging object detection models, a broader class of deep learning algorithms widely used to detect and label multiple objects within a scene. Improving upon a previous physical attack on image classifiers, we create perturbed physical objects that are either ignored or mislabeled by object detection models. We implement a Disappearance Attack, in which we cause a Stop sign to "disappear" according to the detector-either by covering thesign with an adversarial Stop sign poster, or by adding adversarial stickers onto the sign. In a video recorded in a controlled lab environment, the state-of-the-art YOLOv2 detector failed to recognize these adversarial Stop signs in over 85% of the video frames. In an outdoor experiment, YOLO was fooled by the poster and sticker attacks in 72.5% and 63.5% of the video frames respectively. We also use Faster R-CNN, a different object detection model, to demonstrate the transferability of our adversarial perturbations. The created poster perturbation is able to fool Faster R-CNN in 85.9% of the video frames in a controlled lab environment, and 40.2% of the video frames in an outdoor environment. Finally, we present preliminary results with a new Creation Attack, where in innocuous physical stickers fool a model into detecting nonexistent objects.

既存研究と比べてどこが凄い?

物理的な物体が検出器から無視されるDisappearance Attackを提案し、実際にYOLOv2から物体の位置を特定できなくさせたり、存在しない物体を検出できなくさせるようなperturbed physical objectsを作成した。

技術や手法のキモはどこ?

RP2アルゴリズム (Eykholt et al.) の位置・回転不変性を拡張して、比較的制御された実験環境において物体検出器を攻撃する方法を示した。

物体検出器は画像分類器に比べて出力構造がrichなため物体検出器に適した新しいLossを提案している。

Disappearance Attack Loss

ゴール: 物体の位置を特定できないようにする。

物体検出器が物体として認識するかどうかのしきい値(よくconfidence score thresholdとして設定するやつ)を下回ればよいので、物体がシーンに入ったときの最大のconfidence scoreを算出する損失関数の値を、しきい値を下回るまで直接最小化してやればよい。

Creation Attack Loss

ゴール: 存在しない物体を認識するようにモデルを騙す。

任意の既存のシーンに追加することができる物理的なステッカーを作成することで騙す。 複合損失関数を使って、まず追加された物体(ステッカー)の位置を検出させて、ターゲットとなるClassに誤分類させるようにする。

Figure 5: Patch created by the Creation Attack, aimed at fooling YOLO v2 into detecting nonexistent Stop signs.

Figure 6: Sample frame from our creation attack video after being processed by YOLO v2. The scene includes 4 adversarial stickers reliably recognized as Stop signs.

どうやって有効だと検証した?

YOLOv2を使って屋内実験室と屋外環境において攻撃を評価した。 屋内と屋外に分けて実験を行った。屋内の方が成功率が高い。 Faster R-CNNでも有効性を確認した。

議論はある?

  • 今回は物体の位置を特定できない、または存在しない物体を検出するような攻撃をしたが、他にもいくつかの攻撃案がある。
    • Bounding Boxを維持しつつ、Classを変える(これはTargeted Attackと同様)
    • 人間には無意味に見える物体ではあるが、物体検出器だけが認識できる物体の生成
  • 画像分類や物体検出器に対する攻撃をどうセマンティックセグメンテーションに応用させるかが課題。
  • 今回は単一の物体検出器を騙すことしかやっていない。End2Endなパイプラインを侵害できるかどうかがリアルワールドへの影響度合のポイントになる。一般的には大多数の予測に基づいて制御を行うので、いくつかのフレームで騙せればよいわけではなく、大多数のフレームを騙す必要がある。

次に読むべき論文は?

Tシャツを着て騙す手法。これもYOLOv2だった気がするが、これはYOLOv2がターゲットにされていたのはたまたま時期が重なっただけなのか騙しやすいなのかがあるのか気になる。

arxiv.org


最後までご覧いただきありがとうございました。

The Limitations of Deep Learning in Adversarial Settings

こんにちは、futabatoです。

今回は、The Limitations of Deep Learning in Adversarial Settings(Papernot, Nicolas, et al., 2016)の論文に目を通したので、論文メモとしてBlogに残しておきます。

arxiv.org


The Limitations of Deep Learning in Adversarial Settings

論文の概要

JSMAです。
Untargeted Attackに代表されるFGSMと同様に、Targeted Attackの攻撃方法についてイメージが湧きやすく、代表的な攻撃手法となっています。

Fig. 1: Adversarial sample generation - Distortion is added to input samples to force the DNN to output adversary selected classification

Abstract

Deep learning takes advantage of large datasets and computationally efficient training algorithms to outperform other approaches at various machine learning tasks. However, imperfections in the training phase of deep neural networks make them vulnerable to adversarial samples: inputs crafted by adversaries with the intent of causing deep neural networks to misclassify. In this work, we formalize the space of adversaries against deep neural networks (DNNs) and introduce a novel class of algorithms to craft adversarial samples based on a precise understanding of the mapping between inputs and outputs of DNNs. In an application to computer vision, we show that our algorithms can reliably produce samples correctly classified by human subjects but misclassified in specific targets by a DNN with a 97% adversarial success rate while only modifying on average 4.02% of the input features per sample. We then evaluate the vulnerability of different sample classes to adversarial perturbations by defining a hardness measure. Finally, we describe preliminary work outlining defenses against adversarial samples by defining a predictive measure of distance between a benign input and a target classification.

既存研究と比べてどこがすごい?

特定のクラスに誤分類させるために探索空間を効率的に探索することができる。

技術や手法のキモはどこ?

JSMAはWhitebox型の攻撃手法で、saliency(顕著性) mapに焦点を当てている。
入力された特徴量のスコアに対して偏微分を行うことでsaliency mapを得る。
得られたsaliency mapの最大となる要素をとって、その要素にノイズを加える。
(saliency mapの要素には偏微分されたものが入るので、大きいほどtargetクラスに向けて効率よく移動できるイメージ)
ノイズを加えた結果、targetクラスに誤分類されることができたら終了。

Forward Derivative of a Deep Neural Network

Algorithm 1 Crafting adversarial samples

どうやって有効だと検証した?

MNISTの画像に対して平均4.02%(784pixel中32pixel)程pixelにノイズを付与することで97.10%の成功率でAdversarial Examplesを生成できた。

議論はある?

DNNをAdversarial Attackから防御するにはAdversarial Exampleを検出することと学習段階を改善することの2つに分けられる。
Adversarial Exampleの検出は(当時)まだ未解決の問題になっている。

近傍画素の各ペアの二乗差の総和がbenign(良性) samplesよりadversarial samplesの方が常に高かった。

次に読むべき論文は?

AutoEncoderは異常検知にも使われているイメージなので、Adversarial Examplesの検出にも応用できそう。
PuVAE: A Variational Autoencoder to Purify Adversarial Examples


最後までご覧いただきありがとうございました。

Explaining and Harnessing Adversarial Examples

こんにちは、futabatoです。

今回は、Explaining and Harnessing Adversarial Examples (Goodfellow, Ian J., Jonathon Shlens, and Christian Szegedy., 2015)の論文に目を通したので、論文メモとしてBlogに残しておきます。

https://arxiv.org/abs/1412.6572arxiv.org


Explaining and Harnessing Adversarial Examples

論文の概要

  • 著者: Goodfellow, Ian J., Jonathon Shlens, and Christian Szegedy.
  • 年度: 2015
  • 論文URL: https://arxiv.org/abs/1412.6572
  • 被引用数: 11296
  • タグ: Whitebox, Untargeted

Adversarial Example系でおそらく一番有名な論文です。
FGSMを使ってパンダをテナガザルに誤分類させてるみんな大好きなやつですね。

Figure 1: A demonstration of fast adversarial example generation applied to GoogLeNet (Szegedy et al., 2014a) on ImageNet.

Abstract

Several machine learning models, including neural networks, consistently misclassify adversarial examples---inputs formed by applying small but intentionally worst-case perturbations to examples from the dataset, such that the perturbed input results in the model outputting an incorrect answer with high confidence. Early attempts at explaining this phenomenon focused on nonlinearity and overfitting. We argue instead that the primary cause of neural networks' vulnerability to adversarial perturbation is their linear nature. This explanation is supported by new quantitative results while giving the first explanation of the most intriguing fact about them: their generalization across architectures and training sets. Moreover, this view yields a simple and fast method of generating adversarial examples. Using this approach to provide examples for adversarial training, we reduce the test set error of a maxout network on the MNIST dataset.

既存研究と比べてどこがすごい?

Neural Networkが敵対的な摂動に脆弱なのはその線形性にあると仮説を立て、十分高次元な空間における線形性がAdversarial Exampleを引き起こす可能性があると主張した。

技術や手法のキモはどこ?

本論文で提案されているFGSM(Fast Gradient Signed Method)は、Nueral Networkの勾配を利用してAdversarial Exampleを生成するアルゴリズムになっている。

FGSMはWhiteBox型の攻撃となっている。Adversarial Attackを行う際には、モデルそのものは修正できないため、学習済みモデルのパラメータθは定数として扱えるので入力データxを調整することでLossを大きくすることができる。画像の各PixelがLossにどれくらい関与しているかを求めてそれに応じて摂動を追加していく。勾配は backpropagationを使って簡単に算出することができる。

どうやって有効だと検証した?

FGSMを適用した例として、ImageNetで学習したGoogLeNetにAdversarial Attackすることでパンダからテナガザルへ誤分類できていることを示している。

MNISTを使って、エラー率を敵対的学習なしの0.94%から敵対的学習(FGSMに基づく正則化)ありの0.84%に減少させることができ、汎化性能の向上が確認できた。

議論はある?

  • 特定の点ではなく、摂動の方向が最も重要である。
  • 線形モデルは敵対的な摂動に対抗する能力がない。隠れ層がある構造だけが敵対的摂動に耐えられるように訓練すべきである。
  • RBF(Radial Basis Function)ネットワークはAdversarial Examplesに対して耐性がある。
  • アンサンブルはAdversarial Examplesに対して耐性がない。

次に読むべき論文は?

  • 最近Twitterに流れてきたSmooth Adversarial Trainingにて、ReLUのnon-smoothな性質がAdversarial Trainingを阻害していると主張しているそうなので気になっている。
  • FGSMに少し手を加えるとBlackbox型の攻撃手法としても使えるらしい。どの論文にそれが書かれているのかわからないが、見つけたら読んでおきたい。

最後までご覧いただきありがとうございました。

脆弱性診断ツール「Himawari」の試み

この記事はIPFactory Advent Calendar 2021 25日目の記事です。

qiita.com


こんにちは、futabatoです。
先日、MBSD Cybersecurity Challenges 2021の最終審査会を終えました。

setten.sgec.or.jp

y0d3n, okodayon, l7elVliと出場したチーム「After_the_CM」は第三位でした。

5カ月間の振り返りはこちらの記事で行っています。

01futabato10.hateblo.jp

チームメンバーのy0d3nの記事も併せてご覧ください。

y0d3n.hatenablog.com

今回のコンテストの課題は「脆弱性診断ツールの開発」でした。
私たちはGo製の脆弱性診断ツール「Himawari」を開発しました。

f:id:futabato0110:20211225193751p:plain
Himapher(チームに合意を取らず勝手に名付けました)

コンテストが終わっても開発を続けたい想いから、先日リポジトリを公開しました。

github.com

一からWebセキュリティを学んで脆弱性診断ツールの開発を行った私たちの5カ月間の軌跡を、機能説明書のようなものとしてHimawariというプロダクトの面から世に残しておきます。

1. 概要

HimawariはWebアプリケーションに存在する脆弱性を自動的に発見し、ユーザに診断結果を報告することができる脆弱性診断ツールです。 HimawariはBlack Box型の診断ツールなので、Himawariを使った診断において、診断するWebアプリケーションの実装に関する詳細な知識やソースコードは不要です。診断に必要なのは診断対象となるWebアプリケーションのURLです。HimawariにURLを入力すれば診断対象のWebアプリケーションに対して自動的にクローリングを行ってサイトマップを構築した上で診断を行うことができます。
診断結果は脆弱性の解説とその解決策を含む、検証に使われた一連のデータをまとめたレポートを出力してユーザに提示します。
HimawariはWeb User Interface(WebUI)を用意しています。WebUIを利用することでユーザが行う一連の操作をWebブラウザを介して簡単に行うことができます。

図1に示すように、Himawariは大きくCrawlerとScannerとReportの3つのモジュールによって構成されています。

f:id:futabato0110:20211225194954p:plain
図1. Himawariの処理フロー図

順に解説していきますが、まずはHimawariの真髄である独自のデータ構造を持つSitemapについて解説します。

2. Sitemap

Himawariで診断を行うためには、診断対象のWebアプリケーションのSitemapが必要になります。理想的なSitemapには、診断するにあたって必要になるページと攻撃に必要なパラメータ等の情報が漏れなく格納されている状態です。
どこにどのようなリクエストを送信すればよいのかという問題を解決するのがSitemapになります。

SitemapはJSONというデータの形式で管理されており、ファイルとしてDownload / Uploadが可能です。
診断を実施したくない部分があればSitemapの一部を切り取る、特定のページに診断を実施したければSitemapの一部を残してすべて切り取る、後に説明するCrawlerで収集ができないようなページはユーザがJSONを記述することで診断が可能になる等、Sitemapの編集により任意のSitemapが構築できます。

2.1. サイトマップのデータ構造

サイトマップのデータ構造についての説明をしていきます。 Himawariはサイトマップ木構造で保持します。そのデータ構造をここでは「JsonNode」と呼び、以下のように定義します。

type JsonNode struct {
    Path     string        `json:"path"`
    Messages []JsonMessage `json:"messages"`
    Children []JsonNode    `json:"children"`
    URL      string        `json:"url"`
}
 
type JsonMessage struct {
    URL        string     `json:"url"`
    Time       float64    `json:"time"`
    Referer    string     `json:"referer"`
    GetParams  url.Values `json:"getParams"`
    PostParams url.Values `json:"postParams"`
}

構造体JsonNodePath, Messages, Children, URLの4つのフィールドを持ちます。
Messagesフィールドは構造体JsonMessage型の配列です。
構造体JsonMessageURL, Time, Referer, GetParams, PostParamsの5つのフィールドを持ちます。
構造体JsonMessageTimeフィールドはレスポンスタイムを指します。これを通常時のレスポンスタイムとしてTime Basedな検出アプローチで利用します。

ここで、図2で示すようないくつかのPHPファイルで構成される簡単なWebアプリケーションを考えてみます。

f:id:futabato0110:20211225195143p:plain
図2. 簡単なwebアプリケーションのそれぞれの主なソースコード

このアプリケーションの構造を木構造で表現しようとすれば、以下の図3のようになるかと思います。

f:id:futabato0110:20211225195407p:plain
図3. 図2で考えたWebアプリケーションを木構造で表現した図

上記の定義に従ってWebアプリケーションの情報を格納したSitemapのJSONPlantUMLで表現してみると、以下の図4のようになっています。

Webアプリケーションの情報を定義通りに格納することで、たしかにWebアプリケーションの構造を木構造で表現することができており、後に説明するScannerでは、このSitemapから情報を取り出してリクエストを生成・送信していきます。

f:id:futabato0110:20211225204914p:plain
図4. 図2で考えたWebアプリケーションをHimawariでクロールさせた 結果のサイトマップをPlantUMLで表現したもの

2.2 診断時間の概算

Sitemapの情報から診断を実施するパラメータの数が割り出せるため、Sitemapが構築された段階で診断時間の概算が可能です。

3. Crawl機能

1つ目のモジュールはCrawl機能です。

SitemapはJSONファイルを一から手書きで構築することができますが、HimawariではSitemapを自動で構築できるCrawlerを用意しています。
HimawariのCrawl機能を使えば、診断対象のWebアプリケーションのURLを入力するだけでHTML内のハイパーリンクを辿って自動的にクロールを行い、診断するWebアプリケーションに関連する同一オリジン内の全てのページと、攻撃に必要な全てのパラメータ等の情報がサイトマップに保存されていきます。

3.1. アルゴリズム

HimawariのCrawl機能のアルゴリズムについて説明していきます。

HimawariのCrawlerは、入力されたURLから辿って発見したページのHTMLの内容を見てサイトマップを順次構築していきます。
ハイパーリンクやフォーム等の情報から次のページを追いかけて、その次のページをすべて確認し終えると、追いかけに行った地点に戻ってきてそのページの下に進むことを繰り返します。
これは単純なWebアプリケーションであれば深さ優先探索の振舞いをすることになります。Webアプリケーションの規模が大きくなって複雑な遷移をする場合であっても、このアルゴリズムは一貫したアプローチでクロールを遂行できます。
先ほどの簡単なWebアプリケーションの場合でCrawlを行うアルゴリズムをトレースしてみると、以下の図5のようになります。

f:id:futabato0110:20211225210624p:plain
図5. 図2で考えたWebアプリケーションに対するHimawariの クローリングアルゴリズムをトレースした様子

このようなアルゴリズムでHTMLに存在する内容をすべて確認し終えるとCrawlは終了となり、Sitemapが構築されたことになります。

3.2. 診断のスコープ

Himawariではスコープの基準として、オリジンを採用しています。
オリジンとは、Webコンテンツにアクセスするために使われるURLのスキーム(プロトコル)、ホスト名(ドメイン)、ポートによって定義されます。 それら3つが全て一致した場合のみCrawl及びScan(診断)の対象となり、オリジン外の範囲に影響を与えることを防ぎます。

3.3. ユーザ入力による最適な入力値のセット

後述するWebUIのCrawlの設定画面ではユーザ入力による最適な入力値のセットができるようになっています。
入力されるデータはKey, Valueの形で入力を受け付けています。

例えばemail等の指定された形式の入力しか受け付けていない入力欄が存在した場合にCrawlの設定画面にて「key: email, value: himawari@email.com」を入力してCrawlを始めると、その「email=himawari@email.com」という情報を利用してCrawlを行います。 この機能によって、フォーム等の画面で入力される値に間違いがあるためにその先のページをCrawlすることができないことを避けることができます。

3.4. JSONのImport / Exportによるサイトマップの編集

2.Sitemapにて言及はされていますが、HimawariのサイトマップJSONで管理をしていて、Scanを開始する前にサイトマップJSONをダウンロードして編集することができます。

JSONの編集によってHimawariのアルゴリズムでCrawlすることができなかったページの追加及び、データ削除や問い合わせ機能等といった診断を実施してほしくないページの削除を実現できます。
ユーザの手でJSONを編集できるということは漏れのないサイトマップが構築ができるということになります。
これにより、事実上すべてのページをクロールできている状態でScanに進むことができます。

4. Scan機能

2つ目のモジュールはScan機能です。
構築されたSitemapをもとにして診断を実施します。

Himawariが現在検出できる脆弱性は以下の8種類です。

  • Cross-Site Scripting(Reflected・Stored)
  • SQL Injection
  • Cross-Site Request Forgery
  • OS Command Injection
  • Directory Traversal
  • Open Redirect
  • HTTP Header Injection
  • Directory Listing

以下では各種脆弱性検出アルゴリズムについて解説していきます。

4.1. アルゴリズム

4.1.1. 概要

Scan機能を主として担うScan関数は、サイトマップJSONを参照し、JsonNodeのループを回してi番目のJsonNodeを引数に各脆弱性診断アルゴリズムの関数を呼び出します。
JsonNodeChildrenを持つ場合は再帰的にScan関数を呼び出します。 auditというprefixが付いた各種脆弱性検出アルゴリズムの関数の中では、JsonMessageのループを回してj番目のJsonMessageからリクエストを生成し、攻撃を行います。このアルゴリズムサイトマップで構築されたJSONを元にした深さ優先探索アルゴリズムでJsonMessageを取り出し、診断を順に行います。

f:id:futabato0110:20211225212919p:plain
図6. Scanを担う関数のCall Graph

4.1.2. 攻撃用リクエストの生成

JsonMessageに保持されている情報をもとに、Payloadと呼ばれる悪意のあるコマンドやバグを引き起こさせるための文字列を付与してリクエストを作成し、送信します。 Payloadを挿入している箇所は、JsonMessageGETパラメータ, POSTパラメータ, User-Agent, Referer, Path, Cookieです。

4.1.3. 検出アプローチ

Himawariの脆弱性判断機能は大きく、応答時間比較と文字列の部分一致の2パターンに分かれます。

4.1.3.1 応答時間比較

応答時間比較は、攻撃のリクエストに対するレスポンスタイムがJsonMessageTimeフィールドに保持されているCrawl時のレスポンスタイムと比較して一定時間(Payloadで設定した時間 - 誤差)以上遅くなっていた場合に脆弱性と判断するアルゴリズムです。

4.1.3.2 文字列の部分一致

文字列の部分一致は、攻撃のリクエストに対するレスポンスに特定の文字列が存在するかどうかを判断するアルゴリズムです。
比較の対象がレスポンスのヘッダかボディのどちらになるのかは検出したい脆弱性によって異なります。

4.2. 各種脆弱性診断アルゴリズム

4.2.1. Cross-Site Scripting

Cross-Site Scripting(XSS)は、攻撃者によって仕掛けられた悪意のあるスクリプトをサイトに訪れたユーザのブラウザ上で実行させることができる脆弱性です。

XSS脆弱性の検出には、Landmarkと名づけられた目印となる文字列をPayloadに含めます。
デフォルトであればScan開始時のLandmarkの数字は0で、genLandmark関数を呼び出すごとにLandmarkの数字がインクリメントされていくようになっています。

Wapitiを始めとする多くの診断ツールはLandmarkの数字をインクリメントさせるのではなく、乱数を生成するようにしています。
私たちはLandmark番号が衝突することを恐れて絶対に被らないインクリメントの方式で実装しましたが、結果的には実装が若干複雑になってしまいました。

4.2.2.1. Reflected Cross-Site Scripting

Reflected(反射型) XSSはPayloadを仕込んだリクエストに対するレスポンスボディの中でPayloadがscriptタグとして解釈されているかどうかを判断しています。
単なる文字列の部分一致ではtextareaタグの中に出力されている状況等に対応できないが故にFalse Positiveとなってしまう問題がありましたが、この問題はgoqueryというgo言語の外部packageを利用して、scriptタグを解釈することにより解決されました。
scriptタグとして解釈されているものの中で、注入したPayloadの文字列が存在すればReflected XSS脆弱性が存在すると判断しています。

4.2.2.2. Stored Cross-Site Scripting

Stored(持続型) XSS脆弱性が存在すると攻撃者によって書き込まれた悪意のあるスクリプトがサイトのDB等に保存されます。攻撃用のスクリプトがDBに保存されているとWebアプリケーションにアクセスするたびにスクリプトが実行されてしまうのがReflected XSSとの違いです。

Stored XSSの検出のためには、まずメッセージを格納できる候補となるページの探索から始まります。
j番目のJsonMessageに対するXSS攻撃のタイミングでPayloadの代わりにLandmarkを載せたリクエストを送信します。
リクエストを送信後、すべてのJsonMessageに対してリクエスト送信・レスポンス取得を行い、レスポンスボディにj番目のJsonMessageで送信したLandmarkが含まれていれば、Candidateと名づけたStored XSSの攻撃対象となるページとして記録します。
CandidateJsonMessage型のポインタ配列で定義しています。

j番目のJsonMessageが1つ以上Candidateを保持していれば、Stored XSSの検出アルゴリズムへ移行します。
Stored XSSの検出アルゴリズムの中で改めてLandmarkを発行して、PayloadにLandmarkを含ませた上でCandidateにリクエスト送信・レスポンスを取得します。
レスポンスボディの中でscriptタグとして解釈されているものの中で、注入したPayloadの文字列が存在すればStored XSS脆弱性が存在すると判断しています。

Candidateが1つも無い場合はStored XSSの検出アルゴリズムではなくReflected XSSの検出アルゴリズムへ移行するため、Stored XSSが検出される箇所でReflected XSSが検出されることはないようになっています。

f:id:futabato0110:20211225212945p:plain
図7. Stored XSS脆弱性検出アルゴリズムフローチャート

4.2.2. SQL Injection

SQL Injectionは、DBと連携したWebアプリケーションでSQLの呼び出し方に不備があると発生する脆弱性です。

SQL Injectionの検出は2段階になっています。
1段階目では文字列の部分一致を利用したError BasedなアプローチのSQL Injection攻撃、
2段階目は応答時間比較を利用したTime BasedなアプローチのBlind SQL Injection攻撃です。

4.2.2.1. SQL Injection (Error Based)

SQL Injection検査の1段階目のフェーズでは、SQLがエラーを起こすような値をPayloadとしてリクエストを送り、レスポンスボディにある特定のエラーメッセージが含まれているかどうかを判断します。
この時点で特定のエラーメッセージがレスポンスボディに含まれていればSQL Injectionの脆弱性が存在すると判断し、2段階目の検査は行わずに次のJsonMessageの検査を行います。
エラーベースのPayloadで一通り検査が終了して脆弱性が発見できなかった場合は、Blind SQL Injectionの攻撃を実施します。

4.2.2.2. Blind SQL Injection (Time Based)

SQL Injection検査の2段階目のフェーズでは、SQLのエラーメッセージを含む出力結果がHTML上に表示されない場合であっても、レスポンスの差異から脆弱性が存在するかどうかを判断します。

具体的な攻撃手法としてはsleepという、返されるメッセージのタイミングを遅らせるコマンドを使ったPayloadを含むリクエストを送り、レスポンスタイムが一定の時間(Payloadで指定したsleepの時間 - 誤差)以上であれば、SQL Injectionの脆弱性が存在すると判断するアルゴリズムです。

SQLのエラーメッセージ直接表示されていなくてもSQL Injectionの脆弱性を検出できる場合があるため、Time BasedのBlind SQL Injectionの攻撃手法は有効ですが、返されるメッセージのタイミングを遅らせることが基本なので、他の脆弱性検出アルゴリズムに比べて検査にかかる時間が長くなってしまいます。そのため、SQL Injection検出アルゴリズムは2段階に分けて、Error Basedの攻撃手法で検出できるものに関しては検出してしまうというアプローチを取っています。

4.2.3. Cross-Site Request Forgery

Cross-Site Request Forgery(CSRF)は、ログインした利用者の意図したリクエストであるかの確認ができていないと発生する脆弱性で、CSRF脆弱性が存在するとアカウントの不正利用、アカウント内情報の改ざんなどが発生する可能性があります。

CSRFの検出は診断対象のWebアプリケーションがPOSTリクエストを受け取った際にRefererのチェックを行っているかどうかのみを確認しています。
POSTパラメータを持つJsonMessageに対して、Refererを改ざんしてリクエストを送信したレスポンスのステータスコードが400番台500番台である場合にCSRF対策がされていると判断しています。

しかし、これだけでは偽陽性が多くなってしまう可能性が十分にあります。商品検索のようなどのユーザがリクエストを送信しても問題がない機能に関しては、脆弱性になり得ない場合があります。
4.2.2.2.で説明したStored XSS用のCandidateJsonMessageに用意されているので、同様にCSRF用のCandidateを用意して重要な処理が行われる部分をユーザにOnにしてもらうことが現在案に上がっています。

4.2.4. OS Command injection

OS Command Injectionは、シェルの不適切な呼び出し方をしている場合に意図しないOSコマンドの実行が可能になる脆弱性です。

OS Command Injection検出アルゴリズム応答時間比較のアプローチを採用しています。
Blind SQL Injectionの検出手法同様、sleepという返されるメッセージのタイミングを遅らせるコマンドを使ったPayloadを含むリクエストを送り、レスポンスタイムが一定の時間(Payloadで指定したsleepの時間 - 誤差)以上であれば、OS Command Injectionの脆弱性が存在すると判断するアルゴリズムです。

4.2.5. Directory Traversal

Directory Traversalは、攻撃者によって制限されたディレクトリ外の任意のファイルに対して、閲覧をはじめとする開発者の意図しない処理が行える脆弱性です。

文字列の部分一致で脆弱性が存在するかどうかを判断していくため、Unix系OSとWindowsOSのどのコンピュータにでも統一的なメッセージが表示される/etc/passwdwin.iniのファイルパスを指定するPayloadに採用して判断できるようにしてあります。

4.2.6. Open Redirect

Open Redirectは、攻撃者が任意の外部ドメインにリダイレクトさせるURLを作成できる脆弱性です。

Open Redirect脆弱性の検出アルゴリズムはPayloadを載せたリクエストを送り、返ってきたレスポンスのLocationヘッダがhttp://example.comを指していればとOpen Redirectの脆弱性が存在すると判断するアルゴリズムです。文字列の部分一致を用いてLocationヘッダの判断をしています。

4.2.7. HTTP Header Injection

HTTP Header Injectionは、レスポンスヘッダの出力処理に問題がある場合に発生する脆弱性です。

改行コードを含むPayloadとHimawariによってセットされたCookie値をリクエストヘッダに載せたリクエストを送り、レスポンスのSet-CookieヘッダにHimawariがセットしたCookie値が存在するかどうかを文字列の部分一致で判断しています。

4.2.8. Directory Listing

Directory Listingとは、Webサーバのディレクトリ内容をリスト表示するものです。
特定のWebサイトディレクトリにインデックスファイルがない場合にディレクトリの内容を表示するWebサーバーの機能がオンになっていることで、Directory Listingが発生します。
Directory Listingそれ自体は脆弱性とは言い難いですが、この機能がオンになっていることによって意図せずファイルが公開され、攻撃者が攻撃を仕掛けるのに十分な情報を与えてしまう可能性があります。

Directory Listingの検出アプローチは文字列の部分一致です。
Directory Listingが存在するページでは、ApacheでもNginxでも同じメッセージがレスポンスボディに表示されるので、その文字列が存在しているかどうかで判断しています。

JsonNodeが持つURLごとに、URLの末尾に/を付与する場合と付与しない場合の2つのURLに対してリクエストを送り、レスポンスボディに判断基準となるという文字列が含まれているかどうかを判定しています。

4.3. 非破壊な診断

Himawariは非破壊な診断を心がけてScan部分のアルゴリズムを実装したうえで、Payloadを選定しています。
危険なリクエストを送信したが故に診断対象のWebアプリケーションが壊れてしまうことがない攻撃手法を採用しています。

5. Report機能

3つ目のモジュールはReport機能です。 Himawariが診断を行った結果をわかりやすい形で利用者にレポートを表示します。

レポートには、検出した脆弱性の名前, 脆弱性の重要度(severity), CWE番号, 発見した脆弱性の件数, 脆弱性の説明, 脆弱性を防ぐための必須対策, 保険的対策を載せています。
レポートは脆弱性ごとにまとめられており、各脆弱性の情報として、脆弱性を検出した際に利用したPayload, 脆弱性が存在すると判断をした証拠となるEvidence, 脆弱性を検出したParameter, 脆弱性を検出したページのURL, 脆弱性を検出した際にHimawariからWebサーバへのリクエストおよびサーバからのレスポンスの情報が含まれています。

5.1. WebUI上でのレポート提示

診断中に検出された脆弱性は随時WebUIのレポート画面にて表示されます。 以下の図8に示すように見やすい形でユーザに提示します。

f:id:futabato0110:20211225220155p:plain
図8. WebUI上で確認できるレポートの様子

5.2. レポートのファイル出力

診断終了後、WebUIで表示されるレポートと同様の内容をファイルとして出力し、ダウンロードすることができます。
コンテストの関係でファイル形式をMarkdownにしていましたが、より見やすい形があればそのファイル出力にも対応していきたいと思います。

6. その他機能

6.1. Web User Interface

HimawariはNuxt.jsで実装されたシンプルなWebUIを搭載しています。

URLを入力してCrawl、Scan、レポート確認までのフローをWebUIで完結できるようになっています。
3.4で述べたサイトマップJSONのImport / ExportはWebUIを通じて行います。サイトマップJSONがアップロードされた場合はCrawlは行わずにScanの設定画面へ遷移します。

Scan中に検出された脆弱性は随時WebUIのReport画面に反映されます。
診断終了後のレポートはWebUIで確認できる他、Markdownファイルとしてレポートのファイル出力機能を備えています。

6.2.リクエストとレスポンスのログの保存

WebUI上ではすべてのログを表示しませんが、HimawariはCrawl及びScanで発生したすべてのリクエストとレスポンスのログを保存しています。
診断中に想定外のエラーが発生して中断してしまった場合等はログが大いに役立ちます。

6.3. ログイン機能

HimawariのCrawl設定画面とScan設定画面ではログイン情報の入力ができます。

例えば、「username=hoge, password=fuga」 という情報でアカウントを作成している場合は、ログイン情報入力欄に「username=hoge, password=fuga」のログイン情報とリクエストメソッドを指定してCrawlやScanを実行すればそのusernamepasswordを利用してログインを試行します。

Crawl中やScan中にセッションが切れてしまうことを防ぐために、図9で示すようにリクエストを送信するごとにログインを試みるようにしています。この方法であれば、リクエストの数が単純に倍になってしまいますが、セッションが切れないことを優先した結果です。

f:id:futabato0110:20211225221103p:plain
図9. ログイン試行のイメージ図

6.4. Scanのオプション選択

HimawariはQuick ScanモードとFull Scanモードの2種類の診断方法を用意しています。

もとは以下の理由から分けていましたが、計算量の大幅な改良により、Quick ScanとFull Scanの診断時間の差分はほとんど無くなっています。

Stored XSS 検出アルゴリズムの中で実行されるStored XSSの候補となるページをすべてのJsonMessageから探す処理にとても時間がかかってしまうため、主にStored XSSの検出を行わないようにするためにQuick Scanモードを用意しています。

6.5. Landmarkの開始番号の指定

診断対象のWebアプリケーションは環境をリセットすることが難しい場合があります。

Scan中に想定外のエラーが発生して診断が中断されてしまった場合に診断をやり直すことができるようLandmarkの開始番号を指定できるようになっています。この機能はデフォルトでは隠されていて、デバッグオプションとして用意しています。

Landmarkのデフォルトの初期値は0になっているので、そのままスキャンをやり直すとlandmarkを利用しているXSS等の脆弱性の検出を正しく行うことができません。
6.2. で説明したログファイルを確認することでLandmark番号がどこまで使われたかを知ることができるので、未使用のLandmark開始番号を指定して再スキャンを実行できます。

7. 精度評価

Himawariの有効性を示すには、精度を算出して他の診断ツールとあらゆる角度から比較を行う必要があります。

7.1. 評価指標

以下で定義される混合行列を用いて評価関数を作成し、精度を算出しました。

  • TP (True Positive): 診断ツールが検出した脆弱性が、実際に脆弱性が存在したもの。
  • FP (False Positive): 診断ツールが検出した脆弱性が、実際には脆弱性が存在していなかったもの。
  • FN (False Negative): 実際には脆弱性が存在していたが、診断ツールが検出しなかったもの。
  • TN (True Negative): 実際には脆弱性が存在しない箇所を、診断ツールが検出しなかったもの。

以上4つの値から3つの評価指標を算出します。

 Accuracy = \frac{(TP + TN)}{(TP + FP + FN + TN)}

 Precision = \frac{(TP)}{(TP + FP)}

 Recall = \frac{(TP)}{(TP + FN)}

これらの評価指標を用いてベンチマークによる比較を行うことで精度を数値として算出することはできます。

しかし、これらの指標を用いて診断ツールの性能比較を行うことは少し注意が必要だと考えております。1つ1つの脆弱性には重みがあると考えており、検出の難しさや脆弱性の重要度、現実世界での脆弱性の発生しやすさ等によって変わってくる隠れたパラメータが存在していると考えられます。つまり、一概に精度を算出だけして「この診断ツールはRecallが高いから他の診断ツールよりFNが少なくて優秀だ」等と判断することは難しいと考えています。

まずは精度比較のための診断対象の選定には注意が必要で、さらに算出された精度を確認した上でどのような場合にFPやFNが発生してしまったのかの考察をする必要があると考えられます。

また、診断にかかる時間も比較材料の1つであると考えられます。
同じような精度であれば診断時間は短いほうが好ましいですが、FP・FNが多く発生してしまうようではいけません。検出しようとする脆弱性の種類の数やPayloadのバリエーションの豊富さによって診断時間は伸びてしまうので、診断時間と精度は正の相関の傾向が見られる可能性はありますが、無駄なアルゴリズムのせいで診断時間が伸びてしまっている場合も考えれるので、診断にかかる時間のみが診断ツールの優位性を獲得するとは考えにくいです。

7.2 診断対象の脆弱なWebアプリケーション

診断ツールの精度を比較するためには診断対象となるWebアプリケーションが必要となります。
私たちのチームは以下のいくつかの脆弱なWebアプリケーションを利用して脆弱性診断の概念検証(PoC)及び精度比較を行いました。

診断対象のWebアプリケーションにはまず箱庭BadStoreが候補に上がりました。
箱庭BadStoreをHimawariを使ってクロールを実行したところHTMLが崩れている箇所が見つかり、正常にクロールができずにエラーを出して(当時は)終了してしまいました。脆弱性診断の入門用教材としてよく使われる箱庭BadStoreですが、HTMLが崩れている箇所はWebブラウザが辻褄が合うように解釈していることが判明しました。

どのようにHTMLが崩れていたのかは以下の記事で解説されています。

y0d3n.hatenablog.com

こちらの検証は9月に行ったもので診断ができませんでしたが、現在は該当部分のJSONを手書きすれば良いので、診断は可能です。

診断対象となるWebアプリケーションは私たちのチームで実装したSunflowerと、OWASP Broken Web Applicationsから提供されているものを利用しました。

7.2.1 Sunflower

診断練習用のWebアプリケーションは世にたくさんありますが、Himawariが検出したい8個の脆弱性がすべて存在するかつ簡単にPoCを行える脆弱なWebアプリケーション環境が無かったため、私たちのチームでSunflowerと名づけたPoC用の脆弱なWebアプリケーションを構築しました。

github.com

Sunflowerでは、以下の8種類の脆弱性を作りこんでいます。

  • Cross-Site Scripting(Reflected・Stored)
  • SQL Injection
  • Cross-Site Request Forgery
  • OS Command Injection
  • Directory Traversal
  • Open Redirect
  • HTTP Header Injection
  • Directory Listing

SunflowerはHimawariで実装されている脆弱性検出アルゴリズムの全ての脆弱性を網羅できるようになっています。
Sunflower構築後、手動でPoCを行って脆弱性が存在することを確認したうえで、Himawariで実装されている脆弱性検出アルゴリズムのPoCを行いました。

7.2.2. WAVSEP

WAVSEPは、Webアプリケーションに対する診断ツールの品質や精度の評価を支援するために設計された脆弱なWebアプリケーションです。いくつかの論文ではWAVSEPを利用して診断ツールの評価を実施していました。

Evaluation of open source web vulnerability scanners and their techniques used to find SQL injection and cross-site scripting vulnerabilities

https://www.researchgate.net/publication/322558701_Performance_evaluation_of_web_application_security_scanners_for_prevention_and_protection_against_vulnerabilities

WAVSEPでは、以下の6種類の脆弱性に加えて、各脆弱性のFalse Positive用のテストケースが用意されています。

  • SQL Injection
  • Reflected XSS
  • Local File Inclusion
  • Remote File Inclusion
  • Open Redirect
  • Backup

Himawariが対応しているXSS, SQL Injection, Open Redirectの3つの脆弱性の評価を行いました。 (Local File InclusionはDirectory Traversalとは違うものだと認識してたので検査を実施しませんでした。)

WAVSEPでは脆弱性ごとにページが用意されていますが、意図的にそのページへリンクやフォームを用意していないため、WAVSEPのトップのURLを診断ツールに入力して診断してもどのページも発見できないまま終了してしまします。
ページ単位での診断を行うため、診断時間の比較は行わないこととします。

7.2.3 DVWAとGruyere

SunflowerやWAVSEPでは、アンカー要素でしかハイパーリンクを用意していないため、Crawl機能の性能を十分に確認できない問題があります。Crawl機能の性能はScan機能の精度に直結してくると考えているので、SunflowerやWAVSEP以外の脆弱なWebアプリケーションを用意する必要がありました。

そこで採用したのは、DVWA(Damn Vulnerable Web Application)Gruyereです。
DVWAの公式ドキュメントを参照すると、DVWAには以下の脆弱性を作りこんでいると記載があります。

  • Brute Force
  • Command Execution
  • CSRF
  • File Inclusion
  • SQL Injection
  • Insecure File Upload
  • Cross Site Scripting(XSS
  • Easter eggs

Gruyereの公式ドキュメントを参照すると、Gruyereには以下の脆弱性を作りこんでいると記載があります。

  • Cross-Site Scripting (XSS)
  • Client-State Manipulation
  • Cross-Site Request Forgery (XSRF)
  • Cross Site Script Inclusion (XSSI)
  • Path Traversal
  • Denial of Service
  • Code Execution
  • Configuration Vulnerabilities
  • AJAX vulnerabilities
  • Other Vulnerabilities

また、DVWAとGruyereにはオリジン外へのリンクが沢山存在しています。
3.2. 診断のスコープ で述べた通りのオリジン外へのCrawl, Scanは実施しないようにできているかを確認する目的で実験を行いました。

8. 結果と考察

8.1. Sunflower

Sunflowerに備えられている脆弱性CSRF脆弱性のFPを除いて、すべて検出することができています。 CSRF脆弱性のFP分を覗けば、Accuracyは1です。

8.2 WAVSEP

WAVSEPの診断結果をsectoolmarketのフォーマットで算出すると以下の表のようになりました。

WIVIT SQLi RXSS LFI RFI Redirect Backup
Accuracy × 0.988 0.228 × × 0.5 ×
False Positives × 0.3 0 × × 0 ×

脆弱性ごとに精度を算出すると、以下の表のようになりました。

Accuracy Precision Recall
Reflected XSS 0.288 0.525 0.28
FP-Reflected XSS 1 1 -
SQL Injection 0.982 1 0.982
FP-SQL Injection 0.7 0.7 -
Open Redirect 0.5 1 0.5
FP-Open Redirect 1 1 -

sectoolmarketの最終更新日が2016年なので比較対象とするのは好ましくありませんが、当時の診断ツールと比べるとOSS診断ツールとある程度(Reflected XSS以外は)肩を並べられる精度が出ています。

f:id:futabato0110:20211225225917p:plain
図10. sectoolmarketに精度算出されているOSS診断ツールの一部 (最終更新日: 2016年9月16日)

HimawariがFPやFNを出してしまったケースに関しては全て考察を行いました。

SQL Injectionで唯一FNを出してしまったケースでは、HimawariのPayloadを載せたPayload生成部分に問題がありました。Himawariでは、Crawl時に挿入したデータにPayloadを付け加える形でリクエストを生成しています。今回のテストケースでは、Payload以前に文字列が含まれていれば攻撃が刺さらないようになっていたためFNが発生しました。
FNを出してしまいましたが、Sitemapの編集によって検出は可能です。パラメータのValueを空文字にすれば空文字列にPayloadを付け加える形でリクエストを生成するので検出が可能になりますが、それを診断対象に向けたチューニングと言ってしまって良いものなのかは怪しいところです。
また、今回FNを出してしまったケース(SQL Injection - Test Cases: Case04-InjectionInUpdate-String-CommandInjection-WithDifferent200Responses.jsp)は差分処理でのアプローチをして脆弱性を判断するものなので、特にチューニングすることなく応答時間比較のアプローチで他のすべてを検出できているのは上出来だと考えられます。

SQL InjectionでFPを出してしまったケースでは、全てError Based Injectionの検出手法でした。False Positive用のテストケースは、SQLのError文をもとに脆弱性が存在するかを判断しているアルゴリズムでは偽陽性が出てしまうようなテストケースになっていたためFPが発生しました。
Reflected XSSでFNを出してしまったケースは、もともとアラートのあるページやVBScriptを使ったテストケースため検出することができませんでした。後述しますが、HimawariはJavaScriptへの対応を行っていないため、JavaScriptを扱ったテストケースはすべてFNになってしまいます。
JavaScriptベースのリダイレクトには対応していないため、Open Redirectの脆弱性検出のAccuracyは50%となっています。HTMLに存在するRedirectは追えているため、JavaScriptベースでないOpen Redirectは100%の精度で検出できています。

8.3. DVWAとGruyere

DVWAには2.3. 診断のスコープ で述べた通りのオリジン外へのCrawl、Scanが実施しないようにできているかを確認する目的で実験を行いました。
DVWAは34分9秒、Gruyereは8分22秒で診断を終えました。DVWAに存在する脆弱性の全体像が不明なため、自分達で検証ではTPとFPの検証のみとしました。

以下の図11に示しているのが、DVWAをCrawlをして得られたスコープ外のURLの一覧です。

f:id:futabato0110:20211225233524p:plain
図11. WebUIで表示されているOutofScopeの一覧

また、DVWAにはパスワード変更ページが存在します。Scanの際にパスワード変更を行ってしまうとログインが不可能になったまま診断を終えてしまいます。3.4. で説明したHimawariの機能であるSitemapの編集によりパスワード変更ページを回避してScanを終えることができました。

8.4 自動診断ツールのメリット

Webアプリケーションの開発者がWebセキュリティに疎い場合は、診断を行おうとしてもまず何から始めればよいのかわからないと考えています。HimawariのようなBlack Box型の診断ツールを利用することで、簡単にかつ効率的な診断ができると自負しています。

しかし、8.3.であったWAVSEPのあるテストケースのように、診断対象の仕様を把握していないと検出が難しい場合が存在することは、脆弱性診断ツールを利用する人は頭に入れておくべきです。

9. Himawariの限界

Himawariは素早く自動的にWebアプリケーションへ診断を行うことが可能ですが、Himawariにはいくつかの限界があります。
Himawariは脆弱性を検出しなかった場合に脆弱性が存在しないこと証明することはできません。FP・FNが発生していることから、現在のHimawariの能力と限界の線引きをはっきりとさせておくことは今後の発展のためにも重要だと考えています。

9.1. JavaScriptへの対応

HimawariはJavaScriptを一切考慮していません。 そのため、location.href=’./hoge’のようなリダイレクトには対応できず、診断対象サイトの仕様次第ではCrawlが全く出来ない可能性があります。

9.2. CSRF脆弱性検出アルゴリズム

アンチCSRFトークンの実装がされているWebアプリケーションに対するCSRF脆弱性検出は実装できていません。 4.2.3. で説明したとおり、CSRFの検出方法はレスポンスのステータスコードに依存しているため、トークンで対策されているにも関わらずCSRFが検出される可能性があります。

9.2. Open Redirect脆弱性検出アルゴリズム

以下の2点がそろっている場合は、Open Redirectの脆弱性とはなり得ません。

  • もともと外部に遷移する仕様である。
  • Webアプリケーションのユーザにとって外部ドメインに遷移することが容易にわかる。

ユーザにとって意図しないリダイレクトがOpen Redirectの脆弱性であるとすると、診断ツールが「意図しない」を汲み取ってOpen Redirectの脆弱性ではないと指摘することはかなり難しいと考えられます。

また、9.1. JavaScriptへの対応で述べた通り、HimawariのアルゴリズムJavaScriptを考慮していないため、JavaScriptによるオープンリダイレクトの検出アルゴリズムは実装できていません。

9.3. DOM Based XSS検出アルゴリズム

9.1. JavaScriptへの対応で述べた通り、HimawariのアルゴリズムJavaScriptを考慮していないため、DOM Based XSSと呼ばれる脆弱性の検出アルゴリズムは実装できていません。

9.4 診断するWebアプリケーションの実装に依存してしまう部分

HimawariはBlack Box型の診断ツールです。BlackBox型とは、リクエストとレスポンスから脆弱性が存在するかどうかを判断する方法です。
White Box型の診断ツールと違い、実際のソースコードから全体の構造やロジックを確認することはできないため、診断対象の明確な仕様書がなければ隅々までテストを行うことは難しい場合が存在します。
Black Box型の診断ツールはWebアプリケーションに関わっていない第三者でも、情報セキュリティに詳しくない人にでも非常に簡単に診断を行うことができますが、全ての脆弱性を検出することはとても難しいということをユーザは頭に入れて診断ツールを利用すべきです。

9.5. 差分処理

Himawariの脆弱性診断アプローチは、4.1.3. で述べたように応答時間比較と文字列の部分一致の2種類です。世の中に存在する他の脆弱性診断ツールでは、テキストの差分処理を検出アプローチとして採用しているものもありますが、Himawariはテキストの差分処理のアプローチを採用していません。

テキストの差分処理は評価基準が適切でないと、FP・FNが大量に発生してしまうことが予想させたため、検出アプローチとして採用しませんでした。差分処理を諦めたため、8.2. WAVSEP で述べたとおり、検出が難しい場面が発生してしまっています。

10. おわりに

最後までご覧いただきありがとうございます。 ここまでの話を踏まえたうえで、最終審査会で発表したスライドをご覧いただくとより伝わるかなと思います。

speakerdeck.com

私たちの愛着のあるHimawariを今後もコツコツと開発を続けていきたいです。


最後までご覧いただきありがとうございました。

この記事はIPFactory Advent Calendar 2021 25日目の記事です。

qiita.com

昨日24日はfutabatoによる「Machine Learning for Web Vulnerability Detection: The Case of Cross-Site Request Forgery」でした。

01futabato10.hateblo.jp

この記事をもってIPFactory Advent Calendar 2021を完走することができました。
2022年もどうぞよろしくお願いいたします。よいお年をお迎えください。

Machine Learning for Web Vulnerability Detection: The Case of Cross-Site Request Forgery

この記事はIPFactory Advent Calendar 24日目の記事です。

qiita.com


こんにちは、futabatoです。

先日の記事で言及していたCSRF脆弱性検出アプローチに機械学習を取り入れている論文を見つけていたので、論文メモとしてBlogに残しておきます。
まだまだWebセキュリティの用語をきちんと理解できていない部分があるので、ところどころ論文に書いてあることを直訳したが故に変な表現になっている部分があるかと思います。

論文の概要

Calzavara, Stefano, et al. "Machine learning for web vulnerability detection: the case of cross-site request forgery." IEEE Security & Privacy 18.3 (2020): 8-16.

ieeexplore.ieee.org

この論文では、Cross-Site Request Forgery(CSRF)の脆弱性BlackBoxで検出する手法を解説しています。
機械学習によってCSRF脆弱性Blackboxで検出できるようになったかというとそうではなく、実際に脆弱性が存在しているのかを判断しているのは分類後の処理です。
機械学習が解いているタスクは「HTTPリクエストをセキュリティ上センシティブなリクエストであるかどうかの分類する問題」で、一般的なWebアプリケーションから収集したHTTPリクエストから教師あり学習で分類器を作成しています。 上記の方法論はBlackBox型のCSRF検出ツールMitchに取り入れられています。

ieeexplore.ieee.org

Abstract

In this article, we propose a methodology to leverage Machine Learning (ML) for the detection of web application vulnerabilities. Web applications are particularly challenging to analyse, due to their diversity and the widespread adoption of custom programming practices. ML is thus very helpful for web application security: it can take advantage of manually labeled data to bring the human understanding of the web application semantics into automated analysis tools. We use our methodology in the design of Mitch, the first ML solution for the black-box detection of Cross-Site Request Forgery (CSRF) vulnerabilities. Mitch allowed us to identify 35 new CSRFs on 20 major websites and 3 new CSRFs on production software.

Example: Cross-Site Request Forgery (CSRF)

CSRFはユーザーが認証されている脆弱なWebアプリケーションに対して、攻撃者が制御している不要なHTTPリクエストを送信させるものです。
CSRFの特徴は悪意のあるリクエストがユーザのブラウザを経由してWebアプリケーションに送られるため、ユーザが実際に操作した正規のリクエストと見分けがつかないことです。

f:id:futabato0110:20211224222207p:plain
Cross-site request forgery (example)

Preventing CSRF

CSRF脆弱性を対策するためには、いわゆる"重要な処理"の前に正規のリクエストであるかどうかを確認する必要があります。

ユーザーとのやりとりを増やしてもUXが悪くならないのであれば、再認証を強制したり、ワンタイムパスワードCAPTCHAを利用することで、Cross-Siteのリクエストが気づかれずに通ってしまうのを防ぐことができます。

また、Samesite属性というものがあり、Cross-Siteのリクエストでのクッキーの付与を防ぐことができるようです。

developer.mozilla.org

Samesite cookiesCSRFの根本的な原因を解決するものなので、新規のWebアプリケーションには強く推奨されます。
しかしながらこの防御策はまだ普及しておらず、既存のWebアプリケーションは通常、以下のいずれかの技術を用いてCross-Siteのリクエストをフィルタリングしているようです。

  1. RefererOriginなどの標準的なHTTPリクエストヘッダの値をチェックし、リクエストを発信しているページを確認する。
  2. X-Requested-Withのような、Cross-Siteからは設定できないカスタムHTTPリクエストヘッダの存在を確認する。
  3. センシティブなフォームに設定した、予測不可能なアンチCSRFトークンの存在を確認する。

最近の論文では、これらの異なるソリューションの長所と短所が議論されています。

上記3つの方法には、セキュリティチェックを慎重かつ細かく配置しなければならないという制限があります。

例えば、UXを損なうことなく完全な保護を実現するためには、アンチCSRFtokenをセキュリティ上重要なHTTPリクエストのすべてに、そしてそれ以外には付けないようにする必要があります。
結局のところ、CSRF 対策の最適な配置を見つけることが一般的に Web 開発者にとって困難な作業です。

最近のWebアプリケーションの開発フレームワークでは自動化されたサポートが提供されていますが、それでもCSRF脆弱性は日常的に発見されています。

ieeexplore.ieee.org

このため、効果的なCSRF検出ツールの必要性が高まっています。
しかし、どのHTTPリクエストが実際にセキュリティ的にセンシティブであるかどうかを機械的に検出する方法がない場合には、どうすればCSRF検出のための自動化されたツールを提供することができるでしょうか。

(ここで機械学習が使えます!って言いたいんだと思います)

Method

この論文が提示した方法論は、次のように要約できます。

  1. 教師あり学習により、HTTPリクエスト、HTTPレスポンス、Cookieなどの選択されたWebのオブジェクトを、Webアプリケーションのセマンティクスに基づいて分類する分類器を自動的に学習させます。 CSRFを検出する場合であれば、分類器はセキュリティ上センシティブなHTTPリクエストを識別するために利用されます。

  2. 分類器によって返される可能性のある各クラスについて、脆弱性検出のためのヒューリスティックを定義します。 例えば、センシティブでないリクエストはCSRFのために悪用されることはないので、直ちに非脆弱性としてマークすることができます。

  3. 例えばWebブラウザ拡張機能として提供された分類器を使って、対象となる各Webオブジェクトで実行する適切な脆弱性検出ヒューリスティックを選択します。

Mitch

Mitchは、CSRF脆弱性Blackboxで検出するツールです。 これまでのセクションで紹介した方法論に基づいて設計されており、Webブラウザ拡張機能としてGitHubに公開されています。

(論文が言うにはBlackBoxで検出できる初のツールらしい)

github.com

Overview

Mitchは、セキュリティテストが行われるWebサイトで、2つのテストアカウント(ここではAliceとBobとします)を所持していることを前提にしています。
これは、攻撃者(Alice)が自分のセッションで機密性の高いHTTPリクエストを検査し、被害者(Bob)のWebブラウザでそのようなリクエストを偽造するというシナリオをシミュレートするために使用します。
偽造されたリクエストにAliceのセッションに関連する情報が含まれていた場合には、Bobに対するCSRF攻撃ができない可能性があるため、2つのテストアカウントを持つことはツールの精度を高めるために重要です。
例えば、WebサイトがアンチCSRFトークンを使って適切にCSRF脆弱性を防御している場合、AliceのリクエストはBobのセッションで拒否されます。 CSRFを検出するために2つのテストアカウントを使用することは、すでに以前の研究で提唱されており、テスト戦略の一部となっています。

Mitchのアーキテクチャを以下の図に示します。

f:id:futabato0110:20211224231108p:plain
Architecture of Mitch

Mitchをブラウザにインストールした後、セキュリティテスト担当者は、まずAliceとしてWebサイトを閲覧します。
分類器によって機密性が高いと検出されたすべての HTTP リクエストについて、Mitch は対応する HTTP レスポンスのコンテンツを保存します。

Webサイトの閲覧後は、Mitchは収集したセンシティブなHTTPリクエストを使用して拡張オリジン(?, extension origin)に新しいHTML要素を生成して再現できるようにします。

次に、セキュリティテストの担当者はBobとしてWeb サイトで認証を行い、Mitch は生成されたHTMLを利用して、検出されたセンシティブなリクエストをCross-Siteから自動的に再現し、CSRF 攻撃をシミュレートします。

最後に、AliceとBobで収集したレスポンスを比較します。
Bobが受け取ったレスポンスがAliceが受け取ったものと一致した場合、AliceがBobのセッションに対して有効なリクエストを偽造できたことを意味します。

Challenges

現実的にはいくつか課題があるようです。
課題とその解決策についても言及されています。

  1. HTTPレスポンスの変化
    HTTPレスポンスが動的に生成され、同じ操作を複数回行った場合でも現実的には異なるレスポンスが返ってくる可能性があります。
    そのため、Mitchでは非類似HTTPレスポンス(dissimilar HTTP responses)という概念を構築しています。
    一般にHTTPレスポンスの非類似性は、失敗を表すStatus CodeやContent-Typeが異なることなどにより、類似性よりもはるかに容易に確認できるます(例えば、401 Unauthorizedや403 Forbiddenは、不正アクセスを表すもの)。
    Bobの応答がAliceの応答と異なると、AliceのリクエストがBobのセッ ションで失敗した可能性が高く、それはCSRF防御機構の存在を示しているかもしれません。

  2. セッション状態の変化
    WebサイトにおけるAliceとBobの状態は異なるかもしれないので、Bobが受け取ったレスポンスをAliceが受け取ったものと照合することは、CSRF脆弱性を検出する不適切な方法かもしれません。
    例えば、Bobはファイルfooへのアクセス権を持っていないので、機密性の高い操作を実行できないかもしれませんが、ファイルbarをターゲットにした場合、CSRF攻撃は機能可能性はあります。
    Bobが受け取ったレスポンスとAliceが受け取ったレスポンスを比較したとき、Mitchはその違いをBobのリクエストがCSRF防御機構の利用によってAliceのリクエストとは異なる結果になったという決定的な証拠としてすぐには考えません。むしろ、AliceとBobのセッションの状態の違いによって異なる結果が生じる可能性があるため、MitchはAliceのオリジナルのリクエストを新しいAliceのセッションで再現します。Aliceが受け取った新しいレスポンスがオリジナルのものと異なる場合に、リクエストの処理にセッション依存の情報が必要であると考えられ、CSRF対策トークンが採用されている可能性があると判断しています。

  3. 分類エラー
    非常に正確な分類器であっても、センシティブでないリクエストを誤ってセンシティブなものとして分類してしまう可能性はあります。
    この場合、CSRF脆弱性は存在せず、AliceとBobのセッションで一致するレスポンスがあっても、警告を発するべきではないはずです。
    分類器によって生成された誤検出の可能性を判断するために、MitchはAliceのオリジナルリクエストを、最初にWebサイトで認証することなく、セッション外で再現します。取得したレスポンスが元のレスポンスと異なる場合に、要求された操作の実行には認証されたコンテキストが必要ということからCSRFが存在する潜在的な可能性があることが確認されます。

Machine Learning Classifier

ここにはMitchが利用している分類器についての言及がありますが、各特徴量についての定義が書いてあるだけで特にメモとしても残しておく必要のないものなので、割愛します。


独自に構築されたデータセットから分類器を作成する話は以下の論文に書かれていそうなので、次回の記事にしたいと思います。

ieeexplore.ieee.org

若干歯切れの悪い形にはなってしまっていますが、これ以降特に論文メモにしておく情報がないのでここで終えたいと思います。
最後までご覧いただきありがとうございました。


この記事はIPFactory Advent Calendar 24日目の記事です。

qiita.com

昨日23日はdaiki0508くんによる「BackDoorAPK解析してみた」でした。

daiki0508.hatenablog.com

明日25日はfutabatoによる『脆弱性診断ツール「Himawari」の試み』です。お楽しみに。

01futabato10.hateblo.jp