【KEEN 联合创始人 宋宇昊】
这世上的骗局，到底谁买单？
随着移动支付的普及，我们的生活变得越来越便利。我们甚至已经可以不带钱包、现金、银行卡出门，只用手机就能完成吃饭、娱乐、交通、购物的支付。
平时我们一讲到支付安全，大家最容易想到的就是钓鱼、诈骗、木马。确实，钓鱼、诈骗和木马是支付领域最常见犯罪手段，它的犯罪成本低、易于实施。他们其实属于社会工程攻击的范畴，犯罪者一般先通过各种方式获取受害者的信息，比如联系方式、甚至可能是受害者的个人隐私信息，然后犯罪者利用受害者心理弱点进行欺诈，诱使他们做一些操作。例如洗钱调查开安全账户、家人生病、来看看我们的照片等等都是常见的欺诈手段。最近几天被广泛传播的《为什么一条短信就能骗走我所有的财产？》文章中讲的也是一种诈骗手段。
所有欺诈手段的共同点是，犯罪者都要诱使受害者犯错，只有受害者执行了错误的操作才能够让犯罪者得逞。那么是不是只要用户保持清醒的头脑不受骗上当就安全了呢？
答案是否定的。除了用户有犯错的机会，产品厂商的设计者、开发者也会犯错，他们犯的错误也可能导致用户财产受到犯罪者的侵害，当然也可能导致厂商自己受侵害。大家都知道开发者写代码出错，那叫Bug。而如果正好有某个Bug不巧，能够被攻击者利用，在没有被授权的情况下访问或者破坏系统，那这个Bug就叫做漏洞。
有些人会把这类攻击者叫做黑客，但我这儿为了避免混淆不这么称呼，因为在不同场合下黑客有不同含义。有时候，黑客被认为是利用技术研究成果实施计算机犯罪的人，这类人也被叫做黑帽黑客；有时候，黑客是指那些把研究成果用于帮助厂商改进产品，帮助保护用户安全的人，这类叫做白帽黑客。
白帽子们会在各种渠道，例如 GeekPwn 这样的平台上分享并展示出自己的研究成果，然后我们将这些成果提供给厂商，以帮助他们提升产品安全。正因如此，这些案例中的漏洞并没有被用于犯罪行为中，而是被厂商及时地修复了。今天我们就来看看我们能从中吸取到些什么经验和教训。
消费型App存在哪些问题？
所谓消费型APP是指所有能在其中进行充值、购物、购买服务等等消费行为的APP。在这个案例中，是一个O2O提供线下服务的APP，用户可以在APP中充值余额。然而一个恶意的用户可以做到在APP中充值任意多的钱，实际却只支付1分钱或其他任意金额。这个场景中的受害者是这个APP服务的提供商。
那么这个任意占厂商便宜的漏洞是怎么产生的呢？在分析原因前，我们先看一下攻击的流程。
这个场景中有手机APP、支付平台、APP服务端三方。根据厂商的设想，他们预期的是这样的支付流程，我们看下图的左侧：
1、手机APP首先生成了一个100元的充值订单发送给APP服务端；
2、用户获得一个支付链接，依据链接向支付平台支付100元；
3、支付平台会向APP服务端发送消息，说某个订单成功支付了100元；
4、APP服务端收到消息，检查是否支付成功，如成功就往账户余额中增加100元。
这个流程问题在哪儿呢？我们看刚才那幅图的右侧：
如果这个APP用户并不是一个老实的用户，他并没有按照订单返回的支付信息支付100元，而是把它修改为支付0.01元，并且完成支付。在这个情况下，APP服务端同样会收到支付平台发来的消息，说某个订单成功支付了0.01元。然而APP服务端却并不管实际支付了多少钱，只关心这个订单支付成功了，并且按照订单金额给账户中充值了100元。这样用户就成功地坑了APP厂商99.99元。
导致这个问题的原因是什么呢？是一个APP服务端的漏洞，APP服务端没有遵循支付平台的API文档标准，对支付平台回调的支付结果信息做充分的校验。
二维码支付存在哪些问题？
我相信大多数朋友都用过二维码支付，在实体店铺中展示二维码，扫一下就能完成支付，非常方便。我们这就来看一下二维码扫码支付的漏洞案例。在这个案例中，攻击者到任意实体店铺进行消费，以二维码方式支付，但却从受害者的账户中扣费。这里的受害者可以是任何一个在这个支付平台上注册过的用户。在分析原因前，我们先来看一下攻击流程。
这个场景中有用户、实体店铺和支付平台三方。根据支付厂商的设想，预期这样的支付流程：
用户Alice点开扫码支付，这时候支付客户端会向支付平台服务端请求一个二维码，假设这里请求的AccountNo叫Alice，这样支付平台服务端就会返回一个二维码，这个二维码对应于Alice的账户，并且只能用一次，这就相当于一个支付令牌。
店铺的二维码扫描枪扫了一下这个二维码，店铺就获得了这个支付令牌，它就可以从Alice的账号中扣款了。然而有个叫Chuck的恶意用户，它在向服务端请求支付二维码的时候，在AccountNo当中填入了Bob，而不是他自己的账户Chuck，这时候店铺虽然扫描了Chuck手机上的二维码，但实际上会从Bob账户中扣款。
手机POS机存在哪些问题？
很多小店铺或者私营业主使用手机收款POS机来进行收费，这为刷卡消费提供了很多便利。在这个案例中，消费者到一家店铺的POS机上进行刷卡消费。然而在消费者刷卡完成离开店铺之后，恶意的POS机收款方虽然并没有拿到消费者的银行卡和银行卡密码，但依然可以从消费者的卡中扣除任意金额的资金，转到自己账户中。分析原因前，我们先来看一下演示视频。
【视频链接戳这】
这个视频是我们GeekPwn和央视在315晚会上合作的一个短片，短片展示了之前描述的POS问题的案例。在视频中，恶意的POS持有者在刷卡者刷卡消费完成之后，随便拿了一张便利店的会员积分卡，输入任意密码就刷走了之前刷卡者银行卡里的钱。在这里刷便利店的磁条卡和输入任意密码仅仅是为了触发刷卡支付的相应步骤。由于315晚会时间的限制，短片没能细致地解释这个盗刷流程，因此不少观众以为演示的是复制磁条卡的问题，其实这个案例比复制磁条卡更进一步。在刷卡消费过程中，需要两个要素，一是磁卡，二是磁卡的支付密码，缺一不可。因此如果只是复制磁卡，那么还需要额外获得磁卡的密码。在这个案例中，受害者刷卡消费时，刷真实的卡，输入正确的密码，在收款客户端中生成了一个扣款的令牌。然而这个扣款令牌并没有实现一次一密，在刷卡完成后并没有作废，因此恶意的POS持有者就可以从手机内存中取出这个令牌，反复使用反复扣费。所以说，导致这个案例的原因，是支付平台的POS支付协议的漏洞。
指纹支付存在哪些问题？
如果你的手机忘了锁屏，放桌上被人拿走了，钱会被偷走吗？你可能会想：“应该没法转走钱吧，毕竟支付的时候还需要再验证一次。更何况我设置了指纹验证，比支付密码更安全。”大多数时候确实如此，但是如果这里有漏洞，那就不是这样了。这个案例展示了攻击者拿到一台已经解锁屏幕的手机，绕过指纹验证进行支付的场景，受害者当然是手机被拿走的那个人。在分析原因前，我们先看一下攻击流程。
按照正常的指纹支付流程，APP在受到支付请求时会要求验证，让指纹驱动提供相应账户的身份认证信息，比如说需要Alice用户的身份信息。如果这时候是Alice本人在操作，那么指纹驱动控制硬件读取Alice的指纹，并且跟之前登记的Alice的指纹进行特征比对。如果匹配成功，那么指纹驱动就会将Alice的身份认证信息提供给APP，APP就可以继续支付流程。然而在这个案例中的这款手机里，指纹驱动有漏洞，它允许普通用户开启它的调试模式。而在打开调试模式的情况下，它不会再校验指纹，不论刷什么人的指纹，它都将向APP提供手机中登记的身份认证信息。因此，无论谁只要能插上USB线调试这台手机，就能完成支付流程。
我们很容易理解的是，谁犯的错误就应该由谁来避免或纠正。对于钓鱼诈骗这类的威胁，是基于用户的上当受骗而实施的犯罪，这时我们通常需要教育用户，以免用户上当受骗。而对于漏洞威胁，是基于产品厂商的设计者、开发者所犯的错误，那么当然主要就应该由厂商来担负起应对威胁的责任。
对于厂商，有些普适性的建议措施，比如：采用HTTPS等加密协议保护所有的通讯，尽快把磁条卡换成芯片卡等。除此之外，还需要针对性的措施，比如：修复掉所有被发现的漏洞。
每一次漏洞被发现被修复的过程，代价都是高昂的，对于厂商而言，更经济的做法是在产品设计初期或开发过程中就能够提升产品的安全性，这就需要增加设计与开发人员的安全教育，提升安全意识，并且在设计架构、设计协议、开发程序的过程中，引入安全开发流程。这样可以尽可能地减少产品中的漏洞，把漏洞消灭在萌芽阶段，从而减少安全应急的成本。
（演讲到此结束，以下节选2个精彩问答分享）
精彩问答：
1、问：由于线上支付的场景非常多，消费型App校验漏洞、二维码支付协议漏洞，这种越权提取漏洞是否普遍存在？目前我们是否需要避免这类交易呢？
宋宇昊：根据我们的观察，相当多的消费型APP厂商是成长型的中小公司，产品也处于发展初期，因此漏洞相对较多。而支付平台的厂商一般都是大公司，产品相对比较成熟，这类危害严重的漏洞也就并不普遍了。软硬件产品中的漏洞不可避免，作为消费者而言，不必过于恐慌，因噎废食。
可以从两方面考虑这个问题：
一方面从技术角度，考察监督一下厂商的产品是否持续性地暴露出低级错误高危漏洞、厂商是否及时修复被披露的漏洞；
另外从非技术角度，考察厂商是否有政策保障赔付用户的意外损失，并且是否有能力赔付。
2、问：今天提到的攻击方式，很多都带有定向攻击的属性，例如：要针对某个消费型App写充值攻击代码，或者需要拿到被害人的手机，这些都会提高黑客的攻击成本，如何来理解攻击成本和这些攻击成真的可能性之间的关系呢？
攻击成本确实是一个需要考虑的问题：
对于每一个漏洞而言，都需要编写和使用专门针对性的攻击代码进行攻击，攻击成本远远高于批量群发的欺诈信息；
产品漏洞对于厂商而言是可控的（相较于可能受骗的各种用户而言），一旦攻击被厂商知晓，漏洞就会被修复，攻击者也就无法继续利用该漏洞。
