はじめに
パスワードスプレーという攻撃手法について、中途半端に輸入されたものの日本の技術者が正しく理解できるような解説が無いように思います。本記事にて理解が深まれば幸いです。理解すれば「これは危険だな」と思うはずです。
ニュース記事
こちらの記事でパスワードスプレーというワードを意識された方が多いのではないかと思います。
JPCERT コーディネーションセンター（JPCERT/CC）は4月4日、不正ログインを狙った「パスワードスプレー」攻撃への注意を呼び掛けた。多要素認証の活用や推測困難なパスワードの使用といった対策の強化を推奨している。
この記事を読んでも、何がブルートフォース攻撃やリスト攻撃と違うの？という感想しかないのではないかと思います。マイクロソフトの日本語記事も要領をえないという感想です。
もっともわかりやすくて恐怖感のあるパスワードスプレーの実例記事
こちらの記事を紹介します。
Simplifying Password Spraying | Trustwave
英文なので以下で解説します。
なお、このTrustwaveという会社はアメリカのセキュリティ関連大企業です。ニュースソースとしては間違いありません。
まず、Trustwaveは本文書で文末にてspray.shという攻撃自動化シェルをgithubに公開しています。したがって攻撃は簡単に行うことができます。パスワードスプレー攻撃は誰にでも簡単に行うことができることをまず理解してください。
次にこのシェルが何をするかです。
Windowsドメインコントローラーに対して、このツールを使って、以下のコマンドを実行したとします。
$ spray.sh -smb 10.10.10.10 usernames.txt passwords.txt 1 35 SPIDERLABS
それぞれの引数について説明します。
-smb 445/TCPのSMBサービスにアクセスします
10.10.10.10 ドメインコントローラ―のIPアドレスです
username.txt ユーザー名を一覧化したリストです
passwords.txt パスワードファイルです。
1 1つのパスワードを試行します
35 35分毎に試行します
SPIDERLABS SPIDERLABSドメインに対してログイン試行します。
つまり、usernames.txtにあるIDについて、総当たりでpasswords.txtのパスワードを、35分に1個ずつ、10.10.10.10にあるSPIDERLABSドメインコントローラに対してログイン試行していくのです（この例では）。もちろん、60分に10個、のようなカスタマイズもできるようになっています。普通は「同じユーザーが3回失敗したら30分ロックアウトする」というようなポリシーが決まっていると思います。35分毎に試すことによって、ゆっくりかわすのです。
同様に、Outlook Web Accessや、Lync（スカイプ）、CISCO Web VPNの例も下記に記載されています。
https://github.com/SpiderLabs/Spray/blob/master/README.md
ユーザー名は事前入手したりよくある名前を列挙します。パスワードについては、「よく使われるパスワード単語１５０」などを手に入れて2018とか18とか言う数字を後ろにつけて完成させます。このあたりもパスワード作成をspray.shは自動化しています。サンプルのusername.txtもpasswords.txtもgithubに公開されています。
まとめ
具体的には、このツールをいろいろなWEBサービスやドメイン、VPNサービスに対してバックグラウンドでゆっくり動かして「当たり」となるのを待つというのをパスワードスプレー攻撃と読んでいるのです。
１つのサイトにガツガツと同じIPアドレスからパスワード失敗を繰り返していたら、さすがに管理者側に気が付かれますし対策もされます（いくらかの時間、特定IPアドレスからのログインを拒否するなど）。しかし、このようにゆっくりログイン試行されるとペナルティーをすり抜けてしまいますし管理者も気が付きにくいのです。
一件時間がかかりそうですが、複数のサイトに同時にやることによって、確率は上がっていきます。１０サイトやれば１０倍です。攻撃用のサンプルまでありますので実際に世界でこのような攻撃が行われていると推察します。このツールのgithubのソースを見ていただければ理解が進むと思います。
なお、対策としては、JPCERT/CCの指摘の通りかと思います。
- 多要素認証の仕組みを導入する
- ユーザがパスワードを忘れてしまった場合のリカバリ方法について、適切に設定を行う
- アカウントロックの仕組みを導入し、適切に設定を行う
- ユーザのパスワードは、ソルトやハッシュ、ストレッチングを利用し、適切に保管する
このうち最も有効なのは多要素認証ですが敷居が高いのがたまに傷ですね。あとの対応は「適切に」というのは何が適切なのかという話になってくると思います。徹底的に戦うなら、同じIPアドレスからの一定時間の失敗回数を数えて遮断するような仕組みがWAFなどで必要になるのかもしれません。
