パスワードを忘れた? アカウント作成
336003 story
セキュリティ

米シティグループ顧客情報流出、その手口は単純だった 78

ストーリー by hylom
認証とかどうなってたんだ 部門より

cheez 曰く、

米シティグループから21万人ものクレジットカード顧客情報が盗まれた事件(/.J過去記事)の手口は驚くほど単純なものだったそうだ(Mail Online本家/.)。

「ここ最近最も大胆な手口の銀行データ盗難」などと言われたこの事件、大量の顧客情報を盗んだ手口は驚くほど単純なものだったそうだ。なんとシティグループのウェブサイトのクレジットカード顧客が利用するページのURLには顧客の口座番号が埋め込まれていたそうで、犯行グループは単にこの番号を他の番号に置き換えていくことでデータを手に入れていたとのこと。

犯行グループはこの口座番号を入れ替えてデータを取得するプログラムを開発し、大量のデータを持ち逃げしたとのことだ。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • 手口の問題じゃない (スコア:5, すばらしい洞察)

    by rin_penguin (9144) on 2011年06月15日 20時24分 (#1970894)

    ×「手口が単純」
    ○「システムが単純(あるいは考えなし)」

    • by Anonymous Coward

      真・ノーガード戦法

      • by d5 (42418) on 2011年06月15日 21時33分 (#1970937)

        >真・ノーガード戦法

        戦いになってないのだから、戦法ですらないと思う。
        攻撃とかじゃなくて、単に誰でも閲覧できるという仕様は、戦いさえ無意味にしてしまうのだ。

        # ちったぁ抵抗したり当たらない様に逃げたり、打ち返したら戦法かもしれないが...

        親コメント
  • 残念! (スコア:5, おもしろおかしい)

    by northern (38088) on 2011年06月15日 21時05分 (#1970920)

    MDISにシステムを作ってもらっていれば、そこまで被害が広がらなかっただろうに。。

  • by duenmynoth (34577) on 2011年06月15日 20時27分 (#1970897) 日記
    普通なら基本設計の時点で却下されるような駄目仕様
    ・・・だけどもうIT業界自体が「普通」じゃないんだろうな、と思わされる

    #こういうのがあるから「JUnitのカバレッジ100%だから絶対大丈夫!」とか言われても信用できないんですよね
    • 基本設計の時点でダメって、REST [wikipedia.org]的なURL構造がダメってこと? 認証が行われないのはもちろんバグだし、それがテストであぶり出されないのは問題だけれどそれはURL構造とは関係ない。
      親コメント
      • by firewheel (31280) on 2011年06月15日 23時09分 (#1970984)

        それはRESTの問題ではない。

        どんな技術を使おうと、認証なしで他人の機密情報にアクセスできたらダメでしょ。

        親コメント
      • by Anonymous Coward

        URLに秘密情報を入れてはいけないってほとんど常識の部類だと思ったんだけど
        そう油断して基本設計でわざわざ明記しなかったことがこの事故につながったのか。とても良くわかった

        • 参考までに教えて欲しいのだけれど、FORMから口座番号をPOSTするのどれだけの違いがありますか?
          親コメント
          • Re:あまりにもお粗末 (スコア:2, すばらしい洞察)

            by esumi (15966) on 2011年06月15日 21時57分 (#1970948)
            不要である筈の、初回のログイン認証後であっても、毎回のsubmitで口座番号情報を送信させている事に不審を抱き、ちょっと番号いじってみたら
            実際ログイン後でも毎回その情報が利用されサーバ側から読み込まれる口座情報が変化するアホな仕様だったって事ですねぇ

            確かに本質的な間違いはURLにあったとかGETだったとかPOSTだったとかでなく、ログイン認証後の口座情報識別を毎回させていた事にあるように受け取れます

            #誰か気付けよ
            親コメント
          • Re:あまりにもお粗末 (スコア:1, すばらしい洞察)

            by Anonymous Coward on 2011年06月15日 21時57分 (#1970949)

            そもそもPOSTよりもログに残りやすいってのがあるけど、
            決定的なのは、SSL通信の時に大きな差がでるね。

            親コメント
            • by Ryo.F (3896) on 2011年06月16日 9時06分 (#1971114) 日記

              決定的なのは、SSL通信の時に大きな差がでるね。

              出ますかね?
              SSL通信時って、HTTPS通信時ってことですよね?少なくとも、URLのドメイン名より後ろの部分は、暗号化された経路内を流れるから、POSTだろうとGETだろうとPUTだろうと、口座番号が暗号化されているという点では違いが出ない気がしますが。

              画面を後ろから覗き見される危険性が、現実的には一番大きいんじゃないかと。

              親コメント
          • by Anonymous Coward
            URLに秘密情報が含まれるという違いがある。
            • URLにパスワードや暗証とかセッションとかそういう情報を載せるのは御法度だと認識しています。
              でも口座番号は秘密情報なのかな?
              フォームを見れば口座番号のフォーマットはわかります。
              企業のウェブサイトには普通に取引口座の番号が書いてありますよ。
              口座番号をURLに載せないことによりセキュリティ上の何が担保されるんでしょう?
              親コメント
        • by Anonymous Coward
          秘密の情報をどうやってURLに入れたんだ?
    • Re:あまりにもお粗末 (スコア:1, おもしろおかしい)

      by Anonymous Coward on 2011年06月16日 8時47分 (#1971108)
      でも中国の人に依頼するとカバレッジ96%なのに
      「テスト完璧です」って言われるから困る。
      親コメント
    • by Seth (1176) on 2011年06月16日 10時59分 (#1971173) 日記

       所謂、白紙から紙か何かにひとつのブツを
      一応最初から最後まで完結したカタチで造った
      事が人たちが多いから、その辺の、
      「基本設計だとか仕様って言葉自体が、
       理解不能=分からない人たちが多い」
      ですよ、シゴトに限らず(合掌)

       まぁ、ガンプラのフルコンプリートモデルさえ
      1体も組み立てたことの無い人たちと一緒にシゴト
      した時は、さすがに、ツラかったですね(走召糸色木亥火暴)

      --
      ------------------------------ "castigat ridendo mores"
      親コメント
    • by Anonymous Coward

      >#こういうのがあるから「JUnitのカバレッジ100%だから絶対大丈夫!」とか言われても信用できないんですよね

      仕様がおかしいって話なのに、なんでカバレッジの話を持ってくるのか意味がわからん。
      どこのどいつが、「カバレッジ」で「仕様」が問題ないことを「絶対大丈夫」とかほざくんだよ…

      まぁ、そもそもプログラムのバグに関してでも
      >「JUnitのカバレッジ100%だから絶対大丈夫!」
      なんて発言するやつに出会った事ないけど…

      しかも何故にJUnit限定?

      • by Anonymous Coward

        何と戦っているんだ?
        仕様がおかしかったら、カバレッジなんか無意味だというだけの話だよね?

  • by Anonymous Coward on 2011年06月15日 20時54分 (#1970914)

    プレステ2の予約サイトで個人情報が漏れたときも同じやりかただったような。
    予約番号が連番で減らしていくと自分より前に予約したヒトの情報が見放題だったという…。

    • by Anonymous Coward

      それ今年の話じゃないよね。
      「まるで進歩していない(安西先生AA略」だったのか。

  • エロ画像 (スコア:2, 参考になる)

    by Anonymous Coward on 2011年06月15日 20時25分 (#1970895)
    ああ、昔エロ画像サイトで似たようなことをやっていた。
    たいてい連番になっているから、スクリプト組んでwgetで一気に。
    ウェイトをかけて、規制を回避。
    • by Anonymous Coward on 2011年06月15日 20時32分 (#1970901)

      連番の推定アクセスは私も良くやるので、今回の犯行グループがどの様な罪に問われるのか興味のある所だ。

      親コメント
      • by Anonymous Coward
        ACCS事件を思い出してしまいました
    • Re:エロ画像 (スコア:1, 参考になる)

      by Anonymous Coward on 2011年06月15日 20時50分 (#1970912)
      AOLでもそんな感じだったね。
      クレジット番号を入力すると、一定数字毎にヒットする。誤入力の回数制限はないので何回でもトライ。
      有効期限チェックとかないので、1週間はタダで取りあえず使えるようになる。
      日本では手に入らない画像採り放題。
      親コメント
    • by ukenerai (36532) on 2011年06月17日 15時11分 (#1971804) 日記

      必要なら複数のプロキシのリストを取得しておいて、
      オプションでランダムに設定したり、画像を取得できなかったら、
      そのプロキシはリストから削除したり。
      # いらん蓋が開いた気がする

      親コメント
    • by Anonymous Coward
      拝啓、エロハッカー殿
    • by Anonymous Coward

      ダウンロードソフトによってはhttp://example.com/img/img[001-100].jpgみたいなURLを001.jpg~100.jpgに展開してタスク登録してくれるヤツとかもありますね。

  • 信じ難い。バグ死刑国家の方がましなくらい。

    # 後半は嘘8*10^12345

  • ・当初は、submitの際、ユーザー認証に必要な情報も常に同時送信され、認証も都度行う仕様で一応記事のような問題は起きない状態だった
    ・が、時代の移り変わりと共に、セキュリティ・カードが導入されるようになり、認証は1度で済ますよう、途中で変更が加えられた
    ・その時深く考えずに認証後の口座情報引き出し部の仕様のみ従来のままで変更せず通してしまった
    ・気付かない > オアー

    #認証後はランダムに作成された英数字をクライアントに渡し、その英数字と口座番号等の情報をログアウトまで一時的にサーバ側で紐付け記憶させとけば良かったですかね
    • #認証後はランダムに作成された英数字をクライアントに渡し、その英数字と口座番号等の情報をログアウトまで一時的にサーバ側で紐付け記憶させとけば良かったですかね

      そのランダムコードをブルートフォース攻撃されたりして。

      親コメント
      • 普通、そういった一致のチェックを何度も連続失敗した場合、一時的にロック掛けるのが昨今では普通ではないでしょうか

        #今時だとブルートフォース攻撃を許す認証の仕様そのものがそもそも間違いだと思うんだ
        親コメント
        • 普通、そういった一致のチェックを何度も連続失敗した場合、一時的にロック掛けるのが昨今では普通ではないでしょうか

          「普通」が重なってるよ。というのはさておき。

          そんなチェックをするくらいだったら、クライアントからのデータに関係なく、そのセッションがアクセス中の口座番号をサーバ内で管理した方がよくない?

          それに、セッションIDがあるのに、わざわざ別にランダムコードを準備するのは普通なの?
          単にランダムコードって言うけど、実は乱数生成ってそんなに簡単じゃない。下手な方法を使うと、ブルートフォース攻撃どころか、予測攻撃すら成立しちゃうんだよね。
          なので、ランダムコードを自前で作るよりは、実績のあるセッションIDを元にプログラミングするのが、普通なんじゃないかと思うけど、どうかな?

          #今時だとブルートフォース攻撃を許す認証の仕様そのものがそもそも間違いだと思うんだ

          そうだよねえ。そもそもブルートフォース攻撃が一切受け付けない方法がより優れているのでは?
          まあ、セッションIDに対するものは可能性は残るわけだけど。

          親コメント
          • >そんなチェックをするくらいだったら、クライアントからのデータに関係なく、そのセッションがアクセス中の口座番号をサーバ内で管理した方がよくない?
            そう言ったつもりだったんだけど言い方おかしかったのかなぁ

            #なんでそんな細かいところに拘るのかイマイチ解りませんがこれで手打ちにして良いですか?
            親コメント
            • そんなチェックをするくらいだったら、クライアントからのデータに関係なく、そのセッションがアクセス中の口座番号をサーバ内で管理した方がよくない?

              そう言ったつもりだったんだけど言い方おかしかったのかなぁ

              言い方がおかしいね。元のコメントには、

              認証後はランダムに作成された英数字をクライアントに渡し

              で、「クライアントからのデータに関係なく」なんて内容ではないね。

              #なんでそんな細かいところに拘るのかイマイチ解りませんがこれで手打ちにして良いですか?

              細かいところに一々拘るのがプログラミングです。細かいところは適当に、ってのは、プログラムにはならないでしょう?
              セキュリティホールを生み出した人たちも「なんでそんな細かいところに拘るのかイマイチ解りませんが」とか言えば、「手打ちにして良い」なんてことになりますか?

              親コメント
              • すみませんそもそも仕事でも無いですし、私は貴方のようにそんな真剣に本件に取り組めません。
                なので、このスレ上で完璧な対処や実装を模索されるのは貴方にお任せします。どうぞ拘りを持って気が済むまでどうぞ。

                #どうせ堅いレスが入ってるんだろうなぁと思い、嫌になった為見返すのが遅くなり真に申し訳ありませんでした
                #もっとも回答を遅らせた以外については全く悪いとは思ってませんが
                親コメント
              • すみませんそもそも仕事でも無いですし、私は貴方のようにそんな真剣に本件に取り組めません。

                謝罪には及ばないと思いますよ。
                ただ、esumi説がその程度のいい加減さだった、ということが判ったので、それで十分なんじゃないかと思います。

                なので、このスレ上で完璧な対処や実装を模索されるのは貴方にお任せします。

                いやいや。私の意見など、所詮実際に実装をしない素人の意見に過ぎませんよ。現実は、もっと厳しいって事です。
                もちろん、esumiさんが考えてるよりもっと、と言う意味でもありますが。

                親コメント
  • あれ? (スコア:2, 興味深い)

    by Anonymous Coward on 2011年06月15日 23時23分 (#1970992)
    アドレス欄にURL入れて出て来た情報を記録した。何の法を冒してるんだろう?
  • by elderwand (34630) on 2011年06月16日 9時05分 (#1971112) 日記

    何が問題だったのか、記事を読んでもすっきり書いてないので、自分なりに脆弱性の所在と今回の手口をまとめてみる。

    脆弱性の所在:
    認証と認可をきっちり分けてなくて、認証だけで全部の資源へのアクセスを認可してしまってること。
    認証というのは Apache のモジュールでいうと mod_authn_* であり、認可は mod_authz_* 。
    あるいは「認証領域」という言葉で議論することもあるかもしれない。

    手口:
    という脆弱性があるため、自分のカード以外でも番号が分かっていれば、その情報にアクセスできてしまう。番号が分かってなくても、総当たり的にカード番号をとっかえひっかえしてアクセスすれば当たるものには当たる。しかし、はずれも多いわけだから、ログチェックをきちんとやっていればもう少し被害の小さい段階で発見できたはずでもある。

    #だと、思ったんだが、違うかな?

    類似の脆弱性:
    よくあるのが、../ で上のディレクトリをたどれたりすると、 /usr1/../user2 で user1 の認証を通っていると user2 へアクセスできてしまうみたいなやつ。某オープンソースの Web システムで実際にあった話。

  • こりゃもう (スコア:1, おもしろおかしい)

    by Anonymous Coward on 2011年06月15日 20時26分 (#1970896)

    吊すってレベルじゃないですね

    • by Anonymous Coward
      みずほ銀行、まだましwww
  • by Anonymous Coward on 2011年06月16日 8時23分 (#1971095)

    と思わされる事件が続きますね…

typodupeerror

UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie

読み込み中...