拿到一台Linux服务器的服务shell，你看到的器提权可能只是一个普通用户。真正的服务战场在提权那一刻才开始。

去年帮朋友排查一台被入侵的器提权测试机，攻击者留下的服务痕迹很典型：一个低权限的www-data shell，然后通过一个SUID位的器提权vim二进制文件直接拿到了root。整个过程不超过两分钟。服务这个案例说明了一个事实——提权漏洞往往不在内核本身，器提权而在管理员随手留下的服务配置里。

SUID：最容易被忽视的器提权入口

SUID（Set Owner User ID）机制让普通用户执行某个程序时临时获得文件所有者的权限。听起来合理，服务问题出在太多人把SUID随手加到了不该加的器提权程序上。

我见过最离谱的服务一个：某运维给/usr/bin/find加了SUID位，理由是器提权“方便脚本调用”。结果攻击者一条命令就完事：

find / -exec /bin/sh -p \; -quit

拿到root shell的服务那一刻，服务器已经不属于你了。类似的还有nmap、vim、less、python，只要它们带着SUID位，提权几乎是白送。检查方法也简单：

find / -perm -4000 -type f 2>/dev/null

这条命令跑完，你会看到系统里所有SUID程序。如果里面出现了编辑器、解释器、网络工具，那基本可以判定这台机器的安全基线是失控的。

内核漏洞：不是首选，但躲不掉

很多人一提提权就想到内核exploit，比如Dirty COW、PwnKit。这类漏洞确实好用，但有个现实问题：打内核补丁会导致服务器重启，很多生产环境宁可裸奔也不重启。所以老内核在真实环境中大量存在。

我的判断是：内核提权应该作为最后手段。原因很直接——exploit不稳定，打崩了机器就彻底失联。先用配置类漏洞尝试，失败再考虑内核。判断内核版本：

uname -r

然后去searchsploit或者GitHub上比对，但别急着编译运行。先确认目标环境的glibc版本、编译器是否可用，否则你连exploit都编译不过去。

计划任务与PATH劫持

cron job是另一个重灾区。管理员写定时任务时习惯用相对路径：

*/5 * * * * backup.sh

如果这个脚本没有写全路径，而cron的PATH变量里包含可写目录，你只需要在同名路径放一个恶意脚本，等五分钟就拿到权限。这种手法不需要任何漏洞，纯粹是利用配置疏忽。

我个人的习惯是：拿到shell后先看/etc/crontab和/etc/cron.d/，再检查ps aux里有没有以root运行的脚本调用了相对路径的命令。有一次发现一个每分钟执行一次的监控脚本调用了date，而/usr/local/bin在PATH里排在/bin前面且可写——直接替换date，一分钟后root shell到手。

提权之后的事

拿到root不代表结束。清理日志、留后门、横向移动，这些才是攻击者的完整链路。但从防御角度看，提权成功意味着前面所有防线都已经失效。与其纠结怎么检测提权，不如先把SUID清理一遍、把cron脚本改成绝对路径、把内核补丁打上。

这些事不酷，但有用。