7pay 2019年不正利用

他で漏れたIDとパスワードの組で利用者のアカウントに入られ、登録済みのカードからチャージされて店で使われた、と会社は結論づけた。要因には、複数端末からのログインへの対策と、追加の認証が十分でなかったことが挙げられた。

2019年7月1日に始まり、同年9月30日24時に廃止されたバーコード決済のサービス。運営はセブン&アイ・ホールディングス傘下のセブン・ペイ。同社とセブン‐イレブン・ジャパンの発表に沿って書いています。2026年11月時点の情報です。サービスは廃止済みで、弱点は残っていません。

要点

開始の翌日に利用者から問い合わせがあり、その翌日に社内の調査で不正利用が分かった[1]。被害は7月31日17時時点で808人、38,615,473円[4]。
会社が公表した原因は、他で入手したIDとパスワードの組による、いわゆるリスト型アカウントハッキングの可能性が高いこと[4]。
防げなかった要因として会社は、複数端末からのログインへの対策と、二要素認証などの追加認証の検討が十分でなかったことを挙げた[4]。
外部IDの連携、パスワードリマインダー、有人チャットでの再設定が直接の原因になった事例は、調査では見つかっていない[4]。
止める所は、ログインの追加の認証、チャージの前の再認証と上限、取引の監視の3つ。根本は、パスワードだけで決済に届かない作りにすること。

何が起きたか

会社の発表による被害の形は、第三者が何らかの方法で利用者のアカウントに入り、本人になりすまし、登録されたクレジットカードとデビットカードでチャージし、セブン‐イレブンの店で商品を買う、というもの[1]。被害には、不正なチャージと、利用者が自分でチャージした残高を使われたものの両方が入る[4]。

図1 2019年の経緯。出典は会社の発表[1][4][5][6]

時点	人数と金額	発表
7月4日6時	約900名、約5,500万円。不正アクセスが疑われる分の試算	3社の連名、7月4日[1]
7月29日17時	807人、38,605,335円。セブン・ペイの認定	セブン‐イレブン・ジャパン、7月30日[3]
7月31日17時	808人、38,615,473円。不正チャージと不正利用の両方を含む	セブン&アイ・ホールディングス、8月1日[4]

認定は、利用者からの問い合わせとの突き合わせ、カード会社からの情報、不正の型と同じ使われ方をした取引の独自の認定、の3つの方法で行った[4]。会社は被害の全額を補償するとした[1][4]。

公表された原因

8月1日の発表は、外部の情報セキュリティ会社と連携したプロジェクトの調査として、次の2つを書いた[4]。

攻撃者がどこかで不正に入手したIDとパスワードのリストを使い、利用者になりすましてアクセスを試みる、いわゆるリスト型アカウントハッキングである可能性が高い。
外部IDの連携、パスワードリマインダー、有人チャットによるパスワードリセットなどの機能が、不正アクセスの直接の原因となった事例は現時点で見つかっていない。内部からの流出も、明確な痕跡は確認できない。

そのうえで、防げなかった理由を会社は次のように整理した。8月1日の時点の3つと、弁護士を中心とする検証チームの検証を踏まえた10月10日の2つがある。

発表	防げなかった要因
8月1日[4]	1 システム上の認証の水準。複数端末からのログインへの対策と、二要素認証などの追加認証の検討が十分でなかった 2 開発の体制。グループ各社が参加し、システム全体の最適化を十分に検証できていなかった 3 システムリスクの管理の体制。相互の検証と牽制が働いていたか、さらに検証が要る
10月10日[6]	1 7pay独自の認証のシステムなどと、不正の検知と防止の対策が、必ずしも万全でなかった 2 セキュリティの水準に関する厳格な方針が徹底されず、セキュリティを統括するプロジェクト管理の機能と、システムリスクを指摘する管理の機能が十分に働いていなかった

発表

防げなかった要因

8月1日[4]

1 システム上の認証の水準。複数端末からのログインへの対策と、二要素認証などの追加認証の検討が十分でなかった
2 開発の体制。グループ各社が参加し、システム全体の最適化を十分に検証できていなかった
3 システムリスクの管理の体制。相互の検証と牽制が働いていたか、さらに検証が要る

10月10日[6]

1 7pay独自の認証のシステムなどと、不正の検知と防止の対策が、必ずしも万全でなかった
2 セキュリティの水準に関する厳格な方針が徹底されず、セキュリティを統括するプロジェクト管理の機能と、システムリスクを指摘する管理の機能が十分に働いていなかった

発表に無い説明

再設定の流れや外部IDの連携が入口だった、とする記述は会社の文書に無い。会社の文書は、それらが直接の原因となった事例は見つかっていない、と書いている[4]。攻撃者がどこで組を得たか、何件のログインが試されたかも公表されていない。

どこで止められたか

ここからは、架空の決済サービス pay.example.com で、公表された形の攻撃が通る道と、守りを置く所を示す。会社の発表に書かれた事実ではなく、設計の点検の観点である。

図2 公表された形の攻撃が通る道と、守りを置く3か所。架空の作り

A ログインと二段階の認証

使い回された組は、パスワードとしては正しい。正しいパスワードを止める仕組みは、パスワードの外にしか置けない。OWASP は、多要素認証をパスワードを狙う攻撃の大半への飛び抜けて良い守りとし、新しいブラウザや端末、IPアドレス、普段と違う国や場所からのログインを、追加の認証を求める契機に挙げる[8]。会社が挙げた不足も、この2つ、複数端末からのログインへの対策と追加認証だった[4]。会社は7月5日、今後の対策の例として二段階認証の導入を挙げた[2]。

失敗の回数の制限、応答の文言をそろえること、漏えい済みのパスワードの拒否は、A07 認証の不備の「自動化された推測」の節にまとめてある。

共通のIDに決済を足すとき

7iDは、セブン‐イレブンのアプリと7payを使うためのグループ共通のIDだった[4]。会社は7月30日に7iDのパスワードを一斉にリセットし、再ログインの時のパスワードの設定の条件を変えた[3]。

図3 共通のIDに決済を足すと、IDの強さがそのまま決済の強さになる。架空の作り

決済を足す前に、そのIDの認証が決済に見合うかを見直す。既存のパスワードは、決済の無いサービスのために登録されたものである。
決済を初めて使う時に、パスワードの再設定か追加の認証の登録を求め、漏えい済みの一覧と照合する[8]。
IDを共有する全部のサービスの中で、最も重い操作に合わせて認証の強さを決める。

再設定の流れ

会社の調査は、パスワードリマインダーと有人チャットによるパスワードリセットが直接の原因となった事例は見つかっていない、とした[4]。それでも、ログインに追加の認証を足すなら、再設定と回復も同じ強さにそろえないと、そこが残った道になる。OWASP は、回復が多要素認証を回避して乗っ取る道を攻撃者に与えないことが肝心とし、要素を変える前に登録済みの要素で再認証させるよう書く[9]。パスワードとメールアドレスの変更にも多要素認証を求める候補に挙げる[9]。トークンの作り方と期限はA07 認証の不備の「弱いパスワード再設定」の節にある。

外部IDの連携

会社は7月11日に外部IDによるログインを止めた[4]。直接の原因となった事例は見つかっていないとしている[4]。設計の点検では、外部IDでログインした時にも、決済の前の再認証と上限が同じに掛かるかを確かめる。外部の事業者の認証の強さは、こちらでは選べない。外部の事業者が出したトークンを受け取るなら、発行元と宛先を確かめる。A07 認証の不備の「トークンの宛先を確かめない」の節を参照する。

B チャージの前の再認証と上限

ログインを通られても、お金に換える操作の直前で止められる。会社は7月5日、二段階認証と並べて、チャージ1回あたりの上限額の見直しを今後の対策の例に挙げた[2]。キャッシュレス推進協議会のガイドラインは7payの開始の前、2019年4月16日に出ていた。漏れたカード番号の不正利用を対象とするが、決済の時の金額と回数の上限を設けるかを検討し、設けるなら対象、アカウントか端末かの単位、値を決めることと、取引の監視の結果に応じた上限や追加の本人認証を、コード決済事業者に必須として求めている[7]。OWASP も、高額の取引を、セッションの途中で追加の認証を求める場面に挙げる[8]。

図4 チャージの直前に置く判定。架空の作り

悪い例と直した例。架空のチャージのAPI

// 悪い例 ログイン済みなら、登録済みのカードでいくらでも何度でもチャージできる
app.post("/charge", requireLogin, async (req, res) => {
  await chargeFromSavedCard(req.user.id, req.body.amount);
  res.json({ ok: true });
});

// 直した例 上限を常に掛け、危険が高ければ直前の追加の認証を求め、本人に知らせる
app.post("/charge", requireLogin, async (req, res) => {
  const amount = Number(req.body.amount);
  if (!(await withinLimits(req.user.id, amount))) return res.status(422).json({ error: "上限を超えています" });
  const risky = await isNewDevice(req) || await isUnusual(req.user.id, amount);
  if (risky && !recentlyVerified(req.session, 5 * 60)) return res.status(401).json({ stepUp: true });
  await chargeFromSavedCard(req.user.id, amount);
  await notifyOwner(req.user.id, "charge", amount);
  res.json({ ok: true });
});

上限は危険の判定と別に、常に掛ける。判定が外れた時の被害の大きさを決めるのは上限である。

C 検知

発覚は開始の翌日、利用者からの問い合わせだった[1]。会社は7月3日に海外IPからのアクセスを遮断し、7月6日に監視の体制を強め、10月10日には不正の検知と防止の対策が万全でなかったことを要因に挙げた[4][6]。ガイドラインも、取引の監視の実施と精度の向上を、コード決済事業者に必須として求めていた[7]。

利用者の苦情より先に、運営の側で気付く仕組みを開始の日から動かす。ログインの失敗の急増、1つの送信元から多数のID、新しい端末からのログインの直後のチャージを見る。
チャージと支払いのたびに本人へ知らせると、身に覚えのない取引を本人が早く見つける。OWASP は普段と違う出来事を利用者に知らせることを守りの1つに挙げる[8]。
止める手段を、機能ごとに前もって用意しておく。会社はカードのチャージ、現金のチャージ、新規登録、外部IDのログインを段階的に止めた[4]。

修正の状態

7payは2019年9月30日24時に全サービスを廃止した[5]。残高の払い戻しの申し出は、2019年10月1日から2020年1月10日まで受け付けた[5]。会社は再発防止策として、グループのセキュリティを統括する専門の組織の設置、セキュリティとシステム開発の方針と指針の再整備、プロジェクト管理とセキュリティの専門の人材の拡充、社内の教育を挙げた[6]。

守り方

根本の直し方

パスワード1つで決済に届かない作りにする。お金に換える操作の前に、パスワードの外の要素での認証を置く[8][9]。
新しい端末や普段と違う場所からのログインには、追加の認証を求める[8]。
再設定、回復、外部IDのログインを、通常のログインと同じ強さにそろえる。どれか1つでも弱ければ、そこが入口になる[9]。
既存の共通IDに決済を足すときは、IDの認証を決済に合わせて見直し、既存のパスワードを漏えい済みの一覧と照合する[8]。
認証とセッションは、試験を経た仕組みを使う。詳しくはA07 認証の不備。

次は緩和の策で、根本の直し方を済ませたうえで重ねる。

チャージと支払いに、1回と1日の金額と回数の上限を、アカウントと端末の単位で掛ける[7]。
取引を監視し、危険が高い取引は止めて追加の本人確認に回す[7]。
ログイン、チャージ、支払い、連絡先とパスワードの変更を、そのたびに本人へ知らせる[8]。
ログインの失敗を、IDごとと送信元ごとに制限し、記録して警告につなぐ。A07の「自動化された推測」の節。
カードのチャージ、現金のチャージ、新規登録、外部IDのログインを、機能ごとに止められるようにしておく。
決済を出す前の点検で、認証と不正検知を開発の外の目で確かめる。会社が挙げた要因には、開発の体制とリスク管理の体制が含まれる[4][6]。

参照

「7pay」一部アカウントへの不正アクセス発生によるチャージ機能の一時停止についてセブン&アイ・ホールディングス、セブン‐イレブン・ジャパン、セブン・ペイ、2019年7月4日
「7pay」に対する不正アクセスの件第3報セブン‐イレブン・ジャパン、2019年7月5日。今後導入予定の対応策
「7pay」に対する不正アクセスの件第5報セブン‐イレブン・ジャパン、2019年7月30日
「7pay」サービス廃止のお知らせとこれまでの経緯、今後の対応に関する説明についてセブン&アイ・ホールディングス、2019年8月1日。発表のページ
7payサービス終了のお詫びと7pay残高払戻しに関するご案内セブン‐イレブン・ジャパン、2019年9月27日
「7pay」事案に関する再発防止策並びに役員報酬の自主返上および子会社における代表取締役の異動に関するお知らせセブン&アイ・ホールディングス、2019年10月10日
コード決済における不正流出したクレジットカード番号等の不正利用防止対策に関するガイドラインキャッシュレス推進協議会、Ver. 1.0、2019年4月16日。6.2、7.2
Credential Stuffing Prevention Cheat Sheet OWASP Cheat Sheet Series
Multifactor Authentication Cheat Sheet OWASP Cheat Sheet Series

7pay 2019年 不正利用

要点