概要

本記事ではペネトレーションテストの有効性とその限界について考察する。

ペネトレーションテストは侵入テストとともいわれ、指定のサーバに侵入が可能かを調査するサービスである。

テストを依頼されたベンダーは、指定されたサーバに対して様々なテストを行う。どの様なポートが開いているか？動作しているサービスは何か？サービスに脆弱性はないか？脆弱なパスワードは使われていないか？...etc.

これらの多くのテストはサイバー犯罪者が行うものと同じ手順で行われ、実際の攻撃に対する抵抗力を測るのに最適である。

また、ペネトレーションテストには「〇〇と✖✖をすればいい」という明確な定義はないが、一つの基準としてNIST-SP800-115がある。NIST-SP800-115はアメリカ国立標準技術研究所が発行した情報セキュリティテストのガイドラインである。本資料に沿う形でテストを行っているベンダーが多いと考えられる。

本記事ではガイドラインから３つの視点に絞ってペネトレーションテストの効果と限界点について考察する。その３つは「パスワードクラッキング」「脆弱性攻撃」「ソーシャルエンジニアリング」である。

先に結論を書くと、ペネトレーションテストの有用なテストではあるが、システムの安全性を保障しているわけではないと私は考える。

パスワードクラッキング

パスワードクラッキングは、公開されたサービスの認証処理に不正に侵入する攻撃である。

特にIDとパスワードで認証可能なサービスが狙われる。なぜなら公開されたパスワード認証のサービスというのは、誰であっても認証情報の入力を試行することができるからだ。生体認証やクライアント証明書に比べ攻撃準備が必要ないため、攻撃者はサーバに対して、まずこのパスワード認証サービスへのパスワードクラックを実施する。

まずは代表的なパスワードクラックの手法を紹介しよう。

総当たり攻撃：

ID及びパスワードの全ての組み合わせを試す方法だ。例えば、「ID=a, パスワード=a」から「ID=ZZZZZZ.....ZZZZZ, パスワード= ZZZZZZ.....ZZZZZ」までの存在しうるあらゆる組み合わせを試す。この方法は理論上いつか正解にたどり着くが、莫大な組み合わせの認証情報を試す必要がある。現実的な時間では解析不可能なため、用いられることはほとんどない。

辞書攻撃：

よく使われるID(admin、user)と、使用頻度の高いパスワードや辞書に載っている単語を組み合わせる方法だ。総当たり攻撃に比べて試行回数を大きく減らすことができ、また脆弱な認証情報を利用しているユーザを効率的に見つけることができる。

リスト型攻撃：

別サービスで流出した有効なID/パスワードの組み合わせを、対象サービスに試す方法である。多くの人は、ID/パスワードの組み合わせを複数のシステムで使いまわすため有効な攻撃となる。この攻撃は1つのIDに対し１つのパスワードを試すためアカウントロックのようなパスワードクラック対策が有効に作用しないという特徴もある。

ペネトレーションテストにおけるパスワードクラック

ペネトレーションテストでは多くの場合「辞書攻撃」でテストを実施する。なんらかの形で調査・推定したIDと、よく利用されるパスワードTop1000や、対象企業ごとに利用していそうなパスワードリストの組み合わせを使うことが多いだろう。

これらの調査ではデフォルトID・パスワードの組み合わせや空パスワードといった、脆弱すぎる認証情報が登録されたサービスを見つけることができる。

しかし、本テストの目的は「脆弱な認証情報の発見し、サーバ侵入の足掛かりにすること」であり、すべてのユーザの認証情報が強固であることを確認しているわけではないことに注意してほしい。

ペネトレーションテストは業務・サービスであるため、パスワードクラックに無限のリソースを割くことができない。そのため、一定の基準を決め、どこかでテストを打ち切る必要があるのだ。そして、業務時間という制限があるとき、試せる試行回数というのはかなり少なくなる。

ここで例を示そう。あるサーバ上で動作する認証処理に対して辞書攻撃を仕掛ける。IDは1000個、パスワードは10000個用意し、それぞれの組み合わせでログイン可能かを調査する。この際、1秒間に10回認証処理が可能とする(ネットワークやサービスにより1秒間に試せる数は大きく変動する)。

1000×10000×0.1=100万秒

IDは1000個、パスワードは10000個というのは、認証情報が無限の組み合わせがありえることを考えれば控えめな数字といえるが、この組み合わせを試すのに12日間もかかる。１つのサーバの１つのサービスに、ここまでの時間をかけることは難しい。

実際のテストでは、１つのサーバに複数の認証可能なサービスが動作し、またテスト対象のサーバも複数存在する。"10台のサーバのテストを10日間で行う"という契約であれば、その契約に沿った時間にテストを調整する必要がある。

現実的な時間に調整方法としては、攻撃を行う端末を増やす（ただし、サービスの処理限界を考える必要がある）、あるいは認証情報の組み合わせを減らすことが考えられる。

ただ「どの程度の組み合わせを試せば十分といえるか？」という基準は存在しない。そのため、パスワードクラックで調査する認証情報の組み合わせはベンダーに依存することになる。どの程度のテストが行われるかはベンダーにより左右されるが、かなり多くの組み合わせを試したとしても「ID=1000, パスワード=10000」程度であることは理解してもらえたと思う。

これらの試行回数で調査可能なのは「脆弱な認証情報」であり、「個々のIDのパスワード強度」ではない点も理解しよう(そもそも正しいIDがわからない場合が大多数である)。

攻撃者のパスワードクラック

「テストで認証情報を発見できないのなら、攻撃者も発見できないはず」と思われた方も多いだろうが、実際は違う。

攻撃者の攻撃とテストは条件が違うのだ。

まず第一に、攻撃者は時間に縛られない。ベンダーは契約の時間内で完了できるように時間を調整するが、攻撃者は１つのサービス、１つのIDにかなりのリソースを投入することができる。ある例では、攻撃者が１つのサービスを数か月間に渡って攻撃した事象も観測されている。

第二にリスト型攻撃の存在である。リスト型攻撃は、別サービスで有効だった認証情報の組み合わせをそのまま利用する。攻撃者はダークウェブなどでこれらリストを購入する。これらリストの購入は違法行為（あるいはグレーゾーン）であるため、一般のベンダーはまず購入できない。ここでポイントになるのは、リスト型攻撃は「脆弱ではない認証情報」を攻撃可能という点だ。リスト型攻撃で利用される認証情報は、必ずしもパスワードクラックによって破られた認証情報であるとは限らない。例えばサーバに直接侵入し、データベースから抜いてきた可能性も十分考えられる。こうなるとテストでは見つからない強固な認証情報であろうとも、容易に突破されてしまう。

テストとしてのパスワードクラックの限界点

テストとしてのパスワードクラックは業務の一環であり、違法行為や契約以上のリソースを投入することができない。また、これはペネトレーションテスト全体にもいえるが「どこまでやればいい」という明確な基準がない。これらが原因となり、「テストをパス=攻撃に対して安全」という点が保証できなくなる。

上記の点から、テストとしてのパスワードクラックは「設定ミス」を始めとした脆弱な認証情報の発見には役に立つが、それは攻撃に対して安全であることを示さないと考える。攻撃者の攻撃を軽減するには、脆弱なパスワードを登録させないだけでなく、多要素認証やログイン監視ソフトを使い、多方面から防御する必要がある。