WordPress乗っ取りについて考えてみた
世間で姦しいので、WordPress乗っ取りに関して考えてみた。
17:15 追記: どうやら、世間で姦しい方の乗っ取りに関しては、末尾の備考に追記した方が本命でこの推測は予測しすぎという結論に落ち着きそうです。
あくまでも、個人的に考えただけなので、どこかで発生している何かがこんな流れであるということではありません。
以下の内容は、端から見た「どこかの事案」を元にした(勝手な)推測である。
以下の内容は、「仮に似たような事案があったとしても、あくまでも」、特定の誰かを対象としたものではない。
という前提で読んでください。
こんな世知辛いことを書かなきゃいけない今のInternetってどうなのよ?という話は、いつかまた、機会があれば。
前提
どこか(以下 A社)のサービスとして、共有サーバーを用いたレンタルサーバーサービスを提供している
このサーバーサービスでは、Blog設置サービスとしてWordPress(以下WP)やMovableType(以下MT)、メール関係のサービス等が提供されている
このサービスのレンタルサーバーは「共有サーバー」であり、複数の様々な利用者を収容している
DataBaseを提供するサービスも提供しており、MySQLをユーザー単位で提供している
前提知識
WordPressは、PHPとMySQLを利用して動作するシステムである
WordPressで管理される情報は(一部の実体としてのファイル)を除き、全てMySQL内に記録される
WordPressは、(通常) 1サイト毎に 1DB を使用する
DBへの接続には、MySQLの認証ロジックを利用しており、Username/Passwordが必要
WordPressは上記認証情報を wp-config.php に登録している
一般にWeb ServerはApache等のWeb Server Application(以下httpd)がそのサービスを提供する
通常、httpdはシステムに脆弱性を作らないようにするため、(一般には)制限された権限で動作する
この制限された権限でもWordPressが動作するようにWordPressの本体(PHPスクリプトファイル群)は、注意深く権限設定されていなければならない
前提知識から明らかな結論
WordPressサイトへの攻撃は、wp-config.phpを入手できればOK
WordPressサイトへの攻撃は、WordPressのDataが記録されているDB(MySQL)に対象サイトのUsername/Passwordでlogin出来ればOK
もし、WordPressのDataが記録されているDBのrootパスワードを取得できれば、WordPress以外の全データが奪れるので、なおBetter
A社のサービスモデルならば、DBサーバーも複数存在する可能性が高く、もし全てのDBサーバーのrootパスワードが一緒なら、一気に美味しい
考えたケース
A社のWPサービスを利用している大多数のユーザー(5000以上)のサイトが書換えられた
A社でwp-config.phpのpermission等を再度設定しなおしたが、その後も書換えられるという報告が(少なくとも数件)上がっている
WordPressのVersionは関係ない(最新版でも古いものでも同じように発生している)
推測
以下、個人的な推測です。こうだったという証拠はありません
被害が多数にわたっていることから、個別にwp-config.phpが漏れたとは考えにくい
根拠
このwp-config.phpが漏れるためには、wp-config.phpに何らかの方法でアクセスできる必要がある。
WordPressからwp-config.phpにアクセスする方はないと思われる(あるのかもしれないが私は知りません)。
WordPress以外のWebサービス経由か、(ftpやssh等で)loginした上で持っていくか、サーバー自体を乗っとられるか位しか、取得する方策はなさそう。(あるのかもしれないが、私は知りません)
Browserやwget/curl等で取得する方策は、httpd側でphp処理を実行して結果を返すだけになると考えられるのでダメ。
WordPress本体、もしくはPHPのBUGの可能性は捨て切れないが、非常に低いと思われる。
従って、これだけの数(5000以上)のwp-config.phpを「個別に」取得したと言うのは考えにくい。
あり得るとしたらサーバー丸ごと乗っとられて、一気に全部のwp-config.phpを持っていくというシナリオだろう。
注意:
Webサーバーが乗っとられたのか?というと微妙
根拠
もしサーバーが乗っとられたのであれば、WordPress以外のサービスでも書換えなどの攻撃を喰らったのではないかと考えられる。
Blog系は、WPかMTが供給されており、それなりに利用者がいると考えられる。
その他、Mail等も提供されていることを考えれば、WPだけというのは考えにくい
また、一般にこの種のサービスは、利用者にDisk容量を供給するが、一人当たり10Gとか20GとかのDiskを供給することが多い。
その場合、1台のサーバーに5000以上のユーザーを収容するか?というとそういう可能性は低い。
以上から、被害は恐らくサーバー5台分以上に相当する。
それ以上のサーバーがあると考えられるので、その内のWPユーザーがいるものだけを乗っ取ったと言うのは考えにくい。
あり得るシナリオは、1台乗っ取ったか、全部乗っ取っただと思うが、被害範囲から後者。
やはりWPだけが被害を受けていると言うのは考えにくい。
注意
そもそも攻撃者の意図がA社のWPをいじめることにあるなら、WP以外に目をくれない可能性はある
WPを提供しているサーバーとそうでないサーバーが分離している可能性は否定できない
DBが乗っとられたという可能性が高い
WordPressが大雑把に1サイト(一人?)あたりどの程度のData容量を食うのか?を類推してみる。
参考
以上より、
Case-1で1万ブロガーいるとすると、2MBytes * 10000 = 20GBytes/年
Case-2で1万ブロガーいるとすると、300KBytes * 10000 = 3GBytes/年
考え得るシナリオ
結論
以上の考察が正しいとするなら、このような問題が発生した場合、恐らくWordPressの脆弱性とかを疑うよりもサービス及び運用を疑う方が正しいと考えられます。
これは、今回の事案例が「多数の利用者」が「一気に」コンテンツを書換えられたという事例だからで、通常は運用しているWordPressの脆弱性や外部からの攻撃であることが多いでしょう。
備考
ちなみに、世の中にDBが直接公開されている事例と言うのは
こんなの がやはりあるんですね。怖いですね。
あと、某所の事例では、こんな原因の推測もある模様です。
更に追記。こんな情報を見つけました。事実なら、こんな難しい事しなくても行けたということで、衝撃です。つか、さすがにこれが原因なら酷すぎる。元の設定が…