Windowsのログインパスワードをクラックする羽目になった話

先日クライアントから問い合わせがあり、私の収めたWIn7のパソコンでログインが出来なくて困っていると問い合わせがあった。

話をよく聞いて見ると、パスワードの有効期間をデフォルトの42日のままで出荷していたのだが、
クライアントが納品時に初回ログインして、ウイルスソフトのインストールなど必要設定をしたのち2ヶ月あまり放置しており、
久しぶりに起動したらログインできなくなった、という事情らしい。

パスワードの有効期間が切れた場合、通常ならログイン時に有効期間が切れている旨の通知がされ、新しいパスワードを設定するとログインできるので、クライアントの言う「ログインできない」状態というのが不可解であった。

クライアント曰く「42日を過ぎたから古いパスワードが使用できなくなってしまったんじゃないか」と私側の責任に感じているらしく、ちょっとまずい空気感だなーと重いパスワードを解析させてもらうことになった。

Win7のパスワード解析は初めてで、思ったより勉強になったのでポイントをこちらにまとめて置く。

プラン1:Ophcrack

WindowsXP時代からあるツールとしてOphcrackというツールがある。詳細は他のサイトで解説されているので割愛。
Gigazine:Windowsのパスワードをわずか数分で解析する「Ophcrack」の使い方

こちらのツールを試すが、「not tables found」と表示され、パスワード解析そのものがされていない模様。
調べてみると、そもそもWindowsは”パスワードそのもの”は保存しておらず、パスワードから一意に生成できるハッシュ値のみを保持しており、ログイン認証時には入力されたパスワードから同じようにハッシュ値を生成し、保存されているハッシュ値と一致するかを比較することで、パスワードの正否を確認する仕組みらしい。

そして、ハッシュにはLMハッシュとNTLMハッシュという2種類がある。
LMハッシュは強度が低く、簡単に解析されてしまうのだが、NTLMハッシュは強度が高く、今のコンピュータの処理速度では現実的な時間内には解析できないようなものらしい。

そして、OphcrackはWindowsXP時代のLMハッシュなら瞬殺で解析できるが、NTLMハッシュの場合は4文字までのパスワードしか解析しようとせず、それ以外の場合は解析できないツールらしい。

とういか、今回の場合は対象のパソコンのHDDが暗号化されており、CDブートしてもそもそもディスクの情報が読み取れないというオチ。

うっかりしてました。

プラン2:utilman.exeをcmd.exeに置き換えるハック

これも割りかし昔からある手法だが、utilman.exeをcmd.exeに置き換えることによって、ログインしなくてもコマンドプロンプトを立ちあげられるようにしてしまうというハック。しかし、今回の場合、

  1. パスワード自体を解析したい
  2. HDDが暗号化されているのでそもそもutilman.exeの置き換えができない

という点で却下。

しかし、CDブートからOSのシステムファイルにアクセスするという手法ははじめて知った時には目からウロコで、知っておいて損はないと思う。
詳しく知りたい方は@ITにて解説されているのでそちらを一読すると勉強になると思う。
@IT:パスワードを忘れたWindows 7/8/8.1にログオン(サインイン)する

プラン3:ハッシュ入るを引っこ抜いて、手動で解析する

とうことで、結論を先にいうと、今回は手動で解析することで何とか問題解決。
作業の流れを記すと

  1. SAMデータベース(ハッシュ値が格納されいるファイル)を取得する。
  2. samdump2というLinux用のツールでSAMデータベースからハッシュ値を解析する。
  3. ハッシュ値のマッチングを行うPerlスクリプトを書いて、解析させる。

という流れになる。

1.SAMデータベース(ハッシュ値が格納されいるファイル)を取得する。

SAMデータベースはアクセスできない領域に保存されているため通常の方法はアクセスできない。
そこでCDブートして適当なOSを起動し、そのOSからSAMデータベースにアクセスする手法をとる。

WindowsのOSメディアやなければWinPEという復旧用Windowsを作成する。
WinPEの作成の仕方は例によって@IT様にお任せしよう。
@IT:最強のデータ・サルベージ・ツールWindows PE 3.0

CDブートしたのち、(たぶん)Shift+F11でコマンドプロンプトを立ち上げる。
そして以下のパスにあるSAM、SYSTEMの2ファイルを適当なフォルダ、例えばCドライブ直下にコピーする。

cp C:\Windows\System32\config\SAM C:\
cp C:\Windows\System32\config\SYSTEM C:\

2.samdump2というLinux用のツールでSAMデータベースからハッシュ値を解析する。

続いて、ハッシュ値を取得するのだが、パスワードのハッシュ値はSAMファイルに暗号化された形で格納されており、復号するためにはSYSTEMを用いる。
ここの詳しい暗号化の仕組みについては調べていないが、Linuxのsamdump2というコマンドで暗号化を解除し、ハッシュ値を取得することができる。

ということで、VMPlayerにCentOSのMinimal版を構築し,samdump2をインストールする。

sudo yum -y install samdump2

続いて、CentOSにSAM、SYSTEMを転送し、以下のコマンドでハッシュ値を取得する。

samdump2 SAM SYSTEM

ちなみに、他の文献ではbkhiveというコマンドを使って予め復号のための鍵を取得しておく手順がよく解説されているが、

Error reading ControlSet: _RegOpenKey

というエラーが発生しうまくいかないことがあった。
samdumpのヘルプをよむと直接SYSTEMファイルを食べさせることができるようなので上記コマンドで処理した。
めでたく解析に成功すると以下のような結果が表示される。
<ユーザ名>:<UID>:<LMハッシュ>:<NTLMハッシュ>
という形式で出力されるようだ。
Win7環境はデフォルトではLMハッシュは無効化されているのに、LMハッシュの位置にも何かのハッシュ値が表示されていた。
が、本題には関係なさそうなので無視して次にいく。

Administrator:500:5FE055EE93CA7DB048D7645CD4E30C8G:4FEBC2EC1E27A3168F24289B5850F48G:::

3.ハッシュ値のマッチングを行うPerlスクリプトを書いて、解析させる。

つづいて、ハッシュ値とマッチする文字列を見つけ出す作業だが、どうやらWindowsはMD4というアルゴリズムを用いてハッシュ化している。
詳細は例によって@ITに任せ(ry
@IT:人の造りしもの――“パスワード”の破られ方と守り方

ちなみに今のパソコンのマシンパワーを持ってしてもNTLMハッシュを総当り的にクラックしようとすると天文学的な時間が必要になるので解析はまず不可能。
だが、パスワードに一定の傾向や推測されやすいパスワード(例えば誕生日や辞書に乗っている言葉)に限定できる場合、とたんにパスワード候補の数が絞られるため、場合によっては破られてしまう可能性がある。
今回もまさにその通りで、クライアントのパスワードのタイプミスが原因だろうと推測されるので、クライアントが本来設定する予定だったパスワードの文字列あらNumLockやCapsLockがOnになっていた場合、周辺のミスタイプしそうなキーなどから9万種程度にパスワード候補が絞れたため、その9万種と上記手順までで取得したハッシュ値を照合することにした。そのために以下のようなPerlコードを書いた。

#!/usr/bin/perl
use strict;
use utf8;
use Encode ‘encode’;
use Digest::Perl::MD4 qw(md4 md4_hex md4_base64);

#パスワードパターン
my @pattern = q(x x x x x x x x x x x x x);
my $hash_str = uc “取得したハッシュ値”;

if( scalar @ARGV > 0){
    $hash_str = uc $ARGV[0];
}

foreach(@pattern){
    if( $hash_str eq md4_hex encode(“UTF16LE”, $_ ) ){
        print “HIT!!! => “, $_, “\n”;
        exit ;
    }
}

print “Not Found …\n”;

ポイントとしてはWindowsは内部文字列をUnicode(UTF16LE)形式で保持するため、文字列を正しくエンコードした後にハッシュ値に変換するところくらい。ちなみにWindowsの内部文字列のエンコード形式を単にUnicodeとしか書いていない文献がおおくて、思いの外ハマったのはここだけの秘密。

他にも小さなハマりポイントはあったけど、おおまかにはこうした流れで解決することができた。
結果的には再インストールすることもなく、信用を失うこともなく、解決しめでたしめでたしといったところだ。

ふ~、よかった(*´∇`*;△

  1. #1 投稿者: denki (2015年7月10日 - 9:54 午前)

    クライアント曰く「42日を過ぎたから古いパスワードが使用できなくなってしまったんじゃないか」と私側の責任に感じているらしく
    っていうところが納得いかなかった。なぜクライアントは自分でパスワード変更しなかった事を悪びれもしないのか。

    • #2 投稿者: mevest69 (2015年7月10日 - 3:54 午後)

      怒りからの代償行動だったんだと思います。

      冷静になって考えれば全くもってdankiさんの言う通りなのですが、怒っている人に論理的なツッコミは火に油ですからね。謝って解決出来るなら誤ったもん勝ちと思って接してました。

コメントを残す