gitlab-gitea-import-ssrf

GitLab CE 19.4.1 - GitLab Inc.

Gitea 가져오기는 UrlBlocker.validate!를 한 번 호출한 뒤, https의 경우 IP로 고정된 URI를 버리고 원래 호스트명을 Faraday에 넘깁니다. Octokit UrlValidation은 다시 검증하지만 env[:url]을 재작성하지 않습니다. 이 두 조회 사이에 이름을 재바인딩하면 GitLab이 마치 Gitea인 것처럼 루프백에 GET 요청을 보냅니다. 저장소 목록 JSON은 GET /import/gitea/status.json으로 반환됩니다. HTTP 가져오기는 고정을 유지합니다. https://127.0.0.1 직접 지정은 차단됩니다.

개인 네임스페이스에서 Gitea 가져오기를 열 수 있는 로그인 사용자는 GitLab이 자신이 루프백으로 재바인딩한 호스트를 가져오도록 만들 수 있으며, 응답 본문을 받습니다.


ID	아직 CVE 없음
CWE	CWE-918, CWE-367
CVSS	High: 7.7 `CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N`
제품	GitLab CE
영향 받는 버전	19.4.1-ce.0 (v19.4.1-ee 트리의 `26212baacadb`)
인증	인증된 사용자, Gitea 가져오기, 개인 네임스페이스
라이선스	GNU Affero GPL v3.0
실습 환경	`127.0.0.1` 전용

공격자가 할 수 있는 일

Gitea Host URL을 https://<공격자가 제어하는 이름>/으로 설정합니다. UrlBlocker는 첫 번째 공인 A 레코드를 허용합니다. HTTPS client_options는 해당 호스트명을 유지합니다. 그런 다음 127.0.0.1로 재바인딩합니다. Faraday는 GitLab 워커의 루프백에서 캐처로 GET 요청을 보냅니다. status.json의 provider_repos는 캐처가 반환한 내용 그대로입니다.

올인원 omnibus 환경에서는 Workhorse, Puma, 익스포터, 그리고 워커에서 수신 대기 중인 다른 모든 서비스가 해당됩니다. 호스트 RCE는 아니며, 인증 없이 가능한 것도 아닙니다. HTTP Host URL은 고정된 IP에 그대로 유지됩니다.

같은 제품의 유사 잔여 취약점: Gitaly fetch가 resolved_address를 생략함, webhook 0.0.0.0/8.

발견 경위

먼저 2026년 9월 23일자 19.4.1 / 19.3.3 / 19.2.7 패치 노트를 읽은 뒤 v19.4.1-ee 트리를 살펴보았습니다. CI 정규식 RCE, MR diff XSS, Workhorse file.path 읽기는 이 버전에서 이미 닫혀 있습니다. 가져오기 SSRF는 완료되지 않은 상태였습니다.

Import::GiteaController#client_options가 바로 그 잔여 부분입니다:

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

HTTP는 verified_url(IP)을 사용합니다. HTTPS는 provider_url(사용자가 입력한 이름)을 사용합니다. LegacyGithubImport::Client는 해당 호스트로부터 Octokit api_endpoint를 구성합니다. Gitlab::Octokit::UrlValidation은 validate!를 호출한 다음 재작성 없이 @app.call(env)를 호출합니다.

기본 gitlab/gitlab-ce:19.4.1-ce.0을 구동했습니다. 로컬 요청은 꺼져 있습니다. Faraday ssl.verify가 true이므로 Lab CA를 /etc/gitlab/trusted-certs에 두었습니다. gitea.lab에 대한 DNS: 조회 1-2는 1.1.1.1을 반환하고, 이후 조회는 127.0.0.1을 반환합니다. Catcher는 :443에서 GitLab netns를 공유합니다. GET /import/gitea/status.json은 GITLAB-GITEA-IMPORT-SSRF-WITNESS라는 이름의 provider_repos를 반환했습니다. Catcher 로그: GET /api/v1/user/repos peer=127.0.0.1 host=gitea.lab.

직접 https://127.0.0.1/ : "Specified URL cannot be used". HTTP http://gitea.lab/는 핀에 머물렀고 witness를 반환하지 않았습니다.

이미 기록된 잘못된 시도들: Accept: application/json을 사용한 /users/sign_in은 404입니다(HTML은 200). 시드 비밀번호 CveLabRoot9!는 root를 포함하므로 거부되었습니다. CA 바인드 마운트 ro는 재구성 시 파일이 링크된 후 EROFS가 됩니다. 조회 2에서 처음 두 개 후 루프백을 사용하면 Faraday가 연결하기 전에 UrlValidation이 차단합니다. 실제로 성공한 것은 쌍 모드(홀수는 공인, 짝수는 루프백)입니다. 리버스 셸. 연극. 오라클은 status.json의 witness와 catcher peer입니다.

Lab

cd lab
./run.sh

오직 http://127.0.0.1:18400만 대상으로 합니다. GitLab CE는 수 GB의 RAM을 필요로 합니다. 첫 부팅은 느립니다. 승인된 실험실에서만 사용하십시오.

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

남은 것

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

HTTP가 이미 처리하는 것과 동일한 방식으로 https에 verified_url.to_s를 사용하세요. Octokit UrlValidation에서 env[:url]을 고정된 IP로 다시 작성하세요.

참고 자료

gitlab.com/gitlab-org/gitlab 태그 v19.4.1-ee
gitea_controller.rb · legacy_github_import/client.rb · octokit/url_validation.rb
동일 제품: gitlab-gitaly-fetch-ssrf · gitlab-webhook-0net-ssrf
CWE-918 · CWE-367

라이선스

GNU Affero GPL v3.0. LICENSE를 참조하세요. 루프백 실험실 전용입니다. 보증은 제공되지 않습니다.

gitlab-gitea-import-ssrf

인기

gitlab-gitea-import-ssrf

공격자가 할 수 있는 일

발견 경위

Lab

남은 것

참고 자료

라이선스