アットフリークスさんの事後対応が酷すぎた件について
@PAGESご利用ガイド - 13/08/28 【お詫び】ユーザ情報流出に関するお知らせ
@PAGESご利用ガイド - 13/08/29 【お詫び】ユーザ情報流出に関するお知らせ【第2報】
| 2013年2月27日午後2時54分現在の175297 ユーザ の
ユーザ名 |
その時の対策
| ユーザ管理情報DBへアクセスするためのパスワードの変更 パスワードを単一方向の暗号化にて保存するようシステム改修 全ユーザのパスワードリセット(昨日お知らせ済) |
AtFreaksの判断
| ユーザ管理情報DBにアクセスするためのユーザ名とパスワードが流出し、@pages内サーバからユーザデータ情報を抜き出したと判断→経路については分からずじまい |
今回の流出は？
昨日の夜こんなメールが来ました
| 3.現在の対応状況について
直接原因となったプログラムは削除いたしました。
また、 それに伴う、直接的なセキュリティホールも修正いたしました。 引き続き、間接的な部分の調査をおこなってまいります。 ユーザ用の管理情報およびデータの流出を全サーバーで確認いたしました。 |
メールアドレスが重複してるし、一部のサーバーしか漏洩してないとか言ってたのにこれだよ！
わけがわからないよ ・ω・。
要するにこの会社は最悪時の想定ができていないという事だ
どうやら、前回の管理DBのアクセス情報が漏れたのが、システムの脆弱性のせいだったらしく、それをアットフリークスでは放置していた。
結局、流出内容が正確に把握できたのは3月12日？！
全サーバーで流出したといわず、一部だけだといったせいで、公式情報だけ信じてスルーしてたらえらい目にあってたところだよ！
どんな脆弱性？
|
extract — 配列からシンボルテーブルに変数をインポートする extract() をユーザー入力 ($_GET や $_FILES など) のような信頼できないデータについて使用しないでください。 もし行う場合、例えば register_globals を信頼しているような古いコードを一時的に実行したい場合、 EXTR_SKIP のような flags の値が上書きされていないことを確認してください。そして php.ini の variables_order で定義されたものと同じ順で展開すべきであることに留意してください。 |
PHP の extract 関数は危険という話 - まちゅダイアリー(2008-09-06)
要するに、GETにメソッド埋め込むことで、Formのパラメータ書き換えたり 任意のSQL文実行できたりしてやばいらしい
大丈夫かこの会社？･ω･（３回目）
# 艦これも wiki 使ってるからやばいって情報みたけど、あそこって wikiwiki.jp (Pukiwiki Plus) だから全然関係ないような…
Translate
会社としてもさることながら、技術者と営業の齟齬もあるんじゃないかと。
未だにGoogleで site:atwiki.jp s_urldec とすると検索結果に・・・
艦これWikiは、wikiwiki.jpの所とwww56.atwiki.jpの所の2種類あるんですよ
アットフリークスからの情報流出なら
@pagesと同時に@chsからもありましたので
それが発覚した昨年8月の時点で他のサービスのデータも漏れているのではないかとat wikiユーザーの一部で言われていました。
@chsご利用ガイド – 13/08/28
【お詫び】ユーザ情報流出に関するお知らせ
http://www35■atwiki■jp/atchs/pages/587■html
【お詫び】ユーザ情報流出に関するお知らせ【第2報・終】
– 13/09/05
http://www35■atwiki■jp/atchs/pages/588■html
5月に閉鎖されるみたいですが@WORDはそれ以前からWordPressのバージョンアップをしていないせいでたびたびやられていたはずです。
at wikiは数年前にメールでの問い合わせに応答する人はたぶん交代していると思います。
あちらが増やした広告タグのせいで表示が崩れても、具体的にどこにある何がダメなのか指摘しないと直してくれない、などが多々ありましたので
全体を把握できている人がいないのではないでしょうか