Internet Infrastructure Review（IIR）Vol.31
2016年6月13日発行

ランサムウェアの動向

2015年10月から2016年3月までにIIJのWebクローラで検知したランサムウェアの種類と件数を図-15に、ランサムウェアの一覧を表-1に示します。期間当初はほぼすべてがCryptoWall3.0でしたが、2015年10月下旬から11月上旬までの期間でCryptoWall4.0へとバージョンアップしました。また、この時期には少数のTeslaCrypt2.0/2.2も検知されています。特にTeslaCrypt2.2は、メール経由での感染活動も継続しており、日本国内では一時期「vvvウイルス」という名称で話題になりました（※47）。なお、メールの添付ファイルとしては、EXE、JS、DOC（Macro）、SCR及びそれらをZIP圧縮したものなどが用いられていました。これは後述のLockyのケースでも同様です。その後はCryptoWall4.0の寡占状態が続いていましたが、2016年2月上旬を境に極めて短期間のうちに、TeslaCrypt3.0に置き換えられました。以前のバージョンのTeslaCryptにはファイルの暗号化に用いた共通鍵を攻撃者のサーバに伝達するための仕組みに問題があり、公開ツールを用いて復号可能であることが知られていました（※48）が、3.0以降ではこの問題が修正されました。また、2016年2月上旬に検知したLockyは、当時メール経由で大規模に拡散していた（※49）ものですが、Web経由では小規模の検知にとどまりました。TeslaCrypt4.0は2016年3月中旬頃にリリースされ、3.0のバグ修正や暗号化ファイルへの拡張子付与を廃止するなど多少の変更が行われたものです（※50）。なお、TeslaCryptは2016年5月に開発中止が宣言され、その際にマスターキーが公開されたため、ESET社などによってバージョン3.0以降に対応した復号ツールが作成、公開されています（※51）。

拡大する

図-15 IIJ MITF Webクローラが検知したランサムウェアの種類と件数（2015年10月1日～2016年3月31日）

拡大する

表-1 IIJ MITF Webクローラが検知したランサムウェア一覧

動作の流れ

CryptoWall、TeslaCrypt、Lockyなどのランサムウェアが被害者のコンピュータ上で実行されると、次のような過程でファイルの暗号化と被害者への脅迫が行われます。

1.グローバルIPアドレスの確認

一般的なIPアドレス確認サービスに接続してコンピュータのインターネット接続性とグローバルIPアドレスを確認します。これは次に行われる公開鍵のダウンロード処理が行えるかを確認する事前準備と考えられます。CryptoWall3.0は、この処理が実行できない場合、以降の処理が実行されません。また、接続に際してコンピュータのProxy設定を利用するものとそうでないものがあります。なお、CryptoWall4.0やTeslaCrypt3.0/4.0は、このようなグローバルIPアドレスの確認を行いません。

2.サーバとの鍵交換

金銭などを支払った被害者に復号手段を提供するため、攻撃者は何らかの方法で復号手段を手元（支払い手順を実行するサーバ上など）に保持しておく必要があります。LockyやCryptoWallは後述する暗号化の際に必要となる公開鍵をサーバからダウンロードする仕組みであるため、サーバとの接続を妨げることができれば、以降の処理は実行されません。一方、TeslaCryptはあらかじめ実行ファイルにECDH鍵パラメータが埋め込まれているため、サーバとの接続の有無によらず、暗号化が実行されます。

3.VSS管理ファイルの削除

被害者がWindows Vista以降に標準搭載されているバックアップ機能のVolume Shadow Copy Service（VSS）を用いてファイルを復元することを妨げるために、VSS管理ファイルを削除します。UACの設定にもよりますが、初期設定であれば確認ダイアログが表示されます。また、ランサムウェアが管理者権限のないアカウントで実行された場合は、この処理は行われません。

4.対象ファイルの暗号化

拡張子などによって暗号化対象のファイルを選択し、ランダムに生成した鍵を使ってAESで暗号化し、その共通鍵を暗号化したファイルのヘッダ部分に埋め込みます。このとき、TeslaCryptではECDH、CryptoWallやLockyではRSAを用いて共通鍵を第三者に解読できない形にします。

5.脅迫文の表示

Textや、PNG、HTMLなど複数のフォーマットのファイルを表示して、コンテンツが暗号化された旨と、支払い用のWebサーバへの接続手順を表示します（図-16、図-17）。TeslaCryptでは、Webサーバへアクセスすると、お試しで任意のファイルの復号を持ちかけて被害者に暗号化されたファイルをアップロードを促し、暗号化に使った共通鍵の回収を試みます。

対処

ランサムウェアが実行され、コンテンツファイルが利用不能な状態になってしまった場合、自力による復号は非常に困難です。ただし、前述のTeslaCryptのようにマルウェア作成者の不手際や、あるいは鍵情報、ランサムウェアのDecryptorの流出などのために、実効性のある復号ツールが存在する場合がまれにあります。ツールの出自や内容に注意を払う必要はありますが、それらを試行することは選択肢として検討する価値があります。

しかし、残念ながら多くの場合、自力での復号は不可能なので攻撃者の要求を受け入れるか否かの選択しかありません。被害者の業務内容やコンテンツファイルの保存ポリシーにもよりますが、ストレージ故障と同様に機器交換やクリーンインストールで対処することをまず検討すべきです。組織的な観点に立てば、個々のPCのファイルシステムの重要性はそれ程高くない場合が多いのではないでしょうか。一方で、利用不能になったファイルが直ちに人命に関わるようなものであった場合には、攻撃者と取引した事例も存在します（※52）。ファイルの重要度や対価の捉え方、依存する事業の性質にもよるので模範解答は存在しませんが、万が一脅迫に屈するという選択をとる場合には、最低限、次の2点に留意する必要があります。

• 支払いをしてもすべてのファイルが復号されるという保証はない（※53）
• 反社会勢力と取引することになる（事実が公開される可能性がある場合には、相応の説明が必要になる）

なお、攻撃者のサーバに接続した際に、1ファイルだけ、あるいは数ファイルに限って無料で復号すると表示される場合があります。ここでファイルを送信して復号を試す場合は、復号したファイルの内容が攻撃者に漏えいするリスクを受容することになります。

対策

感染を前提とした対策として、ファイルシステムのバックアップが非常に重要です。個々のコンピュータのファイルシステム全体あるいはコンテンツ保存領域、書き込み可能なネットワークドライブについて、定期的なバックアップを実施する運用を推奨します。バックアップファイルが暗号化されてしまう可能性もあるので、例えばファイルサーバの共有ディレクトリとして設定されていないディレクトリやドライブに保存するなど、バックアップファイルは感染が想定されるコンピュータからアクセスできない状態で保持する必要があります。クライアントPCやファイルサーバを仮想環境で運用している場合は、スナップショットによる差分バックアップ機能の活用が効果的です。

Windowsクライアントシステムにおけるマルウェア感染対策ついては、「1.4.2 マルウェアに感染しないためのWindowsクライアント要塞化（前編）」をご参照ください。

要件

OSはWindows 7 SP1以上、各OSのEditionはProfessional（もしくはPro）以上を対象とします。Home Editionでもいくつかの対策については設定可能ですが、ソフトウェアの制限のポリシーやAppLockerのようなプログラムの実行可能範囲を制限するための機能が実装されていないため、ビジネス用途での利用には向かないと判断し、対象外にしています。

前提条件

ここでの説明はドメインに属していないWindowsにてローカルグループポリシーエディターを使用して行っていますが、後述するEMETを含め、Windowsドメインのグループポリシー管理エディターを使用し、配下のクライアントに対して一斉適用することも可能です。また、画像のほとんどはWindows 10 Enterprise Edition 64bitを使用していますが、各Windows のバージョンによって設定できる項目に若干の差異がある場合があります。WindowsはC:\にインストールされていることを想定しています。

基本

まずはソフトウェアをアップデートし、最新に保ちます。

• Windows Update（他のマイクロソフト製品を含む）
• Webブラウザ（FirefoxやGoogle Chromeなどのサードパーティ製品を含む）
• メーラー（Thunderbirdなどのサードパーティ製品を含む）
• Webブラウザプラグイン（Flash Player、Adobe Reader、Java）

この他に利用しているソフトウェアや、出荷時からインストールされているソフトウェアなどがあれば、それらも最新に保ちます。また、不要なソフトウェアは削除しておくとよいでしょう。ウイルス対策ソフトウェアを導入し最新版に保ち、最新パターンファイルに更新します。パーソナルファイアウォールの有効化も必要です。

利用者に管理者権限を与えない

本稿で紹介する対策は管理者権限によって一般ユーザにポリシーを強制し、プログラムの新規インストールを禁止することを前提とした対策を行います。しかし、もし利用者も管理者権限を持っていると、ポリシーを自由に変更してしまうため、一般ユーザ権限のみを付与する必要があります。

アプリケーションホワイトリスティング

Windowsやマイクロソフト社製品標準のプログラムはC:\ WindowsやC:\Program Filesフォルダ以下にインストールされています。また、管理者が用意するプログラムもこれらのフォルダにインストールされることがほとんどです。そこで、これらのフォルダ以外のプログラムの実行やロードを禁止することで、受信したメールにマルウェアが添付されていた場合や、ドライブバイダウンロードによって最終的にマルウェアがダウンロードされた場合に、それらが実行されたりロードされたりすることを防ぎます。この手法はアプリケーションホワイトリスティングと呼ばれ、海外では政府機関などが利用を推奨しています（※54）。ここではAppLockerとソフトウェアの制限のポリシー（SRP）の2つを用いて制限する方法を紹介します。

AppLocker

マイクロソフトは、Windows 7からAppLockerと呼ばれる機能を追加しました。これは、後述するソフトウェアの制限のポリシー（SRP）をより柔軟かつ詳細に管理するための上位版に位置づけられる機能です。Windows 7以降のEnterprise EditionであればAppLockerが使用できます（※55）。

また、許可、拒否のログは共にイベントログに出力されます。イベントビューアーより、アプリケーションとサービスログ、Microsoft、Windows、AppLocker、とたどるとカテゴリごとにログが出力されています（図-22）。

拡大する

図-22 AppLocker - イベントログ

ソフトウェアの制限のポリシー（SRP）

AppLockerがEnterprise Editionのみに付属することからも、マイクロソフトはビジネス環境ではEnterprise Edition を利用すべきであると考えていることが窺えます。しかし、ビジネス用途でWindowsがプリインストールされたクライアントPCを購入した場合、Pro Editionが付属していることがほとんどです。そのため、実際のビジネス環境においてはAppLockerを利用できない場合も少なくありません。また、Windows7より前のOS（Vistaなど）にはどのEditionであってもAppLockerを利用できません。このような場合は、ソフトウェアの制限のポリシーを使用して制限をかけることになります。AppLockerと比較した場合、プログラムの種類別にルールを分けて作成することができない、ライブラリ（DLL）の拒否イベントがログに記録されない、ストアアプリの制御ができない、ルールの強制がカーネルモードではなく、ユーザモードで行われる、ポリシーのインポートができないなど不便な点や機能が欠けている点はありますが、多くの場合でAppLocker同様に有効です（※58）。ちなみにソフトウェアの制限のポリシーとAppLockerを両方設定できるOS上でどちらも設定した場合は、ソフトウェアの制限のポリシーの設定は無視されます。

1. 管理者権限でローカルグループポリシーエディターを起動してください。これはgpedit.mscを実行することで起動することが可能です（図-23）。
2. メニュー左側のツリーからコンピューターの構成、Windowsの設定、セキュリティの設定、ソフトウェアの制限のポリシー、とたどります（図-23）。
3. ソフトウェアの制限のポリシーを右クリックして、新しいソフトウェアの制限のポリシーを選択します（図-23）。
4. 強制をダブルクリックします（図-23）。
5. プロパティが開くので、ソフトウェアのファイルすべてを選択します。また、証明書の規則を適用するを選択し、OKを押してプロパティを閉じます（図-24）。
6. 指定されたファイルの種類をダブルクリックし、プロパティを開きます（図-23）。
7. プロパティでLNKを選択し、削除をクリックします（図-25）。プログラムが制限なしで実行される旨のポップアップが出てきますが、はいをクリックしてポップアップを閉じ、プロパティ画面でOKを押して、プロパティを閉じます。ここでLNKを削除しておかないと、デスクトップ上やスタートメニューなどに存在するすべてのショートカットファイルまでブロックされてしまい、使い物にならないため、ここでは対象から外します。悪意のあるショートカット（LNK）（※59）については、その中に存在するVBScript やJScriptなどが危険であるため、別の対処を行います（この部分については次号のIIRで説明します）。
8. セキュリティレベルをダブルクリックし、許可しないをダブルクリックします。
9. プロパティが開くので、既定値として設定をクリックします（図-26）。一部のプログラムが動作しなくなるという旨のポップアップが表示されるため、はいをクリックしてポップアップを閉じます。プロパティに戻るので、OKを押してプロパティを閉じます。
10. ポリシーを強制したいホストを再起動するか、管理者権限でコマンドプロンプトを開き、gpupdate /forceコマンドを実行すると、ソフトウェアの制限のポリシーが有効になります。

またブロックされた場合のみ、イベントログのアプリケーションに記録されます（図-28）。

拡大する

図-28 SRP - イベントログ

制限回避の脆弱性

マルウェアは一般ユーザ権限で動作した場合、ユーザディレクトリ以下にマルウェアのインストールを試みることが多いため、これらの機能を有効にすれば、多くのマルウェア感染を防ぐことができるでしょう。ただし、初期設定のままではいくつかの脆弱な点が存在します。例えば、C:\Windows\Temp フォルダは、任意のユーザで書き込みと実行が可能であるため、攻撃者がここにマルウェアを生成して実行した場合、初期設定の制限がかかっていても、突破できてしまいます。このようなことがないように、SysinternalsのAccessEnumやAccessChk（※60）のようなツールを使い、実行を許可しているフォルダ以下に一般ユーザが書きこめる場所がないかを調査し、そのフォルダ以下の実行を拒否するルールを追加していく必要があります。また、これ以外にも複数の脆弱性が研究者によって報告されています（※61）。厳密に制限をかけていきたい場合は、これらについても精査し、ルールとして追加をしていく必要があります。

WinSxSフォルダについて

WinSxSフォルダはWindows UpdateのバックアップやWindows の様々な機能（PowerShell、.Net Framework、Hyper-Vなど）が格納されています。機能を有効にするとこのフォルダ内にあるファイルのハードリンクがSystem32フォルダなどに作られるため、ユーザはパスを気にせずに利用できるようになります。ただし有効にする前の状態でも、WinSxSから直接プログラムを実行することは可能です。例えばPowerShellやrundll32.exeなどはこのフォルダ内に存在するため、これらの悪用を防ぐには拒否しておかなければなりません。WinSxS フォルダ以下全体の実行やロードを制限すれば済むのではないか、と考える方もいるかもしれません。しかし、一部のコンポーネントはWinSxS以下に存在するライブラリを直接ロードしていることが、調査した結果分かっています。

AppLockerであれば、実行ファイル（exe）とライブラリ（DLL） のルールを別々に管理できるため、実行ファイルは全体で拒否し、ライブラリについては拒否しない、もしくは一旦すべて拒否しておき、不具合が出たライブラリのみ、ログを確認しながら追加していくという運用が可能です。しかし、ソフトウェアの制限のポリシーはプログラムの種類別に設定することができないため、WinSxS全体を拒否した上で、不具合が出たプログラムのみを部分的に許可するという運用方法しかとれません。しかし切り分けを行う際、ソフトウェアの制限のポリシーによってロードが拒否されたライブラリ（DLL）がログに出力されないため、何を許可して良いのか簡単には分からないという問題も存在します。そこで検証時にWinSxSを許可した状態でSysinternalsのSysmon、Process Monitor、Process Explorer（※62）などを利用してライブラリのロードイベントを記録し、それを許可ルールとして追加するという運用を行うことで、この問題を回避できます。

管理者権限の制限について

AppLockerは既定のルールにAdministratorsグループに属するユーザを許可しています。これらのルールを削除すれば一般ユーザ同様に制限することが可能です。ソフトウェアの制限のポリシーは初期設定ですべてのユーザが対象になっています（図-24）。
《次号に続く》

量子計算機の登場による暗号技術への影響

耐量子暗号（Post-Quantum Cryptography）（※65）は2003年にDaniel J. Bernstein教授によって提唱された概念で、量子計算機の登場に伴い、現在利用されている暗号技術の置き換えを目指す暗号アルゴリズムの総称を指します。Post-Quantum Cryptographyの他にもQuantum Safe Cryptography、Quantum resistant Cryptographyなどの用語が使用されていますが、いずれも同じ概念を指します。

現在公開鍵暗号方式として広く利用されているRSAや（EC） DHは、それぞれ素因数分解の困難性、離散対数問題の困難性が前提となって安全性を担保する暗号アルゴリズムです。現在の計算機アーキテクチャの基ではこれら2つは非常に難しい問題であることが知られています。これに対して1994年に提案されたShorアルゴリズム（※66）は量子計算機を用いることにより、これら2つの問題が多項式時間で解けることが示されました（※67）。そのため現在主流の公開鍵暗号アルゴリズムは量子計算機の登場により脅威に晒されることになります。

では、現在の暗号アルゴリズムはどのくらい使い物にならなくなるのでしょうか？これをビット安全性（※68）という指標を用いて説明することができます。暗号アルゴリズムの強度、もしくは危殆化の進行状況を示す概念として「nビット安全性」という表現が用いられます。パラメータnは当該アルゴリズムの攻撃に必要な計算量が2ⁿ （2のn乗）であることを示しており、共通鍵暗号においては、全数探索に必要な鍵空間の大きさ2ⁿ（nは共通鍵ビット長）に該当します。ハッシュ関数においては出力ビット長がnビットのとき、原像計算困難性に対しては2ⁿ、衝突困難性としては2^n/2が攻撃に必要な計算量の理論値となります。

一般的に、暗号アルゴリズムは徐々に新しいものに移行していく必要があります。NISTによるアルゴリズム移行計画を示すSP 800-131Aは2015年11月に改訂されて、112ビット未満の安全性しか持たないアルゴリズムは利用禁止（Disallowed） となりました（※69）。共通鍵暗号としては2-key Triple-DES（112 ビット鍵を利用しますが総当り方式よりも効率のよい攻撃手法が存在）が除外されています。HMACなどのMAC（メッセージ認証コード）に用いられる鍵長も112ビット以上のみを利用し、署名作成時のハッシュ関数としては既に危殆化したSHA-1 ではなくSHA-2、SHA-3の利用のみとなります（※70）。

公開鍵暗号方式に対しても攻撃計算量を予測することで、それぞれのアルゴリズムに対してnビット安全性を持つ鍵長が定められています。その1つにNISTによるSP 800-57があり2016 年1月に改訂されています（※71）。112ビット安全性は2030年まで有効で、それ以降は128ビット安全性を持つアルゴリズムにシフトすることが想定されています。112ビット安全性に等価な公開鍵としてはRSA-2048、DSA-2048、ECDSA-224、ECDH-224がありますので、これらよりも短い鍵長の利用はすでに禁止されており、2031年以降はRSA-3072、ECDH- 256などへの移行が望まれることになります。

しかし量子計算機が登場すると、これらの想定が崩れてしまいます。それを示す指標の1つに1996年に発表されたGroverアルゴリズム（※72）があります。Groverによると現在のアーキテクチャの計算機でnビット安全性を有していた暗号アルゴリズムは、量子計算機の解読能力によるとn/2ビット安全性しか確保できないことが分かりました。例えば、現在利用されている共通鍵暗号の1つであるAES-128は64ビット安全性しか確保できないことを意味します。そのため128ビット安全性を確保するためには256ビット鍵を利用するAES-256にシフトする必要が出てきます。同様にハッシュ関数においてはSHA-256を署名に利用するケースを考えると、衝突困難性を確保するためには64ビット安全性しか有さないため、SHA-512やSHA3- 512など、出力長として512ビット以上のアルゴリズムを使用しないと128ビット安全性を確保できないことになります。

公開鍵暗号方式においても同様のことを示すことができ、現在256ビット安全性を有すると信じられている鍵長を利用しないと128ビット安全性を確保できません。先程紹介したSP 800-57によるとRSA-15360、ECDH-512などがそれに該当します。更にETSI （European Telecommunications Standards Institute）による2015年6月発行のレポートにおいてはより強いことが示されていて（※73）、上記のように現時点で256ビット安全性を持つと信じられている鍵長を利用したとしても0 ビット安全性であるとの記載があります。

新しい安全性根拠を持つ暗号アルゴリズムの探索

上記の背景のもと、これまでとは異なる安全性根拠を持つ公開鍵暗号アルゴリズムが望まれるようになりました。アカデミアの動きとしては国際会議PQCryptoが2006（※74）年から約1年半ごとに開催されており、前述した会議が第7回目となりました。2013年からETSIはIQC（Institute for Quantum Computing）と共同でIQC/ETSI Quantum-Safe Crypto Workshop（※75）を開催しており、2015年10月の会議では耐量子暗号に関する標準化が必要というコンセンサスを得ました（※76）。本ワークショップは2016年9月には第4回が予定されるなど継続的に情報共有が行われる見込みです。

同様に欧州の動きとしてはH2020 PQCRYPTO projectがあります。H2020（Horizon 2020）（※77）はEUのファンドによる先駆的かつ欧州横断的な研究支援活動で、ECRYPT（European Network of Excellence in Cryptology）及びECRYPT2の活動を支援したFP7の後継と言われています。H2020 PQCRYPTO project（※78）は2015年3月から3年間限定で活動を開始したプロジェクトで、耐量子暗号に関連する研究活動が行われています。活動を開始した半年後の2015年9月には、暫定版ではありますが耐量子暗号アルゴリズムの推奨リスト（ポートフォリオ）の案が既にまとめられています（※79）。

一方で米国ではNISTによる2016年2月のアナウンスに先立ち、2015年4月にPKC2015と併設してNIST主催のワークショップが開催されています（※80）。2015年8月には米国政府調達に利用されるSuite B 暗号リスト（※81）の参照を、特に新たに導入する機器・システムにおいては一旦取りやめるよう要請がありました。また、PQCrypto2016開催の前に3月締切のパブリックコメント（※82）を行い、4月にはNISTIR 8105として第1 版のレポートが発行されました（※83）。2月のアナウンスにおいては2023年から2025年を目処に文書化することを想定し、以下のタイムラインに沿って技術的検証を行うことが示されました。2016年秋を目処に正式なコンペティションの概要が公開され、2017年11月を応募締切とし2018年初頭に応募者によるプレゼンテーションを中心としたワークショップが開催されます。その後、3年から5年程度で技術的解析を行ったあと標準化が行われる見込みです。その際にはAESやSHA-3コンペティションのように1つのアルゴリズムに絞らないことや、NESSIE（※84）のようにポートフォリオ提示に留まらず、きちんと標準化を行うという方向性が提示されています。

耐量子暗号アルゴリズムの有力候補

現在耐量子暗号に用いられると予想されている4つの方式を表-2に提示します。これらは量子計算機が登場しても解読されないと期待されています。

これらのうち、前述したH2020 PQCRYPTO projectによるポートフォリオでは符号理論ベース暗号、ハッシュベース署名がリストされています。一方で日本では格子暗号の解読（※88）が盛んに研究されていますし、日本発で多変数公開鍵暗号のコンペティションが行われています。また、IETFにおいてはCFRG （Crypto Forum Research Group）（※89）にて耐量子暗号の議論が行われており、ハッシュベース署名の1種であるXMSS （Extended Hash-Based Signatures）（※90）の策定が続けられているほか、2016年5月に開催されたEUROCRYPT2016で併設されたinterim meeting（※91）においては暗号のコミュニティからの意見を収集するなどの試みが続けられています。また2016年4月に開催されたIETF-95のCFRG meetingでも耐量子暗号についての議論が行われています（※92）。

NISTの標準化スケジュールを見て分かるとおり、耐量子暗号への移行は喫緊に対応すべき課題ではなく中長期的な視点での対応が望まれます。新しい安全性根拠に基づいた暗号方式であることから、まずはどのくらいの強度があると見積れるのかについて調査する必要があります。そのため表-2に示されるように各種コンペティションが行われていて、より効率的な攻撃手法について研究が進められている状況です。一方で、ある鍵空間から秘密鍵を選択して、当該鍵のみでしか復号することのできない落し戸付き関数を定義する計算量的な安全性に基づく方式ではなく、情報理論的に安全な方式についても研究が進められています（※93）。いずれの選択肢においても、運用コストや実用性を鑑みて緩やかに移行していく必要があり、今後の動向についてキャッチアップしておく必要があるでしょう。

拡大する

表-2 耐量子暗号の分類