移动金融业务外包开发中的安全风险

【前言：繁荣下的隐忧】

随着移动互联网时代的到来，大力发展移动金融业务、不断提高对传统服务的替代率已经成为商业银行等传统金融机构的重要战略。传统金融机构自身在移动领域技术储备不足的情况下，为了快速占领业务制高点往往会选择将系统外包开发。

以移动银行系统为例，开通相关业务的国有商业银行、全国性股份制商业银行和城市商业银行超过80%都是外包开发的。外包的引入推动了移动金融创新的步伐，快速打造了WAP手机银行、短信银行、APP手机银行、微信银行等系列产品，为用户提了丰富的移动金融服务。

需要警惕的是，尚无互联网安全经验的商业银行还没有充分认识到：移动金融盛世之下也正在孕育着一个新的巨大的黑产市场。

外包开发的移动金融应用在安全性方面存在巨大隐患：以笔者多年在安全企业的从业经验来看，外包的开发人员水平参差不齐，大部分外包开发人员在安全方面的技能和意识几乎可以忽略不计;外包商的信息安全管理水平也较差，甚至难以保障自身的安全性，更不要说交付的系统。

过去几年，业内很多安全团队都已经着手开始移动金融特别是移动银行方面的安全研究。事实证明，我们看到的安全现状比想象中的更加糟糕。在今年业内的几个安全会议中，笔者也分享过一些漏洞案例和测试结果。现在笔者把一些外包管理中的典型安全问题整理成文，供业界参考。同时也希望起到抛砖引玉的作用，请业内的大牛们不吝赐教。#p#

【案例一：图形验证码逻辑后门可导致大量用户账号被窃取】

案例概述

Y公司是一个已经上市的信息科技公司，国内多家商业银行都是其客户。我们在分析Y公司的移动银行产品时，发现产品的图形验证码机制存在逻辑后门可以被绕过，利用这个缺陷可以窃取大量用户账号。由于外包团队的代码复用，我们已经在至少两家商业银行的移动银行系统中复现了这个安全问题。

详细分析

我们来看看客户端的登录逻辑，似乎有一点奇怪的东西在里面：

仔细分析一下，这是登录时输入图形验证码的功能，开发人员出于某种需要在这里预留了一个万能验证码(被打了马赛克的四个字符)。正常的用户登录如验证码输入的不正确，系统会给出对应的提示。

如果我们使用预留的万能验证码，情况就不一样了。如下图所示，系统并没有提示登陆验证码错误，而是直接验证账号密码了。

利用这个缺陷，我们可以针对该商业银行所在地的用户进行大规模账号暴力破解攻击。一般来说，大部分用户都习惯将移动银行密码设置为六位数字，而且查询密码和交易密码也有很大的概率设置为相同的。攻击者可以查找该地区的手机号码段范围作为登录用户名，以六位数字组成的密码字典进行暴力破解，几十万移动银行帐户信息唾手可得。#p#

【案例二：调试接口未关闭导致用户敏感信息泄露】

1、案例概述

H公司也是一家上市的科技公司，其金融客户遍布全国，采用H公司移动银行方案的客户包 括至少两家全国性股份制商业银行和多家城市商业银行。笔者在分析H公司的移动银行产品安全性时，发现没有关闭服务端的调试接口，造成大量的用户敏感信息泄露。这种问题其实也比较常见，往往是外包开发完成后上线过程的疏忽造成的，实际上更常见的例子是Android客户端通过logcat输出调试信息的问题。

2、详细分析

移动银行作为电子银行的渠道，动账操作需要和银行的核心系统交互。H公司的开发团队为了方便开发和调试，在手机银行服务端代码中开放调试接口。该调试接口会将用户转账的详细信息输出到web目录的test.log文件中，如图5所示。攻击者可以通过浏览器直接访问到这个log文件，该系统的每一笔转账交易都记录在其中，从中可以获取大量的用户账号、手机号、卡号和交易密码等信息。

这个案例是否让你想起了携程泄露用户信用卡信息的安全事件?是的，如出一辙，只是在金融行业内这种安全事件一般是很少被曝光的。#p#

【案例三：开发商被渗透导致代码和客户端签名证书泄露】

1、案例概述

国内某漏洞平台曾经曝光过这样一个漏洞：某大型国有银行的移动银行ios客户端中存在一个txt文件，文件中存储了一个svn服务器的ip地址、用户名和密码，黑客解压出该文件获取信息后可以直接连上并checkout服务器上的文件。

2、详细分析

这个漏洞直到被平台公开细节后的很长一段时间内都没有彻底修复。在被曝光后数月时间内，该svn服务器一直没有修改泄露的帐户密码，也没有屏蔽互联网的访问。我们分析后发现这台服务器是外包开发商L公司的。L公司号称是专注于向银行提供手机银行全面解决方案和手机支付解决方案的高新技术企业，客户遍布全国。

该svn服务器上存储的内容简直超乎想象，包括该国有银行移动银行系统的全部项目文档、完整的Android和IOS客户端代码，甚至还存放了用于客户端签名的数字证书。下图是当时被曝光的部分数据的截图。利用这些数据信息，黑产从业者可以开发一个拥有该银行合法签名的移动银行木马，借助互联网资源下载网站、论坛甚至假基站等渠道传播。

【结束语：路漫漫其修远】

由于篇幅所限，笔者陈述的三个例子只是从几个侧面揭示了外包开发中存在的风险。在未来一段时间内，金融机构应该仍将会借助外包公司的力量快速建设和升级移动金融业务平台。笔者也赞同业务优先的原则，业务的停滞不前或倒退才是最大的安全风险，不能因噎废食。

但是移动金融毕竟涉及广大用户的个人隐私和资金安全，我们建议金融机构在外包开发的过程中关注如下信息安全风险：

1. 外包公司自身的安全管理水平较低、安全运维能力不足，会造成文档、代码甚至是签名证书等重要信息资产的泄露;

2. 外包公司员工安全技能和安全意识不足，开发的代码经常会存在各种安全漏洞，常见的如服务端任意文件下载、SQL注入、客户端组件暴漏和敏感信息泄露漏洞等;

3.外包开发的管理流程不够正规，投产时未关闭服务端或者客户端的调试接口，被黑客利用会造成不可估量的损失;

4. 外包开发人员故意留逻辑后门等。

针对以上的风险，我们建议金融机构强化如下的安全管理措施：

1. 选择外包商时，应对其安全管理和安全运维状况进行评估;

2. 规范外包开发的管理流程，金融机构的人员也要深度参与到开发过程中进行全过程的管控;

3. 加强对外包开发人员的安全意识和技能培训，将代码漏洞率等作为项目结项考评的要素;

4. 对外包开发的代码进行安全审计，特别是登录、转账等重要业务场景需要重点审计;

5. 建立针对移动金融业务系统的安全测试机制，完善和细化安全测试方法、测试用例，投产前进行严格的安全测试，上线后进行周期性测试;

6. 加强对异常交易的监控和分析。

最后打个小广告，除了平时对互联网金融安全的研究，腾讯安全平台部也招募互联网金融安全方面的岗位，欢迎有志从事互联网金融安全的同学加入我们。我们官方微博有发布相关信息，相信你能找得到。