renaudbako/Web-Exploitation-Scenario-6

# Web-Exploitation-Scenario-6 Web 渗透到 Linux 权限提升 # 执行摘要 通过利用 NoSQL 注入劫持管理会话，我恢复了用户 **sherpa** 的凭据以建立横向立足点，最终利用在用户家目录中发现不安全存储的敏感 SSH 密钥和数据库标识符获得了完整的系统 root 访问权限。 # 服务发现与初始访问 Nmap 扫描结果  步骤 1：NoSQL 注入 该漏洞源于 Node.js 应用程序未对输入对象进行清理。通过注入 `$ne`（不等于）操作符，数据库查询被操纵为返回数据库中的第一个用户（通常是管理员），无论实际密码是什么。    步骤 2：JWT 捕获与认证 成功绕过之后，服务器颁发了一个 JSON Web 令牌（JWT）。 利用方式：将此令牌存储在浏览器 Cookie 中，我成功伪装为 `userId: 65dc88c4e82b0c54b919b2aa`（管理员），从而在无需知晓密码的情况下访问受保护的 `/dashboard` 路由。  步骤 3：仪表板数据渗出 管理仪表板充当了敏感系统信息的中央存储库。 发现：在仪表板界面中，我找到了一个 SSH 身份标识（ID）。 意义：这有效地在 Web 应用程序与底层操作系统之间建立了桥梁。  # 建立立足点 使用发现的凭据，我建立了 SSH 会话  在此阶段，我受限于 **sherpa** 组（GID: 1000）的权限。 # 最终系统接管 整个服务器的沦陷源于 `/home` 目录中糟糕的目录卫生习惯。 Root SSH 密钥：我定位到了 `sherpa` 可访问的 `root_id_rsa`。在加固环境中，此密钥应仅存在于 `/root/.ssh/` 且对任何非 root 用户不可访问。 在 `sherpa` 家目录中找到 root 的 SSH 密钥后，最终的提权变得微不足道。  # 修复措施 # 1. 应用层：防止 NoSQL 注入 初始入口点之所以存在，是因为应用程序将 MongoDB 操作符（如 `$ne`）作为有效输入接受。 输入验证与清理：使用 Joi、Zod 或 Yup 等模式验证库，确保登录字段严格为字符串且不包含对象。 使用对象文档映射器（ODM）：使用 Mongoose 并配合严格定义的 Schema 有助于防止任意对象注入。 安全头部：在 Express 中实现 Helmet 中间件以设置安全头部并缓解常见 Web 漏洞。 # 2. 身份与访问管理（IAM） 在仪表板中捕获 JWT 与发现凭证代表了会话管理与密钥管理的失败。 轮换 JWT 密钥：立即更改 `.env` 文件中的 `JWT_SECRET` 以使任何已被劫持的会话失效。 安全的 Cookie 属性：将 JWT Cookie 设置为 `HttpOnly`（防止 JS 访问）、`Secure`（确保 HTTPS 传输）、`SameSite=Strict`（缓解 CSRF）。 从 UI 移除密钥：敏感信息如 SSH 凭据或密码绝不应在 Web 仪表板中渲染。应使用专用的密钥管理器（例如 HashiCorp Vault 或 AWS Secrets Manager）。 # 3. 操作系统与横向移动 从 sherpa 到 root 的跳转是由于糟糕的文件卫生习惯所致。 保护 SSH 密钥：* 将所有私钥移至其各自的 `.ssh` 目录（例如 `/root/.ssh/`）。 应用严格权限：对目录设置 `chmod 700`，对私钥文件设置 `chmod 600`。 永远不要将 root 私钥存储在普通用户的 `/home` 目录中。 审计文件权限：使用 `find /home -type f -name "*id_rsa*"` 等命令定期识别 misplaced 的密钥。 限制 root 登录：编辑 `/etc/ssh/sshd_config` 设置 `PermitRootLogin No` 或 `PermitRootLogin prohibit-password`，强制用户使用 `sudo` 而非直接 root 访问。 修复日志权限：确保 `/var/log/` 中的系统日志不可被全局写入（777）。它们应归 root 或 syslog 所有，并具有 640 或 644 权限，以防止日志投毒或符号链接攻击。

标签：ATT&CK 初始访问, ATT&CK 权限提升, CISA项目, GNU通用公共许可证, JWT 劫持, Linux 提权, MITM代理, Node.js, NoSQL 注入, SEO 关键词, SSH 密钥, Web 渗透, 会话劫持, 内存分配, 凭据窃取, 协议分析, 威胁模拟, 数据库注入, 服务器监控, 权限提升, 横向移动, 编程规范, 网络安全审计