1. 项目概述从“密码搜寻”到权限提升的攻防视角在Linux系统的管理与安全领域“权限提升”是一个永恒的核心话题。它不仅是系统管理员日常维护中需要防范的风险也是安全研究人员和渗透测试人员必须深入理解的技术点。今天我们不谈那些复杂的零日漏洞或内核提权而是聚焦于一种更为常见、也更容易被忽视的攻击路径密码搜寻。这个标题听起来可能有些“黑客”色彩但其本质是揭示一个普遍存在的安全短板——弱密码与密码不当存储。很多管理员认为启用了sudo、配置了强密码策略就高枕无忧却忽略了系统中散落的、以明文或弱加密形式存在的密码凭证它们就像藏在家门钥匙下的备用钥匙一旦被找到攻击者就能轻松登堂入室。简单来说这个过程就是攻击者在获得一个初始的、低权限的Shell访问例如通过一个Web应用的漏洞获得了www-data用户权限后并不急于使用高风险的漏洞利用而是像侦探一样在系统的各个角落“翻箱倒柜”寻找可能存在的密码、密钥、配置文件、历史命令记录等。一旦找到可用于更高权限账户如root或其他特权用户的密码就能通过su或sudo等合法途径完成权限提升。这种方法隐蔽、稳定且对系统扰动小。对于防御方而言理解攻击者的搜寻思路和路径是加固系统、进行有效安全审计的第一步。无论你是运维工程师、安全从业者还是对Linux安全感兴趣的开发者掌握这套“攻防思维”都至关重要。2. 密码搜寻的核心思路与常见藏匿点解析为什么密码搜寻能成为有效的提权手段这源于Linux系统以及运行在其上的应用程序在设计和日常使用中为了方便常常会将认证信息以不安全的方式留存下来。攻击者的核心思路就是利用这种“便利性”的副作用。他们的搜寻并非漫无目的而是有明确的重点目录和文件类型。我们可以将这些藏匿点分为几个大类用户相关文件、历史记录、配置文件、内存与进程信息以及应用特定文件。2.1 用户相关文件家目录与配置文件的宝藏每个用户的家目录/home/username或/root是首要目标。攻击者会仔细检查以下文件Shell历史文件.bash_history.zsh_history等。用户在执行命令时可能无意中将密码作为参数输入例如mysql -u root -pPssw0rd或sshpass -p secret ssh userhost。这些命令会被完整地记录在历史文件中。各类配置文件许多命令行工具和应用程序会在家目录下创建配置文件其中可能包含连接凭证。.ssh/目录检查id_rsa私钥有时私钥可能未加密。同时查看known_hosts、config文件可能包含主机信息和用户名提示。.aws/目录credentials和config文件可能包含云服务的访问密钥。.git-credentialsGit保存的仓库认证信息。.mysql_history.psql_history数据库客户端的历史命令可能包含密码。其他如.ftp.s3cfg等。用户自定义的脚本或文档用户可能将密码写在~/scripts/下的脚本里或者一个名为passwords.txt、creds.md的备忘录文档中。攻击者会使用find和grep进行地毯式搜索。注意检查这些文件需要相应的读权限。如果攻击者获得的低权限用户无法读取其他用户的家目录那么/root目录通常是无法访问的。但有时通过配置错误如家目录权限为777或通过某些服务如旧的、存在目录遍历漏洞的FTP服务可能实现访问。2.2 系统级配置文件与日志文件系统层面也有大量可能包含密码的地方配置文件/etc/passwd和/etc/shadow是终极目标但shadow需要root权限。然而一些应用的配置文件可能全局可读例如/etc/mysql/my.cnf或debian.cnf可能包含数据库root密码。Apache/Nginx的站点配置/etc/apache2/sites-available//etc/nginx/sites-enabled/可能包含HTTP基本认证的密码哈希或后端服务连接字符串。各种.conf.ini.yml.xml文件在/etc/目录下。日志文件应用程序或系统服务可能在日志中记录错误信息其中包含连接字符串或密码。例如Web应用错误日志/var/log/apache2/error.log、系统日志/var/log/syslog/var/log/auth.log。攻击者会使用grep -i “password\|passwd\|pwd\|auth”等命令进行过滤。备份与临时文件管理员可能创建了配置文件的备份如.bak.old.swpvim交换文件这些文件的安全意识可能较弱权限设置更宽松。2.3 内存、进程与环境变量中的密码这是一个更隐蔽的层面。许多程序在运行时会将密码加载到内存中或通过环境变量传递。进程内存通过工具如strings /proc/$PID/mem或gcore可以转储进程内存并搜索字符串。例如一个正在运行的MySQL守护进程其内存中很可能存在root密码。环境变量执行env或cat /proc/$PID/environ可以查看当前用户或指定进程的环境变量。一些自动化脚本或容器化应用习惯通过环境变量如DB_PASSWORDAPI_KEY传递密钥。bash进程有时密码会出现在/proc/$$/cmdline中特别是当密码作为脚本参数时。2.4 利用自动化工具进行系统化搜寻手动搜寻效率低攻击者通常会借助自动化脚本或工具。最著名的就是LinEnumLinPEAS和Linux Exploit Suggester。这些工具不仅能搜寻密码还能全面检查系统的权限配置、SUID/GUID文件、计划任务、可用内核漏洞等给出一个完整的“攻击面报告”。 以LinPEAS为例它会自动检查我们上面提到的几乎所有路径并用颜色高亮显示可疑的发现如可写的计划任务、包含pass关键词的可读文件等。对于渗透测试人员运行./linpeas.sh往往是获得低权限Shell后的标准动作。从防御角度看定期以非特权用户身份运行这些工具或在安全环境中扫描系统镜像是发现自身系统信息泄露风险的有效方法。3. 实操演练一次完整的密码搜寻与提权过程为了让大家有更直观的理解我们模拟一个简单的场景。假设我们通过一个Web漏洞获得了对目标服务器上www-data用户的命令执行能力拿到了一个反向Shell。3.1 第一步初步信息收集与环境确认首先我们需要知道自己是谁在哪里有什么。whoami # 输出www-data id # 输出uid33(www-data) gid33(www-data) groups33(www-data) pwd # 输出/var/www/html uname -a # 输出Linux target-server 5.4.0-110-generic #124-Ubuntu SMP Thu Apr 4 12:43:39 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux sudo -l # 输出对不起用户 www-data 不能在 target-server 上运行 sudo。信息显示我们是一个权限很低的Web服务用户且没有sudo权限。直接内核提权可能复杂我们优先尝试密码搜寻。3.2 第二步手动进行关键位置搜寻我们从最可能的地方开始。检查当前用户的历史和配置文件# 尝试进入家目录但www-data用户通常没有自己的家目录或目录为空 cd /home/ ls -la # 假设有用户 alice 和 bob # 检查我们能否读取他们的文件 ls -la /home/alice/ # 如果权限拒绝暂时跳过。先看自己的历史。 cat ~/.bash_history 2/dev/null | head -20 # 可能为空因为www-data可能不使用bash交互。搜索包含密码关键词的文件我们可以在整个文件系统或特定目录中搜索。# 在 /var/www (Web目录) 中搜索这里我们最有权限 find /var/www -type f \( -name *.php -o -name *.conf -o -name *.ini -o -name *.yml -o -name *.json \) -exec grep -l -i password\|passwd\|pwd\|auth\|secret\|key {} \; 2/dev/null # 在 /etc 中搜索全局可读的包含密码的文件 find /etc -type f -readable -exec grep -l -i password {} \; 2/dev/null 2/dev/null | head -10假设我们在/var/www/html/config/database.php中发现?php define(DB_USER, app_user); define(DB_PASSWORD, Sup3rS3cr3tPss!); define(DB_HOST, localhost); ?这是一个数据库密码但数据库用户app_user可能权限有限。检查计划任务和系统服务看看有没有以root身份运行的脚本并且我们能否修改或读取它们。cat /etc/crontab ls -la /etc/cron.d/ /etc/cron.hourly/ /etc/cron.daily/ etc. # 特别注意那些全局可写权限为777或所属用户/组可写的脚本 find /etc/cron* -type f -writable 2/dev/null搜寻备份文件和临时文件find / -type f \( -name *.bak -o -name *.old -o -name *.swp -o -name *~ \) -readable 2/dev/null | head -20假设我们找到一个文件/var/backups/shadow.bak并且可读。这可能是管理员错误备份的/etc/shadow文件。我们可以尝试用unshadow工具结合/etc/passwd通常可读进行密码破解。3.3 第三步发现关键凭证并尝试提权在搜寻过程中我们发现了更有价值的东西。检查/opt/目录这是一个常被用于放置自定义应用程序的地方。ls -la /opt/ # 发现一个目录 /opt/internal_tool find /opt/internal_tool -type f -readable 2/dev/null -exec grep -i password\|root\|sudo {} \;我们在/opt/internal_tool/connect.sh中发现了以下内容#!/bin/bash # 用于内部维护的脚本 sshpass -p MyRootPss2024! ssh -o StrictHostKeyCheckingno rootlocalhost $Bingo这是一个以明文硬编码了root密码的脚本并且它使用sshpass工具来非交互式地以root身份执行SSH命令。关键是我们www-data用户是否有权限执行这个脚本ls -la /opt/internal_tool/connect.sh # 输出-rwxr-xr-x 1 root root 245 Jun 1 10:00 /opt/internal_tool/connect.sh权限是755意味着任何用户都可以执行x。这就是我们的突破口。3.4 第四步利用找到的凭证完成权限提升现在我们有两种思路直接利用脚本这个脚本本身就能以root身份执行任意命令。我们运行它。/opt/internal_tool/connect.sh id # 预期输出uid0(root) gid0(root) groups0(root)成功了现在我们可以通过这个脚本执行任何root命令例如/opt/internal_tool/connect.sh bash来获得一个root shell。使用密码直接切换用户我们知道了root的密码是MyRootPss2024!。我们可以尝试直接su到root。su root # 提示输入密码输入 MyRootPss2024! whoami # 输出root同样成功。至此我们通过密码搜寻从一个低权限的www-data用户提升到了最高的root权限。实操心得在实际环境中像connect.sh这样明文存放root密码的脚本是严重的安全失误。但更常见的情况是找到数据库密码、其他用户的SSH密钥或.netrc文件中的FTP密码等。拿到这些凭证后需要判断其用途和权限范围。例如拿到一个MySQL root密码可以尝试写入Web目录的PHP shell拿到一个普通用户的SSH密钥可以登录后继续在该用户环境下进行新一轮的信息收集和提权尝试如检查该用户的sudo权限。4. 防御策略如何让你的系统对密码搜寻“免疫”了解了攻击者的手法防御就变得有的放矢。目标就是大幅增加攻击者搜寻密码的难度和成本甚至让其一无所获。4.1 权限最小化原则收紧每一道门这是最根本、最有效的防御措施。文件与目录权限严格遵守最小权限原则。配置文件尤其是含密码的应设置为仅所有者可读600必要时所有者可写700对于目录。例如chmod 600 /etc/mysql/debian.cnf chmod 700 /home/user/.ssh chmod 600 /home/user/.ssh/id_rsa用户与进程隔离运行业务服务的用户如www-datamysqlredis应该是非登录、无特权用户。确保他们的家目录不存在或为空并且其Shell设置为/usr/sbin/nologin。避免使用root用户直接运行应用程序。SUID/SGID文件审查定期使用find / -type f -perm /6000 2/dev/null检查系统中的SUID/SGID文件移除不必要的特权设置。攻击者会利用这些文件进行提权。4.2 密码与密钥管理消除明文安全存储杜绝硬编码绝对禁止在脚本、配置文件或代码中硬编码明文密码。这是最低级的错误。使用密码管理器或密钥库对于应用程序使用环境变量但需注意进程内存泄露风险、或专门的密钥管理服务如HashiCorp Vault AWS Secrets Manager。在Docker或Kubernetes中使用Secrets对象。强化SSH密钥为SSH私钥设置强密码passphrase。虽然这不能防止私钥被窃取后的离线破解但大大增加了攻击难度。使用密码哈希对于必须存储的密码如数据库用户密码确保存储的是加盐的强哈希值如bcrypt Argon2而非明文或弱加密如base64。4.3 系统加固与监控主动发现与响应定期安全审计可以定期以非特权用户身份在测试环境中运行LinPEAS等自动化审计脚本模拟攻击者的视角发现自身系统的信息泄露点。日志集中与分析确保系统日志auth.logsyslog和应用日志被妥善收集到安全的、只有管理员可访问的日志服务器。监控日志中异常的文件访问行为如大量grep、find命令、失败的sudo/su尝试。文件完整性监控使用工具如AIDEAdvanced Intrusion Detection Environment或Tripwire对关键的系统文件和配置文件建立基线监控其是否被篡改。清理历史与临时文件在~/.bashrc或全局配置中设置HISTCONTROLignorespace命令前加空格不记录和HISTCONTROLignoreboth并考虑设置HISTSIZE和HISTFILESIZE为合理大小。定期清理/tmp/var/tmp目录。配置文本编辑器如vim不要产生.swp交换文件或将其指向安全位置。4.4 安全意识最薄弱的一环所有技术措施都离不开人的执行。代码审查在代码提交环节严格审查是否包含硬编码的密钥、密码或内部服务地址。备份文件管理备份文件应享有与源文件同等级别的安全保护不能因为它是备份就随意设置权限。最小化信息泄露应用程序的错误信息应进行泛化处理避免将数据库连接字符串、堆栈跟踪等详细信息直接返回给用户。5. 进阶技巧与深度问题排查即使遵循了最佳实践在复杂的生产环境中问题依然可能出现。这里分享一些更深层的排查技巧和可能遇到的“坑”。5.1 当密码不在文件中时内存与进程取证如果你怀疑密码泄露但文件系统层面一无所获那么焦点应该转向运行时环境。检查所有进程的环境变量一个快速但粗糙的方法是ps eww。更精准的方法是遍历/proc/[pid]/environ。编写一个小脚本for pid in $(ls /proc | grep ^[0-9]*$); do if [ -r /proc/$pid/environ ]; then echo PID: $pid strings /proc/$pid/environ | grep -i -E pass|key|token|secret echo fi done 2/dev/null转储进程内存进行分析这需要一定的权限和工具。可以使用gdb附加到进程或使用/proc/$pid/mem需要权限。更专业的方法是使用LiME或rekall等内存取证工具。在应急响应中如果怀疑内存中存在敏感信息应立即对内存进行镜像保存供后续离线分析。检查交换空间交换分区swap可能包含从内存中换出的页面其中或有密码片段。使用strings /dev/sdXN交换分区设备并配合grep搜索但这是一个“大海捞针”的过程。5.2 对抗自动化工具混淆与诱饵高水平的防御者会主动设置一些“陷阱”或增加攻击者的分析成本。文件系统诱饵可以在/home/目录下创建一些看似包含密码的假文件如passwords.txt.bak里面放置一些伪造的、无用的或会触发警报的凭证。当攻击者使用这些凭证时会触发安全监控系统的报警。命令历史混淆在.bashrc中设置别名或函数将常见的敏感命令如mysqlcurl -u替换为会记录日志并发出警告的包装脚本。监控敏感文件访问使用auditdLinux审计框架监控对关键文件如/etc/shadow/root/.bash_history的读取访问尝试。例如sudo auditctl -w /etc/shadow -p rwa -k shadow_access任何读取/etc/shadow的尝试都会被记录并可通过ausearch -k shadow_access查询。5.3 从防御视角进行红队演练最好的防御是知己知彼。定期组织或参与内部的“红队演练”模拟真实攻击。获取一个低权限起点这可以通过授权下的漏洞利用、社会工程学测试如钓鱼获取初始凭证或直接提供一个测试账户来实现。执行搜寻与提权在授权范围内使用我们讨论的所有技术手动自动化工具尝试提权。分析结果无论成功与否详细记录攻击路径、利用的弱点、花费的时间。成功的路径就是需要立即修补的漏洞失败的路径则可以用来评估现有防御措施的有效性。修复与改进根据演练报告系统性地修复发现的问题并更新安全策略和监控规则。这种演练不仅能发现技术漏洞更能检验整个组织的检测与响应能力。例如你的SIEM安全信息与事件管理系统是否及时报警了异常的find / -name *pass*命令安全团队是否在合理时间内响应密码搜寻提权之所以长期有效是因为它利用的是“人的惰性”和“系统的默认状态”。防御的本质就是将这种“默认的不安全状态”转变为“经过设计的、持续维护的安全状态”。这需要技术、流程和意识的结合。对于每一位Linux系统的守护者来说理解攻击者的思维像攻击者一样思考是构建更坚固防线的最佳起点。下次当你编写一个脚本或配置一个服务时不妨多问自己一句“如果有一个不怀好意的人拿到了这个权限他能从这里找到通往root的钥匙吗”