Xzbot: xz बैकडोर के लिए नोट्स, honeypot और exploit डेमो

 (github.com/amlweems)
1 पॉइंट द्वारा GN⁺ 2024-04-02 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • xzbot xz बैकडोर (CVE-2024-3094) का विश्लेषण करने के लिए एक repository है, जो honeypot, ED448 public key patch, बैकडोर payload format, और remote code execution डेमो उपलब्ध कराती है
  • honeypot, OpenSSH पर एक सरल patch लगाकर बैकडोर format से मेल खाने वाले public key N value के साथ आने वाले connection attempts को sshd logs में दर्ज करता है
  • ED448 patch, signature verification और payload decryption में बैकडोर द्वारा इस्तेमाल की जाने वाली hardcoded public key को उपयोगकर्ता द्वारा बनाई गई key से बदल देता है, ताकि बैकडोर को trigger किया जा सके
  • बैकडोर payload, SSH certificate की CA signing key के N value में जाता है, और a * b + c से request type बनाता है; Type 2 null-terminated command को system() से चलाता है
  • डेमो CLI, vulnerable SSH server से जुड़कर command चलाने का flow दिखाती है, और सफल exploitation INFO या उससे ऊपर के logs नहीं बनाती

xzbot का दायरा और संरचना

  • xzbot xz बैकडोर CVE-2024-3094 का विश्लेषण करने के लिए एक project है
  • इसमें चार चीज़ें शामिल हैं
    • honeypot: exploit attempts का पता लगाने के लिए एक नकली vulnerable server
    • ed448 patch: अपनी ED448 public key इस्तेमाल करने के लिए liblzma.so को patch करना
    • backdoor format: बैकडोर payload format का विवरण
    • backdoor demo: ED448 private key ज्ञात होने की स्थिति मानकर RCE trigger करने वाली CLI

honeypot: OpenSSH patch से attempts की पहचान

  • openssh.patch OpenSSH पर लगाने के लिए एक सरल patch है, जो बैकडोर format से मेल खाने वाले public key N value के साथ आने वाले connection attempts को रिकॉर्ड करता है
  • flow यह है कि openssh-portable को clone करने के बाद patch लागू किया जाए और autoreconf, configure, make चलाए जाएँ
  • connection attempts sshd logs में xzbot: magic 1 [preauth] और payload bytes के रूप में दिखाई देते हैं

ED448 public key patch

  • बैकडोर signature verification और payload decryption के लिए hardcoded ED448 public key का उपयोग करता है
  • इस public key को उपयोगकर्ता की अपनी key से बदलने पर बैकडोर को trigger किया जा सकता है
  • repository, attacker की ED448 public key और seed=0 से बनाई गई replacement public key value दोनों दिखाती है
  • शुरुआती चरण है बैकडोर शामिल liblzma.so.5.6.1 shared object तैयार करना
    • उदाहरण स्रोत के रूप में xz-utils 5.6.1-1 Debian snapshot दिया गया है
    • pwntools install करने के बाद patch.py liblzma.so.5.6.1 चलाने पर liblzma.so.5.6.1.patch बनती है
    • इसके बाद संशोधित liblzma.so.5.6.1.patch shared object के साथ sshd चलाया जाता है
  • assets में उदाहरण दिए गए हैं

बैकडोर payload format

  • बैकडोर, SSH certificate के साथ connect करते समय CA signing key के N value के भीतर payload डालकर trigger किया जा सकता है
  • इस payload को attacker की ED448 key से encrypt और sign किया जाना चाहिए
  • बाहरी संरचना में ये fields शामिल हैं
    • a: 32-bit
    • b: 32-bit
    • c: 64-bit
    • ciphertext: 240 bytes
  • request type a * b + c से निकाला जाता है
    • अगर value 3 से बड़ी हो, तो बैकडोर processing छोड़ देता है
    • Type 1: उपयोग अज्ञात, और 0 bytes की अपेक्षा
    • Type 2: null-terminated payload को system() से चलाता है
    • Type 3: उपयोग अज्ञात, और 48-byte signature data की अपेक्षा
  • ciphertext, ED448 public key के शुरुआती 32 bytes को symmetric key बनाकर chacha20 से encrypt किया जाता है
    • इसी कारण exploit attempts को दिए गए 32-byte key से decrypt किया जा सकता है
  • decrypt किए गए ciphertext के भीतर 114-byte signature, x और y 1-bit fields, length, command string आदि होते हैं
    • x या y सेट करने पर थोड़ा अलग code path लिया जाता है
  • signature, RFC-8032 ED448 signature है
    • input में 32-bit magic value, command से पहले का 5-byte field, वैकल्पिक रूप से command के length bytes, और server hostkey के SHA-256 hash के पहले 32 bytes शामिल होते हैं

exploit डेमो CLI

  • CLI को Go से install किया जाता है
    • go install github.com/amlweems/xzbot@latest
  • xzbot -h तीन मुख्य options दिखाता है
    • -addr: SSH server address, default 127.0.0.1:2222
    • -seed: xz बैकडोर key से मेल खाने वाला ED448 seed, default 0
    • -cmd: system() से चलाया जाने वाला command, default id > /tmp/.xz
  • उदाहरण 127.0.0.1:2222 पर vulnerable SSH server से जुड़कर id > /tmp/.xz command चलाता है
  • vulnerable server पर system() call location पर watchpoint सेट करने से देखा जा सकता है कि sshd process id > /tmp/.xz चला रहा है
  • execution के बाद /tmp/.xz में uid=0(root) gid=0(root) groups=0(root) output बचा रहने का उदाहरण दिया गया है

process tree और log विशेषताएँ

  • सामान्य SSH connection का process tree sshd से user session और shell तक जाता है
  • बैकडोर execution उदाहरण में xzbot -cmd 'sleep 60' के बाद sshd: root [priv], sshd: root [net], sh -c sleep 60, sleep 60 दिखाई देते हैं
  • सफल exploitation INFO या उससे ऊपर के log entries नहीं बनाती

संदर्भ सामग्री

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

1 टिप्पणियां

 
GN⁺ 2024-04-02
Hacker News की राय

  • यह बात काफ़ी दिलचस्प है कि इसे ऐसा remote code execution नहीं बनाया गया जिसका कोई भी दुरुपयोग कर सके, बल्कि इसके लिए हमलावर की private key ज़रूरी रखी गई
    विडंबना यह है कि यह बहुत security-conscious vulnerability जैसी दिखती है

    • असल मकसद शायद backdoor की उम्र लंबी रखना रहा होगा
      अगर ऐसा बड़ा छेद छोड़ते कि कोई भी घुस सके, तो वह जल्दी मिलकर बंद कर दिया जाता; और अगर performance degradation न होती, तो यह व्यापक रूप से exploit करने योग्य नहीं है—इस वजह से शायद चुपचाप लंबे समय तक बची रहती
    • state-sponsored attack के नज़रिए से देखें तो उन systems में भी safe vulnerability डालने की कोशिश करना काफ़ी समझ में आता है जिन्हें अपने देश के लोग भी इस्तेमाल कर सकते हैं
      xz में किया गया पूरा योगदान आखिरकार इसी backdoor को डालने का काम लगता है; उदाहरण के लिए, malicious payload छिपाने के लिए test framework तक बनाया गया
      xz पर काम करने से पहले उन्होंने BSD के libarchive में भी योगदान दिया था, और वहाँ vulnerability पैदा हुई
    • यह सचमुच state-sponsored exploit जैसा दिखता है
      design और execution बेहद sophisticated थे, और performance issue के कारण इसका पता चलना लगभग पूरी तरह किस्मत जैसा लगता है
    • इसे NOBUS कहा जाता है: https://en.wikipedia.org/wiki/NOBUS
    • पढ़ने से लगता है कि payload signature में target SSH host key शामिल है; पता नहीं यह सही है या नहीं
      अगर ऐसा है, तो इसे servers पर अंधाधुंध नहीं फेंका जा सकता, और किसी एक host को भेजना भी computation के लिहाज़ से काफ़ी महंगा design है

  • यह घटना पूरे weekend मेरे दिमाग़ से नहीं निकली
    mechanism दिलचस्प है और obfuscation तकनीकों का बेहतरीन संग्रह है, और social engineering वाला हिस्सा open source maintainers के लिए शर्मनाक हद तक जाना-पहचाना किस्सा है
    सबसे दिलचस्प बात यह है कि attack vector के रूप में खराब test data चुना गया; एक अच्छा archive तैयार करके उसे संरचनात्मक रूप से manipulate करें और फिर fuzz testing के लिए खराब data की तरह इस्तेमाल करें, तो बाकी steps बेहद आसान हो जाते हैं
    आगे के लिए कहूं तो ऐसी manipulation binary pattern graphs में दिखनी चाहिए
    बाकी techniques payload तय हो जाने के बाद ज़्यादातर सामान्य obfuscation जैसी ही थीं, लेकिन सबसे कमाल की चाल यह थी कि इसी pattern से दूसरे test files में “patch” या बिल्कुल नया backdoor बिना पकड़ में आए जोड़ा जा सकता था
    GitHub का repository को छिपाकर हटाना बिल्कुल मददगार नहीं रहा, और इस घटना का analysis करने में बाधा बना

    • हमारे द्वारा इस्तेमाल किए जाने वाले open source tools की build-time dependencies संदिग्ध लगने लगी हैं
      पता चला कि वह dependency अजीब तरह से xz को पसंद करती है, और अगर यह installed न हो तो सुविधा feature की तरह host machine पर xz तक install कर देती है
      दूसरी dependencies के साथ वह ऐसा व्यवहार नहीं करती, इसलिए यह थोड़ा अजीब है
      ऐसी लंबी बाज़ी डरावनी है, और जब तक असल में “बुराई” execute नहीं होती, तब तक यह पता नहीं चलता कि क्या malicious है और क्या बस अजीब
    • मुख्य कारणों में से एक लगता है कि test input के रूप में इस्तेमाल करने के लिए repository में binary files जोड़ना था
      खासकर अगर वह test failure साबित करने के लिए “binary garbage” file हो, तो malicious content छिपाने के लिए यह बहुत बढ़िया जगह है
    • repository हटाने की वजह से अंत में केवल हमलावरों के पास code और know-how तक पहुंच रह गई

  • community, खासकर amlweems, ने इतनी जल्दी proof-of-concept code implement और document किया—यह बहुत प्रभावशाली है
    अगर crypto functions या payload loading functions में अतिरिक्त vulnerabilities नहीं हैं, तो key टूटने तक इसने बाकी सभी attackers के लिए security flaw खोला भी नहीं होगा
    अगला कदम vulnerable distributions का पता लगाने का तरीका ढूंढना है, जो आसान नहीं लगता; और hardcoded key के साथ कोई SSH servers को actively scan कर रहा है या नहीं, इसकी निगरानी का तरीका upstream में डाला जा सकता है

    • वह original exploit नहीं, बल्कि key बदले हुए version के लिए proof of concept है
      original version के proof of concept के लिए हमलावर की non-public private key चाहिए
    • हमलावर की private key के बिना network से vulnerable deployment detect करना मुश्किल से ज़्यादा असंभव लगता है
      सबसे अच्छा जो किया जा सकता है वह और सूक्ष्म benchmarking है, लेकिन किसी random internet host के धीमे होने की वजह यह है कि वह vulnerable है, वह दूर है, या computer खुद धीमा है—यह पता नहीं लगाया जा सकता
      पहले उस host से connect करने में कितना समय लगा था, इसका access भी नहीं होगा, और routing में बदलाव भी होते रहते हैं

  • जानना चाहूंगा कि क्या किसी ने इस proof of concept को abnormal process behavior detection tools पर चलाकर देखा है
    Carbon Black, AWS GuardDuty, Sysdig जैसे products इसमें आते हैं, और यह देखना कि जब यह असल में deploy हुआ होता तो क्या कोई इसे अपेक्षाकृत जल्दी पकड़ पाता—इसके लिए यह product category बहुत सही case लगती है

    • मुझे लगता है यह इस पर निर्भर है कि exploit normal compression behavior की कितनी अच्छी तरह नकल करता है या उसके भीतर कितना छिपता है
      GuardDuty, CrowdStrike या Carbon Black जैसे EDR की तरह process के अंदर नहीं झांकता, इसलिए उसे पकड़ना मुश्किल होगा; और Sysdig containers और cloud infrastructure देखता है, इसलिए exploit खुद पकड़ना मुश्किल लगता है
      हालांकि privilege escalation के बाद threat actor के follow-up actions में anomalies पकड़ने की संभावना हो सकती है
      अंततः exploit को खुद पकड़ने की सबसे अधिक संभावना endpoint processes monitor करने वाले EDR में, या upstream free/open source software के security issues monitor करने वाली software supply-chain assessment में दिखती है
      दिलचस्प बात यह है कि यह एक बड़े security topic की ओर ले जाता है
      development teams performance hit और isolation actions के समय user experience issues के कारण servers पर EDR लगाना पसंद नहीं कर सकतीं, और free/open source software के इस्तेमाल को सीमित करने वाली policies भी उन्हें पसंद नहीं आ सकतीं
      यह exploit संगठन-स्तर की “vulnerability” के ठीक बीच में वार करता है, और position के हिसाब से exposure बनाए रखने की दलील भी बनती है और उसे ठीक करने की दलील भी
    • Sysdig ने शुक्रवार को blog प्रकाशित किया था
      “runtime detection का एक तरीका यह monitor करना है कि SSHD malicious library load कर रहा है या नहीं। ऐसी shared libraries में अक्सर filename में version शामिल होता है” ऐसा कहा गया था
      blog में वास्तविक detection rule का content भी है, जो मैंने दूसरी security companies में नहीं देखा
      https://sysdig.com/blog/cve-2024-3094-detecting-the-sshd-bac...
    • मुझे लगता है कि इस पूरी product category का ज़्यादातर हिस्सा hype वाले security products जैसा है

  • मैंने नीचे दिए गए लिंक को गलत पढ़ लिया था, और मूल बात को रिकॉर्ड के लिए छोड़ रहा हूँ
    उसी mail thread में नीचे देखने पर कहा गया था कि backdoor commit करने वाले व्यक्ति ने हाल में kernel contribution भी किया है ऐसा लगता है, लेकिन मूल विश्लेषण वाकई शानदार है, इसलिए ऐसी पोस्ट पढ़ना अच्छा है
    https://www.openwall.com/lists/oss-security/2024/03/29/10

    • वह patch series Jia Tan ने नहीं, बल्कि Lasse ने डाली थी
      Lasse ने खुद भी कहा था कि यह बिल्कुल urgent नहीं है और इस merge window में नहीं आएगी, और कोई भी सामान्य व्यक्ति Lasse को malicious actor नहीं बता रहा है
    • जब तक इसका खंडन न हो, Lasse Collin Jia Tan नहीं हैं
    • संदर्भित patch series अभी kernel में शामिल नहीं हुई है
    • यह संयोग हो सकता है, लेकिन JiaT75 aviation में hijacking के लिए transponder code 7500 से काफी मिलता-जुलता है

  • इस घटना में कुछ साल पहले के Audacity incident से बेतुकी हद तक कई समानताएँ हैं
    Cookie guy ने दावा किया था कि उस पर चाकू से हमला हुआ और federal police इस मामले में शामिल थी, जो संकेत देता है कि यह घटना 4chan से कहीं बड़े actor से जुड़ी हो सकती है
    उस समय बहुत से लोगों को लगता था कि केवल Muse Group शामिल है, लेकिन शायद यह कोई Russian state actor भी हो सकता था
    उससे पहले दावा किया गया था कि Audacity में बहुत सारी telemetry और backdoor थे, जिन्हें fork करने के बाद पहले commit में हटा दिया गया
    शायद Audacity में सचमुच backdoor हो सकते हैं, इसलिए source code देखना चाहिए

    • सावधान रहना चाहिए, APT28 काफी खतरनाक है
      आजकल वह APT29 के साथ operations मिला रहा है, और मैं होता तो cozy bear को नहीं जगाता
    • Cookie guy कौन है?

  • compile time पर honey pot openssh.patch https://github.com/amlweems/xzbot/blob/main/openssh.patch के बिना, असली exploit ने runtime पर यह कैसे किया होगा, यह जानना चाहता हूँ
    chain opensshd -> systemd notification -> transient dependency के रूप में शामिल xz थी, लेकिन liblzma.so.5.6.1 memory में load होने के बाद कैसे पीछे जाकर openssh_RSA_verify तक hook या patch लगाता था, यह जानना चाहता हूँ

    • liblzma load करते समय ELF के GOT में malicious code address patch करता है
      अगर यह libcrypto से पहले load हुआ हो, तो symbol audit handler register करता है, जो शायद glibc-specific feature लगता है, और libcrypto के symbols resolve होते समय notification पाकर GOT patching को delay कर सकता है
    • यह ifunc है

  • जानना चाहता हूँ कि क्या यह exploit सिर्फ SSH connection आने पर ही काम करता था
    GitHub पर strings की list में DISPLAY और WAYLAND_DISPLAY शामिल हैं
    https://gist.github.com/q3k/af3d93b6a1f399de28fe194add452d01
    इनका SSH से साफ़ तौर पर कोई संबंध नहीं है, इसलिए संभव है कि connection न होने पर भी यह कुछ करता हो
    यह उन लोगों के लिए महत्वपूर्ण हो सकता है जो मान रहे हैं कि उन्होंने code चलाया लेकिन SSH server को internet पर expose नहीं किया, इसलिए वे सुरक्षित हैं

    • शायद इसकी बहुत संभावना है कि terminal खुला हो या GUI session में चल रहा हो तो exploit को काम न करने देने वाला kill switch हो
      यानी किसी के detection, reproduction या debugging की कोशिश वाली स्थिति से बचने का उपाय
    • यह X11 session forwarding से भी जुड़ा हो सकता है
      अगर untrusted machine से connect करते समय इसे बंद न किया जाए, तो यह client side पर आम security hole बन जाता है

  • “successful exploitation does not generate a log entry” का मतलब क्या यह है कि अगर यह exploit पकड़ा नहीं जाता, तो attacker compromised host पर उस “connection” के लिए sshd log की एक भी entry के बिना root के रूप में arbitrary commands चला सकता था?

    • हाँ
      remote code execution connection phase में होता है, log बचने से पहले
    • फिर भी corresponding login के बिना SSH traffic तो बचा होगा
      जानना चाहता हूँ कि कौन-सी anomaly detection इसे पकड़ सकती थी

  • अगर test files को अलग repository में अलग कर दिया जाता ताकि build time पर उनका इस्तेमाल न हो सके, तो क्या इस attack को और मुश्किल बनाया जा सकता था, यह जानना चाहता हूँ
    तर्क यह है कि build में जो कुछ भी शामिल हो सकता है, वह human-readable होना चाहिए

    • “build में जो कुछ भी शामिल हो सकता है, वह human-readable होना चाहिए” कुल मिलाकर अपनाने लायक अच्छा principle है
      इस attack को aircraft accident की तरह treat करना चाहिए और इसके दोबारा सफल होने की संभावना घटाने वाले नए rules लाने चाहिए
      भले ही हर एक contributor को verify न कर सकें, noisy test data को आसानी से अलग किया जा सकना चाहिए