技術者ブログ

クラウド型WAF「Scutum(スキュータム)」の開発者/エンジニアによるブログです。
金床“Kanatoko”をはじめとする株式会社ビットフォレストの技術チームが、“WAFを支える技術”をテーマに幅広く、不定期に更新中!

2017年10月

1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31        
  • お問い合わせはこちら
Scutum開発者/エンジニアによる技術ブログ WAF Tech Blog

OGNLインジェクションのゼロデイ攻撃を想定した防御機能

はじめに

私は以前の「Struts2が危険である理由」というブログ記事において

例えばS2-045については止めることが出来ていました(ゼロデイでも防ぐことが出来ていました)が、S2-046についてはギリギリ、わずか数時間の差で先にScutum側の防御機能のアップデートが間に合いました。これを受けて今後、より力を入れてStruts2のOGNLインジェクションに特化したゼロデイ攻撃を想定した防御機能を開発する予定です
と書きましたが、これを実際に開発し、現在稼働中の全てのScutumのサーバに対してデプロイしました。

個々の脆弱性への対応ではなくOGNLインジェクションを防ぐ

これまでScutumでは、Struts2に脆弱性が見つかった場合、それぞれの(例えばS2-045、S2-046といった)脆弱性に対してHTTPリクエスト内での発生箇所を絞り、シグネチャを作成していくアプローチを中心にしていました。このようなアプローチには大きく2つの利点があります。該当箇所のみシグネチャマッチングを行えばよいのでCPU負荷が少なく済むこと、そして誤検知の可能性をほぼ排除できるような質の高いシグネチャを作りやすいことです。しかし最大の欠点は「脆弱性が公表されてからWAF側の対策を行う必要がある」つまり後追いの防御となってしまうことです。先のエントリにも書いたように最近は攻撃が実際に送られてくるのが非常に早くなっているため、この欠点は時に致命的になる可能性もあると思います。

そこで我々は根本的に考えを変え、「個々のStruts2の脆弱性に対応していく」のではなく、「OGNLインジェクションを防ぐ」アプローチを取ることにしました。Scutumは元々、例えばSQLインジェクションやコマンドインジェクション等について、「HTTPリクエストのどの部分に攻撃文字列が入っている場合でも、検出して止めにいく」という姿勢を持っていました。これは他の多くのWAFも同様だと思います。

そこに、今回OGNLインジェクションも加える形です。例えばS2-045ではContent-Type、そしてS2-046ではアップロードするファイル名の部分が攻撃対象となりましたが、今後さらに別の箇所にOGNLインジェクションの脆弱性が見つかることが予想できます。これに備え、基本的にHTTPリクエストは全体を通じてOGNLインジェクションの検査対象とし、「そのデータがOGNLインジェクションを行っているものかどうか」をデータサイエンスの技術を用いて判別します。このアプローチは単純なシグネチャに比べると多くのCPUリソースを必要としますが、エンジニアリングによって現実的に許可できる範囲の負荷に落とし込むことができれば問題ありません。

WAFはゼロデイ攻撃を止められるのか?

ちょっと横道にそれます。

「WAFはゼロデイ攻撃を止められるの?」という質問を考えてみます。簡単にまとめると、私の回答は「ゼロデイ攻撃を止めることもあるし、止めないこともある。高い確率で止めるのが、良いWAFである」となります。そしてもちろん、同時に誤検知率は低く保つ必要があります。

例えば「あるウェブアプリケーションの特定のパラメータにコマンドインジェクションの脆弱性があり、パッチはまだリリースされていない」とします。これを攻撃するHTTPリクエストが飛んできたら、それはゼロデイ攻撃です。しかし、コマンドインジェクションの脆弱性を攻撃するパターンは多くの場合似通っています。例えばwgetやcurlなどでリモートの攻撃者の管理下のサーバなどからバックドアのスクリプトなどをダウンロードしようとするケースを考えてみましょう。この場合、その部分の文字列を見てWAFがブロックする確率はかなり高いでしょう。となると、このケースではゼロデイ攻撃は止まるわけです。しかしそこで実行されるコマンドがwgetやcurlなどではなく、例えばwcだったらどうでしょうか(wcはもし実行できても攻撃者にとってそれほどのメリットはないので非現実的な例となりますが)。この場合、WAFが「wc」という2文字だけをもってブロックすることはちょっと考えられません。すると、同じ脆弱性に対するゼロデイ攻撃であったとしても、こちらは止まらないわけです。

このようなケースすら止めることを目指すならば、正常通信を学習してそれとかけ離れたものを止めるアノマリ検知などが考えられるかもしれませんが、これは難易度は高いですし、普段から英単語が入ってくるパラメータであれば、やはりwcは止められないでしょう。

さいごに

今回開発したOGNLインジェクション防御機能は上記のような認識に基づいています。「できるだけ高い確率で、今後見つかるかもしれないゼロデイのOGNLインジェクション攻撃を止める」ことを目指しています。現状、Scutum開発チーム内では「なかなか良い出来になった」と評価しており、次のStruts2の脆弱性がいつ見つかるのかドキドキして待っている状態です。また、先日Struts2、OGNLインジェクションなどを中心にインタビューしていただいた記事が日経ITPro(http://itpro.nikkeibp.co.jp/atcl/column/14/346926/051100966/)に掲載されていますので、ご覧いただければ幸いです。