网络安全 频道

移动金融客户端安全风险分析

  9月12日,乌云安全峰会,来自梆梆安全CTO陈彪带来了《移动金融客户端安全风险分析》主题演讲,以下是演讲全文:

  今天时间比较紧,我重点介绍一下我们提供的解决方案,主要就是梆梆加固的技术,梆梆有两代技术,1.0和2.0。安全评估大家都知道了,就是安全分析人员模拟黑客行为对你的系统进行模拟入侵。

  带手机端的话,基本有一个规范,就是中国人民银行的客户端软件的支付规范,这个里面就规定了客户软件应该怎么做?然后我们现在基本按照这个软件来做相应的安全评估。这里的话主要是用到的一些工具,如果做安卓开发的就非常清楚了。

  可能提一下XPOS,这个是当我们能够,就是装载这个框架之后我们只要写一个插件,这个方法能注入到任何WEB的程序里。比如一个银行给你一个LOGIN,我就能够用这个方法写个插件,直接截取到用户名和密码。

  根据这个我们做了安全评估,基本从这几个方面做的,第一方面,程序安全这个方面来做的,包括它一些安装卸载这部分,另外一个就是从代码安全,就是它是不是具备一定的防侏儒这些能力。另外我们检查所有数据的输入到数据的存储以及传输过程中是否存在安全风险?实际这块银行比较关注的。

  另外,我们在安卓上会暴露很多的组件,这些都会形成一些风险。当你弹出一个界面的时候,后台木马会弹出一个假的,把当前的覆盖掉,你在这个界面上输入的就会被后台的木马拿走了。

  我们可以检查通信安全和业务安全,我们现在做的POC基本能实现转帐,大部分银行客户端转帐过程都能篡改掉,通过侏儒代码方式,直接把客户端转帐的过程的交易修改掉。我们可以检查系统安全这块,就是说如果后台有一个木马,你的程序输入用户密码的时候,会被它直接拿到。

  下面我们做一些基本的测试,第一个就是反编译,基本来说这块就是我们的强项了,就是我们后面解决方案,重点是针对安卓反编译来做的。后面没有加固的话,通过反编译这个能拿到前部的原码,最后拿到服务器等算法都能拿到的。

  比如对某个金融客户端重打包,基本这种情况加上任意COAD都可以加入的,我们这个图里只是添加了一些广告的代码。还有一种,我们通过代码注入方式,注入新的COAD,注入进去之后能把这个客户端里所有敏感数据,我们想要拦截哪些敏感数据全部都能拿到。

  基本上来说,如果说一般金融应用开发客户端来说,它们没有做一些保护的话,在这几项上基本可以做到很容易攻击的。

  下面看一下它可能面临的风险,我归纳了几类:用户信息安全,交易的安全,二次打包的风险,有可能通过逆向发现移动端和服务器端的漏洞。像我们通常用手机银行的话会用软键盘输入密码的时候,很多时候软键盘在开发的时候,做的事情会发现,软键盘上只不过把界面掩盖了,但是在内存里你输入的用户密码一直存在的。

  简单的HOOK掉一些之后就能拿到用户名和密码。金融的客户端因为很多情况下是外包的,就是程序员开发的水平是有一些弱的,就是很多本地存储上根本就是会有很多问题,我们发现很多客户端在下面一些数据都是没有经过加密存储的。

  这个地方会有非常多的方式了,除了刚才那两种还会有像界面劫持,二次打包,这个就是重新打一个APK,比如说在你点确定的时候我把你的密码拿到。另外通过键盘劫持。这个比较有趣的,就是说我们发现某一个密码直接做输入法,这样的话你输入任何东西它都可以拿到的。

  另外,当用户做交易的时候实际上也可以被攻击道,这个例子就是我们做的简单的POC,左边这边是试图转给张三这个人,但是我们通过注入之后,直接修改网络函数,这样的话他在服务器中,就是把他的包改掉,在服务器端收到的就是要转给另外一个人,在这种情况下能够直接实现,把他的真个业务交易,转帐的过程修改掉。当然这些东西还是有很多,其他方面都可能存在攻击的风险。

  第三个风险就是二次打包。就是说二次打包把原来的程序重新分装一下发布到市场。目前来看,游戏这个领域当然是受二次打包比较严重的。像银行的话,我这里列出两个银行,有些银行基本7%的盗版率。

  二次打包以后通常会加一些恶意代码,比如加一些用户名窃取掉的代码,或者加一些恶意的病毒,我们知道在安卓上插一个包,这些病毒的可以通过其他的机子,你不需要点击你的APP,有可能这个病毒也可以工作了。

  另外,我们跟一些金融客户,评估它们客户端,发现他们很多的漏洞,这是乌云上报的漏洞,后面是我们发现的客户端代码的一些逻辑上的漏洞。就是说这个漏洞我们分析它的逆向代码以后,发现它的代码URL带一个参数,这个参数明显是一个数值,直接把这个数值往上加,就可以提到其他用户的信息。

  还有一些漏洞,这可能有点小,右边的这个漏洞就是说,这个客户端做的比较奇怪,转站的时候一般用双通道来通线,通过短信发一个平台密码给你,但是这个客户端还把这个密码发给了自己的客户端程序,就意味着只要截获网络的流量我就知道你的动态密码是什么了。

  上面主要讲的几个金融的风险,下面其实我重点想讲一下这方面的解决方案。我们认为如果你要开发一个真正相对来说安全的客户端,可能要做好几件事情,第一,你的开发人员应该遵循针对移动应用的规范,比如我们刚才讲的,只要我HOOK进去搜查内存就可以搜到所有用户密码,就是因为他存了用户密码。

  这个可以采用一些安全的组件,比如我们接触的一些客户,他们里面会采购一些软件ASK,会清场,通过做关键交易之前进行扫描,看机器上有没有安装相应的木马,可能还需要定期找一些专业公司跟客户端做一些安全评估。

  第二,我今天重点讲的应用加固。程序经过加固以后,要上线到渠道,但是这个时候其实你也需要监测,看市面上有没有出现对你这个包破解、钓鱼或者山寨的应用。安全加固应用刚才LBE张勇提到挺多,刚才跟他在私下里也交流了一下,他没有拿到我们第二代样本,第一代讲的跟张勇很想象的,就是我们拿到APK加固的时候,把它加密,然后放到APK的资源中去,通过运行的时候修改这个程序的入口,让程序的入口先执行脱壳代码,脱壳代码执行完以后交给真正解完密的代码。

  我们在里面会增加一个文件。有一个人对我们进行了分析,他也指出了一个弱点,我们在内存里面是有一个明文的区域的。刚才张勇帮我介绍很多,第一代的问题,不论你怎么做你很难组成大团。我知道爱加密之前会抹掉ADESK,然后针对360最近的,我们最近拿到的一些样本,我们发现360加固的时候,因为有百度脱壳工具,360检查了SPOSE存不存在,如果存在这个程序就不运行。

  这个方法有很多了,从我们角度来看,这些方法都是治标不治本的措施,就是你永远无法从本质上解决内存的下载。我们现在给金融客户,包括一些银行的他们在采用,还有游戏客户在采用,真正使用的是第二代的加固技术,这块技术利用了JAVA里有一个特性,JAVA语言在执行的时候并不像C,我们可以对比C1和JAVA加固的应用,像苹果的也做了加密,但是C程序直接跳转到那个地址去执行代码,所以很多的像C的加壳,或者针对非编语言加壳的话要把所有语言解开,然后跳过去执行。

  我们知道JAVA有一个特点,它执行某个方法的时候,你这个方法可以现在暂时不存在,它可以通过CLOAD去找这个方法,找到以后做去执行。我们第二代是从整个DESK级别降到方法级别,也就是每个方法我们是单独加密的。当这个方法被虚拟机调用到的时候我们才会按需地去解密,同时我们会保证这个虚拟机在内存,这个解密后的COAD在内存里是不连续的。

  另外,我们目前正在加的一些相关的安全措施,比如说会加一些,因为你可以说是我试图重新再内存再构造这个东西,但是这个方法是没有解密的,你只有强制的办法去让我把你所有的方法都解出来,或者修改虚拟机,无非就是加一些方法去处理这些东西。这种我称为方法替换方式。

  当虚拟机执行某个方法的时候,这个引擎,我们的加固引擎只解这个方法,只有的话,比如说在我们这个基础上,加固起来以后,在内存里面有可能只有不到四分之一的代码被解开了,还有四分之三的代码实际上是没有不解开的,你只有点,点到了全部路径后才可能被解开,我想这也比较困难。

  这是我们现在推出的,就是给客户用的,我们现在还在做第三代的技术,这是基于代码,指令的替换,就是带内存跑的方法的代码,实际上是被我替换过的,而不是真正的原始的代码,你拿到这个代码以后,你还得需要知道我怎么映射这些OPCOAD。

  你们发现某个APK里面,看到里面全是空窗版的,基本上是经过我们处理过的架构。这个方法也不需要有什么DEX,就是所有的启动到正常运行的过程中,你通过DEX下载,永远跟你在ADK拿到的Classes Dex是一样的。因为我们做的比较早,所以有些客户并不是对JAVA保护很K,因为我们知道很多的编程框架,像游戏厂商,代码都放在一个里面,我们对这些代码都可以做相关的保护。

  这个用法是一般的厂商告诉我们,你要加密哪些文件,APK有哪些文件我们可以给他做。APK文件所有密钥的,就是布局文件全部都加密了。也就是说,这个的防御,比如这种包你单纯拿到了Classes Dex你是拼不回去的,因为那些资源全部经过加密,所以你拿到JAVA层面是没有太大用处的。

  这块是我们现在给企业基本上都是采用这套方案的。我们也做企业的SO库,我们也有比较成熟的方案。这块如果说你想做APK特别强劲的话,我们基本上可以把这个APK所有文件做加密,除了系统原来的图标。现在我们给一些银行,如果它采用了ATM的框架我们都会做成ATM5加密。

  提一下渠道监控,对银行我们也可以提供这样的服务,这个服务我们会提供一个爬虫,这是到市场上抓第三方的应用程序。通过加速度的分析引擎,这个能够分析出两个APK之间是否相似,我们现在有几个大的引擎,就是说基本信息,像图标或者你的名字,因为我们知道有很多的应用,它就纯粹钓鱼的,我们甚至有一个银行的客户出现过这种情况,它的APP还没开发完也没有上线,但是市面上已经有叫这个名字的APP存在了。

  所以基本信息比较我们就能发现出相似的山寨后的,直接是钓鱼的APP。另外它在你包的基础上修改的话,它大部分的资源跟你是基本接近的。也就是说我们通过资源也能够比较出两个APK是否相似的。

  最后就是代码纯粹的比较,因为相信代码破解的话,也就是往里面加一个包,真正修改或者在入口的地方修改一下,然后通过代码相似度也能够比较出来,通过这个引擎我们也可以及时关注银行或者金融的程序是否有山寨或者盗版。

  总结一下,目前对像手机银行可能面临的这些安全风险,所以我们一般跟客户谈的时候,首先加强客户端开发人员的培训,就是开发的时候考虑到很多安全的问题,然后我们可能会跟一些合作厂商定期的对这些移动的客户端进行评估,评估完了以后我们希望他们使用一些加固,这样的话阻止别人山寨,上线之后我们还要实现监控,看是否出现山寨、钓鱼或者直接盗版的情况。

0
相关文章