2018年7月の定期パッチで修正されたOracle WebLogic Server の脆弱性(CVE-2018-2894)について
7月のOracleの定期のパッチリリースでいくつか脆弱性の修正が入りました。
危険度の高い脆弱性として、以下の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 へアクセスします。
今回のPoCは Web Service Test Client への攻撃のため、まずはこれを有効化します。 コンソールにアクセスし、「base_domain」から、「General -> Advanced」のメニューから「Enable Web Service Test Page」にチェックを入れます。
コンテナを再起動して設定を有効化します。 ちなみに、この設定を行わずに攻撃対象のパスにアクセスすると404が返ってきます。
docker restart wlsadmin
http://localhost:7001/ws_utc/config.do へアクセスします。
ここは 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を押します。
左のメニューから「Security」を選択し、「Add」を押してKeystoreを追加します。
名前に適当な値を入れ、JSPのバックドアをアップロードします。
アップロードしたPOSTのレスポンスにタイムスタンプ(id)の値が返ってくるので、この値を覚えておきます。
アップロードしたファイルにアクセスします。
ここでは「/ws_utc/css/config/keystore/<タイムスタンプ>_<アップロードしたファイル名>」というパスにファイルが存在します。
jspファイルがバックドアとして動作します。これで任意のコード実行が可能です。
今回のPoCは前述の通り、開発モードでしか動作しません。
試しに Production Mode にチェックを入れて、再起動してみます。
この状態だと、「/ws_utc/config.do」へアクセスしても503が返ってくるため、ファイルのアップロードができません。
別のPoC
同じ脆弱性を悪用するPoCでコンフィグファイルのインポートを行うところでバックドアをアップロードするものがありました。 PoC自体は検証できていないのですが、アップロードが可能なことは確認できました。
最初に「http://localhost:7001/ws_utc/」へアクセスします。
このフォルダのアイコンをクリックすると設定のインポート画面が出てきます。
先ほどのバックドアファイルをインポートします。
設定ファイルではないため、怒られてしまいます。
ですが、ファイルのアップロード自体は完了しており、Dockerコンテナ内に入って探すと確かにアップロードしたファイルを見つけることができます。 以下はKeystoreのアップロード時と同じパスを設定している場合です。
これで、「/ws_utc/css/upload/RS_Upload_2018-07-22_14-30-17_948/import_file_name_backdoor.jsp」のURLパスにアクセスすると、バックドアが動作します。
こちらも条件は同じで、開発モードで Web Service Test Client が有効になっている必要があります。
まとめ
攻撃は任意のファイルがアップロードできるため、影響は大きいですが、現状のPoCでは開発モードで特定のサービスを有効にしている場合のみ影響を受けるようです。商用のサービスでは、まあ、そんな環境があるとも思えないので、あまり影響はないかと考えています。 ただ、今後違う形の攻撃コードが出てくる可能性もありますので、アップデートはしておくべきかと思います。