パスワードを忘れた? アカウント作成

セブン-イレブンアプリに外部IDで不正ログインできる脆弱性が存在するとの報道」記事へのコメント

  • by Anonymous Coward on 2019年07月12日 21時30分 (#3651026)

    [独自記事]7pay不正利用問題、「7iD」に潜んでいた脆弱性の一端が判明
    https://tech.nikkeibp.co.jp/atcl/nxt/news/18/05498/ [nikkeibp.co.jp]

    が分かりやすいです。

    ただし、上記記事は、全く異なる2つの脆弱性の話が書かれているので、混同しないようにご注意ください。

    【脆弱1 : OpenID Connectのアクセストークン未検証】

    OpenID Connectのアクセストークンを検証していなかったので、ID(メールアドレス等)さえわかれば、
    パスワードが分からなくても、OAuthが成功したことにして他人がログインできる脆弱性があった。
    あまりにも酷すぎる脆弱性ですね!

    【脆弱性2 : 7iD の API のアクセスコントロールがガバガバな仕様】

    実は、7iD 自体をOpenIDとして、他のサイトにログインすることが可能なAPIを提供していました。
    ところ、がこのAPIのアクセスコントロールがガバガバで、API経由で他のアプリを含めた広範な個人データ、
    ハッシュ化されたパスワードなども取得可能だったのです。
    7iD で信頼できないサイトや脆弱性のあるサイトにログインしたら大変なことになるということです。

    脆弱性2については、仕様ともいえますが、まぁ危険ですね。
    Googleアカウントでどっかのサイトにログインしたら、そのサイトがGoogleアカウントのハッシュからGoogleドライブへのアクセス権やらGmailの送信権やら全取得、
    しかもAPIのアクセス権設定は無しで全承認しかないとかだったら、大騒ぎですよね。
    7iDはそういう仕様なのです。

    ここに返信
    • by Anonymous Coward on 2019年07月12日 21時37分 (#3651031)

      結局のところ、7payは、OAuthの認証が成功したというデータを送り付けるだけで、OpenIDのID(メールアドレス等)が分かるだけでログインできたのでした。

      つまり、チャージされた残高は、メールアドレスさえわかれば、第三者が使用可能でした。

      そして、登録されているクレジットカードからのチャージには、OpenIDでログインした場合を含めて追加で認証パスワードが必要なのですが、
      OpenIDでログインした状態ならば画面に表示される、お問い合わせ番号、7iDメアド、nanaco番号(すべてアプリに表示)だけあれば、それもリセットできました。
      https://twitter.com/ppp_payland/status/1146924240970514432 [twitter.com]

      7payの悪用はリスト型攻撃だと言われてましたが、メールアドレスとパスワードのリストではなく、メールアドレスだけのリストで攻撃可能だったのです。

      まぁ、リスト型攻撃には変わりないといったら変わりないのですが……。

      • by Anonymous Coward

        すげーなー、というしかないなぁ。
        7payと社長が矢面に立たされ袋叩きにされたけど、実際はベンダーの方の責任の可能性が高いってことか。
        今後のことを考えると、どこなのか公開して欲しいところ・・・

        • でも、その成果物を受け取って検収し、サービスインしたのは7-11側なので一義的に責任は7-11側にある。
          どこがベンダーであっても一緒ですよ。それをもってサービス提供側をを甘やかしてはならない。

          • by Anonymous Coward

            確かにそうだが、検証できるだけの技術ある人もいないだろうに。まぁそれが問題なんだけど。

            なんで日本の大企業は自分とこで技術者抱えて作ろうとしないんだろ。
            本当にバカだよねぇ。

            • by Anonymous Coward

              脳筋脳花企業では往々にしてシステム屋と言う「何か訳のわからん事をやっている奴ら」は隅っこに追いやられるか、子会社に追放される。

        • by Anonymous Coward

          そういう業者に発注したのもセブン側でしょ。

          とりあえずモックだけ作って本格実装は後回しにして開発進めていたら、その開発
          期間では無理です、実装が間に合いませんと問題を申告した技術者が本部の意向で
          左遷されて、後任のYESマンはなにもわからず本部の言われるとおりにした結果、
          本番環境でもモックのままサービスインしてしまった...
          みたいなことだって、ありえるんだから。

          合言葉は「動いているから良いじゃない」。

          責任者が被害しゃぶるのは良くないよ。

          • by Anonymous Coward

            苦汁「しゃぶれよ」

          • by Anonymous Coward

            あるいは
            発注者側責任者『何か起きたら全部責任は俺が取る!』と豪語する

            900件5500万円のクラック被害発生、セブングループとコード決済の信用が地に落ちる

            発注者側責任者『』、あるいは他グループ、競合他社に夜逃げ、あるいは首吊り自殺

    • 7iDのAPIは認証通れば、フル住所・生年月日・メールアドレス・電話番号・パスワードハッシュ他、あらゆる情報全取得可能。

      証拠
      https://pbs.twimg.com/media/D-yY32pU0AAXuxl.jpg:large [twimg.com]
      https://pbs.twimg.com/media/D-yY32pU0AAXuxl.jpg:large [twimg.com]

      認証通っているなら良いのでは? というのは間違い。
      だって、7iDのパスワードと追加認証の決済パスワードが同じなら、パスワードハッシュから解析できてしまうし(弱いパスワードはハッシュからでも解析可能)、
      APIから取得できる情報が、決済パスワードリセットの本人確認情報にもなるので、そこから攻めることもできる。

      OpenID Connect (OIDC) 1.0 準拠の分権的な認証プロトコルのオープンスタンダードを採用と聞くと、モダンで最先端なスラド民が喜びそうだが、大した知識がないのにそういう最先端の実装をすると、個人情報も何もかもオープンになってしまうのである。
      omni7を認証基盤にして、シンプルで最先端でかっこよいシステムを作ろうとして墓穴を掘った感じ。

      たいしたスキルも無いのに、オープンソースとか、オープンスタンダードだとか、そういうのを重視する「意識高い系」の人は大迷惑。

      最先端のシステム(OpenID Connectやら7iD認証基盤)を導入せずに、素直に独自のIDとパスワードで認証して、初回設定時と新規ログイン時にはSMSで確認コードを送る(二段階認証)という、古臭くてレガシーな仕様にしとけばこんな問題(不正ログインや不正チャージなど)はおきなかった。

    • by Anonymous Coward

      脆弱性2の方はTwitterで検証ツイートが出回ってたやつですね
      https://twitter.com/bulkneets/status/1147460171066560512 [twitter.com]
      まあ仰るとおり仕様とも言えますし騒ぐほどの事でもないかなと。

      問題は脆弱性1の方で、何人かは事件後に気付いてたようですが、さすがに口外した人はいなかったですね。
      パスワードリセットのメールが来ていない被害者が乗っ取られたのはこれを悪用されたと見て間違いないんじゃないかと。

      • by Anonymous Coward

        > これを悪用されたと見て間違いないんじゃないかと。

        この手口は使われていないと広報が新聞に答えてますね。

        セブンHDによると、専門家から、セブン―イレブンアプリに外部のIDから接続するシステムに欠陥があり、個人情報が他者から見られる危険性があると指摘されたという。「今のところ情報漏洩の形跡はない」(広報)という。
        https://www.asahi.com/articles/ASM7C647CM7CULFA02D.html [asahi.com]

        この手口だとすると不可解なのは、逮捕された出し子には、パスワードを伝えていたというのをどう説明するのか。

        出し子に脆弱性1でログインさせたわけではないとすると、どうやってパスワードを得たのか?

        • by Anonymous Coward

          親コメ見て、ええ…これはヤバ過ぎるだろ、と思いながら見てたけど、それですら無いのか。なんだこのセキュリティホールのバーゲンセールは?

        • by Anonymous Coward

          API叩いてパスのハッシュ抜けたらしいし、
          外部IDで入ってAPI叩いてパスクラ掛ければ行けたんじゃね?

    • 実際には弱いパスワードならハッシュから解析されちゃうから、ハッシュにしても漏洩しないように管理しなければいいことに変わりはないんだけど、
      パスワードってハッシュ化すると厳重に管理しなければという意識が薄れてしまって今回のようにAPIとして垂れ流すといった問題が起きちゃうんですよね。

      パスワードハッシュをAPIから取得可能にする意味あるのかな? と疑問だけど、データベースに入れた情報は原則全部APIから叩けるようにしたんだろうね。

      • by Anonymous Coward

        Salt付きハッシュなら漏洩しても、まあ別に……
        # Adobe漏洩事件のように全部同じSalt振ってなければ、ね
        # ところでDB情報を全部APIから叩けると仮定するとSaltはどこへ消えた?

        • by Anonymous Coward

          salt付きだと解決するのはレインボーテーブル攻撃が防げるだけだよ。高速に解けないだけで、時間かければ解ける。

          • by Anonymous Coward

            900件同時多発と言うから、まあ無理だな解読(が原因とは考えがたい)

        • by Anonymous Coward

          # ところでDB情報を全部APIから叩けると仮定するとSaltはどこへ消えた?

          普通に考えたらパスワードに埋め込まれているんでは?
          そうでないなら、普通ではないというだけだろう。
          今更不思議に思うことではない。

          • by Anonymous Coward

            見た感じ問題の文字列はSHA-512っぽい長さなので、saltがくっつけられてるとは思えんよね。

            • by Anonymous Coward

              固定ソルトかソルト無し、やろなぁ……
              ハッシュをAPIで返すのが意図通りの仕様であるなら、
              検証もAPI叩いた側でできる→追加情報不要→ソルト無しって事になるが……
              単にDB吐いてるだけなら固定ソルトもありうるかな。

              まぁハッシュとソルト持ってかれたら、
              総当たりないし辞書攻撃で短いないし弱いパスは突破されるね。
              ソルト類はレインボーテーブルでの超高速攻撃などは防ぐがほかは微妙。

              • by Anonymous Coward

                16桁のも破られているのでPW解読突破の線は薄い。
                あるいは複合的手法によりクラックされたとも考えられるが、短期間に900件同時多発とすると考えにくい(OpenID経由でクラックしたと言うのが最もしっくりくる)

              • by Anonymous Coward

                ソルト無しだったならレインボーテーブルで突破できた可能性もあるけど……
                apiの大穴以上にサーバ自身に任意コード系の穴があった可能性も考えたほうがいいかな。

    • by Anonymous Coward

      社長が「二段階認証」という単語を知らなかったことについて謎の擁護の流れができているようなんだがそういうのは一事が万事なんだよな

      • by Anonymous Coward

        社長が仕様を提示したんですかねぇ・・・

      • by Anonymous Coward

        二段階認証はあくまでも基本設計レベルの話なんで、二段階認証に対応しててもOpenID Connectの大穴みたいにガバガバに実装だと何の意味もないし。

        要するに2018年末にSIerとベンダー交替して7ヶ月の突貫工事でオンボロシステムで大事故、大損害、と言う経営層の誰かクビが飛ぶか首吊り自殺しても全然おかしくないレベル

      • by Anonymous Coward

        社長だって知っててもおかしくない、バカにされても仕方ないレベルかもしれんが、どっちかと言えばあそこにそういう事について受け答えできる人が用意されてないのが悪い。
        コレをネタに社長をバカにすることと技術的な問題や社内体制の問題をアレコレ言い合うのとは別の問題だよ。
        社長が技術的につよつよだったところで社内体制がダメだったら同じ事が起きるんだから。

    • by Anonymous Coward

      >【脆弱性2 : 7iD の API のアクセスコントロールがガバガバな仕様】
      これを脆弱性と呼んでる人たち正直技術者としては二段階認証を知らない社長と同レベルでは?という疑問がある
      問題が切り分けできないなら技術的なこと喋るのやめたほうがいいですよ。

      • by Anonymous Coward

        技術者得意の答え『それは仕様です』って奴ですか?

        ま7iD側がID Providerやるケースはレアケースで、実際にそれを設定していたユーザもごく少数でしょうから、900件の情報漏えいルートとしての可能性は低いでしょう。

        ただし、この脆弱性だけでも(5500万円損害事故が起きて無くても)個人情報漏洩事故として官庁(内閣府個人情報保護委員会等)に対し速やかに報告が義務付けられるレベルだけど!?

      • by Anonymous Coward

        んー、情報が全部取れ流のは最悪仕様としてもパスワードハッシュが取れるのは脆弱性かな? 不必要だし。
        とはいえ、脆弱性1に比べれば大した話では無い。監査とかでは指摘あると思うけどね。このレベルでも。事業者側でリスク判断レベルで。

    • by Anonymous Coward

      リンク先の記事以上に#3651026の概要が分かりやすくて助かります。

      > 脆弱性2については、仕様ともいえますが、まぁ危険ですね。
      社長が会見で利便性の方を優先したようなことを言ってと思いますが、アプリ(や連携するサイト)の
      設計思想として、セキュリティよりも利便性を重視する方針なんでしょうかね?

Stay hungry, Stay foolish. -- Steven Paul Jobs

処理中...