米シティグループ顧客情報流出、その手口は単純だった 78
ストーリー by hylom
認証とかどうなってたんだ 部門より
認証とかどうなってたんだ 部門より
cheez 曰く、
米シティグループから21万人ものクレジットカード顧客情報が盗まれた事件（/.J過去記事）の手口は驚くほど単純なものだったそうだ（Mail Online、本家/.）。
「ここ最近最も大胆な手口の銀行データ盗難」などと言われたこの事件、大量の顧客情報を盗んだ手口は驚くほど単純なものだったそうだ。なんとシティグループのウェブサイトのクレジットカード顧客が利用するページのURLには顧客の口座番号が埋め込まれていたそうで、犯行グループは単にこの番号を他の番号に置き換えていくことでデータを手に入れていたとのこと。
犯行グループはこの口座番号を入れ替えてデータを取得するプログラムを開発し、大量のデータを持ち逃げしたとのことだ。
手口の問題じゃない (スコア:5, すばらしい洞察)
×「手口が単純」
○「システムが単純(あるいは考えなし)」
Re: (スコア:0)
真・ノーガード戦法
Re:手口の問題じゃない (スコア:1)
>真・ノーガード戦法
戦いになってないのだから、戦法ですらないと思う。
攻撃とかじゃなくて、単に誰でも閲覧できるという仕様は、戦いさえ無意味にしてしまうのだ。
# ちったぁ抵抗したり当たらない様に逃げたり、打ち返したら戦法かもしれないが...
Re:手口の問題じゃない (スコア:1)
>そんなことしたら、ノーガードじゃ無くなっちゃうじゃん。
いや、ほんまもんは乾坤一擲のダブルクロスカウンター狙いなのだが....
# 明日のジョーじゃなくて、明後日のジョーというか....
# ハタ坊だじょー....
残念！ (スコア:5, おもしろおかしい)
ＭＤＩＳにシステムを作ってもらっていれば、そこまで被害が広がらなかっただろうに。。
あまりにもお粗末 (スコア:3, 興味深い)
・・・だけどもうIT業界自体が「普通」じゃないんだろうな、と思わされる
＃こういうのがあるから「JUnitのカバレッジ100%だから絶対大丈夫！」とか言われても信用できないんですよね
Re:あまりにもお粗末 (スコア:1)
Re:あまりにもお粗末 (スコア:1)
それはRESTの問題ではない。
どんな技術を使おうと、認証なしで他人の機密情報にアクセスできたらダメでしょ。
Re:あまりにもお粗末 (スコア:1)
その口座番号がログインしたユーザーのものかチェックしないってのがそもそもの問題だな。
Re:あまりにもお粗末 (スコア:1)
元記事から読み取れた"仕様"に関する記述がURL設計だけだったから、氏がどういう風に考えているのか聞きたかったのです。
認証が行われないのは仕様ではなく単なるバグでしょう。
Re: (スコア:0)
URLに秘密情報を入れてはいけないってほとんど常識の部類だと思ったんだけど
そう油断して基本設計でわざわざ明記しなかったことがこの事故につながったのか。とても良くわかった
Re:あまりにもお粗末 (スコア:1)
Re:あまりにもお粗末 (スコア:2, すばらしい洞察)
実際ログイン後でも毎回その情報が利用されサーバ側から読み込まれる口座情報が変化するアホな仕様だったって事ですねぇ
確かに本質的な間違いはＵＲＬにあったとかＧＥＴだったとかＰＯＳＴだったとかでなく、ログイン認証後の口座情報識別を毎回させていた事にあるように受け取れます
#誰か気付けよ
Re:あまりにもお粗末 (スコア:1, すばらしい洞察)
そもそもPOSTよりもログに残りやすいってのがあるけど、
決定的なのは、SSL通信の時に大きな差がでるね。
Re:あまりにもお粗末 (スコア:2, 参考になる)
決定的なのは、SSL通信の時に大きな差がでるね。
出ますかね？
SSL通信時って、HTTPS通信時ってことですよね？少なくとも、URLのドメイン名より後ろの部分は、暗号化された経路内を流れるから、POSTだろうとGETだろうとPUTだろうと、口座番号が暗号化されているという点では違いが出ない気がしますが。
画面を後ろから覗き見される危険性が、現実的には一番大きいんじゃないかと。
Re: (スコア:0)
Re:あまりにもお粗末 (スコア:1)
でも口座番号は秘密情報なのかな？
フォームを見れば口座番号のフォーマットはわかります。
企業のウェブサイトには普通に取引口座の番号が書いてありますよ。
口座番号をURLに載せないことによりセキュリティ上の何が担保されるんでしょう？
Re:あまりにもお粗末 (スコア:3, すばらしい洞察)
一般論としては、口座番号そのものはもちろん秘密情報ではないでしょう。口座番号だけ
分かっていても、出来るのは「その口座に振り込むこと」くらいですし。
問題は「口座番号が分かれば個人情報やクレジットカード情報にアクセスできる」システムを
作ってしまったことなわけで。
Re:あまりにもお粗末 (スコア:1)
いや、令状に基づく法の執行たる差押えと同列に語られても……
Re: (スコア:0)
Re:あまりにもお粗末 (スコア:1, おもしろおかしい)
「テスト完璧です」って言われるから困る。
設計/仕様＝理解できない (スコア:1, 興味深い)
所謂、白紙から紙か何かにひとつのブツを
一応最初から最後まで完結したカタチで造った
事が人たちが多いから、その辺の、
「基本設計だとか仕様って言葉自体が、
理解不能＝分からない人たちが多い」
ですよ、シゴトに限らず（合掌）
まぁ、ガンプラのフルコンプリートモデルさえ
1体も組み立てたことの無い人たちと一緒にシゴト
した時は、さすがに、ツラかったですね（走召糸色木亥火暴）
"castigat ridendo mores" "Saxum volutum non obducitur musco"
Re: (スコア:0)
>＃こういうのがあるから「JUnitのカバレッジ100%だから絶対大丈夫！」とか言われても信用できないんですよね
仕様がおかしいって話なのに、なんでカバレッジの話を持ってくるのか意味がわからん。
どこのどいつが、「カバレッジ」で「仕様」が問題ないことを「絶対大丈夫」とかほざくんだよ…
まぁ、そもそもプログラムのバグに関してでも
>「JUnitのカバレッジ100%だから絶対大丈夫！」
なんて発言するやつに出会った事ないけど…
しかも何故にJUnit限定？
Re: (スコア:0)
何と戦っているんだ？
仕様がおかしかったら、カバレッジなんか無意味だというだけの話だよね？
ソニーが通った道 (スコア:3, 参考になる)
プレステ2の予約サイトで個人情報が漏れたときも同じやりかただったような。
予約番号が連番で減らしていくと自分より前に予約したヒトの情報が見放題だったという…。
Re: (スコア:0)
それ今年の話じゃないよね。
「まるで進歩していない(安西先生AA略」だったのか。
Re:ソニーが通った道 (スコア:1, 興味深い)
ドッグイヤーだと思ったらサザエさん時空だった
#サザエさん時空も、時間が経たない割に技術は進歩するのだが
エロ画像 (スコア:2, 参考になる)
たいてい連番になっているから、スクリプト組んでwgetで一気に。
ウェイトをかけて、規制を回避。
連番の推定アクセス (スコア:1, 興味深い)
連番の推定アクセスは私も良くやるので、今回の犯行グループがどの様な罪に問われるのか興味のある所だ。
Re: (スコア:0)
Re:エロ画像 (スコア:1, 参考になる)
クレジット番号を入力すると、一定数字毎にヒットする。誤入力の回数制限はないので何回でもトライ。
有効期限チェックとかないので、1週間はタダで取りあえず使えるようになる。
日本では手に入らない画像採り放題。
Re:エロ画像 (スコア:1)
必要なら複数のプロキシのリストを取得しておいて、
オプションでランダムに設定したり、画像を取得できなかったら、
そのプロキシはリストから削除したり。
# いらん蓋が開いた気がする
-- う～ん、バッドノウハウ？
Re: (スコア:0)
Re: (スコア:0)
ダウンロードソフトによってはhttp://example.com/img/img[001-100].jpgみたいなURLを001.jpg～100.jpgに展開してタスク登録してくれるヤツとかもありますね。
なんぼなんでも (スコア:2)
信じ難い。バグ死刑国家の方がましなくらい。
# 後半は嘘8*10^12345
どうしてこうなったか推理してみるテスト (スコア:2, 興味深い)
・が、時代の移り変わりと共に、セキュリティ・カードが導入されるようになり、認証は１度で済ますよう、途中で変更が加えられた
・その時深く考えずに認証後の口座情報引き出し部の仕様のみ従来のままで変更せず通してしまった
・気付かない ＞ ｵｱｰ
＃認証後はﾗﾝﾀﾞﾑに作成された英数字をｸﾗｲｱﾝﾄに渡し、その英数字と口座番号等の情報をログアウトまで一時的にｻｰﾊﾞ側で紐付け記憶させとけば良かったですかね
Re:どうしてこうなったか推理してみるテスト (スコア:1)
＃認証後はランダムに作成された英数字をクライアントに渡し、その英数字と口座番号等の情報をログアウトまで一時的にサーバ側で紐付け記憶させとけば良かったですかね
そのランダムコードをブルートフォース攻撃されたりして。
Re:どうしてこうなったか推理してみるテスト (スコア:1)
＃今時だとブルートフォース攻撃を許す認証の仕様そのものがそもそも間違いだと思うんだ
Re:どうしてこうなったか推理してみるテスト (スコア:1)
普通、そういった一致のチェックを何度も連続失敗した場合、一時的にロック掛けるのが昨今では普通ではないでしょうか
「普通」が重なってるよ。というのはさておき。
そんなチェックをするくらいだったら、クライアントからのデータに関係なく、そのセッションがアクセス中の口座番号をサーバ内で管理した方がよくない？
それに、セッションIDがあるのに、わざわざ別にランダムコードを準備するのは普通なの？
単にランダムコードって言うけど、実は乱数生成ってそんなに簡単じゃない。下手な方法を使うと、ブルートフォース攻撃どころか、予測攻撃すら成立しちゃうんだよね。
なので、ランダムコードを自前で作るよりは、実績のあるセッションIDを元にプログラミングするのが、普通なんじゃないかと思うけど、どうかな？
＃今時だとブルートフォース攻撃を許す認証の仕様そのものがそもそも間違いだと思うんだ
そうだよねえ。そもそもブルートフォース攻撃が一切受け付けない方法がより優れているのでは？
まあ、セッションIDに対するものは可能性は残るわけだけど。
Re:どうしてこうなったか推理してみるテスト (スコア:1)
そう言ったつもりだったんだけど言い方おかしかったのかなぁ
＃なんでそんな細かいところに拘るのかイマイチ解りませんがこれで手打ちにして良いですか？
Re:どうしてこうなったか推理してみるテスト (スコア:1)
そんなチェックをするくらいだったら、クライアントからのデータに関係なく、そのセッションがアクセス中の口座番号をサーバ内で管理した方がよくない？
そう言ったつもりだったんだけど言い方おかしかったのかなぁ
言い方がおかしいね。元のコメントには、
認証後はランダムに作成された英数字をクライアントに渡し
で、「クライアントからのデータに関係なく」なんて内容ではないね。
＃なんでそんな細かいところに拘るのかイマイチ解りませんがこれで手打ちにして良いですか？
細かいところに一々拘るのがプログラミングです。細かいところは適当に、ってのは、プログラムにはならないでしょう？
セキュリティホールを生み出した人たちも「なんでそんな細かいところに拘るのかイマイチ解りませんが」とか言えば、「手打ちにして良い」なんてことになりますか？
Re:どうしてこうなったか推理してみるテスト (スコア:1)
なので、このスレ上で完璧な対処や実装を模索されるのは貴方にお任せします。どうぞ拘りを持って気が済むまでどうぞ。
＃どうせ堅いレスが入ってるんだろうなぁと思い、嫌になった為見返すのが遅くなり真に申し訳ありませんでした
＃もっとも回答を遅らせた以外については全く悪いとは思ってませんが
Re:どうしてこうなったか推理してみるテスト (スコア:1)
すみませんそもそも仕事でも無いですし、私は貴方のようにそんな真剣に本件に取り組めません。
謝罪には及ばないと思いますよ。
ただ、esumi説がその程度のいい加減さだった、ということが判ったので、それで十分なんじゃないかと思います。
なので、このスレ上で完璧な対処や実装を模索されるのは貴方にお任せします。
いやいや。私の意見など、所詮実際に実装をしない素人の意見に過ぎませんよ。現実は、もっと厳しいって事です。
もちろん、esumiさんが考えてるよりもっと、と言う意味でもありますが。
Re:どうしてこうなったか推理してみるテスト (スコア:1)
セッションの存続時間と、攻撃に必要な時間を天秤にかけて安全性を担保していることを理解していますか？
はい。理解しています。ランダムコードが十分に長ければ、被害は少なくなるとは思います。でも、そこを明らかにしておかないと、無意味とまでは言いませんけど、被害が出やすくなってしまいますね。
そもそも、そのセッションと、そのセッションからアクセスできる口座番号を結びつけて管理しておくべきではないですか？
#1970960 [srad.jp]では、ランダムコードの長さも、セッションと口座番号との関連付けも、言及されていませんね。
しかし、セッション云々と言うのなら、新たなランダムコードなんか必要ないとも思いますが。ユーザ対口座が1:nの関係だったとしても、その口座を切り替える処理があればいいような気がします。
Re:どうしてこうなったか推理してみるテスト (スコア:1)
セッションIDにブルートフォース攻撃とはどういうことなの？
セッションIDへのブルートフォース攻撃は、ありえますよ。まともに生成されたセッションIDなら、その危険性は十分に下がるというだけです。
それが、セッションとの関連が定かではない「口座番号等の情報」と関連付けられた「ランダムに作成された英数字 [srad.jp]」程度思い付きだと、どんな攻撃を防ぎ得るかも定かではありません。そもそも、セッションIDですらありませんしね。
そんな面倒なことをするよりは、もっといい方法がありそうですよね。
あれ？ (スコア:2, 興味深い)
authn と authz (スコア:2)
何が問題だったのか、記事を読んでもすっきり書いてないので、自分なりに脆弱性の所在と今回の手口をまとめてみる。
脆弱性の所在：
認証と認可をきっちり分けてなくて、認証だけで全部の資源へのアクセスを認可してしまってること。
認証というのは Apache のモジュールでいうと mod_authn_* であり、認可は mod_authz_* 。
あるいは「認証領域」という言葉で議論することもあるかもしれない。
手口：
という脆弱性があるため、自分のカード以外でも番号が分かっていれば、その情報にアクセスできてしまう。番号が分かってなくても、総当たり的にカード番号をとっかえひっかえしてアクセスすれば当たるものには当たる。しかし、はずれも多いわけだから、ログチェックをきちんとやっていればもう少し被害の小さい段階で発見できたはずでもある。
＃だと、思ったんだが、違うかな？
類似の脆弱性：
よくあるのが、../ で上のディレクトリをたどれたりすると、 /usr1/../user2 で user1 の認証を通っていると user2 へアクセスできてしまうみたいなやつ。某オープンソースの Web システムで実際にあった話。
こりゃもう (スコア:1, おもしろおかしい)
吊すってレベルじゃないですね
Re: (スコア:0)
ソニー叩きとは一体何だったのか (スコア:1, すばらしい洞察)
と思わされる事件が続きますね…