XZ बैकडोर: समय, अभिशप्त समय, और धोखे
(rheaeve.substack.com)- xz/liblzma tarball में मिले बैकडोर को लेकर, Jia Tan के Git commit timezone और काम के पैटर्न को उसके वास्तविक सक्रिय क्षेत्र का अनुमान लगाने के सुराग के रूप में इस्तेमाल किया गया
- commit समय को
GIT_AUTHOR_DATEऔरGIT_COMMITTER_DATEसे बदला जा सकता है, लेकिन पूरे टाइमलाइन को विश्वसनीय रूप से मिलाने की तुलना में सिर्फ timezone बदलना अधिक आसान रहा होगा - Jia Tan के 440 commit में से अधिकांश UTC+08 में दर्ज हैं, लेकिन कुछ UTC+02·UTC+03 रिकॉर्ड पूर्वी यूरोप की winter/summer time switching से मेल खाते हैं
- 6 अक्टूबर 2022 और 27 जून 2023 की timezone switching इतनी कम दूरी पर दिखती है कि उसे वास्तविक यात्रा से समझाना कठिन है, जिससे साधारण travel की संभावना कमजोर पड़ती है
- कुछ +0200 commit संभवतः Lasse Collin ने
git amसे patch apply करते समय बनाए, इसलिए email patch workflow में timezone information की विश्वसनीयता सीमित हो जाती है
xz बैकडोर और विश्लेषण का दायरा
- xz/liblzma tarball में मिला बैकडोर free software ecosystem के भरोसे को गहराई से हिला देने वाली घटना माना गया
- माना जाता है कि यह बैकडोर xz के लंबे समय के maintainer Jia Tan ने डाला हो सकता है
- समुदाय में Jia Tan के बारे में उसके नाम के अलावा लगभग कोई जानकारी नहीं थी, और वह नाम भी वास्तविक न हो सकता है
- विश्लेषण का आधार JiaT75 की GitHub activity और xz repository के commit timestamp हैं
- शुरुआती संदर्भ के रूप में सार्वजनिक लेख oss-security mailing list post है
Git timestamp को फर्जी बनाना कठिन क्यों है
- Git commit time को
GIT_AUTHOR_DATEऔरGIT_COMMITTER_DATEenvironment variable से बदला जा सकता है - जो commit अभी push नहीं किए गए हैं, उन्हें amend करके बाद में तारीख बदलना भी संभव है
- लेकिन विश्वसनीय time data forgery पर कई तरह की पाबंदियाँ होती हैं
- अगर ऐसा commit push किया जाए जो भविष्य में बना हुआ लगे, तो शक हो सकता है
- online discussion से भी पुराना दिखने वाला commit भी अस्वाभाविक लगता है
- ऐसी पाबंदियों से बचने के लिए commit रोककर रखने पड़ सकते हैं, जिससे project development में देरी हो सकती है
- वास्तविक समय बदलने के बजाय अगर सिर्फ timezone बदला जाए, तो गणना या commit delay के बिना धोखा देना अधिक आसान हो सकता है
UTC+08 रिकॉर्ड और UTC+02/03 की संभावना
- Jia Tan के अधिकांश commit, कुल 440, UTC+08 timestamp में दर्ज हैं
- UTC+08 चीन के CST का संकेत हो सकता है, लेकिन Indonesia, Philippines और Western Australia भी इसी timezone में आते हैं
- Jia Tan जैसा नाम किसी एशियाई, खासकर चीनी, पहचान का आभास देने का संकेत भी हो सकता है
- यह संभावना रखी गई कि वास्तविक सक्रिय क्षेत्र UTC+02 winter time / UTC+03 summer time वाला इलाका रहा हो
- इसमें पूर्वी यूरोप का EET, Israel का IST आदि शामिल हैं
- अगर UTC+08 रिकॉर्ड को UTC+02/03 के आधार पर समायोजित किया जाए, तो काम का पैटर्न सामान्यतः सुबह 9 बजे से शाम 6 बजे तक दिखता है
- बिना समायोजन के वही पैटर्न मंगलवार रात 12 बजे और सुबह 1 बजे काम करने जैसा लगता है, जो कम स्वाभाविक है
timezone switching से मिले संकेत
- कुछ commit ऐसे हो सकते हैं जहाँ Jia Tan timezone बदलना भूल गया हो
- UTC+02 के 3 commit और UTC+03 के 6 commit मिले
- UTC+02 फरवरी और नवंबर की winter time से मेल खाता है
- UTC+03 जून, जुलाई और अक्टूबर की शुरुआत के summer time से मेल खाता है
- यह पूर्वी यूरोप के summer time transition, यानी अक्टूबर के आखिरी weekend के बाद +0200 और मार्च के आखिरी रविवार के बाद +0300, के पैटर्न से मेल खाता है
- यह timezone Lasse Collin और Hans Jansen के timezone से भी मेल खाता दिखता है
- 2 अप्रैल के update में Joey Hess की टिप्पणी के आधार पर यह जोड़ा गया कि ऐसे कई मामले वे commit हैं जिनमें committer Lasse Collin है
- हालांकि Lasse द्वारा commit किए गए Jia के सभी commit में यही पैटर्न नहीं दिखता, और कई बार वे +0800 में दर्ज हैं
- इसलिए +02/03 commit गलती थे या सिर्फ workflow का बदलाव, यह साफ नहीं है
वास्तविक यात्रा मानना कठिन क्यों है
- यह कहना कि UTC+08 में रहने वाला व्यक्ति कभी-कभार UTC+02/03 क्षेत्र में उड़कर गया, detailed timestamp से अच्छी तरह मेल नहीं खाता
- 6 अक्टूबर 2022 को 21:53:09 +0300 commit के बाद 17:00:38 +0800 commit है
- दोनों commit के बीच अंतर लगभग 11 घंटे है
- चीन से पूर्वी यूरोप या मध्य पूर्व तक केवल उड़ान का समय ही कम से कम 10~12 घंटे होता है, और direct flight दुर्लभ होने से यह और लंबा हो सकता है
- 27 जून 2023 को 23:38:32 +0800 commit और 17:27:09 +0300 commit लगातार दिखते हैं
- दोनों commit के बीच का अंतर कुछ मिनटों के स्तर का है
- ऐसे transition इस संभावना को मजबूत करते हैं कि Jia Tan वास्तव में UTC+08 CST क्षेत्र में नहीं था
छुट्टियाँ और सप्ताह के बीच काम का पैटर्न
- holiday pattern भी चीन की तुलना में पूर्वी यूरोप से अधिक मेल खाता दिखाई देता है
- चीन की सार्वजनिक छुट्टियों के लिए Bank of China Indonesia की 2023 holiday guide का संदर्भ लिया गया
- चीन की सार्वजनिक छुट्टियों के रूप में बताए गए दिनों में भी काम के रिकॉर्ड हैं
- 29 सितंबर 2023: Mid-Autumn Festival
- 5 अप्रैल 2023: Qingming Festival
- 22~27 जनवरी 2023 आदि: Spring Festival अवधि
- पूर्वी यूरोप की छुट्टियों के संदर्भ में 25 दिसंबर Christmas और 31 दिसंबर व 1 जनवरी New Year पर काम का रिकॉर्ड नहीं दिखता
- Jia के सबसे सामान्य कामकाजी दिन मंगलवार 86 बार, बुधवार 85 बार, गुरुवार 89 बार और शुक्रवार 79 बार हैं
नाम और patch apply करने से जुड़ी caveat
- अगर “Jia Cheong Tan” वास्तविक नाम है, तो यह चीन में इस्तेमाल होने वाले Han character नाम की वैध Romanization नहीं लगता, बल्कि Malaysia जैसे Southeast Asia क्षेत्र की naming style के करीब बताया गया है
- “Cheong” spelling आधुनिक चीन में प्रचलित नहीं मानी जाती, और यह उदाहरण भी दिया गया कि चीनी शैली की English naming में नाम के अक्षर आमतौर पर जुड़े हुए लिखे जाते हैं
- उदाहरण “Yangqing Jia” है, “Yang Qing Jia” नहीं
- हालांकि +0200 वाले दो commit
de5c5e4,e446ab7aमें committer Lasse Collin है, और वे संभवतः Jia द्वारा email से भेजे गए patch कोgit amसे apply करके बने - उन commit और पास के कुछ commit में एक जैसे timestamp हैं, जो
git amसे patch file bundle apply करने की स्थिति से मेल खाते हैं - जब patch email के जरिए आते-जाते हैं, तो timezone information पर भरोसा करना कठिन हो जाता है, इसलिए इस विश्लेषण का कुछ हिस्सा कमजोर पड़ता है
1 टिप्पणियां
Hacker News राय
अगर यह राज्य-समर्थित हमला था, तो इस बात की पूरी संभावना है कि कोड और mailing list संदेश लिखने वाले व्यक्ति/विभाग के अलावा एक अलग टीम भी रही हो, जो उनके इंटरनेट पर जाने के समय और timestamps को “project settings के अनुरूप कहानी” से मिलाती हो
कभी-कभी उन्होंने जानबूझकर “गलतियां” भी डाली होंगी, ताकि जांचकर्ताओं को असली जगह नहीं बल्कि कोई और चुनी हुई जगह लगे
एक दूसरे लेख[1] में भी यह संभावना उठाई गई थी कि अचानक बने accounts ने urgency पैदा कर maintainer handover को तेज कराया हो सकता है
[1] https://connortumbleson.com/2024/03/31/watching-xz-unfold-fr...
via: https://news.ycombinator.com/item?id=39888854
संबंधित हिस्सा "Progress will not happen until there is new maintainer" खोजने पर मिल जाएगा
इसमें यह दिखाना भी शामिल है कि गतिविधि किसी खास location से हो रही है, और साथ ही इसे एक से ज्यादा व्यक्ति जैसा न दिखने देना भी
मुझे नहीं लगता कि वह पूर्वी यूरोप से है, लेकिन UTC+0200/+0300 देखें तो यूरोप में Finland, Baltic देश, Ukraine, Romania, Moldova और Greece इसके दायरे में आते हैं
थोड़ा नीचे जाएं तो Israel सहित Middle East का काफी बड़ा इलाका भी इसमें आ जाता है
हालांकि Finland में आम तौर पर July को पसंद किया जाता है, इसलिए यह वहां कम आम है
देखने में यह आपस में मेल खाता लगता है
खासकर IDF की Unit 8200 की काफी प्रसिद्ध reputation है
इसका मतलब यह नहीं कि दूसरे देशों में क्षमता नहीं है, और यह हमला ऐसा भी नहीं लगता कि इसके लिए NSA या GCHQ स्तर के संसाधन जरूरी हों। असल में यह एक अकेला भेड़िया भी हो सकता है, फिर भी यह ध्यान देने लायक है
जिन ताकतों के पास लगभग असीम संसाधन और प्रेरणा होती है, वे जिम्मेदारी को किसी खास दिशा में मोड़ने के लिए false flag operations कर सकती हैं। ये लोग निशान मिटाने में बहुत माहिर होते हैं, और सबसे अनुभवी security researchers को भी यह educated guess लगाने में कि जिम्मेदार कौन है, महीनों या सालों लग सकते हैं
इसलिए “किसने किया” पता लगाने की कोशिश लगभग समय की बर्बादी है
सबक यह है: production environment में किसी भी वजह से cutting-edge unverified software न डालें; संगठन के penetration testers नियमित रूप से stack तोड़कर देखें और नतीजे संगठन व package maintainers को बताएं; free और open source maintainers को हर release में खासकर security-sensitive नए code का audit करना चाहिए; और maintainers को donate करना चाहिए
शुक्र है कि यह stable में नहीं गया, और system के अंदर security Chernobyl फटने से ठीक पहले हम बाल-बाल बच गए
कुछ लोग सभी को यह मनवाने की कोशिश कर रहे हैं कि कोई खास शक्ति जिम्मेदार है, और इसमें geopolitical उद्देश्य हैं। उदाहरण के लिए, जब US में लोकप्रिय web apps के foreign ownership पर रोक लगाने की चर्चा चल रही हो, तब ऐसी कानून से फायदा उठाने वाली सरकारों या कंपनियों के लिए यह कितना सुविधाजनक होगा अगर Chinese नाम वाला कोई GitHub user, PRC से आया हुआ लगने वाले timestamps के साथ attack vector commit करे
भले ही वह सचमुच mainland China का कोई व्यक्ति हो, अगर उसे state support मिला है तो indictment और extradition request आने पर भी उसे US Marshals के हवाले किए जाने की संभावना बहुत कम है। उल्टा, बड़ी organization की जानकारी दुश्मन तक न जाए, इसलिए उसका “मुंह बंद” भी कराया जा सकता है
Bond film जैसी साजिशों को छोड़ दें तो उस knowledge को practical तौर पर लागू करने की जगह ज्यादा नहीं है। users कहां से आते हैं, यह आमतौर पर पहले से पता होता है, और geo-blocking भी की जा सकती है। नहीं तो उस region से आने वाले दूसरे threats के लिए तैयार रहना चाहिए
GMT+8, नाम की बनावट (Chinese/mixed dialect शैली का नाम + Hokkien surname), और Singapore के VPN exit या hosting server जैसे दिखने वाली जगह से access करने के संकेत[1], चाहे वास्तविक हों या disguise, Singaporean identity से पूरी तरह मेल खाते हैं
इसलिए [1] के source ने “नाम नकली जैसा लगता है” कहा, तो उसे कुछ हद तक सावधानी से लेना चाहिए। Mainland China के लोग diaspora Chinese communities को हमेशा अच्छी तरह नहीं जानते
बताए गए holidays में से काफी Singapore public holidays[2] नहीं हैं। 24 January public holiday था, लेकिन “working days पर काम करता है” वाला pattern लगाने के लिए 22 January Sunday था, फिर भी उसे काम किया हुआ दिखाया गया है
Jia Tan की posts, खासकर पुरानी posts, ज्यादा देखना रोचक होगा। Singaporean, mainland Chinese, अलग-अलग Slavic-language speakers और native English speakers को अलग करने के लिए काफी स्पष्ट linguistic habits हो सकती हैं
[1] https://boehs.org/node/everything-i-know-about-the-xz-backdo...
[2] https://www.mom.gov.sg/employment-practices/public-holidays
बेशक sample बहुत छोटा है, इसलिए इससे बहुत ज्यादा निष्कर्ष नहीं निकाला जा सकता
Singaporeans में लगभग 10% का surname Tan है
[1] [https://en.wikipedia.org/wiki/File:Singaporean_surnames_by_f...](https://en.wikipedia.org/wiki/File:Singaporean_surnames_by_frequency.png)
मुद्दे की गंभीरता को थोड़ी देर के लिए अलग रख दें, तो मैं इस घटना के डिटेक्टिव नॉवेल जैसे पहलू में पूरी तरह डूब गया हूँ
इंटरनेट जिस तरह “किसने, कैसे, क्यों” का पता लगा रहा है, वह दिलचस्प है
कुछ साल पहले से मैंने ठीक इसी वजह से टर्मिनल में
gcकोTZ=UTC0 git commitपर मैप कर रखा हैसिस्टम टाइम या git सेटिंग बदलने की जरूरत नहीं पड़ती। ग्लोबल सेटिंग में कोई बेहतर तरीका भी हो सकता है, लेकिन
वजह कोई दुर्भावनापूर्ण नहीं है। मैं बहुत यात्रा करता हूँ, और पब्लिक रिपॉजिटरी में अपना ट्रैवल शेड्यूल लीक नहीं करना चाहता
यह सिर्फ टाइमज़ोन को UTC पर सेट नहीं करता, बल्कि समय को 00:00 भी कर देता है, ताकि commit में सिर्फ तारीख की जानकारी बचे। मुझे लगता है कि git commit में स्थायी रूप से सेव होने वाली जानकारी के लिए तारीख काफी है, और सटीक commit time लीक करने की जरूरत नहीं
alias git='TZ=UTC0 git'इसमें manual step चाहिए, और मैं location services भी इस्तेमाल नहीं करता
Jia बेचारा। 2 साल की सारी मेहनत बेकार हो गई
Jia, अगर तुम यह पढ़ रहे हो, तो याद रखना कि जो shot लिया ही नहीं जाता, वह 100% miss होता है। सिर ऊँचा रखो, भाई
“सुबह-सुबह नियमित रूप से कौन काम करता है?”
मैं
“अगर hacker है, तो दोपहर और देर रात काम करना कहीं ज्यादा plausible है”
यहाँ hacker को young person से बदल दें तो शायद ज्यादा सही लगेगा
मैं 41 साल का हूँ और पिछले 10 सालों में शायद मुश्किल से 20 दिन ही ऐसे रहे होंगे जब मैं सुबह 7 बजे से पहले जागा हूँ। मैं अभी भी computer work इसलिए आधा झेल पाता हूँ क्योंकि यह उन गिने-चुने पेशों में है जिनमें ज्यादातर दिनों सुबह 11 बजे–शाम 7 बजे के schedule पर काम करते हुए भी अच्छा किया जा सकता है
morning people और night people होते हैं। हर किसी की अपनी rhythm होती है और उस पर judgment नहीं करना चाहिए, लेकिन उम्र बढ़ने के साथ यह अपने-आप बदलती है या बदलनी चाहिए, ऐसा नहीं है
c/hacker/younger personयह syntax क्या है?sedsubstitution काs/a/b/तो जानता हूँ, लेकिनcसे शुरू होने वाला नहीं जानतासुबह में “morning people” से निपटने जैसी interruptions ज्यादा होती हैं, और दोपहर के बाद से शाम तक interruptions काफी कम हो जाती हैं
random calls और emails से भरे 8-hour workday की तुलना में बिना interruption के 4 घंटे में कहीं ज्यादा काम हो सकता है। मैं अब young person भी नहीं हूँ, लेकिन अगर interruptions न हों और कुछ घंटों तक बीच-बीच में सोच रखा हो, तो आधे समय में काम खत्म हो जाता है, इसलिए कुछ काम रात में भी करता हूँ
अगर आपकी सुबहें शांतिपूर्ण होती हैं, तो ईर्ष्या होती है
“मंगलवार, 27 जून 2023 को 23:38:32 +0800 और 17:27:09 +0300 के दो commits दिखते हैं। हिसाब लगाने पर दोनों commits के बीच करीब 9 घंटे का फर्क है”
लेकिन 17:27:09 +0300 तो 22:27:09 +0800 है, इसलिए दोनों commits में करीब 1 घंटे का फर्क नहीं है?
“और निर्णायक रूप से, 6 अक्टूबर 2022 को 21:53:09 +0300 commit के बाद 17:00:38 +0800 commit दिखता है। यह सिर्फ कुछ मिनटों का फर्क है!”
नहीं। यह लगभग 10 घंटे का फर्क है
लगता है लेखक ने दोनों analyses गलती से उलट दिए, या उन्हें timezone calculation ठीक से नहीं आती
अगर कोई American, या पूरी तरह किसी और region का व्यक्ति, Chinese होने का ढोंग करने वाले Eastern European होने का ढोंग कर रहा हो तो?
अगर कोई चीज़ छिपानी हो, तो कम से कम एक और layer of indirection तो डाली ही होगी
ऐसी setup में इस तरह की leaks से कोई खास फर्क नहीं पड़ेगा
मैं original authors में से एक हूँ। आगे की analysis के लिए बहुत-से अच्छे ideas मिले, और बार-बार आए चार objections का जवाब यह है
मैं मानता हूँ कि यह साफ नहीं है कि एक व्यक्ति था या कई। लेकिन अगर team भी थी, तो timezone approach बता सकता है कि वह team कहाँ थी। activity times दुनिया भर में फैली team की तुलना में regular working hours जैसे बहुत ज्यादा दिखते हैं
commit times बदले गए हों, या scheduling script से commits/uploads हुए हों, यह possibility当然 है। फिर भी असल में बड़े timezone difference को छिपाने के लिए बहुत ज्यादा delay डालना पड़ेगा, इसलिए मुझे यह practical रूप से मुश्किल लगता है। क्योंकि xz vacuum में develop नहीं हुआ था; वह issue filings या mailing list posts जैसी online events पर react करते हुए develop हुआ था
दोनों examples सच में उलट-पुलट लिख दिए गए थे। जिन दो times को करीब 10 घंटे अलग बताया था, वे असल में कुछ मिनटों के फर्क वाले हैं, और जिन times को कुछ मिनटों का फर्क बताया था, वे करीब 10 घंटे अलग हैं। update किया जाएगा
आखिर में, यह भी सही है कि UTC+2/3 सिर्फ Eastern Europe ही नहीं, बल्कि Middle East के कुछ हिस्सों को भी शामिल करता है। इस हिस्से को भी article update में स्पष्ट कर दिया गया है