前言
老生常谈了 不过当年被提出来的时候就看到很多消息说 本地一打一个准 实战一个都打不了 当时也没需求也没研究 正好hw看到一个红队跳板 稍微看看
测试
对于使用<通配的技巧 最初我还是在乌云社区上看到的 后来用过这个方法去配合serv-u跳目录问题 遍历了整个ftp 见https://hundan.org/2018/08/12/Serv-u%E8%B7%A8%E7%9B%AE%E5%BD%95/#exp 不过当时对此认知不够 以为通配符是ftp的问题
消息是这样的 简单回溯一下 估计就是tag.htm被删了
翻到最初的文章 我们注意到
回去检查各个文件引用 但是本地成功依旧是远端失败 怀疑可能修补了 下载了个最新版的dede
最新版并没有对这块做出改动 问题也可以成功复现 只能怀疑是被人改动了
分析
通过后门拿到了程序 下载回来看了一下 确实有改动
为了加快调试 用原版代码覆盖 的确成功复现
想了想 这个确实是解决了找后台的问题 搜了一下
新的问题？
但是 是不是会引入新的问题？ 这个文件的本意是为了拦截问题文件的上传 现在直接放行了 从设计上来说 是因为dede代码结构设计有点问题 导致没有上传行为 却进行了上传审计
经过简单的研判 找到了文章缩略图上传的地方 通过修改content-type即可绕过
而这在添加代码前是做不到的
不过总的来说 到后台之后拿shell的方法很多 这个修正也还算能接受 有没有更好的修复方式？
更精确地说 我们需要判断出上传行为和找后台行为 上传行为的拦截在于判断 正常文件与恶意文件 找后台行为的拦截在于 正常文件和不存在的文件
知道这个 就很简单了 更好的修复方案应该是 加一段file_exists包裹住
不过本身这个也不是什么大问题 而且也不能实质性解决问题 图片马也能绕过 把code写到相机制造者里 然后手动调整一下 即使修复也一样绕过 dede后台拿shell方法不少
what’s more
反思？
这个方法真的能修复找后台的问题吗 关键在于如何进入这段 使得其造成差别
1 | exit('Upload filetype not allow !'); |
满足条件：getimagesize can’t return array or false
https://www.php.net/manual/en/function.getimagesize.php
按照手册来说是不行的 但是如果能够在后台目录里的文件 出现那么一个文件 使得包含其后出现fatal报错 停止运行 （或者notice/warning级别 但是前提是其能够显示） 源码里似乎有那么几条稍微符合这个条件 但并没有fatal级别的报错
……
不过事实上 即使有fatal级别的问题 也无法实现 因为默认后台目录里文件相当有限 也无法从前台控制 则无法构造恶意文件探测
跳转拼合的想法 二级目录回跳时会直接被处理掉 比如 ../123/.. 会直接被处理到 ../ 再进入系统 因此就算前台能传恶意文件也没用
基本上可以说 代码的修复确实解决了通过这个手段猜目录的问题 而带来的新问题可以忽略不计
更多的拓展思考
这个问题可以拓展到 后台目录与通配符的问题 以及一个读取的文件名可控的情况下 当然这个拓展其实非常狭隘
但是如果说 后台的图片比较大 非常大 这个时候就有余地了 就有一个时间差在里面
话又说回来 dedecms使用了大量的 @ 进行错误屏蔽 我不觉得这是一个好的行为 或许dede的这个 可以改一改 加点想法 做成ctf题目
当然我不觉得dedecms 找后台的思路 在这里就终结了 我觉得翻一翻php源码和dede源码 还能找到其他通配符出现的问题点
但是我现在还是没搞懂 攻击者是如何进入到跳板机的 只是 跳板机在我取证的时候手滑敲错了命令 后来管理员全部清理了 我也就无从考证了
burp repeater出问题了？
遇到了个有点不得其解的问题
repeat自动更新了content-length 导致发包后数据不对 上传上去的30kb变成48kb 文件无法读取 有点怀疑是burp的问题
关闭cl更新 又会导致一直reset
用hex模式把jpg改为php又正常了 可能是哪里自动处理了换行
点回第一个包 发送正常 再点一次 异常 自动更新cl 挺离谱的 可能真的是新版本burp的bug
