筆者が閲覧したのは、セキュリティ会社Sucuri Labs社の親切な有志が作成してくれた特別なWebページです。
Yahoo!以外のEメールアドレスも情報流出していた
注目していただきたいのは、この「scobb@ixxxxb.com」が、Yahoo!アドレスではなく、筆者自身が作成し管理してきたアドレスで、長年筆者が所有してきたドメインに由来するということです（画像ではドメインを伏せてあります）。漏洩したのは「Yahoo!のパスワード」と思われていたのに、実際には非Yahoo!のEメールアドレスとそのパスワードにも被害が及んでいたのが、この事件の特異な側面でした。
この側面がすぐに認知されなかったのは、当初事件を伝えた見出しが「Hackers expose 453,000 credentials allegedly taken from Yahoo service（Yahoo!サービスにハッキング被害、認証情報45万3千件が流出か）」というものだったためです。これは、Ars TechnicaのDan Goodin氏の記事ですが（現在はアップデート済み）、この見出しを批判する意図はありません。
ただ、この見出しによって、メディアの注目が最も有名なYahoo!のみに集まったのは自然な成りゆきで、事件の詳細が徐々に明らかになっても、Yahoo!の名前のみが前面に出続けることになりました。
どうしてEメールアドレスの情報が流出したのか？
では、筆者のアドレスが流出していることが分かった経緯をお話ししたいと思います。
アドレスが漏れていたことは、流出アカウントのリストにクエリを実行する、前述のSucuri LabsWebページを使って確認できました（リスト自体は、SQLインジェクション攻撃でYahoo! のサーバーからアドレスを盗み出していた一味がインターネット上に公開していました）。
問題は、どうしてわざわざWebページを閲覧する気になったかということです。2006年頃、筆者はAssociated ContentというWebサイトへ投稿しようとしていて、そこにアカウントを作成していました。
2012年7月12日の時点で、www.associatedcontent.com を閲覧してみると、このサイトは Yahoo!Voicesになっていることが分かります。Associated Contentと今回の事件の関わりは、自分に配信されるニュースフィードで偶然に発見したのです。
軽い気持ちで、筆者のメールアーカイブを検索してみたところ、看過できない情報にゆきあたりました。Associated Content への登録完了通知です。このメッセージからは、Associated Contentのセキュリティに対するアプローチが適切でないことが見てとれます（元のメールではパスワードが平文で表示されています）。
より大規模で、（願わくば）より仕事熱心な企業によって買収された後も、こうしたやり方が継続することがありうるという事実は、控え目に言っても不安を掻き立てます。
そこで、念のためにパスワード変更を徹底的に行うことにしたわけです。
数百万件のパスワードが流出中
45日間で、我々が把握しているだけでも数百万件のパスワードが流出し、その中にはLinkedIn、Nvidia、Phandroidといったサイト由来のものも含まれています。
この機会に、ご家族全員にもデジタル認証情報の変更を促すことをお勧めします。
パスワードの変更をした後に時間に余裕があれば、パスワードを流出させた企業のCEOにEメールを出してみても良いかもしれません。これらの企業を信用したユーザーとして、より安全な個人情報保護の対策を求めてください。
これほどの大企業としては残念なことですが、これらのWebサイトのプログラムの質は、率直に言って基本的なセキュリティ対策の水準にも達していませんでした。
Yahoo!のサーバーからパスワードファイルを盗み出した技術は、SQLインジェクションという、よく知られた方法です (Search Securityの記事でこの話題が取り上げられたのが2008年ですから、対策を講じるにも充分な時間があったはずです)。
読者のみなさんの会社でも、パスワードの取り扱いという点から、Webサイト構築の方法を見直すよい機会かもしれません。特にサポートフォーラムを設けている場合には要注意です。
最近、各紙で取り上げられた2件の個人情報流出の標的となったのは、いずれもフォーラムです。2件の事件と同様の手口が流行しているわけではありませんが、この2件のニュースが知られれば、模倣犯が生まれる可能性があります。
まず初めに、Webからアクセスできるサーバーにパスワードを平文で保存していないことを確認することが肝心です。大企業にお勤めの方には、過去の買収時に獲得したサーバー上でそのままになっている古いファイルのサブドメインを全て見直すこともお勧めします。
出典：blog.eset.com
