技術者ブログ

はじめに

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 / リモートからの任意のコードの実行)となる脆弱性になっています。

ELインジェクションは誰が作り込んでしまうか?

ELインジェクションも他のインジェクション系の脆弱性と同じように、個別のウェブアプリケーションのコードで発生する可能性と、フレームワークそのものに作り込んでしまう可能性が考えられます。前者はウェブアプリ開発者、後者はフレームワーク開発者の担当範囲になります。

SQLインジェクションやコマンドインジェクションは、個別のウェブアプリケーション開発においてSQLやシステムコマンドを利用したい場面で作り込んでしまう可能性が高いです。一方でELについては、ウェブアプリケーション開発の中ではそれほど(少なくとも、危険な形では)使われることはないと考えられるため、一般的なウェブアプリ開発者がELインジェクションの脆弱性を作り込む可能性はかなり低いと考えられます。

ただし注意が必要なのは、フレームワークがその使用者であるアプリ開発者向けに用意しているAPIが、実は引数の文字列を内部でELとして解釈している場合があることです。上に挙げたDropwizardの脆弱性はこれに当たります。アプリ開発者としては作法に従って開発したつもりが、実はRCEになってしまう、という形です。アプリ開発者がELインジェクションを作り込んでしまう典型的なパターンの1つとして意識しておくのがよいでしょう。

一方でフレームワーク側では、既知の脆弱性を見れば明らかなように、いくつかのELインジェクションが見つかっています。個別のウェブアプリの開発者よりもフレームワーク側の開発者に、より多くの注意が要求される状況が今後も続くと考えられます。

Struts2くらいの危険性があるのか?

ELがOGNLに似ているのであれば、「つまりJavaEEのアプリケーションが全てStruts2みたいな酷い事になるのか?」と想像してしまうかもしれません。これについては2つの点で考えるとよさそうです。

1つめは「ELインジェクションがどのくらい頻繁に発生しうるか」ということ。つまり脆弱性の存在の可能性です。これが、Struts2におけるOGNLインジェクションと同じくらい多くなる、確率が高くなるのかどうか。

2つめは「ELインジェクションが発生したら、どのくらい危険か。ほぼRCEになるのか」ということ。こちらは簡単なので先に答えを書いてしまうと、Yesです。ELインジェクションはほぼRCEになると考えてよいでしょう。

ELインジェクションはどのくらい頻繁に発生しうるか?

前項の1つめについて考えます。既知のELインジェクションの脆弱性の数がそれほどは多くないことからもわかるように、ELインジェクションはOGNLインジェクションほど頻繁には発生しなさそうです。これは何故かというと、Struts2はOGNLを非常に多くの場面で活用、多用しているからです。一般的にELはJavaEEアプリケーションあるいはフレームワーク等において、Struts2におけるOGNLほどは多くの役割を期待されておらず、その結果ELインジェクションの発生する可能性も低く抑えられているようです。

ただしELは標準仕様であるため、OGNLはほぼStruts2のみで使用されているのに対し、ELは非常に多くのウェブアプリ・フレームワークで使われます。今後、もしかしたらELの可能性を最大限に活かそうとする、ある意味で非常に危険なJavaのウェブアプリケーションフレームワークが登場し台頭する可能性もあります。そのような場合には、一気にELインジェクションの波が来るかもしれません。

しかし少なくとも2020年4月現在においては、「それほど頻繁に発生する脆弱性ではなさそう」という見方ができるでしょう。

ScutumにおけるELインジェクション対策

ScutumではOGNLインジェクションと同じように、ELインジェクションについても汎用化した防御を提供します。つまり、上にあげた4つの例のような特定のフレームワーク等の既知の脆弱性について、それぞれシグネチャやルールを定義するのではなく、HTTPヘッダやウェブアプリケーションのパラメータの広い範囲、全体について防御を行います。

現在はベイジアンネットワークによってELインジェクション攻撃に対する防御を実装しています。汎用的に防御するため、今後見つかるかもしれない、未知のELインジェクションの脆弱性についても防御することが期待できます。

シグネチャあるいはルールで防御する際の注意点

以前のエントリで攻撃者が行うWAF回避策について、コマンドインジェクションを例に紹介しましたが、ELインジェクションでもこれに似たテクニックが想定できます。

ELインジェクションは最終的なRCEにおいてJavaのコードに繋げるため、RuntimeクラスやProcessBuilderクラスへアクセスしようとすることが多いです。そのためシグネチャでこれらの文字列を止める、というアプローチが考えられます。

しかしELでは

'a'.getClass().forName('jav'.concat('a.lang.R').concat('untime'))

のようにconcat等のStringクラスの関数を使って文字列を自在に操ることができます。シグネチャで防御する場合には、それよりも先に必須となる、getClassやforName等を探す方がよいかもしれません。

まとめ

今回はScutumが最近防御を強化した、ELインジェクションについて簡単に紹介しました。今後脆弱性が出てくる可能性は引き続きそれほど高くないだろうと予測していますが、もし見つかった場合には、Struts2におけるOGNLインジェクションと同じように非常に危険な存在となります。JavaEEの機能を使ったフレームワークを使っている場合には、アップデートの情報を見逃さないようにしましょう。