技術者ブログ

はじめに

Log4jやStruts2など、Java製ソフトウェアにおいてリモートからの任意のコード実行(RCE)の脆弱性が目立つ時代になってしまっていますが、これにさらにSpringも加わってきました。この記事では特にCVE-2022-22965に焦点を当て、技術的な視点からの解説を行ってみます。

はじめに

2021年12月に発見されたLog4jのCVE-2021-44228は、稀に見るレベル、まさに超弩級の脆弱性となっています。今回、私はTwitterを主な足がかりとして情報収集を行いましたが、(英語・日本語どちらにおいても)かなりWAFそのものが話題になっていることに驚きました。ある人は「WAFが早速対応してくれたから安心だ！」と叫び、別の人は「WAFを回避できる難読化の方法が見つかった。WAFは役に立たない！」と主張する。さらにはGitHubに「WAFを回避できるペイロード(攻撃文字列)一覧」がアップロードされ、それについて「Scutumではこのパターンも止まりますか？」と問い合わせが来るなど、かなりWAFでの防御とその回避方法について注目が集まりました。

実はWAFにおいては、「回避(EvasionあるいはBypass)」との戦いは永遠のテーマです。これは今回Log4jの件で強く意識されたように「WAFが役に立つか、あるいは無駄なセキュリティ投資になるか」の境目を決定する要素であり、そのため非常に、本当に非常に重要な要素です。実は我々Scutumの開発チームはこの部分に特に力を入れているため、「WAFの回避テクニック」に世間の注目が集まるのは少しうれしい部分もあったりします。

今回はこの「WAFの回避」に焦点を当て、Log4jでの具体的な例を中心に、難読化やそれを見破るいたちごっこについて書いてみます。

はじめに

世界的に知られているウェブサーバ実装のApache HTTP Serverがパストラバーサルの脆弱性を出してしまいました。しかも最初に発見されたCVE-2021-41773だけでなく、すぐに別のパストラバーサル脆弱性CVE-2021-42013も見つかり、わずか数日という短い期間において2度のバージョンアップが行われるという慌ただしい状況になりました。今回はこのApacheの脆弱性と、それに対してScutumがどのように対応できたかについて簡単にご紹介します。

はじめに

Isolation Forestは教師なしでアノマリ検知に使うことのできる優れたアルゴリズムです。性能が高く、またデータの前処理が楽で、とても使いやすいことが知られています。

Scutumではアノマリ検知のアルゴリズムとしてIsolation Forestを使っています(※1)が、最近になり、Isolation Forestの性能を高める「Thinning」という新たな手法を開発しました。これによって、よりWAFとしての攻撃検知精度を高めることができるようになります。今回はこの「Thinning」という手法について解説してみたいと思います。

ファジング(Fuzzing)が便利

コンピュータにランダムに生成させたデータを入力とし、ソフトウェアの予期せぬ挙動を観測・発見する手法がファジングです。脆弱性発見の文脈で使われることが多いですが、一般的なごく普通のソフトウェア開発でも便利に使うことができます。私もこれまでに何度か、開発中の関数にファジングを行うことで、想定できていなかったバグを見つけたことがあります。

ファジングの大きな魅力の1つは、個人の想像力を超えることができる点です。開発をテスト駆動で進めているとしても、必要となるテストをすべて網羅できていない場合が多々あります。テスト駆動開発はあくまでも個人(あるいはチームメンバー)が見つけることができたテストしか実行できないので、その人の能力や想像力を超えることができません。しかしファジングであれば、人が考えもつかないようなパターンを試してくれます。もちろんファジングもブルートフォース的に全パターンを試すわけではないので、まだ抜けがある可能性はありますが、近年のコンピュータの性能の向上は著しいため、かなりの高確率で良いテストを発見してくれます。

おまたせしました

この度、ついにこの記事を完成させることができました。これは私が数年前からずっと書きたいと思っていた、ウェブのアクセスログに対する、機械学習を使った異常検知の実例です。私は事あるごとに(※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が発見されました。既にアップデートは提供されています。影響を受けるバージョンなどの情報についてはオフィシャルのページを参照ください。今回はこの脆弱性の技術的な側面について解説します。