@PAGESで平文のパスワードを含む全ユーザーの管理情報が流出 41
ストーリー by headless
平文 部門より
平文 部門より
無料ホームページサービス「@PAGES」のユーザー管理情報データベースから、平文のパスワードを含む全ユーザー175,297人分の管理情報が流出したそうだ(ユーザ情報流出に関するお知らせ【第2報】、
ITmediaニュースの記事、
INTERNET Watchの記事、
CNET Japanの記事)。
流出したのはパスワードのほか、ユーザー名やメールアドレス、登録日時、登録時のIPアドレスなど。クレジットカード情報や住所、氏名、電話番号などは管理情報として登録されていないため流出していないという。原因としては、ユーザー管理情報データベースにアクセスするためのユーザー名とパスワードが流出し、データが抜き出された可能性が想定されるとのこと。流出したデータは「一般のブラウザではアクセスできない特定の場所」で閲覧可能な状態となっており、該当ファイルを削除することは技術的に困難だという。@PAGESを運営するアットフリークスでは、全ユーザーのパスワードをリセットし、ユーザー管理情報データベースに保存するパスワードを暗号化、ユーザー管理情報データベースにアクセスするためのパスワードを変更したとのことだ。
流出したのはパスワードのほか、ユーザー名やメールアドレス、登録日時、登録時のIPアドレスなど。クレジットカード情報や住所、氏名、電話番号などは管理情報として登録されていないため流出していないという。原因としては、ユーザー管理情報データベースにアクセスするためのユーザー名とパスワードが流出し、データが抜き出された可能性が想定されるとのこと。流出したデータは「一般のブラウザではアクセスできない特定の場所」で閲覧可能な状態となっており、該当ファイルを削除することは技術的に困難だという。@PAGESを運営するアットフリークスでは、全ユーザーのパスワードをリセットし、ユーザー管理情報データベースに保存するパスワードを暗号化、ユーザー管理情報データベースにアクセスするためのパスワードを変更したとのことだ。
一般のブラウザではアクセスできない特定の場所に一般のブラウザで行ってきました (スコア:3, 興味深い)
「一般のブラウザではアクセスできない特定の場所」という言い方をしていますが、これは少しでも安心感を持たせたいという目的があってこういう言い方になったのでしょうか。
確かに、普通はツール（意味深）をインストールしてアクセスする場所にありました。
けれども、私はなんのツールもインストールせず、特別なアドインや拡張機能をインストールしていないFirefoxで流出したデータを含むファイルをダウンロードできました。ある程度の知識があれば、だれでもできると思います。
ファイルの内容を見た印象は、データベースをセットアップするときに使ったのかなというものでした。
このファイルを使った人は、その内容（平文でのパスワードを含んでいること）の重要性から、非常に慎重に扱わないといけないと分かってそうなものですけどね。
メールアドレスの種類が多様だったので、特徴的なものをgrepで抜き出してみました。
数はユーザ数ですが、発表資料に合わせて重複があってものべで数えています。
@*.go.jp:16
@*.lg.jp:6
@pref.*.jp:4
@*.city.*.jp:3
@town.*.jp:1
@*.ac.jp:890
.ac.jpが特に多い点が目につきますが、毎年同じ時期に集中してアカウントを取得しているので、情報系の演習で使われたのではないかと推測しています。
.co.jpは全体の４割程度を占めていて、excite&hotmail&yahooを除くと597ですが、そこから会社のアドレスとその他のフリーメールアドレスとを分別しきれませんでした。
あと、明らかに有効でないメールアドレスであったり、アフィリエイト業者が取得しているためにアカウントが凍結されたりしているので、有効なアカウント数は発表されたユーザ数よりも少ないと思います。
８月３１日付け追記から (スコア:3, 興味深い)
ユーザ情報流出に関するお知らせ【第2報】 [atwiki.jp]から一部転載。
それ以降にパスワードを変更している場合には（変更前のパスワードは流出しているので既に不正アクセスされていたかもしれませんが、変更後のパスワードについては流出していないと考えたいから）流出したパスワードでの不正アクセスの恐れはございません。
また、流出時刻以降にメールアドレスを変更している場合には（変更前のメールアドレスは流出しているので既に不正アクセスされていたかもしれませんが、変更できたということは変更以降には流出していないと考えたいから）変更後のメールアドレスは流出しておりません。
ニホンゴムズカシイネ。
個人的には、@PAGESへの不正アクセスによる被害よりも、メールアドレスが所属しているメールサーバに使いまわされたパスワードで不正アクセスされることのほうが被害甚大だと思っています。
Re: (スコア:0)
>メールアドレスが所属しているメールサーバに使いまわされたパスワードで不正アクセスされること
デフォルトでは@PAGESが生成した5文字程のパスワードが設定されているので、ユーザ側にて使い回しているパスワードへ変更する措置を取っていない限りは、そのような恐れはありません。
Re:８月３１日付け追記から (スコア:1)
>5文字程
今確認したら、生成される文字数は英数字で14字です。
英数字で14字でないパスワードを数えたら、31317個でした。
全体で175297個ありますから、少なくとも17.9%はパスワードを変更していることになります。
>ユーザ側にて使い回しているパスワードへ変更する措置を取っていない限りは、そのような恐れはありません。
リスト形式のクラックで使うには十分な数だと思います。
Re:８月３１日付け追記から (スコア:1)
ちょっと訂正。
データベース上ではハッシュ化か何かして14字以上にしているようですね。
逆にいうと13字以下の場合は生のパスワードになっています。
14字以上の場合にも生のパスワードが含まれていますが、割合としては少ないものでしょう。
175297個のうち英数字で13字以下のパスワードは31309個ありますから、少なくとも17.9%はパスワードを変更していることになります。
P2Pなネットワークに流れているのかな？ (スコア:2)
やけに遠回しな表現だけど、そういう事だよね。
Re:P2Pなネットワークに流れているのかな？ (スコア:1)
いや最近はやりのTorです。「一般のブラウザではアクセスできない」というのはほとんど嘘
@chs（2ch風掲示板サービス）でも流出、ただしパスワードはハッシュ (スコア:2)
@chs「【お詫び】ユーザ情報流出に関するお知らせ」 [atwiki.jp]
＞ ※流出内容
＞ユーザ名
＞パスワード（暗号化済）
＞メールアドレス
＞登録時のIP
＞※影響範囲
＞2013年2月25日 19時36分以前に登録されたユーザ様全員
＞
＞パスワードは単一方向の暗号方式を用いており、
＞暗号化されたパスワードから元のパスワードを推測することはできません。
こうなると、アットフリークス管理下のサービスでは全てユーザデータの流出を疑う必要があるのではないだろうか。
少なくとも、ユーザ側は自衛としてそれを前提として動くべきなんじゃないかなと思う。
2chでもそうだったけど (スコア:1)
パスワードを平文保存 (スコア:0)
こういう事件を見るたびになぜパスワードを平文保存するのか理解できないのだが。
ハッシュ化するのが常識じゃないのか？
Re: (スコア:0)
そして慌てて「ユーザーのパスワードの暗号化」とか言われても、またマヌケな実装してんでしょ？と疑わざるを得ない件。
Re: (スコア:0)
「IT技術者の人件費は、システムが動かなくなるまで削減され続ける」
というマーフィーの法則(?)があってもいいと思う。
そういう組織では技術者は「安かろう悪かろう」なんだよ。
Re: (スコア:0)
実際安かろう悪かろうなエンジニアも多いけどな
Re: (スコア:0)
そりゃ、やっすい金しか払ってくれない奴等になんて
モチベーション上がる訳もなく品質の悪いものが納入されるだろ
Re: (スコア:0)
まあそれも一面の真実かもしれんけど、
同じ相手に高い報酬払えば高い品質が得られるわけでもないでしょ。
安かろう悪かろう。
悪かろう安かろう。
Re: (スコア:0)
Re: (スコア:0)
>同じ相手に高い報酬払えば高い品質が得られるわけでもないでしょ。
得られる場合は多いと思いますよ。
システム改修には多くの時間＝マンパワーが必要なわけで、
逆に言うと会社側が明示的にマンパワーを使うことを許可しない
限り、改修はされません。
改修にマンパワーを使うことを許可したら、結果的に
残業代という「報酬」を払うことになります。
Re: (スコア:0)
>「IT技術者の人件費は、システムが動かなくなるまで削減され続ける」
すでに「壊れたダンプカー理論」というのが存在してます。
http://www.mars.dti.ne.jp/~hirok/xp/col/028.html [dti.ne.jp]
Re: (スコア:0)
こういうコメントを見るたび、結構複雑な気分になる。常識なのは確かなのだが。
個人的にはパスワードよりもその他の個人情報の方が流出の害があるので、パスワードが平文保存されていてもあまり問題はない。
(パスワードの使い回しは、ユーザーの方が悪いと思っている)
どちらかというと、住所氏名レベルのものは暗号化して、漏洩の堤防を作ってもらった方が有り難いと言えば有り難い。
パスワードを平文保存していると、管理者レベルの人に(意識しなくてもうっかり)パスワードを見られてしまうリスクもあるが、
メアドの類も同様に他人には見られたくない情報なので、取り立ててパスワードばかりを厳重に取り扱ってもらう事が良いとも言えない。
まあ、パスワードを平文保存しておくメリットは特にないから、ハッシュ化ぐらいやっておけという事なのだろうが・・。
Re:パスワードを平文保存 (スコア:2)
どちらかというと、住所氏名レベルのものは暗号化して、漏洩の堤防を作ってもらった方が有り難いと言えば有り難い。
エンドユーザの立場としては確かにそうかもしれないけど、元々、特殊な事情がない限り、平文のパスワード（可逆な暗号化処理を処理をしている場合を含む）をシステム側で保持する理由がないのに、それを平文で取得できた時点で、住所、氏名に関するまっとうな保護手段が容易できるわけがない、と思っちゃうなぁ。
可逆な形でユーザのパスワードを保持するって、サーバサイドにとっては、かなりリスクの高い行為なんだけど。
Re:パスワードを平文保存 (スコア:1)
個人情報もユーザーパスワードで暗号化すればいいのに、ということでは。
それならパスワードをハッシュ化しておけば、パスワードが判明しない限り個人情報が漏洩することもない。
とはいえ、運用側としては、請求書送るとか運用上の目的があって個人情報を持っていると思うので、復号できないと困ってしまうのは確か。そうするとバックドアを用意するか、パスワードを復号可能な状態で保存するか、になってしまう……
そこで考えた。
個人情報を暗号化したキーを所有するのは管理者のみとする。
ユーザーは個人情報を「登録」できるが、閲覧できるのは管理者だけとする。
登録済みの個人情報を修正するには、単純に再登録する。（修正不可。上書きのみ。項目単位での部分的な再登録は許可）
かつて、パスワードの確認機能を廃して再設定機能のみとしたように、個人情報も確認機能を取っ払って再設定のみ可能としてしまう。
これならどうだろう。
Re:パスワードを平文保存 (スコア:1)
個人情報を暗号化したキーを所有するのは管理者のみとする。
ユーザーは個人情報を「登録」できるが、閲覧できるのは管理者だけとする。
「のみとする」なんて言葉だけで対策になってないです。
何らかの問題で両者が漏れて、漏洩するだけでしょう。
大抵の情報漏洩は、「閲覧できるのは権限のあるユーザーのみとする」システムで起きていますよ。
Re:パスワードを平文保存 (スコア:1)
とはいえ、運用側としては、請求書送るとか運用上の目的があって個人情報を持っていると思うので、復号できないと困ってしまうのは確か。そうするとバックドアを用意するか、パスワードを復号可能な状態で保存するか、になってしまう……
普通は、
とするかな。確か、Windows で暗号化フォルダを使った時の挙動なんかが、こんな感じだったはず。
Re: (スコア:0)
郵便局が住所と氏名をハッシュ化するサービスを提供すれば、IT屋が住所と氏名を管理する必要は全くないですよね。
Re: (スコア:0)
いや、運用のためならそういう情報を外部公開しているサーバや同じサーバセグメントに置いておく必要は無いわけで。
ユーザーが変更する度にトリガーでもかませ、外部から一方通行で参照できない管理セグメントのどっかへ変更を飛ばして
そちらで管理するとか、やり様はいろいろとある。
問題は本人がパスワード忘れて復号化も出来なくなってしまった時だけど、そのときは別途サービス側で用意した
仮パスワードで暗号化したデータで上書きしてしまうとかさ。
Re: (スコア:0)
＞問題は本人がパスワード忘れて復号化も出来なくなってしまった時
このときに、そのIDの持ち主は連絡してきた本人とどうやって確認するか？
が問題では？
普通、個人情報をある程度比較して一致してたら本人とみ見なすと思うのですが。
Re: (スコア:0)
チャレンジレスポンス認証に使いたい場合、とか。
http://www.ipa.go.jp/security/awareness/administrator/remote/capter6/5.html [ipa.go.jp]
昔ハッシュしかないのに「APOP対応お願い☆」と言われた困った覚えがある。
Re: (スコア:0)
あー、安直すぎですね。実際はこうなのですよ。
http://www.ipa.go.jp/security/awareness/vendor/programmingv1/b09_01.html [ipa.go.jp]
Re:パスワードを平文保存 (スコア:1)
この実装だと、サーバー側で持っているハッシュ化された文字列を入手されると、それを使ってサービスにログインできてしまうので、生パスワードを入手されたのと実質同じことになります。ハッシュ化したメリットは、他のサービスでパスワードを使いまわしていても被害が及ばないという程度ではないでしょうか。
ちなみに、元コメントで触れられているAPOPは、生パスワードとチャレンジ文字列を合わせてレスポンスを生成するプロトコルなので、サーバー側で生パスワードを持つ必要があります。
UNIX でパスワードをハッシュ化することで安全性が増加していたのは、経路を盗み見るのが困難だったからです。無料サービスで https を使うことが予算的に厳しい場合、ネットワーク上に生パスワードを流すわけにはいかず、チャレンジレスポンス方式を使うことになりますが、その場合、結局サーバー側で保持しているのは「見られたらログインされてしまう文字列」であって、それにハッシュがかかっていたとしても安心できるものではありません。
Re: (スコア:0)
それって興味本位のカジュアルクラックは防げるけど、本気のクラックには無意味ですよね。
でも緩和策としてはアリか。その辺、運用形態とも関わってくるから有効性の評価は難しいな。
Re: (スコア:0)
ハッシュ化するにも、ちゃんとsaltを使ってるところは、どれだけあるやら
最近 (スコア:0)
こういう流出が増えたように感じるが、ハッカーが日本の企業を狙うようになったのかな？
IDとパスの組み合わせを他のサイトに流用してアタック掛けて成果が出ることがわかって
海外組のターゲットが日本に移ったとか
Re: (スコア:0)
って経営者いっぱいいそうだし。
Re: (スコア:0)
ホント最近マジで多い。
そのせいか！ (スコア:0)
同社運営のatwordがメンテナンス中のまま止まっているのはそのせいか(´･ω･`)
そのくせ最新情報が2013/01/31 [atwiki.jp]で止まったまんま。
@CHS [atwiki.jp]も漏れてますな。
この流出祭りの今なら言える。「ぬるぽ」 (スコア:0)
つまり、こういう事だろ。でもネットは記録が残るから記憶には残らなくても
それなりのしっぺ返しはあるだろうから安心しちゃいかんよ。
ガッ (スコア:0)
漏れているのが２月２７日以前のデータっていうのは気になるね。
すでに半年経っていて，実際に漏れたデータが確認されたから漏洩が明らかになったんだろうけど，
@PAGES がどの時点で把握していて，８月２８日の緊急メンテ・公表にいたったのかは興味深い。
未だにデータベースのパスワードは放置状態です (スコア:0)
流出問題を受けて、ユーザーのログインパスワードは強制リセットされたんですが、MySQLパスワードはそのままです。
一方的に変更すると、パスワードベタ書き状態のスクリプトが動かなくなるから避けたんでしょうけど、
ユーザーがMySQLパスワードを変更する画面も用意されていません。
MySQLパスワードからの変更なんて最初から想定していないのです。
ユーザーに公開されている phpMyAdmin にログインすると、ユーザーデータベースのテーブル操作(SELCT/UPDATE...)が可能になります。
一応クエリ実行で set pasword = 〜 も出来るのです(まあ何でも出来るわけです)が、平文で流れます。
そもそもここの各種管理ページには https の概念がありません。
基本無料のサービスなんだものと割り切って使うしかないのかもしれません。
こういう事件の犯人って (スコア:0)
捕まったというニュースをほとんど聞いたことがないのですが、実際に捕まってないのでしょうか。
Re: (スコア:0)
そもそも、被害届とか出てるんでしょうかね？？