カテゴリー : サーバー

ロリポップに対して残念な気持ち

良かれと思った親切心で行動した結果が、想像していた状況と違う進み方をすると結構がっかりした気分になってしまうようです。「何か期待しているからだ。」と突き放されてしまうとそれで終わりですが、精神衛生上気持ちの整理をしておこうかと思い、ブログに書き留めておくことにしました。

折しもベネッセ社の顧客情報漏洩問題で大きな騒ぎとなっておりますが、既に眠らされたであろうベネッセ社の酷い対応の話もまた蘇ってきました。

【悲報】ベネッセのサイトに脆弱性を指摘したらプロバイダから警告来てネットを停止された…

これは「XSSの脆弱性をベネッセに報告したらプロバイダに接続を止められた。」というもので、ベネッセとプロバイダの関係がよく分かりませんが、少なくとも善意が徒になったようでした。

さて今回自分のしたお節介は、「レンタルサーバーから不正と思われるアクセスがあったのでその報告」をしたことです。

WordPressのサイトには毎日のように不正アクセスを狙った攻撃が行われておりまして、自分のサイトも同様ですので、独自のプログラムでアクセスログを残すようにしています。

アクセスの多くは海外のサーバーからが多いのですが、たまに国内のサーバーからもあります。そして今回、昨年大規模クラッキングがあったロリポップサーバーのIPアドレスだったので、一応報告しておこうという気持ちが起こりました。

結果、あのときのロリポップを運営する会社を束ねるGMOインターネット社会長の対応も思い出してしまいました。以下は、あのときの当方の記事です。

ロリポップ大規模クラッキング事件を考える

ロリポップへの報告ですが、知り合いがいるわけでもありませんので「お問合せフォーム」を利用して連絡をしました。返信メールの内容は別におかしいモノではなく、詳細についてアクセス時間を秒まで含めて知らせて欲しい、ということでした。

数日複数回のアクセスがありましたのでリストをキャプチャ画像にして返信したところ、「配信専用のためお問合せフォームから連絡しろ」と、メールで怒られてしまいました。

詳細を知らせて欲しい、といいながら「どこに送ってくれ」の情報もないし、担当者は名字しか名乗らないし、「やる気はないのだろう」と直ぐに察しました。

ブックマークもしていないレンタル会社のお問合せフォームに入力するのは面倒ですが、乗りかけた船でしたのでもう一度、「キャプチャ画像を送るから送り先を知らせて欲しい」旨連絡しました。

すると、メール文の中に含めてあった「不正アクセスされたURL」で調べるとのこと、また「結果について知らせて欲しい」件については、「社内利用規約に基づき詳細な対応内容について連絡できない。」という回答でした。

ここが一番重要で、報告は「何が起きているのか」の情報を共有させて欲しいから、行うわけです。相手には対応の必要がある情報として有益だと思いますし、また自分に対しては関心のあるセキュリティに関してフィードバックになります。

この件で、GMOインターネットや関連企業がどんな会社か、担当者の仕事に対するモチベーションは、などが何となく透けて見えてしまった気分でした。

今後は報告するのも相手を見てからにしたいと思います。この件はこれで終わりです。

クラッキングされて、悪い結果で自社の名前が晒されないように注意したいモノです。

 

ロリポップ大規模クラッキング事件を考える

2013年8月29日は、朝Twitterを見るとロリポップサーバーがクラッキングされ大騒ぎの状態でした。利用はしていませんが、推移を見守りつつ釘付けの一日でした。

本日は30日で、まだ侵入ルートやクラッキングの手口は明らかではありません。が、状況を見つつ2つの点で感じたことや考察を記録しておきます。なお、本記事の公開は状況が落ち着いてからします。

被害の大きさ

キャプチャ画像はロリポップの『当社サービス「ロリポップ!レンタルサーバー」ユーザーサイトへの第三者による大規模攻撃について」に掲載された内容の一部です。

lolipop_jp_info_news_4149_01

8,438件がサイト数なのか契約者数なのかハッキリしませんが、クラッキングされたサイトの顕著な状態は、サイトのタイトルにクラッカー名と思われる「Hacked by Krad Xin」と付け加えられている点と、サイトにより文字コードがUTF-7にされ、ブラウザで表示できないところが沢山ありました。

なお、本記事ではサイトが改竄されたので「クラッキング」という言葉を使います。

初動のやり取り

利用者からの報告に社長がいきなり「風説の流布になりますよ。事実を確認してからツィートしてください。そのような事実はありません。」て、もっとも永江さんの報告だからこのような対応になったのだと思いますが、確認もせず火消しに走ったわけです。

ここからクラッキングが判明して対応を始めるまでのツィートは、多くの人が参照可能なところで発言する内容とは思えないため、自分としては残念に感じました。

ですが、緊張感が高まりました。

ロリポップ側の姿勢

大変疑問に感じました。何しろ自分には責任ありません、感が前面に出ています。

[現在までに判明している被害状況]
WordPressのプラグインやテーマの脆弱性を利用し、不正なファイルがアップロードされました。 またそのファイルを利用し、wp-config.phpの設定情報が抜き出されることにより、データベースの書き換えが行われ、WordPressサイトが改ざんされました。

これ読んだ人は間違いなくクラッキングの原因は「WordPressのプラグインやテーマ」だと思うでしょう。

ですが8000以上もがクラッキングされたのですから、サーバー機能にレンタルサーバーとしては脆弱な部分がある、と推察されるし、中の人も分かっているためこのような書き方になったのではないかと思います。

というのも、WordPressのデータベースアクセスに関する情報が「wp-config.php」ファイルにあるわけですが、対策で「ファイルパーミッションを400に変更」としています。

クラッキングの拡大はなぜ

WordPressに限らずログイン名とパスワードで管理画面を操作するのは、ほとんどのサービス、Amazonも、PayPalも、銀行も、皆が利用する方法です。

ログイン名やパスワードが知られ不正ログインされれば、当然被害を受ける可能性は100%なわけですが、他のユーザーまで及ぶものでしょうか?

この点においてレンタルサーバーに脆弱性があるのでは、と思い及ぶ訳です。ロリポップがこの点を明らかにするかどうか、静かに見守りたいと思います。

なお発表の事実から予想すると、不正にアップロードされたプログラムにより共用サーバー上のディスク内を容易にアクセスでき、wp-config.sysが参照されサーバーのログイン情報が抜き取られたように思います。

次にデータベースにアクセスされ、WordPressの登録データ(サイト名やキャラクタセット)が書き換えられたのでしょう。

ここで疑問に思うのは、ある1人のユーザーサイトから他のユーザーのデータベースをアクセスできるかどうか?です。

できるのであれば、正にウィークポイントです。

そうでなければ8000件以上のユーザーサイトにログインするには、ユーザー管理情報が分からない限りは無理かと思います。ですので、他の人が言及しているようにデータベースがグローバルアクセスできる状態だったのではないでしょうか。

このような事実があれば重大事なので、真相が明らかにされるかどうかは疑問な訳です。

<追記 130831>
MySQLのユーザーアクセスの設定は、ユーザー名とホスト指定しかないため同じホストに収容されている場合は、1人のユーザーサイトから他のユーザーのデータベースもアクセス可能なことに気が付きました。
</追記 130831>

PHPに関してですが、PHPがモジュールモードで動作している場合、セーフモードにより自分以外のユーザーソースへのアクセスに制限が加えられるわけですが、ロリポップではセーフモードをOFFにできるような記事が検索で上がってきました。これは危険ではないでしょうか?

セーフモードは 5.3 で非推奨、5.4で削除されたので、サーバー側で対応しない限りモジュールモードで動作するPHPは危険です。

もし利用しているサーバーでPHPをCGIモードで動作させることができるのであれば、直ぐに移行するべきです。

なおレンタルサーバーによりPHPのバージョンが5.3に上げられない場合、お引越しをする方がセキュリティ上は幸せになれます。

脆弱性を孕んだサーバーは、狙われれば確実に餌食になります。

Webアプリケーションを安全に利用するために

共用レンタルサーバーを利用する上で注意しなければならないのは、第1に今回のようにレンタルサーバー自身に脆弱性が存在するかどうかです。経験上で申し上げると緩いレンタルサーバーは見たことがあります。

しかし一般的には提供会社を信頼するしかありませんので、専門家のアドバイスを聞いて判断するしかないと思います。

ではWebアプリケーション(プログラム)を安全に利用するためにはどうするべきでしょうか?それは何と言っても、不正ログインされないようにログイン名やパスワードはしっかりと管理しておくことでしょう。

また、保存されるデータが何かも重要になります。

クレジット情報など重要なデータを扱わない限りはサイトが書き換えられる程度なので、バックアップさえしっかり取っていればそれほど心配はいらないと思います。

なお、書き換えられる程度、と言っても、ウィルスソフトを仕込まれたり悪意あるサイトへリンクを張られたりする可能性があるので、楽観的ではいられません。WordPressのようなCMSは、サイトの表示内容を変更したり、プログラムをアップロードできるので注意が必要です。

以前クラックされたサイトでは、参照されるタイミング(このときは時間でしたが)によってJavaScriptのプログラムが組み込まれたり、組み込まれずに普通に表示したりと、手の込んだ処理がなされ、クラッキングに気付き難いようになっていました。

一方、信用情報やあるいは平文のパスワードがある場合は、セキュリティに関して一切の甘さは許されません。そのようなサイトは、共用レンタルサーバーでの利用はあり得ないと思います。

ロリポップユーザーはどうしたらいいか?

大変な被害を被られご心中お察しいたします。

いろいろと書いてみましたが、ステークホルダーのことを考え削除しました。

(2013-08-30)

WordPressのプラグインやテーマの脆弱性とは(2013-08-31)

レンタルサーバーの脆弱性について多くの人が気付いていたように、ロリポップはレンタルサーバーに脆弱性があったことを認めました。

lolipop_jp_info_news_4149_02

しかしその侵入経路を「WordPressのプラグインやテーマの脆弱性を利用」と特定していますが、その根拠が曖昧です。

もしその事実がハッキリしているならば、どのプラグインの、あるいはどのテーマのどういったウィークポイントを付いてWordPressのユーザー名とパスワードを抜き出したのか、説明する必要があるかと思います。

この点について今後説明があるかどうか待ちますが、経緯を見ていると最初に社長の「WordPressには脆弱性がある」の発言から始まって、今は言い回しが変化して「プラグインやテーマの脆弱性」と表現しているところを見ると、言葉が引っ込められなくなっているからではないでしょうか?

実は、WordPressサイトを狙ったブルートフォースアタックが行われていることが頻繁にTwitter にも流れており、不正ログインされた原因はこれではないかと推察しているからです。

WordPressの利用は危険?(2013-09-02)

今回は、WordPressの利便性が悪用されたのを実感しました。

どのサイトもログイン名やパスワードが漏れれば被害を受ける可能性は大きいわけですが、CMS機能があるWordPressは自サイトにダメージを受けるだけでなく、そのサイトをアクセスする利用者にも影響を及ぼすことが簡単にできます。ましてや共用サーバーに脆弱な部分があればその被害は甚大であることを目の当たりにしました。

WordPressの利用が危険かどうかに関して、不正ログインされた場合の影響が非常に大きいので、不正ログインされ易ければ「危険」と言わざる負えないでしょう。

危険を回避するためには、不正ログインされ難い機能を追加していく必要があると思います。専門家でないユーザーが簡単に利用できるWordPressは、今のままでは利用者次第であまりにも大きい穴が空いてしまいます。

そこで、ログイン操作が面倒になりますが2段階認証やキャプチャ画像の利用、ログイン失敗回数の制限などを利用したログインは有効かと思います。

今後の機能追加を期待したいと思います。

突然Apacheが動かなくなった

今日は4月1日月曜日、出勤すると朝一番、「システムに接続できませーん」と連絡が。何、朝から4月バカ言ってんの、だったら良かったのに。

サーバーは動作しているし、pingは通るし、SSHで接続はできるので問題はそこではない。どうやらApacheが落ちているようで早速再起動、[失敗]の表示。えーーーっ?

サーバー管理者と言っても運用に入れば、年に数回ユーザー管理で操作するぐらいなので、全く対応ができない。とにかく業務ができるようにする方が先決なので、Pentium 4の古いPCを引っ張り出して来て、代替動作させることにした。

心配なのは運用サーバーはAsianux Server 3でPHPが5.2、一方代替えはUbuntu Server 12.04でPHPが5.3。業務システムはCakePHP1.2系で組み込んでいるので「きっと何かあるだろうなぁ」と思いつつ、作業を進める事を決断した。

データベースを移植し、Apache2を設定、DNS切り替えて何とか昼過には使えるようになった。ええそうです、ドタバタしました(´Д`;)。あとは野となれ山となれ。

さて元のサーバーで何故Apacheの起動ができなくなったのか?見事ビンゴな回答が@ITの会議室にあり、Google先生に指示していただきました。

Apacheが突然起動できなくなった
http://ap.atmarkit.co.jp/bbs/core/flinux/27877

blunderさんが回答して下さった内容で、ログ「logs/nss_error_log」を覗くと

[error]Certificate not verified: 'Server-Cert'
[error]SSL Library Error: -8181 Certificate has expired
[error]Unable to verify certificate 'Server-Cert'. Add "NSSEnforceValidCerts off to nss.conf so the server can start until the problem can be resolved.

と出力されていた。で、

# certutil -L -d /etc/httpd/alias -n Server-Cert

とすると「Validity」の表示に

Validity:
    Not Before: Thu Mar 26 20:50:22 2009
    Not After : Tue Mar 26 20:50:22 2013

と。先週の火曜日に切れていたようだけど、連絡はなかったので暫く動作していたということか。

メッセージの通り、nss.confに「NSSEnforceValidCerts off」とセットしてApacheを再起動したら[ OK ]と表示。

これでエイプリルフールの一日が終りました。

ところで、Kindle Paperwhite買ったらいろいろ買い込んでしまい、楽しんでいるのでちょっと紹介します。

   

と、定番かも知れませんが一通り購入しました。自分持ちのPDFはメールでクラウドに送れば、WiFi接続することでKindleにダウンロードされます。自分は3G付きを購入したので、Kindleストアで購入したものは直ぐにダウンロードされて読めます。便利いいです。

で、最近藤本壱さんの

を購入して、曖昧だった正規表現の勉強をし直してます。

MySQL 古いMTからMTOS(5.14)へのデータ移植について

古いMovable Typeのデータを新しいMovable Type(以下MT)へ移す作業で、サイトごと移すためにデータの引っ越し作業を実施しました。古い方にはデータのエクスポート機能がないようで、MySQLデータベースからデータを取り出し新しいサイトのデータベースに移す、という方法です。

古いサイトのMySQLはバージョンが3.23、新しい方は5.1で、文字コードがEUC-JPのデータをUTF-8に変換して取り込まないとなりません。この作業に時間が少し掛ったのでその備忘録です。

古いバージョンのデータを新しいMTへ持ち込む方法として助かったのは、新しいMTで利用するデータベース(mt-config.cgiで指定)のテーブルが古いバージョンだと、自動でテーブルをアップグレードしてくれる事でした。なので、テーブルの構造やデータをいじる必要がなかったのです。

手順

1.エクスポート

まずはデータをSQLテキストでエキスポートします。この方法は簡単で、phpMyAdminが利用できるなら「エクスポート」を利用します。エクスポートする際は、面倒臭くても各テーブルを別々にエクスポートしましょう。自分は一括でエクスポートして痛い目を見ました。

出力時は「DROP TABLE」を追加し、「ファイルで保存」出力する名前をテーブル名で指定してエンコーディングせずに「non」指定でダウンロードします。

今回は「mysqldump」が利用できなかったのでphpMyAdminを使いました。

2.EUC-JPをUTF-8へ変換

これはテキストエディタのTeraPadを利用しました。TeraPadの注意点は、8000文字以降は無視されてしまうことです。そのため別のMeryも利用しました。いずれもWindowsのフリーソフトです。

3.インポート

SSH接続でしたので、FTPでアップロードしたファイルをmysqlコマンドを利用してインポートしました。

mysqlコマンドを使う場合、コマンドでログオンしてからインポートする方法とログオンせずにmysqlコマンドにSQLデータをリダイレクトしてインポートする方法があります。

コマンドでログオンする場合

$>mysql -h localhost -u username -p databasename
Password:
>source SQLデータファイル名;

コマンドにリダイレクトする場合

$>mysql -h localhost -u username -p databasename < SQLデータファイル名

以上で、mt.cgiをブラウザから呼び出しアップグレードして、新しいMTに移す事ができました。

 躓いたところ

2ヶ所の落とし穴にはまりました。

最初の落とし穴はインポートしたデータが文字化けしてしまうことです。mysqlコマンドでデータを見る限りは正しく表示されるのに、MTでページを表示するととんでもない事に。

原因はmysqlコマンドを実行した際の文字コード設定変数にありました。

こんな状態で取り込んでいたのが原因のようです。そこで「set names utf8;」を実行して矯正します。

これで文字化けは解消しました。

次の落とし穴は肥大したテーブル「mt-comment」と「mt-log」です。山のようにスパムが送り込まれており、取り込まれたデータは表示できないようなデータも含まれているためです。

実際、SQLデータにデータを落とすとあちこちでデータフィールドの境が壊れ、取り込もうとしてもエラーになってしまうのです。

仕方ないのでphpMyAdminを利用してデータを抽出し、さらにテキストエディタで修正して取り込むようにしました。取り込み時にエラーが発生した場合はそれを修正して再投入です。しかしながら「mt-log」の方はきっぱりとあきらめました。ログなのでテーブル構造だけとしました。

抽出する際の方法は、繰返し実施している人ならきっとノウハウがあると思います。自分は初めてでしたので、以下の2つの方法を考えてみました。

1つはcomment_author項目がアルファベットのみのデータをはじく方法です。where句に以下の指定をします。

WHERE comment_author not REGEXP '[0-9a-zA-Z[:blank:] @\.-]'

この方法だと、文字化けしたデータをはじく事が上手くできませんでした。もう1つはcomment_junk_log内の「Filter (0)」に目を付けた方法です。

WHERE comment_junk_log not like '%Filter (0)%'
AND comment_junk_log not like '%Filter (-1)%'

この方法は結構効きました。comment_idでソートしたらスパムデータが後の方にかたまったので、テキストエディタで削除して取り込みました。

もっと複雑なSQLを組めればさらに精度が上がるでしょうが、今回はここまでで止めました。

 

CentOS 5 操作備忘録 2

少し時間を空けただけで操作を忘れてしまう、そんなおバカな自分の参照用です。

固定IPアドレスの設定とDNSのIPアドレス設定

サーバー公開のためDHCPサーバーを利用せず固定IPアドレスを設定する場合、gatewayアドレスやDNSサーバーのアドレス設定が必要になる。DNSサーバーの設定はファイルが異なる。

固定IPアドレスの設定
/etc/sysconfig/network-scripts/ifcfg-eth* *はカード番号(0)
DEVICE=eth0
BOOTPROTO=none #DHCPを利用するときはdhcp
ONBOOT=yes
GATEWAY=192.168.0.254
IPADDR=192.168.0.1
NETMASK=255.255.255.0
DNSサーバーのアドレス設定
/etc/resolv.conf
nameserver xxx.xxx.xxx.xxx
nameserver xxx.xxx.xxx.xxx