
सामान्य वेब सर्वरों का उपयोग करके हालिया CVE-2021-44228 (Log4Shell) भेद्यता के दुरुपयोग के विरुद्ध मज़ेदार चीज़ें।
आम वेब सर्वरों का उपयोग करके हाल की CVE-2021-44228 (Log4Shell) भेद्यता के दुरुपयोग के खिलाफ मज़ेदार चीज़ें।
@shipilev की पोस्ट (https://gist.github.com/shipilev/92e709a868f3d328b6636e1bfc21cf09) के आधार पर मैंने उनके उदाहरण को Apache2 पर पोर्ट किया। एक सहकर्मी ने इसे Lighttpd के लिए किया। मैंने सुविधा के लिए अपने उदाहरणों को सार्वजनिक करने का निर्णय लिया।
अनुरोध हेडर, यूज़र एजेंट या कहीं और "jndi:" स्ट्रिंग डालने के कुछ ही कारण हैं। फिलहाल, मैं केवल एक ही कारण जानता हूँ: CVE-2021-44228 का शोषण। उम्मीद है कि दुनिया कमजोर Log4j संस्करणों के हर कार्यान्वयन को पैच करने में व्यस्त है, तब तक हमलावरों को जितना संभव हो धीमा करना उचित हो सकता है। तो क्या हम उन्हें कुछ गीगाबाइट बकवास परोसें जब वे आपकी सेवाओं का शोषण करने का प्रयास कर रहे हों?
निम्नलिखित कोड स्निपेट Log4Shell 0-Day के खिलाफ आपके डिवाइस और सेवाओं की सुरक्षा नहीं करते हैं! कृपया कमजोर सॉफ़्टवेयर को अपडेट करें, jndi-लुकअप को अक्षम करने के लिए log4j2.formatMsgNoLookups=true का उपयोग करें या जब तक पैच उपलब्ध न हो इसे ऑफ़लाइन ले जाएँ! इसका उपयोग केवल उन सर्वरों पर करें जिनमें Log4j-सक्षम सेवाएँ नहीं हैं! CVE-2021-44228 को कम करने के बारे में अधिक जानकारी: https://research.hisolutions.com/log4shell
यह ${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://${hostName}.} जैसे अस्पष्ट कॉल या "jndi:" भाग को छिपाने की कोशिश करने वाली हर दूसरी चीज़ को भी कवर नहीं करेगा। चूँकि इसका कोई सरल समाधान नहीं है, इसलिए मैं इस समय अधिक उन्नत पहचान तकनीकों को कवर नहीं करूँगा। मुझे अब भी विश्वास है कि अधिकांश हमले इनका उपयोग नहीं करेंगे, इसलिए हम अभी भी अधिकांश स्क्रिप्ट किडीज़ को परेशान कर सकते हैं। :)
Linux पर, कुछ रैंडम HTML संदेश के साथ एक फ़ाइल बनाएँ। कृपया नीचे दिए गए उदाहरण से LOL का उपयोग न करें, क्योंकि इससे हमलावर के लिए हमें बायपास करने के लिए एक सामान्य फ़िल्टर लागू करना आसान हो जाता है। हम फ़ाइल निर्माण की प्रगति दिखाने के लिए pv उपयोगिता का उपयोग कर रहे हैं, आपको इसे अपने पसंदीदा पैकेज मैनेजर के माध्यम से इंस्टॉल करना पड़ सकता है या बस इसे छोड़ दें।
$ awk 'BEGIN { for(c=0;c<10000000;c++) printf "<p>LOL</p>" }' > 100M.html
$ (for I in `seq 1 100`; do cat 100M.html; done) | pv | gzip -9 > 10G.boomgz
$ rm 100M.html
मान लें कि आपका वेब सर्वर www-data के रूप में चलता है, तो www-data के स्वामित्व वाली एक निर्देशिका बनाएँ ताकि हमें हर उस वेबरूट में एक कॉपी अपलोड न करनी पड़े जिसे वेब सर्वर संभवतः सर्व कर रहा है:
mkdir /bombs
mv 10G.boomgz /bombs
chown -R www-data:www-data /bombs
अब मज़ेदार हिस्से के लिए...
देखें https://gist.github.com/shipilev/92e709a868f3d328b6636e1bfc21cf09
सारा श्रेय @shipilev को जाता है
आवश्यक मॉड्यूल सक्षम करें
a2enmod rewrite headers ratelimit
/etc/apache2/sites-enabled पर जाएँ। अपने पसंदीदा संपादक के साथ हर होस्ट कॉन्फ़िगरेशन फ़ाइल खोलें और युक्त प्रत्येक पंक्ति के ठीक ऊपर निम्नलिखित कोड स्निपेट डालें (एक से अधिक हो सकते हैं):
RewriteEngine On
RewriteCond %{THE_REQUEST} "^.*(\${jndi|\${\${).*$" [OR]
RewriteCond %{QUERY_STRING} "^.*(\${jndi|\${\${).*$" [OR]
RewriteCond %{REQUEST_URI} "^.*(\${jndi|\${\${).*$" [OR]
RewriteCond %{HTTP_COOKIE} "^.*(\${jndi|\${\${).*$" [OR]
RewriteCond %{HTTP_HOST} "^.*(\${jndi|\${\${).*$" [OR]
RewriteCond %{REMOTE_HOST} "^.*(\${jndi|\${\${).*$" [OR]
RewriteCond %{REMOTE_USER} "^.*(\${jndi|\${\${).*$" [OR]
RewriteCond %{HTTP_USER_AGENT} "^.*(\${jndi|\${\${).*$" [OR]
RewriteCond %{HTTP_REFERER} "^.*(\${jndi|\${\${).*$"
RewriteRule . /bombs/10G_lol.boomgz [L]
<Files ~ "\.boomgz$">
Header Set Expires "Sat, 1 Jan 2000 00:00:00 GMT"
Header Set Content-Encoding "gzip"
Header Set Content-Type "text/html"
SetOutputFilter RATE_LIMIT
SetEnv rate-limit 100
</Files>
<Directory /bombs>
allow from allow
Require all granted
</Directory>
आप सोच रहे होंगे कि @shipilev के शुरुआती उदाहरण की तुलना में इतने अधिक चर क्यों हैं। मैंने यथासंभव अधिक से अधिक स्थानों को पकड़ने की कोशिश करने का निर्णय लिया। यह बहुत ही दुर्लभ मामलों में सेवाओं को बाधित कर सकता है, इसलिए यदि आप जाँचों के मूल सेट का उपयोग करना चाहते हैं, तो RewriteEngine On कथन के बाद की पहली 7 पंक्तियों को टिप्पणी करें या हटा दें और शेष पंक्तियों से |\${\${ भागों को हटा दें।
आप कोड को एक नई फ़ाइल में भी रख सकते हैं, जैसे /etc/apache2/conf-available/anti-jndi.conf और इसे इस तरह शामिल कर सकते हैं:
Include /etc/apache2/conf-available/anti-jndi.conf
अब फ़ाइल(फ़ाइलों) को सहेजें और Apache2 कॉन्फ़िगरेशन को रीलोड करें:
systemctl reload apache2
यदि सब कुछ ठीक रहा, तो आपको कोई त्रुटि संदेश नहीं मिलना चाहिए।
जल्द आ रहा है
आप जाँच सकते हैं कि क्या आप सफल हुए हैं, अपनी संशोधित वेबसाइट से curl के माध्यम से कनेक्ट करके (your-hostname को उन सेवाओं में से एक के वास्तविक होस्टनाम से बदलना याद रखें जिन्हें आपने अभी संपादित किया है:
curl -s -L your-hostname -A "\${jndi:testing}" | pv > /dev/null
आपको एक प्रोग्रेस बार दिखना चाहिए, जो लगभग 100kb/s डाउनलोड स्पीड दिखा रहा हो। यदि आप इसे रद्द नहीं करते हैं, तो यह कुछ मिनटों के बाद समाप्त हो जाना चाहिए, यह इस बात पर निर्भर करता है कि आपने प्रारंभिक HTML फ़ाइल में स्ट्रिंग के रूप में क्या उपयोग किया था। मेरे लिए, इसमें लगभग 5 मिनट लगे। अब देखें कि क्लाइंट साइड पर क्या हो रहा है:
curl -s --compressed -L your-hostname -A "\${jndi:testing}" | pv > /dev/null
देखिए कैसे यह अब 100kb/s नहीं रहा? कम्प्रेशन अपना जादू दिखाता है, क्लाइंट साइड पर यह कुछ गीगाबाइट है। इसलिए कुछ मिनटों तक बकवास का ढेर डाउनलोड करने के बाद, हमलावर के पास कुछ गीगाबाइट पड़े होते हैं, बशर्ते डेटा विश्लेषण के लिए संग्रहीत किया गया हो। कौन जानता है? :)