XZ बैकडोर घटना - प्रारंभिक विश्लेषण परिणाम

 (securelist.com)
2 पॉइंट द्वारा GN⁺ 2024-04-13 | 1 टिप्पणियां | WhatsApp पर शेयर करें

  • घटनाओं की टाइमलाइन:

    • 2024.01.19: XZ वेबसाइट को एक नए maintainer (jiaT75) द्वारा GitHub pages पर स्थानांतरित किया गया
    • 2024.02.15: .gitignore में build-to-host.m4 जोड़ा गया
    • 2024.02.23: दुर्भावनापूर्ण script stages वाली दो "test files" जोड़ी गईं
    • 2024.02.24: XZ 5.6.0 रिलीज़ किया गया
    • 2024.02.26: CMakeLists.txt में Landlock security feature को नुकसान पहुंचाने वाला commit
    • 2024.03.04: बैकडोर के कारण Valgrind में समस्याएँ उत्पन्न हुईं
    • 2024.03.09: दो "test files" अपडेट की गईं, CRC functions संशोधित किए गए, Valgrind issue को "ठीक" किया गया
    • 2024.03.09: XZ 5.6.1 रिलीज़ किया गया
    • 2024.03.28: बग का पता चला, Debian और RedHat को सूचित किया गया, Debian ने XZ को rollback किया
    • 2024.03.29: OSS-security mailing list पर email प्रकाशित हुआ, RedHat ने पुष्टि की कि बैकडोर वाला XZ शिप किया गया था
    • 2024.03.30: Debian ने builds बंद किए और rebuild प्रक्रिया शुरू की
    • 2024.04.02: XZ के मुख्य developer ने बैकडोर घटना को स्वीकार किया

  • दुर्भावनापूर्ण बैकडोर शामिल XZ distributions के hash values:

    • xz-5.6.0: MD5, SHA1, SHA256 hash values उपलब्ध कराए गए
    • xz-5.6.1: MD5, SHA1, SHA256 hash values उपलब्ध कराए गए

प्रारंभिक संक्रमण विश्लेषण

  • Stage 1 - छेड़छाड़ किया गया build-to-host script:

    • release source files शुरुआत में हानिरहित थे, लेकिन हैकर-नियंत्रित URL से डाउनलोड करने पर इनमें build-to-host.m4 फ़ाइल शामिल होती थी, जो malicious code चलाती थी
    • यह .m4 फ़ाइल build के दौरान चलती थी और test folder में जोड़ी गई पहली फ़ाइल को संशोधित कर decompress करती थी

  • Stage 2 - inject किया गया shell script:

    • .m4 फ़ाइल द्वारा inject की गई malicious script यह जाँचती थी कि क्या यह Linux पर intended build process के भीतर चल रही है
    • अगला चरण चलाने के लिए good-large_compressed.lzma फ़ाइल का उपयोग किया जाता था; यह सामान्य रूप से compress की गई थी, लेकिन decompress किए गए data के भीतर garbage data शामिल था
    • head/tail commands से 33,492 bytes निकाले जाते थे और tr command से basic substitutions लागू कर obfuscation हटाई जाती थी

  • Stage 3 - बैकडोर निष्कर्षण:

    • अंतिम चरण का shell script कई जाँचें करता था कि क्या यह अपेक्षित environment में चल रहा है
    • यह उसी good-large_compressed.lzma फ़ाइल के अलग offsets में छिपे बैकडोर binary code को निकालता था
    • XZ tool से फ़ाइल निकाली जाती थी और head calls की एक श्रृंखला द्वारा RC4-जैसे algorithm से binary data decrypt किया जाता था
    • compressed फ़ाइल को XZ से extract कर predefined value के आधार पर शुरुआती bytes हटाए जाते थे, फिर liblzma_la-crc64-fast.o के रूप में सहेजा जाता था
    • crc_x86_clmul.h में is_arch_extension_supported function को संशोधित कर __get_cpuid call को _get_cpuid में बदला गया

binary बैकडोर विश्लेषण

  • stealth loading scenario:

    • XZ CRC calculation के लिए lzma_crc32, lzma_crc64 functions का उपयोग करता है, जिन्हें ELF symbol table में IFUNC type के रूप में संग्रहीत किया जाता है
    • optimized version का उपयोग करना है या नहीं, यह dynamically तय करने के लिए IFUNC का उपयोग किया जाता है
    • बैकडोर को object file के रूप में सहेजा जाता है और इसका मुख्य लक्ष्य compile के समय main executable से link होना है
    • object file में _get_cpuid symbol शामिल होता है; original source में एक underscore हटाने से ऐसा होता है कि code जब _get_cpuid को call करता है, तो वास्तव में बैकडोर version call होता है

  • बैकडोर code विश्लेषण:

    • शुरुआती बैकडोर code को 2 बार call किया जाता है, और वास्तविक malicious activity तब शुरू होती है जब lzma_crc64 IFUNC _get_cpuid को call करता है
    • यह GOT address ढूंढकर cpuid pointer की location पता करता है और उसे main malicious function pointer से बदल देता है
    • मुख्य लक्ष्य specific functions को hook करना है ताकि संक्रमित system से होने वाले सभी connections की निगरानी की जा सके

  • मुख्य व्यवहार:

    • RSA_public_decrypt, EVP_PKEY_set1_RSA, RSA_get0_key जैसी libcrypto functions hooking targets हैं
    • यह जाँचता है कि वर्तमान process execution criteria पर खरा उतरता है या नहीं, और kill switch की उपस्थिति भी देखता है
    • string operations के लिए Trie structure का उपयोग किया जाता है
    • ELF Symbol structure की location खोजने के लिए 3 या अधिक symbol resolver routines का उपयोग किया जाता है
    • rtdl-audit feature का दुरुपयोग कर symbol resolving routine को hijack करके function hooking हासिल की जाती है

GN⁺ की राय

  • यह लेख open source software में malware injection के एक बेहद परिष्कृत हमले के मामले को अच्छी तरह दिखाता है। इससे यह सीख मिलती है कि open source के फ़ायदे का उल्टा इस्तेमाल भी किया जा सकता है।

  • Linux systems को निशाना बनाने वाले cyber attacks और बैकडोर लगातार अधिक परिष्कृत होते जा रहे हैं। खासकर SSH servers के ज़रिए हमले गंभीर security threat बन सकते हैं।

  • दूसरी ओर, यह open source ecosystem की self-correcting क्षमता भी दिखाता है। आखिरकार बैकडोर को community ने खोज निकाला और तेज़ी से प्रतिक्रिया दी। पारदर्शिता ही कुंजी है।

  • उन्नत Trie data structure, Symbol Resolver, dl_audit hooking जैसी तकनीकों का उपयोग यह दिखाता है कि Linux malware तकनीकी रूप से कैसे विकसित हो रहा है। Linux system security पर भी विशेष ध्यान देने की ज़रूरत है।

  • कंपनियों को open source software अपनाते समय सिर्फ license नहीं, बल्कि security verification भी अनिवार्य रूप से करना चाहिए। यह ज़रूर परखना चाहिए कि distribution source विश्वसनीय है या नहीं, और code की निरंतर monitoring हो रही है या नहीं।

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-04-13
Hacker News राय

सारांश:

  • हमलावर ने detection से बचने के लिए scripts और code में बहुत मेहनत की थी, इस लिहाज़ से यह पूरा project diversion या एक साथ चल रहे कई प्रयासों के विकल्प के रूप में काम कर सकता है
  • SSHD पर फोकस करने से system के बाकी हिस्सों या तकनीकी और सामाजिक पहलुओं पर पड़ने वाले असर को भी ध्यान में रखना चाहिए
  • हर dynamic linking library का अपना GOT होना और dynamic linking पूरा होने के बाद table को read-only के रूप में चिह्नित करना एक उपयोगी hardening step हो सकता है
  • source code ऐसा लगता है मानो disassembler चलाकर, code क्या करता है यह समझकर, फिर सब कुछ वर्णनात्मक नामों के साथ बदलते हुए तैयार किया गया हो
  • backdoor में bug की वजह से SSH में जो delay और slowdown हुआ, वही आखिरकार इसके उजागर होने का कारण बना; इस पर कोई analysis हुआ है या नहीं, यह जानने की जिज्ञासा है
  • xz repository फिर से GitHub पर दिखाई दी है, और maintainers सफाई का काम कर रहे हैं, जैसे ifunc support हटाना और test files बनाने वाला code commit करना
  • यह कल्पना कि ऐसे कई backdoor होंगे जिन्हें लोग ढूंढ नहीं पाए, और यह उम्मीद कि इस तरह का कोई और unnoticed मामला न हो