聊聊近期公开的几个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

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写的，我瞬间都没想法了。