这是一个创建于 485 天前的主题，其中的信息可能已经有所发展或是发生改变。
这个事关注的人挺多的，我只是发了个帖子描述事情经过，没想到得到各位大牛的鼎力相助，评论里有大牛分析出双重认证是怎么绕过的，有的帮忙破解这个应用的后台查数据的，还有帮我扫描域名信息提供资料的，帮我转发到其他平台的，在这里向各位说一声谢谢，也感谢 V2EX 提供这样一个平台可以让我发声。
绕过双重认证
原贴中关于如何绕过双重认证，有一些描述不太准确，虽然我补充到后面了，但还是有一定的误导，导致大家都在关注钓鱼的密码框。
因此我把帖子下沉了，在这个帖子里详细说一下原理，有些步骤我无法实践，是通过结果倒推的。
第一步 登录 Apple ID 页面
这一步很多人都没意识到，是在 App 里内置了一个隐藏的 WebView 访问 appleid.apple.com/sign-in，由于是在受害者自己的设备上，弹窗出来之后人脸识别就登录了，很多人包括我自己对这个弹窗没那么敏感，根本没有意识到是在登录 Apple ID 的管理后台。
提供两个对比视频，过程是一样的，最终都是登录到了 Apple ID 的管理后台。
一个是用内置的 Safari 登录。
https://www.bilibili.com/video/BV1d841117Lv/?share_source=copy_web&vd_source=172f1dea4092d685cfef2703eaabfd08
一个是用 App 内置的 WebView 登录，这个 WebView 还可以隐藏。
视频是由微博大佬 BugOS 技术组 提供的。
https://www.bilibili.com/video/BV1Nj41197A5/?share_source=copy_web&vd_source=172f1dea4092d685cfef2703eaabfd08
第二步 获取密码
通过伪造的密码输入框钓鱼，诱导受害者输入密码，这一步大家都比较清楚，我就不附图了。
第三步 获得 Cookie
这一步是通过大牛破解了对方的后台，有 Cookie 相关的配置以及记录，我猜测的。
在第一步的 WebView 登录之后，就可以通过注入 JavaScript 获取到 Cookie ，有了 Cookie 之后，就可以给 appleid.apple.com 的后台 API 发起 HTTP 请求了。
第四步 接收验证码
这一步有一个自动接收验证码并保存下来的服务即可，这个应该不太难。
第四步 添加信任号码
Apple ID 管理页面的地址是 appleid.apple.com/account/manage，在这个页面可以添加一个双重认证的信任号码。
拿第二步的密码、第三步的 Cookie 、第四步的验证码，就可以模拟添加信任号码的 API ，发起 HTTP 请求，添加一个新的号码。
至此，所有的操作都在受害者本机完成，不会触发双重认证，事后我查看了家人的邮箱，第一封被盗相关的邮件内容也是通知她有一个新的信任号码加入了 Apple ID 。
我认为整个事件确实有人为疏忽的问题，但是双重认证不就是为了避免这些疏忽，才有的最后一道防线的么，而通过这种手段添加双重认证号码竟然不需要再次认证，导致这个机制直接被绕过了，这才是最严重的问题。
后续
苹果的退款基本不太可能了，我已经尝试了所有的渠道，警察那边我提供了 App 、域名等资料，但是后面再联系就不回我了，感觉他们也不太相管，因此我只有一条路就是起诉了，接下来就是整理各种证据找律师了，如果这件事还有后续的话，我再更新吧，谢谢大家关注。
第 1 条附言 · 2023-07-27 18:50:52 +08:00
最近情况：苹果刚刚把我家人的所有被盗订单都退款了，但是还没有跟我联系，感谢大家的支持。
 |
1
billlee 2023-07-25 21:34:32 +08:00  6
iOS 这个设计真是离谱，如果 webview 能被 app 控制，那就应该视为是 app 的一部分，和系统 webview 完全隔离。不能把对系统的信任延伸到 webview 上。
|
 |
2
cwyalpha 2023-07-25 21:42:32 +08:00 via iPhone 1
苹果没有协助警察断支付渠道么
|
 |
3
mineralsalt 2023-07-25 21:45:01 +08:00
这个技术含量太高了, 就算媒体转发了也没有什么热度, 普通人根本就不懂这些, 也不愿意去了解. 也就只能在 V2EX 可以引起关注了
|
 |
4
tediorelee 2023-07-25 22:21:36 +08:00
马克一下，关注
|
 |
5
PhDLuffy 2023-07-26 02:41:49 +08:00
第四步接收验证码不就是 MFA 验证？
首先会弹出 ip 地址验证，有地图地点显示确认， 确认异地登录之后才会显示 6 位密码，而且这 6 位密码是系统级，怎么被截屏获取的呢？ app 有这么大的权限么？ |
 |
6
yfwo 2023-07-26 05:12:08 +08:00 2
@billlee 嘿嘿，就是离谱。而且现在被用于诈骗了，说明之前早就被用于更值钱、更敏感的间谍、信息战、商战等活动，毕竟很多人会同步 iCould 照片。
@mineralsalt 差评公众号 发了文章，开头有个图展示了的 9 个不同的骗子 App ，都名为“菜谱大全”，却没有一个是正经菜谱，全部上架了 App Store 。可见 App Store 审核非常垃圾。 |
 |
7
terence4444 2023-07-26 05:39:12 +08:00 via iPhone
@PhDLuffy 本机登录是没有 2FA 验证码的，APP 里嵌套了个浏览器用脚本控制登录。
|
 |
8
rshun 2023-07-26 08:33:57 +08:00
接收验证码不应该是发短信或者在受信设备上弹窗吗？ 我很好奇这是如何获取验证码的
|
 |
9
ajyz 2023-07-26 08:42:17 +08:00 via iPhone 1
其实这种情况，在本机操作，即便有弹窗二次验证一样中招，更应该值得诟病的应该是 App Store 怎么会有这种 app 上架，这才是问题的根本。应该以此向苹果索赔。
|
 |
10
V392920 2023-07-26 09:05:08 +08:00
同问,OP 说的第四步没怎么看懂,是接收什么验证码?不是说在本机不会弹 2FA 吗?
|
|
11
V392920 2023-07-26 09:08:40 +08:00
@V392920 回复自己的疑问,通过看原贴,OP 说的第四步应该是指添加信任手机号时,新添加的手机号需要接收验证码,攻击者搭建一个自动接收手机号验证码的服务
|
 |
12
TSYGFQ 2023-07-26 09:33:50 +08:00 via Android
蹲一个后续
|
|
13
PhDLuffy 2023-07-26 11:00:44 +08:00
@V392920 新添加手机号，你所有的登录同一个 icloud 账号的设备都会系统级弹窗显示某个手机号哪个设备新添加了，就这还引不起注意么？
我特别好奇的还是它怎么就在某个异地设备上越过 mfa 添加手机号？就我所知，不太可能。除非人主动给与 mfa 验证码 |
 |
14
xzsjWang 2023-07-26 11:29:17 +08:00
感觉问题应该是谁能浮现？不用上架，就自己签名一个试试能否走通？否则我还是不太相信。
感觉还有一个因素不能轻易放过那就是「人为因素」，听 OP 说已经跟家人反复核实，但是不排除着急的情况下忘了，或者大脑紧张的时候给自动模糊记忆了。 |
 |
18
X26U68jE5Q6D0ih0 2023-07-26 11:52:34 +08:00
感觉苹果可能知道了, 但是如果给楼主开了退款先例, 之前的所有损失只要找都需要退款, 但钱早就套走了, 苹果不想承担
|
 |
19
akaraccoon 2023-07-26 12:00:59 +08:00
经过我实际测试，在绑定了实体安全密钥并开启双重验证的的 iphone 设备，在面对这种钓鱼的时候，也失去了作用。完全不需要 2fa ，只需扫脸和密码就可以登陆 id 管理页面并添加新的安全手机号。
|
 |
20
Zheming 2023-07-26 12:03:11 +08:00 via iPhone
我的推测，诱导成功的核心在于，网页端添加两步验证手机号，可以通过短信验证码的形式进行，而短信验证码会在输入法上方有个快速输入框，有些人没有防备以为是注册 app 的验证码，没仔细看就写进去了，自然就攻破了这一道防线
|
|
21
akaraccoon 2023-07-26 12:07:22 +08:00
@Zheming 不是的。我测试过了已经。这种钓鱼模式，苹果压根就不会给你发短信验证码/或者信任设备上的验证码/以及 yubikey 密钥，统统不需要。直接跳过了。苹果的双重认证说明里明确说明了 在新设备或者网页登录时候需要以上三种的 2fa,但是实际上在本机 iphone 上登录时，以上三种都跳过了。就是说对本机的信任度是极高极高的。！！
|
 |
22
Nitroethane 2023-07-26 12:22:38 +08:00
第三步「获得 Cookie 」，如果 appleid.apple.com 的 Cookie 设置了 HttpOnly 的话是不能通过 JS 拿到的，你看看 appleid.apple.com 的 Cookie 有没有设置这个。
|
 |
23
Chad0000 2023-07-26 12:25:35 +08:00 via iPhone
@akaraccoon
主要是“对本机的信任延伸到了 webview 上”，如一楼所说。而 app 能完全控制 webview ，就没有安全可言。只要作恶的诱导用户在本机 app 的 webview 登陆就彻底失防。 |
 |
24
leonshaw 2023-07-26 13:16:21 +08:00 via Android
1 楼说的对
|
 |
26
yinmin 2023-07-26 15:57:23 +08:00 via iPhone
@airycanon 微信操作：我 - 服务 - 钱包 - 消费者保护 - 安全保障 - 百万保障 - 资金被盗申赔 - 账单有被盗交易，然后选择被盗交易提起索赔。
|
 |
27
airycanon OP @yinmin 微信支付没试过，但是从它的描述看，只支持微信账号被盗的索赔，我这种情况可能不行，我试一下，感谢提醒。
|
 |
28
tin3w5 2023-07-26 16:25:05 +08:00
@akaraccoon 不知道是否能通过 profile 的方式强制要求即使在本机也必须 2FA ？
当然，就像 @Chad0000 说的，如果不能做到让 webview 在 app 之间隔离，那安全只能是伪命题。 |
 |
29
ff8 2023-07-26 16:38:56 +08:00
微信端应该不会理赔。微信端只知道频繁多次多笔 AppStore 扣款这一个点。至于扣款的设备，扣款的商品微信都不知道，无法触发微信支付风控。
|
 |
30
Danswerme 2023-07-26 16:55:06 +08:00
@Nitroethane 我看了 appleid.apple.com 的 cookie ， 绝大部分 都是 httpOnly 的，非 httpOnly 的几个 cookie 看起来也和登录状态无关。WebView 插入的 JS 应该也是遵循 httpOnly 无法获取到 cookie ， 但是 iOS 上 WKHTTPCookieStore 提供了获取所有 cookie 的能力。
https://developer.apple.com/documentation/webkit/wkhttpcookiestore/2882005-getallcookies |
|
31
Danswerme 2023-07-26 16:59:39 +08:00
楼主原帖 283 楼有人贴出了相关代码，可以看出是使用 uniapp 编写的，关键代码是 plus.navigator.getCookie("https://appleid.apple.com") ，plus.navigator.getCookie 是 html5plus 提供的能力。
https://www.html5plus.org/doc/zh_cn/navigator.html |
 |
32
explore365 2023-07-26 17:09:26 +08:00
逻辑漏洞，苹果应该限制通过 webview 访问 appleid.apple.com 的 App 白名单。
|
 |
33
oovveeaarr 2023-07-27 00:19:49 +08:00
说一句题外话，苹果是强制要求使用 In App Browser 的。。。
|
 |
34
quotationm 2023-07-27 09:21:39 +08:00
@billlee 前段时间支付宝的 webview 不是也出过问题吗，不知道后续怎么样了，这些标榜安全的公司怎么回事，骗子都跑到家里拉屎了
|
 |
35
777777 2023-07-27 11:21:24 +08:00
https://support.apple.com/zh-cn/HT213841 感觉是利用了 iOS 16.6 修复的漏洞，webkit 有好多任意代码执行和一个信息泄露。如果是真的楼主可以用苹果存在漏洞进行索赔。（总有人跟我杠 ios 安全，ps：我用的也是 iPhone ）
|
Select Language