危険？！UNIQLO のTwitter 連動イベント
ユニクロ、26周年「誕生感謝祭」でTwitter連動型サイト公開:ニュース - CNET Japan
と言うわけで、ユニクロでツイッター連動イベントやってるのですが、どうもやばそうなので調べてみました。
初心者向けに後半に 簡単な説明と分かりやすい例をあげておきます。
* 5/26 21:30 UNIQLO様から SSL対応を担当部署に依頼したのでお待ちくださいと回答いただきました。
* 5/28 結局対応に言及されなかったみたいなので、追加記事を書きました。
まずためしにUser test ID 12345で送信してみます。
本来出るはずの、こういう認証画面が出ない！
これがネットに流れるキャプチャデータです。クリックすると拡大できます。
どういうことかと言うと、http://uniqlo-happy-line.s2factory.co.jp/system/stand_in_line.php へ username=test&status=UNIQLO%20LUCKY%20LINE%E3%81%AB%E8%A1%8C%E5%88%97%E3%81%AA%E3%81%86%E3%80%82&password=12345&char%5Ftype=arm%3D20%26body%3D20%26border%3D4%26face%3D1%26foot%3D11%26hair%3D59%26kutsu%3D1%26type%3D2R
と言う情報をHTTP(暗号化なし)で送ってるわけです。
stand_in_line.php が LOGでフォーム情報を記録していれば、UNIQLOはTwitterのIDとPASSWORDを収集することも出来るわけです。
仮に保存されていると仮定して、悪意が無かったとしても、
IDとパスワードが閲覧できちゃうわけですから、ハッキングされた場合、大量にIDとパスワードが漏洩する危険があります。
追記：S2FactoryさんはサーバーをUNIQLOさんに用意してるだけと言う事が分かりました。Hiroshi D. James様/コメントの方 ありがとうございます。(参考： Hiroyuki Hanai様のTwitter / quanta様のTwitter)
Googleにあるデータを確認してみたところ、
http://uniqlo-happy-line.s2factory.co.jp/system/data/heads400_tails400.txt
http://uniqlo-happy-line.s2factory.co.jp/system/data/all_line.txt
http://uniqlo-happy-line.s2factory.co.jp/system/data/all_line_tweets.txt
と言うデータが見える模様(後ろ２つはなぜかすぐ削除、最初のも後日削除されました*1)
と言うわけで、キャッシュデータから確認してみました。
all_line.txt の方はheads400_tails400.txt に出てる表示用のデータとほぼ同じフォーマットで 1～５カラムと７，１０カラム目のデータが全ユーザに対して保存されているみたいです。
all_line_tweets.txt の方もheads400_tails400.txt に出てる表示用のデータとほぼ同じフォーマットで 1、２，６カラムと８～１０カラム目のデータが全ユーザに対して保存されているみたいです。
簡単な説明
・5/26 15:00の時点で個人情報が流出したわけではない。
・非常にまずいPHPの実装をしたので、S2Factory内に悪意のある人がいれば、簡単にIDとパスワードを取得できる。
・もしフォームの内容を記録していれば、S2Factoryへ外部からのハッキングでIDとパスワードが取得される可能性がある。
・従来(TwitPicやゲームのように)のTwitter のIDとPasswordを使うサイトと違って、*3BASIC認証/OAuthすら経由せず、S2Factoryのサイトへ*4生のIDとパスワードを送ってから処理してるのが問題。
今回の問題点の分かりやすい例
*実例
あなたが良く利用しているお店でクレジットカードを使います。
ヨドバシカメラのELIOやJRのクレジットカード対応発券機を想像すれば分かりやすいと思います。
通常は、カードをお店の人に渡して、暗証番号を自分で入力して決済します。
しかし、今回は、お店の人にカードを渡したところ、暗証番号を入れる機械が無いので、暗証番号を教えてくださいと言われたので、仕方なくお店の人に告げました。
お店の人はコンピュータに買物の内容を打ち込んでいますが、そのコンピュータには液晶モニタが付いていて、現在入力している内容が表示されていて、お店の人が、不正な入力をしていないか全ての入力内容がお客さんにも分かるようになっていて安心なんだそうです。
後で分かったことですが、その店員さんは、正社員ではなく、臨時で雇われた、アルバイトだったそうです。
赤字で書いた３つの問題点を今回の事例に置き換えてみると・・・・。
・暗証番号をお知えて下さい→通常はTwitterのAPIを使います。
・全ての入力内容がお客さんにも分かる→つまり、ほかのお客さんにも丸見えですね。今回の送信データは httpsで暗号化されて無かったのです。
・正社員ではなく、臨時のアルバイト→ 今回パスワードを預かったのは、Twitterでも、UNIQLOでもなく S2 Factoryと言うところでした。
5/26 23:55 追記：S2 Factoryさんは、単にサーバーを貸してただけと言うことなので、そのコンピュータが人から借りた物だったと言ったところでしょうか？
ただ、今回は、クレジットカードの暗証番号の様にお金が絡むような、重大な話ではありませんが、例え話のような状況が起こりました。
IDとパスワードを暗号化して送信しなかったせいで事故が起こった事例としては、先日も記事に書いた、ウェブインベンターとメッセサンオーの顧客情報漏洩が記憶に新しいと思います。
実行してしまった場合＆どうしても参加したい場合は？
類推で居ないパスワードに変更すればOKです。
IDとパスワードが誰かの手に渡って、悪戯されたり、パスワードを変更される前ならば・・・ですが。
不安だけど、UNIQLOに並んでみたいと言う方は、捨てアカウントを作ってアクセスすると良いかもしれません。
*1 Passwordは、現在Googleキャッシュにもれてるファイル中には含まれていませんでした
*2 2007年創立で、1998年創立のIMG SRC Group の子会社らしい。結構、メジャーな企業のサイトを手がけている。
*3 BASIC認証/OAuth と 生パスワードの違い について、OAuthで承認す
ると、相手はTwitterユーザーがログインして出来ることが全て出来るようになります。パスワードを変えても、権限は変わりませんが、後で取り消すことができます。 生のパスワードがもれた場合、そのパスワードで他のサービスのパスワードも類推することが出来るかもしれませんが相手が勝手にログインしてパスワードを変更する前に変えてしまえば大丈夫だと言うのが違いますね。
*4 通常、パスワードやIDを送信するサイトはURLの頭に、httpsが付き、データが暗号化されて送信されています。だから、目的のホスト以外では復号することはできないので、心配ありません。しかし、http の場合 生でIDとパスワードを送信しているので、例えば、会社から送信した場合、以下の可能性があります。
・社内のネットワーク管理者にパスワードとIDが丸見えになる。
・社内のネットワークログにTwitter ID/Password が保存される。
・途中経路のプロクシやプロバイダなどにID/Passwordがもれる。
・S2 Factoryのターゲットのサーバ以外の管理サーバーのログにIDとPasswordが保存される。
関連記事：
メッセサンオーの個人情報流出とWEBインベンダーのカートの脆弱性
【続報】メッセサンオー顧客情報流出のWEBインベンダーの対応について
UNIQLOのプレスリリースでの公式発表について
関連サイト：
ユニクロトップ - UNIQLO ユニクロ
ユニクロ、26周年「誕生感謝祭」でTwitter連動型サイト公開:ニュース - CNET Japanhttp://cms.blog.livedoor.com/cms/article/add?blog_id=2914225
S2 Factory | About
Translate
>S2Factory内に悪意のある人がいれば、簡単にIDとパスワードを取得できる。
そんなこと言ったら銀行のシステム子会社とかも同じじゃね？
> そんなこと言ったら銀行のシステム子会社とかも同じじゃね？
セキュリティを扱う会社の場合、限られた人しか、アクセス出来ず、情報を閲覧する場合、誰がどのデータを見たかなどが厳密に管理されています。
しかし、この場合、中継するコンピュータ上全てに生のデータが流れてしまう上に、誰が閲覧したかも特定することは出来ません。
だから、社外秘の上のランクの極秘資料を扱うのと社内報を扱うのとの違いくらいの差があります。
>中継するコンピュータ上全てに生のデータが流れてしまう
いやいやｗ
TCP/IP 通信とは何かから勉強し直してくださいよｗ
> TCP/IP 通信とは何かから勉強し直してくださいよｗ
あー、一応ネットワークのプログラムも仕事にしてる人なのでそこら辺は多分大丈夫です(^^;
わたしの書き方が悪かったのかもしれませんが、中級者にも分かりやすい例を挙げると、
・社外、集合住宅から出るためのProxy、コンテンツ規制サーバーなどが通信内容を処理する。
・DeleGateサーバーがHTTPのリクエストの通信内容を丸々保存する。
・TCP/IPの通信では目的のPCでは無くても、ルータなどの枝に当たるPCの通信を解析すると、近縁のPCへ向けたデータが物理層には到達していることがある。
等も通信経路で漏洩する例です。
そらゲートウェイで盗聴することだって、経路上で「たまたま」平文の該当部分がチラ見えすることだってあるでしょうよ。
悪意を持った人間がそれを狙ってやることが現実的なのか？
一体どれだけの人間にそれが可能なのか。
そもそも、その場合の守秘義務ってのはユニクロじゃなくネットワーク管理者やらにかかってくるんだと思うんですがね。
> そらゲートウェイで盗聴することだって、経路上で「たまたま」平文の該当部分がチラ見えすることだってあるでしょうよ。
> 悪意を持った人間がそれを狙ってやることが現実的なのか？
確かに、特定の人をターゲットにすると言う目的ではおっしゃる通りです。
では、少し見方を変えてみましよう
今回は1万人を超えるひとが、何度も、家や学校、職場と場所を変えて応募します。
つまり、その中には野良プロクシを利用している方もいて、
その中には、悪意のあるサーバがある可能性もある訳で、
SSLじゃなかったせいで、twitterのid PASSが盗まれた人が居る可能性が
否定出来ないのです
ユニクロの守秘義務などの問題をクリアしたとしても、
今時、暗号化もせず平文でパスワードを送るのは、webインベンダー位でしょう
#ちなみにハックは狭義の侵入するという意味以外に、
以外にコンピュータやネットワークの動作を解析するという意味
があるので参考までに。
野良プロクシを使ってる人とかまで仮定に入れちゃうんですか…
内部犯行があれば、外部からのハッキングがあれば、という仮定で危機感を煽ってみたり。
このサイトの設計がお粗末であることは事実かもしれませんが、ちょっとこの記事もどうなのかという気がします。
あと、BASIC認証なら大丈夫だったんでしょうか。駄目ですよね？
非常にまずいphpの実装、というのも謎です。まずいのは根本的な設計じゃないですかね。
> このサイトの設計がお粗末であることは事実かもしれませんが、ちょっとこの記事もどうなのかという気がします。
確かに、不安を煽るだけで、対策とか根本的なこと書くの忘れてました(^^;
ありがとうございます。
仰る通り、サイトの根本的な設計に問題があると思います。
SSLじゃなかったせいでパスワードが盗まれたんですかね？
その場合、俺としては野良サーバ踏んじゃったせいだと思うんですけどね
個人情報保護を謳うなら当然SSLを使うべきというのは同意見です
使うなとか使っても意味ないなんて思ってないですよ
>・非常にまずいPHPの実装をしたので、S2Factory内に悪意のある人がいれば、簡単にIDとパスワードを取得できる。
-> 外部にデータ委託していると免責事項で言っている以上、当然ですね。SSL使ってようが内部犯がいれば同じです。
>・もしフォームの内容を記録していれば、S2Factoryへ外部からのハッキングでIDとパスワードが取得される可能性がある。
-> これはSSL実装とは無関係ですね。そもそもユニクロは記録してないって言ってますね。
> stand_in_line.php が LOGでフォーム情報を記録していれば、UNIQLOはTwitterのIDとPASSWORDを収集することも出来るわけです。
-> 免責事項で、得た情報をどのように使うか明記していますね。
> 仮に保存されていると仮定して、悪意が無かったとしても、
IDとパスワードが閲覧できちゃうわけですから、ハッキングされた場合、大量にIDとパスワードが漏洩する危険があります。
-> だからパスワードは保持していないと言ってますね。そもそもSSL使ってようが、内部にデータ保持してればハッキングで漏洩は当たり前に起きますね。
なんだか、叩かれるべき点は暗号化されてないって点だけだと思うんですが、それ以上のことまでユニクロのせいにしてません？
ユニクロは、外部業者にデータ委託することもある、パスワードは保持してないと当初から明記していますよ？
それと、暗号化されてない点については、ユニクロやIPAに直接報告すればいいんじゃないでしょうか。
公開して喧伝する必要ってなんです？
パスワードが悪意のある第三者に盗聴される危険があったって事ならそう書けば宜しいのでは。
言ってしまえば、「初めから何も漏洩していない」わけですよ。
予め悪意を持って経路上に機器を置いて初めて「盗聴が可能だった」今回と、さながらXSSでDBの中身すっぱ抜かれるような「漏洩」とを同義に叩くのはさすがに乱暴じゃないですか？
長文ですみませんね。
どうもむやみに祭りを加速させたがっておられたように見受けたもので。
純粋に「未だ見ぬ被害者たち」に注意喚起されたかったのであれば謝ります。
#ハックの意味はどうでもいいんですけどね、ハッククラック談義なんて今更ですし
（つか該当のツイート消えてますね。。。ｗ）
SSL通信じゃない以上、手元でキャプればそりゃ何でも見れます
そんなのは当たり前なんです、裏をとるまでも無いことです
コメント書いてる間に元記事変わってたｗ
ユニクロさんが端的に書いておられることを長文で書いてしまい申し訳ないです
メッセサンオーの件とは全然問題の内容が違うと思いますがね～～・・・
まぁ何事にもリスクは有ると言うことを人々がもっと気づくといいですね
記事よみました。
問題なのはあなたのようにこういった問題の不安をあおって
ツイッターやサイトで一方的に発信する人でしょうね。
これはユニクロにこの内容を伝えて直してもらうっていうのをやればいい話ですよね。落ち着いてからまとめたりする良識のある大人対応が必要なのでは？
火事場で騒いで写真とってる人とかわりませんよ。
あと例えは極端すぎなのと分かりにくいですね。
お金が絡んでくる内容を例えに出すと問題の本筋が伝わりませんよ。
>問題なのはあなたのようにこういった問題の不安をあおって
UNIQLOのイベントでパスワードなどの個人情報が晒されていると
書いたわけではなく、実際の処理などを考察した上で、何が起こっている
かを分かりやすく書いたつもりです。
今回のケースは、ユニクロさんや、S2 Factoryさんに進言して、
対応を求めるのは当然ですが(勿論、私からはメール済みです)、
自分で調査した上で、正しい事実を記事にしました。
のらさんのように私の記事が過剰に書きすぎていると思われる方の
気持ちも分からなくは無いのですが、今回のケースでは、記事に
書いたような理由で、個別の対策をする必要があり、安全だと言い
切ってしまう方がまずいと思いました。
(確かに、パスワードがネット上に公開されていると言う噂はデマ
でしたが、他のルートでパスワードが漏洩した人が居る可能性が
あるわけで、IDとPASSWORDを変更する方がよいと思います)
量は少ないでしょうが・・・
ラインを共有しているネカフェ、無線LANスポット辺りで
盗聴していたら漏れるんではないでしょうか。
見えない損害を知ろうとするのは煽りでは無いと思いますね。
まとめてレスです。
きりが無いので割愛していますが、どうしても回答がほしい方は、
Twitterへお願いします|･ω･)ノ
>#ハックの意味はどうでもいいんですけどね、
>つか該当のツイート消えてますね。。。ｗ
いあ、消してないです。単に、TLに埋もれただけでしょうｗ
Tween使ってるなら、何度かSHIFT +F5を押してみてください。
http://twitter.com/BlackWingCat/status/14745651250 ←該当
> なんだか、叩かれるべき点は暗号化されてないって点だけだと思うんですが、それ以上のことまでユニクロのせいにしてません？
> ユニクロは、外部業者にデータ委託することもある、パスワードは保持してないと当初から明記していますよ？
TwitterのユーザーPasswordを直接扱わなくてもいい方法があるのに、わざわざユーザのIDとPasswordを自サイト(実際は委託サイトですが)に入力させたのも問題です。そのせいでSSLの問題も引き起こしてるわけですから、ちょっと無責任でしたよね。
PHPの処理ではパスワードを含むデータを保存して無いかもしれませんが、SSLを通していない以上、記事内で書いたようにユーザーの意図しないところで生のデータが保存されている可能性が高いです。
http://twitter.com/hanai/status/14751577423
とのことです。
> @norahmodel S2 FactoryはLUCKY LINEの実装には関わっておりません。
あらま風評被害もいいとこだ
しかしお粗末な実装ですな。SSL以前に平文で送信してるのは論外です。
必死に書き込んでたのはS2 Factoryの関係者ですか？
記事にも書きましたが、S2F様はホスティングだけで、実装には関わって無いですよ
あ