Windowsは非管理者権限でログオンしていればどの程度安全か？　ほか

　2月のセキュリティの話題としては、まず日本国内では引き続きフィッシングが多発している状況が報道されています。

　また、Internet Explorer 9/10を対象としたゼロデイ攻撃が発生し、特に日本が標的になっているとの発表がセキュリティベンダーからありました。

　海外では、1月に世界中で広く注意喚起されていた「NTP増幅攻撃」について、ヨーロッパで大規模な攻撃が確認されたとの報道がありました。報道によれば、2013年3月に発生したSpamhausに対するDDoS攻撃の300Gbpsを大幅に上回る400Gbpsを超える過去最大規模の攻撃だったようです。

韓国未来創造科学部、ソフトウェア自動更新機能のセキュリティガイドライン

　近年、OSだけでなく、ウェブブラウザーをはじめとするユーザーアプリケーションも自動更新機能を搭載しているものが増えており、また、この機能は脆弱性対策の観点からも標準で有効に設定されていることが多いです。

　そのような中、自動更新機能を悪用した攻撃も増えてきており、特に韓国では、2009年の「7・7DDoS大乱」をはじめ、2011年の農協金融ネットワーク麻痺事件、2011年のSKコムズ個人情報流出事件、2013年の「3・20大乱」など、この数年で起きた大規模インシデントの多くが、このような自動更新機能が悪用されたものでした。

　この事態に韓国未来創造科学部は、国家保安技術研究所とともに韓国内の主要ソフトウェア製品の更新システムを調査・分析し、その際の調査結果をもとに開発者に向けた「更新システムのセキュリティガイドライン」を作成し、公開しました（本稿執筆時点では韓国語版のみ）。

　ガイドラインでは、韓国以外のソフトウェアを含め、実際の更新システムにどのようなものがあるかを紹介しているほか、そのようなシステムにおいてどのような脅威が想定されるか、また、その脅威に対してどのような対策が有効かを紹介しています。

　ガイドラインの結論として挙げられている対策法は、いずれもセキュリティの専門家にとっては当たり前の内容ですが、実際には対策されていないソフトウェアが少なくないようです。また、すぐに対策するには難しい点もあり、そのような「短所（導入を妨げる要因）」についても説明されているなど、セキュリティの専門家でない開発者向けの資料として比較的現実的な内容となっています。ガイドライン自体は韓国内で開発されたソフトウェアを対象としていますが、韓国以外でも十分に使える内容であることから、今回はその概要を簡単に紹介したいと思います。

　まず、既存のソフトウェア更新システムの問題点として以下の4点が挙げられています。

1）相互認証保障技術未適用

　更新サーバーとクライアントとの間で相互認証する機能がないため、クライアントが偽サーバーに接続して更新が実行されてしまうケースがある。

　韓国で2011年に起きたSKコムズ個人情報流出事件は、DNSスプーフィングで偽の更新サーバーにアクセスさせられたことが原因とされている。

2）通信チャネル保護技術未適用

　更新サーバーとクライアントの通信チャネルが十分に保護されておらず、平文または簡易な保護手段でやり取りされているケースがある。この場合、更新に関連した重要な情報や通信プロトコルを攻撃者が傍受し、更新システムの攻撃に悪用する可能性がある。具体的には以下のようなケースがある。

• 更新情報ファイルおよび実行ファイルを暗号化せずに平文で伝送
• 更新情報ファイルをXORエンコーディングで伝送
• 更新情報ファイルおよび実行ファイルをよく知られたアルゴリズム（zip、bzip2、cabなど）で圧縮
• 更新サーバーとクライアントの間の通信プロトコルが分析可能

3）機密性保障技術未適用

　更新に関連した重要な設定ファイルやインストールファイルが保護されずに平文の状態でクライアントの一時フォルダやインストールフォルダに保存される、または簡易な保護手段で保存されるケースがある。この場合、攻撃者がこれらのファイルを解析することで更新システムの仕組みを知り、攻撃に悪用する可能性がある。具体的には、更新情報ファイル（*.xml、*.iniなど）や実行ファイル（*.exe、*.dllなど）が暗号化されずに平文で保存されているケースがある。

4）低水準の完全性保障技術の適用

　更新情報ファイルや実行ファイルについて完全性を検証しない、または検証していても安全でない方法を使っているケースがある。例えば、以下のようなケースがある。

• 更新情報ファイルと実行ファイルの両方に対して完全性を検証しない
• 更新情報ファイルは完全性を検証するが、実行ファイルは検証しない
• 実行ファイルは完全性を検証するが、更新情報ファイルは検証しない
• 実行ファイルは完全性を検証するが、実行ファイル以外のファイル（Flash、画像、設定ファイルなど）は検証しない（不正に更新された画像ファイル経由でマルウェア感染した被害事例あり）
• 単純なXORエンコーディングで更新情報ファイルの完全性を検証
• MD5などのハッシュで更新情報ファイルと実行ファイルの完全性を検証
• MD5などのハッシュと対象鍵暗号（AES）で実行ファイルの完全性を検証

　韓国で起きた2009年の7・7DDoS大乱や2013年の3・20大乱などは、更新ファイルの完全性を検証する仕組みがあれば防げた可能性がある。

　これらの問題点を踏まえ、ガイドラインではソフトウェア更新システムの「セキュリティ10カ条」を提示しています。

1. （必須）更新設定ファイルのデジタル署名検証
2. （オプション）更新設定ファイルの暗号化
3. （必須）実行ファイルのデジタル署名検証
4. （必須）非実行ファイルのデジタル署名検証
5. （必須）自社製品だけでなく同梱されている他社製品についても同様に完全性を検証
6. （オプション）PKIベース（例：SSL）の通信チャネル保護
7. （オプション）更新サーバーのアドレスの完全性検証
   →更新サーバーのURL（クライアントからの接続先）は、設定ファイルなどの外部から読み取る形式ではなく、ソースコード上に固定する。
   →外部から読み取らざるを得ない場合はサーバーのホスト名（FQDN）やドメイン名を厳密に限定する（文字列比較の厳密化）。
8. （必須）証明書の状態（有効期間、認証パスなど）検査
9. （オプション）実行ファイルの難読化
10. （必須）自動更新セキュリティ不備時に機能削除
    →上記の必須項目が不備な場合には自動更新機能を止め、ユーザーが手動でダウンロード／インストールする方法に誘導し、その上で署名を検証するようにユーザーに指示。

　ガイドラインでは上記10カ条の各項目について、より具体的に説明していて、例えば「署名は更新サーバー上で行わない」「複数のファイルをアーカイブしたものに署名するのもよい」など細かいところまで紹介しています。また、そのような手法を採用する上での注意事項なども掲載しています。

　紹介されている対策方法そのものには特に目新しいところはないですし、現実的には少々「やり過ぎ」と思える点も（またその逆も）ないではないですが、このガイドラインを参考に、開発および更新システムの運用の現場ではチェックリストを作るとよいかもしれません。

Windowsは管理者権限のないユーザーでログオンしていればどれくらい安全か？

　一般的に、管理者権限のないユーザーの権限でコンピューターを利用する方が、管理者権限のあるユーザーで利用するよりも「安全」とされていますが、Microsoft Windowsにおいて具体的にどの程度「安全」になるのかを調べた結果が公開されました。

　これは、米セキュリティベンダーのAvectoが、2013年にMicrosoftが公開した脆弱性情報全333件を分析したもので、調査レポートによれば、これらの脆弱性のうち60％が、管理者権限のないユーザーでリスクを軽減（mitigate）でき、さらに、最も深刻な「緊急（Critical）」レベルの147件に絞れば92％が軽減できるとしています。

　また、Windows OSに限定すれば「緊急」レベルの脆弱性の96％が軽減され、Internet Explorerについてはレベルに関係なく100％すべての脆弱性が軽減できるという結果が出ています。

　セキュリティにかかわる者にとっては、ある程度予想通りの結果とも言えますが、それでも90％を超える数字が具体的に示されているのは興味深いです。

　しかし、だからと言って管理者権限さえなければ安全というわけではありません。注意しなければならないのは、今回の調査結果があくまで現時点で公開されている情報に基づけば「軽減される“可能性がある”（could be mitigated）」としているだけで、危険を確実に回避できることを保証しているわけではないという点です。また、管理者権限がなくても何らかのユーザー権限を奪取してしまえば、そこから別の脆弱性を使うなどして権限昇格し、管理者権限を取得することも可能なことはよく知られています。つまり、通りすがりの攻撃は防げる「かも」しれませんが、本気で攻められればダメなことに変わりはないのです。

　今回の調査レポートは、管理者権限のないユーザーでの利用を推奨する際の参考資料に使うにはいいのですが、逆に、管理者権限さえなければOKという誤解を生まないような注意が必要でしょう。