
第3回 「Forbidden」「サンプル」をセキュリティ的に翻訳せよ
辻 伸弘
NTTデータ先端技術株式会社
2007/9/26
第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」――ここからなにを読み取るか
それはどのような挙動なのか。問題となる挙動を示す前に、まず、今回のテストケースの前提条件を示しておこう。
- システム上で、デフォルトでインストールされたApache 2.1.4以前が稼働している
- システム内には、root、tsujiというユーザーの2つが存在する。
この条件の下、下記のようなリクエストを送信してみよう。
- http://●●.jp/~root/
- http://●●.jp/~tsuji/
- http://●●.jp/~muman/
結果は以下のとおりである。
![]() |
![]() |
a. /~root/へアクセス |
b. /~tsuji/へアクセス |
![]() |
|
c. /~muman/へアクセス |
|
| 図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」以下のユーザーが存在していないというように、ブラウザでリクエストを送信したときと同じ結果が得られていることが分かる。手間をかけブラウザでアクセスしなくても、自動化されたツールを利用することで手軽に調査が行われてしまうことが分かっていただけたと思う。
1/3 |
| Index | |
| 「Forbidden」「サンプル」をセキュリティ的に翻訳せよ | |
| Page1 ユーザーディレクトリ機能が教える「ヒント」 「Forbidden」――ここからなにを読み取るか |
|
| Page2 ユーザーの存在を隠すための対策 “彼ら”に知らせていい情報やヒントなどない |
|
| Page3 隠れた脅威、それは「デフォルトコンテンツ」 「知ることは最大の防御なり」を再度認識しよう |
|
セキュリティ対策の「ある視点」 バックナンバー
- 第1回 たった2行でできるWebサーバ防御の「心理戦」
- 第2回 ディレクトリ非表示の意味をもう一度見つめ直す
- 第3回 「Forbidden」「サンプル」をセキュリティ的に翻訳せよ
- 第4回 メールサーバ防御でも忘れてはならない「アリの一穴」
- 第5回 DNS、管理者として見るか? 攻撃者として見るか?
- 第6回 己を知り、敵を知る――Nmapで見つめ直す自分の姿
- 第7回 魂まで支配されかねない「名前を知られる」という事件
- 第8回 魂、奪われた後――弱いパスワードの罪と罰
- 第9回 人の造りしもの――“パスワード”の破られ方と守り方
- 第10回 SNMPコミュニティ名、そのデフォルトの価値は
- 第11回 ハニーポットによるウイルス捕獲から見えてくるもの
- 第12回 プレイバックPart.I:ウイルスのかたち、脅威のかたち
- 第13回 プレイバックPart.II:シフトした脅威の中で
- 第14回 ASV検査、ペネトレテスターの思考を追う
- 第15回 報告、それは脆弱性検査の「序章」
- 第16回 たった1つの脆弱性がもたらすシステムの“破れ”
- 最終回 Q.E.D.――セキュリティ問題を解決するのは「人」
| セキュリティ対策の「ある視点」 連載インデックス |
TechTargetジャパン
- Facebook タイムライン利用時の「鉄則」 (2012/2/9)
ユーザーインターフェイスの変更措置に伴い浮上した、Facebookの「過剰な情報提供」のリスクと対策とは - 無料サービスなら通信内容を記録してもいいの? (2012/1/13)
無料の公衆無線LANサービスが、ユーザーに無断で通信履歴を記録していたことが判明し、話題に - 攻撃はまるでレーザービーム (2011/12/26)
2011年に話題となった標的型攻撃は「人」という弱点ををねらい打ちにしました。では、人に教育さえしておけば防げるものなのでしょうか? - 見せたくないなら「持たせない」が鉄則! (2011/12/15)
逆コンパイル対策で難読化したのに、大事なデータが解析されちゃった? Androidアプリのセキュリティの道は深い
|
|
キャリアアップ
スポンサーからのお知らせ
- - PR -
イベントカレンダー
- - PR -



