脆弱性検査 – パスワードチェック –

前回記載したように、ポートスキャンが実施されると、サーバーや機器上で開いているポートが発見される。その結果、telnet や ssh、http や ftp などが開いていると、ここに対するログイン試行が行われる恐れがある。

一方、telnet は論外としても、ssh や http、ftp などは諸々の都合上開けておきたい場合が多い。

そのような場合、ポートを開けていても、十分な安全性を確保で来ているかどうか、を確認しておく必要がある。

よって今回は、不正なログインがされないかどうかを確認するための一手段として、オンラインでのパスワード推測について記載する。

主な内容は以下の通り。

1. hydra のインストール
2. 基本的な使い方
3. 実施結果
4. 挙動の確認
5. 攻撃された側のログ確認
6. 対策例
7. まとめ

なお、hydra は脆弱性検査に使うべきものであるが、当然使い方によっては攻撃にも利用されうる。

このため、自分の責任範囲外のサイトなどに適用した場合、ハッキング行為とみなされる恐れがある。

よって、利用する際には、これまで記載してきた環境のように、自分のネットワーク内にある、自分のサイトや機器の脆弱性検査に限って利用すべきであることにご注意頂きたい。

■hydra のインストール

hydra はオンラインのパスワード推測ツール。ssh、http、ftp など各種のプロトコルに対して、オンラインパスワード推測を試すことができる。

まずはこれをインストールする。インストール自体はやっぱり非常に簡単。

root@raspi-03# apt-get install hydra -y

で終了。

ということで、早速使ってみる。

■基本的な使い方

hydra も当然色々なオプションが存在するが、個々の意味などについては、https://tools.kali.org/password-attacks/hydra

を参照してもらえればと思う。

基本的な使い方は以下の通り。

root@attacker:~# hydra -l [user 名] -P [辞書ファイル] [プロトコル]://[IP アドレス]

-l オプションをつけることで、user 名を指定できる。

[user 名] 部分に、user 名の候補を記載したテキストファイルを指定すると、そこに記載された全ての user に対するパスワード推測が行われる。

次に、-P オプションにより、推測に利用する辞書ファイルを指定する。

パスワード推測実行時には、ここで指定されたファイルに記載されているパスワードが全て試される。

最後に、対象プロトコル（ssh なのか http なのか ftp なのか等）と対象サーバーの IP アドレスを指定する。

これで、オンラインでのパスワード推測が実行可能となる。

ちなみに、-P オプションを -X オプションに変更することで、brute-force（総当たり）によるパスワード推測も可能。

その場合、[辞書ファイル] 部分において、利用する文字種類や文字数を指定する。
＊具体的な指定方法はここでは割愛する。

さらに、-e ns オプションを最後に付与することで、パスワードなしアカウントかどうか、ログイン名とパスワードが同じになっているかどうか、を確認する事もできる。

パスワードなしのアカウントがないか、等を調べる際には有益なので、覚えておくと良さそう。

■実施結果

今回のトライアル環境では、三号機から、一号機の ftp サーバーに対して試してみた。user 名は既知のものとして、raspi-01 を指定。

パスワード（辞書）ファイルは、お試し用に自分で作成。

以下のような、いわゆる簡単なパスワードを 4 つほど記載している。

      password
      passwd
      123456
      qwerty

その結果がこちら。

raspi-01 のパスワードが password であることが、見事に露呈している。

■挙動の確認

上述のような辞書攻撃の場合、パスワードが辞書ファイルに記載されてさえいれば、簡単にパスワードが露呈してしまうことが確認できた。
＊辞書に載っているような簡単なパスワードを使わない、というのはこういうことだ、というのが改めて実感できた。が、実際には、どうやってパスワードが当たったかどうかを判断しているのだろう？

ちょっと気になったので、wireshark でパケットをキャプチャしてみることにした。

まず、hydra によるオンラインパスワード推測を実行してる間、全てのパケットをキャプチャする。

その結果がこれ。

一番上のパケットから 4 行分を見ると、一号機に対し、送信元（三号機）側のポート番号を変えて、SYN パケットを送っている。

なるほど。そういうことか。

FTP の場合、サーバーへの制御アクセスは大体 21 番ポートと決まっているが、クライアント側のポートはクライアント側で任意の値を指定できる。

また、パスワード（辞書）ファイルに記載しているパスワード数は今回 4 である。

ということで、多分以下のような動作を行ってるのだろう、と思われる。

• パスワード（辞書）ファイルに記載されたパスワード数をカウントし、試行回数とする。
• クライアント側ポート番号をランダムに選択する。
• 選択したポート番号を、（試行回数 – 1 回）分まで +2 していく。

だとすると、クライアントポート番号 1 つに付き、1 つのパスワードを試す、ということをしているはず。

ということで、先ほどキャプチャしたパケットを、ポート番号でソートして見た。

まずはパスワード推測に成功したケース（ポート番号 36322）。

ハイライトされている 15 行目において、USER として raspi-01 を送っている。

次に、それに対するパスワードを見てみる。

こちらも、ハイライトされている 23 行目において、 PASS の引数に password を送っている。

その結果、

41 行目において、一号機（192.168.0.1）から三号機（192.168.0.20）宛に、ログインが成功した旨を表すパケットが飛んでいる。

となると、これを成功として記録していることになる。なるほど。

では、次のパスワードはどう試しているのか？

成功した場合のポート番号（36322）の次のポート番号（36324）のやりとりを見てみる。

先ほどとは異なり、ハイライトされた 37 行目において、PASS の引数が passwd となっている事が分かる。

そしてその結果、

49 行目において、ログイン失敗を表すパケットが一号機から三号機に送られている。

こうやって、試行するパスワード毎にクライアント側のポートを変えることで、同一サーバーに対する複数のログイン試行を分離しているのか。

当たり前っちゃー当たり前のことなんだが、実際に見てみるとよく分かった。

■攻撃された側のログ確認

しかしこれだけログイン試行があれば、サーバー側のログにログイン失敗の結果が残っているはず。ということで、一応一号機側の ftp に関するログを確認。

一号機では、vsftpd で ftp サーバーを実現しているので、/var/log/ 以下の vsftpd.log を見てみる。

当然のことながら、赤枠部分に成功から失敗までのログがちゃんと残っている。

ということで、やはりこういったログの確認は重要だと改めて思う。

■対策例

オフラインでのパスワード推測は分かるけど、オンラインの場合はどうやっているのか、というのが今回よく分かった。じゃぁ実際にどうやって対策すればよいのか。

直接的な対策は、当然のことながら、パスワードを推測されないような値にすればよい。

よくいう、文字数を増やす、英数大文字小文字記号を入れる、辞書に載っているような安易なパスワードを使わない、は確かに重要だ。

ただ、パスワードを強固にするといっても、現実的には結構限界があったりする。

やっぱり意味のないパスワードなどは覚えにくい人が多い。

このためどうしても簡単なパスワードとなりがち。

複数のユーザーが存在するような環境ならなおさら。

加えて、攻撃する側は、パスワード推測を仕掛けたら、後は 2、3 日とか一ヶ月とか、放っておけばよいだけ。

ということで、間接的であるが根本的な対策は、やっぱりパスワードでログインできるような状態にしない、だと思う。

具体的には、ssh の場合にはパスワード認証を禁止し、公開鍵認証のみを許す形にする、ftp は ftps/sftp などにする、だと思う。

これらの設定方法に関しては、追って記載していこうとおもっている（・・・がなかなか手がつけられていない）。

■まとめ

ということで、今回はオンラインでのパスワード推測を試してみた。前回と合わせ、実際には、

• nmap で開きポートを検索する
• ログイン系のサービスがあれば、hydra などを使ってパスワードを推測する

など非常に簡単にやられてしまうことがよく分かった。

よって、インターネットに公開するサーバーなどを立てる場合には、（これだけでは不十分極まりないが）公開以前に最低限上述のようなことを試しておくべきだと思う。

ということで、まとめとして今回のポイントを以下に記載しておく。

次回はオンラインでの脆弱性検査について、もう少し幅広い検査の方法を書こうと思う。