検索
連載

魂、奪われた後――弱いパスワードの罪と罰セキュリティ対策の「ある視点」(8)(4/4 ページ)

ユーザー名が知られることは魂を奪われるのと同義。そしてその魂、管理者権限を奪うと、彼らはパスワードハッシュを丸裸にしていきます。

Share
Tweet
LINE
Hatena
前のページへ |       

それでも判明できない理由

 さて、先ほどのJohn The Ripperの結果だが6つのユーザーのパスワードのうち完全に復元することのできたものは、4つであった。「king」と「joker」のパスワードは、一部は復元されているものの、すべては判明していない。

 このような場合は、残された手段は、総当たりという力技しかない。だが、John The Ripperの総当たりモードですべての文字種を試すとしてもいつまでに復元できるという保証はまったくないのである。

 これがどの程度の計算量が必要なのかを見てみよう。アルファベットの大文字と小文字、数字、記号(スペースを含む)を使用している可能性があるパスワードで使用可能な文字種の数は、以下のようになる。

26 * 2 + 10 + 33 = 95

 1文字のパスワードでも95通りのパターンが存在する。これが、文字数が増えるにつれ文字数分のべき算をすることとなる。8文字のパスワードの場合は

95 * (95 ^ 8 - 1) / ( 26 - 1) = 6634204312891000

である。もはや、いくらか即答できない数字である。この数字に対して、1日に60億パターン試行できるとしても、すべてを試行するには3000年以上かかることになる。まったくもって現実的ではない。

 しかし、ペネトレーションテストの現場は、これに対してあきらめの姿勢ではない。奥の手もあわせて紹介しよう。

逆転の発想――Rainbow Crackによるパスワード復元

 「Rainbow Crack」は、LM、MD5、SHA1に対応したオフラインパスワードクラッカーである。John The Ripperとは何が異なるのかというと、John The Ripperが試行するパスワード文字列をリアルタイムにハッシュ化して、ハッシュ化されたパスワードと比較し、復元を試みるのに対して、Rainbow Crackは、あらかじめハッシュ化されたデータ(Rainbow Table、以下RT)を用意しておき、それとハッシュ化されたパスワードとの比較を行うという方法で復元を試みる。つまり、リアルタイムではなく、あらかじめハッシュ化したデータを使用している分、劇的とも呼べる速度で復元を行うことができるのである。

 ただし、素晴らしいメリットだけではない、あらかじめRTを用意しなければならないことがデメリットである。パスワードのけた数、使用する文字種が増えるにつれ大きなサイズのRTが必要となる。RTは自身のコンピュータで生成、またはダウンロードする必要があるので、RTを用意するだけでもかなりの時間を要する。ちなみに、筆者が利用しているすべての文字種(95文字)、7文字分に対応したRTは約64Gものサイズとなる。

 すべての文字種といかないまでも、RTの作成にチャレンジしたいと思う読者の方もいらっしゃると思う。今回は持ち運びのことも考え、DVD1枚サイズで収まるalpha-numeric、つまり、大文字と小文字の英字と数字で構成されたパスワードであれば、復元することができるRTの作成方法を以下に示しておく。

rtgen lm alpha-numeric 1 7 0 2400 40000000 all
rtgen lm alpha-numeric 1 7 1 2400 40000000 all
rtgen lm alpha-numeric 1 7 2 2400 40000000 all
rtgen lm alpha-numeric 1 7 3 2400 40000000 all
rtgen lm alpha-numeric 1 7 4 2400 40000000 all


 上記コマンドのそれぞれを実行し、5つのファイルが作成できたらrtsortコマンドに引数としてそれぞれの作成したファイルを指定し、ソートを行う。例えば、上記一番上のコマンドで作成したファイルに対して、実行するコマンドは、以下のとおりである。

rtsort lm_alpha-numeric#1-7_0_2400x40000000_all.rt


 ソートが完了したら、復元に用いることが可能な状態となる。

 それでは、筆者の手元にあるすべての文字種に対応したRTを使用して、先ほど復元できなかった2つのユーザーのパスワードに対して復元を試みた結果を見てみよう。

図9 記号を含んだパスワードも復元されていることに注目
図9 記号を含んだパスワードも復元されていることに注目

 当然といえば当然なのだが、上図のようにパスワードの復元に成功した。これで、取得されたすべてのユーザーのパスワードの復元に成功したといえる。

パスワード復元の実態をどう生かすべきか

 今回解説した、ペネトレーションテストにおける侵入後の活動はいかがだっただろうか。

 侵入後の活動は、お客さまの要望や対象のOSやアプリケーションの環境などによって変化するため、今回紹介した流れはそのごく一部なのだが、Windows系OSへの検査の場合のスタンダードなものであると筆者は考えている。

 今回の記事では、筆者なりに細かく書かせていただいたつもりである。実は、それには、理由がある。

 今回、紹介している手法は、何もペネトレーションテストを行う人間や攻撃者のみが用いて有益なものではない。この記事を読んでくださっている中には、サーバ管理者の方もいらっしゃるだろう。管理者の方の中には、パスワードポリシーを設定し、ある程度の強度を持ったパスワードの使用をユーザーに要求している方も多いかもしれない。

 ただ、そのパスワードの内容までを把握しているだろうか。

 設定されているパスワードの中には、パスワードポリシーを満たしていたとしても、内部の情報を知っていればある程度、容易に想像がついてしまうような「ある意味安易な」パスワードが存在する可能性は大いにある。

 そこで、社内での承認を取ることが大前提ではあるが、今回の記事を参考に、社内のパスワード監査を行ってみてはいかがだろうか。パスワード復元ツールを監査ツールとして利用すれば、先に挙げたような、DVD1枚に収まるRTで復元できてしまうパスワードを使用しているユーザーがどの程度存在するのか? などといった基準を設けることもできる。社内での承認が難しい場合は、これらのツールのデモンストレーションを行うことで、「安易なパスワード」の実態を体験してもらうことは価値があるだろう。

 検査、攻撃を行う者の視点を利用し、自身の管理するネットワーク、コンピュータのセキュリティレベルを向上させていただければ幸いである。

著者紹介

NTTデータ・セキュリティ株式会社

辻 伸弘(つじ のぶひろ)

セキュリティエンジニアとして、主にペネトレーション検査などに従事している。

民間企業、官公庁問わず多くの検査実績を持つ。

自宅では、趣味としてのハニーポットの運用、IDSによる監視などを行っている。



Copyright © ITmedia, Inc. All Rights Reserved.

前のページへ |       
ページトップに戻る