काही आठवड्यांपूर्वी Log4j च्या सुरक्षेच्या समस्येच्या बातम्यांमुळे नेटवर्कवरील अनेक वापरकर्त्यांना उलटे वळवले गेले होते आणि हे असे आहे की ही त्रुटींपैकी एक आहे ज्याचा सर्वात जास्त फायदा घेतला गेला आहे आणि ज्याला अनेक तज्ञांनी "सर्वात धोकादायक" म्हणून लेबल केले आहे. दीर्घकाळ », नेटवर्कमध्ये ज्ञात असलेल्या असुरक्षांपैकी आम्ही त्यापैकी काहींबद्दल बोलतो ब्लॉगवर आणि यावेळी आम्हाला दुसरी बातमी सापडली आहे.
आणि काही दिवसांपूर्वीची गोष्ट आहे Log4j 2 लायब्ररीमध्‍ये आणखी एक असुरक्षा ओळखण्‍यात आली अशी बातमी प्रसिद्ध झाली (जे आधीच CVE-2021-45105 अंतर्गत सूचीबद्ध आहे) आणि जे, मागील दोन समस्यांप्रमाणे, धोकादायक म्हणून वर्गीकृत केले गेले होते, परंतु गंभीर नाही.
नवीन समस्या सेवा नाकारण्यास अनुमती देते आणि लूप आणि असामान्य समाप्तीच्या स्वरूपात प्रकट होते काही ओळींवर प्रक्रिया करताना.
असुरक्षितता $ {ctx: var} सारख्या संदर्भ शोध वापरणाऱ्या प्रणालींना प्रभावित करते, लॉग आउटपुट स्वरूप निर्धारित करण्यासाठी.
अगोदर निर्देश केलेल्या बाबीसंबंधी बोलताना Log4j आवृत्ती 2.0-alpha1 ते 2.16.0 मध्ये अनियंत्रित पुनरावृत्तीपासून संरक्षणाचा अभाव आहे, काय प्रतिस्थापनामध्ये वापरलेले मूल्य हाताळण्यासाठी आक्रमणकर्त्याला अनुमती दिली एक अंतहीन लूप तयार करण्यासाठी ज्यामुळे स्टॅकवरील जागा संपेल आणि प्रक्रिया थांबेल. विशेषतः, "$ {$ {:: - $ {:: - $$ {:: - j}}}}" सारखी मूल्ये बदलताना समस्या आली.
तसेच, हे लक्षात घेतले जाऊ शकते की ब्लूमिरा संशोधकांनी असुरक्षित Java अनुप्रयोगांवर हल्ला करण्याचा प्रस्ताव दिला आहे जे बाह्य नेटवर्कच्या विनंत्या स्वीकारत नाहीत, उदाहरणार्थ, डेव्हलपर किंवा Java ऍप्लिकेशन्सच्या वापरकर्त्यांच्या सिस्टमवर अशा प्रकारे हल्ला केला जाऊ शकतो.
पद्धतीचा सार असा आहे की जर असुरक्षित Java प्रक्रिया असतील तर वापरकर्त्याच्या सिस्टमवर जे फक्त स्थानिक होस्ट (लोकलहोस्ट) कडून नेटवर्क कनेक्शन स्वीकारतात किंवा RMI-विनंत्यांची प्रक्रिया करतात (रिमोट मेथड इनव्होकेशन, पोर्ट 1099), हल्ला निष्पादित JavaScript कोडद्वारे केला जाऊ शकतो जेव्हा वापरकर्ता ब्राउझरमध्ये दुर्भावनापूर्ण पृष्ठ उघडतो. अशा हल्ल्यात जावा ऍप्लिकेशनच्या नेटवर्क पोर्टशी कनेक्शन स्थापित करण्यासाठी, WebSocket API वापरला जातो, ज्यावर HTTP विनंत्यांप्रमाणे, समान-उत्पत्तीचे कोणतेही निर्बंध लागू केले जात नाहीत (वेबसॉकेटचा वापर स्थानिक नेटवर्कवरील नेटवर्क पोर्ट स्कॅन करण्यासाठी देखील केला जाऊ शकतो. उपलब्ध नेटवर्क ड्रायव्हर्स निर्धारित करण्यासाठी होस्ट).
Google द्वारे प्रकाशित Log4j सह अवलंबनांशी संबंधित लायब्ररींच्या असुरक्षिततेचे मूल्यमापन करण्याचे परिणाम देखील स्वारस्यपूर्ण आहेत. Google च्या मते, समस्या मावेन सेंट्रल रेपॉजिटरीमधील सर्व पॅकेजपैकी 8% प्रभावित करते.
विशेषतः, प्रत्यक्ष आणि अप्रत्यक्ष अवलंबित्वांसह 35863 Log4j संबंधित Java पॅकेजेस असुरक्षिततेच्या संपर्कात आले होते. या बदल्यात, Log4j केवळ 17% प्रकरणांमध्ये प्रथम स्तरावर थेट अवलंबित्व म्हणून वापरले जाते आणि असुरक्षिततेने कव्हर केलेल्या 83% पॅकेजेसमध्ये, Log4j वर अवलंबून असलेल्या इंटरमीडिएट पॅकेजेसद्वारे बंधनकारक केले जाते, म्हणजेच सांगा. दुसऱ्या आणि सर्वोच्च स्तरावर अवलंबित्व (21% - दुसरा स्तर, 12% - तिसरा, 14% - चौथा, 26% - पाचवा, 6% - सहावा).
असुरक्षिततेच्या दुरुस्तीच्या दराने अद्याप बरेच काही हवे आहे, असुरक्षितता ओळखल्याच्या एका आठवड्यानंतर, 35863 पॅकेजेसपैकी ओळखल्या गेल्या, समस्या आतापर्यंत फक्त 4620 मध्ये, म्हणजेच 13% पर्यंत निश्चित केली गेली आहे.
अवलंबित्व आवश्यकता अद्ययावत करण्यासाठी आणि Log4j 2 च्या निश्चित आवृत्त्यांसह जुन्या आवृत्तीचे बंधन बदलण्यासाठी पॅकेज बदल आवश्यक आहेत (जावा पॅकेजेस विशिष्ट आवृत्तीसाठी बंधनकारक आहेत, आणि नवीनतम आवृत्ती स्थापित करण्यास परवानगी देणारी खुली श्रेणी नाही).
Java ऍप्लिकेशन्समधील भेद्यता दूर करणे या वस्तुस्थितीमुळे बाधित होते की प्रोग्राम्समध्ये अनेकदा लायब्ररीची प्रत वितरणामध्ये समाविष्ट असते आणि सिस्टम पॅकेजमध्ये Log4j 2 आवृत्ती अपडेट करणे पुरेसे नसते.
दरम्यान, यू.एस. एजन्सी फॉर इन्फ्रास्ट्रक्चर प्रोटेक्शन अँड सायबर सिक्युरिटीने एक आणीबाणी निर्देश जारी केला ज्यामध्ये फेडरल एजन्सींना Log4j असुरक्षिततेमुळे प्रभावित माहिती प्रणाली ओळखणे आणि समस्या अवरोधित करणारी अद्यतने स्थापित करणे आवश्यक आहे. 23 डिसेंबरपूर्वी.
दुसरीकडे, 28 डिसेंबरपर्यंत एक मार्गदर्शक सूचना देण्यात आली होती, ज्यामध्ये संस्थांनी केलेल्या कामाचा अहवाल देण्याचे बंधन होते. समस्याग्रस्त प्रणालींची ओळख सुलभ करण्यासाठी, उत्पादनांची यादी तयार केली गेली आहे ज्यामध्ये असुरक्षिततेची पुष्टी केली गेली आहे (यादीमध्ये 23 हजारांहून अधिक अनुप्रयोग आहेत).
शेवटी, हे लक्षात घेण्यासारखे आहे की काही दिवसांपूर्वी प्रकाशित झालेल्या Log4j 2.17 मध्ये भेद्यता निश्चित करण्यात आली होती. आणि ज्या वापरकर्त्यांनी अद्यतने अक्षम केली आहेत त्यांना संबंधित अद्यतन पूर्ण करण्याची शिफारस केली जाते, या व्यतिरिक्त असुरक्षिततेचा धोका कमी केला जातो की समस्या फक्त Java 8 सह सिस्टमवर प्रकट होते.
स्त्रोत: https://logging.apache.org/