2013年08月30日

ロリポップでWordPressの改竄が拡がった理由

ロリポップでの大規模なWordPressサイトの改竄について
http://lolipop.jp/info/news/4149/

ロリポップからのリリースでは、管理パスワードとログインへのアクセス制限の強化を推奨して、パーミッションの変更と全体のウイルスチェックを行うとしている。WordPressそのもののアップデートはマニュアルに方法が記載されているものの、リリースでは触れられていない。
このことから、被害が大きくなったのは、ロリポップの提供していたWordPressのインストール手順に問題があり、wp-config.phpなどのファイルのパーミッションが不適切だったためではないかと推察出来る。


いくつかのアカウントだけWordPressの管理パスワードが突破される、というのであれば、世界中でほぼいつでも起こっている。
もし、あるユーザーの管理パスワードが脆弱で推測することが出来てしまうと、そのWordPress管理画面から自由にプラグインを導入できる。古い脆弱なWordPressやプラグインを使っている場合も同様で、この場合、そのユーザーアカウントで攻撃者は任意のスクリプトを実行でき、ファイルやDB上のデータ全てを自由に改竄可能になる。
ここまでは、ロリポップに限らずどこのホスティングサービスでも起こりうる、脆弱なパスワードあるいは古いバージョンを使っているユーザーの自己責任と言える。

安価な共用サーバーでのウェブホスティングでは、数多くのユーザーが一つのサーバーを利用している。一つのアカウントに侵入されても、同一サーバーの他のユーザーのデータを読まれたり、変更されたりしないように、CGIは各ユーザーの権限で動作させ、ファイル・ディレクトリの所有者がパーミッションでアクセスを制限することで、他のユーザーの秘密のデータを保護している。そのため、(脆弱な)あるユーザーの権限でCGIが実行できても、影響範囲はそのユーザー1人にとどまる。
(ユーザー毎のchroot/jail/LXCなどを利用ことで、パーミッションに依存せず、各ユーザのデータを保護しているところも有るだろうが、少なくともロリポップはそうでは無かったことになる)

しかし、wp-config.phpに不適切なパーミッション(たとえば444、サーバー上の全てのユーザーが読み込み可能)が設定されていて、そのファイルの場所が分かっていれば、他のユーザーがスクリプトの内容を読めてしまう。wp-configにはデータベースに接続するためのパスワードが記載されているので、DBに接続して管理パスワードを変更してしまえば、管理者としてログインしてウェブサイトを改ざんできる。

つまり、WordPressをインストールしたユーザーのうち、たった1人が脆弱なパスワードを利用していたり脆弱な古いバージョンを使っていて、ファイルのパーミッションが不適切であれば、同じサーバーのユーザーが芋づる式に二次被害を受けることになる。
対策として、真っ先にアナウンスされた内容はWordPressのアップデートを推奨するもの(WordPress自体の脆弱性対策)ではなく、強い管理パスワードとパーミッションの再設定を求めるものだったことから、この推測が補強される。

ロリポップにWordPressをインストールしたユーザーの多くが、誤ったパーミッションを設定していた理由は幾つか想像できる。単にユーザーの不注意かも知れないし、ロリポップへのWordPressインストール方法を紹介したサイトが、間違ったパーミッション設定を多数のユーザーに伝授してしまったのかもしれない。

しかし最もありえそうなのは、ロリポップの「WordPress簡単インストール」機能に問題があり、ユーザーのwp-config.phpに不適切なパーミッション(たとえば644)を設定してしまった場合。
ロリポップのWordPressインストール手順にはインストール後のパーミッションの変更が記載されていなかったので、ユーザーはそうと気付かずに、インストーラが設定した不適切なパーミッションのまま運用していた、と考えられる。

WordPressの簡単インストール機能がどのように動作するのか、現在その機能が無効化されていて確かめることが出来ないが、ほぼ同様の動作をするだろうMovableTypeの簡単インストール機能は有効で、自動的にDBアカウントとパスワードが記入される mt-config.cgi のパーミッションは644のままだった。ユーザー権限でCGIを動作させている共用サーバでは通常、400(所有者のみ読み出し可能)に変更するはずだ。
wp-config.php のパーミッションを400にする必要があるのに、同じ方法でDBに接続するMovableTypeは変更する必要が無いというのが不思議なところだ。二次被害を引き起こした可能性がある以上、WordPressにかぎらず全てのインストール機能は無効化して、全てのファイルのパーミッションの再確認をするべきだ。


上記の推測があたっているとすると、ユーザーが強固なパスワードを使っていて、手順通りに最新バージョンで運用していても、脆弱なユーザーの二次被害を受けることになる。
(追記)
各サーバーで最初に侵入されたアカウントへが侵入経路がWordPressの脆弱性であろうと、それ以外であろうとも関係は無い。
(/追記
thx:名無しさん

ユーザー側でとれる対応は、
・wp-config.phpやmt-config.cgiなど、同一サーバーの他のユーザーに見られては困るファイル(管理パスワードやDBパスワードを記述したファイル)のパーミッションを400に制限する(脆弱なユーザーからの二次被害対策)
・手元のバックアップと現状のファイル・DB内データを比較し、改竄があればバックアップから復元する(バックドアや不正なリンク設置への対策)
・DB接続用パスワードも強固なものに変更する(対応するwp-config.phpの記述も変更する)


現状のロリポップの記載内容では、改ざんされたウェブサイトの所有者全員が脆弱なWordPressプラグイン・テーマを使っていたかのように書かれている。WordPress以外のCGIスクリプトにも同じ問題が起きていないかのチェックがなされていない、というのは問題だと思うのだが。
posted by ko-zu at 00:30| Comment(2) | TrackBack(0) | セキュリティ | このブログの読者になる | 更新情報をチェックする
この記事へのコメント
> しかし、wp-config.phpに不適切なパーミッション(たとえば444、サーバー上の全てのユーザーが読み込み可能)が設定されていて、そのファイルの場所が分かっていれば、他のユーザーがスクリプトの内容を読めてしまう

もし、この状態だったのであれば WP をクラックする必要は無くて、「正規にロリポップにユーザ登録」すれば、他のユーザのスクリプトの内容が読めますね。
WP は関係ないですね。
Posted by 名無し at 2013年08月30日 10:55
> もし、この状態だったのであれば WP をクラックする必要は無くて、「正規にロリポップにユーザ登録」すれば、他のユーザのスクリプトの内容が読めますね。
何年も前から計画していない限り、狙ったサーバーにアカウントを作るのは困難なので、攻撃者がユーザー登録している、というのは考えにくいと思われます。

もちろんこれも侵入方法の一つではあり、最初に侵入された理由がWPの脆弱性以外でも、他のユーザーへの影響は全く同じ、という点でWPは関係ないのでおっしゃるとおりです。追記で明確化してみました。ありがとうございます。
Posted by こーず at 2013年08月30日 21:57
コメントを書く
お名前: [必須入力]

メールアドレス:

ホームページアドレス:

コメント: [必須入力]

認証コード: [必須入力]


※画像の中の文字を半角で入力してください。

この記事へのトラックバック
×

この広告は1年以上新しい記事の投稿がないブログに表示されております。