CVE-2014-0094 के struts1 समाधान के बारे में

परिचय

CVE-2014-0094 का struts1 पर प्रभाव संक्षेप में प्रस्तुत किया गया है। जब तक विशेष रूप से उल्लेख न किया गया हो, सभी संस्करणों की पुष्टि java 1.7.0_02, struts 1.3.10, apache-tomcat-6.0.39 और FreeBSD 8.2 पर की गई थी।

कृपया ध्यान दें कि किसी भी परिस्थिति में स्रोत या लेख की सामग्री की गारंटी नहीं है। साथ ही, जो भी घटना घटित हो, मैं उसके लिए उत्तरदायी नहीं हूँ। विशेष रूप से, यदि इस सामग्री का दुरुपयोग किया जाता है, तो मेरी कोई भागीदारी नहीं है। (हालाँकि ऐसा कहने से कुछ नया नहीं होता।)

इस बार, विभिन्न वेब स्रोतों के संदर्भ में समाधान के ठोस उदाहरण प्रस्तुत किए गए हैं। ज्ञात तथ्यों को छोड़कर, संदर्भित URL स्रोत आदि में दर्ज किए गए हैं। जिन्होंने जानकारी सार्वजनिक की, मैं उनका आभार व्यक्त करता हूँ।

जितना संभव हो सके पारिभाषिक शब्दों से बचते हुए, हालाँकि इसमें थोड़ी अशुद्धि हो सकती है, सरल शब्दों में लिखा गया है।

struts1 में इस बार की कमजोरी को CVE-2014-0094, S2-020 आदि नामों से पुकारा जाता है या नहीं, यह स्पष्ट नहीं है, लेकिन फिलहाल इसे CVE-2014-0094 ही कहेंगे।

पृष्ठभूमि

फिर से समझाने की आवश्यकता नहीं कि CVE-2014-0094 एक बहुत बड़ी समस्या है।

http://www.nta.go.jp/sonota/sonota/osirase/service.htm

「e-Tax सॉफ्टवेयर (WEB संस्करण)」、「कर रिटर्न आदि तैयार करने का कोना」、「NISA (जापानी ISA) कोना」 सेवा रोकने की सूचना (महत्वपूर्ण) 25 अप्रैल 2014 के अनुसार, राष्ट्रीय कर एजेंसी की वेब सेवा struts1 का उपयोग करती है, और इसकी खोज के उसी दिन सेवा रोक दी गई थी। ऐसा प्रतीत होता है कि क्षति को न्यूनतम रखने के लिए तुरंत सेवा रोक दी गई थी।

जब हमने यहाँ प्रयोग किया, तो केवल URL तक पहुँचने से सेवा रुकने और किसी भी फ़ाइल के रिसाव की पुष्टि हुई। चूँकि केवल URL तक पहुँचना पर्याप्त है, अनाम ईमेल पते से URL वाला ईमेल मेलिंग सूची में भेजकर, अपराधी की पहचान करना कठिन हो जाता है, और सेवा को आसानी से रोका जा सकता है। क्या यह सचमुच इतनी आसानी से हमला करने योग्य समस्या है?

सबसे पहले करने वाला काम: सिस्टम को रोकना

यही सबसे महत्वपूर्ण है। यदि किसी तीसरे पक्ष की संस्था ने घोषणा की है कि कम से कम प्रभाव हो सकता है, तो पहले सेवा रोककर क्षति को फैलने से रोकना ही सही तरीका है। भले ही बाद की जाँच में पता चले कि कोई प्रभाव नहीं था, लीक हुई जानकारी वापस नहीं आ सकती। निस्संदेह, इसके लिए राजनीतिक निर्णय की आवश्यकता है। किसी कंपनी के मामले में, नैतिकता, दैनिक समस्या के प्रति जागरूकता और जोखिम प्रबंधन आदि पर सवाल उठते हैं।

यह जाँचना कि किस प्रकार का हमला संभव है

यह समस्या इस तथ्य के कारण है कि सिस्टम द्वारा रखे गए कुछ कॉन्फ़िगरेशन मानों को बदला जा सकता है। यह जाँचना आवश्यक है कि कौन से कॉन्फ़िगरेशन मान बदले जा सकते हैं। उन मानों के आधार पर, यह निर्धारित करें कि किस प्रकार का हमला संभव है।

ये कॉन्फ़िगरेशन मान Servlet कंटेनर के अनुसार भिन्न होते हैं। tomcat6 में संभवतः मनमाना कोड निष्पादन असंभव है, लेकिन tomcat8 में मनमाना निष्पादन संभव है। इसके अलावा, jetty, WebSphere Application Server आदि जैसे उपयोग किए जाने वाले वातावरण के अनुसार, यह जाँचना आवश्यक है कि कौन से कॉन्फ़िगरेशन मान मौजूद हैं।

tomcat6 के मामले में, ऐसे 23 कॉन्फ़िगरेशन परिवर्तन संभव कहे जाते हैं,

class.classLoader.resources.dirContext.docBase

इसे बदलने पर, सामान्य रूप से सिस्टम का संचालन असंभव हो जाता है, और, JSP प्रदर्शित करने के बजाय सर्वर पर किसी फ़ाइल को निर्दिष्ट करके, किसी भी फ़ाइल को प्राप्त (लीक) करना संभव हो जाता है।

tomcat8 के मामले में, मनमाना कोड निष्पादित किया जा सकता है, क्योंकि tomcat6 की तुलना में सेट किए जा सकने वाले मान अधिक हैं। यदि वे कॉन्फ़िगरेशन मान उपयोग किए जा रहे Servlet कंटेनर में मौजूद नहीं हैं, तो फिलहाल समस्या कम मानी जा सकती है।

यह जाँचना कि हमला हुआ या नहीं

इस बार कॉन्फ़िगरेशन मान परिवर्तन URL में उस स्ट्रिंग को शामिल करने के अलावा, सामान्य अनुरोध के छिपे हुए फ़ील्ड के रूप में भी संभव है, और cookie में वह मान शामिल करना भी संभव कहा गया है। एक्सेस लॉग से, छिपे हुए फ़ील्ड में सेट करने के मामले का पता नहीं चलता है।

अक्सर रविवार देर रात को सिस्टम को पुनः आरंभ किया जाता है; उससे थोड़ा पहले docBase को बदलकर फ़ाइल प्राप्त कर ली जाती है, और फिर सिस्टम पुनः आरंभ हो जाता है, इसलिए सिस्टम प्रशासकों के लिए असामान्यता को नोटिस करना कठिन होता है। यदि उस समयावधि में स्टेटस 404, 500 आदि बार-बार आ रहे हों, तो संभवतः कुछ फ़ाइल के लीक होने की संभावना अधिक है।

समाधान करना

struts1 का समर्थन समाप्त हो चुका है (ओपन सोर्स समर्थन क्या है, इस चर्चा को छोड़ते हुए), इसलिए सुरक्षा पैच जारी नहीं होता। इसे स्वयं हल करने की आवश्यकता है।

इसकी जड़ BeanUtil की समस्या है, और अनुचित स्ट्रिंग आने पर उसे अनदेखा करने के लिए एक कार्यान्वयन करना आवश्यक है। BeanUtil एक ऐसा उपकरण है जो ऑब्जेक्ट के कॉन्फ़िगरेशन मानों को बदलता है (यह कहना काफी अनुमानित है)।

कार्यान्वयन उदाहरण निम्नलिखित है

  com.haselab.struts.filter
  web.xml

यही है।

सीधे शब्दों में कहें तो, web.xml में सिस्टम प्रारंभ होने पर BeanUtil के व्यवहार को बदलने वाले प्रोग्राम को कॉल किया जाता है। SafeResolverListener.java को कॉल किया जाता है, और अब से BeanUtil SafeResolver.java का उपयोग करेगा। SafeResolver.java में, यदि विश्लेषण की जा रही स्ट्रिंग (केस-असंवेदनशील) 'classLoader' है, तो "" लौटाया जाता है। अर्थात, classLoader के लिए कोई भी मान सेट करना असंभव बना दिया जाता है। इस व्यवहार के लिए

 https://gist.github.com/nakamura-to/11347570

को संदर्भित किया गया है। (यह इतना छोटा प्रोग्राम है कि इसे ज्यों का त्यों उपयोग किया गया है।)

यदि एप्लिकेशन पक्ष में classLoader नामक सेटिंग को बदलने की आवश्यकता होती है, तो यह विधि उस सेटिंग को असंभव बना देती है, इसलिए यह समाधान उस मामले के लिए काम नहीं करता। लेकिन, सामान्यतः किसी चीज़ का नाम classLoader नहीं रखा जाता, इसलिए अभी कोई समस्या नहीं है। यदि आप चिंतित हैं, तो एप्लिकेशन के सभी स्रोतों पर,

grep -r -i classLoader *

जैसा कमांड चलाकर पुष्टि कर लें कि यह मौजूद नहीं है।

सत्यापन विवरण

हमने docBase के पुनर्लेखन का सत्यापन किया। mvn से deploy करने के बाद, ब्राउज़र में struts के अंतर्गत देखें। हर बटन दबाने पर, docBase का पुनर्लेखन और /etc/passwd फ़ाइल का प्रदर्शन किया जाता है।