検索
連載

「Forbidden」「サンプル」をセキュリティ的に翻訳せよセキュリティ対策の「ある視点」(3)(1/3 ページ)

なにげなく接しているメッセージ、それを文字通りに受け取らないことで見えてくるものもあるのです。あなたはこの問いにどう答えますか?

Share
Tweet
LINE
Hatena

 第1回第2回とWebサーバ“Apache”のセキュリティ設定について紹介したが、引き続きApacheのセキュリティ設定について、新たな視点を提供したい。今回は「ユーザーディレクトリが有効」「デフォルトのコンテンツの存在」をキーワードとして、ここに潜む問題を解説させていただく。

ユーザーディレクトリ機能が教える「ヒント」

 ユーザーディレクトリ機能とは、Apacheのモジュールの1つである「mod_userdir」を利用した機能である。

 皆さんは、Webサイトを巡回しているときに、http://●●.jp/~tsuji/のようなURLを何度も見たことがあるだろう。

 このURLをリクエストすると、指定したユーザー(上記の場合はtsujiユーザー)のホームディレクトリにアクセスできるのである。ユーザーディレクトリは、このようにシステム内のユーザーごとのホームディレクトリを、Webで公開・管理することに利用される機能である【注1】

【注1】

ホームディレクトリ以下をそのまま公開することは好ましくないため、多くの場合は、ホームディレクトリ以下に「public_html」などの共通の名前のディレクトリを用意し、そのディレクトリを公開専用にする場合がほとんどである。つまり、http://●●.jp/~tsuji/とリクエストをすると、システム内の/home/tsuji/public_htmlにアクセスできるということである。


 この機能は、httpd.confなどのApache設定ファイルに記述されている。まず、どこに有効/無効の設定が記述されているのか、あらかじめ確認しておこう。

 デフォルトでは、設定ファイルの中に以下のような記述がある。

# UserDir: The name of the directory that is appended onto a user's home

# directory if a ~user request is received.

#

UserDir public_html

リスト1 httpd.confのユーザーディレクトリ設定

 上記の「UserDir public_html」の部分がユーザーディレクトリ機能の設定部分である。デフォルトでは、http://●●.jp/~tsuji/とリクエストした場合、/home/tsuji/public_htmlにあるファイルに対してアクセスすることとなる(多くの場合はindex.htmlやindex.phpなどのインデックスファイルが表示される)。

 このユーザーディレクトリ機能を提供するmod_userdirモジュールは、Apache 2.1.4以前ではデフォルトの状態で有効になっている。この機能は、前述したような用途のために使用されるのだが、あるリクエストに対する応答において、セキュリティの観点から問題となる挙動をする。

「Forbidden」――ここからなにを読み取るか

 それはどのような挙動なのか。問題となる挙動を示す前に、まず、今回のテストケースの前提条件を示しておこう。

  1. システム上で、デフォルトでインストールされたApache 2.1.4以前が稼働しているApache 2.1.4以前が稼働している
  2. システム内には、root、tsujiというユーザーの2つが存在する。 root、tsujiというユーザーの2つが存在する。

 この条件の下、下記のようなリクエストを送信してみよう。

a.http://●●.jp/~root/
b.http://●●.jp/~tsuji/
c.http://●●.jp/~muman/

 結果は以下のとおりである。

図1 それぞれのURLにアクセスしたときの応答
図1 それぞれのURLにアクセスしたときの応答

 上記の結果を見比べてほしい。c.のみ「Not Found」と表示されており、応答が違うことが分かるだろう。

 ユーザーディレクトリが有効になっている場合、システム内に存在しないユーザーのディレクトリにアクセスした場合は「Not Found」が、システム内に存在するユーザーのディレクトリにアクセスした場合は「Forbidden」が返されるのである。

 これは、どういうことを示しているのだろうか。

 この挙動を利用して、さまざまなユーザーディレクトリへのリクエストを試行し、「Forbidden」を返すリクエストを確認することで、システム内に存在するユーザーを見つけ出すことができるのだ。

 いちいちユーザーディレクトリをブラウザのアドレスバーに入力して確認するのは、面倒で現実的ではないと感じた方もいらっしゃるかもしれないが、このような作業を手動で行わなくとも、あらかじめ、テキストファイルに書かれた複数のユーザーディレクトリをチェックし「Forbidden」が返ってきたユーザーを通知してくれるツールも存在している。

 今回のテストケース環境にて、ツールを実行した結果は以下のとおりである。

[*] Checking http server [192.168.0.XXX:80]...

Apache => yes

Vulnerable => yes

OS => Unix unknow

[*] Searching for system accounts...

root => yes

tsuji => yes

muman =>

sergey =>

sasha =>

pavel =>

dark =>

(以下略)

リスト2 テストケースでのツール実行結果

 実行結果では、ユーザーディレクトリへアクセスを行い「Forbidden」を返したもの、つまり、システム内に存在するユーザー名の横には「yes」と表示されている。「root」と「tsuji」が存在していることが分かり、「muman」以下のユーザーが存在していないというように、ブラウザでリクエストを送信したときと同じ結果が得られていることが分かる。手間をかけブラウザでアクセスしなくても、自動化されたツールを利用することで手軽に調査が行われてしまうことが分かっていただけたと思う。

Copyright © ITmedia, Inc. All Rights Reserved.

       | 次のページへ

Security & Trust 記事ランキング

  1. 「SMSは認証に使わないで」 米CISA、モバイル通信を保護する8つのベストプラクティスを公開
  2. 終わらせましょう。複雑過ぎるKubernetes/クラウドネイティブが生む心理的安全性の低下を――無料でクラウドセキュリティの勘所が分かる130ページの電子書籍
  3. 日本人の約半数が「1年前より危険」と考えるオンライン詐欺とは マカフィーがホリデーショッピング詐欺に関して調査
  4. 3割程度のSaaS事業者が標準的なセキュリティ対策をしていない アシュアードがSaaS事業者を調査
  5. 中小企業の20%の経営層は「自社はサイバー攻撃に遭わない」と信じている バラクーダネットワークス調査
  6. 商用国家安全保障アルゴリズム(CNSA)の期限となる2030年までに暗号化/キー管理サービス市場が60億ドルに達するとABI Researchが予測 急成長の要因とは?
  7. ChatGPTやClaudeのAPIアクセスをかたってマルウェアを配布するPython用パッケージ確認 Kasperskyが注意喚起
  8. NIST、3つのポスト量子暗号(PQC)標準(FIPS 203〜205)を発表 量子コンピュータ悪用に耐える暗号化アルゴリズム、どう決めた?
  9. 廃止済みの「Internet Explorer」を悪用したリモートコード実行の脆弱性、Microsoftは対策パッチをリリース
  10. AWS、組織のセキュリティインシデント対応を支援する「AWS Security Incident Response」を発表 アラートに圧倒されるセキュリティチームをどう支援?
ページトップに戻る