地方商业银行APP安全性分析

0x00、业务需求

国内133家地方商业银行作为商业领域国外IT厂商和商家必争之地,无论是IT基础设施建设、容灾备份系统建设、还是信息安全建设等,各家银行都做的如火如荼,当然,目前只针对企业级市场,很少有银行愿意接受安全众测,原因很简单,测试过程不可控。

但是IT环境变化的加速度在不断的增快,面临目前严重的安全态势,希望银行也能接受众测这种商业模式,或者由众测小伙伴把自己的测试经验写成PoC代码的形式share给厂商。

测试对象:133家商业银行

0x01、测试流程方法

针对银行的业务接口,为了适应目前移动互联网业务需求,各个地方商业都相继推出了自家的银行App。但是对于这种新的商业模式和业务接口,你们的App安全做好接受国内上万白帽子的众测的准备了么?

对于银行类目前有相关业务审核标准。银联的移动终端支付应用软件安全规范应该算是其中之一。

那么,针对上述宽泛的规定,需要具体化App测试方向。

下面我以北京银行android客户端为例进行分析。

No.1、源代码安全

(1)、反编译源码

首先通过Android killer反编译 bob.apk

在编译的过程中出现多次报错。同时,android killer没有识别到是哪家APP加固程序(以前分析其他工程的时候 可以识别梆梆安全、爱加密)所以,只能考虑其他办法识别,那么,加固的核心是处理dex文件,那好,进入虚拟机中找到com.rytong.bankbj的libDexhelper.so文件,看看有什么特征关键字没?

通过nox_adb.exe pull /data/app-lib/com.rytong.bankbj-1/libDexHelper.so 导入到本地IDA Pro中查看。

很明显是阿里云的APP加固(aliyun)。 目前没有很好的脱壳工具,,只能是看有限的java和smali代码。来分析银行业务流程,当然,你可以直接调用这个lib中的方法直接解原始dex,不过需要研究其参数等,还有人家存在的一些防盗机制。(随着分析的深入,发现反编译的代码虽然经过混淆,但是基本上了解其原理够用)

(2)、硬编码查询

思路:查询AndroidManifest.xml

1.1、AndroidManifest.xml

高德地图API调用

<meta-data android:name="com.amap.api.v2.apikey" android:value="261b11c16677e0738b32cfcf3c4d3bc8" />

1.2、asset相关资料

asset\config.txt 暴露和安全相关的信息

开发模式下联网获取css、lua和image的接口GET_RESFILE_URI /test_s/get_page? //启动时,通过联网下载最新的xhtml文件到手机本地,通过lua加载。SESSION_KEY phone/get_keys? //在后面分析通讯秘钥中,产生session key时使用,通过手机号产生session key

加密信道当前版本tls_version 1.3 //在后面分析通讯秘钥中,判断tls版本用,对https验证要求很高。

dynamickey /user_s/dynamickey? 一字一密接口,EULA.txt:Beijing RYTong Information Technology Co.LTD http://rytong.net/ 融易通开发的。

1.3、APPKEY/APP_KEY/apikey

(1)XMPP Apikey

package com.rytong.push;

Log.i(a, "apiKey=" + this.f); Log.i(a, "xmppHost=" + this.g); Log.i(a, "xmppPort=" + this.h);

通过logcat查询到:

I/Androidpn_s( 2508): Callback Activity... I/Androidpn_s( 2508): apiKey=bjpush I/Androidpn_s( 2508): xmppHost=61.135.232.215 I/Androidpn_s( 2508): xmppPort=5222

(2)session apikey

(3)第三方SDK

androidpn做消息推送 是基于XMPP协议的推送,建议更改成最新的MQTT协议。因为XMPP推送协议本身没有很好的SSL安全机制,需要自己在上层实现,复杂。当然也可以使用国内互联网厂商的构建的推送服务,例如:极光推送、小米推送等,安全问题有推送服务厂商托管。

No.2、数据存储安全

这部分主要是关注Shared_prefs\sqlite database\Cookies webview会话\Token本地存储。运行夜神android模拟器。

(1)查看Shared_prefs相关内容

这里我要吐个槽了,北京银行怎么还用xmpp协议做消息推送呢?让我想起来前段时间被破解的京东智能家电的洗衣机的破解案例,协议本身没有任何加密。

而且服务地址暴露,很容易被入侵,然后列举出来有多少客户端DeviceID在xmpp服务器上,并且可以伪造钓鱼推送消息。(后来查找源代码,发现XMPP使用Smack API调用,同时又证书调用,暂时是安全的)当然在这里没有发现有价值的泄露数据。

不过结合阅读混淆的反编译源代码发现:

源代码位置:com.rytong.push.u.class. xmpp_password使用DESCipher做的加密,那也可以DESCipher解密函数实现解密。

(2)查看Sqlite database相关内容

通过nox_adb.exe pull /data/data/com.rytong.bankbj/database/database.sql 导入到本地SQLite Database browser中查看

这个就有点说不过去了,你不能把中国银行的账号明文存储吧?要不加密sqlite数据库,要么加密存储在数据库中的字段。

(3)Cookies webview会话

在windows上建立drozer环境检查,>nox_adb.exe forward tcp:31415 tcp:31415 //在PC上使用adb进行端口转发,转发到Drozer使用的端口31415,选择Drozer>Embedded Server>Enabled //在Android设备上开启Drozer Agent >C:\Program Files\drozer>Drozer.bat console connect //在PC上开启Drozer console

运行 app.package.attacksurface com.rytong.bankbj

运行 app.activity.info -a com.rytong.bankbj

看到这里,大家都明白了,已经没有利用的可能性,PASS。

No.3、数据传输安全

(1)通讯秘钥分析

先访问一下https://ebank.bankofbeijing.com.cn/perbank/eAccount.do 查看一下网站的CA证书。

没有坏到使用自签名证书。

但是,经过Fiddler代理抓包发现无法得到HTTPS的流量。

然后在反编译源代码中搜索 X509TrustManager 、HostnameVerifier 、 setHostnameVerifier、ALLOW_ALL_HOSTNAME_VERIFIER等关键字搞清楚其生成证书的流程:

研究一:Say Hello, 验证服务端签名

package com.rytong.tools.clienthello;

研究二、AES 密钥交换( rsa + base64 + hmac)

Hmac 是本机mac地址做相应的处理,从代码来看是做过MD5和SHA1的加密处理。

package com.rytong.app.emp;

(2)Token分析

大家可以看出来:

这个是报文签名,每次都不一样,大家就别想破解了,PASS。。

No.4、安全增强测试

(1)自绘键盘分析

银行应用有一个特殊的功能,那就是需要输入银行的账号和密码,而且银行密码都是六位数字,如何解决其安全问题,一般都使用自绘键盘处理输入的密码过程。

首先先检测一下是否为目前最安全的动态自绘键盘。

看上面两张图,会发现键盘数字出现的位置都不一样,那么证明为自绘随机键盘,

通过源代码可以搜索,keyboardView、InputMethodManager查找其编程逻辑。

攻击方式检测:

安全评估:没有使用第三方键盘SDK做安全加固,获取其保存内容不是无可能。建议使用专业的专业SDK键盘。

(2)So文件分析

AppVerify.So:联网校验所有app的文件是否被篡改。

程序入口:JNI_Onload()

(1)加载com/rytong/tools/crypto/AppVerify.So 文件

(2)调用GetApkPath(_JNIEnv *,std::string,_jobject *)

(3)调用VerifyHash(_JNIEnv *,char *,char const*,int)

(4)_Z10VerifyHashP7_JNIEnvPcPKci

Java_com_rytong_tools_crypto_AppVerify_verifyHashByC (使用SHA1算法校验)

(5)调用update 更新

(6)GetApkMFData =》加载META-INF/MANIFEST.MF

对所有文件做完整性校验很必要,防止二次打包,好思路。

0x02、安全建议

本银行程序最核心的安全机制是使用RSA非对称加密算法+本地HMAC,充分保障了SSL数据传输安全,当然,没有使用xposed hook通讯协议的测试方法验证其安全性。由于调用xposed需要重新编译apk加log看数据结果,比较复杂下期再说。

当然也要做出以下几条:

(1)开发者遵守App的安全开发代码规范。

(2)使用成熟安全组件、如:软键盘、清场,特别是推送服务不建议使用xmpp。

(3)定期对客户端进行安全评估。(众测模式)。

(4)有必要做App安全加固(建议使用传统安全厂商)、阻止代码反编译、阻止APP运行时被动态注入。

* 作者:bt0sea,本文属FreeBuf原创奖励计划文章,未经许可禁止转载

原文发布于微信公众号 - FreeBuf(freebuf)

原文发表时间:2015-10-08

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏web前端教室

[前端常见病] 之 后端数据还没有,前端怎么进行?

标题所描述的情况,一般出现在后端进度滞后,前端又积累了一些工作量的情况下。在业务需求已经基本清晰的时候,前端的进度是很快的,UI设计出设计图,前端小兄弟切页面,...

23710
来自专栏魏艾斯博客www.vpsss.net

iq block country 插件屏蔽中国 IP 防止 wordpress 外贸网站被抄袭

1.1K5
来自专栏Java技术栈

同样是5年的开发经验,差距在哪里了?

我现在就职于一家中型的互联网企业,去年年底入职的薪资和待遇都很不错,但是总结起来说的好听就是全村人的希望,说的不好听就是一个人几乎干了一个项目组的事。

1096
来自专栏程序猿DD

阿里巴巴硅谷 Istio 专家解读Istio 1.0 发布

Istio 1.0 于北京时间8月1日0点正式发布!虽然比原本官网公布的发布时间晚了9个小时,但这并未影响到Istio在社区的热度。

1743
来自专栏FreeBuf

走进科学:对七夕“超级病毒”XX神器的逆向分析

首先给各位无良媒体记者跪了。七夕那天刚从公司拿到样本的时候还以为是主管随便到网上扒了个木马demo给我练手,第二天看新闻才知道这小玩具已经搞得满城风雨,媒体竟然...

1965
来自专栏晨星先生的自留地

渗透某摄像头系统

3313
来自专栏FreeBuf

防范数据窃取从了解其手法做起

数据窃取是针对组织攻击链中的最后一个阶段。攻击者窃取数据的技术可谓花样百出,网上也有大量关于数据窃取方面的技术文档以及工具。本文的目的就是尽可能的将这些技术整合...

743
来自专栏菩提树下的杨过

Flash/Flex学习笔记(7):FMS3.5基于IIS的安装

一般来讲,在windows上安装软件从来都不是什么难事儿,但FMS却在安装过程中"充满"了误导(好吧,其实也就是夸张的说法而已) 1.下载FMS3.5 http...

2376
来自专栏岑志军的专栏

iOS逆向-ipa包重签名及非越狱手机安装多个微信

4924
来自专栏Data Analysis & Viz

手把手教你完成一个数据科学小项目(1):数据爬取

请先阅读“中国年轻人正带领国家走向危机”,这锅背是不背? 一文,以对“手把手教你完成一个数据科学小项目”系列有个全局性的了解。

1762

扫码关注云+社区

领取腾讯云代金券