TL; ड
माभेन सेन्ट्रलको कलाकृति प्रकाशित io.github.davidtimur:c2-lab नौ रिलिजहरू पठाइयो, जसमध्ये आठले कुनै पनि डाउनस्ट्रीम परियोजनाको संकलनको क्रममा रिमोट-एक्सेस पेलोड कार्यान्वयन गर्यो जसले जारलाई यसको एनोटेसन-प्रोसेसर मार्गमा राख्यो। कुनै पनि अनुप्रयोग कोडले यसलाई आयात गर्नुपर्दैनथ्यो। स्रोतको कुनै पनि लाइनले यसलाई सन्दर्भ गर्नुपर्दैनथ्यो। त्यहाँ कुनै स्थापना स्क्रिप्ट थिएन, कुनै पोस्ट-इन्स्टल समतुल्य थिएन, र निरीक्षण गर्नको लागि कुनै पनि प्रकारको लाइफसाइकल हुक थिएन।
कार्यान्वयन भेक्टर जार भित्रको एकल ४६-बाइट फाइल हो: जाभा सेवा-प्रदायक दर्ता जसले कार्यान्वयन गर्ने वर्गलाई नाम दिन्छ javax.annotation.processing.Processor। जाभा कम्पाइलरले यस्ता दर्ताहरू स्वचालित रूपमा पत्ता लगाउँछ। एकपटक फेला परेपछि, javac कम्पाइलिङको सामान्य भागको रूपमा कक्षालाई इन्स्ट्यान्टिएट गर्छ र चलाउँछ। यसको मतलब पेलोडको रनटाइम वातावरण बिल्ड मेसिन हो, यस समयमा बिल्ड मेसिनले गर्नुपर्ने एउटै काम गरिरहेको छ।
नौ रिलिजहरूमा कमाण्ड-एन्ड-कन्ट्रोल च्यानल तीन पटक पुनर्निर्माण गरिएको थियो: अपरेटर-सप्लाई गरिएको कलब्याक URL, त्यसपछि ngrok TCP टनेलमा रिभर्स शेल, त्यसपछि HTTP पोलिंग च्यानल जसको पथहरू दुई पटक सारियो। अन्तिम रिलिजले JVM पूर्वनिर्धारितको रूपमा नो-अप TLS ट्रस्ट प्रबन्धक स्थापना गर्यो, संकलन अवधिको लागि कुनै पनि प्रमाणपत्र स्वीकार गर्दै.
उक्त कलाकृतिले आफ्नै POM र MIT लाइसेन्समा "C2 Lab Payload" शब्दहरू बोकेको थियो। हामीले अवलोकन गरेको सम्पूर्ण अवधिभर यो Maven Central मा लाइभ थियो र त्यसबेलादेखि यसको सम्पूर्ण सहित हटाइएको छ io.github.davidtimur समूह।
शरीर रचना: कार्यान्वयन इन्जिनको रूपमा कम्पाइलर
जाभाको एनोटेसन प्रशोधन ढाँचा अवस्थित छ त्यसैले पुस्तकालयहरूले कम्पाइल समयमा कोड उत्पन्न गर्न सक्छन् - लोम्बोक, डैगर, र ORM र सिरियलाइजेशन उपकरणहरूको लामो सूची पछाडिको संयन्त्र। प्रोसेसरले जार भित्र एउटा सादा-पाठ फाइलको साथ आफूलाई घोषणा गर्दछ:
META-INF/services/javax.annotation.processing.प्रोसेसर
प्रत्येक प्रभावित रिलीजमा त्यो फाइलको सामग्री, शब्दशः र पूर्ण:
io.github.davidtimur.c2lab.C2Processor
फाइल १.०.१ देखि १.०.८, md५ सम्मका रिलीजहरूमा बाइट-समान छ। 7d2a08a5c8869a47eea9fa62487dfbe4. रिलिज १.०.० मा यो समावेश छैन।
जब जाभाक चल्छ, यसले यी सेवा प्रविष्टिहरूको लागि एनोटेसन-प्रोसेसर मार्ग स्क्यान गर्दछ र फेला पारेको कुरा लोड गर्दछ। कम्पाइल भइरहेको परियोजनामा कुनै पनि कुराले प्रोसेसर उल्लेख गर्न, केहि पनि एनोटेट गर्न, वा केहि पनि कन्फिगर गर्न आवश्यक छैन। मार्गमा उपस्थिति पर्याप्त छ। यो त्यो गुण हो जसले JavacDoor लाई आपूर्ति-श्रृंखला ढाँचाहरूबाट अलग गर्दछ जुन धेरैजसो उपकरणहरू वरिपरि बनाइन्छ:
एउटा स्थापना हुक भनेको म्यानिफेस्टमा भएको घोषणा हो, र म्यानिफेस्ट भनेको जो कोहीले पनि पढ्ने पहिलो कुरा हो। आयात-समय पेलोड कम्तिमा पढ्न योग्य स्रोतमा बस्छ। सेवा दर्ता दुवै होइन: यो एउटा फाइलनाम र एउटा लाइन हो जसले क्लासलाई नाम दिन्छ, र व्यवहार निर्देशिकाबाट टाढा कम्पाइल गरिएको बाइटकोडमा रहन्छ।
पेलोड वर्गले आफैंले शेलिंग आउट गरेर होस्ट टोही गर्छ। संकलित वर्गहरूको स्थिर पूलहरूमा समावेश छ /बिन/श, म को हु, uname -a, PWD युनिक्स मार्गमा र कार्यसूची विन्डोज मार्गमा, सँगै रिडिरेक्ट त्रुटि स्ट्रिम चाइल्ड प्रोसेसको त्रुटि आउटपुटलाई क्याप्चर गरिएको स्ट्रिममा मर्ज गर्न। दुई JSON टेम्प्लेटहरूले होस्टबाट परिणामहरू बोक्छन् — एक दर्ता बीकन:
{"host":"%s","os":"%s","user":"%s","dir":"%s"}
बाट जनसंख्या भएको होस्टनाम आदेश र ओएस.नाम, प्रयोगकर्ता नाम, र प्रयोगकर्ता.डाइरेक्टरी प्रणाली गुणहरू, र परिणाम कलब्याक:
{"version":"%s","host":"%s","time":"%s","output":"%s"}
कम्पाइलरको आफ्नै आउटपुटमा छोडिएका प्रगति मार्करहरू असामान्य रूपमा स्पष्ट छन्: [C2] संकलन-समय कार्यान्वयन पूरा भयो, [C2] कलब्याक पठाइयो → HTTP , [C2] शेलसँग जोडिएको छ .
नौ रिलिजहरू, तीन C2 पुस्ताहरू
रिलिजहरू एउटै पेलोडका नौ प्रतिलिपिहरू होइनन्। तिनीहरू पुनरावृत्ति लग हुन्, र तिनीहरूलाई क्रमबद्ध रूपमा पढ्दा डेलिभरी भेक्टर स्थिर रहँदा च्यानल पुनर्निर्माण भइरहेको देखाउँछ।
त्यो तालिकामा भएका तीनवटा विवरणहरू चित्रण गर्न लायक छन्, किनकि प्रत्येकले कलाकृति सेट कसरी पढ्नुपर्छ भनेर परिवर्तन गर्दछ।
भेक्टर १.०.२ मा होइन, १.०.१ मा आउँछ। रिलिज १.०.० मा उही जासूसी र कलब्याक तर्क छ तर यसमा कुनै सेवा फाइल छैन र एनोटेसन-प्रशोधन आयात छैन; यो केवल यदि केहिले यसलाई कल गर्छ भने मात्र चल्छ। १.०.१ बाट सेवा फाइल उपस्थित छ र संकलित वर्गहरू आयात हुन्छन् javax.annotation.processing.समर्थितस्रोतसंस्करण। टिकट गरिएका दुई रिलिजहरू - १.०.० र १.०.२ - को तुलना गर्ने कुनै पनि मूल्याङ्कनले सही निष्कर्ष निकाल्छ कि केहि परिवर्तन भयो, तर कहाँ गलत पहिचान गर्छ।
रिभर्स शेल ठ्याक्कै एउटा रिलीजमा अवस्थित हुन्छ। रिलिज १.०.२ मा समावेश छ ०.tcp.ngrok[.]io, लग लाइन [C2] शेल 0.tcp.ngrok[.]io:19823 मा जडान गरिएको छ।, एउटा अन्तरक्रियात्मक ब्यानर c2-शेल, र एउटा फ्रेम टर्मिनेटर __अन्त__। रिलिज १.०.३ पछिका रिलिजहरूमा ती मध्ये कुनै पनि समावेश हुँदैन र यसको सट्टा HTTPS होस्टमा पुग्छ। टिकट गरिएका रिलिजहरूलाई मात्र नामकरण गर्ने टेकडाउन अनुरोधले मृत TCP अन्त्य बिन्दुलाई उद्धृत गरेको हुने थियो जबकि छ पछिका रिलिजहरूमा उपस्थित लाइभ HTTP च्यानललाई उल्लेख नगरी छोड्ने थियो।
अन्तिम रिलीजले यातायात प्रमाणीकरण हटाउँछ। रिलिज १.०.८ ले कार्यान्वयन गर्ने वर्ग थप्छ javax.net.ssl.X509 ट्रस्ट म्यानेजर जसको प्रमाणपत्र-जाँच विधिहरूले केही गर्दैन, मार्फत दर्ता गरिएको सधैं-सत्य होस्टनाम प्रमाणिकरणकर्ता पूर्वनिर्धारित होस्टनामप्रमाणकसेटगर्नुहोस्र सबैलाई विश्वास गर्नुहोस् JVM को पूर्वनिर्धारित रूपमा दुवै स्थापना गर्ने रुटिन। प्रभाव यो हो कि त्यो कम्पाइलको बाँकी भागको लागि, JVM ले कुनै पनि होस्टबाट कुनै पनि प्रमाणपत्र स्वीकार गर्दछ - पेलोडको आफ्नै ट्राफिकको लागि मात्र होइन, तर निर्माणले TLS मार्फत पछि गर्ने अरू कुनै पनि कुराको लागि।
HTTP च्यानल, यसलाई प्रयोग गर्ने सबै छ रिलीजहरूमा, एकल होस्टद्वारा अगाडि बढाइएको छ: टेबलफुल-फेभर-क्रेज्ड.एनग्रोक-मुक्त[.]देवप्रत्येक अनुरोधमा हेडर हुन्छ ngrok-छोड्नुहोस्-ब्राउजर-चेतावनी, जसले नि:शुल्क ngrok टनेलहरूले ब्राउजरहरूलाई सेवा दिने इन्टरस्टिशियल पृष्ठलाई दबाउँछ। रिलीजहरूमा पथ सेटहरू शिफ्ट गर्दछ — / बाहिर १.०.७ मा गायब हुन्छ, र /सेमीडी सँग बदलिन्छ / मतदान — तर होस्ट कहिल्यै परिवर्तन हुँदैन।
आत्म-बहिष्कारले बताउँछ
१.०.१ देखि प्रत्येक POM ले कलाकृतिको आफ्नै निर्माणको लागि कम्पाइलर तर्क सेट गर्दछ:
-प्रोक: कुनै पनि होइन
त्यो झण्डाले एनोटेसन प्रशोधनलाई असक्षम पार्छ। यहाँ यसको प्रभाव पूर्व होcise: जब प्रोसेसर भएको परियोजना आफैं कम्पाइल हुन्छ, प्रोसेसर चल्दैन।
यो झण्डाको पूर्णतया सामान्य प्रयोगहरू छन्। एनोटेसन प्रोसेसर पठाउने परियोजनाले बुटस्ट्र्यापको समयमा त्यो प्रोसेसर आफैंमा लागू गर्नबाट जोगिनु पर्छ, र बिल्ड-टूल कागजातले ठ्याक्कै यही सिफारिस गर्छ। एक्लै लिँदा यसले केही पनि प्रमाणित गर्दैन।
प्रोसेसरले गर्ने कामसँगै लिँदा, यसले एक विशिष्ट असममिति वर्णन गर्दछ: कोडले कलाकृति विरुद्ध कम्पाइल गर्ने सबैको मेसिनहरूमा कार्यान्वयन गर्दछ, र कलाकृति निर्माण गर्ने मेसिनमा होइन। झण्डा सेवा फाइल - १.०.१ - परिचय गराउने उही रिलीजमा र त्यसपछिको प्रत्येक रिलीजमा देखा पर्दछ। "रिलीज जहाँ कम्पाइल-समय कार्यान्वयन सुरु हुन्छ" र "रिलीज जहाँ कम्पाइल-समय कार्यान्वयन स्थानीय रूपमा बन्द हुन्छ" बीचको सम्बन्ध कलाकृति सेटमा एकल सबैभन्दा उपयोगी विश्लेषणात्मक संकेत हो, र यो कुनै पनि चीजलाई डिकम्पाइल नगरी सादा-पाठ POM मा देखिन्छ।
हामी प्रभावलाई ध्यान दिन्छौं र त्यहीँ रोकिन्छौं। झण्डा किन राखिएको थियो भन्ने कुरा कलाकृतिहरूमा केही पनि बोल्दैन।
मेटाडेटाको अर्को एउटा अंश उल्लेख गर्न लायक छ, प्रायः यसलाई हटाउनको लागि। POM ले परियोजनालाई "C2 ल्याब पेलोड" नाम दिन्छ, यसलाई "C2 ल्याब पेलोड आर्टिफ्याक्ट" को रूपमा वर्णन गर्दछ, र यसलाई MIT लाई इजाजतपत्र दिन्छ। यस प्रकारको स्व-लेबलिङ कहिलेकाहीं प्रमाणको रूपमा प्रस्तुत गरिन्छ कि प्याकेज एक अनुसन्धान अभ्यास हो।cise लाईभ खतराको सट्टा, र कहिलेकाहीँ त्यो पठन सही हुन्छ — पहुँचयोग्य पूर्वाधार नभएको घोषित क्यानरी यसभन्दा फरक वस्तु हो। यो यहाँ लागू हुँदैन। सार्वजनिक भण्डारमा प्रकाशित कार्यात्मक इम्प्लान्ट, कुनै पनि उपभोक्ताद्वारा पहुँचयोग्य, नौ रिलीजहरूमा तीन पटक पुनर्निर्माण गरिएको आउटबाउन्ड पूर्वाधारको साथ, यसको मेटाडेटाले यसलाई जे भन्छ त्यसलाई ध्यान नदिई प्रत्यक्ष क्षमता हो। POM मा रहेको नामले यसको विरुद्ध कम्पाइल गर्ने मेसिनमा के हुन्छ भन्ने बारेमा केही परिवर्तन गर्दैन।
निर्माण मेसिनहरूको लागि सूचकहरू
यदि यस कलाकृति विरुद्ध बिल्ड होस्ट कम्पाइल गरियो भने, प्रमाण डिस्कमा रहेको निरन्तर इम्प्लान्टको सट्टा बिल्ड लग र नेटवर्क टेलिमेट्रीमा बस्छ - पेलोड कम्पाइलर प्रक्रिया भित्र चल्छ र यससँगै बाहिर निस्कन्छ।
जार वा स्थानीय भण्डार क्यासमा
META-INF/services/javax.annotation.processing.Processorनामकरणio.github.davidtimur.c2lab.C2Processor- सेवा फाइल md5
7d2a08a5c8869a47eea9fa62487dfbe4 - अन्तर्गत कक्षाहरू
io/github/davidtimur/c2lab/:C2Processor,C2Task,Task, र १.०.८ मा भित्री वर्गTask$1
निर्माणमा रहेको आउटपुट
[C2] compile-time execution complete[C2] callback sent → HTTP[C2] callback failed:[C2] shell connected to- अन्तरक्रियात्मक ब्यानर
c2-shell; फ्रेम टर्मिनेटर__END__
प्रक्रियामा रहेको टेलिमेट्री
javacअभिभावकको रूपमा/bin/sh -c(युनिक्स) वा विन्डोज कमाण्ड इन्टरप्रेटर- बाल आदेशहरू
whoami,uname -a,pwd(युनिक्स) वाtasklist(विन्डोज) कम्पाइल चरणद्वारा अभिभावकत्व प्राप्त
नेटवर्क टेलिमेट्रीमा
- आउटबाउन्ड TCP मा
0.tcp.ngrok[.]io:19823(रिलिज १.०.२) - HTTPS लाई
tableful-fervor-crazed.ngrok-free[.]dev, बाटोहरू/register,/cmd,/poll,/out(१.०.३ देखि १.०.८ सम्म रिलिज हुन्छ) - अनुरोध हेडर
ngrok-skip-browser-warning: true - निकायहरू मिलाउन अनुरोध गर्नुहोस्
{"host":...,"os":...,"user":...,"dir":...}or{"version":...,"host":...,"time":...,"output":...}
कन्फिगरेसनमा
- वातावरण चर
CALLBACK,CALLBACK_URL; प्रणाली गुणcallback.url
प्रकाशकको मेटाडेटा
- समूह
io.github.davidtimur; प्रकाशकको ठेगानाdavudboi999@gmail[.]com; हस्ताक्षर गर्ने कुञ्जीE520C345EF94423D
रिलिज १.०.८ चलाएको बिल्डले एउटा अतिरिक्त जाँचको वारेन्टी दिन्छ। त्यो रिलिजले JVM-व्यापी पूर्वनिर्धारितको रूपमा अनुमति दिने ट्रस्ट प्रबन्धक स्थापना गर्ने भएकोले, उही JVM मा पछि गरिएको कुनै पनि TLS जडान - निर्भरता रिजोल्युसन, आर्टिफ्याक्ट अपलोड, डिप्लोयमेन्ट चरण - प्रमाणपत्र प्रमाणीकरण बिना नै अगाडि बढ्यो। त्यो विन्डोबाट आउने ट्राफिकलाई प्रमाणित मान्नु हुँदैन।
संकलित कलाकृतिहरूलाई किन फरक स्क्यानिङ आवश्यक छ
JavacDoor एउटा उपयोगी परीक्षण केस हो किनभने यसले एकैचोटि दुई सामान्य धारणाहरूलाई पराजित गर्छ, र कुनै पनि असफलता कुनै एक विक्रेताको उपकरणमा विशिष्ट हुँदैन।
पहिलो धारणा यो हो कि खतरनाक कोडले आफूलाई म्यानिफेस्टमा घोषणा गर्छ। जीवनचक्र वरिपरि धेरै आपूर्ति-श्रृंखला उपकरणहरू व्यवस्थित गरिएका छन्। hooks, किनभने npm र PyPI को लागि कार्य सामान्यतया त्यहीं हुन्छ। JavacDoor मा कुनै हुक छैन। यसको ट्रिगर एउटा सेवा-दर्ता फाइल हो जसको नाम जाभा इन्टरफेस हो र जसको सामग्री क्लास नाम हो। त्यो स्थिर रूपमा समात्नको लागि तपाईंले उपचार गर्नुपर्छ META-INF/services/javax.annotation.processing.प्रोसेसर आफ्नै अधिकारमा कार्यान्वयन प्रवेश बिन्दुको रूपमा, बराबरीमा स्थापना पछि स्क्रिप्ट — र त्यसपछि नाम दिइएको वर्गलाई बाइटकोडमा पछ्याउनुहोस्। इकोसिस्टमहरूसँग यस आकारको आफ्नै स्वत: खोज संयन्त्रहरू हुन्छन्, र प्रत्येक एउटा प्रविष्टि बिन्दु हो, चाहे टुलिङले यसलाई एकको रूपमा गणना गरून् वा नगरून्।
दोस्रो धारणा यो हो कि स्ट्रिङहरू स्रोत फाइलहरूमा बस्छन्। जारको लागि, अन्त्य बिन्दुहरू, शेल आदेशहरू, JSON टेम्प्लेटहरू, र लग मार्करहरू सबै स्थिर पूलहरूमा हुन्छन्। कक्षा फाइलहरू। greps टेक्स्ट टुलिङले केही फेला पार्दैन — स्ट्रिङहरू अस्पष्ट भएकोले होइन, तर तिनीहरू एक संरचित बाइनरी कन्टेनरमा छन् जुन टेक्स्ट स्क्यानले पार्स गर्दैन। यस पोस्टमा भएका प्रत्येक नेटवर्क सूचक स्थिर-पूल पार्सिङबाट बाहिर आएका हुन्। ती मध्ये एक पूर्ण रूपमा बनाइएको हो। https:// क्लास फाइल भित्र सादा दृश्यमा रहेको URL; जारको पढ्न सकिने सामग्रीको टेक्स्ट स्क्यानले अझै पनि यसलाई सतहमा ल्याउने छैन। यहाँ हराउनको लागि कुनै एन्कोडिङ छैन, पढ्नको लागि केवल कन्टेनर ढाँचा छ।
दुबै खाडलहरूको आकार एउटै छ: एउटा कलाकृति ढाँचालाई परिभाषित अर्थशास्त्र भएको संरचनाको सट्टा फाइलहरूको झोलाको रूपमा व्यवहार गरिएको थियो। सुधारात्मक अनग्ल्यामरस छ — कन्टेनरलाई पार्स गर्नुहोस्, इकोसिस्टमको आफ्नै स्वत: खोज प्रविष्टि बिन्दुहरू गणना गर्नुहोस्, र तिनीहरूलाई कम्पाइल गरिएको कोडमा पछ्याउनुहोस्। विशेष गरी निर्माण-समय भेक्टरहरूको लागि, तेस्रो जाँच सस्तो र आश्चर्यजनक रूपमा निदानात्मक छ: उपभोक्ताहरूलाई कलाकृतिले के गर्छ भनेर तुलना गर्नुहोस् जुन यसले आफूलाई छुट दिन्छ। एउटा कलाकृति जसले कम्पाइल-टाइम प्रोसेसर दर्ता गर्छ र एकै साथ आफ्नै निर्माणको लागि कम्पाइल-टाइम प्रशोधनलाई असक्षम पार्छ, यसले तपाईंलाई सादा-पाठ POM को दुई लाइनहरूमा आफ्नो बारेमा केही भनेको छ।
आज माभेन कलाकृतिहरू उपभोग गर्ने टोलीहरूका लागि, तीन व्यावहारिक उपायहरू पालना गर्नुहोस्:
- एनोटेसन-प्रोसेसर मार्गलाई कार्यान्वयन सीमाको रूपमा व्यवहार गर्नुहोस्। त्यहाँ पुग्ने निर्भरताहरूले तपाईंको निर्माणमा कोड चलाउँछन्। जहाँ निर्माणलाई एनोटेसन प्रशोधनको आवश्यकता पर्दैन, -प्रोक: कुनै पनि होइन यो रक्षात्मक रूपमा उत्तिकै उपयोगी छ जति यो यहाँ स्थानीय रूपमा थियो; जहाँ यसले गर्छ, कम्पाइल क्लासपाथबाट इनहेरिट गर्नुको सट्टा प्रोसेसर सेटलाई स्पष्ट रूपमा पिन गर्नुहोस्।
- लग कम्पाइलर उपप्रक्रियाहरू। धेरैजसो परियोजनाहरूमा शेल जन्माउने कम्पाइल चरण असामान्य हुन्छ र तुच्छ रूपमा सतर्क हुन्छ।
- मेटाडेटालाई गवाहीको रूपमा नलिनुहोस्। प्याकेजको नाम वा विवरणमा "ल्याब", "परीक्षण", "पेलोड", र "PoC" दायरा सीमा होइनन्। पहुँचयोग्यता र व्यवहार हुन्।
कलाकृति र यसको सम्पूर्ण समूहलाई हटाइयो Maven हाम्रो रिपोर्ट पछ्याउँदै सेन्ट्रल; आर्टिफ्याक्ट मार्ग र समूह मार्ग दुवैले अब ४०४ फर्काउँछ, र सेन्ट्रल अनुक्रमणिकाले कुनै मिल्दो निर्देशांकहरू रिपोर्ट गर्दैन। यसले यो आर्टिफ्याक्ट बन्द गर्छ। यसले भेक्टर बन्द गर्दैन, जुन जाभा कम्पाइलरको दस्तावेजीकृत सुविधा हो र जार प्रकाशित गर्ने जो कोहीको लागि उपलब्ध छ।
सन्दर्भ
यस पोस्टले कुनै बाह्य स्रोतहरू उद्धृत गर्दैन। सबै निष्कर्षहरू नौ प्रकाशित जारहरूको प्रत्यक्ष-हस्त स्थिर विश्लेषण हुन्, हटाउनु अघि माभेन सेन्ट्रलबाट प्राप्त गरियो। कलाकृतिहरूबाट कुनै पनि कोड कुनै पनि बिन्दुमा कार्यान्वयन गरिएको थिएन।
