漏洞描述

GitLab 是一个用于仓库管理系统的开源项目，使用 Git 作为代码管理工具，可通过 Web 界面访问公开或私人项目。

在GitLab CE/EE版本14.7(14.7.7之前)、14.8(14.8.5之前)和14.9(14.9.2之前)中使用OmniAuth提供商(如OAuth、LDAP、SAML)注册的帐户设置了硬编码密码，允许攻击者潜在地控制帐户。

漏洞版本

Gitlab CE/EE >=14.7,<14.7.7

Gitlab CE/EE >=14.8,<14.8.5

Gitlab CE/EE >=14.9,<14.9.2

环境搭建

选择 docker hub 上的 gitlab/gitlab-ce:14.7.4-ce.0 版本

Image Layer Details - gitlab/gitlab-ce:14.7.5-ce.0 | Docker Hub

编写docker-compose 文件，使用docker-compose up -d 搭建、端口会映射到本地 8080端口、还将映射三个目录。

version: '3'services:gitlab:image: 'gitlab/gitlab-ce:14.7.4-ce.0'container_name: 'gitlab'restart: alwaysprivileged: truehostname: 'gitlab'environment:TZ: 'Asia/Shanghai'ports:- '8080:80'volumes:- ./config:/etc/gitlab- ./data:/var/opt/gitlab- ./logs:/var/log/gitlab

conf目录下的 gitlab.rb 是配置文件、 initial_root_password 是初始密码文件会，它将会保存24小时。

接下来我们在github 上创建新的 OAuth application 。

Application name 的名字可以随便写。

Homepage URL 是gitlab 的 url ，因为本地搭建且端口映射在8080上

Authorization callback URl 是认证回调url ，用户被 GitHub 重定向的站点

Homepage 填写： http://127.0.0.1:8080

Callback url 填写：http://127.0.0.1:8080/users/auth/github/callback

但Callback 如果这样填写的话会出一个问题,这个后面再说。

点击 Register application 注册成功，会获取到 Client ID 、 Client secrets( 点击 Generate a new client secret 去创建一个新的secret )

在gitlab的配置文件中开启Oauth 认证，我们cd 到 /config/gitlab.rb 然后去追加一些代码。

将刚刚获取创建到的 app_id app_secret 添加上。

### OmniAuth Settings

###! Docs: https://docs.gitlab.com/ee/integration/omniauth.html

gitlab_rails['omniauth_allow_single_sign_on'] = ['github']

gitlab_rails['omniauth_auto_link_ldap_user'] = true

gitlab_rails['omniauth_block_auto_created_users'] = true

gitlab_rails['omniauth_providers'] = [

{

name: "github",

app_id: "APP_IP",

app_secret: "APP_SECRET",

args: { scope: "user:email" }

}

]

访问本地 8080端口、到此环境已经搭建成功。

漏洞复现

漏洞原理

Github OAuth app 采用了OAuth2。在我们认识漏洞之前，先简单了解一下 OAuth2。

传统的身份验证模型：

在传统的客户端-服务器身份验证模型中，客户端通过使用资源所有者的凭据向服务器进行身份验证来请求服务器上的访问受限制的资源（受保护的资源）。为了向第三方应用程序提供对受限资源的访问权限，资源所有者与第三方共享其凭据。

传统的身份验证模型中会存在哪些问题和限制呢？

- 第三方应用程序会以明文的形式存储存储资源所有者的凭据。

- 任何第三方应用程序的泄露都会导致最终用户的密码以及受该密码保护的所有数据受损。

还有别的问题和限制。感兴趣的朋友可以去了解一下 [rfc6749](http://www.rfcreader.com/#rfc6749)。

OAuth2是如何解决的呢？

OAuth2 通过引入授权层并将客户端的角色与资源所有者的角色分开来解决这些问题。在 OAuth2 中，客户端请求访问由资源所有者控制并由资源服务器托管的资源，并向其颁发一组与资源所有者不同的凭据。客户端获取访问令牌（表示特定作用域、生存期和其他访问属性的字符串），而不是使用资源所有者的凭据来访问受保护的资源。访问令牌由授权服务器在资源所有者的批准下颁发给第三方客户端。客户端使用访问令牌访问资源服务器承载的受保护资源。）

OAuth2数据流程？

（A）用户打开客户端以后，客户端要求用户给予授权。

（B）用户同意给予客户端授权。

（C）客户端使用上一步获得的授权，向认证服务器申请令牌。

（D）认证服务器对客户端进行认证以后，确认无误，同意发放令牌。

（E）客户端使用令牌，向资源服务器申请获取资源。

（F）资源服务器确认令牌无误，同意向客户端开放资源。

Github中 OAuth web授权流程

A、用户被重定向，以请求他们的 GitHub 身份

B、用户被 GitHub 重定向回您的站点

C、您的应用程序使用用户的访问令牌访问 API

看下Gitlab Diff 记录， password.rb 中定义了默认密码。当使用第三方登录的时候，会自动创建与github同名的账户，默认密码为 123qweQWE!@#000000000

我们在Gitlab登陆页，选择登陆方式为GitHub时：

1、Gitlab会向 http://127.0.0.1:8080/users/auth/github 发起POST请求。

2、http://127.0.0.1:8080/users/auth/github 会重定向到https://github.com/login/oauth/authorize?发起GET请求，携带的参数如下。

client_id : 在gitlab.rb 中填写的app_id

redirect_uri: 授权后重定向到项目的地址，必须和Github OAuth App时的callback url相同

response_type: 表示授权类型，此处的值固定为"code"

Scope: user:email 希望得到的权限范围.

state: 不可猜测的随机字符串。它用于防止跨站点请求伪造攻击。

3、Gitlab发起的 redirect_uri 与在GitHub中填写的callback中不相同时。报了错。

我们在Github填写的Callback 为 http://127.0.0.1:8080/users/auth/github/callback

此时的redirect_uri为。http://gitlab/users/auth/github/callback

在我去想着如何修改 redirect_uri ，做了很多尝试没有用。

4、没有办法的办法下、因为redirect_uri 与callback不同、然后我尝试将Github 的 Callback修改为redirect_uri，将redirect_url ( http://gitlab/users/auth/github/callback) 填到 Callback 看起来太荒谬了。怎么会有这种url。

5、没什么办法，只能先试试吧。先将 Github 的Callback修改为http://gitlab/users/auth/github/callback做尝试。

6、回到gitlab登陆页，点击GitHub登陆、跳转到授权页面。红框标注的是认证后将会跳转到 http://gitlab ,这肯定不对。先往下走吧。再看看这次请求的参数。

7、最后会向GitHub中填写的Callback跳转发起GET请求参数为 http://gitlab/users/auth/github/callback?code=xxxxxxx&state=xxxxxxxx,碰到了糟糕的502。但是，有的好消息是、他有code参数和state参数。

8、当我再翻看OAuth2 的数据流程时，我注意到在第六步时会将 Access Token 发送到Resource Server ，只要将这个请求发到http://127.0.0.1:8080/users/auth/github/callback ,就已经接近完成了。既然GitHub不能自己跳转、我尝试能不能自己去修改。

9、将gitlab 修改为 http://127.0.0.1:8080 ,然后又被跳转到登陆页。出现了以下错误，

您的帐户正在等待您的GitLab管理员的批准，因此被阻止。如果您认为这是一个错误，请联系您的GitLab管理员

登陆root账号查看，存在一个没有激活的账户。

最后利用管理员权限、将用户激活、测试。

注意注册的用户账户名是 GitHub用户名、

密码就是123qweQWE!@#000000000

修复建议

目前官方已经对该漏洞进行了修复，在做好数据备份之后升级到安全版本。

参考材料

https://about.gitlab.com/releases/2022/03/31/critical-security-release-gitlab-14-9-2-released/?fbclid=IwAR0yf94g69dMEKraW-g7SCnfEXlgVrj6dKgpFxoWzonpmwHeaxTrK8l3by8

https://about.gitlab.com/releases/2022/03/31/critical-security-release-gitlab-14-9-2-released/?fbclid=IwAR0yf94g69dMEKraW-g7SCnfEXlgVrj6dKgpFxoWzonpmwHeaxTrK8l3by8critical-security-release-gitlab-14-9-2-released/?fbclid=IwAR0yf94g69dMEKraW-g7SCnfEXlgVrj6dKgpFxoWzonpmwHeaxTrK8l3by8

https://docs.github.com/cn/developers/apps/building-oauth-apps/authorizing-oauth-apps

http://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html

CVE-2022-1162 Gitlab 硬编码漏洞分析相关推荐

【安全狗漏洞通告】Gitlab 硬编码漏洞解决方案
近日,安全狗应急响应中心监测到Gitlab官方发布安全通告,披露了其Gitlab产品存在硬编码漏洞.漏洞编号CVE-2022-1162. 漏洞描述 GitLab 是一个用于代码仓库管理系统的开源项目, ...
CVE-2022-1162 Gitlab 硬编码漏洞复现
目录 0x01 声明: 0x02 简介: 0x03 漏洞概述: 0x04 影响版本: 0x05 环境搭建: Docker环境搭建: 漏洞环境搭建: 创建文件拉取内容: 访问: Github配置: 新 ...
某些厂商防火墙存在硬编码漏洞复现
一.漏洞背景硬编码漏洞简单的说就是密码以加密的形式存在于页面中,如base64 cmd5等形式,我们可以直接通过对应的解密软件进行界面二.漏洞复现祭出fofa大法,fo ...
D-Link 修复多个硬编码密码漏洞
聚焦源代码安全,网罗国内外最新资讯! 编译:奇安信代码卫士 D-Link 发布固件热修复方案,解决了基于 DIR-3040 AC3000 的无线互联网路由器中的多个漏洞. 如成功利用这些漏洞,攻击者 ...
linux与s7-300,Siemens SIMATIC S7-300硬编码凭证安全限制绕过漏洞
发布日期:2011-08-03 更新日期:2011-08-03 受影响系统: Siemens SIMATIC S7-300 描述: ---------------------------------- ...
2022CTF培训（十一）IOT 相关 CVE 漏洞分析
附件下载链接 D-Link DIR-823G 固件全系统仿真 2022CTF培训(十)IOT 相关 CVE 漏洞分析是采用 qemu-user 对个别程序进行仿真,而对于完整的仿真需要使用 qemu ...
从搜狐入侵铱迅信息网站事件，分析编码漏洞问题
从搜狐入侵铱迅事件,分析编码漏洞问题,虽说入侵没有成功,但非常典型的入侵行为,还是值得分析的. 1.在入侵中,黑客没有在任何页面做尝试,直指铱迅信息的search的部分,显示出黑客想一针见血的用心. ...
国产软件CVE漏洞分析系列：泛微OA系统漏洞编号：SSV-91661
今天开始扒拉一下各种国产软件已经公布的漏洞,有些公司自己把漏洞保密起来,其实真是傻啦吧唧的,以为不让大家知道,漏洞就不存在吗!没办法,可能也是为了上市公司的股价吧.普通人对于漏洞的理解还是有点狼来了的 ...
linux内核安全数据,【漏洞分析】Linux内核XFRM权限提升漏洞分析预警（CVE–2017–16939）...
0x00 背景介绍 2017年11月24日, OSS社区披露了一个由独立安全研究员Mohamed Ghannam发现的一处存在于Linux 内核Netlink socket子系统(XFRM)的漏洞,漏 ...

CVE-2022-1162 Gitlab 硬编码漏洞分析