远程开个户，我怎么隔空被黑产偷走了银行卡

江湖天籁

世界上最远的距离不是 520 我站在你面前，你没有发红包给我，而是你拿着一张百夫长黑金卡，而我，拿着一张每月余额艰难在正负间挣扎的银行卡。



银行卡怎么了？谁还没有么？

有，现在远程开户就能办理。

不仅是银行卡，电话卡、社保卡等也都可以远程办理。

呵，就算拥有的余额一言难尽，还是有人盯上我的银行卡，不过背后黑手的目标并不是简简单单这张“银行卡”。

今天，宅客频道编辑与梆梆安全的高级安全顾问赵千里聊了聊，揭秘背后黑手如何在你远程开户的过程中搞小动作，他们的目的又是什么。

忧伤的金融业


以银行卡开户为例。

话说现在的银行储蓄卡基本分为三类：一类卡、二类卡、三类卡。

1.持有数量不同

一类卡一个银行只可以有一张；

二类、三类卡不限制。

2.交易限额不同

一类卡没有限额；

二类卡非绑定账户转入资金、存入现金日累计限额合计为1万元，年累计限额合计为20万元等。

三类卡余额不得超过1000元；非绑定账户资金转入日累计限额为5000元，年累计限额为10万元等。

在银行的操作中，一类卡开户必须用户到银行现场开户，但是二、三类卡可以远程开户。

远程开户的中心要义是：证明我是我，还要证明我是合法的我。

具体操作步骤是，先通过手机卡和对应的验证码通过第一层验证，再上传身份证的正反面信息，通过人脸识别通的验证，接着关联一类银行卡账号，最后，填写个人信息、电子签名等完成开户。


［图片来源：央视新闻］

看上去这些步骤都很简单，而且大大节约了去银行窗口现场开卡的时间，但是有很多安全风险，可以直接造成几类后果：

1.在银行搞活动时，批量开卡薅羊毛，套取现金；

2.利用第三方支付平台漏洞，用虚假账号盗取资金；

3.有些人向黑产贩卖虚假账户的信息，自己搞一把虚假账号，又通过黑产来贩卖做好的虚假账号的信息，实现“完美闭环”；

4.通过虚假的账号信息实施诈骗、洗钱等非法活动。

总之一句话，搞钱，干坏事。

黑产的 N 个诡计


我们来看看黑产的招数：

第一招，偷梁换柱。

攻击者想用别人的身份信息注册，但手里没有别人的手机卡，得不到验证码，怎么办？他想到了一招——自己找一个170号段的非实名制手机号接收短信，通过第一关。

但是，问题来了，这个170的手机号也不是别人的真手机号，他是怎么蒙混过关的？

原来，最终提交的数据是非法手机号，服务端验证会出错，但是攻击者将提交验证的数据劫持并将手机号改成了别人的真手机号。



第二招，临门一脚截胡。

攻击者上传假照片，虚假手机验证码等，虽然这些验证环节均失败，但是在最后后台结果返回时，篡改结果，由于这几项信息没有连接起来统一认证，服务端认为“结果对”则“程序对”，前面一系列认证都算通过。



第三招，谁真谁假？

攻击者用真实信息开户，真实信息开户上传到服务端时，服务端明确信息没有问题，返回的数据允许正常开户，你以为他要开具一张真卡？错，攻击者把服务端发回的数据包改成验证失败，客户端拿到服务端验证失败的结果后选择再提交一次，由于客户端身份已经被认可，服务端会接受后续客户端发送的数据，这时攻击者通过篡改的方式提交一次虚假信息，就能实现使用虚假信息的虚假开户。



第四招，搞定客户端。

攻击者直接破解客户端的源码，篡改运行中的业务数据，实现虚假开户。

第五招，见招拆招。

由于身份证识别系统和一些人脸识别系统存在缺陷，攻击者可以通过身份证生成器、PS 照片通过验证。

运营商发现了蛛丝马迹


攻击者“隔空”截胡银行卡手段这么多，搞起运营商来也不含糊。

赵千里说，运营商的渠道商，包括虚拟运营商可通过实名制远程开卡，有专门的开卡设备。在一次监测中，他发现运营商在实名开卡中，服务端暴露了异常开卡的信息，运营商的 POS 系统显示，客户端存在虚假设备、虚假地理位置和虚假身份证。

攻击者是如何暴露的？

比如，开卡的时间间隔很短，十秒钟来一个。



业务日志里也存在蛛丝马迹，安全研究员发现，数据中缺少一些正常的手机字段，比如设备识别信息、IMEI、OS info、安卓 ID 等，基本可以判断是模拟器开的卡。

员工在 A 地，却频繁在 B 地开卡等。



攻击者展开了“钓鱼”的骚操作，他们首先提供了真实的个人信息，利用这些个人信息实现了虚假身份证的制作，然后使用模拟器攻击框架，破解客户端，获得内存数据，或者利用通讯协议对数据进行批量的篡改。这些数据传到服务端时，服务端通常照单全收，N 个假账户出来了。

几个防范招式


宅客频道发现，判断一个客户端行不行，也许就跟找对象一样复杂。

第一，要考察对象自身的人品——这个终端是否安全可靠。

第二，他都跟什么人来往——终端所处的环境是否可以信任？

赵千里说，需要检测运行过程，防止动态注入。防止内存数据被篡改，判定运行环境中是否存在模拟器、攻击框架，以及代理是否被截获。

通过历史运行数据判定运行环境是否在合理的范围内，比如是否有地理位置欺诈，还要防止代码被反编译，逻辑被暴露，同时也要通过渗透测试这样的手段来明确业务中存在的安全风险，及时修复。

比如，他曾遇到一个这样的案例——一家电商 App 的业务逻辑被人发现了。

“你能输出的金额是一块钱到 9999，你下个单，后台的服务器不会验证你发过来的金额。如果这件商品的正常价格就是 98 元，后台只要提交数据，不会再次验证金额，就会直接给你发货。”赵千里对宅客频道说。

你以为攻击者会改成 1 块钱尝试性付款吗？

不！1块钱都不会给你。

攻击者破解 App 后，找到了客户端到服务端的接口，然后制作一个假客户端，登陆账号，把值改成了“-1”。

什么，还倒欠人一块钱？？？

原来，很多字段定义时，不能识别“-1”。而有时数据库定义字段时，“-1”等于最大数，攻击者输入“-1”后获得了 9999 的购买力。

“但是电商在做这个 App 时，首先不会考虑这个问题，它没有考虑到攻击者攻破App 后手动生成了一条交易，所以核心点是，它最初认为移动端是可信的，现在发现不可信后，就需要基于客户端不可信的情况做监管手段。”赵千里说。