渗透测试-Android-App渗透测试测试流程
渗透测试-Android-App渗透测试测试流程
0x01：前⾔：
仅作为记录以供参考
0x02：漏洞测试⽅法以及修复⽅案
⼀、组件以及源码安全元彪所有电影
1、签名校验
命令：
//test.apk 为要检测的包
< -verify test.apk -verbose –certs
如果显⽰jar已验证即为已做了签名校验
修复⽅案：增加验证签名机制。
2、任意调试漏洞
通过对apk⽂件进⾏解包，检测 l ⽂件的 debuggable 属性，如果该属性为 true，则存在任意调试漏洞。解包过程：
命令：
//test.apk为要拆解的包名 test为拆解后存放的⽂件夹
java -jar apktool_2.4.0.jar d -f apl test.apk -o test
使⽤编译器打开XML⽂件，搜索关键字 debuggable ，如果存在该属性且为 true ，则存在任意调试漏洞，如果不存在该属性则不存在该漏洞（debuggable默认为false）
修复⽅案：将 debuggable 改为 false。
3、AllowBackup漏洞
通过对apk⽂件进⾏解包，检测 l ⽂件的 allowBackup 属性，如果该属性为 true，则存在 allowBackup 漏洞。⽤户可通过adb backup来进⾏对应⽤数据的备份，在⽆root的情况下可以导出应⽤中存储的所有数据，造成⽤户数据的严重泄露。
高级的含蓄的骂人的话 使⽤编译器打开XML⽂件，搜索关键字 allowBackup ，如果存在该属性且为 true ，则存在allowBackup漏洞，如果不存在该属性也存在该漏洞（allowBackup默认为true）
修复⽅案：将 allowBackup 改为 false。
4、APP代码未混淆
使⽤ dex2jar 对apk⽂件内的 classes.dex ⽂件处理得到 classes-dex2jar.jar ⽂件，使⽤ jd-jui 反编译jar⽂件得到源码，如果代码未混淆，即代码的类名、函数、变量等未变为⽆意义的字符，则有源码暴露、资源⽂件暴露、主配⽂件篡改、核⼼SO库暴露、暴⼒破解恶意利⽤等风险。
操作⽅法：
使⽤解压缩包软件打开apk⽂件，将classes.dex⽂件复制出来。
使⽤ dex2jar 将classes.dex处理为jar⽂件
命令：
./d2j-dex2jar.bat /d/渗透测试/移动app渗透/dex2jar-2.0/classes.dex
然后使⽤jui打开jar⽂件，如果代码未混淆，将是下⾯这个样⼦
已经混淆的，如下
修复⽅案：将代码进⾏混淆加密。
5、APP未作应⽤完整性校验
五大战区驻地 未检测app的MD5或CRC32、SHA1准确性以及完整性，导致可以修改app任意⽂件⼆次打包。
拆包后将 app logo ⽂件替换为其他图⽚，⼀般存在于res⽂件夹下的以mipmap开头的⼏个⽂件夹中，或者直接在apk⽂件夹下搜索launcher、logo 。然后重新打包签名，查看是否可以正常安装使⽤
过程如下：将app拆包后更换app的logo⽂件
重新打包apk，打包⽣成的apk⽂件默认存放在apk⽂件夹中dist⽂件夹下：
命令：
//test指要打包的⽂件夹
java -jar apktool_2.4.0.jar b test/
将apk签名：
同是天涯沦落人歌词 命令：
//test.apk是要签名的apk test1.apk是签名后输出的apk
java -jar signapk.jar testkey.x509.pem testkey.pk8 test.apk test1.apk
尝试安装，如果可以正常安装且可以正常打开使⽤，代表存在app未作应⽤完整性校验
修复⽅案：在app安装时⾸先进⾏CRC32、MD5或SHA1校验，校验与源app值相同时才可以正常安装，否则禁⽌安装或设置开启app⾃动关闭
6、APP敏感数据泄露
主要检测软件包内的db数据库是否泄露了敏感信息，本地数据库有可能明⽂保存⽤户的账号密码或其他信息。
将⼿机和pc连接，pc部署adb环境，⼿机需要root，adb进⼊⼿机系统
命令：
adb shell
切换root权限，命令：
su
进⼊/data/data⽬录，此⽬录是⽤户安装的软件⽬录
选择要进⼊的包，包名在 l ⽂件中，通过搜索package可以得到地板砖十大名牌
进⼊相应的包，查看⽂件⽬录，应该存在database⽬录
进⼊该⽬录，查看⽂件，导出.db⽂件
命令：
cp xx.db /sdcard/
然后在sd卡，也就是⼿机内部存储器即可可见数据库⽂件
使⽤数据库管理⼯具SQLiteExpert打开即可
未完待续……
⼆、逻辑漏洞
1、邮件
存在点：存在于任意可发送验证码的位置，发送验证码⼀般都有限制时间。
验证⽅法：输⼊⼿机号、邮箱后抓包后多次重放，如果接到许多验证码即代表存在邮件。
产⽣原因：服务器未作后端校验，只是在前端设置了60s冷却时间，但是服务端并与前端进⾏联合校验，导致可以绕过限制时间不停发邮件或验证码。
修复⽅案：服务端记录邮件发送冷却时间，与前端其进⾏联合校验。
2、任意⽤户密码重置
存在点：回密码和修改密码处
验证⽅法：1.修改密码，修改⾃⼰的密码，输⼊正确信息后抓取发送数据包，然后改变⼿机号（或邮箱）这⼀参数，将它改为其他⼿机号（或邮箱），然后发出数据包。
2.回密码，输⼊⾃⼰的⼿机号（或邮箱），获取验证码，然后输⼊正确的验证码，抓包，将⼿机号（或邮箱）这⼀参数改为其他⽤户的⼿机号（或邮箱），发送数据。
产⽣原因：1.输⼊密码后提交到服务端的post数据包需要包含当前⽤户的⾝份信息，⽽⼀般⽹站是通过⽤户名或⽤户ID来标识⽤户⾝份的，如果这个⽤户名或⽤户ID没有和当前⼿机号、短信验证码进⾏绑定，也就是说服务端只验证⽤户名、ID是否存在，⽽不去验证⽤户和当前⼿机号是否匹配，那么我们就可以通过修改⽤户名、ID去修改其他⽤户的密码了。
2.漏洞原因判断了验证码是否正确，⽽没有判断该验证码是否跟该⽤户匹配。
修复⽅案：对参数进⾏复杂加密，将⽤户名、验证码和⼿机号进⾏绑定，输⼊新的密码，然后提交到服务端，服务端应对当前⽤户名、⼿机号、短信验证码进⾏⼆次匹配验证，都为true时，才可以修改成功。
未完待续......
版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。
发表评论