Skip to content
KitploitKITPLOIT
उपकरणएक्सप्लॉइटब्लॉग
Log in
जमा करें
उपकरणएक्सप्लॉइटब्लॉग
जमा करें

हैकिंग, पेनटेस्ट और साइबर सुरक्षा उपकरण आपके सुरक्षा शस्त्रागार के लिए!

Kitploit हैकिंग, साइबर सुरक्षा और पेंटेस्टिंग टूल्स की एक निर्देशिका है। कमजोरियों को खोजने, सिस्टम का विश्लेषण करने, परीक्षण को स्वचालित करने और अपनी सुरक्षा को मजबूत करने के लिए नवीनतम प्रोजेक्ट अपडेट खोजें।

फ़ीडसंपर्कगोपनीयता© 2026 Kitploit

टूल निर्देशिका

श्रेणियाँ

सभी श्रेणियाँ देखें
Loading categories
gitlab-gitea-import-ssrf — GitLab - उच्च - Gitea HTTPS आयात SSRF - UrlBlocker पिन ड्रॉप | Kitploit
उपकरण/GitHubGitHub/abraxas/gitlab-gitea-import-ssrf
भेद्यता विश्लेषणशोषणवेब एप्लिकेशन शोषणवेब सुरक्षापेनिट्रेशन टेस्टिंगलैब और अभ्यास
GitHubabraxas/gitlab-gitea-import-ssrf

gitlab-gitea-import-ssrf

GitLab - उच्च - Gitea HTTPS आयात SSRF - UrlBlocker पिन ड्रॉप

रिपॉजिटरी देखें
137 दिन पहलेअभी तक समीक्षित नहीं

सबसे लोकप्रिय

सभी देखें →

हमारे समुदाय द्वारा सबसे अधिक उपयोग किए जाने वाले उपकरण खोजें।

सभी उपकरण खोजें

हमारे उपकरणों का संग्रह ब्राउज़ करें

सभी उपकरण देखें →
साझा करें

Abraxas Labs - gitlab-gitea-import-ssrf

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

राइट-अप: https://abraxaslabs.tech/research/gitlab-gitea-import-ssrf

gitlab-gitea-import-ssrf

GitLab CE 19.4.1 - GitLab Inc.

Gitea आयात UrlBlocker.validate! को एक बार कॉल करता है, फिर https के लिए IP-पिन किए गए URI को फेंक देता है और Faraday को मूल होस्टनाम सौंप देता है। Octokit UrlValidation फिर से सत्यापन करता है और env[:url] को फिर से नहीं लिखता। उन लुकअप्स के बीच नाम को रीबाइंड करें और GitLab लूपबैक को GET करता है जैसे वह Gitea हो। रेपो-लिस्ट JSON GET /import/gitea/status.json पर वापस आता है। HTTP आयात पिन बनाए रखते हैं। सीधा https://127.0.0.1 अवरुद्ध है।

एक साइन-इन किया हुआ उपयोगकर्ता जो अपने व्यक्तिगत नेमस्पेस पर Gitea आयात खोल सकता है, GitLab से ऐसा होस्ट फ़ेच करवा सकता है जिसे वह लूपबैक पर रीबाइंड करता है, और उसे बॉडी मिल जाती है।

IDअभी तक कोई CVE नहीं
CWECWE-918, CWE-367
CVSSHigh: 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://<name-they-control>/ पर सेट करें। UrlBlocker पहले सार्वजनिक A-रिकॉर्ड की अनुमति देता है। HTTPS client_options उस होस्टनाम को बनाए रखता है। 127.0.0.1 पर रीबाइंड करें। Faraday GitLab वर्कर लूपबैक पर कैचर को GET करता है। status.json का provider_repos वही होता है जो कैचर ने लौटाया।

ऑल-इन-वन ऑम्निबस पर वह Workhorse, Puma, एक्सपोर्टर, और वर्कर पर सुनने वाला कुछ भी हो सकता है। होस्ट RCE नहीं। अनप्रमाणीकृत नहीं। HTTP Host URL पिन किए गए IP पर ही रहता है।

वही उत्पाद, सहोदर अवशेष: Gitaly fetch resolved_address छोड़ देता है, webhook 0.0.0.0/8।

मैंने इसे कैसे खोजा

मैंने पहले 23 सितंबर 2026 के 19.4.1 / 19.3.3 / 19.2.7 पैच नोट्स पढ़े, फिर v19.4.1-ee ट्री। CI regex RCE, MR diff XSS, Workhorse file.path रीड इस पिन पर बंद हैं। Import 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 को खड़ा किया। Local-requests बंद। /etc/gitlab/trusted-certs में Lab CA क्योंकि Faraday ssl.verify true है। gitea.lab के लिए DNS: lookups 1-2 1.1.1.1 लौटाते हैं, बाद के lookups 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 है); seed पासवर्ड CveLabRoot9! अस्वीकृत क्योंकि इसमें root है; CA bind-mount ro reconfigure के बाद फ़ाइल को लिंक करने पर EROFS है; lookup 2 पर पहले-दो-फिर-loopback करने से UrlValidation Faraday के कनेक्ट होने से पहले ब्लॉक कर देता है। Pairs मोड (विषम public, सम loopback) ही काम आया। एक reverse shell। नाटक। Oracle 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

https के लिए verified_url.to_s का उपयोग उसी तरह करें जैसे HTTP पहले से करता है। Octokit UrlValidation में env[:url] को pinned 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। केवल लूपबैक लैब। कोई वारंटी नहीं।

टूल डाउनलोड करें