技術者ブログ

おまたせしました

この度、ついにこの記事を完成させることができました。これは私が数年前からずっと書きたいと思っていた、ウェブのアクセスログに対する、機械学習を使った異常検知の実例です。私は事あるごとに(※1)「情報セキュリティ分野でもデータサイエンスの技術は非常に重要だ」と繰り返していますが、この記事の内容はまさにその1つの証となると思います。この記事で示される内容を見れば、「うわ、機械学習、マジでヤバイい(語彙力)んだな...」となるでしょう。以下に心当たりのあるセキュリティエンジニアはぜひ読んで、そして実践してみてください。

• 機械学習に興味はあるものの、どこから手を付ければよいのかイメージがわかない
• 本当にAIやデータサイエンス、機械学習がセキュリティの分野で役に立つのか、確信がもてない
• データサイエンスや機械学習は難しそうだと思っている
• ログ解析において、grepや単純な統計処理よりも、さらに上のレベルに行きたい
• 大量のデータからインテリジェンスを引き出す手法を身につけたい
• AIに大量のログを解析するお仕事をさせて、自分はのんびりしたい
• やたらコア数の多いCPUでマシンを組んでしまったが、実のところ持て余している

今回の異常検知は、セキュリティ×機械学習の入門にぴったりの内容です。これまで、「誰でもアクセスが可能な、ウェブサーバのアクセスログのサンプルデータはないだろうか？」と何度も探していたのですが、意外に見つかりませんでした。今回ついにそれが見つかったので、こうして無事に記事にすることができました。

はじめに

以前「シグネチャ依存型のWAFは避けよう」という記事に詳しく書いたように、WAFの仕事の本質は分類です。

WAFにはファイアウォールという言葉が含まれることから、その仕事には「守る」あるいは「防ぐ」ようなイメージがありますが、実際にはWAFが仕事を行う上で最も重要になるのは、その通信が攻撃なのかどうかを見分けること、つまり「分類」です。分類が終わってしまえば、その結果に応じて通信を許可したり、禁止するだけでよいので、そこには技術的な意味での難しさはありません。

つまりWAFというのは「ソフトウェアが分類を行う場面」であり、いかにしてコンピュータ、ソフトウェアに上手に物事を見極めてもらうのか、分類してもらうのかという点が、よいWAFを実現するために必要な技術のコアになります。

あるHTTPリクエストを見て、「ああ、これは攻撃だよね」と専門家が目で確認してわかる場合。果たしてソフトウェアに同じことをやらせることができるでしょうか。近年急激に進化しているデータサイエンス(AI技術)を用いることで分類性能を上げ、これを実現に近づけていくことが、良いWAFへの道すじになります。

この視点から考えてみる場合、シグネチャ(あるいはルール)というのはデータサイエンスの分類技術の中ではかなり分類が苦手なものであるため、シグネチャをコア技術としてWAFを作るということはとても最適な選択であるとは言えません。

私が上記のブログを発表したところ、「シグネチャは古い」という言説が古くなっていないことが逆に驚きだ、というフィードバックを頂きました。実は私もそう思います。私は2014年の時点でシグネチャの限界をデータサイエンスを学ぶことで突破できることに気づき、このことを他のWAFベンダーや開発者にも知ってほしくてこちらの記事を公表しました。カンファレンス等で旧知の他社のWAF担当者に会った際にも「機械学習やデータサイエンスを使うと、シグネチャ依存型よりも良くなる」という話を繰り返した記憶があります。それから6年が経過し、さらにデータサイエンスに関する情報が手軽に手に入るようになったにも関わらず、シグネチャ依存型のWAFは減るどころか、むしろいくつか増えてしまいました。

この記事では「なぜ、シグネチャ依存型のWAFが減らないのか」についていくつかの理由を挙げてみます。尚、この記事を読む前に下記の記事に目を通して頂けると、内容が伝わりやすいかと思います。

1. シグネチャ依存型のWAFは避けよう(記事1)
2. WAFにおけるシグネチャの功罪(記事2)
3. 大手クラウドのオプション型のWAFの弱点(記事3)

下記はあくまでも私個人の考察に過ぎず、明確なエビデンスが存在しない部分もあります。その前提でお読み頂ければと思います。

はじめに

前々回の記事ではサブクエリを「(select」ではない形で書けるようになったことによってWAFが回避されるケースがあるという例について触れました。今回の記事では、PostgreSQLの特定の関数をSQLインジェクションに使うケースを見ていきます。

はじめに

最近ではIaaSやPaaSを中核とする大手クラウドサービスが、それら以外にも数多くのメニュー、サービスを横並びに展開するようになりました。ここにはCDNやWAFが含まれることもあります。これらのクラウドサービスにおいて、CDNはさておき、WAFについてはあくまでも「オプション」的な立ち位置にあるものが多いようです。今回は個人的にこの「クラウドのオプション型」のWAFについて気になっている点を紹介します。

はじめに

SQLインジェクションという攻撃手法(脆弱性)は10年以上前から基本的な原理は変わっていません。しかし攻撃される対象であるデータベースそのものは少しずつ進化し、新たな機能や文法、関数をサポートしていきます。そのため、SQLインジェクションの脆弱性が存在する場合に、そこから「どのように攻撃して、その結果何ができるか？」という点については、データベースの進化に合わせた変化があります。

WAFは防御対象となるウェブアプリケーションに脆弱性がある前提でSQLインジェクション攻撃を見つけるものであるため、データベースの比較的新しい機能や文法を使われたとしても、きちんと見つけることができるようになっていることが理想的です。

Scutumにおいてもデータベースが比較的最近サポートするようになった文法等に合わせて防御を強化しています。今回はサブクエリを使ったSQLインジェクションを例として紹介します。

はじめに

私は「シグネチャ依存型のWAFは避けよう」という記事(以下、前記事)において、以下の内容を示しました。

• WAFの仕事の本質は「分類」である
• WAFというのは、ソフトウェアが分類を行う場面である
• ソフトウェアが分類する＝AI/データサイエンス分野の技術である
• シグネチャは10年以上前の古い分類技術で性能が低く、2020年の時点で使うべきでない

上記だけ眺めれば、WAFにおいてシグネチャを使っても良い事はなさそうに見えます。しかし実際には、シグネチャ(あるいはルール)だけを使っている「シグネチャ依存型」のWAFが今もたくさん存在しています。つまり、何かしら、シグネチャが生き残っている理由があるはずです。

今回は、WAFにおけるシグネチャの利点・欠点について、より掘り下げて行きたいと思います。なお、本文内で何度か登場する「誤検知」は、「本来止めるべきでない正常な通信を、誤って攻撃と分類してしまった」というケース、つまり偽陽性の意味で使っています。

はじめに

Tomcatに新たな脆弱性CVE-2020-9484が発見されました。既にアップデートは提供されています。影響を受けるバージョンなどの情報についてはオフィシャルのページを参照ください。今回はこの脆弱性の技術的な側面について解説します。

はじめに

2020年のGWはオライリーの「Pythonではじめる教師なし学習」とOutlier Analysisという2冊の本を読んでいたのですが、その過程で私が数年前から持っていた、教師なし学習についての大きな疑問に対する答えが得られました。これは個人的には「年に1度、あるかないか」というくらい大きな衝撃を伴うイベントだったので、ここでブログにまとめたいと思います。なお、もしかしたら、知っている人には当たり前の話なのかもしれません...(もしそうだったらすみません)。

また、オライリー「Pythonではじめる教師なし学習」で行われているハイパーパラメータのチューニングには致命的な間違いがあるので、それも合わせて紹介します。

はじめに

Scutumにおいて教師なしの異常検知アルゴリズムであるIsolation Forestを使うため、フルスクラッチでJavaで実装し、GitHubでオープンソースで公開しました。今回はこの実装について簡単に紹介したいと思います。

WAFでは絶え間なく沢山の通信を処理しますが、このうちの殆どは攻撃ではない正常な通信であり、ごく一部が攻撃、つまり異常になります。データが多いことから、教師なし学習で異常を見つけることで、WAFの防御性能を高めることを目指しています。

Isolation Forestの概要

2020年現在、機械学習の主流は「教師あり学習」ですが、Isolation Forestは「教師なし学習」に属します。「教師なし学習」ではグループ分けを行うクラスタリングが有名ですが、Isolation Forestはグループ分けではなく、「異常検知」あるいは「外れ値検知」を行うためのアルゴリズムです。

はじめに

ScutumはWAFとして色々な種類のインジェクション攻撃に対応しています。今回、特に差し迫った危機というわけではありませんが、ScutumにおいてELインジェクション対策を強化したのでお知らせします。

ELとは?

ELはExpression Languageの略です。Javaのエンターブライズ版(Java EE)で定義されており、一部のJavaのウェブアプリケーション開発において使われています。Viewから手軽にJavaのオブジェクトにアクセスすることができ、Java自体には詳しくないフロントエンド側の開発者やデザイナーでも効率的に開発を可能にする目的で作られているようです。

ウェブアプリケーションセキュリティの文脈では、「ELはOGNLに似ている」という説明がわかりやすいでしょう。Struts2に対するOGNLと、JavaEEに対するELは非常に似た役割を持っており、立ち位置はほぼ同じと言えます。

ELインジェクションとは?

ELもOGNLと同じく「1つの独立した言語」であるため、ユーザ入力がELとして解釈されてしまう箇所があれば、そこでELインジェクションが成立します。例えば下記の、今年のCVEである4件を見てみましょう。

CVE-2020-9296
Netflix ConductorにおけるELインジェクション(RCE)
https://securitylab.github.com/advisories/GHSL-2020-027-netflix-conductor

CVE-2020-9297
Netflix TitusにおけるELインジェクション(RCE)
https://securitylab.github.com/advisories/GHSL-2020-028-netflix-titus

CVE-2020-10199
Nexus Repository ManagerにおけるELインジェクション(RCE)
https://securitylab.github.com/advisories/GHSL-2020-011-nxrm-sonatype

CVE-2020-5245 及び CVE-2020-11002
DropwizardにおけるELインジェクション(RCE)
https://securitylab.github.com/advisories/GHSL-2020-030-dropwizard

ELインジェクションの脆弱性は任意のJavaのコード実行に繋がるケースが多く、上記の例もすべてELインジェクションの結果RCE(Remote Code Execution / リモートからの任意のコードの実行)となる脆弱性になっています。