生産性のない話

趣味の範囲でサイバーセキュリティの話

2018年7月の定期パッチで修正されたOracle WebLogic Server の脆弱性(CVE-2018-2894)について

7月のOracleの定期のパッチリリースでいくつか脆弱性の修正が入りました。

CPU July 2018

危険度の高い脆弱性として、以下の2つがあり、いずれも攻撃コードが公開されています。

  • CVE-2018-2893

WLS Core Components の脆弱性でT3プロトコルを利用してネットワーク経由でコード実行ができます。 T3プロトコルはこれまでいくつかリモートからのコード実行の脆弱性が見つかっており、運用しているシステムでは無効化しておくのが無難かと思います。

  • CVE-2018-2894

WLS - Web Servicesの脆弱性。2017年10月に公開された脆弱性(CVE-2017-10271)と同じコンポーネントでHTTP経由でコード実行が可能な脆弱性。 こちらはHTTPなので、対象のモジュールが動いていて、そのパスが存在していたら危ないです。

影響を受けるバージョン

サポートされている Oracle WebLogic Server で影響を受けるのは以下のバージョン

  • 10.3.6.0
  • 12.1.3.0
  • 12.2.1.2
  • 12.2.1.3

脆弱性検証

PoCが公開されているCVE-2018-2894の脆弱性の検証を行いました。

環境は前回作ったCVE-2017-10271のDockerのイメージを使おうとしましたが、前回のDockerイメージはProductionモードでビルドしており、公開されているPoCは開発モードでしか攻撃が成功しないため、使えませんでした。

Oracle WebLogic Server のWLS Security に関する脆弱性(CVE-2017-10271)について - 生産性のない話

ということで、新しいDockerイメージをビルドします。今回はバージョン 12.2.1.2を作ります。

ちなみに、前回作ったのはバージョン 12.1.3 なのですが、このバージョンのDockerfileはデフォルトでProductionモードになっており、明示的にビルドの際に引数「PRODUCTION_MODE=dev」を付与する必要があります(バージョン 12.1.3 以外はデフォルトで開発モードになっているのに、なぜそうなっているのかは不明……)。

Oracleの公式のDockerfileをクローンします。 OracleJavaのイメージをビルドした後で、以下のコマンドを実行します。

cd OracleWebLogic/dockerfiles/12.2.1.2/
# Oracleのサイトからファイルをダウンロードしてくる
mv ~/Downloads/fmw_12.2.1.2.0_wls_Disk1_1of1.zip ./
mv ~/Downloads/fmw_12.2.1.2.0_wls_quick_Disk1_1of1.zip ./
cd ../
./buildDockerImage.sh -d -v 12.1.3
cd ../samples/12212-domain
docker build -t 12212-domain --build-arg ADMIN_PASSWORD=admin1234 .

出来上がったイメージを起動します。

docker run -d --name wlsadmin --hostname wlsadmin -p 7001:7001 12212-domain

これで http://localhost:7001/console へアクセスします。

f:id:blueBLUE:20180722075036p:plain

今回のPoCは Web Service Test Client への攻撃のため、まずはこれを有効化します。 コンソールにアクセスし、「base_domain」から、「General -> Advanced」のメニューから「Enable Web Service Test Page」にチェックを入れます。

f:id:blueBLUE:20180722075335p:plain

コンテナを再起動して設定を有効化します。 ちなみに、この設定を行わずに攻撃対象のパスにアクセスすると404が返ってきます。

docker restart wlsadmin

http://localhost:7001/ws_utc/config.do へアクセスします。

f:id:blueBLUE:20180722075403p:plain

ここは Web Service Test Client の設定ページですが、このKeystoreをアップロードするところでjspバックドアをアップロードできます。 まず、アップロード先のディレクトリを指定する必要があります。 画像にある「Work Home Dir」の値を「/u01/oracle/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal/com.oracle.webservices.wls.ws-testclient-app-wls/4mcj4y/war/css」に変更し、Submitを押します。

f:id:blueBLUE:20180722075430p:plain

左のメニューから「Security」を選択し、「Add」を押してKeystoreを追加します。

名前に適当な値を入れ、JSPバックドアをアップロードします。

f:id:blueBLUE:20180722075504p:plain

アップロードしたPOSTのレスポンスにタイムスタンプ(id)の値が返ってくるので、この値を覚えておきます。

アップロードしたファイルにアクセスします。

ここでは「/ws_utc/css/config/keystore/<タイムスタンプ>_<アップロードしたファイル名>」というパスにファイルが存在します。

jspファイルがバックドアとして動作します。これで任意のコード実行が可能です。

f:id:blueBLUE:20180722075523p:plain

今回のPoCは前述の通り、開発モードでしか動作しません。

試しに Production Mode にチェックを入れて、再起動してみます。

f:id:blueBLUE:20180722075740p:plain

この状態だと、「/ws_utc/config.do」へアクセスしても503が返ってくるため、ファイルのアップロードができません。

f:id:blueBLUE:20180722075752p:plain

別のPoC

同じ脆弱性を悪用するPoCでコンフィグファイルのインポートを行うところでバックドアをアップロードするものがありました。 PoC自体は検証できていないのですが、アップロードが可能なことは確認できました。

最初に「http://localhost:7001/ws_utc/」へアクセスします。

f:id:blueBLUE:20180722234749p:plain

このフォルダのアイコンをクリックすると設定のインポート画面が出てきます。

f:id:blueBLUE:20180722234840p:plain

先ほどのバックドアファイルをインポートします。

f:id:blueBLUE:20180722234902p:plain

設定ファイルではないため、怒られてしまいます。

ですが、ファイルのアップロード自体は完了しており、Dockerコンテナ内に入って探すと確かにアップロードしたファイルを見つけることができます。 以下はKeystoreのアップロード時と同じパスを設定している場合です。

f:id:blueBLUE:20180722235220p:plain

これで、「/ws_utc/css/upload/RS_Upload_2018-07-22_14-30-17_948/import_file_name_backdoor.jsp」のURLパスにアクセスすると、バックドアが動作します。

f:id:blueBLUE:20180722235239p:plain

こちらも条件は同じで、開発モードで Web Service Test Client が有効になっている必要があります。

まとめ

攻撃は任意のファイルがアップロードできるため、影響は大きいですが、現状のPoCでは開発モードで特定のサービスを有効にしている場合のみ影響を受けるようです。商用のサービスでは、まあ、そんな環境があるとも思えないので、あまり影響はないかと考えています。 ただ、今後違う形の攻撃コードが出てくる可能性もありますので、アップデートはしておくべきかと思います。