開発者コンソールを開いた状態で、このサイトにアクセスすると、「/DATA/」から始まる長い文字列を含むURLがあります。オブジェクトを投げると、それを解釈してコード実行が行われます。ここで、「/DATA/」以降に適当な値を入れてアクセスすると、その値をJAVAオブジェクトとして正しく認識できずにエラーが返ってきます。PoCを投げてみます。PoCは上記のリンクにありますが、同様のURLの「/DATA/」以降の文字列を細工したものになっています。/tmp/richfaces0day_joaomatosf」です。処理が行われ、レスポンスとして200が返ってきます。いうことで、コンテナの中に入って、コマンドが実行されていることを確認します。コマンドが実行され、「/tmp」配下にファイルが作成されました。このURLに含まれる長い文字列ですが、これはシリアライズ化したオブジェクトをzlibで圧縮し、BASE64でエンコードしたものとなっています。そのため、以下のようにして逆処理をしてやると、シリアライズ化されたオブジェクトが現れ、実行コマンドが確認できるようになります(念のため、ペイロードを一部マスクしています)。「serialVersionUID」というパラメータが共通のものがないため、PoC生成の段階でアプリケーション毎に別の値を指定してやる必要があるようです。そのため、攻撃先の環境によって、別々の値を指定する必要があり、共通のPoCが利用できないようです。利用している場合の検証が行われいます。www.youtube.comまとめシリアライズ関係の脆弱性は理解しにくいところがあって、なかなか難しいです。JAVAオブジェクトをシリアライズ化してそのままやり取りするようなアプリケーションは危険だということは理解していますが、今回のようなURLに一見してわからない形で入ってくることもあるんですね。この場合、通常通信と攻撃通信が見ただけで判断できないのがちょっと辛いです。EOLを迎えているフレームワークであり、利用しているところはないだろうと思ってはいますが......。脆弱性(CVE-2018-2894)について検証7月のOracleの定期のパッチリリースでいくつか脆弱性の修正が入りました。2018危険度の高い脆弱性として、以下の2つがあり、いずれも攻撃コードが公開されています。脆弱性でT3プロトコルを利用してネットワーク経由でコード実行ができます。T3プロトコルはこれまでいくつかリモートからのコード実行の脆弱性が見つかっており、運用しているシステムでは無効化しておくのが無難かと思います。Servicesの脆弱性。2017年10月に公開された脆弱性(CVE-2017-10271)と同じコンポーネントでHTTP経由でコード実行が可能な脆弱性。こちらはHTTPなので、対象のモジュールが動いていて、そのパスが存在していたら危ないです。影響を受けるのは以下のバージョン10.3.6.012.1.3.012.2.1.212.2.1.3脆弱性検証PoCが公開されているCVE-2018-2894の脆弱性の検証を行いました。環境は前回作ったCVE-2017-10271のDockerのイメージを使おうとしましたが、前回のDockerイメージはProductionモードでビルドしており、公開されているPoCは開発モードでしか攻撃が成功しないため、使えませんでした。生産性のない話ということで、新しいDockerイメージをビルドします。12.2.1.2を作ります。以外はデフォルトで開発モードになっているのに、なぜそうなっているのかは不明......)。Oracleの公式のDockerfileをクローンします。OracleJavaのイメージをビルドした後で、以下のコマンドを実行します。.出来上がったイメージを起動します。攻撃のため、まずはこれを有効化します。Page」にチェックを入れます。コンテナを再起動して設定を有効化します。ちなみに、この設定を行わずに攻撃対象のパスにアクセスすると404が返ってきます。設定ページですが、このKeystoreをアップロードするところでjspのバックドアをアップロードできます。アップロード先のディレクトリを指定する必要があります。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は前述の通り、開発モードでしか動作しません。チェックを入れて、再起動してみます。この状態だと、「/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パスにアクセスすると、バックドアが動作します。有効になっている必要があります。まとめ攻撃は任意のファイルがアップロードできるため、影響は大きいですが、現状のPoCでは開発モードで特定のサービスを有効にしている場合のみ影響を受けるようです。商用のサービスでは、まあ、そんな環境があるとも思えないので、あまり影響はないかと考えています。今後違う形の攻撃コードが出てくる可能性もありますので、アップデートはしておくべきかと思います。脆弱性(CVE-2018-2894)についてTweet広告を非表示にするもっと読むコメントを書く2018-05-24XdebugとNetBeansを使ったDrupalのデバッグ環境をdocker-composeのみで立てる昨年の末ごろにデバッガを使って脆弱性検証を行う勉強会に参加させていただきました。connpassとても参考になりました。その時の内容は下記の記事がとても詳しくまとめてくれています。tigerszk.hatenablog.com自分が脆弱性検証をやるときにデバッガを使うことはやったことがなかったのですが、そういう方法があるというのは新しかったです。脆弱性検証の場合、別に開発するわけではないのであくまでプロジェクトは一時的なもので、また複数のバージョンを立てて壊してとしていくので、そういう点でDockerとの相性がよく、自分もかなりの頻度で使っています。Dockerを使ってこういう環境を立てておくと、後々応用が利きそうだなと思いました。いうことで今回はXdebugとNetBeansを使ったデバッグ環境を立てます。脆弱性が見つかったDrupalのデバッグ環境を立ててみます。NetBeansのDockerコンテナとしては以下を参考にしました。IDEをGUIで起動できます。/usr/local/netbeans-8.2/bin/netbeansNetBeansのPHPのIDEをインストールしています。「--silent」オプションを付けることでGUIなしでインストールできます。-」とかで認証拒否の状態に戻すことを推奨します)。次にDrupalのDockerコンテナです。公式のものにXdebugをインストールしています。xdebug・・・Xdebugの設定は以下の通りです。[xdebug]zend_extension=/usr/local/lib/php/extensions/no-debug-non-zts-20151012/xdebug.soxdebug.remote_enable=1xdebug.remote_handler=dbgpxdebug.remote_connect_back=0xdebug.remote_autostart=1xdebug.remote_host=172.42.0.4xdebug.remote_port=9000xdebug.max_nesting_level=1000xdebug.idekey="netbeans-xdebug"設定についてはいろいろと必要なオプションがあります。デバッガの接続元のIPを指定する必要があるので、NetBeansのIPを指定する必要があります。そのため、docker-composeでネットワークを作成し、IPを固定しています。デバッグ対象となるアプリケーションのファイルを共有しておく必要があるので、ボリュームを作成しています。このボリュームを触るときに権限の設定が面倒なので、NetBeansはrootで動かしています。以上から出来上がったDockerの設定ファイルは以下になります。github.comこれをビルドします。