ユーザー・アカウント情報を守る

　攻撃者がターゲット・ホストに対して侵入を試みる際，まず行われるのが「情報収集」である。ここでいう情報には，（1）ネットワークに関する情報，（2）OSやサービスのタイプやバージョン情報，（3）ユーザー・アカウント情報---などが挙げられる。今回は，アカウント情報に焦点を絞り，取得された場合の危険性や，攻撃者がどのように情報収集するのかについて解説する。

アカウント情報の重要性

　多くの場合，攻撃者の目的はターゲット・ホストで管理者権限を取得することである。いうまでもなく，管理者権限を奪えばホストを自由自在にコントロールできるからだ。そのことを十分認識し，rootには複雑なパスワードを設定し，かつ頻繁に変更したり，UNIX系OSであれば，コンソールからでないとrootでログインできない，などとしている管理者は多いだろう。

　しかしながら，一般ユーザーのアカウントについては，「取得されたところでパスワードがあるから大丈夫」，あるいは「パスワード管理がずさんなユーザーのファイルがいじられるだけ。システムに影響を与えることはない」---などと，タカをくくっている管理者も多いのではないだろうか。

　これは大きな間違いである。いくら管理者が声を大にして注意しようとも，推測可能なパスワードをつけてしまうユーザーは必ず存在する。ssh（Secure Shell）で先日報告されたようなセキュリティ・ホールが存在する場合には，推測する必要もなくログインされてしまう恐れもある（[関連記事]）。

　そして，一般ユーザーとしてログインされてしまうと，次には管理者権限が狙われる。重要なファイルのアクセス制限がデフォルトのまま，あるいは不適切な設定である場合には，一般ユーザーになりすました攻撃者に操作されてしまう。そうなれば，管理者権限が奪われたのと同等の影響をホストが受ける恐れがある。

　システムやアプリケーションのバグを悪用され，一般ユーザー権限から管理者権限を奪われる（いわゆる「権限の昇格」）恐れもある。リモートからいきなり管理者権限を奪われるバグと比較すれば重要度は低いため，権限の昇格に関するバグ対策は後回しにされている可能性がある。

　重要なことは，（1）推測されにくいパスワードをユーザーに設定させ，（2）ファイルのアクセス制限などを適切に設定し，（3）パッチを適切に適用する---といった基本的な対策を施して，たとえアカウントを取得されたとしても，システムが“攻略”されないようにしておくことである。しかし，100％は望めない。やはり，アカウント情報は，攻撃者にとって有用な情報源となり得るのである。そのことを十分認識して，アカウント情報の保護に努める必要がある。

アカウント情報の収集方法

　アカウント情報を守るためには，攻撃者がどのように情報収集するのかを知っておくべきだろう。そこで以下では，具体的な収集方法について述べる。

　まず考えつくのが，「finger」や「rusers」といったサービスを利用する方法である。例えば，あるリモート・ホスト（remote_host）に対して，

% finger @remote_host

と入力すれば，remote_hostにログインしているユーザーが表示され，

% finger -l user@remote_host

とすれば，「user」の登録情報が表示される。

　もっとも，こういったサービスは，その危険性が周知されているので，サービスを停止しているサイトがほとんどであろう。最近は，デフォルトではこれらのサービスを起動しない設定のOSも存在する。また，サービスが稼働していても，ファイアウオールなどでアクセス制限されているので，これらのサービスが一般公開されていることはあまりない。

　ただし，これらのサービスを外部から利用できないようにしていても，アカウント情報を取得する方法がある。

サーバーのレスポンスで突き止める

　アカウント情報そのものを返すサービスが使えなくても，指定したアカウントが存在するか否かさえ分かれば，アカウント情報を収集できる。適当に推測したアカウントを次から次へと試行すればよいのである。例えば，Solaris に同梱されている「ftpd （in.ftpd）」で発見されている問題を悪用すれば，このことは可能だ。

　具体的には，対象となる ftp サーバーへ telnet クライアントで接続し，以下のコマンドを入力すればよい。telnet クライアントは ftp プロトコル全体を実装してはいないが，コントロール・セッションのみであれば対話的な処理の一部は可能である。そのため，以下のやりとりが可能である。

220 ftpserver FTP server (SunOS 5.7) ready.
cwd ~root ←ユーザ入力部分
530 Please login with USER and PASS.
cwd ~aaaaa ←ユーザ入力部分
530 Please login with USER and PASS.
550 Unknown user name after ~

　ここで，2つの「cwd」コマンドに対する，サーバーのレスポンスの違いに気付かれたであろうか。ホストに存在するアカウントである「root」を入力した場合には，「530」のメッセージだけを返したのに対して，存在しない「aaaaa」を入力した場合には，「530」のメッセージに加えて，「550」も返している。これを悪用すれば，アカウントを自動生成して送信し，サーバーのレスポンスを調べるようなプログラムを作ることは可能だろう。「530」だけを返したアカウントが，そのホストに存在することになる。

メール・サーバーも悪用可能

　多くのホストで運用されているメール・サーバー（デーモン）・プログラムも，アカウント情報の収集に利用可能だ。以下に，その代表的なプログラムの1つ「sendmail」を例にとって説明する。

　まず考えられるのが，sendmailが備える「EXPN」および「VRFY」コマンドを利用する方法である。引数としてアカウント（ユーザー名）を与えると，そのアカウントが存在するかどうかを返すコマンドである。悪用される恐れがあるので，前述の「finger」などと同様に禁止している管理者は多いだろう。

　しかし，これらのコマンドを禁止していても，SMTP プロトコルを利用してアカウント情報を取得する方法が存在する。メールの送信には不可欠な「MAIL FROM」と「RCPT TO」コマンドを使用する方法だ。これらのコマンドは，メール・サーバー（MTA：Message Transfer Agent）間，あるいはメール・サーバーとメール・ソフト（MUA：Message User Agent） 間で，次のように使用される。以下の例では，「src@lac.co.jp」のユーザー（正確には，「エンベロープ From」）から，「dst@lac.co.jp」のユーザー（正確には，「エンベロープ To」）へ発送する処理の一部を示している。

MAIL FROM:  ←ユーザ入力部分
250 ... Sender ok
RCPT TO:  ←ユーザ入力部分
250 ... Recipient ok
DATA ←ユーザ入力部分
354 Enter mail, end with "." on a line by itself

上記は dst@lac.co.jp が存在する例である。では，「エンベロープ To（RCPT TOコマンドの引数）」に存在しないアドレス（アカウント）を指定した場合にはどうなるだろうか。

MAIL FROM:  ←ユーザ入力部分
250 ... Sender ok
RCPT TO:  ←ユーザ入力部分
250 ... Recipient ok
RCPT TO:  ←ユーザ入力部分
550 ... User unknown

　ご覧のとおり，サーバーからは「550」のステータスが返され，該当するアカウントは存在しないことが分かる。「ftpd」のところでも述べたように，これを悪用すれば，アカウント情報の収集は可能である。

　これを避けるには，アカウントの存在に関係なく ステータス 250 を返すようにサーバーを設定すればよい。実際，そのように設定しているサーバーは着実に増えているようである。

　現在，さまざまな認証方法が提案，実装されているものの，多くの環境においては，依然「ユーザー名/パスワード」による認証方法に依存していることは事実である。そのため，今回取り上げたアカウント情報の重要性は非常に高く，開示すべきでない情報のひとつであると筆者は考える。もちろん，メール・アドレスなどから判明してしまうことは避けられないが，それでも開示は必要最低限に抑えるべきである。

　バッファ・オーバーフローの問題や，それを用いたウイルスの問題などが大々的に報じられている現状においては，今回取り上げたアカウント情報のような問題は，一見すると地味で小さな問題と思えるかもしれない。しかし，悪用のされ方によっては，大きな問題へとつながる危険性があることを，改めて認識する必要があるだろう。

---

---

　IT Proセキュリティ・サイトが提供する「今週のSecurity Check [一般編]」は，その週に起きたUNIX関連およびセキュリティ全般のニュースや動向をまとめた週刊コラムです。セキュリティ・ベンダーである「株式会社ラック」のスタッフの方を執筆陣に迎え，専門家の立場から解説していただきます。