getshell渗透测试

随着攻防演练愈演愈烈，弱小的我也不得不加入攻防大军的队伍里，而本篇文章就记录了某次攻防演练中的getshell历程。在这次攻防演练中，初步利用工具批量打点无果，作为团队里卑微的撕口子工具人，只能选择一个站一个站硬啃。

1 开始

又是熟悉的“开局一个后台”系列，初期重点选择没有验证码机制的后台去进行爆破：

这里目录与账号密码同时进行爆破，然而不出意外，没有任何结果：

既然爆破无果，只能再试试其他的思路。

一般URI中带#的js多为webpack模块打包。于是决定再次从前台webpack打包的js接口入手：

利用浏览器功能美化js文件，通过搜索path关键字，查找后台路由：

通过构造路径进入后台，发现大部分接口存在二次验证。直接跳转至登录页，对path路径进行多次尝试，找到个人头像上传点。

测试直接上传jpg成功后，抓包尝试修改后缀上传webshell。但发现服务端直接对上传的文件进行了重命名，此条线索终止。

随后，找到导入excel处尝试XXE：

下载模板，解压后修改其中xml文件的内容，加入payload：

上传后发现所添加的ceye平台出现了请求：

其中有http请求,说明可以下载文件：

修改payload为访问外部实体的语句：

在vps上预先放置外部实体：

开启http服务等待下载：

之后上传文件，会触发服务器请求vps下载dtd外部实体的命令，进而读取内容。另外开启ftp服务以实现文件内容外带，尝试读取/etc/passwd中的内容。

这里直接在网上寻找的脚本：

“https://github.com/ONsec-Lab/scripts/blob/master/xxe-ftp-server.rb”

尝试读取ssh key，读取成功：

“/root/.ssh/id_rsa.pub”

对主机进行端口探测，发现22端口处于filtered状态，尝试连接发现超时，考虑到时间成本，暂时放弃这条路线。

最后在个人中心处找到一个可下载的APP：

打开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下，要想查找上传路径有两种方法，一种是通过网盘在下载文件时查看是否会有文件路径，第二种就是根据上传接口去构造猜测文件路径。

当打开网盘界面时，发现在网盘加载文件列表时需要用户会话认证，没有即为空。

白茫茫的背景图，让本不富裕的我更加雪上加霜。

只能寄希望于最后一处更加渺茫的方法：猜测路径。

手工对URI逐级进行拆分：

结果拆到第二步，惊喜就出现了，没有提示404，证明文件存在：

好家伙，我直接好家伙，这居然还是system权限，花光了我一年的运气：

shell已到手，打点工具人也该撤退了。

2 总结

本文先从Web端入手进行渗透，在webpack模式下对后台查找未授权访问点，如上传跟XXE测试，测试无果后在后台发现apk安装包，转向防护相对薄弱的Android移动端进行渗透最终getshell。

因为初始目标明确，就是为了拿到webshell打开口子，所以进行渗透时都是奔着可以getshell的方式进行重点测试。