技術者ブログ

はじめに

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レベルで管理している場合には、そのサーバが踏み台にされている可能性が非常に高いです。今回は私達が行った「踏み台にされないための」対策について紹介します。