WAFおよびRASPにおけるLog4Shell

弊社のContrast Protect(RASP)を利用されているお客様は、今回の様な脆弱性やリモートコードの実行（RCE）が発見される何年も前から、安全性を確保しており、今回のLog4Shellの問題でRASP（Runtime Application Self-Protection）の有効性が証明されました。私たちは、提供するサービスをさらに向上させ、流出による情報漏えいを阻止したいと考えています。

今回のRASP活用事例は、根本的にWeb Application Firewall (WAF)では対処できない問題があるということを示しています。簡単に説明しますと、RASPは、実行時にアプリケーション内部から確認することで、アプリケーションの安全性を高め、アプリケーションの動作の前後関係を把握して正確に攻撃を検知し、ブロックします。それに対し、WAFは、通常ネットワークの境界に設置されHTTPトラフィックを監視し、提供されたシグネチャに基づいて攻撃を検出しています。

次に、Log4Shell対応するためのRASPのケースを紹介します。

WAFでは対処できない理由
WAFでは対処できない理由は、主に3つあります。

1：WAFはシグネチャによる検知しかできず、その設定は非常に多様性がある
Twitterでは、WAFを回避する攻撃として、いくつかのエンコーディングが話題になっています。コミュニティでは、シグネチャでの対応がかなり難しいことを即座に理解しました。ここでは目を見張るような例をご紹介します。
この攻撃にシグネチャで防御する方法があったとしても、正当なトラフィックと捕らえてしまい、システムを混乱させ、絶望的な結果となります。このように、WAFは、低スキルの攻撃者を可視化する事は可能ですが、実際の防御には適していないと考えています。

2：WAFは攻撃の帯域外の要素を確認していない
この攻撃で見落とされている要素の1つは、実はエクスプロイトがアプリケーションを騙して別のサービス（DNS、LDAP、RMI、CORBA）にアクセスさせるため、こちらのSophosの図が示すように、これらの出口のトランザクションはどれもWAFを通過していません。

したがって、エクスプロイトが成功したかどうかはWAFでは判りません。WAFは、スクリプト・キディがバニラ攻撃をしているかどうかを伝えるだけです。WAFを導入する前から、その動作は解った筈ですが、何故同じ過ちを繰り返してしまうのでしょうか。

3：ネットはHTTPだけではない
私たちのコードの大部分は、非同期、イベント-ドリブン、メッセージキューによるトリガー、プロトコルバッファーによるシリアライズなど、ますます多くなってきています。このバグは、途方もなく迂回した経路を経て、アプリケーションの奥深くで無造作に問題を引き起こしてしまう可能性があります。

内部的には、ある顧客のアプリが単純なLog4Shellペイロードで攻撃され、そのペイロードデータが分析され、不正なプログラムがサーバに送られ、いくつかのデータが記録され、それがログアグリゲータに取り込まれて、最終的にSlackチャネルに共有される、というような連鎖が見受けられました。これら全ての場所を攻撃から守らなければなら無い事を考慮すると気が遠くなります。小さな文字列が企業内に入り込み、そこから多くのシステムに伝播する可能性はいくらでもあるのです。

例えれば、サッカースタジアムの正門付近に監視カメラを1台設置して、中にいる全てのファンを守っている、などと宣言することは不可能です。

何をどのように守るか

私達は、2018年あたりからLog4Shellの様な攻撃に対する防御策を提供しています。それは、私たちがこのLog4jの脆弱性が発見されることを予見していたからではありません。悪用可能な操作（デシリアライズやELインジェクション実行など）と悪用となる対象（プロセス構築、動的なコードのロードなど）を分離するサンドボックスを構築していたからです。私はMicrosoft BlueHat 2018での講演で、この戦略について、OGNLのサンドボックス化を例にして詳しく説明させて頂きました。

一般的に利用されているエクスプロイト経路（JNDI→LDAP→デシリアライズ/EL→RCE、JNDI→RMI→EL→RCE）は、それらのパスがサンドボックス化されているステップを持つため、実行できません。これはハッカーがRCE(リモートでコードの実行
)への別の経路を見つけられないということではありません。実際、我々はさらに研究を進めようと試みておりますが、ここ数日間は、Contrast Protectのユーザであれば問題は発生しておりません。

以前Struts2がRCEを公開した際に、OGNL(Object-Graph Navigation Languageの略称)機能実行を強化したため、私たちはOGNL機能の実行をハード化したため、すぐに防御することができ、Contrast Protectの製品のすばらしさを感じました。もちろん、ライブラリの脆弱性だけでなく、カスタムコードの脆弱性にも対応しています。

これらの攻撃を利用したデータ流出も可能です。RCEと比べて面白みはないかもしれませんが、非常にハイリスクであることに変わりはありません。透明性と公平性の確保のため、コード実行を可能にする次のステップを踏まずに、同様のエクスプロイト経路を使用して、RMI / LDAP DNS /経路の情報を自分自身にリークさせてしまうという問題は一般的に防御できませんがContrast Protectでは防御可能です。数日中に、この攻撃の情報漏洩機能を防止するエージェントの更新版をリリースする予定です。弊社研究チームは今後も、この防御が一般化できるかどうかを見極めるためにじっくり考察し、次の新たな脆弱性に万全に備えていけるよう準備しています。

私は、ベンダーが救急車を追いかける悪徳弁護士のように行動することに対し抵抗を感じています。私たちのチームが忍耐強くこの防御機能を構築したことを誇りに思うと同時に、RASPなしでアプリケーションを実行することが、如何に危険かを世界に示せることを願っている、という言葉で締めくくりたいと思います。

Contrast製品による、Log4jのような攻撃からJavaアプリケーションを保護する方法や、トライアルの実施については、お気軽に弊社までお問い合わせください。
＞お問い合わせ