2017年06月27日

メルカリの情報流出は、キャッシュから

メルカリのWeb版の方で、個人情報が漏れた可能性があるというニュースがあった時は、攻撃でも受けてDBから情報でも盗まれたのかと思ったけど
実際は違ったようです。
個人情報が漏れた可能性があると。偶然他人の個人情報が見えてしまった可能性があるということのようです。
ユーザー側で不正な操作は全くしてないのに、たまたま他人の個人情報が見えてしまったら、怖いですね。もしかしたら自分の情報も誰かに見られた可能性も・・ないとは言えないし(実際に漏れた情報は少ないと思うけど)

仕組みは簡単、リバースプロキシのような構成になっていて、間のキャッシュサーバーが情報を保存しておいて、その情報を表示してしまっていたと。

よくある?単純なミスとも言えるけど
昔はキャッシュコントロールでトラブルはあったが、今はCDNを使う仕組みを使うことで大量のアクセスを回避してるので、CDNの仕組みに詳しくないとトラブルにあうこともありそうです。
今回はCDNを乗り換え時のミス、CDNのキャッシュコントロールに違いに気づかなかったのが問題だったようですね。

参考)メルカリの個人情報流出、陥った「no-cache」の罠
http://itpro.nikkeibp.co.jp/atcl/column/14/346926/062601030/
posted by zjapan at 09:39| Comment(0) | TrackBack(0) | 事件です | このブログの読者になる | 更新情報をチェックする

2014年11月19日

YosemiteにしたらJavaが不安定に!JDKは別途インストールが必要でした

YosemiteにしたらJavaが不安定になったので、簡単なメモ

Javaのアップデートがシステム環境設定から出来たので大丈夫かと思ってたら、こちらはアプレット用(ブラウザ用)で、JDKの方は別途自分でダウンロードしてインストールする必要がありました。
最初にインストールしたのがずっと前だと忘れちゃうんだよね(^^;

せっかくなので最新のJDK 8をダウンロードしたインストールしました。
http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html

Javaも最近はセキュリティ問題が頻発しているし、アップデートはちゃんとしておいた方がよいですね。

$ java -version
java version "1.8.0_25"
Java(TM) SE Runtime Environment (build 1.8.0_25-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)


$ /usr/libexec/java_home -V
Matching Java Virtual Machines (2):
1.8.0_25, x86_64: "Java SE 8" /Library/Java/JavaVirtualMachines/jdk1.8.0_25.jdk/Contents/Home
1.7.0_45, x86_64: "Java SE 7" /Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home

ラベル:java JDK
posted by zjapan at 15:51| Comment(0) | TrackBack(0) | 事件です | このブログの読者になる | 更新情報をチェックする

2014年11月13日

サーバー攻撃代行サイト 800円からの!?

以前高校生がゲーム会社を攻撃したって話題があったけど
海外の攻撃代行サイトを使ったとかいわれていたやつ
なんとDDoS攻撃の代行がたったの800円で出来てしまったらしい(^^;

海外に攻撃代行サイトなるものがあることは知ってたけど、こんなに安いとは。しかも単純な攻撃ではなくDDoS(分散サービス妨害)とは・・・もちろん分散一概にいっても、どのくらいの規模かによるが。実は数台の分散攻撃だったとかwww

ちなみに、攻撃代行サイト自体は不正サービスとは限らないです。というか攻撃代行というよりは、攻撃テスト用サービスと言った方がいいでしょうね。
よくある手口の攻撃を自社サイトに対して自動的に実行して、脆弱性を発見するサービスですから

ただ大規模なDDoS攻撃までテストする必要性は感じないし、そこまでするサービスもないと思うんだけど
それでも悪用しようと思えば出来てしまうってことか・・・

もっともまともなサービスとして攻撃代行サイトをやっているところだったので、簡単に犯人が割り出せたってことなんだろうけど
ラベル:DDoS
posted by zjapan at 15:30| Comment(0) | TrackBack(0) | 事件です | このブログの読者になる | 更新情報をチェックする

2012年10月19日

なりすまし事件、警察も大変だぁ

話題のなりすまし事件ですが、警察を批判するのは簡単だけど、もうちょっと詳しい状況を知りたいですね。

今回のなりすまし事件は大きくわけると2つの手口があったようで
1、リモート操作のウイルス
2、リンクをクリック

●2番目のリンクをクリックしただけで逮捕された人はかわいそうですね。
もちろん安易に怪しいリンクをクリックすべきではないですが・・・特に2chのような掲示板は、あと怪しいメールのリンクもだけど
でもそれだけでいきなり逮捕されるって・・・さすがにひど過ぎ!

警察の捜査がIPアドレスの特定に偏り過ぎていたというのもあったようで

参考)なりすまし事件、想定外が油断に 警察、被害者に自白強要か
http://www.itmedia.co.jp/news/articles/1210/17/news064.html

クロスサイトスクリプトなどの脆弱性を狙われたと思うが、これってリンクを踏んだ人のみの責任ではなく、サイト側もある程度の責任もあると思う。そんな簡単に成り済ましでメールを送れるサイトを作るべきではないという意味でね。
ちゃんとアクセスログを調べていればある程度わかると思うんだけど・・・きっとそのリンクを踏んだ人が少なかったのでしょうね。もし沢山の人が踏んでいれば問題は別にあるって気づくことが出来る可能性が高いが、1人しかいなかったら、その人に問題があると認識されてもおかしくはないですからね。

でも、これってユーザー側で完全に防ぐのは難しいと思うので・・・やっぱり怪しいリンクはクリックしないに限りますね。

●1番のリモート操作ウイルスの方ですが・・
これは感染の方法が気になりますね。
2chのリンクからソフトをダウンロードしたとかあるけど、それってどうなんでしょう。あまりにも無防備過ぎるというか、ウイルス対策ソフトを過信しすぎかも
あとそれにすぐに気づかなかった理由も気になる。ソフトのインストール時に怪しい動きをして気づいたというニュースもあったけど、その前に逮捕された人はそれを申告していなかった?気づいていなかった?それとも・・怪しいソフトだった?

例えば、有料ソフトの不正ダウンロードとかよくある手口だったのかも?これは今だとダウンロード自体が犯罪ですが、当時はまだ犯罪ではなかったですが、人道的にちょっとだよね。

あとリモート操作ウイルスに感染されたパソコンを放置しておくこと自体も怖いですよね。
昔からこの危険性は言われていて、国際犯罪に使われたら大変なことになると・・・インターネットに常時接続することの恐怖として言われてましたね。今回みたいに掲示板に書き込むという犯罪?そんな幼稚な手口に使われるなんて想定外でしたからね。

感染済みのパソコンを野放しにしていたら、さらに2時被害が広がる可能性もあるので、リモート操作ウイルスに感染した場合はやっぱりそれなりの対応も必要なのかも?
警察はそこら辺の見極めが出来ないといけないとなると大変ですが・・今後はさらに多くの手口が出てくるので、もっとスキルを持った捜査官が必要でしょうね。

※特にモバイル(Android)をリモート操作するウイルスが増えているので、今後はもっと大変になるでしょう。
posted by zjapan at 16:01| Comment(0) | TrackBack(0) | 事件です | このブログの読者になる | 更新情報をチェックする

2012年10月09日

IPアドレスを証拠に逮捕!でもリモートアクセス可能なウイルスで掲示板に書き込みされた!?

最近掲示板に不当な書き込みをした人を警察が逮捕したというニュースがありましたが、それが誤認逮捕だったとか・・・
これはちょっと怖いです。全然関係ない人も逮捕される可能性があるということですから

○IPアドレスは証拠になるのか?
ある程度はなるでしょうけど、それだけでアクセスした人を特定するのは難しいでしょうね。
特に今後は簡単に逮捕されるようなことはないと思いますが・・・
家庭でルーター使っている人などは、設定に注意しないと、勝手に他人に使われて悪さされる可能性があるということは昔から言われていますからね。

○リモートアクセスウイルス?
でも今回はウイルスが原因らしい。それもリモートアクセスが可能な高度な?ウイルスで、PCを操作されて掲示板に書き込みしたらしい?
これが本当なら・・・リモートアクセス可能なウイルス自体は昔からあったけど、こんな無意味な愉快犯にも使われるようなツールになったということの方が怖いかも?

ちょっと検索すれば沢山出てくるけど、下は2003年の警告ですね。
ベンダー各社、外部からのリモート操作が可能なウイルスを警告
http://internet.watch.impress.co.jp/www/article/2003/0225/lovgate.htm

今までは、リモートアクセス可能なウイルスを作るのは高度な知識が必要でした。
ですので、そんなウイルスを作る人はそれなりの動機を持っていたと思われます。
まぁ単に技術力をアピールしたい暇人ってことも多かったと思いますが・・

個人情報を盗んで儲けようとか、政治的な理由などで攻撃したいけど身元は特定されたくないとか
そんな理由ではなく、匿名掲示板に書き込むことに使われるとは・・・

もちろんリモート操作のテストという可能性もありますが
特定企業のPCに入り込んで、いろいろ操作する為の前準備という可能性もあるので、今後注意が必要ですね。
posted by zjapan at 15:42| Comment(0) | TrackBack(0) | 事件です | このブログの読者になる | 更新情報をチェックする

2012年06月22日

ファーストサーバ障害、管理プログラムの不具合!?

これは人ごとでないかも?
管理プログラムのミスにより、ファーストサーバで大規模に障害が発生したようです。

ファーストサーバのレンタルサーバーに障害、ユーザーデータの消失も
障害の影響を受けたサービスは、共用レンタルサーバーサービスの「ビズ」「ビズ2」、専用サーバーサービスの「エントリービズ」「エンタープライズ3」、VPSサービスの「EC-CUBEクラウドサーバ マネージドクラウド」。影響を受けた顧客数は約5000。

なぜ広範囲のサーバーに障害が発生したのか?
同じ管理プログラム(バックアップのスクリプトか?)を使っていたからのようです。しかもバックアップデータまで破壊されたとか・・・

これって本当に不具合なのかなぁ
確かに管理用スクリプトって一つ間違えると大きな事故になることがあるけど、そうならないように慎重に作るし、もし不具合があってもなるべく影響範囲が少なくなるように考えて作るように個人的には心がけてきましたが・・・にわか管理者だと気にせずいわれた通りスクリプトを作って動かすだけ、って人も中にはいたけど・・・ここまで酷いとちょっと別の可能性も疑ってしまうね。
まぁこの推測は外れて欲しいけど(^^;
posted by zjapan at 14:12| Comment(0) | TrackBack(0) | 事件です | このブログの読者になる | 更新情報をチェックする

2012年02月21日

探検ドリランドのカード増殖問題について

昨日驚きのニュースが飛び込んできました。
グリーが提供している「探検ドリランド」というゲームのレアカードを、不正に入手して、転売して儲けている人がいたそうです。

レアカードの転売自体にも問題はありそうですが、それはおいていて、なぜレアカードの増殖なるゲームのバグが存在したのか考えてみましょう。

○2つの端末で同時アクセスを行うと
2chなどにレアカードの増殖方法がアップされて問題が発覚したそうですが(問題自体はずっと前から存在していたらしい?)その方法が、同一IDをもった2台の端末で”同時に”アクセスする方法のようです。

携帯ゲームだと、そもそも携帯の固定IDで認証していれば、同じIDは存在しないから、同時にアクセスするような状況は考えなくてよかったというのがあったのでしょう。
スマホなどだとこの方法では駄目だと思いますが、昔ながらの携帯ゲームを作っていたプログラマが大勢いただろうグリーでは、携帯文化が残っていた可能性もあります。

○インフラ側から今回の問題を考えると(中の人でないので、もちろん推測)
もしかしたら、マスター/スレーブ間のレプリケーションのずれを利用した可能性も考えられます。

例えば、カード管理用DB1とトレーディング管理用DB2があったとして
トレーディング時には
1、DB1からカードを抜き出して、DB2へカードをセットする。
2、DB2上でトレーディング条件があえばトレーディング成功
3、【受け取り】DB2からトレーディング後のカードを抜き出して、DB1へ追加する。
のような手順になると思われます。

ここからは思いっきり推測ですが、グリーほどの規模のソーシャルゲームになると、DB1もDB2も複数あって、しかもマスター/スレーブ構成になっている可能性が高いです。
例えば3番のカードを受け取る処理ですが、実際はもっと複雑になっていて
3番の受け取り処理はきっとこんな感じ
1、DB2のスレーブから、受け取るカードがあるか確認する。
2、受け取るカードがあれば、DB1へ受け取ったカードを追加する。
3、DB2のマスターで受け取ったカードを削除する。

この一連の処理は一瞬で終わるので普通は問題ないのですが、3番目のマスターを変更したものがスレーブに反映される前に、同じIDを持った端末で受け取り処理を実行されると、無いはずのカードが受け取れてしまうという問題が発生することがあります。

もちろんこれは推測ですが、グリーの開発者の昔の記事を読むと、トランザクションなどはなるべく使わなく、そして途中で失敗してもユーザが損しない方法で処理するようなことが書かれていました。

グリーの規模のソーシャルゲームについては経験ないですが、それよりももっと小さい規模のゲームでも、DB周りの処理は本当に気をつけないとすぐに過負荷で落ちてしまうことがあったので、きっと探検ドリランドも負荷対策には苦労していたと予想出来ます(きっと自分の予想以上でしょう)
トランザクションをなるべく使わないような方針にしていた可能性は高いと思われ、そこを今回利用されてしまったと思われます。

○改善案
ちゃんとロックして問題が起こらないようにするのが一番ですが、DBの負荷は大幅に高まる可能性もあり、きっと大変でしょう。
同一IDの同時アクセスのみを防ぐだけならそんなに難しくないと思いますが、他にも同じような処理をしている可能性も高く、それら全てに同時アクセスのチェック機構を組み込むのも面倒だし漏れる可能性も高くなるので、難しい判断になるでしょうね。


◆楽天オークションでも売っていたようですね(下は既に出品キャンセルのようですが)
posted by zjapan at 15:34| Comment(0) | TrackBack(1) | 事件です | このブログの読者になる | 更新情報をチェックする