Windowsに対する各種クライアント・サイド・アタック


Windows 2000 World 2000年9月号
月刊セキュリティレポート No.8


本文書は、Windows 2000 World誌に寄稿した記事の原稿を、 IDGジャパン編集部殿の許可を得た上で掲載したものです。



このところ、Windowsに対する各種のクライアント・サイド・アタック（WebアクセスやHTMLメールによるクライアントマシンに対する攻撃）が多数報告されている。今回はその中でも比較的危険度が高く、任意のプログラム起動につながるような以下の4つの問題について解説する。
  • Office 2000 UA Control問題
  • IE HTML Help問題
  • IE Force Feeding問題
  • Access 2000 VBA問題


Office 2000 UA Control問題


この問題は@stakeのDildog氏によって今年の5月に報告された[1]。Office 2000に付属する特定のActiveXコントロールの不具合により、Internet Explorer（IE）からOffice 2000アプリケーションを操作することができるというものだ。マイクロソフトはこの問題に対し、セキュリティ情報（英語版[2]および日本語版[3]）および関連する修正モジュールを提供した。

問題があるのは「Office 2000 UA Control」と呼ばれるActiveXコントロールで、Office 2000あるいはOffice 2000ファミリーの製品（Word 2000、Excel 2000等）に付随しインストールされる。このActiveXコントロールは本来、ヘルプファイルにおいてデモを自動的に実行するために用いられる。前述したマイクロソフトのセキュリティ情報には具体的な例として、Excelのヘルプ「表示形式を作成する」の中で「ここをクリック!」と表示されたヘルプトピックをクリックした際に「セルの書式設定」ダイアログが表示されるケースを説明している（図1）。このコントロールの機能を使用することにより、Officeアプリケーションのいくつかの機能（例えばマクロのセキュリティ設定変更等）を実行することが可能となる。


図1 Excelのヘルプ「表示形式を作成する」で「ここをクリック!」をクリック することにより「セルの書式設定」ダイアログを自動的に表示する例。


問題の本質は、このOffice 2000 UA Contorolが上記の通り高度な（すなわちクライアントマシンにとって危険な）機能を実行可能であるにもかかわらず、「スクリプトを実行しても安全」として設定されていることにある。読者の皆さんは本連載の第一回（Windows NT World 2000年1月号）に解説した「IE5.0のScriptlet.Typelib問題[4]」を覚えておられるだろうか。あの時もScriptlet.TypelibというActiveXコントロールが今回と同様「スクリプトを実行しても安全」であると誤って標準で設定されていたため、非常に大きな問題として広く危険性が指摘された。

IEの「インターネット」セキュリティゾーンにおける標準設定では、「スクリプトを実行しても安全」とマークされているActiveXコントロールのスクリプト実行を許可している。すなわちインターネット上のWebサイトに今回のOffice 2000 UA Controlを操作するようなスクリプト記述が行なわれたWebページがあった場合、それをアクセスしたIEは無条件で実行してしまうのだ。


図2 Dildog氏のデモページ。「Click here if you want to try it」をクリックすることでデモが実行。


Dildog氏は今回の問題のデモページをインターネットで公開している[5]（図2）。氏のアドバイザリ文書によると、このデモでは以下について実行する。
  • 一つのフレーム内にダミーのWord文書（blank.doc）を読み込み、Wordを起動する。
  • 別のフレーム内にスクリプトが書かれたHTMLページ（oua.html）を読み込み、以下のスクリプトを実行する。
      • - Office 2000 UA Controlの作成
      - UA Controlを実行中のWordプログラムにアタッチ
      - Wordプログラムをアクティブアプリケーションにする
      - ツール/マクロ/セキュリティのダイアログを表示
      - セキュリティレベル「低」ラジオボタンをクリック
      - 「OK」ボタンをクリック
  • ダミーWord文書のフレーム内に別のWord文書（evil.doc: マクロを含む）を読み込む。
  • Wordのマクロセキュリティ設定は「低」に変更されているので、evil.doc内のマクロは警告なしに動作し、Cドライブのルートにdildog_was_here.txtという名称のファイルを作成する。
すなわち、Office 2000 UA Controlを利用してまずWord 2000のマクロセキュリティ設定を変更（図3）し、その後にマクロを含んだWord文書を実行するという流れになる。なお、このデモを実行した後はかならずWordのマクロセキュリティ設定を元に（デフォルトは「高」）戻すようにしていただきたい。上記デモサイトでも元に戻すためのURLを提供している。


図3 Word 2000のマクロセキュリティ設定が「低」に変更された様子。この状態ではマクロを含むWordファイルを開く際に警告のダイアログが表示されない。


マイクロソフトの提供する修正モジュールは、Office 2000 UA Controlを機能制限された新しいバージョンに入れ替えることで対処している。またクライアントマシンで以下の対策のいずれかを施すことにより、この問題は回避できる。
  • IEのセキュリティゾーンで、「ActiveXコントロールとプラグインの実行」を「無効にする」に設定する。
  • IEのセキュリティゾーンで、「アクティブスクリプト」を「無効にする」に設定する。



IE HTML Help問題


この問題はGeorgi Guninski氏によって今年の3月に報告された[6]。他のプログラムを起動するようにコーディングされたHTML HelpファイルをWebページ上で表示させることにより、クライアントマシン上で任意のプログラムを起動させることが可能になるというものだ。マイクロソフトはこの問題に対し、セキュリティ情報（英語版[7]および日本語版[8]）および関連する修正モジュールを提供した（本原稿執筆時点では日本語版修正モジュールは未提供）。

HTML Helpは、HTMLベースの記述によりアニメーションやハイパーリンク等の多彩な機能をユーザに提供する。その機能の一つに「ショートカット」があるが、これを利用すればHTML Helpファイルから別のプログラムを起動することができる。ちなみにコンパイルされたHTML Helpファイルは「.chm」という拡張子を持つ。コンパイルするためのツール（HTML Help Workshop）もマイクロソフトのWebサイトで無償で提供されている（図4）。


図4 HTML Help Workshopツールを用いてHTML Helpファイルを作成する様子の例。このHTML Helpファイルをコンパイルして実行すると、「cmd /k dir」が自動的に実行される。


今回の問題は、スクリプトでwindows.showhelp()メソッドを使用することにより、例えばIEでWebサイトにアクセスした場合に不正なHTML Helpファイルを表示し、さらにその中の記述に基づいてクライアント側で任意のプログラムを起動できてしまうというものである。ただしこの攻撃が成功するためには、クライアントマシンからHTML Helpファイルが通常のファイルパス（c:\test.chm等）やUNCシェア（\\ホスト名\共有名\test.chm等）でアクセスできなければならない。マイクロソフトは修正モジュールによって、HTML Helpファイルがローカルマシン上にある場合のみショートカットを使用できるように変更し、対処した。すなわち悪意のあるリモートマシン上のHTML Helpファイルにはwindows.showhelp()メソッドでアクセスできないようにしたのである。



MSの修正モジュールでは防げないHTML Help攻撃


その後Georgi Guninski氏は、リモートマシン上に不正なHTML Helpファイルを置いてUNCシェアで参照するという方法ではなく、ローカルマシン上に不正HTML Helpファイルを強制的にダウンロードさせてそれをwindows.showhelp()で参照する方法によるデモを公開した[9]。それはメールメッセージファイル（拡張子「.eml」）の中で添付ファイルをフレームに表示させる際に、その添付ファイルが一時ディレクトリ（テンポラリ・ディレクトリ）に既知のファイル名で一時ファイルとして作成されるという性質を利用したものだ。

図5を見ていただきたい。HTML Help攻撃用のファイル（.eml）はIEでアクセスしてもOutlook/Outlook Expressで表示しても良い。はじめの、
    <IFRAME src=3D"cid:000701bf8458$eb570380$dc0732d4@bbb"></IFRAME>
の記述により、このメールメッセージファイルにBase64でエンコードした状態で添付されている不正なHTML Helpファイル（abcde.chm）がクライアントマシン上の一時ディレクトリに同一ファイル名でコピーされる。


図5 HTML Help攻撃の例。フレームに添付ファイルを読み込む過程で一時ディレクトリにabcde.chmがコピーされるので、それをshowhelp()メソッドで表示させ、不正なプログラムを起動する。


次にスクリプトとして記述されている、
    setTimeout('window.showHelp("c:/windows/temp/abcde.chm");',1000);
は、c:\windows\tempディレクトリ（Windows95/98の標準的な一時ディレクトリ）中のabcde.chmファイルを表示しようとする。もしクライアントマシンの一時ディレクトリがこの通りであれば、不正なHTML Helpファイルはこの時点で表示される。次の行、
    setTimeout('window.showHelp("c:/temp/abcde.chm");',1000);
は、Windows NTの標準的な一時ディレクトリを試している。もし攻撃側がクライアントマシンの一時ディレクトリを推測することが可能であればこのようにいくつものディレクトリを試す必要はない。そのパスを指定すれば良いだけである。

さて見事HTML Helpファイル（abcde.chm）を表示できれば、あとはそのファイルに記述された通りに任意のプログラムを起動することができる。この例では、
    <PARAM name="Item1" value=",wordpad.exe,">
のように指定してワードパッドを起動している。

このような手法を用いることにより、クライアントマシンのローカルディスクにHTML Helpファイルをコピーし、それを表示させるようなことが可能となるため、前述したマイクロソフトの修正モジュール（UNCシェアではHTML Helpを起動できなくなる）の対策は十分ではない。この件については別途CERT/CCからもアドバイザリ文書が発行されている[10]。

HTML Help問題の対策は次の二つが考えられる。
  • IEのセキュリティゾーンで、「アクティブスクリプト」を「無効にする」に設定する。
  • 一時ディレクトリを推測困難な名称に変更する。
Windows 2000ではデフォルト状態で一時ディレクトリの名称が、
    \documents and settings\'username'\local settings\temp
のようにユーザ名が含まれた形になっているため、Windows 95/98やWindows NTと比較すれば推測がやや困難である。しかしいずれにせよ全く別のディレクトリ名を使用することが望まれる。



IE Force Feeding問題


この問題は今年の6月にBugtraq等のセキュリティメーリングリストに報告された[11]。これも前述のHTML Help問題と同様の手法を用いて不正なプログラムとそれを起動するHTMLファイルを一時ディレクトリにコピーし、任意のプログラムをクライアントマシン上で実行するというものだ。


図6 Force Feedingのデモで表示される火星（?）のイメージデータ。


この問題の報告者によってデモページ[12]が用意されているが、このURLにアクセスするとすぐにデモが起動する可能性があるので注意していただきたい（図6）。このデモにおいても、フレーム内にデータを表示させる際に一時ディレクトリに該当ファイルが同一名称でコピーされることを利用している。この攻撃で興味深いのは以下のようなオブジェクト・タグを使用していることだ。
    <OBJECT CLASSID='CLSID:10000000-0000-0000-0000-000000000000' CODEBASE='mars.exe'>
Weld Pond氏によると、CLASSIDはオールゼロでない限り何でもいいらしい。この記述により、クライアントマシンの一時ディレクトリにコピーされたmars.exeが実行する。

この攻撃は筆者が試した限り、IEの一般的なセキュリティゾーン設定をいかに厳しく設定しても回避できない。ファイルのダウンロードを無効にしても、一時ディレクトリにはそのファイルがコピーされる。また攻撃の最後のフェーズではローカルに保存されたHTMLファイルを開くため、「マイ コンピュータ」セキュリティゾーンとなり、セキュリティ設定は非常に緩いものが適用される。

この問題を回避する最も有効な方法は、
  • 一時ディレクトリを推測困難な名称に変更する。
ことである。



Access 2000 VBA問題


この問題はGeorgi Guninski氏によって今年の6月に報告された[13]。これは、不正なVBAスクリプトが記述されたAccess 2000のデータベースファイル（拡張子.mdb）をIEでアクセスすることにより、任意のプログラムがクライアントマシン上で起動してしまうというもの。

Access 2000にはデータベースのフォーム中にVBAスクリプトを記述できる。例えばフォームの中で、
    Call Shell("cmd.exe", 1)
のようなスクリプト記述を行なうことにより、mdbファイルを開いた際にcmd.exeを起動することが可能である（図7）。


図7 Access 2000のフォームがロードされる際に、cmd.exeが起動するように記述した例。


このようなmdbファイルをIEでアクセスした場合、通常はファイルダウンロードのダイアログが表示され、直接Accessが起動することはない。しかしWebページ上で、
    <object data="db1.mdb" id="d1"></object>
のようなオブジェクト・タグ記述を行なうことで、このWebページをアクセスした際に自動的にAccessが起動し、db1.mdbを読み込むことができてしまう。

この攻撃についても筆者が試した限り、IEの一般的なセキュリティゾーン設定を厳しく設定しても回避できない。ActiveXコントロールの実行やスクリプト、あるいはファイルのダウンロード全てを無効に設定しても、mdbファイルは実行されてしまう。

この問題に対するワークアラウンドとして、
  • Access 2000の管理者パスワードを設定することにより、Access起動時にログオンダイアログを表示するようにする。
という方法がSecurityFocusに紹介されている[14]。



以上、最近話題になっている各種クライアント・サイド・アタックを解説した。今回特に興味深いのは、HTMLのフレームに表示するためにIEはWindowsの一時ディレクトリ（環境変数TEMPで参照）に既知のファイル名で当該ファイルをコピーするという事実だ。これにより、攻撃者はWebアクセスやHTMLメールによって任意のファイルをクライアントサイドの一時ディレクトリにコピーすることが可能になる。もし一時ディレクトリのパスが推測できれば（デフォルトでは推測は容易）様々な方法の攻撃に利用される危険性がある。

IEやOutlook/Outlook Expressを使用する際には、セキュリティゾーンの設定による保護と併せて、今後は一時ディレクトリのパスを推測困難なものに変更することが求められるであろう。 


[1]  Microsoft Office 2000 UA Control Scripting
     http://www.securityfocus.com/templates/advisory.html?id=2214

[2]  MS00-034: Patch Available for "Office 2000 UA Control" 
     Vulnerability 
     http://www.microsoft.com/technet/security/bulletin/ms00-034.asp

[3]  「Microsoft Office 2000およびOffice 2000ファミリー製品関する
     脆弱性」よく寄せられるご質問について
     http://www.microsoft.com/japan/security/uactrl0515fq.htm

[4]  IE5.0のScriptlet.TypeLib問題
     http://www.trusnet.com/secinfo/docs/scriptlet/

[5]  OUA Vulnerability Proof of Concept
     http://www.l0pht.com/advisories/ouahack/index.html

[6]  IE 5.x allows executing arbitrary programs using .chm files
     http://www.nat.bg/~joro/chm-desc.html

[7]  MS00-037: Patch Available for "HTML Help File Code Execution"
     Vulnerability
     http://www.microsoft.com/technet/security/bulletin/ms00-037.asp

[8]  "HTML Help File Code Execution" の脆弱性に関する英語版修正
     プログラムが公開
     http://www.microsoft.com/japan/security/default.htm#IE0602

[9]  IE and Outlook 5.x allow executing arbitrary programs using 
     .eml files 
     http://www.nat.bg/~joro/eml-desc.html

[10] CA-2000-12 HHCtrl ActiveX Control Allows Local Files to be 
     Executed
     http://www.cert.org/advisories/CA-2000-12.html
     
[11] Force Feeding
     http://www.securityfocus.com/templates/archive.pike?list=1&
     msg=414102.961876827898.JavaMail.imail@goochy.excite.com

[12] Mars
     http://members.xoom.com/malware/mars.mhtml

[13] IE 5 and Access 2000 vulnerability - executing programs
     http://www.nat.bg/~joro/access-desc.html

[14] Microsoft Internet Explorer 5.01 and Access 2000 VBA Code
     Execution Vulnerability
     http://www.securityfocus.com/bid/1398

2000年6月執筆
塩月 誠人
インターナショナル・ネットワーク・セキュリティ株式会社