就在这几天前后爆发了一场中小规模的 Apple Pay 盗刷问题，使得对于此项技术和功能的质疑越发严重。特此以不是那么严谨的形式，从不同角度分析和复盘此次事件的起因、经过和技术细节。尽量以客观真实的方式阐述事件，本文章不针对任何组织或主体,如果有疑问，欢迎各位指出。 起因 根据小红书等平台的消息，在 9 月 26 日晚上出现了首次对于中国银行卓隽万事达信用卡的盗刷情况，且可以出现交易的类型为 Apple Pay 虚拟卡，在 Apple Wallet 中也可以看到卡片的交易详情。此后在很短的时间内盗刷仍在延续，并且扩散到了中国银行的所有种类的万事达借记卡，从单币种到全币种完全覆盖，至此盗刷仍在进一步扩大，逐步地在招商银行、农业银行等银行也出现了相同的盗刷问题。 至 27 号，目前盗刷的大浪头已经过去，但仍有小部分在不断盗刷，好多漏洞点已被补上，至今还有不少持卡者正通过报警和 dispute 等方式寻求款项争议的帮助。经过案例整合后发现，绝大部分盗刷卡片的卡组织都是 Mastercard 万事达 。 目前卡类型没有具体的限制，主要以信用卡为主，借记卡也掺杂在其中，但主要比例不是很大，并且不涉及某个卡种、币种或其他的类型，只要是 Mastercard 万事达卡再加上 Apple Pay 绑定就存在着相关问题风险。 技术概述 在找到此次 Apple Pay 盗刷事件的主要核心问题所在，最需要的应该是先简单了解一下 Apple Pay 的盗刷、Apple Pay 的支付流程和简单的技术细节 首先要知道，Apple Pay 为什么一直被说为安全，是因为它采用 tokenization 标记化支付技术。 所谓 tokenization 标记化支付，可以简单理解为，之前你想要付款买一个东西，是需要你信用卡的信息才能够向你的信用卡扣款。你每次拿着实体卡向别人支付，实际上也只不过是把这套信息给了商家，让商家用这套信息扣款罢了。 但这样的话就出现一个问题：你无论向哪个商户付款，你给商户的信息永远是一套。那么只要有一个别有用心的商户拿到了你这套信息，他不再需要你的实体信用卡，就可以依靠这个信息直接向你的信用卡扣款，这样就会很危险，很容易被盗刷。 但是 Apple Pay 的 tokenization 不会把你真实的信用卡信息直接透露给商家，它会根据你真实的信用卡信息生成一套假的信用卡信息，每次都用这套假的信用卡信息向别人刷卡，并且每次的信息都会根据本地的加密算法进行刷新。这样的话，在不同的商户那里拿到的信息都不一样，商户也没有办法通过拿到的信息再扣款，因为这个信息用过一次就失效了。 将卡片添加到 Apple Pay 时，你输入卡片信息后，iPhone 会将信息经 Apple 服务器转发至银行服务器。银行服务器校验你能否开通 Apple Pay，若可以，便生成一个专门留存在你设备上的、为设备打造的设备虚拟卡号（DPAN，Device-PAN），再将虚拟卡号及加密密钥全部发送到你的 iPhone，由 iPhone 存储到一块单独芯片——Secure Element 芯片中。这块芯片与手机其他存储芯片分开，普通应用完全没有权限访问，甚至有的系统组件也不能访问 Secure Element 中的信息。 在你准备进行交易时，会打开 Apple Wallet，通过 Touch ID 或 Face ID 校验身份，用生物验证技术解锁 Secure Element 中的数据。此时，Secure Element 会完全在本地，通过银行传过来的 DPAN 和安全加密算法，生成一个一次性的支付信息，也就是 cryptogram。 之后 cryptogram 和 DPAN 会通过 NFC 传递给 POS 机，而加密算法和你的真实设备卡号都不会从 iPhone 中流出去。这样的话，商户那边拿到你的 cryptogram 之后只能用一次，第二次就用不了了，这便是 Apple Pay 的一个简单运作机制。 问题出在了哪里？ 由于目前官方机构并没有发文，也没有一个明确的调查报告，万事网联中国及万事达中国已经发文要成立专项调查小组，但是具体的信息并没有传出，目前只能根据网上传出的信息来拼凑真实状况。以下信息皆为小道消息或推测，切勿完全当真。 1.DPAN设备虚拟卡号泄露问题 首先第一点，DPAN 及设备虚拟卡号它是从你的真实卡号生成出来的一个虚拟设备卡号，跟你的真实卡号是不一样的，但是为了让更多的 POS 机好识别，一般来说，DPAN 是按照银行卡卡号的格式走的，假如说你银行卡的卡号是 1234-1234-1234-1234，那么虚拟卡也就是 DPAN 的格式也是 1234-1234-XXXX-XXXX。卡号由卡 BIN 和卡号后半段组成。卡 BIN 是一张卡的卡头，也可以成为卡的信息。一般来说，同一个卡组织、同一家银行、同一个卡种、同一个地区，它们的前几位都是相同的。 当然也有不少卡组织有自己的 tokenization range 卡号池，这样的话同一卡组织内也不完全要求同样的 BIN，会从相关的卡池中直接随机一个卡 BIN 出来，这样就和原来卡号完全不一样了 而后半部分就是设备卡信息和真实卡不同的地方，这部分通常根据加密算法随机生成，这样的话就可以实现和原卡号后几位隔离开 但是，有一些信息指出，在有些卡组织（或某家银行）的内部交易中，似乎并没有严格按照加密的要求和规定，每次虚拟卡号的后 8 位或后 4 位随机生成，而是按照发卡顺序以 0001、0002、0003 的顺序按顺序生成。这样的话， 不法分子或盗刷者在没有经历过真实 Apple Pay 交易的情况下便可轻松知道在某一个数字范围内的大批量卡号全部都是真实的，都可以用，便相当于直接获取了大批量的 DPAN 名单 。 2.DPAN权限系统问题 问题又一次出现了，按理说 DPAN 会受到 DPAN 权限管理系统和 tokenization 的限制，只有在此银行允许通过线下或者线上交易的时候，DPAN 才是有效的，在其余场景下，只要没有获得授权，DPAN 都是没有用的，哪怕你获得了也只能干看。它本身虽然在很多国内草台班子的银行中被作为新开卡或者新开户在银行系统里处理，但它本身不应该拥有作为一个银行卡的完整权限，它应该是受限的，仅能在特定用途中被使用。 但是问题出现了，根据部分信息指出，很多银行的系统里错误地将 DPAN 虚拟设备卡片这张卡当成了一张具有完整权限的普通银行卡，并且没有对于使用这个卡号进行交易进行限制，也就是说， 只要他人得到了这个卡号，就可以用这个卡号去进行交易 。这使得 DPAN 在泄露之后又具有了可用权限。 3.三要素境外交易漏洞 但银行在进行境外线上交易的时候其实还是有很多防线的，最简单的防线就是三要素和 3DS。三要素就是卡号、卡有效期和 CVV 验证号，只有说输入完 3 个信息全部输入正确才能够进行交易；而 3DS 就是需要在输入三要素之后，进行银行的手机预留手机号验证或邮箱验证，相当于二次验证。这样的话不法分子得不到全量信息，看起来也没有什么问题的样子。 但是事实证明，在好多的银行内部并没有实现完全强制的三要素验证，也就是说在部分环境下，哪怕用户只输入三要素中的 2 个，比如说卡号和有效期，不输入 CVV 或者不做 3DS，也能完成验证。 卡号在前面说了，由于银行系统的问题，使得原来不能在线上用的 DPAN 变得可用，而有效期这个问题就更好解决了。虚拟卡的有效期都是按照开卡日期开始计算，一般有一个固定的 5 年或者几年，而万事网联的 Apple Pay 上线日期又很固定，有大量的用户都集中在上线的前一天、上线的第一天或第二天等日期内进行交易，进行新增的卡片。只要不法分子用几个常见的开卡日期做推算，在开卡日期基础上加 5 年或者几年，就可以直接推算出虚拟卡片的有效期，相当于 2 个要素都有了，就直接就可以 实现在网站上直接扣款，无需进行验证 。 另外，由于一部分 checkout 网站的不完善，不法分子通过伪装声明自己的付款是 Apple Pay 付款，因此骗过了 checkout 系统的眼睛，使得 checkout 不再校验 CVV 或者其他的安全措施。 于是在这 3 个漏洞的共同驱动下，最终导致只要不法分子拿到 DPAN 和有效期就可以直接刷。而且由于 DPAN 在银行系统中的记录是专门为 Apple Pay 等手机支付所提供的，所以就会被显示，所以交易信息就会被推送到 Apple Wallet 上，就会被认定为通过 Apple Pay 交易，于是到最后就被认定了，Apple Pay 被盗刷。 疑问？ 1.为什么安卓手机没有被盗刷，反倒苹果的 Apple Pay 被盗刷了？ 根据现有的资料和数据来说，主要是由卡组织提供的服务出现了问题。而目前支持 Mastercard 万事达及万事网联卡添加的 X pay 平台仅有苹果的 Apple Pay 一家，其他的华为 Pay、小米 Pay、荣耀 Pay 都不支持通过 Mastercard 万事达卡支付，自然也就不会有这个问题。 2.我之前使用了 AirCard 这个项目，更改了卡片，是不是这个项目有后门不安全？ AirCard 这个项目的源码是公开的，虽然有些人会说安装的发行版本不一定是完全依照着源码构建的，但是 AirCard 所利用的漏洞其实是对于 Apple Wallet 原数据的更改，而真正涉及到卡片和财产安全的信息，如上文所述，全部存储在 SE 芯片及 Secure Element 芯片当中，这块芯片完全独立于其他的系统部门，别说普通的应用了，就连系统都不是能够完全访问 SE 芯片的，并且从技术角度上来看，AirCard 就没有办法访问到 SE 芯片，也就构不成财产安全。就算它真的有病毒，那么利用的也是现有的 Apple 漏洞，在它真正的开始发作之前，漏洞就会被修复，因为这类漏洞通常极为明显。 3.没有可能是苹果服务器泄露的数据吗？ 根据 Apple 在文档中提供的信息，苹果的服务器是不存储任何的银行卡信息的，包括 DPAN、cryptoGRAM 以及设备以及真实信用卡号码 CVV 等这些信息，顶多经过一下苹果服务器的中转，最后 DPAN 之类的存储在本地的安全 SE 芯片内，其他的是存储在银行客户端的，当然，这确实只是 Apple 自己的一面声明。 要说真的具体的来说，如果 Apple 遵守了这个声明，那么问题就不出在这儿。如果 Apple 没有遵守的话，真的偷偷的存储了一部分信息，那确实有一定的可能，但是可能性不大。 4.为什么是部分银行而不是全部银行出现问题？ 很显然，这件事情若以上资料属实的话，那么完全就是发卡行的锅，因为部分发卡行没有完善自己的 IT 系统，导致了 DPAN 还能够被正常使用这一巨大问题。虽然不能说其他银行一定没有问题，但是至少在此次事件中，其他银行并没有暴露出 DPAN 的权限管理重大失误。 5.那么 Apple Pay 真的没有一点责任吗？ 没有给 Apple 洗地的意思，但就这个环节来看没有问题： Apple 端：Apple Pay 本身的代码包括 Secure Elements 没有出现一点问题，也没有证据证明 Apple 服务器存储或泄露了用户信息。 问题环节：整体环节出在了银行端和卡组织端系统管理的重大失误和纰漏。 责任边界：Apple Pay 仅为银行或卡组织提供了 tokenization 服务，Apple 没有权利也没有能力负责管理各个银行的软件或硬件系统；不是 Apple 想赌这个口子，而是 Apple 根本没有能力，也不知道有这个口子。 6.盗刷到底是怎样绕过 SE 的动态验证码的？ 从国际标准和通用惯例上来讲，使用 D-PAN 支付必须走 Secure Elements，通过本地加密算法计算出来的一个动态 CVV 及动态验证码。但是由于卡组织和银行的疏漏，验证流程过于简单，主打一个让 D-PAN 什么都能走，于是便疏忽了这一点。目前暂且不清楚万事达是否也有相似的问题。 结论与结果 目前事件已有初步结果： 网关限制：Stripe 等 checkout 网关已限制通过 D-PAN 的放行，先不管银行是否做出决定，checkout 们已开始行动；Visa 网络已拒绝，虽尚未波及 Visa，但也加强了 D-PAN 限制。 支付冻结：中国银行正对活动中涉及的意外支付进行支付冻结。 风险加强：很多网关开启反欺诈类型，全网都在加强风险控制。 风险范围：此风险点不只存在于万事达，VISA 和 American Express 在部分银行也可能出现。 评价：本次各种加强和防护从某种角度算是一件好事。 不过这也确实说明了一个是这条链路上出现的问题，还有一个就是草台班子的普遍祝愿，以后这种情况减少发生 1 个帖子 - 1 位参与者 阅读完整话题

  • 情报分类：服务器与云资源
  • 分类依据：内容涉及服务器、云资源或网络线路
  • 信息来源：服务器 / LINUX DO - 最新话题
  • 发布时间：2026/9/27 16:15:31