セブン-イレブンアプリに外部IDで不正ログインできる脆弱性が存在するとの報道 92
ストーリー by hylom
後手後手 部門より
後手後手 部門より
日経新聞が、スマートフォン向けのセブン-イレブンアプリに脆弱性があると報じている。この脆弱性は第三者がFacebookやLINEなどの外部IDで不正にログインできるというものだという。
日経新聞の報道後、セブン＆アイ・ホールディングスは外部IDでのログインをできないようにしたことを発表した（共同通信）。発表では脆弱性があったかどうかには触れられておらず、「セキュリティ強化に向けた総点検の一環」とのみ書かれている。
なお、セブン-イレブンアプリでのトラブルを受けて、「セブン-イレブンアプリ」やそれを想起させる呼称を使って氏名や生年月日などを不正に入手しようとする不審な電話も報告されているという（セブン＆アイ・ホールディングスの発表）。
パスワードなしで他人のアカウントにログインできた (スコア:5, 参考になる)
［独自記事］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はそういう仕様なのです。
メールアドレスだけで決済もクレジットカードチャージも可能 (スコア:5, 参考になる)
結局のところ、7payは、OAuthの認証が成功したというデータを送り付けるだけで、OpenIDのID(メールアドレス等)が分かるだけでログインできたのでした。
つまり、チャージされた残高は、メールアドレスさえわかれば、第三者が使用可能でした。
そして、登録されているクレジットカードからのチャージには、OpenIDでログインした場合を含めて追加で認証パスワードが必要なのですが、
OpenIDでログインした状態ならば画面に表示される、お問い合わせ番号、7iDメアド、nanaco番号（すべてアプリに表示）だけあれば、それもリセットできました。
https://twitter.com/ppp_payland/status/1146924240970514432 [twitter.com]
7payの悪用はリスト型攻撃だと言われてましたが、メールアドレスとパスワードのリストではなく、メールアドレスだけのリストで攻撃可能だったのです。
まぁ、リスト型攻撃には変わりないといったら変わりないのですが……。
Re: (スコア:0)
すげーなー、というしかないなぁ。
7payと社長が矢面に立たされ袋叩きにされたけど、実際はベンダーの方の責任の可能性が高いってことか。
今後のことを考えると、どこなのか公開して欲しいところ・・・
Re:メールアドレスだけで決済もクレジットカードチャージも可能 (スコア:1)
でも、その成果物を受け取って検収し、サービスインしたのは7-11側なので一義的に責任は7-11側にある。
どこがベンダーであっても一緒ですよ。それをもってサービス提供側をを甘やかしてはならない。
Re: (スコア:0)
そういう業者に発注したのもセブン側でしょ。
とりあえずモックだけ作って本格実装は後回しにして開発進めていたら、その開発
期間では無理です、実装が間に合いませんと問題を申告した技術者が本部の意向で
左遷されて、後任のYESマンはなにもわからず本部の言われるとおりにした結果、
本番環境でもモックのままサービスインしてしまった．．．
みたいなことだって、ありえるんだから。
合言葉は「動いているから良いじゃない」。
責任者が被害しゃぶるのは良くないよ。
Re: (スコア:0)
苦汁「しゃぶれよ」
トレンドに乗ろうとして、最先端の認証プロトコルのオープンスタンダードを採用するから…… (スコア:2, 参考になる)
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で確認コードを送る（二段階認証）という、古臭くてレガシーな仕様にしとけばこんな問題（不正ログインや不正チャージなど）はおきなかった。
素晴らしいAPIとJSONの活用 (スコア:2, 参考になる)
画像のURLミスっておんなじ画像になってたので修正
sp-api.omni7.jpのAPIにトークン投げた結果
証拠画像1: https://pbs.twimg.com/media/D-yY32pU0AAXuxl.jpg:large [twimg.com]
証拠画像2: https://pbs.twimg.com/media/D-yY4uKVUAEzApG.jpg:large [twimg.com]
証拠画像3: https://pbs.twimg.com/media/D-1pQMHUIAEYw-7.jpg:large [twimg.com]
技術者としてはJSONでこう綺麗にあらゆるデータがまとまって返ってくるのは気持ちいいんんですけどね
クラッカーにとっても気持ちいい設計です
Re: (スコア:0)
脆弱性2の方はTwitterで検証ツイートが出回ってたやつですね
https://twitter.com/bulkneets/status/1147460171066560512 [twitter.com]
まあ仰るとおり仕様とも言えますし騒ぐほどの事でもないかなと。
問題は脆弱性1の方で、何人かは事件後に気付いてたようですが、さすがに口外した人はいなかったですね。
パスワードリセットのメールが来ていない被害者が乗っ取られたのはこれを悪用されたと見て間違いないんじゃないかと。
パスワードをハッシュ化の害 (スコア:0)
実際には弱いパスワードならハッシュから解析されちゃうから、ハッシュにしても漏洩しないように管理しなければいいことに変わりはないんだけど、
パスワードってハッシュ化すると厳重に管理しなければという意識が薄れてしまって今回のようにAPIとして垂れ流すといった問題が起きちゃうんですよね。
パスワードハッシュをAPIから取得可能にする意味あるのかな？ と疑問だけど、データベースに入れた情報は原則全部APIから叩けるようにしたんだろうね。
Re: (スコア:0)
Salt付きハッシュなら漏洩しても、まあ別に……
# Adobe漏洩事件のように全部同じSalt振ってなければ、ね
# ところでDB情報を全部APIから叩けると仮定するとSaltはどこへ消えた？
Re: (スコア:0)
社長が「二段階認証」という単語を知らなかったことについて謎の擁護の流れができているようなんだがそういうのは一事が万事なんだよな
Re: (スコア:0)
社長が仕様を提示したんですかねぇ・・・
Re: (スコア:0)
>【脆弱性2 : 7iD の API のアクセスコントロールがガバガバな仕様】
これを脆弱性と呼んでる人たち正直技術者としては二段階認証を知らない社長と同レベルでは？という疑問がある
問題が切り分けできないなら技術的なこと喋るのやめたほうがいいですよ。
メールアドレスとパスワードだけでログインできるから弱い (スコア:3, 参考になる)
Yahoo! Japan IDとかのオープンIDって二段階認証が強要されるわけではないので、
多くの二段階認証を設定していない人の場合、メールアドレスとパスワードだけでログインできちゃいます。
この2つは使いまわしされるので「リスト型攻撃」にとっても弱いんですね。
任意の二段階認証って実際のところ、あまり意味ないですよね。
二段階認証をわざわざ設定するようなユーザは、パスワードを使いまわししていない上、パスワードが強力だったりしますから。
そしてオープンIDのAPIの仕様にもよるんですが、
一般的に、初めてログインする端末だとメールアドレスに確認コードを送るといった仕様を、API利用者側が追加で行うことはできません。
Googleの場合はGoogle側がそういったことをやってくれますが（プロバイダと端末の両方が違う場合）、Yahoo! IDは緩いし、サイト側で条件を変えることはできません。
なので、スラドレベルのサイトだったらオープンIDを使うと便利なのでよいですが、オープンIDは決済システムには向かないと思います。
オープンIDの認証に加えて、二段階認証を独自にやったりしたら余計に複雑怪奇でユーザーからすると訳の分からないシステムになっちゃいます。
なので、決済システムのようなセキュリティ重視の案件ならば、独自に要件を定めて、独自に実装するのが一番ではないでしょうか。
「オープンID」ってのが気持ち悪い (スコア:1)
OpenID Connectのことでしょ？
普通名詞と誤認するからやめてほしい
Re: (スコア:0)
Appleを「アップル」と書いたり、JavaScriptを「Javaスクリプト」と書いたり、Websiteを「Webサイト」と書くのも気持ち悪いですか？
Re: (スコア:0)
> JavaScriptを「Javaスクリプト」
これは凄く気持ち悪い。
Re: (スコア:0)
弊社の若いエンジニア達はJavaScriptをジャバスクと読んでるし、社内資料にもジャバスクって書いてますが、貴方はこういうの見たら発狂しそうですね！
Re: (スコア:0)
そんなフリスクじゃないんだから。
発狂はしないが頭悪そうだぞ、それ。ちゃんと指導してやれ。
Re: (スコア:0)
そのケースで「Javaスク」って書かれてたら気持ち悪いって話だろ たぶん噛み合ってない
Re: (スコア:0)
そんな会社とは取引したくないな
Re: (スコア:0)
「アイパス」とかもつかってそう
Re: (スコア:0)
これに限らず、やたらに口語を文語へ持ち込むようなマネはやめたほうがいいぞ
Re: (スコア:0)
Website って固有名詞なのですか？
Re: (スコア:0)
OpenIDとOpenID Connectは別もの。
ってかOpenIDは古い規約なんだよね。
OAuthの広まりを受けてOpenIDを作り直したのがOpenID Connectという感じ。
まさかほんとにOpenIDを使ってるわけではないだろうけど。
SSLとTLSの関係に似ている (スコア:0)
TLSとSSLは別のもの。
ってかSSLは古い規約なんだよね。
SSLの脆弱性を受けてSSLを作り直したのがTLSという感じ。
まさかほんとにSSLを使ってるわけではないだろうけど。
「オープンアイデイ」と書くべき (スコア:0)
そうですよね！
日本語で書くなら、商標の称呼通り「オープンアイデイ」と書くべきですよね。
https://www.j-platpat.inpit.go.jp/c1800/TR/JP-2010-009969/87C53D374E9F... [inpit.go.jp]
それって脆弱性？ (スコア:0)
オープンIDのことは詳しくは分からないけど、もともと本人の使用を前提にしているんだからオープンIDの性質上当たり前では？
Re: (スコア:0)
結局のところ、二段階認証が無い、って時点で詰んでたという話なのでは。
いいこと思いついた、nanacoのIDと紐づけて、支払時にnanacoのfelica機能で認証しようぜ！
ハードウェアキーだから偽造できまいｗ
Re: (スコア:0)
外部IDでも外部ID側で意思確認できてれば関係ない
そして外部側で出来てなかったというソースは無い
外部IDでの認証が成功したと勝手に誤認する欠陥があった可能性がある
Re: (スコア:0)
名前とかの情報はOpenIDのプロバイダからもらってる。認証に失敗したら、プロバイダから情報が来ないので、さすがに誤認はしないんじゃないかなぁ。
任意のアカウントのパスワードを誰でも変更可能っていうよくわからん脆弱性は、OpenID経由のやつだけが対象外だったので、まだこの件に関しては OpenIDのものだけが安全だったのだが、こっちにもなんか問題あったら、全滅じゃないのか？
Re: (スコア:0)
偽物の外部IDと真性の内部IDが不正に連携できる脆弱性って話だろ
真性の外部IDと真性の内部IDが正当に連携できるだけなら当然脆弱性ではない
Re: (スコア:0)
分かった、憶測だけど悪意のある第三者が勝手に作った外部IDと7payID?を提携させても普通は7payID内部で外部IDと提携するか確認や認証機構があるけど
今回それが無かったって事じゃなかな？ だったら相当やばいね、だから被害がこんなに拡大したのかも･･･
Re: (スコア:0)
セブンのID自体も外部扱いだったから（想像）、問題の洗い出しのために一回全部止めたんでは
Re: (スコア:0)
日経の書出しが悪いのでそう思うのも無理はないけど、本文はこう。
トークン認証バイパス？
Re: (スコア:0)
OpenID Connectって接続手順がたーくさんあるのね。
シンプルじゃないというレベルじゃなく、ぐちゃぐちゃ。
大抵の場合、列挙されているだけでなぜそうしなければいけないのかの説明はない。必然性があるからたくさんあるんだけどね。
どれでもいいから簡単な実装で、という戦略で使うとこんな風になる。
ID＝メールアドレスをランダムにすべき (スコア:0)
よくパスワードをランダム主張するのが良いというセキュリティの専門家が居ますが、
現実としては糞みたいなパスワードリマインダー等が蔓延っているので、パスワードだけ安全にしてもアカウントを守れるとは限りません。
パスワードだけでなく、ID＝メールアドレスもランダムにして、サービス毎に違うものにすべきです。
私の場合、セブンペイだったら seven-pay-qihu1r4ratf4jahg@example.com のようにします。
qihu1r4ratf4jahg の部分はサービス毎に別のランダムな英数字にします。
example.com は独自ドメインで、有効なメールアドレス（@の左部）はコマンド1行で増やせるようにしています。
この方法は、同時に迷惑メール対策（どこから漏洩したか分かるし、迷惑メールが来たメールアドレスのみ切り捨てるのも容易）や、フィッシング詐欺メール対策にもなります。
パスワードリマインダーもID＝メールアドレスが分からないと使えないことが多いので、リマインダーの悪用も防げます。
今回のセブンペイみたいに、パスワードリマインダーも、認証も何もかも酷いサービスであっても、ID＝メールアドレスがランダムであるならば悪用はされませんでした。
皆さん、ID＝メールアドレスはランダムにして、使いまわさないようにしましょう。
Re:ID＝メールアドレスをランダムにすべき (スコア:1)
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]
Re: (スコア:0)
＞パスワードだけでなく、ID＝メールアドレスもランダムにして、サービス毎に違うものにすべきです。
その方法の弱点は、パスワードを忘れちゃうような人だとIDも分からなくなって、
パスワードリセットもできないから本人が二度とログイン不可能になっちゃうことですね。
＃誰もログインできないと言う意味では鉄壁の防御と言っていいのかな？
登録E-mailアドレスと、ログインIDを独立したものにして、パスワード（とID）のリセットは
E-mailアドレスを中心に実行するあたりが落とし所かな。
これさえもIDを覚えるのが面倒という人の前にはなんの意味もない。
そういう意味ではケータイ使った二段階認証って、ほんと良く考えられたシステムだと思う。
Re: (スコア:0)
確かにその方が望ましいけれども、世の中のすべての人が気軽にメールアドレス増やせる環境なわけじゃない
用意できる人なら「糞みたいなパスワードリマインダー等」の心配はまず不要だろうし、Google等のメールアカウントをサービス毎に用意するのはどうかと思う
Gmailは+nameで対応済み (スコア:2, 参考になる)
Gmailだとしたら、
hoge@gmail.com のアドレスあったら、hoge+abcdefg@gmail.com や hoge+ifiaufuf@gmail.com のようなアドレスも自動で同じメールボックスに受信できますよ。
フィルター機能でラベル分けすることもできます。
なので、サービス毎にメールアドレスを分けるのも簡単にできます。
Re:Gmailは+nameで対応済み (スコア:1)
ただ + が入っていると不正なメールアドレスとする困ったサイトが一定存在するのが難点。
皆がRFC5322を守れば良いのに (スコア:1)
+ は本来普通に使うができるはずなのに、弾く糞サイトがあるのは困ったものですね。
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]
Re: (スコア:0)
> [参考] 「メールアドレスのルール」系まとめがそろって間違ってるのでご注意を
> 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
Re: (スコア:0)
むしろE-mailアドレスについては、アドレスの方が糞仕様，又は仕様バグだよねとしか。
仕様を記述するのもバリデータを実装するのも苦労するような仕様にするなよと。
あの時代にバリデーションの実装とか考えずに、即興で作ったものならまあそんなもんだろけど。
JavaScriptが糞言語であるのと同じような物．
Re: (スコア:0)
態々試さないけど、メールアドレスの正確な仕様に沿っているシステムってどんだけあるんだろ。
"\\.....!#$%&'*+-/=?^_`{|}~.....\""@example.com
こんなんウチのシステムに受け入れていいのかって逆に思う。まともにメールをやりとりできる気がしない。
# フレームワークのバリデーションをそのまま使ってる。それが正確かどうかなんてしらん。
Re: (スコア:0)
逆に、皆がもうRFC5322の”でくくればなんでもありみたいな規定をやめるように考えてくれたらいいのに。
RFCは完璧で絶対遵守ってものじゃないよ。他人を貶す道具にしたい人には便利なものかもしれないけどね。
Re: (スコア:0)
お金やらからまない一般サイトでは、パスワードをサイトごとに別のランダムにして、
それをパスワード管理ソフトや、ブラウザのパスワード保存機能で覚えさせておくのが最適では？
Re: (スコア:0)
外部IDでのログインをできないようにした
https://www.sej.co.jp/company/important/2019071202.html [sej.co.jp]
セキュリティー強化しました
https://www.sej.co.jp/company/important/2019070522002.html [sej.co.jp]
別件ですけど？