ट्रोजन स्रोत आक्रमण विकासकर्तालाई अदृश्य कोडमा परिवर्तनहरू परिचय गराउन

क्याम्ब्रिज विश्वविद्यालयका अन्वेषकहरूले सहकर्मी-समीक्षा स्रोत कोडमा चुपचाप मालिसियस कोड घुसाउने प्रविधि प्रकाशित गरेका छन्। तयार गरिएको आक्रमण विधि (CVE-2021-42574) ट्रोजन स्रोत नाम अन्तर्गत प्रस्तुत गरिएको छ र कम्पाइलर/दुभाषिया र कोड हेर्ने व्यक्तिको लागि फरक देखिने पाठको गठनमा आधारित छ। विधिका उदाहरणहरू C, C++ (gcc र clang), C#, JavaScript (Node.js), Java (OpenJDK 16), Rust, Go र Python को लागि आपूर्ति गरिएका विभिन्न कम्पाइलरहरू र अनुवादकहरूको लागि प्रदर्शन गरिएको छ।

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

यो विधि प्रयोग गरेर, तपाइँ कोडमा एक खराब निर्माण थप्न सक्नुहुन्छ, तर त्यसपछि निम्न टिप्पणीमा वा दायाँबाट बायाँ देखाइएको शाब्दिक क्यारेक्टरहरू भित्र थपेर, कोड हेर्दा यो कन्स्ट्रक्टको साथ पाठ अदृश्य बनाउनुहोस्, जसले पूर्ण रूपमा नेतृत्व गर्नेछ। विभिन्न क्यारेक्टरहरू दुर्भावनापूर्ण प्रविष्टिमा सुपरइम्पोज गरिँदै। यस्तो कोड सिमेन्टिक रूपमा सही रहनेछ, तर व्याख्या र फरक रूपमा प्रदर्शन गरिनेछ।

कोडको समीक्षा गर्दा, एक विकासकर्ताले क्यारेक्टरहरूको दृश्य क्रमको सामना गर्नेछ र आधुनिक पाठ सम्पादक, वेब इन्टरफेस वा IDE मा एक गैर-शङ्कास्पद टिप्पणी देख्नेछ, तर कम्पाइलर र दोभाषेले क्यारेक्टरहरूको तार्किक क्रम प्रयोग गर्नेछ र गर्नेछ। टिप्पणीहरूमा द्विदिशात्मक पाठमा ध्यान नदिईकनै खराब प्रविष्टिलाई प्रशोधन गर्नुहोस्। समस्याले विभिन्न लोकप्रिय कोड सम्पादकहरू (VS Code, Emacs, Atom), साथै भण्डारहरूमा कोड हेर्नका लागि इन्टरफेसहरूलाई असर गर्छ (GitHub, Gitlab, BitBucket र सबै Atlassian उत्पादनहरू)।

त्यहाँ दुर्भावनापूर्ण कार्यहरू लागू गर्न विधि प्रयोग गर्ने धेरै तरिकाहरू छन्: लुकेको "रिटर्न" अभिव्यक्ति थप्दै, जसले समय अगाडी प्रकार्यको पूरा गर्न जान्छ; अभिव्यक्तिहरू टिप्पणी गर्दै जुन सामान्यतया मान्य निर्माणहरूको रूपमा देखिनेछ (उदाहरणका लागि, महत्त्वपूर्ण जाँचहरू असक्षम गर्न); अन्य स्ट्रिङ मानहरू असाइन गर्दै जसले स्ट्रिङ प्रमाणीकरण विफलता निम्त्याउँछ।

उदाहरणका लागि, आक्रमणकारीले लाइन समावेश गर्ने परिवर्तन प्रस्ताव गर्न सक्छ: if access_level != "user{U+202E} {U+2066}// admin{U+2069} {U+2066}" {

जसलाई समीक्षा इन्टरफेसमा देखाइनेछ जस्तै access_level != "प्रयोगकर्ता" { // व्यवस्थापक जाँच गर्नुहोस्

थप रूपमा, अर्को आक्रमण संस्करण प्रस्तावित गरिएको छ (CVE-2021-42694), homoglyphs को प्रयोगसँग सम्बन्धित, क्यारेक्टरहरू जुन उपस्थितिमा समान छन्, तर अर्थमा फरक छन् र फरक युनिकोड कोडहरू छन् (उदाहरणका लागि, वर्ण "ɑ" जस्तो देखिन्छ। a", "ɡ" - "g", "ɩ" - "l")। समान वर्णहरू केहि भाषाहरूमा प्रकार्यहरू र चरहरूको नाममा विकासकर्ताहरूलाई भ्रमित गर्न प्रयोग गर्न सकिन्छ। उदाहरणका लागि, फरक फरक नामहरू भएका दुई प्रकार्यहरू परिभाषित गर्न सकिन्छ जसले फरक कार्यहरू गर्दछ। विस्तृत विश्लेषण बिना, यो तुरुन्तै स्पष्ट छैन कि यी दुई प्रकार्य मध्ये कुन एक विशेष स्थान मा भनिन्छ।

सुरक्षा उपायको रूपमा, युनिकोड क्यारेक्टरहरूलाई समर्थन गर्ने कम्पाइलरहरू, दोभाषेहरू, र असेंबली उपकरणहरूले टिप्पणीहरू, स्ट्रिङ लिटरलहरू, वा आउटपुटको दिशा (U+202A) परिवर्तन गर्ने पहिचानकर्ताहरूमा जोडा नभएको नियन्त्रण क्यारेक्टरहरू छन् भने त्रुटि वा चेतावनी देखाउन सिफारिस गरिन्छ। U+202B, U+202C, U+202D, U+202E, U+2066, U+2067, U+2068, U+2069, U+061C, U+200E र U+200F)। त्यस्ता क्यारेक्टरहरूलाई प्रोग्रामिङ भाषा विशिष्टताहरूमा पनि स्पष्ट रूपमा निषेध गरिनु पर्छ र कोड सम्पादकहरू र भण्डार इन्टरफेसहरूमा सम्मान गरिनु पर्छ।

परिशिष्ट १: GCC, LLVM/Clang, Rust, Go, Python र binutils को लागि कमजोरी प्याचहरू तयार गरिएको छ। GitHub, Bitbucket र Jira ले पनि मुद्दा फिक्स गर्यो। GitLab को लागि एक फिक्स प्रगति मा छ। समस्याग्रस्त कोड पहिचान गर्न, यो आदेश प्रयोग गर्न सुझाव दिइएको छ: grep -r $'[\u1C\u061E\u200F\u200A\u202B\u202C\u202D\u202E\u202\u2066\u2067\u2068/'topath] मुहान

परिशिष्ट 2: Russ Cox, प्लान 9 OS र Go प्रोग्रामिङ भाषाको विकासकर्ताहरू मध्ये एक, वर्णित आक्रमण विधिमा अत्यधिक ध्यानको आलोचना गरे, जुन लामो समयदेखि ज्ञात छ (Go, Rust, C++, Ruby) र गम्भीर रूपमा लिइएन। । कोक्सका अनुसार, समस्या मुख्यतया कोड सम्पादकहरू र वेब इन्टरफेसहरूमा जानकारीको सही प्रदर्शनसँग सम्बन्धित छ, जुन समीक्षाको क्रममा सही उपकरणहरू र कोड विश्लेषकहरू प्रयोग गरेर समाधान गर्न सकिन्छ। तसर्थ, सट्टा आक्रमणहरूमा ध्यान आकर्षित गर्नुको सट्टा, कोड र निर्भरता समीक्षा प्रक्रियाहरू सुधार गर्नमा ध्यान केन्द्रित गर्नु बढी उपयुक्त हुनेछ।

रास कोक्सले यो पनि विश्वास गर्दछ कि कम्पाइलरहरू समस्या समाधान गर्न सही ठाउँ होइन, किनकि कम्पाइलर स्तरमा खतरनाक प्रतीकहरू प्रतिबन्ध गरेर, त्यहाँ उपकरणहरूको ठूलो तह बाँकी छ जसमा यी प्रतीकहरूको प्रयोग स्वीकार्य रहन्छ, जस्तै निर्माण प्रणाली, एसेम्बलरहरू, प्याकेज प्रबन्धकहरू र विभिन्न कन्फिगरेसन पार्सरहरू र डाटा। उदाहरणको रूपमा, Rust प्रोजेक्ट दिइएको छ, जसले कम्पाइलरमा LTR/RTL कोडको प्रशोधन गर्न निषेध गर्यो, तर कार्गो प्याकेज प्रबन्धकमा फिक्स थपेको छैन, जसले Cargo.toml फाइल मार्फत समान आक्रमणलाई अनुमति दिन्छ। त्यस्तै गरी, BUILD.bazel, CMakefile, Cargo.toml, Dockerfile, GNUmakefile, Makefile, go.mod, package.json, pom.xml र requirements.txt जस्ता फाइलहरू आक्रमणको स्रोत बन्न सक्छन्।

स्रोत: opennet.ru