Hatena::ブログ(Diary)

セキュリティは楽しいかね? このページをアンテナに追加 RSSフィード Twitter

2008-03-01

EFSで暗号化されたファイルを復号するには?またはWindowsのパスワードをクラック(リカバリー)する方法

EFS(Encrypting File System)はWindows2000(NTFS5)以降のOSに標準で実装されている暗号ファイルシステムである。フォレンジック調査では時々EFSファイルを復号して調べることが必要になる。対象ファイルを利用しているユーザーが協力してくれてファイルの暗号化を解除してくれればよいが、そうでない場合にはなんらかの手段で解除を行わなければならない。ということでその方法についてまとめておく。


(注意)上記のような場合だけでなく、なんらかの手段で暗号化されたファイルを取得した第三者が、不正に解除を試みることも想定される。ユーザーはこうしたリスクも想定してどのような脅威があるのかを正確に理解しておくことが重要だ。ここでは暗号化解除を試みる側を「攻撃側」、暗号化を行ったユーザーを「防御側」と表現する。ユーザーは、フォレンジック調査で復号を行う場合には攻撃側として、自分のPCから情報が漏洩するのを防ぐ場合には防御側としてふるまうことになる。

EFSの仕組み

EFSの仕組みの詳細についてはマイクロソフトのサイトを見てもよいが、下記のサイトの情報が非常によくまとまっているのでお勧めしておく。かなり詳細かつ正確に記されており、とても参考になる。

上記サイトの説明にもあるように、EFSで暗号化されたファイルにはFEK(File Encryption Key)が付加されている。この鍵はファイル毎に異なっており、OSが自動で生成する。共通鍵暗号方式が採用されており、OSのバージョンによって異なるアルゴリズム(DESX, 3DES, AES)が使われている。暗号化されたファイルにその鍵も一緒についているわけだが、もちろんこの鍵(FEK)は別の鍵(ユーザーの公開鍵)で暗号化されている。EFS用のユーザーの公開鍵/秘密鍵のペア(RSAを利用)は最初にEFSを使用して暗号化を行う際に自動的に生成される。そして最後にユーザーの秘密鍵はユーザーのマスターキーで暗号化される。そしてこのマスターキーはそのユーザーのパスワード暗号化されている。


まとめると、こういう関係になっている。

暗号化ファイル <= FEK <= ユーザーの公開鍵 <=> ユーザーの秘密鍵 <= マスターキー <= パスワード

A<=BはBの鍵でAを暗号化すること、A<=>BはAとBがRSAの鍵ペアであることを表している。FEKはファイル毎に異なるがそのほかはユーザーに固有のもので共通である。なおここでは混乱するので、回復エージェントについては考慮していない。またマスターキーはSYSKEYでも保護されるのだがここでは無視する。


ちなみにユーザーの秘密鍵とマスターキーは以下の場所に保存されている(usernameとsidはそれぞれ環境によって異なる)。マスターキーは90日毎に自動的に再生成されるので複数あるはずだ。

  • 秘密鍵 C:\Documents and Settings\(username)\Application Data\Microsoft\Crypto\RSA\(sid)\
  • マスターキー C:\Documents and Settings\(username)\Application Data\Microsoft\Protect\(sid)\

EFSの暗号化を解除する

フォレンジック調査の場合、HDDイメージ全体にアクセスできるのが普通である。そのためここでは攻撃側はHDD内のファイル全てにアクセスできるものとする。すると、暗号化の解除に必要な鍵ファイルは全てHDD内に含まれているわけだから、攻撃側はユーザーのパスワードさえわかれば、あとは芋づる式にファイルを復号できることになる。

(注意)ユーザーの秘密鍵エクスポートしてHDD内から削除したり、マスターキーを保護しているSYSKEYのモードを2にしてSYSKEYパスワードを設定したりすると、ユーザーのパスワードだけでは復号できない。が、ここでは無視する。


ということで結局、上記のような状況においては、「EFSの暗号化を解除すること」=「ユーザーのパスワードクラックすること」と言い換えることができる。ユーザーのパスワードさえわかれば、PCにログインしてファイルにアクセスすることもできるし、Advanced EFS Data Recoveryのような専用ソフトでEFSの暗号化を解除することもできる。

Windowsパスワードクラックする

攻撃側は目的のファイルの暗号化を解除するために、ユーザーのパスワードクラックしなくてはならないが、ローカルアカウントドメインアカウントではその方法は異なる。これはパスワードハッシュの保存方法が異なるからである。順に見ていこう。

ローカルアカウント

ローカルアカウントの場合、パスワードハッシュはSAM(Security Account Manager)というレジストリ(SAMファイル)に保存される。SAMはシステムキー(SYSTEMファイル)で暗号化されているが、どちらのファイルもHDD内(C:\Windows\system32\config\)に含まれるので、容易に復号してパスワードハッシュを取得できる。(SYSKEYモードが2または3の場合を除く)


SAMに保存されているパスワードハッシュには2つの形式がある

LM Hash
LanManハッシュと呼ばれるもので、Windowsの脆弱なパスワード方式の代名詞みたいになっている。最長で14文字まで、アルファベットの大文字と小文字を区別しない(すべて大文字になる)、使用できる文字セットに制限がある、7文字ずつに区切られてハッシュ値が生成される、ソルトがない、などダメダメな仕様をもっている。パスワードのパターンは全部で7兆5千億くらいしかない。14文字のパスワード(これより短い場合にはパディングされる)を7文字ずつにわけ、それぞれを鍵としてDESで固定文字列を暗号化した結果をパスワードハッシュとして保存する。一方向ハッシュ関数は利用していないので、厳密にはハッシュではない。LM Hashはこのあと述べるように簡単にクラックできる。
NT Hash
最長127文字まで、Unicode文字も使用できる(Altキーを使って入力する)、パスワード全体からMD4でハッシュ値を生成する、などの特徴をもっている。相変わらずソルトはないが、パスワード総数はほぼ無限大。そのため比較的長いパスワードであればクラックするのは不可能といえる。

下位互換性を考慮してデフォルトでは両方のハッシュ形式で保存されているが、LM Hashが対応していない15文字以上のパスワードを設定するか、レジストリの設定を変えることで、LM Hashを保存しないようにすることもできる。(しかし現実にはLM Hashが保存されていないケースにお目にかかることはほとんどない。)


LM Hashが保存されている場合、ほぼ100%パスワードクラックは可能である。これはパスワードの総パターン数が非常に少ないためである。しかもRainbow Tableを使うことにより比較的短時間で解析することができる。LM Hashの全パターンに対応したRainbow TableはInternetから入手することができる。もちろん自分で生成することも可能だ。データサイズも全部で数十GB程度にしかならない。Rainbow Tableでパスワードクラックするには、Rainbow Crack、ophcrack、Cain&Abelなどのツールを使う。


LM Hashが保存されていない場合、NT Hashを対象にクラックすることになる。これはLM Hashと比較して格段に難しい。パスワード長が7文字程度までで、Unicode文字などの特殊な文字を含んでいなければ(つまりLM Hashと同じような条件であれば)、Rainbow Tableで対応できる。そうでない場合には、辞書攻撃やブルートフォース攻撃で地道にやるしかない。容易に推測できるようなパスワードが設定されていなければ、これでクラックできる可能性はかなり低いだろう。ちなみに容易に推測できない強いパスワードというのは、パスワードが十分長いためにブルートフォース攻撃に時間がかかり、推測できるような単語が含まれないために辞書攻撃にも耐えられるパスワードのことである。なお攻撃用のツールとしては、John the Ripperや Cain&Abelなどがある。

ドメインアカウント

ドメインアカウントの場合はローカルアカウントとは少し状況が異なる。オリジナルのパスワードハッシュActive Directoryに保存されている。しかし、クライアントPCが常にネットワークに接続されていてADと通信できるわけではない。そのためこのような状況でもログインできるように、PC内にはパスワードハッシュキャッシュとして保存されている。ここではこのキャッシュされたハッシュを攻撃対象とする。


パスワードハッシュレジストリ(HKLM\SECURITY\CACHE\NL$n)に保存されているが、LSASS(Local Security Authority System Service)によってRC4暗号化されており、そのままではクラックできない。そこでまずこの暗号化を解除してパスワードハッシュを抽出することが必要になる。SYSTEM HiveファイルとSECURITY Hiveファイルがあれば、Cain&Abelなどのツールでハッシュを抽出することができる。


抽出されたハッシュドメインアカウントパスワードからMD4でハッシュ値を生成したものだが、ローカルアカウントのNT Hashとは異なり、ソルト処理されている。ソルトにはドメインアカウントのユーザー名が使われている。そのため、Rainbow Tableのようにあらかじめハッシュ値を計算しておくことはできない。したがって、キャッシュされたドメインアカウントパスワードハッシュを解析するには、辞書攻撃やブルートフォース攻撃を行うことになる。NT Hashの解析と同様に、容易に推測できるようなパスワードが設定されていなければ、これでクラックできる可能性はかなり低い。


なお、ドメインアカウントパスワードハッシュキャッシュするかどうかは、レジストリの設定で変えられる。そのため、常にADに接続できる環境(例えばイントラネット内のデスクトップPCやサーバなど)では、キャッシュしないように設定してもよい。

回復エージェント

ここまでの議論では回復エージェント(Data Recovery Agent)については無視してきたので、ここで少し補足しおく。FEKはユーザーの公開鍵で暗号化されるが、実は回復エージェントの公開鍵でも同時に暗号化される。そのため、このファイルはユーザーの秘密鍵と回復エージェントの秘密鍵のどちらでも復号できる。したがって調査対象のPCで回復エージェントが設定されていたかどうかは重要なポイントである。


回復エージェントのデフォルトの設定は、そのPCがドメインのメンバーか、そうでないかによって異なる。またOSのバージョンによっても変わる。まずドメインメンバーのPCの場合には、いずれのOSにおいても、ドメイン管理者のアカウントが回復エージェントとして自動的に設定される。一方、ドメインメンバーではないPCの場合、Windows2000ではローカルの管理者アカウント(Administrator)が回復エージェントに設定される。しかしWindowsXP以降はこれが変更され、デフォルトでは回復エージェントは設定されない。


回復エージェントが設定されている場合、攻撃側は暗号化したユーザーか回復エージェントに指定されているアカウント(例えばAdministrator)のどちらか一方のパスワードがわかればファイルを復号できる。

パスワードリセット

もう一つ、パスワードクラックではなく、パスワードのリセットについても補足しておく。これはローカルアカウントに限った話だが、パスワードをリセットすることは比較的簡単にできる。一番簡単なのはSAMファイルを消してしまうことで、この場合には次回起動時に自動的にSAMが再生成され、アカウントパスワードは空にリセットされる。そのためローカルアカウントパスワードなしでログインすることができる。なおこの方法では、再生成されるのはAdministratorとGuestのデフォルトアカウントだけである。ntpasswdなどのツールを使えば、既存のアカウントパスワードをリセットしたり、特定のパスワードを再設定することもできる。しかし、これまでの話でわかるように、EFSファイルを暗号化している鍵はユーザーのパスワード暗号化されており、パスワードをリセットできても、EFSファイルを復号することはできない。

まとめ

EFSで暗号化されたファイルを復号するには鍵が必要だが、鍵ファイルが全て入手できる状況では、結果的にユーザーのパスワードさえわかればよい。そこでパスワードクラックすることが必要となる。


ローカルアカウントの場合、SAMに保存されたパスワードハッシュを解析する。LM Hashが保存されていればほぼ間違いなくパスワードは判明する。しかし、LM Hashが保存されておらず、容易に推測できないパスワードが設定されている場合にはパスワードを解析することは難しい。(現実的な時間では解析できない。)

ドメインアカウントの場合、通常はPC内にキャッシュされたパスワードハッシュが保存されているため、これを解析する。しかしこのハッシュはユーザー名でソルト処理されているため、事前にハッシュ値を計算しておくことはできない。NT Hashと同じく、容易に推測できないパスワードが設定されている場合にはパスワードを解析することは難しい。


いずにせよ、EFSで暗号化されたファイルが復号できるかどうかは、ユーザーのパスワードの強度に依存している。

さいごに

長々と書いてきたが、これらの内容はいずれも何年も前から良く知られている事実で、特に目新しいものはひとつもない。しかし、私の感覚では今でも一般のユーザーにはあまり知られていないように思う。フォレンジック調査は誰もがやるものではないかも知れない。しかしPCの盗難や紛失などのリスクはどんなユーザーにもあり、防御側として考えた場合、どのような攻撃方法が存在するのかについて知ることには意義があると思う。

Technorati: , , , , ,

ccicci 2008/03/03 21:45 LM Hashを保存しない運用がないのはなぜなんでしょうか.単に設定忘れが多いということですかね.
内部調査でパスワードを教えてくれないユーザがいると,それだけ「特異点」になってしまう(疑われてしまう)のでそのようなケースは実際は少ないように思えるのですが,実際どのくらいあるのですか?また,社内ポリシーとしてパスワードを開示する規定を作っている会社って少ないのでしょうか?
質問ばかりですいません.実際のインシデントに対処したことがないのですごく興味があります.

ukky3ukky3 2008/03/03 23:46 私もそれほど多くの事例を知っているわけではないのですが...

LM Hashについては、かなりセキュリティを意識している会社でもわざわざ設定しているところはあまり見かけませんね。設定忘れと言うより、単に知らないだけなのではないかと思っています。あとは下位互換性の観点から、社内に古いOSのサーバが残っていてLanMan認証を使っているというケースがもしかしたらあるのかもしれません。

「ユーザーがパスワードを教えてくれない」と言うのはちょっと正確ではなかったかも知れません。私が知っている例だと、パスワードを知らせないまま会社を辞めていなくなっちゃったりするんですよ。まあデータを全部きれいさっぱり消去していなくなるよりはまだましですが。

またパスワード設定に関するポリシーはあっても、開示について規定しているところって聞いたことないですね。そういう問題点の指摘自体がまだ一般的でない気もします。

あんまり参考にならない情報ばかりですいません。

ccicci 2008/03/05 00:51 なるほど互換性の問題もあるんですね.

「インシデント時のパスワード開示については社内ポリシーとして規定する」ということをいくつかの文献で見かけたことがありますが,洋書もしくは翻訳書なので日本では稀なのかもしれません.

ありがとうございました.

ukky3ukky3 2008/03/05 23:05 「インシデント発生時のパスワード開示」については、なかなかおもしろいテーマなので、どこかでちょこっと調べてみます。貴重なコメントありがとうございます。またよろしくお願いします。

はてなユーザーのみコメントできます。はてなへログインもしくは新規登録をおこなってください。

Connection: close