Gitlab侦察介绍 Gitlab渗透测试思路

目录导航

尽管 Gitlab 不像 Github 那样流行，但如今运行它是很常见的。尤其是在微软收购 Github 之后，似乎有更多的个人和组织涌向 Gitlab。

在这篇文章中，我想记录一些在后渗透很有用的侦察命令，供蓝队队员注意。

让我们假设一个人可以访问 Gitlab 令牌作为前体。让我们通过一些有趣的命令和脚本片段来了解更多信息。

找到一个 Gitlab 令牌 – 接下来怎么办？

首先，让我们定义几个将重复使用的环境变量。

TOKEN=$(cat .token)
GITLAB_HOST=[yourserver]
GITLAB_API="https://$GITLAB_HOST/api/v4"

就是这样，这些变量是不言自明的。

我是谁？

一旦找到令牌，第一个明显的命令就是检查它属于哪个用户。

curl --silent --header "Authorization: Bearer $TOKEN" "$GITLAB_API/user" | jq .username

注意：也可以为PRIVATE-TOKENGitlab 实例提供专用的 HTTP 标头。Gitlab 在此处记录了更多有用的信息。

检索项目

使用有效的令牌可以枚举项目：

curl --silent --header "Authorization: Bearer $TOKEN" \
     "$GITLAB_API/projects/owned=true&simple=true&per_page=100" | jq

攻击者可能会寻找他们“拥有”的项目，因此他们可以进行签入，例如签入.gitlab-ci.yml文件以修改/创建 CI/CD 管道。

假设你有一个令牌列表（我们毕竟是红队成员），也可以循环调用 API，如下所示：

TOKENS=$(cat .tokens)
for T in $TOKENS
do
    curl --silent --header "Authorization: Bearer $T" \
         "$GITLAB_API/projects/owned=true&simple=true&per_page=100" | jq 
done

将此信息通过管道传输到文件中以供以后分析也可能很有用。

克隆项目

源代码通常包含明文凭据。为了在代码中搜索秘密和其他信息，Gitlab 提供了利用 API 令牌git从服务器拉取项目的能力。

以下是实际效果：

PROJ_PATH=MyProject/KoiPhish/KoiPhish.git
git -C ./src/ clone "https://gitlab-ci-token:$TOKEN@$GITLAB_HOST/$PROJ_PATH

注意gitlab-ci-tokenURL 中的用户名。还有其他几种方法可以做到这一点。同样，请参阅Gitlab 文档以获取更多详细信息。

枚举 Gitlab CI/CD 变量

Gitlab CI/CD 变量很棒！为什么？因为通常也包含明文秘密！

枚举它们的命令是：

PROJECT_ID=123
curl --silent \
     --header "Authorization: Bearer $TOKEN" \ 
     "$GITLAB_API/projects/$PROJECT_ID/variables" | jq

攻击者可能会在 CI/CD 变量中找到有趣的密码、令牌或访问密钥。

提示：工程师可以保护他们的变量而不是广泛暴露它们。例如，可以使用只能从某些分支访问的受保护变量。

组和实例级变量

等等，还有更多：

Gitlab 也有组，组也可以有变量！
实例级 CI/CD 变量仅供管理员访问。

运行者令牌

在项目详细信息中，我还发现了一个runners_token.

PROJECT_ID=123
curl --silent --header "Authorization: Bearer $TOKEN" \
     "$GITLAB_API/projects/$PROJECT_ID" | jq .runners_token | jq

来自 Gitlab 文档：

注册后，运行者会收到一个身份验证令牌，当从作业队列中提取作业时，它会使用该令牌对 GitLab 进行身份验证。身份验证令牌本地存储在运行程序的 config.toml 文件中。

最初我假设该令牌是身份验证令牌，但它实际上是注册令牌。

我花了一段时间才意识到这一点。最初，我尝试使用以下方法将令牌验证为身份验证令牌：

curl --request POST "$GITLAB_API/runners/verify" --form "token=$RUNNER_TOKEN"

但这没有用。然后我意识到这runners_token是项目 CI/CD 管道页面中显示的注册令牌。因此，获得访问权限意味着您可以注册自己的RUNNER！

更多关于 Runners 注册如何工作的信息可以在这里找到。

有趣的是，就在两天前，Gitlab 发布了一个关于 Runner Registration Tokens的关键 CVE 。

SSH 密钥

管理员还可以为用户获取 SSH 密钥——我还没有尝试过，但似乎这些功能之一不应该存在，我想指出这一点。

检测访问异常和缓解措施

在较高的层面上，防御者面临的最大挑战是，令牌何时被盗并不明显，无论其使用是否来自合法用户。

对于 Blue Teamers 而言，识别访问异常是识别令牌是否已泄漏并被对手积极滥用的好方法。
使用受保护的分支和受保护的变量也可以帮助限制暴露——因此请教育您的工程师并利用它们。

Gitlab 文档页面上有很多关于如何锁定令牌和运行器的有用信息，因此请查看那里的信息以获取更多详细信息。

结论

这是关于基于 Gitlab 的侦察和 CI/CD 攻击的简短介绍。攻击者滥用 DevOps 基础设施确实有很多有趣的途径。一旦获得对 DevOps 基础设施的访问权限，就有大量信息可供访问。请留意，因为我将发布更多有趣的研究。

参考

from

转载请注明出处及链接