クラッキング(ハッキング)被害を受けたサイト管理者がとるべき2つの重要な対策

生まれて初めてクラック(ハッキング)された。今回クラックされたのは自分が借りているバリューサーバー。今のところ やられたのはその中の1台のみらしく、幸いにして閲覧者に被害を及ぼす心配はなかった。今現在は大丈夫でも、今後危険になる可能性が「ある」。その可能性が、侵入されたサーバーにファイルとして「残っている」という事実だ。では、どうしたらよいのか。今後同じような被害を受けた人のために、今回の対処方法を書き残しておきます。

お詫び:
2014年1月19日17時頃から23時すぎまで、当サイトはクラッキング(ハッキング)被害を受けました。閲覧画面に下のような表示がなされましたが、閲覧された方に被害が及ぶ心配はありません。ご迷惑をおかけして申し訳ございません。詳細は以下の記事をご覧ください。


追記 2014年1月20日21:01
本日夕方17時過ぎから先ほど20時すぎまで、またクラックされましたが、今回は明確に原因を特定できているようです。

VALUE-DOMAIN.comのユーザーフォーラム s1.valueserver.jpへのクラッキングについて より

特定の管理ユーザー以外昇格できないようにする設定ファイルに、とあるユーザー様が追加され、そのユーザー様領域内での不正なプログラムがおかれておりました。

当サイトを閲覧いただいた皆様には重ねがさね失礼いたしました。以下、本文です。


生まれて初めてクラック(ハッキング)された。まあ、共有サーバーである以上誰かがミスれば全体に影響するというのはある。今回クラックされたのは自分が借りているバリューサーバー(VALUE SERVER – valueserver.jp)。

今のところ やられたのはその中の1台、s1.valueserver.jpのみらしく、幸いにして閲覧者に被害を及ぼす心配はなかった模様。今回、この記事を書いているテーマはここで、閲覧者に被害を及ぼす心配は「なかった」のであって、今現在は大丈夫でも、今後危険になる可能性が「ある」ということ。その可能性が、侵入されたサーバーにファイルとして「残っている」という事実だ。

詳しく説明するために、まず起こった状況から。

クラッキングされた画面

実際に受けたクラッキングの詳細

自分が気づいたのは23時過ぎだったんだけど、実際には17時頃に最初のクラッキングがあったらしい。最初というのは、その後再びファイルが書き換えられるアタックがあったから。最低でも2回侵入されている。

VALUE-DOMAIN.comのユーザーフォーラム s1.valueserver.jpへのクラッキングについて より

2014/01/19(Sun) 18:58
今日の17時ごろs1サーバー内のファイル(ファイル名に”index”が含まれるもの)が別の内容に書き換えられたようです(添付画像参照)。

2014/01/19(Sun) 22:42
先ほど修正したはずなのですが、22:26 にまた index.html が
別のファイルに書き換えられました。(一部のディレクトリのみ)
もうどうにでもなれって感じです。

1回目の攻撃で黒地の画面に”Hacked by Jacko Nexus”と表示されるようになり、2回目の攻撃で画像が兵士のものに変更され、音も鳴るようになった。自分が実際に見ているのは音の出る方の画面。

クラッキング(ハッキング)の原因

正確な原因は攻撃した側と、被害を受けたサーバー管理者しかわからないので、バリューサーバーの発表を待つ必要がある。もちろん待っても本当の原因を発表するとは限らないけど。ただ、フォーラムの情報を見るとポートに穴が開いていたらしい。

VALUE-DOMAIN.comのユーザーフォーラム s1.valueserver.jpへのクラッキングについて より

2014/01/20(Mon) 01:00
はてなブックマーク ( http://b.hatena.ne.jp/entry/kumalog.com/2014/01/19201213.php ) で以下のような指摘がありました。
—————
s1.valueserver.jpの31337ポート(トロイの木馬に感染したときの
Back Officeポート。通称「エリート」ポート)が空いているね。
—————
確認したところ現在も開いたままなので、まだ色々まずいかも知れません。

2014/01/20(Mon) 05:27
こんばんは。
はてなブックマークで31337ポートが空いてるよって書いた者です。
HTTP復旧したようですね。もう31337ポートは空いていません。
おそらくセキュリティパッチを当ててサーバーを再起動したか、
新しい筐体にユーザーのデータを移して起動させたのかと思います。

私はここのサーバーを使っていないので、NULLさんが指摘された
PHPのバックドアのファイルが残っていないか気になるところですが、
これでしばらくは大丈夫かなと思います。

#しかし未だ開ける必要のないポートが沢山開いている…。
iptablesでファイアウォール設定とかやってないのでしょうね…。
OSやミドルウェアの更新とかも定期的にやらずに放置だったのでしょうね…。

クラッカーは、おそらく開いているポートから侵入したのでしょう。

追記:[2014/01/20 21:30] 原因が公式発表されました

  • あるユーザーにて、WordPressの脆弱性をつき、不正なプログラムが設置された
  • そのプログラムからシステムの脆弱性つかれ、インデックスページを書き換えるプログラムを実行された
  • インデックスページを設置されているサイトにおいて、id.htm、in.php、index.php、index.htm、index.html の内容が変わり、動作しなくなった

被害を拡大しないためにするべきこと

バリューサーバーの対応が出来たので多分、今すぐ再侵入される可能性は低いと思う。しかしまだ問題が残っている。それはクラッカーによって書きこまれたPHPのバックドアファイルだ。これが残っている以上、いつでもクラッカーは攻撃を仕掛けられる。どういうことかというと、実はフォーラムにこのように書きこまれている。

VALUE-DOMAIN.comのユーザーフォーラム s1.valueserver.jpへのクラッキングについて より

2014/01/20(Mon) 01:27
Tomさんの
>~/inphpの内容
>http://dwm.me/download/in.txt
がかなり興味深いですね。

デコードすると分かるのですが、バックドアとして機能するようです。
これは早急に対策しないとマズイです。
いつ悪意のあるページに書き換えられてもおかしくありません。

追記:http://dwm.me/download/in.txt
このファイルですが削除されたみたいです。
アップしたのは私なんですが、消したのはおそらく管理サイドだと思うので再アップはしません。
ソースは公にしないほうがいいとも思うので。

そのバックドアとは何なのか。

IT用語辞典より

バックドア 【 backdoor 】

クラッカーにより侵入を受けたサーバに設けられた、不正侵入を行うための「裏口」。

クラッカーはコンピュータへの侵入に成功すると、次回も侵入できるように、管理者に気づかれないようこっそりと侵入経路を確保する。これがバックドアである。

簡単に言えば、今は「ターミネーター2」でシュワちゃんが溶鉱炉に入ることになった時のような状況。ファイルがある以上、それを消し去らないとまた敵が攻撃してくる。

では、どうしたらいいのか。自分は対策には2種類あると思っている。それは具体的な対策と潜在的な対策だ。具体的な対策を書く前に、潜在的な対策を書いておきたい。

発信者の責任

もしも推測の通りポートの穴が原因なら、それはバリューサーバーの管理責任といえる。しかし、そのサーバーを使ってサイトを公開している以上、忘れてはいけないことがある。自分たちは、あくまで発信者なのだ。サイトを訪れた閲覧者に不利益をもたらすことをしたのなら自分にも責任が生じる。

これは今月本当にあった話だけど、テレビ番組でダンサーがFUCKと書かれた衣装を着て踊ったとする。しかも子供向けの番組で。これはダンサーだけの責任だろうか?放送局にも責任はあるのではないか?いや、むしろ局側の責任のほうが大きいのじゃないか。

そしてブログというのは例え小さかろうがメディアであるということ。メディアである以上、テレビと同じ立場だ。配信する側には責任がある。バックドアからウィルス的なものを仕込まれ閲覧者に感染したら、そのサイトにも責任が生じる。

参考:社員にTOEIC受験を義務づけるのは楽天やUNIQLOより放送局にお願いします | More Access! More Fun!

f83e2898

被害を受けるのはサーバーのユーザーだけとは限らない。自分のサイトを開いた人が何かを仕込まれるかもしれない。もしそうなった時、責任はそのサイトにもある。それが情報を発信する側の責任だ。

昨年あった「あし@」の詐欺広告

昨年、あし@のサーバーが乗っ取られ、パーツを貼っているブログに強制的に詐欺広告が表示されるという事件があった。

あし@で表示された詐欺広告

「あしあっと事務局」がユーザーに送ったメールより

この度、2013年9月20日に、あし@の広告を配信しているアドサーバーの広告管理アカウントの一つに部外者からの侵入があり、広告の内容の一部に改変が加えられた事で、あし@の広告が表示されると、予期せぬポップアップ広告が表示されいるという現象が発生しておりました。
ご迷惑をおかけ致しましたブロガー様、読者様には深くお詫び申し上げます。

この時、気になったことがある。「あし@」が設置された状態で放置された、更新していないブログの多くが管理者の気づくことなく「詐欺広告」を表示し続けていたという事実。そして、それに引っかかり詐欺ソフトを買ってしまった人物もひとり知っている。

もちろん一番悪いのはクラッカー(ハッカー)だ。そして、それを防げなかった「あし@」にも責任はあるだろう。それが原因かどうか知らないが「あし@」は今月いっぱいでサービスを停止する。

では、この広告を配信してしまった「ブログ」には責任がないのだろうか?自分は「ある」と思っている。ましてや、更新せず放置したまま気づかなかったブログ管理者の責任は大きいと思う。

クラッカーの攻撃を受けたサーバーにとって、侵入を許してしまうのはある意味やむを得ない部分もあって、防げなかったことを強くは攻めるつもりはない。同じように、ブログで使っていたパーツが知らないうちに詐欺広告を表示していたとしても、ある意味やむを得ない。というか貼っている以上防ぎようがない。

問題はいかに早く気がつくかだ。そして気がついたらいかに早く対処するかだ。2次攻撃を受けるまで気がつかなかった自分が言えることではないが、サイト管理者は責任を持って対処しないといけない。

共有サーバーには自分以外のサイトもある

そして、共有サーバーを使っている以上、自分がバックドアを仕込まれたら他の全員に迷惑をかけることになる。今回の責任がバリューサーバーだとしてもバックドアを削除せずに残したままにしておいたのなら、次の被害を受けた時の責任はそのサイトにもある。それが共有サーバーなら他の全員に被害が出る。

実際、昨年「ロリポップ」が乗っ取られた時の状況は、たったのひとりから発生した可能性もある。

【緊急警報!!】ロリポップとGMOのinterQのWordPressが軒並み乗っ取られてます | More Access! More Fun!

サーバクラックではないとすると、1人のアカウントに侵入し、同じサーバ上のWordPressをすべて乗っ取ったというのが一番考えられるのではないかと。共有サーバでWordPressを使う危険性がまざまざと浮き彫りになったわけです。

具体的な対策

では、どうしたらよいのか。バリューサーバーのユーザーは、おそらく自分で対処できるベテラン揃いだと思う。けど、今後同じような被害を受けた人のために、今回の対処方法を書き残しておきます。

トップディレクトリに5つのファイルが書きこまれているので全て削除。

  • id.htm
  • in.php
  • index.php
  • index.htm
  • index.html

このうちの少なくともどれかひとつは、元からあったファイルの名前ですが、改ざんされています。削除して作りなおしてください。特に重要なのが「in.php」で、これが問題のバックファイルです。

5つのファイルが書きこまれているのはトップディレクトリだけですが、その他のディレクトリにindex.* (index.で始まるファイル)がある場合、すべて確認、訂正します。

静的なHTMLだけなら、これで完了と思われます。

WordPressの場合

WordPressの場合も、トップディレクトリのindex.phpを書きなおすだけでサイトは表示されるようになります。しかし、トップディレクトリの修正だけでは管理画面にログインできません。wp-admin/index.phpも書き換えられています。

WordPress3.8の初期状態のindex.phpは以下のとおりですが、すべて改ざんされていました。

wordpress $ find . -name index.* -print
./wp-content/index.php
./wp-content/themes/twentyfourteen/index.php
./wp-content/themes/index.php
./wp-content/themes/twentytwelve/index.php
./wp-content/themes/twentythirteen/index.php
./wp-content/plugins/index.php
./wp-content/plugins/akismet/index.php
./wp-admin/user/index.php
./wp-admin/index.php
./wp-admin/network/index.php
./index.php

バックアップがない場合、英語版の wordpress.org または 日本語版の ja.wordpress.org のどちらかから.zipファイルをダウンロードして解凍。中にあるindex.phpをそのまま再設置します。英語版も日本語版も index.php は同じなので日本語版でなくても大丈夫です。

インストールしているテーマやプラグインの中にもindex.*があるのですべて修正します。

WordPressを専用ディレクトリにインストールしている場合、トップディレクトリのindex.phpの中身は1行だけ違います。それについてはWordPress Codexの「WordPress を専用ディレクトリに配置する」を参照してください。

今回の攻撃ではDB(データベース)の改ざんは、確認されていません。