GitLab पासवर्ड रीसेट बग से 5,300 से अधिक सर्वर जोखिम में

 (scmagazine.com)
1 पॉइंट द्वारा GN⁺ 2024-01-29 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • GitLab की CVE-2023-7028 भेद्यता पैच जारी होने के लगभग 2 हफ्ते बाद भी दुनिया भर के 5,379 सर्वरों पर बनी हुई है, जिससे रिमोट डेवलपर अकाउंट takeover हो सकता है
  • समस्या लॉगिन सिस्टम के पासवर्ड रीसेट फ्लो में है, जहां हमलावर पीड़ित की किसी interaction के बिना अपनी unverified email address पर रीसेट लिंक मंगवा सकता है
  • GitLab ने 11 जनवरी 2024 को CVSS 10 स्कोर वाली इस भेद्यता का खुलासा किया और 16.5.6, 16.6.4, 16.7.2 तथा 16.1.6~16.4.5 backport versions के लिए security updates जारी किए
  • Shadowserver Foundation ने 23 जनवरी को 5,379 vulnerable instances का पता लगाया; इनमें अमेरिका के 964 और जर्मनी के 730 सर्वर सबसे अधिक थे, और 24 जनवरी तक यह संख्या घटकर 4,652 रह गई
  • Self-managed GitLab Community Edition और Enterprise Edition चलाने वाले operators को logs में multiple email array के रूप में आए रीसेट requests की जांच करनी चाहिए और अकाउंट takeover का जोखिम घटाने के लिए 2FA सक्षम करना चाहिए

CVE-2023-7028 का जोखिम

  • CVE-2023-7028 GitLab लॉगिन सिस्टम की एक भेद्यता है, जो unpatched GitLab servers पर रिमोट अकाउंट takeover तक ले जा सकती है
  • GitLab ने 11 जनवरी 2024 को इस भेद्यता का पहली बार खुलासा किया और इसे patch किया
  • इस भेद्यता का CVSS स्कोर 10 है, जो सर्वोच्च गंभीरता दर्शाता है
  • हमलावर खास तौर पर तैयार किए गए HTTP request के जरिए पीड़ित की किसी interaction के बिना पासवर्ड रीसेट email अपनी unverified email address पर भेजवा सकता है
  • GitLab Community Edition 16.6.1 पर परीक्षण करने वाले एक researcher ने AttackerKB पर CVE-2023-7028 को “बेहद प्रभावी और exploit करना आसान” बताया

प्रभावित versions और patch

  • GitLab ने निम्न versions के लिए security updates जारी किए
    • 16.5.6
    • 16.6.4
    • 16.7.2
  • patch को निम्न versions में भी backport किया गया
    • 16.1.6
    • 16.2.9
    • 16.3.7
    • 16.4.5

Shadowserver की detection रिपोर्ट

  • Shadowserver Foundation ने 23 जनवरी को, यानी पैच जारी होने के लगभग 2 हफ्ते बाद, दुनिया भर में 5,379 vulnerable GitLab instances का पता लगाया
  • देशों के हिसाब से अमेरिका और जर्मनी में vulnerable instances सबसे ज्यादा थे
    • अमेरिका: 964
    • जर्मनी: 730
  • 24 जनवरी को Shadowserver dashboard पर vulnerable instances की संख्या घटकर 4,652 रह गई
  • Shadowserver के अनुसार यह गिरावट अपने आप में सकारात्मक है, लेकिन यह वास्तविक trend है या scanning में अस्थायी उतार-चढ़ाव, यह तय करने के लिए और समय चाहिए

compromise indicators की जांच कैसे करें

  • Self-managed GitLab Community Edition और GitLab Enterprise Edition ग्राहकों को logs में CVE-2023-7028 exploitation के संकेत जांचने चाहिए
  • जिन logs और conditions की जांच करनी है, वे इस प्रकार हैं
    • gitlab-rails/production_json.log: /users/password path पर आए HTTP requests में params.value.email अगर कई email addresses वाला JSON array हो
    • gitlabs-rails/audit_json.log: meta.caller.id अगर PasswordsController#create हो और target_Details कई email addresses वाला JSON array हो

GitLab.com, GitLab Dedicated, 2FA पर प्रभाव

  • GitLab ने कहा कि उसे GitLab.com या GitLab Dedicated instances पर इस बग के exploit होने का कोई मामला नहीं मिला
  • ग्राहकों को 2FA सक्षम करने की सिफारिश की गई है
  • 2FA, CVE-2023-7028 के जरिए अकाउंट takeover रोकता है, लेकिन unpatched instances पर हमलावर पासवर्ड रीसेट करके उपयोगकर्ता को उसके अकाउंट से lock out कर सकता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-01-29
Hacker News की राय

  • account-based web apps में email address को account से जोड़ने वाला feature मुझे सच में डरावना लगता है
    मुझे इस bug का इतिहास नहीं पता, लेकिन penetration testers जिस area को तुरंत छेड़ते हैं, यह वही है; और यह एक पुराना pattern है, जो 2000s की शुरुआत के standard Unix MTA implementations में password reset mails को कई addresses पर भेजने के लिए trick करने वाली vulnerabilities तक पीछे जाता है
    ऐसा लगता है कि GitLab में feature-rich web framework ने इस attack surface को फिर से जिंदा कर दिया; और अगर किसी आम HN reader की दिलचस्पी जगी हो, तो password reset feature, खासकर email linking logic, जरूर check करना चाहिए
    मुझे लगता था GitLab security team काफी अच्छी है, फिर भी ऐसा bug आया—यह दिखाता है कि इस category के bugs से बचना कितना मुश्किल है

    • दूसरे comment में बताए गए behavior को देखें तो यह bug avoid करना बहुत आसान लगता है
      अगर statically typed language इस्तेमाल की होती, तो जानबूझकर ऐसा बनाए बिना यह होना मुश्किल था; और code review में भी यह इतना साफ दिखता कि colleague कहीं backdoor डालने की कोशिश तो नहीं कर रहा, ऐसा शक हो जाता
    • GitLab security team को अच्छा कहना मुश्किल है
      secondary email address linking feature हाल ही में जोड़ा गया था और यह शुरू से मौजूद feature भी नहीं था, इसलिए लगता है कि account security से जुड़े नए feature की proper abuse testing किए बिना shortcut लिया गया
      इसके अलावा शायद एक CVSS 9.6 CVE भी था, जिसमें integration feature किसी दूसरे user की permissions से commands run कर सकता था
      बाहर से देखने पर लगता है कि feature release की speed, सुरक्षित तरीके से test कर पाने की speed से आगे निकल रही है; और शायद monetization मुश्किल होने की वजह से ऐसा हो
      business perspective से कुछ हद तक समझ आता है, लेकिन अगर self-hosted Git solution का core असल में account management है, तो ऐसे security issues business को ही गिरा सकते हैं
    • अजीब viewpoint है
      email नहीं तो किससे link करना चाहिए? मैंने 20 साल से ज्यादा समय तक बड़े user base वाली site चलाई है; शुरुआत में usernames इस्तेमाल किए थे और वह disaster था
      सबको एक-दूसरे के usernames पता थे, इसलिए password brute-force या reset attempts आसान थे
      समस्या email इस्तेमाल करने में नहीं है, बल्कि login और password recovery logic को जरूरत से ज्यादा complex बनाने, abstractions का excessive इस्तेमाल करने, over-engineering करने, और security-sensitive areas में proper verification के बिना code push करने में है
      GitLab का security history भी देखना चाहिए। साल में कई बार critical exploits आए जिनके कारण GitLab distributions को urgent upgrade करना पड़ा, और security के लिहाज से मैंने जिन products का इस्तेमाल किया है उनमें GitLab सबसे खराब रहा
    • जब भी मुझे कोई गलत password reset mail मिलता है, मैं चिंता करता हूं कि कहीं किसी ने मेरा account hijack करने के लिए मेरे control से बाहर कोई recovery email address चुपके से add तो नहीं कर दिया
      अभी तक मेरे साथ ऐसा नहीं हुआ, लेकिन इस case की तरह दुर्भाग्य से यह पूरी तरह संभव है
    • यह exploit कैसे काम करता है? अगर कोई अच्छी summary वाली post link हो तो जानना चाहूंगा

  • अगर Rails codebase में वह हिस्सा देखना चाहते हैं जिससे यह exploit हुआ, तो fix commit यहां है
    https://gitlab.com/gitlab-org/gitlab/-/commit/c571840ba2f0e9...

    • यह असली fix से ज्यादा follow-up refactoring जैसा लगता है
      fix शायद यहां है: https://gitlab.com/gitlab-org/gitlab/-/commit/abe79e4ec43798...
      recoverable.send_reset_password_instructions(to: email) if recoverable&.persisted? से बदलकर recoverable.send_reset_password_instructions if recoverable&.persisted? किया गया
    • # Concern that overrides the Devise methods / # to send reset password instructions to any verified user email / module RecoverableByAnyEmail—तो क्या यह feature था?
      लेकिन fixed version में भी नाम अभी भी RecoverableByAnyEmail ही है। क्या लोग अपने बदले जा रहे code के आसपास पढ़ते ही नहीं?
    • Ruby ज्यादा नहीं जानता, क्या बता सकते हैं कि error कहां है?

  • हम पर भी यह attack हुआ था, और इसे एक दूसरे “feature” के साथ इस्तेमाल होते देखा जिसने exposure और बढ़ा दिया
    मूल रूप से इस attack के लिए reset किए जाने वाले user का email जानना पड़ता है, लेकिन GitLab user ID से बंधा हुआ एक hidden email address होता है। यह ID 1 से बढ़ने वाला number है
    ID 1 या 2 के admin होने की संभावना ज्यादा होती है, इसलिए वे अच्छे target बनते हैं, और email 1-user@mail.noreply.. जैसी form में होता है
    यह सच में खराब था और automated जैसा लग रहा था। यहां 2FA ने बचा लिया

  • email password reset सही तरीके से implement करने पर भी security nightmare है
    इससे भी बुरी बात यह है कि ज्यादातर services में इसे बंद भी नहीं किया जा सकता, और bypass करने के लिए आम तौर पर Enterprise SSO ही option होता है
    कुछ services SMS token के लिए phone number set करने देती हैं, लेकिन email और SMS token दोनों require करने वाला तरीका मैंने नहीं देखा

    • किस तरह से इसे security nightmare मानते हैं, यह जानना चाहूंगा

  • मुझे वह bug याद आ गया जिसमें login form में password array डालने पर account को brute-force किया जा सकता था
    बदकिस्मती से वह spam device का घटिया web interface था, और पता नहीं वह intentional था या किसी PHP beginner का लिखा code
    उस समय password में special character रखने वाले एक user ने, जो तब rare था, यह खोजा था

    • Ruby on Rails में ORM के .where(...) parameter में array देने पर array values के बीच OR condition की तरह process होता है
      इसलिए अगर code User.where(name: name, password: password) जैसा था, तो ऐसा होना काफी plausible लगता है

  • यह एक अच्छा reminder है कि GitLab जैसी internal services को सिर्फ trusted users की पहुंच वाले VPN के पीछे रखना चाहिए

    • सच में समझ नहीं आता कि internal version control और CI/CD को public internet पर क्यों रखा जाता है
      VPN इसी तरह के use case के लिए होता है
    • सही है, हम भी इसी वजह से बच गए, और कुछ दूसरे safeguards भी थे
      मैं एक बड़ी सरकारी telecom company में काम करता हूं, और network वाले लोग वाकई बहुत अच्छे हैं। वे server वालों को सीमा पार नहीं करने देते
      कुछ external projects और consultants के लिए हमने GitLab को कुछ हद तक expose किया था, लेकिन फिर भी internet से freely access नहीं किया जा सकता
      users भी AD में manage होते हैं, इसलिए password reset के लिए SMTP connection ही नहीं है
      हालांकि 2FA enforce करना और मजबूत करना होगा। फिलहाल हर project को अपने 2FA rules खुद तय करने दिए गए हैं

  • सच कहूं तो मैं कोई भी internal server public internet पर नहीं रखूंगा
    सिर्फ VPN से access कराकर second line of defense रखना बेहतर है

    • खासकर GitLab जैसी चीज़ों में external integrations से बहुत फायदा हो सकता है जिन्हें GitLab API call करनी होती है
      बिल्कुल उन्हीं requests को allowlist में डालना भी संभव है, लेकिन यह काफी झंझट वाला हो सकता है
    • code forge चलाने के लिए GitLab मेरी पसंदीदा choice है: git.drk.sc
      high-security environment हो तो ज्यादा defensive tactics अपनाने से सहमत हूं, लेकिन मेरा मानना है कि software को public web पर भी टिक पाने के लिए design किया जाना चाहिए
    • सही है, खासकर अगर company self-hosted GitLab इस्तेमाल करती है तो उसे हमेशा company VPN के पीछे रखना चाहिए

  • GitLab updates automate करना वाकई आसान है
    सिर्फ एक तरीका देखें तो Docker+Compose के साथ GitLab चलाना बहुत stable है, और Watchtower जैसे tools से रोज़ update कराया जा सकता है
    मेरे पास 7 साल से ज्यादा समय से ऐसे चल रहे दो GitLab servers हैं और कोई समस्या नहीं आई
    आसपास इतने पुराने GitLab instances दिखते हैं कि समझ नहीं आता admins आखिर कर क्या रहे हैं

  • अब यह दिखावा बंद होना चाहिए कि Ruby/Rails security-critical software के लिए अच्छा choice है
    समझता हूं कि GitLab पहले ही इस पर बन चुका है, इसलिए उसे संभालना पड़ेगा, लेकिन आगे से यह दिखावा बंद होना चाहिए कि cleverness और hidden control flow को priority देने वाली languages और frameworks ज्यादा boring alternatives से बेहतर हैं
    अगर मैं बहुत ज्यादा चिढ़ा हुआ लग रहा हूं, तो वजह यह है कि मुझे production में चल रहे Ruby codebase से निपटना पड़ता है
    किसी ने सोचा कि abstraction की 17 layers code को बहुत scalable बना देंगी, और उसी वजह से मुझे ऐसे काफी scenarios दिखते हैं जहां इसी तरह के issues exploit होने का इंतज़ार कर रहे हैं

    • मुझे लगता है ऐसी language या framework से बचना बेहतर है जो caller को किसी parameter को string या strings की array के रूप में specify करने दे
      इस एक गलती की cost, उस feature के इस्तेमाल से मिली कुल value से ज्यादा होने की संभावना है

  • SSO और 2FA हमेशा इस्तेमाल करने का यह एक और reminder है