XZ बैकडोर: “यह auth bypass नहीं बल्कि RCE है, इसमें gate है और इसे replay नहीं किया जा सकता”

 (bsky.app)
1 पॉइंट द्वारा GN⁺ 2024-03-31 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • xz बैकडोर के reverse engineering के प्रारंभिक विश्लेषण के अनुसार, यह व्यवहार साधारण auth bypass नहीं बल्कि remote code execution (RCE) के अधिक करीब है
  • हुक किया गया RSA_public_decrypt सर्वर host key के signature को एक स्थिर Ed448 key से verify करता है; यही flow का मुख्य बिंदु है
  • signature verification पास होने पर payload को system() में भेजा जा सकता है और execute किया जा सकता है
  • यह विश्लेषण अनुमति लेकर साझा किए गए प्रारंभिक निष्कर्षों पर आधारित है, और Bluesky पोस्ट में quoted post या embedded content शामिल है
  • बैकडोर को gated और unreplayable रूप में संक्षेपित किया गया है, इसलिए इसे उसी input के साधारण पुन: उपयोग वाले हमले की तरह नहीं देखना चाहिए

xz बैकडोर का execution flow

  • अनुमति लेकर साझा किया गया reverse engineering का प्रारंभिक विश्लेषण हुक किए गए RSA_public_decrypt पर केंद्रित है
    • यह सर्वर की host key के signature को एक स्थिर Ed448 key से verify करता है
    • verification के बाद payload को system() में पास करता है

वर्गीकरण और सीमाएँ

  • इस व्यवहार को auth bypass नहीं बल्कि remote code execution (RCE) के रूप में वर्गीकृत किया जाता है
  • बैकडोर को gated/unreplayable विशेषताओं वाला बताया गया है
  • मूल Bluesky पोस्ट में quoted post या अन्य embedded content शामिल है

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

1 टिप्पणियां

 
GN⁺ 2024-03-31
Hacker News की राय

  • इस मामले पर अतिरिक्त reverse engineering के नतीजे आए हैं। इसमें उस prefix trie से निकाली गई symbol remapping जानकारी शामिल है जिसका इस्तेमाल backdoor strings छिपाने के लिए करता था, और लगता है कि reverse engineering/analysis से खुद को भी छिपाने की कोशिश की गई थी
    https://gist.github.com/smx-smx/a6112d54777845d389bd7126d6e9...
    decode की गई strings की पूरी सूची यहाँ है
    https://gist.github.com/q3k/af3d93b6a1f399de28fe194add452d01
    OpenSSL internals को अच्छी तरह न जानने वाले के नज़रिये से देखें तो, N वैल्यू शायद rsa_st के n field से ली जाती है
    https://github.com/openssl/openssl/blob/56e63f570bd5a479439b...
    यह वैल्यू BIGNUM है, और यह एक variable-length type लगती है
    https://github.com/openssl/openssl/blob/56e63f570bd5a479439b...
    backdoor remote attacker से मिले certificate से यह वैल्यू निकालता है, उसे ChaCha20 से decrypt करने की कोशिश करता है, और सफल होने पर system() को दे देता है। system() लगभग एक simple wrapper है जो मौजूदा process जिस user privileges के साथ चल रहा है, उन्हीं के साथ shell script की एक लाइन चलाता है
    अगर मैंने इसे सही समझा है, तो यह public key bypass से भी बदतर है। public key bypass होने पर सैद्धांतिक रूप से सिर्फ उसी user के privileges मिलते जिसके रूप में login करने की कोशिश हो रही है, और hardened SSH settings में root login रोका गया हो सकता था
    लेकिन यह sshd process के अपने ही context में remote code execution है, इसलिए अगर sshd root के रूप में चल रहा हो, तो payload भी root के रूप में चल सकता है। व्यापक रूप से फैल सकने वाले remote code execution के हिसाब से यह व्यावहारिक रूप से लगभग सबसे खराब स्थिति है

    • सही sandboxing, SELinux, और mitigation techniques हों तो हमलावर को root privileges के साथ कुछ करने से रोका जा सकता है। हालांकि SSH daemon पर प्रभावी sandbox लगाना बहुत मुश्किल है
    • बेहद विशाल बात है। 1 अरब कंप्यूटरों के privileges से क्या करना है, यह कैसे तय किया जाएगा, इसकी मैं कल्पना भी नहीं कर सकता

  • अगर यह backdoor performance issue की वजह से न पकड़ा जाता, तो बाद में इसके पकड़े जाने की कितनी संभावना थी, यह जानने की जिज्ञासा है। मेरी समझ में performance problem code की गलती/ऐसी defect थी जिसे ठीक किया जा सकता था, इसलिए यह भी अहम है कि क्या ऐसे tools थे जो इसे पकड़ सकते थे
    ऐसे सवाल इस बात को समझने से जुड़े हैं कि क्या इस तरह का backdoor पहली बार था, या बस पहली बार सामने आया है

    • ऐसे माहौल में करीब 1 साल काम करने के अनुभव से, जहाँ malicious IT actors बहुत ज़्यादा थे, मैं कहूँगा कि पकड़े जाने की संभावना हमेशा काफ़ी ऊँची रहती है। राज़ बनाए रखना कल्पना से परे ऊर्जा माँगता है, और सच की सुसंगतता बनाए रखना भी उतना ही कठिन है
      एक छोटी सी गलती से सब कुछ बिखर सकता है, और कभी-कभी एक ही वाक्य से chain reaction शुरू होकर बारीकी से बनाई गई योजना उजागर हो जाती है
      आपराधिक जाँचें रोज़ ऐसे ही होती हैं। पुलिस के पास resource constraints होते हैं, लेकिन software को रोज़ hobby के तौर पर analyze करने वाले लोग, hobby की तरह लगातार analyze करने वाले experts, और पेशेवर तौर पर analyze करने वाले experts देखते रहते हैं
      आख़िरकार, इसके कभी न कभी पकड़े जाने की संभावना काफ़ी थी
      XZ attack बहुत अच्छी तरह अंजाम दिया गया था, लगभग एक masterpiece जैसा। अगर इसमें किसी state agency की भूमिका रही हो तो मुझे हैरानी नहीं होगी। लेकिन साथ ही यह बेहद lucky भी था। अभी जो चीज़ें problem के रूप में दिख रही हैं, उनमें से कोई एक भी मिल जाती, तो मैं ही नहीं मेरे कई सहकर्मी भी लंबी investigation में लग जाते
      इससे निकलने वाला एक निष्कर्ष यह है कि अगर xz/liblzma open source न होता, तो ऐसी समस्या ढूँढना असंभव होता। बेशक open source होने की वजह से यह शुरुआत में संभव भी हुआ, लेकिन ज़रा सोचिए कि अगर यही चीज़ Windows या MacOS के अंदर होती तो क्या होता
    • अगर exploit इस्तेमाल न किया गया होता, तो इसके पकड़े जाने की संभावना काफ़ी कम रहती। इसे छिपाने की जगह बहुत सही चुनी गई थी। यह व्यवहारतः codebase के बाहर था, ऐसी जगह जहाँ auditor की नज़र नहीं जाती
      लेकिन इस्तेमाल न करने पर इसका उद्देश्य पूरा नहीं होता। जितना ज़्यादा इस्तेमाल होगा, उतनी ही बाद में detect होने की संभावना बढ़ेगी। इसकी तुलना SolarWinds से की जा सकती है
    • लगता है आने वाले कुछ महीनों तक बहुत से लोग इस दिशा में गहराई से सोचेंगे। सवाल code review का है या किसी तरह के behavior analysis का
      निजी तौर पर मुझे system() call कुछ ढीला लगा, और संभव है कि binary feature scanner उस path को संभावित रूप से पकड़ सकता था
    • इसे पकड़ना मुश्किल ही होता। sshd patching linking stage पर होती है, जो एक स्वीकार्य चरण है, और अगर यह analysis सही है तो यह master key backdoor भी नहीं है, इसलिए सामान्य login audit traces नहीं मिलते। और sshd का दूसरे processes शुरू करना अपने-आप में स्वाभाविक रूप से अनुमत हो सकता है
      बहुत सख़्त SELinux policy हो तो शायद यह पकड़ा जा सके कि sshd shell के अलावा कुछ और चला रहा है, लेकिन उस स्तर की hardening बहुत दुर्लभ होगी
      target के बाहर से खोजने वाली समस्या का भी जैसे परीक्षण हो चुका है। कई लोगों ने valgrind वगैरह से payload को देखा, लेकिन कुछ नहीं दिखा। इसे debugging environments में न पकड़ा जाए, इसके लिए भी काफ़ी अच्छी सुरक्षा की गई लगती है। क्योंकि payload के नीचे की उजागर infrastructure, ASan जैसे tools के साथ compatible नहीं है
      भले ही यह link हो जाए, code main() से बहुत पहले execute हो जाता है, इसलिए debugger से liblzma के आसपास देखने पर भी आम तौर पर execution का वह क्षण दिखाई नहीं देगा
      strace के साथ process बनने के बाद के सभी system calls और linker actions देखे जा सकते हैं। लेकिन अब तक जो समझ आया है, उसके अनुसार payload उस चरण में activation तय करने के लिए system calls नहीं करता, बल्कि argv और environ जैसी चीज़ों को देखता है
    • एक दिलचस्प संबंधित बिंदु यह है कि Ken Thompson attack भी PWB में memory performance bug की वजह से खोजा गया था
      [0] https://en.wikipedia.org/wiki/PWB/UNIX
      [1] https://news.ycombinator.com/item?id=38020792

  • लगता है कि binary payload के अंदर एक encoded string है
    https://gist.github.com/q3k/af3d93b6a1f399de28fe194add452d01...
    यह string एक kill switch की तरह काम करती है
    https://piaille.fr/@zeno/112185928685603910
    अगर सच में ऐसा है, तो एक mitigation यह हो सकता है

    echo "yolAbejyiejuvnup=Evjtgvsh5okmkAvj" | sudo tee -a /etc/environment
    • -a ज़रूर शामिल करें। नहीं तो environment file मिट सकती है। और सामान्य तौर पर सही उपाय यही है कि malicious code रहित version पर upgrade करें और restart करें
    • यह बहुत अजीब है। इसमें ज़ोरदार state actor वाली गंध आती है, मानो वह अपने ही systems को बचाने का तरीका छोड़ना चाहता हो

  • क्या कोई संक्षेप में बता सकता है कि backdoor ठीक-ठीक क्या करता है? क्या यह अभी पता है? ऐसा नहीं लगता कि backdoor खुद payload है, तो क्या इसके लिए कोई malicious archive चाहिए, या यह sshd process में hook लगाकर remote attacker के malicious packets सुनता है?
    मूल पोस्ट से ऐसा लगता है कि attacker SSH session के authentication से पहले वाले चरण में malicious payload भेज सकता है, लेकिन यह क्यों कहा जा रहा है कि exploit शायद कभी सामने ही न आए, यह समझ नहीं आता। अगर code को reverse engineer किया जा सकता है, तो proof of concept भी लिखा जा सकता है, है न?
    आखिर attacker इस backdoor वाले machine पर control कैसे पाता है?

    • इसे ऐसे समझें जैसे एक दरवाज़ा जो सिर्फ सही knock करने पर खुलता है। जिसे secret knock नहीं पता, उसके लिए वह सिर्फ दीवार जैसा दिखता है और वैसा ही व्यवहार करता है। secret knock के बिना शायद यह साबित करने का भी कोई तरीका न हो कि वह खुलता है
      यहाँ भी स्थिति कुछ ऐसी ही है। xz कोई संदिग्ध काम करने से पहले कुछ data को decrypt करने की कोशिश करता है। यह asymmetric तरीका है, इसलिए secret encryption key दिए बिना भी decryption verify किया जा सकता है। क्योंकि matching public key मौजूद है
      secret key को ढूँढना व्यावहारिक रूप से असंभव है, और payload decryption विफल होने पर इसका व्यवहार किसी स्पष्ट तरीके से अलग नहीं दिखता, इसलिए हो सकता है कि exploit code कभी सार्वजनिक न हो। exploit code बनाने का एकमात्र तरीका यही है कि secret key किसी तरह मिल जाए, और व्यावहारिक रूप से यह तभी होगा जब backdoor developer ही उसे leak करे
    • जो मैंने पढ़ा है उसके आधार पर attack vector कुछ ऐसा दिखता है। sshd शुरू होता है, libsystemd को load करता है, और वह XZ library को load करती है जिसमें hacked code मौजूद है
      XZ library RSA signature verify करने वाली OpenSSL functions के अपने versions inject करती है
      जब कोई SSH में login करते समय authentication के लिए signed SSH certificate पेश करता है, तो वही modified functions call होती हैं
      certificate में सामान्य login प्रक्रिया के दौरान username या role जैसी assertions हो सकती हैं, जिनसे तय होता है कि certificate किसी खास user login के लिए valid है या नहीं। लेकिन अगर modified functions किसी खास attacker key से signed certificate पहचान लें, तो वे certificate के कुछ subfields निकालकर उन्हें system command के रूप में execute करती हैं। execution context sshd का होता है, यानी root user
      दुर्भाग्य से attacker की signing key ज्ञात नहीं है, और केवल वही public key ज्ञात है जिसका उपयोग hacked code verification के लिए करता है। मूल रूप से attacker संक्रमित system पर root के रूप में arbitrary command execution कर सकता है, और निशान शायद ज़्यादा से ज़्यादा failed login attempt जैसा ही दिखेगा। अगर system internet-exposed है, तो वैसे भी ऐसे attempts बहुत आते रहते हैं
    • अभी भी लगता है कि यह ठीक-ठीक क्या करता है, यह पता नहीं है। लेकिन “replay नहीं हो सकता” वाले हिस्से को मैं ऐसे समझता हूँ। अगर payload गलत हो, या attacker key का signature verify न हो, तो backdoor सामान्य व्यवहार पर लौट जाता है
      attacker key के signature की ज़रूरत होना ही मुख्य बात है। जब तक वह key leak न हो जाए या RSA algorithm टूट न जाए, तब तक दूसरे researchers या तीसरे पक्ष के लिए इस backdoor का दुरुपयोग करना असंभव है। अगर RSA टूट जाए तो यह उससे भी बड़ी समस्या होगी
    • अगर public-key cryptography सही तरह से इस्तेमाल हुई है और उसमें कोई exploitable bug नहीं है, तो reverse engineering करने पर भी proof of concept नहीं बनाया जा सकता
    • वितरित exploit source नहीं बल्कि binary था, और test data के भीतर चतुराई से छिपाया गया था। साथ ही payload को एक non-public private key से verify किया जाता है
      फिलहाल केवल attacker ही exploit चला सकता है, इसलिए scanning भी संभव नहीं है। performance degradation जैसे secondary effects को छोड़ दें तो इसे detect करना कठिन है, और वास्तव में यह उसी तरह पकड़ा गया

  • यह समझना मुश्किल है कि इतना महत्वपूर्ण package, जिसे इतने सारे Linux servers रोज़ इस्तेमाल करते हैं, funding की कमी के कारण अपने मूल लेखक द्वारा maintain नहीं किया जा सका। open source में कुछ बदलना चाहिए
    एक समाधान ऐसा license हो सकता है जो एक निश्चित आकार से बड़ी companies या businesses को maintenance cost चुकाने के लिए बाध्य करे

    • ऐसे license का लोग काफ़ी विरोध करते हैं। “यह अब free नहीं रहा” वाली बड़ी प्रतिक्रिया शुरू हो जाती है, और संबंधित इकाई को cancel कर दिया जाता है
    • मैं सोच रहा हूँ कि क्या सचमुच funding की कमी थी, या फिर burnout
    • प्रस्तावित EU Cyber Resilience Act खुद को समाधान के रूप में पेश कर रहा है। मोटे तौर पर, चाहे firewall हो या toaster, vendor अपने product lifetime के दौरान vulnerabilities के लिए ज़िम्मेदार होगा
      इसलिए vendors के पास open source को सुरक्षित बनाए रखने की प्रेरणा होगी। जैसे maintainers को पैसा देना, code audit करवाना, या full-time कर्मचारियों को hire करके contribution कराना
    • importance और necessity एक ही चीज़ नहीं हैं। यह package महत्वपूर्ण से ज़्यादा ज़रूरी package है
    • यह समझना कठिन है कि xz जैसी इतनी complex चीज़ की ज़रूरत क्यों है। bzip2 का code छोटा है, और शायद एक व्यक्ति के बहुत थोड़े समय से भी maintain किया जा सकता है

  • अगर आप अभी xz repository में जाएँ, तो वह GitHub Terms of Service violation के कारण disabled दिख रही है। disabled होना तो स्वाभाविक है, लेकिन अच्छा होता अगर GitHub code और history को रहने देता, एक banner दिखाता, और केवल exploitable functionality को block करता
    इससे researchers और दूसरे लोग exploit को सीख सकते। कम गंभीर मामलों में अगर कोई library malicious code host करते हुए repository हटवा दे, तो लोग शायद उसे मामूली बात समझकर नज़रअंदाज़ कर दें

    • शायद वे नहीं चाहेंगे कि automated tools इसे download करें
    • उस repository की GitHub events को CSV के रूप में यहाँ देखा जा सकता है: https://github.com/emirkmo/xz-backdoor-github
      अगर source code में रुचि है, तो उसे ढूँढना आसान है। यह code और Git repository दुनिया भर की कई Git repositories से जुड़ी हुई है, और releases में source कई बार bundled रहा है
    • xz का अपना Git mirror है, इसलिए सभी commits देखे जा सकते हैं

  • एक कम-ज्ञात open source गेम का व्यावहारिक रूप से मेंटेनर होने के नाते, मैंने डेवलपर्स को आते-जाते देखा है। जो भी मूल्यवान योगदान होता है, उसे बस मर्ज कर देता हूँ
    कुछ सहयोगी अलग-अलग coding style के साथ C और C++ के मिले-जुले कोडबेस में काफ़ी गहराई तक बदलाव करते हैं। मैं हमेशा implementation details पूरी तरह नहीं समझ पाता, लेकिन मन के एक कोने में यह डर रहता है कि अगर कोई सचमुच बुरा backdoor डाल दे, तो प्रोजेक्ट बर्बाद हो सकता है
    अच्छी बात यह है कि गेम इतना obscure है और इसका attack surface भी बहुत छोटा है। फिर भी, इससे कम-से-कम Windows binaries को नेक इरादे से sign करने का लालच छोड़ दिया है
    यह xz backdoor वाकई एक बहुत बड़ा दुःस्वप्न है, और मूल डेवलपर्स तथा इसमें फँसे हर व्यक्ति के लिए दुख होता है

    • बात सही है, लेकिन यह सिर्फ़ software की समस्या नहीं है। सच कहूँ तो, मुझे यक़ीन नहीं कि किसी सार्थक अर्थ में इसे “समस्या” कहना भी सही है
      जब आप जंगल के रास्ते पर चल रहे होते हैं, तो कोई गुज़रती कार आपको बस टक्कर मारकर निकल सकती है। ड्राइवर के पकड़े जाने की संभावना कम है, इसे रोकने का कोई तरीका नहीं, और पुलिस भी पास नहीं है। software backdoor से कहीं ज़्यादा डरावना यह परिदृश्य दरअसल उन न्यूनतम जोखिमों में से है जिन्हें कुछ करते हुए जीने के लिए स्वीकार करना पड़ता है। और हाँ, ऐसा वास्तव में होता भी है
      लेकिन अंततः ज़्यादातर लोग सक्रिय रूप से दूसरों को नुकसान पहुँचाने की कोशिश नहीं करते। इंसानों के हर काम की बुनियाद हमेशा से इसी धारणा पर रही है, और आज भी है
      यह भ्रम कि code review को थोड़ा और सख़्त कर देने, linter, CI और pattern matching का ज़्यादा इस्तेमाल करने, code signing को और फैलाने, और लोगों की पहचान सत्यापित करने से ऐसी चीज़ें रुक जाएँगी—असल समस्या वही है। यह उस Silicon Valley शैली के भ्रम का लक्षण है कि दुनिया को हर सूक्ष्म स्तर पर प्रबंधित और नियंत्रित किया जा सकता है, और किया जाना चाहिए। ऐसे “इलाज” अक्सर उस बीमारी से भी बदतर हो सकते हैं जिसे वे रोकना चाहते हैं
    • ZeroMQ के दिवंगत Pieter Hintjens ने Optimistic Merging नाम की प्रथा का समर्थन किया था। इसमें योगदानों को code review या CI results का इंतज़ार किए बिना तुरंत मर्ज कर दिया जाता है। ढीले merge criteria रखने वाला यह तरीका पूरी तरह असंगत नहीं है
      [1]: http://hintjens.com/blog:106
      मैं यह समझता हूँ कि इससे ऐसा community बन सकता है जहाँ contributors प्रोजेक्ट में भाग लेकर अच्छा महसूस करें। लेकिन मुझे यह हमेशा ऐसा लगा कि इससे प्रोजेक्ट बिना किसी स्पष्ट vision या direction के बढ़ता जाता है, और अंत में दूसरे लोगों के योगदानों को किसी साझा मानक तक लाने का असंगत बोझ maintainers पर डाल देता है
      असली code review किसी अज्ञात भविष्य के समय तक टल जाता है, और तब वह review कितना गहरा होगा, कौन उसकी ज़िम्मेदारी लेगा, या समस्याओं को कौन ठीक करेगा—यह सब अस्पष्ट रहता है। अंत में यह मुझे ऐसे नुस्खे जैसा लगता है जो इस बात पर से नियंत्रण ही हटा देता है कि users तक वास्तव में क्या ship हो रहा है
      इसमें malicious code के distribution की समस्या भी है। उस blog post की comments में भी यह मुद्दा उठता है, और Pieter ठीक वही scenario बताते हैं जो xz मामले में हुआ
      “मान लीजिए Mallory धैर्यवान, छलपूर्ण है, और काफ़ी समय तक एक वैध contributor जैसा व्यवहार करके प्रोजेक्ट पर नियंत्रण पा लेता है, फिर धीरे-धीरे backdoor डालना शुरू करता है। तब सावधानीपूर्वक code review भी मदद नहीं करेगा। Mallory को बस इतना trust हासिल करना है कि वह maintainer बन सके; यह संभव है या नहीं, इसका नहीं बल्कि कैसे का सवाल है।”
      वे निष्कर्ष निकालते हैं कि “सबसे अच्छी रक्षा community का आकार और विविधता है”
      लेकिन मेरा मानना है कि सावधानीपूर्वक code review वास्तव में ऐसी घटना की संभावना कम कर सकता है। चाहे trusted contributor हो या बाहरी contributor, अगर हर contribution की गहराई से समीक्षा की जाए, तो अजीब व्यवहार या ऐसे commits जो “A करते हैं” कहें लेकिन वास्तव में B करें, उन्हें पहले पकड़ने की संभावना बढ़ती है
      यह भी विवाद का विषय है कि क्या Optimistic Merging सचमुच बड़े और अधिक विविध community की ओर ले जाता है। कड़े contribution guidelines के बावजूद कई projects में सक्रिय community होती है। और यह अब भी इस सवाल का जवाब नहीं देता कि malicious patch को कब और कैसे पकड़ा जाएगा
      xz की समस्या यह नहीं थी कि community छोटी थी, बल्कि यह थी कि community थी ही नहीं। एक अकेले malicious actor ने प्रोजेक्ट पर नियंत्रण पा लिया था, और लगभग किसी दूसरे की निगरानी थी ही नहीं। contribution guidelines community के आकार का कारण नहीं थीं, और चाहे Optimistic Merging इस्तेमाल हुआ हो या नहीं, यह फिर भी हो सकता था
      [2]: http://hintjens.com/blog:106/comments/show#post-2409627
    • यह देखकर मैं हमेशा हैरान होता हूँ कि कंपनियाँ network perimeter security पर बहुत भारी मेहनत करती हैं, लेकिन dev organizations में लोग रोज़मर्रा में brew install cask या vi/emacs/vscode extensions इंस्टॉल करते रहते हैं
      Rust को शायद default रूप से सबसे सुरक्षित programming language/community कहा जा सकता है, और इसका security-first design pointer वाली शरारतों को लगभग असंभव बना देता है। फिर भी सबसे आम और recommended install path यह है, और मैं खुद भी पूरा पाखंडी हूँ क्योंकि मैं भी अक्सर यही करता हूँ
      https://www.rust-lang.org/tools/install
      यह सिर्फ़ एक उदाहरण है। बहुत से लोगों के लिए “इसे curl करो और sh में pipe कर दो” वाली आदत muscle memory बन चुकी है—यानी remote code execution का दरवाज़ा खुद खोलना, और साथ ही किसी के unsafe block पर बहस करना
    • ईमानदारी से कहूँ तो, हमारी सद्भावना का दुरुपयोग होगा यह बस समय की बात थी। “जल्दी थककर जल्दी ठीक कर लो” या “कोई मेरा प्रोजेक्ट ownership लेना चाहता है?” जैसी हरकतें समस्या को न्योता देती हैं, लेकिन जब तक open source कोडिंग के लिए बिना भुगतान वाला प्रेम-श्रम बना रहेगा, तब तक इनके बिना दुनिया की कल्पना करना भी कठिन है
      यह हुआ, इसका दुःख है, लेकिन हैरानी नहीं। काश ऐसे malicious actors का मुकाबला करने के लिए बेहतर tools आएँ, और वे भी open source हों

  • यह backdoor कई सवाल खड़े करता है। उसी टीम या मिलती-जुलती किसी टीम ने और कौन-से backdoor लगाए होंगे? ऐसी टीमें कितनी सक्रिय हैं? ऐसे घुसपैठ हमलों के प्रति संवेदनशील dependencies कितनी हैं? हमारे उद्योग में इस तरह के गुप्त targeted operations के लिए attack surface कितना बड़ा है?
    apache httpd, postgres, mysql, nginx, openssh, dropbear ssh, haproxy, varnish, caddy, squid, postfix जैसी प्रमुख network services और उनकी सभी dependencies, और उन dependencies के पूरे committer graph को बनाना शायद यह समझने का पहला कदम हो सकता है कि सबसे अधिक मूल्य कहाँ है और निगरानी सबसे कम कहाँ है
    यह किसी के द्वारा ऐसा करने की पहली कोशिश नहीं हो सकती। यह सिर्फ पहली कोशिश है जो असफल हुई और सामने आ गई। Linux kernel में आज़माया गया और पकड़ा गया backdoor हमें मालूम है, लेकिन यह remote attack है और प्रकृति में पूरी तरह अलग है

    • सबकी तरह zero-day इस्तेमाल करने के बजाय backdoor बनाने का फैसला क्यों किया गया होगा?
      ऐसा कुछ क्यों नहीं बाँटा गया जो harmless दिखे और पकड़े जाने पर bug जैसा लगे, बल्कि पूरी तरह functional backdoor लागू किया गया और उसकी deployment method तक छिपाने की कोशिश की गई?
      यह एक सोचा-समझा निर्णय रहा होगा। इसका कारण लक्ष्य क्या था, इस बारे में संकेत दे सकता है
    • यह भी पूछा जाना चाहिए कि Debian ने ऐसी services, जो root के रूप में चलती हैं और इंटरनेट से connections स्वीकार करती हैं, उनसे अनावश्यक libraries load कराने के लिए patch क्यों किया

  • इसका मतलब शायद यह है कि remote exploit के लिए scan करने के लिए हमलावर की private key चाहिए, जो हमारे पास नहीं है। दूसरा विकल्प सिर्फ local detection script चलाना ही है

    • scanners के लिए चुना जा सकने वाला एक बिल्कुल भयानक तरीका यह होगा कि अगर RSA authentication उपलब्ध हो, तो उसे “potentially vulnerable” के रूप में mark कर दिया जाए। ज़्यादातर SSH servers RSA authentication उपलब्ध कराते हैं, और वास्तव में SecSH RFC भी इसे implement करना अनिवार्य बताता है। इससे लोग password authentication पर लौटने के लिए प्रोत्साहित हो सकते हैं
      जब तक यह साबित न हो जाए कि यह समस्या वास्तविक systems में व्यापक रूप से फैली हुई है, तब तक ऐसा तरीका उन पुराने समान “experts” से भी बदतर लगेगा जो हर साल password बदलवाने पर ज़ोर देते थे, जिससे वास्तविक security घटती थी और सिर्फ कागज़ी security बेहतर दिखती थी
    • चूँकि ऐसा लगता है कि signature verification code तभी चलता है जब client public key किसी खास fingerprint से मेल खाती है, इसलिए शायद timing information से इसका पता लगाया जा सके
      backdoor का signature verification लगभग 100µs लेगा, इसलिए fingerprint से मेल खाने वाली key का processing time अन्य keys की तुलना में उतना अधिक होना चाहिए। यह time difference कम-से-कम LAN पर व्यावहारिक रूप से detect किया जा सकता है, और अगर scanner लक्ष्य के काफ़ी पास से चलाया जाए, तो इंटरनेट के पार भी संभव हो सकता है
      repeated authentication failures के बाद client IP को block करने वाले systems scanning को और कठिन बना देंगे
      (https://bench.cr.yp.to/results-sign.html में Ed448 verification लगभग 4 लाख cycles बताया गया है, जो 4GHz पर 100µs के बराबर है)
    • ट्वीट में कहा गया है कि यह “replay नहीं किया जा सकता”। यह replay क्यों नहीं किया जा सकता, यह जानने की जिज्ञासा है। क्या backdoor लगा हुआ sshd कोई challenge देता है और हमलावर को उसी पर sign करना होता है?

  • यह शायद अलोकप्रिय राय हो, लेकिन पूरे operation की प्रशंसा किए बिना रहना मुश्किल है। निस्संदेह इसकी निंदा की जानी चाहिए, लेकिन फिर भी यह प्रभावित करता है। कल्पना से लेकर execution तक यह सचमुच एक कलाकृति जैसा था, और इसका इतनी जल्दी पकड़ में आ जाना बेहद बड़ा सौभाग्य था

    • अगर payload ने SSH login के दौरान बेतरतीब 0.5 सेकंड का ठहराव पैदा नहीं किया होता, तो शायद यह लंबे समय तक पकड़ा ही नहीं जाता
      अगली बार हमलावर संभवतः ऐसा payload बनाएँगे जो उन कामों में असामान्य latency spikes पैदा न करे जहाँ इंसान इंतज़ार कर रहा होता है
      इससे मुझे किसी तरह Kim Dotcom का वह मामला याद आता है जब उसे पता चला कि वह अवैध wiretapping का निशाना है। वजह यह थी कि MW3 में अचानक उसका ping बहुत बढ़ गया था। जाँच करने पर पता चला कि सिर्फ उसके packets को भौतिक रूप से बहुत दूर स्थित GCSB कार्यालय के रास्ते route किया जा रहा था। GCSB के पास New Zealand के permanent resident की जासूसी करने का अधिकार नहीं था। अंत में उसे New Zealand के प्रधानमंत्री से व्यक्तिगत माफ़ी मिली थी
    • “वैसे भी merge नहीं किया जाना चाहिए था, लेकिन उस व्यक्ति ने कमाल का काम किया। भयानक था, मगर कमाल का था।”
      मेरे हिसाब से सबसे चतुर हिस्सा project selection था जिसमें घुसपैठ की गई। बाद में “Hans” की IFUNC pull request चर्चा पढ़ना दिल तोड़ने वाला है, लेकिन यह बहुत अच्छी तरह दिखाता है कि यही project क्यों चुना गया
      मैं जानना चाहूँगा कि “Jia” और “Hans” के पीछे कितने लोग थे, और उन्होंने communication तथा code contributions का विश्लेषण और रणनीति कैसे बनाई। mailing list पर दबाव बनाने का नाटक करने वाले तीसरे व्यक्तित्व जैसे कुछ पहलू थोड़े ढीले-ढाले बनाए गए लगते हैं
      इसलिए अब भी यह संभव है कि यह किसी परिष्कृत छोटी टीम, या यहाँ तक कि किसी अकेले व्यक्ति का काम रहा हो। अगर यह कोई state actor था, तो मैं मानूँगा कि ऐसे operation के लिए fake personas को दिन भर बनाने और बनाए रखने वाले लोग होते होंगे
      अगर किसी ने सोचा होता, “ये तीन users कुछ ज़्यादा ही रूखे ढंग से दबाव बना रहे हैं, ये कौन हैं? तीनों accounts लगभग एक ही समय पर बने हैं। यह संदिग्ध है। कोई fake accounts से इस चीज़ को इतना ज़ोर देकर आगे क्यों बढ़ाएगा? इसकी जाँच करनी चाहिए,” तो दिक्कत हो सकती थी। कुल डाले गए effort की तुलना में वह हिस्सा लापरवाह, खराब योजना वाला, या कम बजट वाला लगता है
    • सहमत हूँ, लेकिन social engineering वाला हिस्सा विशेष रूप से क्रूर लगता है
    • मुझे नहीं लगता यह इतनी अलोकप्रिय राय है। कई मायनों में यह बेहद प्रभावशाली हमला है। यह सूक्ष्म था, कई वर्षों में तैयार किया गया था, और अगर हमलावर ने वह अजीब performance degradation वाली गलती न की होती जिसने जाँच शुरू कराई, तो शायद हमें कभी पता ही नहीं चलता
      अगर एक नाटकीय परिकल्पना जोड़ें, तो संभव है कि हमलावर उस सूचना-परमाणु बम से डर गया हो जिसे वह फोड़ने वाला था, और उसने जानबूझकर इसे बिगाड़ दिया हो
      अंतिम परिणाम से घृणा करते हुए भी हम हमले की जटिलता को स्वीकार कर सकते हैं
    • “प्रशंसा” सही शब्द है या नहीं, पता नहीं, लेकिन यह निश्चित रूप से काफ़ी प्रभावशाली operation था