GitLab CVE-2023-7028 भेद्यता वाले अनपैच्ड सर्वर
- GitLab की गंभीर भेद्यता CVE-2023-7028 मंगलवार तक 5,300 से अधिक सर्वरों पर अनपैच्ड रही, जिससे सॉफ़्टवेयर डेवलपर्स के अकाउंट दूरस्थ रूप से हाइजैक किए जा सकते हैं।
- इस बग को अधिकतम CVSS स्कोर 10 मिला, और GitLab ने इसे पहली बार 11 जनवरी को सार्वजनिक किया और पैच जारी किया।
- GitLab लॉगिन सिस्टम की इस कमजोरी के कारण हमलावर, पीड़ित की किसी भी इंटरैक्शन के बिना, किसी अनऑथेंटिकेटेड ईमेल पते पर पासवर्ड रीसेट लिंक भेज सकता है।
पैच जानकारी और भेद्यता परीक्षण परिणाम
- GitLab संस्करण 16.5.6, 16.6.4, 16.7.2 के लिए सुरक्षा अपडेट जारी किए गए हैं, और इन्हें 16.1.6, 16.2.9, 16.3.7, 16.4.5 संस्करणों में भी backport किया गया है।
- एक शोधकर्ता ने GitLab Community Edition संस्करण 16.6.1 में इस बग का परीक्षण किया और AttackerKB पर परिणाम साझा करते हुए कहा कि यह "बहुत प्रभावी है और इसका फायदा उठाना आसान है"।
कमजोर इंस्टेंस की पहचान और घटती प्रवृत्ति
- पैच उपलब्ध होने के लगभग 2 सप्ताह बाद, Shadowserver Foundation ने दुनिया भर में 5,379 कमजोर GitLab इंस्टेंस का पता लगाया।
- अमेरिका और जर्मनी में सबसे अधिक कमजोर इंस्टेंस पाए गए, जिनकी संख्या क्रमशः 964 और 730 थी।
- Shadowserver का डैशबोर्ड टूल दिखाता है कि 24 जनवरी को कमजोर इंस्टेंस की संख्या घटकर 4,652 रह गई।
- Shadowserver के एक प्रवक्ता ने SC Media से पुष्टि में कहा कि कमजोर इंस्टेंस की संख्या में कमी एक सकारात्मक प्रगति है, लेकिन यह तय करने के लिए कि यह वास्तविक प्रवृत्ति है या केवल अस्थायी उतार-चढ़ाव, अभी और समय चाहिए।
GitLab CVE-2023-7028 के compromise indicators
- GitLab Community Edition और GitLab Enterprise Edition के self-managed इंस्टेंस चलाने वाले GitLab ग्राहकों को लॉग की समीक्षा कर यह जांच करनी चाहिए कि कहीं CVE-2023-7028 का दुरुपयोग तो नहीं हुआ।
gitlab-rails/production_json.log में /users/password पाथ के लिए HTTP requests की जांच करें, और देखें कि params.value.email कई ईमेल पतों वाले JSON array के रूप में बना है या नहीं।
gitlabs-rails/audit_json.log में उन एंट्रीज़ की जांच करें जहां meta.caller.id PasswordsController#create है और target_Details कई ईमेल पतों वाले JSON array के रूप में बना है।
- GitLab.com या GitLab Dedicated इंस्टेंस में इस बग के दुरुपयोग का कोई पता नहीं चला।
- GitLab ने दो-चरणीय प्रमाणीकरण (2FA) सक्षम करने की भी सिफारिश की है। इससे CVE-2023-7028 के जरिए अकाउंट takeover रोका जा सकता है, लेकिन अनपैच्ड इंस्टेंस का उपयोग करने वाले यूज़र अभी भी इस जोखिम में हैं कि हमलावर भेद्यता का फायदा उठाकर पासवर्ड रीसेट कर दें और उन्हें उनके अकाउंट से लॉक आउट कर दें।
GN⁺ की राय
- यह लेख GitLab की गंभीर सुरक्षा भेद्यता से जुड़ी महत्वपूर्ण जानकारी देता है। CVE-2023-7028 सॉफ़्टवेयर डेवलपर्स के अकाउंट सुरक्षा के लिए सीधा खतरा बन सकता है, इसलिए उचित कार्रवाई ज़रूरी है।
- पैच उपलब्ध होने के बावजूद दुनिया भर में बड़ी संख्या में सर्वर अब भी कमजोर स्थिति में हैं, जो security awareness और समय पर अपडेट करने के महत्व को रेखांकित करता है।
- यह दो-चरणीय प्रमाणीकरण (2FA) के महत्व को भी सामने लाता है और उपयोगकर्ताओं को अतिरिक्त सुरक्षा उपाय अपनाने की सलाह देकर सुरक्षा के प्रति जागरूकता बढ़ाने का अवसर देता है।
1 टिप्पणियां
Hacker News राय
"मैं account-based web app में 'email address को account से link करने' वाली functionality के ख़तरे के बारे में कहना चाहता हूँ। यह उन चीज़ों में से एक है जिन्हें pentester तुरंत manipulate करने की कोशिश करते हैं, और शुरुआती 2000s से इसमें vulnerabilities मिलती रही हैं। GitLab में भी यही समस्या फिर से सामने आई। GitLab के पास एक बेहतरीन security team है, लेकिन लगता है ऐसे bugs से बचना मुश्किल है। अगर इस कहानी में रुचि रखने वाला कोई सामान्य Hacker News पाठक यह पढ़ रहा है, तो उसे अपना password reset feature, खासकर email linking logic, ज़रूर जाँचना चाहिए।"
"मैं Rails codebase में इस vulnerability को खोजने वाले commit का link साझा कर रहा हूँ: GitLab commit link"
"मैं इस bug से प्रभावित हुआ था। Attack करने के लिए user का email पता होना ज़रूरी है, लेकिन GitLab user ID (1 से बढ़ने वाली संख्या) से जुड़ा एक hidden email address भी होता है। ID 1 या 2 के admin होने की संभावना ज़्यादा होती है, इसलिए वे अच्छे target बनते हैं। Email format '1-user@mail.noreply.<gitlabhost>' जैसा होता है। यह automated attack जैसा लग रहा था, और 2FA ने हमें बचा लिया।"
"Email के ज़रिए password reset, सही तरीके से implement होने पर भी, एक security nightmare है। ज़्यादातर services में इस feature को disable नहीं किया जा सकता, और विकल्प अक्सर सिर्फ enterprise SSO होता है। कुछ services में SMS token के लिए phone number सेट किया जा सकता है, लेकिन email और SMS token दोनों अनिवार्य करने वाला option मैंने नहीं देखा।"
"मैंने एक बार ऐसा bug खोजा था जिसमें login form में password array डालकर account पर brute-force attack किया जा सकता था। वह spam appliance के लिए एक भद्दा web interface था, और यह तय नहीं था कि वह जानबूझकर ऐसा था या किसी PHP beginner ने code लिखा था। उस समय special characters वाला password इस्तेमाल करने वाले user ने इसे खोजा था।"
"यह फिर याद दिलाता है कि GitLab जैसी internal services को ऐसे VPN के पीछे चलाना बेहतर है जहाँ सिर्फ trusted users ही पहुँच सकें।"
"GitLab update automation बहुत आसान है। Docker+Compose में GitLab चलाइए और Watchtower आदि के ज़रिए रोज़ update कर दीजिए। मैं 7 साल से ज़्यादा समय से इसी तरीके से GitLab server चला रहा हूँ और कोई समस्या नहीं हुई। आसपास देखें तो बहुत से GitLab पुराने versions पर हैं, admins आखिर कर क्या रहे हैं?"
"मेरा सिद्धांत है कि किसी भी तरह के internal server को public internet पर expose नहीं करना चाहिए। सिर्फ VPN के ज़रिए access देकर दूसरी defense line बनाई जानी चाहिए।"
"यह एक और reminder है कि हमेशा SSO इस्तेमाल करें और 2FA का उपयोग करना न भूलें।"
"आइए यह मानना छोड़ दें कि Ruby/Rails, सुरक्षित होना ज़रूरी वाले software के लिए सही choice है। मैं समझता हूँ कि GitLab को इससे निपटना पड़ता है, लेकिन आगे चलकर हमें मानना चाहिए कि intelligent और hidden control flow को प्राथमिकता देने वाली languages और frameworks की तुलना में कुछ अधिक simple चीज़ें बेहतर होंगी। मैं production Ruby codebase पर काम करता हूँ, और मुझे साफ़ दिखता है कि abstraction की कई layers को code को बहुत extensible बनाने वाला समझने वाले किसी व्यक्ति की वजह से इसी तरह की समस्या फिर हो सकती है।"