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

セブン-イレブンアプリに外部IDで不正ログインできる脆弱性が存在するとの報道 92

ストーリー by hylom
後手後手 部門より

日経新聞が、スマートフォン向けのセブン-イレブンアプリに脆弱性があると報じている。この脆弱性は第三者がFacebookやLINEなどの外部IDで不正にログインできるというものだという。

日経新聞の報道後、セブン&アイ・ホールディングスは外部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

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

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

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

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

    • 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の方で、何人かは事件後に気付いてたようですが、さすがに口外した人はいなかったですね。
      パスワードリセットのメールが来ていない被害者が乗っ取られたのはこれを悪用されたと見て間違いないんじゃないかと。

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

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

      • by Anonymous Coward

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

    • by Anonymous Coward

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

      • by Anonymous Coward

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

    • by Anonymous Coward

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

  • by Anonymous Coward on 2019年07月12日 19時55分 (#3650981)

    Yahoo! Japan IDとかのオープンIDって二段階認証が強要されるわけではないので、
    多くの二段階認証を設定していない人の場合、メールアドレスとパスワードだけでログインできちゃいます。
    この2つは使いまわしされるので「リスト型攻撃」にとっても弱いんですね。

    任意の二段階認証って実際のところ、あまり意味ないですよね。
    二段階認証をわざわざ設定するようなユーザは、パスワードを使いまわししていない上、パスワードが強力だったりしますから。

    そしてオープンIDのAPIの仕様にもよるんですが、
    一般的に、初めてログインする端末だとメールアドレスに確認コードを送るといった仕様を、API利用者側が追加で行うことはできません。
    Googleの場合はGoogle側がそういったことをやってくれますが(プロバイダと端末の両方が違う場合)、Yahoo! IDは緩いし、サイト側で条件を変えることはできません。

    なので、スラドレベルのサイトだったらオープンIDを使うと便利なのでよいですが、オープンIDは決済システムには向かないと思います。
    オープンIDの認証に加えて、二段階認証を独自にやったりしたら余計に複雑怪奇でユーザーからすると訳の分からないシステムになっちゃいます。
    なので、決済システムのようなセキュリティ重視の案件ならば、独自に要件を定めて、独自に実装するのが一番ではないでしょうか。

  • by Anonymous Coward on 2019年07月12日 20時50分 (#3651009)

    OpenID Connectのことでしょ?
    普通名詞と誤認するからやめてほしい

    • by Anonymous Coward

      Appleを「アップル」と書いたり、JavaScriptを「Javaスクリプト」と書いたり、Websiteを「Webサイト」と書くのも気持ち悪いですか?

      • by Anonymous Coward

        > JavaScriptを「Javaスクリプト」
        これは凄く気持ち悪い。

        • by Anonymous Coward

          弊社の若いエンジニア達はJavaScriptをジャバスクと読んでるし、社内資料にもジャバスクって書いてますが、貴方はこういうの見たら発狂しそうですね!

          • by Anonymous Coward

            そんなフリスクじゃないんだから。
            発狂はしないが頭悪そうだぞ、それ。ちゃんと指導してやれ。

          • by Anonymous Coward

            そのケースで「Javaスク」って書かれてたら気持ち悪いって話だろ たぶん噛み合ってない

          • by Anonymous Coward

            そんな会社とは取引したくないな

          • by Anonymous Coward

            「アイパス」とかもつかってそう

          • by Anonymous Coward

            これに限らず、やたらに口語を文語へ持ち込むようなマネはやめたほうがいいぞ

      • by Anonymous Coward

        Website って固有名詞なのですか?

    • by Anonymous Coward

      OpenIDとOpenID Connectは別もの。
      ってかOpenIDは古い規約なんだよね。
      OAuthの広まりを受けてOpenIDを作り直したのがOpenID Connectという感じ。

      まさかほんとにOpenIDを使ってるわけではないだろうけど。

      • TLSとSSLは別のもの。
        ってかSSLは古い規約なんだよね。
        SSLの脆弱性を受けてSSLを作り直したのがTLSという感じ。

        まさかほんとにSSLを使ってるわけではないだろうけど。

    • そうですよね!
      日本語で書くなら、商標の称呼通り「オープンアイデイ」と書くべきですよね。

      https://www.j-platpat.inpit.go.jp/c1800/TR/JP-2010-009969/87C53D374E9F... [inpit.go.jp]

  • by Anonymous Coward on 2019年07月12日 19時02分 (#3650939)

    オープンIDのことは詳しくは分からないけど、もともと本人の使用を前提にしているんだからオープンIDの性質上当たり前では?

    • by Anonymous Coward

      結局のところ、二段階認証が無い、って時点で詰んでたという話なのでは。

      いいこと思いついた、nanacoのIDと紐づけて、支払時にnanacoのfelica機能で認証しようぜ!
      ハードウェアキーだから偽造できまいw

      • by Anonymous Coward

        外部IDでも外部ID側で意思確認できてれば関係ない
        そして外部側で出来てなかったというソースは無い

        外部IDでの認証が成功したと勝手に誤認する欠陥があった可能性がある

        • by Anonymous Coward

          名前とかの情報はOpenIDのプロバイダからもらってる。認証に失敗したら、プロバイダから情報が来ないので、さすがに誤認はしないんじゃないかなぁ。

          任意のアカウントのパスワードを誰でも変更可能っていうよくわからん脆弱性は、OpenID経由のやつだけが対象外だったので、まだこの件に関しては OpenIDのものだけが安全だったのだが、こっちにもなんか問題あったら、全滅じゃないのか?

    • by Anonymous Coward

      偽物の外部IDと真性の内部IDが不正に連携できる脆弱性って話だろ
      真性の外部IDと真性の内部IDが正当に連携できるだけなら当然脆弱性ではない

      • by Anonymous Coward

        分かった、憶測だけど悪意のある第三者が勝手に作った外部IDと7payID?を提携させても普通は7payID内部で外部IDと提携するか確認や認証機構があるけど
        今回それが無かったって事じゃなかな? だったら相当やばいね、だから被害がこんなに拡大したのかも・・・

    • by Anonymous Coward

      セブンのID自体も外部扱いだったから(想像)、問題の洗い出しのために一回全部止めたんでは

    • by Anonymous Coward

      日経の書出しが悪いのでそう思うのも無理はないけど、本文はこう。

      関係者によると、外部IDの一部の情報が分かれば、本人になりすましてセブンイレブンアプリにログインし、個人情報を閲覧できてしまう脆弱性があった。

      トークン認証バイパス?

    • by Anonymous Coward

      OpenID Connectって接続手順がたーくさんあるのね。
      シンプルじゃないというレベルじゃなく、ぐちゃぐちゃ。
      大抵の場合、列挙されているだけでなぜそうしなければいけないのかの説明はない。必然性があるからたくさんあるんだけどね。
      どれでもいいから簡単な実装で、という戦略で使うとこんな風になる。

  • by Anonymous Coward on 2019年07月13日 0時19分 (#3651086)

    よくパスワードをランダム主張するのが良いというセキュリティの専門家が居ますが、
    現実としては糞みたいなパスワードリマインダー等が蔓延っているので、パスワードだけ安全にしてもアカウントを守れるとは限りません。

    パスワードだけでなく、ID=メールアドレスもランダムにして、サービス毎に違うものにすべきです。
    私の場合、セブンペイだったら seven-pay-qihu1r4ratf4jahg@example.com のようにします。
    qihu1r4ratf4jahg の部分はサービス毎に別のランダムな英数字にします。
    example.com は独自ドメインで、有効なメールアドレス(@の左部)はコマンド1行で増やせるようにしています。

    この方法は、同時に迷惑メール対策(どこから漏洩したか分かるし、迷惑メールが来たメールアドレスのみ切り捨てるのも容易)や、フィッシング詐欺メール対策にもなります。

    パスワードリマインダーもID=メールアドレスが分からないと使えないことが多いので、リマインダーの悪用も防げます。
    今回のセブンペイみたいに、パスワードリマインダーも、認証も何もかも酷いサービスであっても、ID=メールアドレスがランダムであるならば悪用はされませんでした。

    皆さん、ID=メールアドレスはランダムにして、使いまわさないようにしましょう。

    • by Anonymous Coward on 2019年07月13日 1時36分 (#3651101)

      Sign in with Apple最大の特徴は、簡単便利な生体認証を利用した二段階認証とアカウントを作成するときのメールアドレスの取り扱い方法です。

      まず、ログインするときは指紋認証(Touch ID)または顔認証(Face ID)を利用し、パスワード入力は不要。これはとても便利です。スマホを持って画面を見ていればいいので、二段階の煩わしさはまったく感じません(Googleのサードパーティアプリも指紋認証が使えるところもあるんですが、まだそこまで普及してません)。

      そして、アカウントを作成する時、通常はメールアドレスを入力するところですが、実際使っているアドレスはあまり公開したくないですよね。そういった方のためにAppleはランダムな文字を組み合わせて、臨時のメールアドレスを作ってくれます。なので、サードパーティ側に実際のアドレスを知られずに済みます。広告会社など、メールアドレスからユーザの情報を得ることも多いので、ランダムなアドレスなら安心です。ちなみに、アプリなどからメールが来た場合は、Appleが元のアドレスに転送してくれます。
      https://www.gizmodo.jp/2019/06/details-of-sign-in-with-apple.html [gizmodo.jp]

      親コメント
    • by Anonymous Coward

      >パスワードだけでなく、ID=メールアドレスもランダムにして、サービス毎に違うものにすべきです。
      その方法の弱点は、パスワードを忘れちゃうような人だとIDも分からなくなって、
      パスワードリセットもできないから本人が二度とログイン不可能になっちゃうことですね。
      #誰もログインできないと言う意味では鉄壁の防御と言っていいのかな?

      登録E-mailアドレスと、ログインIDを独立したものにして、パスワード(とID)のリセットは
      E-mailアドレスを中心に実行するあたりが落とし所かな。
      これさえもIDを覚えるのが面倒という人の前にはなんの意味もない。

      そういう意味ではケータイ使った二段階認証って、ほんと良く考えられたシステムだと思う。

    • by Anonymous Coward

      確かにその方が望ましいけれども、世の中のすべての人が気軽にメールアドレス増やせる環境なわけじゃない
      用意できる人なら「糞みたいなパスワードリマインダー等」の心配はまず不要だろうし、Google等のメールアカウントをサービス毎に用意するのはどうかと思う

      • by Anonymous Coward on 2019年07月13日 1時53分 (#3651104)

        Gmailだとしたら、
        hoge@gmail.com のアドレスあったら、hoge+abcdefg@gmail.com や hoge+ifiaufuf@gmail.com のようなアドレスも自動で同じメールボックスに受信できますよ。
        フィルター機能でラベル分けすることもできます。
        なので、サービス毎にメールアドレスを分けるのも簡単にできます。

        親コメント
        • by Anonymous Coward on 2019年07月13日 3時21分 (#3651125)

          ただ + が入っていると不正なメールアドレスとする困ったサイトが一定存在するのが難点。

          親コメント
          • by Anonymous Coward on 2019年07月13日 4時01分 (#3651128)

            + は本来普通に使うができるはずなのに、弾く糞サイトがあるのは困ったものですね。
            Gmailのエイリアスが弾かれる不具合というのは、RFCを守らないでいい加減なバリデーションをやっていると、困ったことになるという良い例ですね。

            あと、半可通が "." (ドット) が2つ以上連続するメールアドレスはRFC違反だという出鱈目を広めてしまった(何故か信じている技術者が多い)せいで、わざわざドットの連続を正規表現で弾く糞サイトが最近増えてきているようです。どっかのライブラリがそうしているのかもしれませんが。

            正しくは、local-part を quoted-string (") で囲えば、" と \ を除く すべての記号 (印字可能 ASCII 記号)が利用できます。 さらに、quoted-string の中では quoted-pair が利用できると書かれているので、" と \ でさえも、直前に \ を配置すれば利用できます。

            つまり

            "\\.....!#$%&'*+-/=?^_`{|}~.....\""@example.com

            はRFC準拠の正しいメールアドレスです。これが弾かれるシステムは糞ですので、試してみると良いと思います。糞システムを検出するリトマス試験紙になります。

            [参考] 「メールアドレスのルール」系まとめがそろって間違ってるのでご注意を
            https://orgachem.hatenablog.com/entry/2013/11/26/015343 [hatenablog.com]

            親コメント
            • by Anonymous Coward

              > [参考] 「メールアドレスのルール」系まとめがそろって間違ってるのでご注意を
              > https://orgachem.hatenablog.com/entry/2013/11/26/015343 [hatenablog.com]

              この記事のコメントによるとSMTPに限定しているようだが、それなら参照するのはRFC 5321のほうがいいと思うの(間違っているまとめに言えという話かもしれんが)。FWSとかコメントとか考えなくてよくなるし。

              で、RFC 5321には
              > While the above definition for Local-part is relatively permissive,
              > for maximum interoperability, a host that expects to receive mail
              > SHOULD avoid defining

              • by Anonymous Coward

                むしろE-mailアドレスについては、アドレスの方が糞仕様,又は仕様バグだよねとしか。
                仕様を記述するのもバリデータを実装するのも苦労するような仕様にするなよと。

                あの時代にバリデーションの実装とか考えずに、即興で作ったものならまあそんなもんだろけど。
                JavaScriptが糞言語であるのと同じような物.

            • by Anonymous Coward

              態々試さないけど、メールアドレスの正確な仕様に沿っているシステムってどんだけあるんだろ。

              "\\.....!#$%&'*+-/=?^_`{|}~.....\""@example.com

              こんなんウチのシステムに受け入れていいのかって逆に思う。まともにメールをやりとりできる気がしない。

              # フレームワークのバリデーションをそのまま使ってる。それが正確かどうかなんてしらん。

            • by Anonymous Coward

              逆に、皆がもうRFC5322の”でくくればなんでもありみたいな規定をやめるように考えてくれたらいいのに。

              RFCは完璧で絶対遵守ってものじゃないよ。他人を貶す道具にしたい人には便利なものかもしれないけどね。

    • by Anonymous Coward

      お金やらからまない一般サイトでは、パスワードをサイトごとに別のランダムにして、
      それをパスワード管理ソフトや、ブラウザのパスワード保存機能で覚えさせておくのが最適では?

typodupeerror

日々是ハック也 -- あるハードコアバイナリアン

読み込み中...