xz sshd बैकडोर का रैबिट होल, उम्मीद से कहीं ज़्यादा गहरा

 (twitter.com/bl4sty)
2 पॉइंट द्वारा GN⁺ 2024-04-07 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • xz के sshd बैकडोर में शुरू में सामने आए RSA_public_decrypt हुक से आगे, पहुंचना अधिक कठिन अतिरिक्त कोड पाथ भी आंशिक रूप से ट्रिगर किए गए
  • अटैक फ्लो में छेड़छाड़ किए गए कमांड से mm_answer_keyallowed हुक इंस्टॉल किया जाता है, फिर कई नकली ssh-rsa public keys का उपयोग करके कमांड बफर जोड़ा जाता है
  • इस “magic buffer” में अतिरिक्त बैकडोर कमांड और 2 ed448 signatures शामिल हैं, और signatures में host key SHA256 digest तथा KEX के session_id को शामिल किया जाता है
  • मौजूदा PoC बड़े पैमाने पर संशोधित paramiko SSH client library का उपयोग करता है, और कमांड 0x03 system()-आधारित RCE तथा uid/gid सेटिंग्स को सक्षम बनाता है
  • authentication bypass भी पुष्टि हो चुका है, और mm_keyallowed_backdoor cmd 1 से mm_answer_authpassword response को ओवरराइट करके किसी भी password से लॉगिन किया जा सकता है

और गहराई से जुड़े बैकडोर पाथ

  • xz sshd बैकडोर में पहले ज्ञात व्यवहार से अधिक गहरी functionality शामिल है, और उसका कुछ हिस्सा सीधे ट्रिगर किया जा चुका है
  • मुख्य entry point RSA_public_decrypt हुक है
    • सही तरीके से तैयार किया गया कमांड भेजने पर sshd के mm_answer_keyallowed function में एक और हुक इंस्टॉल हो जाता है
    • इसके बाद कई नकली ssh-rsa public keys देकर “magic buffer” को टुकड़ों में जोड़कर बनाया जाता है
  • “magic buffer” अतिरिक्त बैकडोर कमांड रखने वाला बफर है
    • इसके भीतर 2 ed448 signatures भी शामिल हैं
    • ये signatures RSA_public_decrypt वाले बैकडोर signatures की तरह host key के SHA256 digest से salt किए जाते हैं
    • आखिरी signature SSH initial key exchange (KEX) से निकले 0x20-byte session_id को भी शामिल करता है

PoC और authentication bypass

  • मौजूदा PoC बड़े पैमाने पर संशोधित paramiko SSH client library में implement किया गया है
  • अभी ट्रिगर किया गया कमांड इस code path का 0x03 है
    • यह system() के जरिए बुनियादी RCE को फिर से संभव बनाता है
    • यह uid/gid सेट करना भी support करता है
  • अभी भी समझे जाने के लिए और code बाकी है, और mm_answer_keyallowed बैकडोर कमांड्स में से एक अंततः mm_answer_keyverify को भी हुक करता है, इसलिए interactive session का पूरा authentication bypass संभव दिखता है
  • इसके बाद authentication bypass की पुष्टि हुई
    • mm_keyallowed_backdoor cmd 1 mm_answer_authpassword के response को user-defined value से ओवरराइट कर सकता है
    • यदि response को { u32(9), u8(13), u32(1), u32(0) } पर सेट किया जाए, तो किसी भी password से लॉगिन संभव है

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

1 टिप्पणियां

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

  • https://threadreaderapp.com/thread/1776691497506623562.html

  • यह घटना कुछ मायनों में बहुत प्रोफेशनल लगती है, और कुछ मायनों में काफ़ी शौकिया, इसलिए अजीब लगती है
    एक महत्वपूर्ण पैकेज का maintainer बनने लायक भरोसेमंद पहचान लंबे समय तक बनाई गई, कई लोगों की संलिप्तता जैसा दिखने वाला social engineering attack किया गया, असली पहचान और हमले के स्रोत को उजागर नहीं होने दिया गया, और obfuscation भी काफ़ी परिष्कृत थी
    फिर भी production version में bug और performance regression का पहुँच जाना ढीला-ढाला लगता है। अगर कोई state-backed संगठन सच में बहुत सक्षम होता, तो लगता है कि वह public project में submit करने से पहले private तौर पर काफ़ी testing करके संदेह जगाने वाली performance गिरावट को हटा देता

    • “state-backed” सुनते समय शायद लोग अपेक्षाएँ बहुत ऊँची रख लेते हैं। बड़े संगठन आखिरकार दूसरे बड़े संगठनों जैसे ही हो जाते हैं और bureaucracy, deadline, release cycle, और teams के बीच communication की समस्याओं से जूझते हैं
      हाल का iOS का “शायद backdoor” वाला मामला भी दिखाता है कि बहुत-सी vulnerabilities जमा करके रखने वाले संगठन इस बात की हमेशा परवाह नहीं करते कि उनमें से कुछ जल जाएँ
    • यह मानना मुश्किल नहीं है कि code विकसित करने वाले लोग उसी समय Valgrind चलाकर performance नहीं देख रहे थे
      लक्ष्य server और appliance थे, और default image पर Valgrind चलाने वाले server या appliance कितने होंगे। बाद में सोचने पर लगता है “यह खयाल क्यों नहीं आया”, लेकिन संभव है कि उन्होंने उन्हीं system images पर test किया हो जिन्हें वे निशाना बना रहे थे, न कि किसी आम developer की custom image पर
    • 2024-02-29 को libsystemd में liblzma को link न करने के लिए एक PR आया था [0]
      Kevin Beaumont ने अनुमान लगाया कि “Jia Tan” ने यह देखकर तुरंत समझ लिया होगा कि backdoor निष्क्रिय हो सकता है, इसलिए इस exploit में लगी भारी मेहनत बेकार न जाने देने के लिए उसने जल्दी मचाई होगी [1], और यह बात सही लगती है
      उसी deadline pressure की वजह से 5.6.0 में crash हुआ होगा, और performance regression को कम या खत्म करने जैसी polishing के लिए समय नहीं मिला होगा, जो इस घटना के पकड़े जाने का मुख्य कारण बना
      [0]: https://github.com/systemd/systemd/pull/31550
      [1]: https://doublepulsar.com/inside-the-failed-attempt-to-backdo...
    • अगर Google भी बेधड़क Gemini लॉन्च कर सकता था, तो क्या यह मानना इतना कठिन है कि इस तरह के shadow organizations कहीं अधिक सूक्ष्म तरीकों से fail हो सकते हैं
      जैसा Patrick McKenzie दूसरी जगहों पर देखते हैं, criminal organizations भी non-criminal organizations की तरह ही committee और consensus से चलती हैं। उस नज़र से देखें तो feature bloat से पैदा हुई performance गिरावट के कारण जहाज़ डूबना समझ में आता है। जिन कंपनियों में मैं रहा हूँ, वहाँ इससे भी ज़्यादा शौकिया गलतियाँ हुई हैं
    • सक्षम state-backed संगठनों से भी चूक हो सकती है। intelligence agencies भी हमेशा उतनी निर्मम और सक्षम नहीं होतीं जितनी लोग कल्पना करते हैं। UK में हुई Kremlin assassination attempts तो लगभग गलतियों की कॉमेडी जैसी थीं [1]
      शायद ऐसा भी हो कि उनके इस्तेमाल में कोई दूसरा backdoor या वैकल्पिक access route बंद हो गया हो, और उन्हें जल्दी में एक नया रास्ता चाहिए था
      [1] https://en.wikipedia.org/wiki/Poisoning_of_Alexander_Litvine...

  • यहाँ जो sophistication है, वह सच में दिलचस्प है, लेकिन आखिरकार यह काफ़ी साफ़ दिखने वाली performance regression की वजह से पकड़ा गया
    इससे एक असली crime program में सुना हुआ quote याद आता है: “हत्या में पकड़े जाने के दस लाख तरीके होते हैं, और अगर उनमें से आधे भी सोच सको तो तुम जीनियस हो”

    • अगर मान लें कि account के पीछे एक team थी, तो यह समझ में आता है। किसी ने functionality विकसित की होगी, और किसी दूसरे, जो ज़्यादा लापरवाह या कम अनुभवी था, ने उसे integrate किया होगा
      कोई तीसरा व्यक्ति fake accounts संभाल रहा होगा और comments व PRs में interaction कर रहा होगा
    • हो सकता है मैं भोला हूँ या बहुत जल्दी भरोसा कर लेता हूँ, लेकिन जब भी यह चिंता होती है कि शायद ऐसे backdoors पहले से ही व्यापक रूप से फैले हुए हैं, तब यही विचार आता है
      समझ नहीं आता कि इस बार बस बदकिस्मती से यह पकड़ा गया, या ऐसे attacks को वास्तव में सफल बनाना ही बहुत मुश्किल है। उम्मीद है कि दूसरी बात सही हो, लेकिन सच में पता नहीं
    • अगर मुझे सही याद है, तो performance regression सिर्फ तब होती थी जब code को default के बजाय -fno-omit-frame-pointer के साथ compile किया जाता था। https://mastodon.social/@AndresFreundTec/112187000944648334
    • अगर काफ़ी समय मिलता और local testing ज़्यादा की गई होती, तो इसके सफल होने की संभावना काफ़ी थी
      यक़ीन है कि libsystemd के @teknoraver patch की वजह से उनकी deadline timing बदल गई
    • क्या “अगर उनमें से आधे भी सोच सको” वाली बात हत्या के मामलों को सुलझाने वालों पर भी लागू होती है?

  • जब ऐसी घटनाओं पर बारीकियों में बहुत गहराई तक जाने वाले तकनीकी लेख आते हैं, तो अक्सर यह सोचकर हैरानी होती है कि सब लोग क्यों कहते हैं, “यह ज़रूर किसी nation-state का समर्थन प्राप्त ऑपरेशन है”, “timestamp देखो, यह अकाट्य सबूत है”
    xz घटना गुप्त थी और लंबे समय तक मेहनत से तैयार किया गया हमला था, यह सही है, लेकिन क्या वाकई एक सक्षम व्यक्ति से आगे की किसी चीज़ की ज़रूरत है? यह तथ्य कि ऑनलाइन मौजूद अलग-अलग लोग इसका विश्लेषण और समझ कर सकते हैं, यह भी दर्शाता है कि यह एक व्यक्ति की समझ की सीमा के भीतर है
    ऐसा क्यों नहीं हो सकता कि यह किसी बुद्धिमान लेकिन असंतुष्ट व्यक्ति ने अकेले किया हो

    • nation-state actor की ओर इशारा करने वाला सबसे बड़ा तत्व social engineering attack में लगाए गए समय की तुलना में अपेक्षित लाभ का आकार है
      इस तरह की मुनाफ़ा-केंद्रित योजना तर्कसंगत नहीं लगती। इससे यह पूरी तरह खारिज नहीं होता कि कोई अतार्किक actor या पैसे के अलावा किसी और मकसद वाला व्यक्ति हो सकता है, लेकिन इससे nation-state actor सबसे संभावित उम्मीदवार लगता है
      अगर यह सफल हो जाता, तो इसे बेचने की संभावित कीमत बहुत बड़ी होती, लेकिन critical infrastructure में exploit डालकर उसे इतना लंबे समय तक छिपाए रखना कि ग्राहक उसे खरीदें और इस्तेमाल करें, इसकी संभावना बहुत कम है। राज्य ऐसे moonshot उठा सकते हैं, लेकिन मुझे लगता है कि कोई व्यक्ति ज़्यादा expected value वाले लक्ष्य ढूंढेगा
      बेशक, इसका यह मतलब नहीं कि यह कोई अत्यंत सक्षम nation-state actor था या इसमें बहुत अधिक संसाधन लगाए गए थे
    • सहमत। इस हैक के लिए बहुत कौशल, दृढ़ता और समय चाहिए था
      लेकिन क्या यह बात काफ़ी हद तक कई open source developers पर भी लागू नहीं होती? मकसद भी साफ़ है। इस exploit की black market में शायद millions of dollars की कीमत होती
    • कुछ भी नहीं। वह कौन था, यह किसी को नहीं पता
    • “अकाट्य सबूत” वाली बात आपने कहाँ देखी, इसका आधार जानना चाहूँगा
      जानकार लोगों के बहुत से अनुमान देखे हैं, लेकिन ऐसा शब्द इस्तेमाल होते नहीं देखा

  • क्या backdoor की obfuscation को समेटने वाला कोई लेख है? install build scripts नहीं, मेरा मतलब असली backdoor से है
    मैंने binary को Ghidra में डालकर मिली functions को देखा था, लेकिन execution intercept करने के लिए इस्तेमाल होने वाले ifunc mechanism से परिचित न होने के कारण छोड़ दिया और दूसरों पर छोड़ दिया
    उसमें anti-debugging फीचर हैं, इसलिए मुझे लगा कि code भी obfuscate किया गया होगा। चूँकि यह एक opaque binary के रूप में वितरित हुआ था, मैंने सोचा कि कम-से-कम कुछ code ऐसी key से encrypted होगा जो हमारे पास नहीं है। STUXNET payload के कुछ हिस्सों की तरह

    • backdoor पर पूरी तरह से comprehensive analysis अभी तक नहीं आई है। anti-debugging का कुछ हिस्सा flags से bypass किया जा सकता है, लेकिन इस बार यह compile stage में संभाला गया था, इसलिए मामला थोड़ा अधिक पेचीदा है
      anti-debugging फीचर होने का यह मतलब नहीं कि code ज़रूर obfuscate भी किया गया हो। जैसा ऊपर कहा गया, यह build के समय किया गया था। मानो उसने पहले से अपने ही घर में जाल बिछा दिए हों
      यह घटना दिखाती है कि जब package maintainer सही source नहीं लाता, तो कैसी समस्याएँ पैदा होती हैं

  • मैंने इस घटना को बहुत बारीकी से follow नहीं किया, लेकिन यह बहुत अजीब है कि hack के हमलावर पर लगभग कोई चर्चा सुनने को नहीं मिलती

    • “हालाँकि मेरा मानना है कि वह वास्तव में UTC+02 सर्दियों/UTC+03 DST time zone से है, यानी ऐसा क्षेत्र जिसमें पूर्वी यूरोप (EET) या इज़राइल (IST) शामिल हैं”
      https://rheaeve.substack.com/p/xz-backdoor-times-damned-time...
    • काफ़ी अटकलें रही हैं। एक व्यक्ति से ज़्यादा, कई लोगों के शामिल होने की संभावना अधिक लगती है, और यह ransomware group या किसी राज्य की intelligence agency भी हो सकती है
    • Satoshi analysis की तरह, अगर संबंधित online personas के communication का semantic analysis किया जाए तो सांस्कृतिक दिशा का अंदाज़ा लगाने में दिलचस्पी होगी
      समय के साथ writing style में अंतर आया या नहीं, यह देखने से यह भी पता चल सकता है कि क्या कई लोग एक ही persona के रूप में काम कर रहे थे। committed code भी काफ़ी है, इसलिए code style के अंतर से यह देखना भी उचित होगा कि क्या एक से अधिक लोग शामिल थे
    • क्या चर्चा करें? कुछ भी ज्ञात नहीं है

  • यह काफ़ी राहत की बात है कि यह व्यापक रूप से फैलने से पहले पकड़ा गया
    सिर्फ़ इस स्पष्ट कारण से नहीं कि हम नहीं चाहते कि कोई अज्ञात entity हमारी infrastructure पर remote code execution रखे। अगर लोग इसे लगातार खंगालते रहे, तो अंततः ऐसा payload बन सकता है जो किसी को भी backdoor इस्तेमाल करने दे
    एक entity के पास access होना बुरा है, लेकिन अगर कोई भी access पा सके, तो वह कहीं ज़्यादा बुरा है

    • अगर payload private RSA key है, तो क्या यह लगभग असंभव नहीं होगा?

  • thereaderapp.com की जगह देखने के लिए लिंक:
    https://nitter.poast.org/bl4sty/status/1776691497506623562

  • हैरानी की बात है कि कई दिन बीत जाने के बाद भी यह अब तक पूरी तरह सुलझा नहीं है
    जब दुनिया भर की नज़र इस पर हो और मुख्य हिस्से सैद्धांतिक रूप से सार्वजनिक भी हों, तब भी इसका इस हद तक टिके रहना दिखाता है कि obfuscation काफ़ी अच्छी थी

  • इस घटना में long game वाली प्रकृति चिंताजनक है
    पहला, backdoor बनाने की “infrastructure” खड़ी करने के लिए लंबे समय तक सही मौके का इंतज़ार किया गया। दूसरा, exploit के असली production में फैल जाने के बाद भी शायद किसी और लंबे खेल की तैयारी की गई होगी। lottery winnings इस्तेमाल करने का सही तरीका investment ही तो है
    तीसरा, अब सोचने पर मजबूर करता है कि क्या ऐसा खेल अभी भी चल रहा है। डर लगता है