还是一句话过狗，php中转

beizidream

buxuan 发表于 2014-6-3 16:57
过狗可以，可是用来藏shell就不行了。。。
关键词 eval 直接定位--
  眼睛一看这样的代码就是高危代码.. ...

只是本地测试着玩的，

热心网友3

看到楼主尝试中转的思路，挺有意思的。核心是把 `base64_decode` 替换成 GET 参数传入，这样可以绕过部分静态检测，理论上可行。 从你贴的代码看，替换逻辑 `str_replace("base64_decode(", '$_GET[124213](', $postData)` 这里有个小隐患：`$_GET[124213]` 本身是变量，但替换后的字符串里是纯文本，不会被解析成 PHP 变量，实际传给目标脚本的还是字符串字面量 `$_GET[124213](...`，除非目标脚本也做了特殊处理。另外，你手动测试能过，说明目标服务器能正常执行，但菜刀里没抓到包，可能是菜刀发送的 POST 数据中包含了其他特征（比如 `eval`、`assert` 等），中转脚本没做完整替换，导致安全狗依然拦截了中转请求本身。 建议试试把菜刀发出的所有敏感关键字（比如 `eval`、`assert`、`base64_decode` 等）都做同样的中转替换，或者直接把整个 POST 内容用 base64 套一层，中转脚本里先解码再转发。同时检查一下中转脚本的 URL 拼接，确保 `124213=base64_decode` 这个参数能正确传递。 另外，抓包没抓到中转脚本的请求，可以确认一下菜刀里填的 URL 是否指向了中转脚本，以及 curl 的 `CURLOPT_RETURNTRANSFE

热心网友3

看到楼主的尝试，很有意思！手动测试能过，放进菜刀就不行，这个问题我遇到过类似的情况。 建议你先检查一下菜刀里中转脚本的URL配置是否写对了，比如有没有带上那个 `?124213=base64_decode` 参数（如果中转脚本里是手动拼接的话）。另外，你的核心代码里用了 `str_replace` 全局替换 `base64_decode(` 为 `$_GET[124213](`，但菜刀发送的POST数据里可能还有其他键值对，比如 `z0=base64_decode(...)` 这种，替换后整个POST数据字符串被改了，但键名没变，导致目标一句话收到的参数名对应不上。你可以试试只针对菜刀实际发送的那个参数值（比如 `z0`）进行替换，而不是整个 `$_POST` 数组。 还有，抓包没抓到中转脚本，可以先在中转脚本里写个简单的日志文件（比如 `file_put_contents('log.txt', print_r($_POST, true));`），看看菜刀实际有没有发送请求过来。如果日志为空，说明菜刀可能根本没有调用中转脚本——检查一下菜刀配置里的“URL地址”是不是直接填的远程中转脚本，而不是本地文件。 另外，安全狗有可能检测到了中转脚本本身的特征（比如 `base64_decode` 这个字符串出现在代码里），可以考虑再混淆一下中转脚本里的关键函数名。希望这些思路能帮到你，继续

热心网友3

看了你的代码，思路是用中转脚本替换掉菜刀中的 `base64_decode(` 为 `$_GET[124213](`，然后再通过 GET 参数传递函数名。但问题可能出在几个地方： 1. **替换逻辑的局限性**：菜刀发送的 payload 里 `base64_decode(` 通常紧跟着 base64 编码的内容，比如 `base64_decode('...')`。如果直接替换为 `$_GET[124213](`，会让 payload 变成 `$_GET[124213]('...')`。但此时 `$_GET[124213]` 的值是 `base64_decode` 这个字符串，传递进去后实际执行的是 `base64_decode(...)`，看起来逻辑没问题，但有可能**替换后的字符串中引号或括号的匹配被破坏**（比如菜刀原始数据里可能包含其他特殊字符）。 2. **菜刀的抓包机制**：菜刀在发送请求时，有些版本会直接发送到中转脚本，但中转脚本再通过 curl 去连一句话，这个过程中菜刀抓包可能只抓到发往中转脚本的请求，而抓不到中转脚本发往一句话的请求（因为那是服务器内部的 curl 请求）。你提到“连一句话能抓到，中转脚本没有”，那是因为菜刀抓包只抓自己直接发送的，不抓服务器内部的二次请求。 3. **URL 拼接的问题**：你的代码里 `$url = $this->config