https://twitter.com/piyokango/status/844361226767380481
http://www.freezepage.com/1490165400GAZZVSXBDT
である。キャッシュの freezepage ですまんが、まあいいだろ。
これ自体はハセカラ界隈のスクリプトキディが show tables かなんかを実行する jsp 一枚仕込んだというだけの話なのだと思うが、問題は JINS の対応だ。
t_jins_gmo_brandtoken_cancel_if_rireki
t_jins_gmo_brandtoken_change_if_rireki
t_jins_gmo_brandtoken_entry_if_rireki
t_jins_gmo_brandtoken_exec_if_rireki
などといったテーブル名から、おそらく GMO ペイメントトークン決済を利用しているものと思われる。これはクレジットカード番号を一切 JINS 側のサーバーに通過させなくていいような構成になっており、今回のこの事例から JINS 側が保存していたクレジットカード情報が流出した可能性は、恐らくない。
しかしながら今回攻撃されたドメイン https://www.jins.com/ にはクレジットカードの入力ページが存在している( http://s.ssig33.com/gyazo/d09c0f5915f84eab8c8712eb0d23150d )。
この為、こうしたページも不正に改造されていた場合、攻撃を受けていた期間に入力されていたクレジットカード番号が不正に流出している可能性がある。
ところで JINS 側はこうした問題を認識して今朝未明にメンテナンスを行なっていたようである( https://www.jins.com/jp/news/2017/03/322.html )。
推測するに、調査をしたところクレジットカード番号入力ページの jsp なりなんなりが改竄されていた事実はとりあえず確認できなかったので、特になんの発表もしていないのであろう。ところで JINS は 4 年前にもサイトをクラックされクレジットカード番号を流出させた経験がある( https://www.jins.com/jp/illegal-access/info.pdf )。にも関わらずこの対応はちょっとおざなりすぎではないだろうか。
現実に可能性は低いと思うが、例えば以下のような可能性が考えられる。
1. ハセカラ関係者っぽく見せかけた低レベルのクラック ↑ を行なう。
2. その裏でクレジットカード番号入力ページに本気のクラックを仕掛ける
3. 1. でしかけたハセカラクラックが露見する前に 2. のクラックについては撤収して 1. の証拠だけを残しつつ 2. の証拠を消す
このようにすることで、クレジットカード情報を収集していたという事実を関係各位に認識させる時間を可能な限り遅らせ、不正な買い物などをする時間の余裕を稼ぐことができる、かもしれない。もちろんこんなことが行なわれた可能性はほとんどなくて、事実はバカなスクリプトキディが適当に遊んでいただけなのだと思う。しかしこの可能性を無視していいとは思えない。
こうした可能性について調査するには 7 時間では全く足りないし、あるいは一度外部に大々的に告知をしてサービスを停止するなどの対処も必要ではないか。
JINS は 4 年前のクラック被害から何も学んでおらずユーザーデータや資産を防護する基本的な姿勢が欠けているとしか思えない。