www.morihi-soc.net

セキュリティの話題を中心に取扱中

ハニーポット観察記録(27) 「wp-config.php の一時ファイルを狙った攻撃」

どうも.ハニーポッターの森久です.

WordPress の脆弱性を狙った攻撃は相変わらず多いです.

例えば,timthumb.php の脆弱性を狙った攻撃(ハニーポット観察記録(16))や Slider Revolution を狙った攻撃(ハニーポット観察記録(20))は去年から継続して,さらに勢いを増して検知しています.

今回はオリジナルハニーポットで検知した,このような特定の脆弱性を狙った攻撃ではなく,Web サイト管理者の人為的な,またはうっかりやらかしてしまいそうなミスを狙った攻撃について取り上げます.

検知した攻撃

攻撃その1

攻撃その2

※一部の情報を意図的に伏せています.

両方共 wp-config.php に関するファイルにアクセスを試みていますね.どのような目的なのでしょうか.

 

wp-config.php とは

まず wp-config.php がどのようなファイルなのか調べます.WordPress 日本語版をダウンロードしてサンプルファイルを見てみます.今回は本記事執筆時点の最新版である WordPress 4.2.2 を参考にしました.

ダウンロードした zip ファイルの中に wp-config-sample.php ファイルがあるので,中身を見てみます.するとファイルの先頭に下記のようなコメントが確認できます.

どうやら WordPress の設定情報が含まれるようです.また機密性が高いと思われる,データベースの認証情報が含まれるようです.

 

~や.bakファイル

さて攻撃者はなぜ wp-config.php そのものではなく,ファイル名の後ろに ~ や .bak をくっつけてアクセスしてきているのでしょうか?

これはおそらく wp-config.php ファイルを編集する際に使用するエディタが自動的に生成する一時ファイルや,バックアップされたファイルを狙ったものと考えられます.

たとえば vim というテキストエディタは,ファイル保存時に変更前のファイルを「ファイル名~」という名前で自動的に保存します.またファイル編集中に何らかの理由でエディタがクラッシュすると,編集中のファイルを「ファイル名.swp」という名前で一時的に保存します.

また用心深い人であれば,ファイルを編集する前に手動でバックアップを取るかもしれません.その時に使われるファイル名として「元ファイル名.bak」は使われやすい名前だと思います.

このように今回検知した攻撃は,WordPress の管理者によるファイル編集の影響や,バックアップファイルの管理の不備により,誰もがアクセス可能な状態のファイルが存在しないかどうかを調べることが狙いだと考えられます.

当然ですが,これらのファイルが存在しアクセスされてしまうと,データベースの接続情報が窃取されてしまう可能性があります.さらに二次的な被害として,データベースへの接続制限がされていない場合は,データベースへの不正ログインとデータベース内部の情報を窃取や操作されてしまう可能性があります.

 

狙われやすいファイル

今回検知していたのは ~ と .bak ファイルだけでした.しかし攻撃者の視点に立つと,これら以外のファイルも狙いたくなります.

 

一旦,ハニーポットから離れます.

WordPress の脆弱性調査といえば,WPScan が有名です.WPScan は WordPress に特化した脆弱性診断ツールです.診断対象の WordPress のサイトに既存の脆弱性が存在しないかどうかを調査することが可能です.なお WPScan のインストールや使い方などは本記事では割愛します.

WPScan(Version 2.7) で今回と同様の狙いの攻撃について調べました.下記は実際に WPScan が実行した攻撃のうち,wp-config.php に関するものの抜粋です.

  • wp-config.php.save
  • wp-config.php.swp
  • wp-config.php.swo
  • wp-config.php.old
  • wp-config.php.orig
  • wp-config.php~
  • #wp-config.php#
  • .wp-config.php.swp
  • wp-config.php_bak
  • wp-config.php.bak
  • wp-config.php.original

結構たくさんありますね.

 

対策

さて今回の攻撃はどのような対策をすれば防げるのでしょうか? 特定の脆弱性を狙った攻撃であれば,パッチを適用したりバージョンアップしたりすることで対策ができます.しかしながら,今回のような特定の脆弱性ではない場合は対策方法が異なります.

たとえば下記のような方法が対策として挙げられます.

  1. Web 公開ディレクトリ上のファイルをエディタで直接編集しない
  2. バックアップする際は,バックアップ先を Web 非公開ディレクトリにする.
  3. 特定の拡張子に対するアクセスを制限する.

まず1の対策ですが,急いでいるときやほんの少しの編集作業などのときに,ついやってしまいがちです.攻撃はいつやってくるかわかりません.僅かな編集作業中に攻撃が来ないという保証はありません.ローカル環境のような安全な場所でファイルを編集し,アップロードやコピーをするように心がけましょう.

2の対策ですが,バックアップファイルを安全な場所に保管するというのは,Web サイトを管理する上で非常に重要です.そもそもバックアップファイルを公開する必要はありませんので,ローカル環境やデータ管理が安全にできる場所に保存しましょう.

3の対策ですが,1や2の対策漏れでうっかりファイルを作成してしまった・されてしまったときの対策となります.たとえば .htaccess で下記のように記述することで,アクセス制限をすることができます.

※2015年6月10日追記:スペース文字がエスケープされていた部分を修正しました.

なおテキストエディタにおいて「一時ファイルを作成しない設定をする」という方法も対策としては考えられますが,エディタの利便性を失うことになるため,上記ではあえて提示していません.利便性とセキュリティリスクを考慮した上で,一時ファイルを作成しない設定の可否を決めることを推奨します.

 

参考になれば幸いです.

以上です.

 

参考情報

7日目 WordPressを使った某ブログ
http://kusano-k.hatenablog.com/entry/2014/12/01/000356#advent7

そのバックアップ、危険です!wp-config.phpの中身が丸見えに!
http://www.nishi2002.com/11190.html

[技術ブログvol.7] WPScanを使ってWordPressサイトをチェックしてみる
http://www.denet.ad.jp/technology/2013/11/vol7-wpscanwordpress.html

WordPressの脆弱性スキャンツールwpscanを使ってみる
http://d.hatena.ne.jp/ozuma/20130820/1376927068

 

Written by morihisa

6月 9th, 2015 at 10:25 pm