Android 渗透测试篇之信息泄露漏洞
信息泄露，更多是个广义的定义，最直接的解释用户的个人信息被攻击者所知，目前随着移动互联网高速发展，中国互联网络信息中心(CNNIC)在京发布第46次《中国互联网络发展状况统计报告》，截至2020年6月，我国网民规模达9.40亿，相当于全球网民的1/5；互联网普及率达67%，数量非常庞大，用户个人信息都会各种APP收集，但是遗憾的是，APP开发者并没有非常重视安全问题，导致APP存在信息泄露漏洞，泄露用户的手机号码，姓名，身份证号，银行卡号，汽车牌照号等等敏感的个人信息，甚至攻击者用收集到的信息用于黑灰产（广告推销，杀猪盘，网贷等），好消息是从国家层面越来越重视网络安全，企业也越来越重视。
1
典型的信息泄露风险点
风险1: 应用的Manifest文件中allowBackup属性值设置为true，可通过adb backup对应用数据进行备份，在无root的情况下可以导出应用中存储的所有数据。
> adb backup -f D:/back.ab -noapk 应用包名 即可备份
修复建议：将应用Manifest文件中allowBackup属性值设置为false
风险2：应用客户端与服务端交互过程中未做校验，导致信息泄露，比如：攻击者截获客户端服务端交互的数据包，任意修改用户ID，遍历其他用户的数据信息，导致用户的信息泄露。
修复建议：服务端加强身份验证机制,数据传输通道加密。
风险3：应用注册时，验证码明文返回至客户端，导致任意手机号码登录的风险。
修复建议：禁止验证码明文返回本地。
风险4：应用将源代码上传至github，导致源代码泄露。
修复建议：禁止将源代码上传到第三方托管平台。
风险5：验证码的请求次数和时间未做限制，导致攻击者可以暴力**，最终导致信息泄露。
修复建议：对验证码的请求次数和时间进行限制，服务端加强身份验证机制。
风险6：应用未做自定义软件键盘，导致应用在键盘输入时，信息被监听。
修复建议：核心业务输入使用自定义软键盘，禁止用系统键盘。
2
典型案例解析
案例1：某APP允许攻击者利用代理工具篡改数据包获取用户敏感信息。
（1）启动APP，进行注册登录，进入个人资料界面；
（2）拦截请求“个人资料”的数据包；
（3）我们发现请求数据中使用sign字段是用来作为认证的，并且APP还会在后台打印相应的调试日志。
（4）研究发现，根据日志里的内容计算SHA1，就得出生成sign的值。
（5）根据上述原理，修改相应的uid生成相应的sign。
（6）将数据修改后，进行数据包重放，即可得到其他用户的个人资料。
案例2：某APP验证验证码返回值客户端，利用验证登录任意账号。
（1）启动APP，在APP的注册界面，输入测试手机号进行注册操作。
（2）点击发送验证码，使用抓包工具拦截对应的数据包。
（3）对比发送到手机的短信验证码，发现与数据包中返回值相同。
（4）再次点击发送验证码，从数据包中可知短信验证码是316911。
（5）输入任意手机号码，输入验证码316911。
点击注册按钮，发现注册成功，此时返回值返回的数字就是短信验证码，可以通过返回值的验证码，使用任意手机号进行登陆，然后修改其密码等操作。
案例3：某出行APP，通过工具暴力**验证码等手段，任意登录。
（1）启动APP尝试注册操作，输入手机号，点击获取验证码，然后使用工具抓取数据请求。
（2）点击注册，APP会向手机发送一个短信验证码，此时，对发送的短信验证码使用fiddler工具进行抓包拦截。
（3）输入错误短信验证码0000，点击完成会提示验证码不正确或已失效，继续抓包。
数据包显示：
（4）通过burp工具对短信验证进行**，当**成功时会返回一个正确的值:
(5) 客户端重新进行验证码的请求，使用fiddler工具中断数据包，把上面**成功的值输入进去，数据返回值提示成功，说明我们**成功。
在手机客户端界面会显示登录成功。
通过以上案例，不管是那种方式，都是由于服务端没有对客户端做校验导致的，让攻击者钻了空子，如果服务端加强客户端的身份验证机制，对数据传输通道进行了有效的加密，这种风险也就不存在了。
好了，本篇文章就分享到此，感谢大家关注，下一期再见。
— END—
---------------------------------------------