Skip to content
KitploitKITPLOIT
FerramentasExploitsBlog
Log in
Enviar
FerramentasExploitsBlog
Enviar

Ferramentas de Hacking, PenTest e Cibersegurança para o seu Arsenal de Segurança!

Kitploit é um diretório de ferramentas de hacking, cibersegurança e pentesting. Descubra as últimas atualizações de projetos para encontrar vulnerabilidades, analisar sistemas, automatizar testes e fortalecer sua segurança.

FeedsContatoPrivacidade© 2026 Kitploit

Diretório de Ferramentas

Categorias

Ver todas as categorias
Loading categories
gitlab-gitea-import-ssrf — GitLab - Alta - SSRF na importação HTTPS do Gitea - UrlBlocker pin drop | Kitploit
Ferramentas/GitHubGitHub/abraxas/gitlab-gitea-import-ssrf
Análise de VulnerabilidadesExploraçãoExploração de Aplicações WebSegurança WebTestes de PenetraçãoLabs e Prática
GitHubabraxas/gitlab-gitea-import-ssrf

gitlab-gitea-import-ssrf

GitLab - Alta - SSRF na importação HTTPS do Gitea - UrlBlocker pin drop

Ver Repositório
há 15 diasAinda não revisado

Mais Populares

Ver todos →

Descubra as ferramentas mais usadas pela nossa comunidade.

Explore todas as ferramentas

Navegue pela nossa coleção de ferramentas

Ver todas as ferramentas →
Compartilhar

Abraxas Labs - gitlab-gitea-import-ssrf

abraxaslabs.tech  ·  github.com/abraxas  ·  @abraxas_null  ·  [email protected]  ·  gitlab-gitea-import-ssrf

gitlab-gitea-import-ssrf

GitLab CE 19.4.1 - GitLab Inc.

A importação do Gitea chama UrlBlocker.validate! uma vez e, em seguida, para https, descarta a URI fixada por IP e entrega ao Faraday o hostname original. O UrlValidation do Octokit valida novamente e não reescreve env[:url]. Faça o rebind do nome entre essas consultas e o GitLab faz GET no loopback como se fosse o Gitea. O JSON da lista de repositórios retorna em GET /import/gitea/status.json. As importações HTTP mantêm o pin. https://127.0.0.1 direto é bloqueado.

Um usuário autenticado que consegue abrir a importação do Gitea em seu namespace pessoal pode fazer o GitLab buscar um host que ele faz rebind para o loopback, e recebe o corpo da resposta.

IDainda sem CVE
CWECWE-918, CWE-367
CVSSAlto: 7.7 CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N
ProdutoGitLab CE
Afetado19.4.1-ce.0 (26212baacadb na árvore v19.4.1-ee)
Autenticaçãousuário autenticado, importação do Gitea, namespace pessoal
LicençaGNU Affero GPL v3.0
Labsomente 127.0.0.1

O que um atacante pode fazer

Defina a URL do Host do Gitea como https://<nome-que-ele-controla>/. O UrlBlocker permite o primeiro registro A público. O client_options de HTTPS mantém esse hostname. Faça o rebind para 127.0.0.1. O Faraday faz GET no catcher no loopback do worker do GitLab. O provider_repos do status.json é o que o catcher retornou.

Em um omnibus all-in-one, isso é o Workhorse, o Puma, os exporters e qualquer outra coisa escutando no worker. Não é RCE no host. Não é não autenticado. A URL de Host HTTP permanece no IP fixado.

Mesmo produto, resquícios irmãos: Gitaly fetch omite resolved_address, webhook 0.0.0.0/8.

Como eu encontrei

Li primeiro as notas de patch de 23 de setembro de 2026 das versões 19.4.1 / 19.3.3 / 19.2.7, depois a árvore v19.4.1-ee. RCE por regex no CI, XSS em diff de MR e leitura de file.path no Workhorse estão fechados neste pin. O SSRF de importação não estava finalizado.

Import::GiteaController#client_options é o resquício:

host: verified_url.scheme == 'https' ? provider_url : verified_url.to_s,

HTTP usa verified_url (IP). HTTPS usa provider_url (o nome que o usuário digitou). LegacyGithubImport::Client monta o api_endpoint do Octokit a partir desse host. Gitlab::Octokit::UrlValidation chama validate! e depois @app.call(env) sem reescrever.

Subi o gitlab/gitlab-ce:19.4.1-ce.0 padrão. Local-requests desativado. CA do lab em /etc/gitlab/trusted-certs porque o ssl.verify do Faraday é true. DNS para gitea.lab: as consultas 1-2 retornam 1.1.1.1, consultas posteriores retornam 127.0.0.1. O catcher compartilha o netns do GitLab na :443. GET /import/gitea/status.json retornou provider_repos com o nome GITLAB-GITEA-IMPORT-SSRF-WITNESS. Log do catcher: GET /api/v1/user/repos peer=127.0.0.1 host=gitea.lab.

https://127.0.0.1/ direto: "Specified URL cannot be used". O HTTP http://gitea.lab/ permaneceu no pin e não retornou o witness.

Caminhos errados já registrados: /users/sign_in com Accept: application/json retorna 404 (HTML retorna 200); a senha de seed CveLabRoot9! foi rejeitada porque contém root; bind-mount da CA com ro dá EROFS depois que o reconfigurar cria o link do arquivo; dois primeiros e depois loopback na consulta 2 faz o UrlValidation bloquear antes do Faraday conectar. O modo pairs (ímpar público, par loopback) foi o que funcionou. Um reverse shell. Teatro. O oráculo é o witness no status.json mais o peer do catcher.

Lab

cd lab
./run.sh

Alvo somente http://127.0.0.1:18400. O GitLab CE quer vários GB de RAM. O primeiro boot é lento. Somente lab autorizado.

status.json status=200 ... provider_repos ... GITLAB-GITEA-IMPORT-SSRF-WITNESS
catcher GET /api/v1/user/repos peer=127.0.0.1 host=gitea.lab status=200 witness=True
negative-a https://127.0.0.1 blocked
negative-b http://gitea.lab no-witness
SUCCESS GITLAB-GITEA-IMPORT-SSRF status.json mode=pairs http=200 GITLAB-GITEA-IMPORT-SSRF-WITNESS

O resquício

def client_options
  verified_url, provider_hostname = verify_blocked_uri
  {
    host: verified_url.scheme == 'https' ? provider_url : verified_url.to_s,
    api_version: 'v1',
    hostname: provider_hostname
  }
end

Use verified_url.to_s para https da mesma forma que o HTTP já faz. Reescreva env[:url] no UrlValidation do Octokit para o IP fixado.

Referências

  • gitlab.com/gitlab-org/gitlab tag v19.4.1-ee
  • gitea_controller.rb · legacy_github_import/client.rb · octokit/url_validation.rb
  • Mesmo produto: gitlab-gitaly-fetch-ssrf · gitlab-webhook-0net-ssrf
  • CWE-918 · CWE-367

Licença

GNU Affero GPL v3.0. Veja LICENSE. Somente lab em loopback. Sem garantia.

Baixar ferramenta