随着攻防演练愈演愈烈，弱小的我也不得不加入攻防大军的队伍里，而本篇文章就记录了某次攻防演练中的getshell历程。在这次攻防演练中，初步利用工具批量打点无果，作为团队里卑微的撕口子工具人，只能选择一个站一个站硬啃。
又是熟悉的“开局一个后台”系列，初期重点选择没有验证码机制的后台去进行爆破：
这里目录与账号密码同时进行爆破，然而不出意外，没有任何结果：
一般URI中带#的js多为webpack模块打包。于是决定再次从前台webpack打包的js接口入手：
利用浏览器功能美化js文件，通过搜索path关键字，查找后台路由：
通过构造路径进入后台，发现大部分接口存在二次验证。直接跳转至登录页，对path路径进行多次尝试，找到个人头像上传点。
测试直接上传jpg成功后，抓包尝试修改后缀上传webshell。但发现服务端直接对上传的文件进行了重命名，此条线索终止。
下载模板，解压后修改其中xml文件的内容，加入payload：
之后上传文件，会触发服务器请求vps下载dtd外部实体的命令，进而读取内容。另外开启ftp服务以实现文件内容外带，尝试读取/etc/passwd中的内容。
“https://github.com/ONsec-Lab/scripts/blob/master/xxe-ftp-server.rb”
对主机进行端口探测，发现22端口处于filtered状态，尝试连接发现超时，考虑到时间成本，暂时放弃这条路线。
打开app发现需要登录，且抓包发现与Web端登录接口一致，放弃尝试登录绕过，直接反编译apk，找到主界面的activity：
通过adb 的am指令绕过登录界面，到达MainActivity（Android端一些APP手势密码绕过也可以利用此方法步骤，直接跳转到设置手势密码的Activity界面，通过重新设置手势密码来进行绕过，但是同样需要通过AndroidManifest.xml来查找相应的Activity名称）。
“am start ｛包(package)名｝/｛包名｝.{活动(activity)名称}”
仔细寻找功能点。这里很累，因为如果请求没有身份认证通过，便会直接退回登录界面，需要一直利用am指令进行主页跳转：
在订单流程处找到一处上传附件的地方，发现其对后缀名进行了白名单校验，放弃。
最后发现app只有在网盘功能处，上传时不需要cookie认证，这里第一次进行上传时uri路径存在null参数，怀疑是用来获取用户昵称在服务端创建文件夹。
将null修改为admin，虽然再次成功上传，但是没有直接返回文件路径，即使找到路径也很有可能是上传到静态目录，无法对脚本文件进行解析。
虽然网盘很大概率是静态目录，但撕口子的迫切感让我不得不把握住每一次可能的机会，遂开始尝试查找路径。
在此APP下，要想查找上传路径有两种方法，一种是通过网盘在下载文件时查看是否会有文件路径，第二种就是根据上传接口去构造猜测文件路径。
当打开网盘界面时，发现在网盘加载文件列表时需要用户会话认证，没有即为空。
结果拆到第二步，惊喜就出现了，没有提示404，证明文件存在：
好家伙，我直接好家伙，这居然还是system权限，花光了我一年的运气：
本文先从Web端入手进行渗透，在webpack模式下对后台查找未授权访问点，如上传跟XXE测试，测试无果后在后台发现apk安装包，转向防护相对薄弱的Android移动端进行渗透最终getshell。
因为初始目标明确，就是为了拿到webshell打开口子，所以进行渗透时都是奔着可以getshell的方式进行重点测试。
注意:在挖src的时候，不建议去getshell,否则后果自负
原文始发于微信公众号（迪哥讲事）：从移动端突破获取getshell
免责声明:文章中涉及的程序(方法)可能带有攻击性，仅供安全研究与教学之用，读者将其信息做其他用途，由读者承担全部法律及连带责任，本站不承担任何法律及连带责任；如有问题可邮件联系(建议使用企业邮箱或有效邮箱,避免邮件被拦截，联系方式见首页)，望知悉。
点赞
https://cn-sec.com/archives/2833570.html
复制链接
复制链接
-
左青龙
- 微信扫一扫
-
-
右白虎
- 微信扫一扫
-
评论