Skip to content
GitLab
Next
    • GitLab: the DevOps platform
    • Explore GitLab
    • Install GitLab
    • How GitLab compares
    • Get started
    • GitLab docs
    • GitLab Learn
  • Pricing
  • Talk to an expert
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
    Projects Groups Topics Snippets
  • Register
  • Sign in
  • GitLab GitLab
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
    • Locked files
  • Issues 54.9k
    • Issues 54.9k
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 1.5k
    • Merge requests 1.5k
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Artifacts
    • Schedules
    • Test cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Container Registry
    • Terraform modules
    • Model experiments
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GitLab.orgGitLab.org
  • GitLabGitLab
  • Issues
  • #294178
Closed
Open
Issue created Dec 16, 2020 by GitLab SecurityBot@gitlab-securitybotReporter

Unauthenticated CI lint API may lead to information disclosure and SSRF

HackerOne report #1059596 by myster on 2020-12-15:

Report | How To Reproduce

Report

HI!

CI Lint API (https://docs.gitlab.com/ee/api/lint.html) allows anonymous access for anyone to validate yaml syntax which in itself is not really an issue however use of remote includes may result in an abuse of this unauthenticated API endpoint.

Scenario 1:

An administrator enables internal requests to use Webhooks with internal services assuming its safe to do because all users are part of the organization and can be trusted.

This would also allow an attacker to abuse the CI Lint Api with remote includes to perform internal network requests.

PoC .gitlab-ci.yml:

include:  
  remote: 'http://127.0.0.1:9100/b.yml'  

curl request:

curl -s -H 'Content-Type: application/json' https://redacted/api/v4/ci/lint --data '{ "include_merged_yaml": true, "content": "include:\n  remote: 'http://127.0.0.1:9100/b.yml'" }'  

response (if port is open):

    "Included file `http://127.0.0.1:9100/b.yml` does not have valid YAML syntax!"  

Scenario 2:

Let's assume that internal requests are blocked. Even in such a scenario, following risks are present:

  1. Abuse of the Gitlab instance as a proxy to port scan remote targets (I know there are a lot of such proxies out there, but still there should at least be an option to disallow this)

  2. Disclosure of origin IP address + User agent of Gitlab instance when its running behind a load balancer or services like Cloudflare for DDoS protection.

Therefore, I think this endpoint should not be public by default and enforcing authentication might be a good idea allowing a toggle to disable it if one is aware of potential risks here.

Thanks!

Impact

  • Origin IP address disclosure
  • Unauthenticated SSRF when an admin whitelists internal endpoints for Authenticated users

How To Reproduce

Please add reproducibility information to this section:

Proposal

#294178 (comment 484606184)

Edited Feb 15, 2021 by Dominic Couture
Assignee
Assign to
Time tracking