技術者ブログ

はじめに

前々回の記事ではサブクエリを「(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 / リモートからの任意のコードの実行)となる脆弱性になっています。

はじめに

先日、とあるScutumを利用中のお客様からうれしいフィードバックを頂きました。

「ウェブサーバをオンプレからクラウドに移した際に、WAFを(一時的にScutumをやめて)そのクラウドにメニューとして用意されていたWAFに切り替えてみたところ、誤検知が多発して本当に苦労した。Scutumがいかに楽なのかが実感できた」というものです。そのお客様はその後、そのクラウドのWAFから、再びScutumに戻ってきてくれました。

最近では著名なクラウドサービスにメニューとしてWAFがあるようですが、私が知っている範囲では、それらの多くは「シグネチャ」あるいは「ルール」を使って攻撃を見つけようとする種類のWAFのようです。本ブログではこれらの「シグネチャあるいはルールのみによって防御を行う」タイプのWAFを、「シグネチャ依存型」のWAFと定義します。

シグネチャ依存型のWAFは2020年という時代にそぐわない、古くて性能の低いものです。個人的に、上で例に挙げさせていただいたようなケース(WAFで、不必要に苦労してしまうこと）が増えることを危惧しています。

今回はシグネチャ依存型のWAFはできるだけ避けたほうがよい、という私の意見について、根拠を明確にして説明させて頂こうと思います。

はじめに

ソースIPを詐称したSYNパケットを1つだけ踏み台サーバーに送ることにより、再送されるものを含め、数回SYN-ACKパケットが攻撃対象に送られてしまうのがSYN-ACKリフレクション攻撃です(※1)。あなたが(クラウド/オンプレミス問わず)サーバをOSレベルで管理している場合には、そのサーバが踏み台にされている可能性が非常に高いです。今回は私達が行った「踏み台にされないための」対策について紹介します。