Skip to content
GitLab Next
  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • GitLab FOSS GitLab FOSS
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 0
    • Issues 0
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 0
    • Merge requests 0
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Container Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • Code review
    • Insights
    • Issue
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • GitLab.org
  • GitLab FOSSGitLab FOSS
  • Issues
  • #53242
Closed
Open
Created Oct 26, 2018 by GitLab SecurityBot@gitlab-securitybotReporter

SSRF in project integrations (webhook)

HackerOne report #429147 by nyangawa on 2018-10-26:

Summary: An invalid IP address check could be utilized to access any IP addresses including private IP addresses

Description: The validators in lib/gitlab/url_blocker.rb does not check URL's like http://[0:0:0:0:0:ffff:127.0.0.1]:6379, which is an IPv6 address but used to map to IPv4. Replacing the 127.0.0.1 part to any other IP addresses is also possible.

Steps To Reproduce:

(Add details for how we can reproduce the issue)

  1. Create a webhook in any existing projects, with URL like http://[0:0:0:0:0:ffff:127.0.0.1]:9100
  2. Test the webhook

Supporting Material/References:

I did several harmless tests on Gitlab.com. https://gitlab.com/Nyangawa/www-gitlab-com/hooks/415288

And verified it's possible in my 11.4.0 Gitlab docker instance.

Impact

Due to some limits of Gitlab's web hook, this is an blind SSRF issue without full response printed. But it is still possible for an attacker to send POST requests to internal services to do further penetration to the infrastructure.

Assignee
Assign to
Time tracking