GitHub पर मिले 1 लाख से ज़्यादा संक्रमित repositories

 (apiiro.com)
1 पॉइंट द्वारा GN⁺ 2024-03-01 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • 2023 के मध्य में शुरू हुआ repository confusion (repo confusion) campaign फिर से फैल रहा है, और GitHub पर समान malicious payload वाले 1 लाख से ज़्यादा repositories detect किए गए हैं
  • attackers legitimate repositories जैसे दिखने वाले malicious clones बनाकर developers को भ्रमित करते हैं, और cloning, loader insertion, re-upload, mass forking, और गुप्त promotion को मिलाते हैं
  • malicious repository चलाने पर 7-stage obfuscation के बाद Python code और binaries डाउनलोड होते हैं, और login जानकारी, browser passwords, cookies जैसे संवेदनशील data चोरी होते हैं
  • भले ही GitHub अधिकतर forks को automatically delete कर दे, detection से बच निकले repositories और manually uploaded copies बची रहती हैं; कुल का सिर्फ 1% भी जीवित रहे तो हजारों malicious repositories बने रहते हैं
  • attack flow PyPI malicious packages से GitHub repositories की ओर शिफ्ट हो रहा है, जिससे package managers के बाहर की software supply chain भी सीधा attack surface बन गई है

Repository confusion attack का तरीका

  • Repository confusion dependency confusion से मिलता-जुलता है, क्योंकि इसमें user को legitimate repository के बजाय malicious repository डाउनलोड करने के लिए प्रेरित किया जाता है
  • फर्क exploitation point में है
    • dependency confusion package manager के behavior का इस्तेमाल करता है
    • repository confusion इस बात पर निर्भर करता है कि इंसान मिलते-जुलते दिखने वाले repository को गलती से चुन ले
  • इस campaign में infection की संभावना बढ़ाने के लिए GitHub पर बड़े पैमाने पर malicious repositories फैलाए गए
    • TwitterFollowBot, WhatsappBOT, discord-boost-tool, Twitch-Follow-Bot जैसे मौजूदा repositories को clone किया गया
    • clones में malware loader insert किया गया
    • उसी नाम से GitHub पर फिर से upload किया गया
    • हर repository को automatically हजारों बार fork किया गया
    • forums और Discord आदि पर stealthily promote किया गया

Malicious repository चलाने के बाद flow

  • user जब malicious repository इस्तेमाल करता है, तो छिपा payload 7-stage obfuscation हटाता है
  • इसके बाद malicious Python code और binary executables fetch किए जाते हैं
  • malicious code मुख्य रूप से BlackCap-Grabber के modified version पर आधारित है
  • collection targets में कई apps के login credentials, browser passwords और cookies, और अन्य confidential data शामिल हैं
  • चुराया गया data attacker के C&C(command-and-control) server पर भेजा जाता है, और आगे की malicious activity होती है
  • संबंधित code analysis Trend Micro की technical analysis में देखी जा सकती है

GitHub auto-delete और बचे हुए repositories

  • GitHub automation को identify करके forked repositories के अधिकतर हिस्से को तेजी से remove कर देता है
  • हालांकि automation detection कई repositories को miss कर देता है, और manually uploaded repositories बचे रहते हैं
  • attack chain बड़े पैमाने पर automated है, इसलिए सिर्फ 1% भी बचा रहे तो हजारों malicious repositories हो जाते हैं
  • GitHub पर 🔥 2024 language:python search करने पर वर्तमान में फैल रहे कुछ repositories देखे जा सकते हैं
  • deleted repositories को शामिल करें तो कुल scale लाखों से भी ऊपर पहुंच जाता है
    • deletion आमतौर पर upload के कुछ घंटों बाद होता है, इसलिए documentation मुश्किल है
    • कई original repositories बने रहते हैं, और deletion मुख्य रूप से fork bomb को target करता है
    • उदाहरण के लिए Mattia69 repository list के summary में हजारों forks दिखते हैं, लेकिन fork details में वे नहीं दिखते
  • कुछ users अनजाने में malicious repositories fork कर देते हैं, जिससे secondary social-engineering network effect भी बनता है

Campaign timeline

  • May 2023: Phylum ने PyPI पर upload किए गए malicious packages की report की
    • इन packages में current payload का शुरुआती हिस्सा शामिल था
    • ये chatgpt-api जैसे popular GitHub repositories के forks में planted os.system("pip install package") calls के जरिए फैले
  • July–August 2023: कई malicious repositories GitHub पर upload हुए, और PyPI packages fetch करने के बजाय सीधे payload deliver करने लगे
    • यह PyPI द्वारा malicious packages हटाने और security community की बढ़ती attention के बाद आया बदलाव था
    • Trend Micro के Aliakbar Zahravi और Peter Girnus ने technical analysis प्रकाशित की
  • November 2023–present: similar malicious payload वाले 1 लाख से ज़्यादा repositories detect हुए हैं, और संख्या लगातार बढ़ रही है
  • यह तरीका attackers के लिए क्यों favorable है, यह साफ है
    • GitHub का scale बड़ा है, इसलिए mass instances भी relatively छोटे दिखते हैं और detect करना मुश्किल होता है
    • पहले के विपरीत, package manager शामिल नहीं है, इसलिए explicit malicious package name indicator के रूप में नहीं बचता
    • target repositories छोटे niche areas में हैं और popularity कम है, इसलिए developers malicious impersonation repository को गलती से clone कर सकते हैं

Package manager से SCM की ओर शिफ्ट

  • PyPI malicious packages से GitHub malicious repositories की ओर movement कई package managers और SCM platforms में देखे गए trend से जुड़ा है
  • security community ने package managers पर ज्यादा focus किया, तो attack path दूसरी जगह shift हो गया
  • GitHub और similar platforms पर accounts और repositories automatically create करना आसान है, और ये convenient APIs और bypass करने में आसान loose rate limits देते हैं
  • countless repositories के बीच छिपा जा सकता है, इसलिए SCM software supply chain को stealthily infect करने के लिए अच्छा target बन जाता है
  • dependency confusion campaigns, package registries में malicious code, और SCM के जरिए malicious code का फैलना दिखाता है कि tools और security mechanisms बहुत होने के बावजूद software supply chain security कमजोर है

Infection check indicators

  • Python code में नीचे दिए patterns search करें और matches की जांच करें
    • exec(Fernet
    • exec(requests
    • exec(__import
    • exec(bytes
    • exec("""\nimport
    • exec(compile
    • __import__("builtins").exec(
  • local machine पर social platform automation, bots, game-related repositories हैं या नहीं, यह check करें और उन्हें remove करें
  • अगर इन्हें इस्तेमाल करना ज़रूरी हो, तो फिर से install करें, लेकिन source को सावधानी से verify करें या sandbox में run करें
  • अगर ऐसे repository को clone करने की संभावना है, तो नीचे दिए cookies, credentials, keys को compromised मानकर response करना चाहिए
    • Browser: financial services, email services, cryptocurrency services, Amazon, eBay, AliExpress, Facebook, Instagram, Twitter, Youtube, Discord, TikTok, Telegram, Twitch, Steam, Yahoo, ExpressVPN, Spotify, streaming services
    • Apps: Exodus, Atomic Wallet, Guarda, Coinomi, Ethereum
  • file checksums की पूरी list practical रूप से संभालना मुश्किल है, लेकिन कुछ common items VirusTotal graph में देखे जा सकते हैं
  • Cloudflare ने notification मिलने के बाद मिले हुए malicious addresses के DNS records disable कर दिए

Defense और response

  • GitHub को notify किया गया और उसने अधिकतर malicious repositories delete कर दिए, लेकिन campaign अभी भी जारी है
  • supply chain में malicious code inject करने वाले attacks तेजी से ज्यादा व्यापक हो रहे हैं
  • system और network level पर malware पकड़ने वाले solutions बहुत हैं, लेकिन supply chain attackers के लिए अब भी बड़ा और profitable attack surface है
  • malicious repository मिलने पर, वह इस campaign का हिस्सा हो या नहीं, GitHub के abuse or spam report के जरिए report किया जा सकता है
  • Apiiro ने connected codebases को monitor करने वाला malicious code detection system बनाया है
    • LLM-based code analysis
    • code decomposition into full execution flow graph
    • heuristic engine
    • dynamic decoding, decryption, de-obfuscation
  • injected malicious payloads को monitor नहीं किया गया, तो organization security developers की इस ability पर निर्भर हो जाएगी कि वे लगभग identical गलत repository न चुनें, CI/CD misconfiguration बिल्कुल न हो, और third-party code 100% safe हो
  • सामान्य vulnerability detection और collection से आगे बढ़कर, software supply chain और application risk की अगली generation को उजागर करने वाला approach जरूरी है

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

1 टिप्पणियां

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

  • पब्लिक repositories या external sources से लाए गए code के साथ सावधानी बरतने और dependency tree verification करने वाली सामान्य चेतावनी से आगे बढ़कर, अगर पब्लिक repositories में बड़े पैमाने पर malicious code मौजूद है, तो उस content पर train हुए LLMs और automation tools पर उसका क्या असर होगा, यह सोचने वाली बात है
    Copilot जैसे tools जब लंबे code responses बनाते हैं, तो ऐसा भी लग सकता है कि malicious हिस्से गलती से उनमें मिल जाएँ
    साधारण injection vulnerabilities जैसी चीज़ें तो पहले से ही अक्सर देखी जाती हैं

    • LLM output में backdoor गलती से आ जाने से ज़्यादा चिंता इस बात की है कि intelligence agencies जानबूझकर LLM output में backdoor डालें
      अभी शायद ऐसा न हो, लेकिन कुछ ही सालों में यह पूरी तरह संभव लग रहा है
    • LLM सिर्फ input data में मौजूद vulnerable code को copy-paste नहीं करेंगे, बल्कि लगता है कि वे खुद नई vulnerabilities भी बना सकते हैं
      AI accuracy को लेकर कोई guarantee नहीं देता
    • मैंने अभी Hugging Face के safetensors conversion bot के compromise से जुड़ा एक LLM मुद्दा पोस्ट किया है: https://news.ycombinator.com/item?id=39549482
      इसमें दिखाया गया कि attacker, Hugging Face Safetensors conversion space से जुड़े service bot पर नियंत्रण कर सकता है, और यह ecosystem में unsafe machine learning models को अधिक सुरक्षित versions में बदलने वाली एक लोकप्रिय service है
    • जोखिम असली है, लेकिन यह कुछ वैसा ही है जैसे किसी सहकर्मी के PR को review के बिना स्वीकार कर लेने पर कहीं से copy किया गया vulnerable code अंदर आ जाना
      LLM इस्तेमाल करने हैं तो code review में ज़्यादा मेहनत लगानी होगी, और मुझे लगता है कि यह trade-off ठीक है
    • इस campaign में detect किए गए samples की संख्या इतनी ज़्यादा है कि यह सोचे से अधिक वास्तविक जोखिम है
      लेकिन इसे किसी वास्तविक incident तक पहुँचने के लिए मुख्यतः दो barriers पार करने होते हैं: generator को ऐसे code से बचने के लिए internal instructions मिलते हैं, और LLM की प्रकृति के कारण उसके लिए attacker का असली address ज्यों का त्यों दोहराना आसान नहीं होता
      फिर भी bind shell, denial of service, और on-site exfiltration जैसे कई attack vectors अब भी बने रहते हैं

  • GitHub लगभग उसी तरह fail हो रहा है जैसे Usenet हुआ था
    कोई भी repository बना सकता है, और official repositories तथा spam repositories के बीच फर्क बताने का कोई स्पष्ट तरीका नहीं है
    जैसे Amazon ने “everything store” बनने का लक्ष्य रखा और अंत में “हर चीज़ का 90% कचरा” वाली स्थिति में पहुँचकर एक ज़्यादातर कचरे की दुकान बन गया, वैसे ही GitHub को तय करना होगा कि उसका product “सबके लिए repository” है या “विश्वसनीय code”
    उदाहरण के लिए official PG JDBC में भी ऐसा कुछ नहीं दिखता जिसे spammer दोहरा न सके, तो फिर यह कैसे भरोसा किया जाए कि यह infected repository नहीं है: https://github.com/pgjdbc

    • लगता है GitHub ने 16 साल पहले कंपनी शुरू करते समय ही सबके लिए repository वाला रास्ता चुन लिया था
    • Java library के मामले में आम तौर पर GitHub से नहीं, बल्कि Maven Central से download किया जाता है
      Sonatype, groupId में इस्तेमाल हुए reverse domain की ownership proof माँगता है, और इस मामले में वह org.postgresql है
      तरीका यहाँ दिया है: https://central.sonatype.org/faq/how-to-set-txt-record/
      और अधिक भरोसे के लिए आप GPG signatures भी verify कर सकते हैं, क्योंकि Maven Central पर publish होने वाले सभी artifacts signed होते हैं, लेकिन कमी यह है कि Postgres signing में जो key इस्तेमाल करता है, उसे Sonatype से स्वतंत्र किसी रास्ते से हासिल करना होगा
      PG के मामले में, जल्दी खोजने पर भी मुझे वह key नहीं मिली
    • शायद लोगों को ठीक से अंदाज़ा नहीं है कि यह संख्या कितनी छोटी है
      GitHub पर करीब 50 करोड़ repositories हैं, इसलिए यह स्तर वास्तव में काफ़ी अच्छा माना जा सकता है
    • 1 लाख से ज़्यादा infected repositories अच्छी बात नहीं हैं, लेकिन इसका यह मतलब नहीं कि GitHub fail हो गया
      जो developer ऐसी infected repositories उठा कर इस्तेमाल करेगा, वह GitHub पर वे न भी हों तो unsafe products बनाने के और भी बहुत तरीके ढूँढ़ लेगा
    • अगर आप domain ownership साबित करें, तो organization page पर verification badge मिल सकता है, जिससे भरोसेमंदी काफ़ी बढ़ सकती है
      दिए गए उदाहरण वाला organization शायद बस यह प्रक्रिया पूरी नहीं कर पाया

  • सप्लाई चेन की समस्या वाकई सिरदर्द है
    यह सीधे npm रिलीज़ को target नहीं करता, लेकिन BrowserBox नाम के हल्के virtualized web browser प्रोजेक्ट को monitor करने के लिए मैं npm रिलीज़ बनाकर socket.dev का उपयोग कर रहा हूँ
    इस प्रोजेक्ट में भी पूरे transitive dependencies सहित लगभग 800 dependencies हैं, हालांकि top-level dependencies सिर्फ 19 हैं, इसलिए पूरे stack के हिसाब से यह अपेक्षाकृत हल्का माना जाएगा
    अब सोच रहा हूँ कि इन 800 dependencies का snapshot npm के @browserbox namespace में रख दूँ और जो vulnerabilities मिलें उन्हें track करके patch करूँ
    यह पागलपन जैसा लगता है, लेकिन अभी हालात ऐसे ही हैं, और कम से कम ऐसा करने पर Node/JS पक्ष की सप्लाई चेन vulnerabilities के लिए कंपनी की security level के भीतर सीधे गारंटी दी जा सकती है
    https://socket.dev
    https://github.com/BrowserBox/BrowserBox

    • npm में इसी तरह की functionality कितनी है, यह नहीं पता, लेकिन crates.io और cargo में cargo audit और cargo deny जैसे tools हैं जो pipeline में dependency tree के CVE जाँचते हैं
      lock file पूरे tree का sha256 बनाए रखती है, इसलिए repository hack हो जाए तब भी बदलाव रोकने के लिए mirroring की ज़रूरत नहीं होती
      latest की बजाय कुछ महीनों पुराने version पर fix रहना एक ठीक संतुलन लगता है, जिससे नए CVE से बचा जा सके और साथ ही बहुत पुराने version में फँसकर एक साथ बड़े बदलाव करने की नौबत भी न आए
      download count, समान उद्देश्य वाले top-level dependency की तुलना में, एक ठीक-ठाक metric लगता है, हालांकि यह काफ़ी हद तक subjective है
      Austral linear types के ज़रिए dependencies को बारीक permissions देता है
      जैसे graphics library को file I/O की ज़रूरत नहीं होनी चाहिए, और network transport library को microphone access की ज़रूरत नहीं होनी चाहिए
      यह सिर्फ mitigation है, लेकिन इसे दूसरी भाषाओं में भी देखना चाहूँगा
    • “सिर्फ लगभग 800 dependencies” जैसा वाक्य थोड़ा सिहराने वाला है
      करीब 10 साल पहले .NET से Java पर आने के बाद मुझे हैरानी हुई कि dependency hell में जाने वाला समय बहुत बढ़ गया, और आजकल Java और Python दोनों projects में vulnerability updates और dependency issues पर बहुत डरावना समय खर्च होता है
      शायद .NET में यह समस्या कम इसलिए थी क्योंकि automatic package management अपेक्षाकृत देर से आया और NuGet भी नया था, इसलिए उस समय बहुत से projects ने इसे अभी अपनाया नहीं था और विशाल transitive dependency tree से बचने की संस्कृति अधिक मजबूत थी
      Boeing की हाल की समस्याएँ भी कुछ ऐसी ही लगती हैं
      पिछले कई दशकों में production को बाहरी suppliers को ज़्यादा सौंपने और cost optimization पर ज़ोर देने से supply chain management लगातार कठिन हुआ है, और बड़े परिप्रेक्ष्य में यह आधुनिक software engineering की supply chain culture से मिलता-जुलता है
      जब मैं एक ऐसी financial company में काम करता था जहाँ supply chain security की वजह से package managers पर रोक थी, तब dependency management सबसे कम झंझट वाला था और quality issues भी सबसे कम थे
      ऐसे code में फ़ायदा है जो जब तक आप उसे स्पष्ट रूप से न बदलें, तब तक कभी नहीं बदलता
      हम उन हिस्सों का भी बहुत कुछ खुद implement करते थे जिन्हें दूसरे लोग package से ले आते, लेकिन क्योंकि हम सिर्फ ज़रूरी चीज़ें करते थे और code standards ऊँचे रखते थे, इसलिए उसे समझना, debug करना और modify करना आसान था
      पहली बार लिखने की लागत एकबारगी होती है और अच्छी तरह amortize हो जाती है, लेकिन ऐसा code संभालने की recurring cost जो सबके लिए सब कुछ करने की कोशिश करता है, लंबी अवधि में अधिक बढ़ती है और आमतौर पर जमा होती रहती है
      Rich Hickey का “Simple Made Easy” इस phenomenon को अच्छी तरह दिखाता है; simple और easy अलग-अलग चीज़ें हैं, और simple विकल्प शुरुआत में भले अधिक कठिन लगे, लेकिन दूसरे क्रम के प्रभाव जमा होने पर लंबी अवधि में वही अधिक आसान बनता है

  • इसी तरह के repositories को यूँ ही देखते हुए मुझे यह बात पहले ही समझ आ गई थी
    मैं पहले भी किसी भी repository का code यूँ ही run नहीं करता था, लेकिन अब repository और owner पर भरोसा होने पर भी sandbox VM चलाता हूँ
    आज के developer को लगता है कि काम, शौक और निजी उपयोग के लिए कम से कम तीन environment साफ़ तौर पर अलग रखने चाहिए

    • यह बात कि developer को काम, शौक और निजी environment अलग रखने चाहिए, खुद इस बात का संकेत है कि digital life की complexity इतनी बढ़ चुकी है कि उसकी long-term sustainability पर शक होने लगे
    • हर साल Qubes ज़्यादा समझदारी भरा विकल्प लगता है
    • मैं भी अब सिर्फ संभावित malware की वजह से ऐसा नहीं करता
      कुछ projects malicious नहीं होते, फिर भी design के स्तर पर ढीले या मूर्खतापूर्ण ढंग से लिखे होते हैं
      मैंने हाल ही में जो एक program चलाया, उसने बिना मेरे कुछ माँगे ~/.bashrc में 3 lines जोड़ दीं, और मुझे यह कई दिन बाद पता चला
      मैं समझ नहीं पाता कि कौन developer इसे अच्छा विचार मानता है, और इसलिए अब हर बार बाहरी code चलाते समय sandbox का उपयोग करता हूँ
    • यह Qubes OS इस्तेमाल करने की बहुत अच्छी वजह लगती है, जहाँ हर चीज़ default रूप से VM में चलती है
      यही मेरा रोज़मर्रा का OS है
    • काम और निजी environment को न मिलाना क्या बुनियादी बातों में सबसे बुनियादी नहीं है?
      क्या सच में ऐसे employers हैं जो इसे अनुमति देते हैं?

  • यह जानना चाहता हूँ कि कार्यस्थल पर ऐसी समस्याओं से बचने के लिए लोग कौन-से टूल इस्तेमाल करते हैं, और क्या वे अपनी मौजूदा सेटअप से संतुष्ट हैं
    हम एक काफ़ी छोटी टीम हैं और बहुत अधिक साप्ताहिक डाउनलोड वाला SDK विकसित कर रहे हैं। हमने snyk, aikido.dev, renovate-आधारित solutions आदि का मूल्यांकन किया है, लेकिन यह स्पष्ट नहीं है कि वे इस तरह की समस्या में मदद करते हैं या नहीं
    टीम अभी छोटी है, इसलिए snyk जैसे false positives अधिक देने वाले टूल को संभालना भी बोझ है

    • GitHub repository को सीधे इस्तेमाल करने के बजाय, हम NuGet, PyPI, npm जैसे सामान्य package repositories के public packages इस्तेमाल करते हैं, और Sonatype के Repository तथा Firewall को हमारे और package repository के बीच proxy के रूप में रखते हैं
      Sonatype सभी packages का analysis करता है, उन पर अलग-अलग metadata जोड़ता है, और Firewall में इस्तेमाल होने वाली policies परिभाषित करके बाकी को फ़िल्टर कर देता है
      यह केवल public dependencies पर लागू होता है, लेकिन कुछ साल इस्तेमाल करने के बाद यह काफ़ी अच्छी तरह काम करता दिखा है
      अब तक malware की समस्या नहीं हुई है, known vulnerabilities वाले packages codebase में आ ही नहीं पाते, और जो इस्तेमाल में हैं उनमें vulnerability मिले तो alert मिल जाता है
    • हम कार्यस्थल पर Semgrep Supply Chain इस्तेमाल करते हैं और काफ़ी संतुष्ट हैं
      यह मिली हुई supply chain vulnerabilities को reachable, unreachable, और undetermined में बाँट देता है, जिससे triage बहुत आसान हो गया है और नई vulnerabilities का आकलन करने में लगने वाला समय काफ़ी घट गया है
    • लगता है इस subthread में malware और vulnerabilities को बहुत लोग गड़बड़ा रहे हैं
      जिन vendors का ज़िक्र हुआ है, वे malware नहीं बल्कि सिर्फ़ vulnerabilities detect करते हैं
      भले ही vulnerability detection अच्छा हो, codebase में डाले गए malware से आप फिर भी सुरक्षित नहीं होते
    • मैं एक open source tool Packj बना रहा हूँ, जो public malicious packages, abandoned packages, typosquatting packages आदि जैसे ख़तरनाक PyPI/NPM/Ruby/PHP/Maven/Rust packages को detect करता है
      यह static, dynamic, और metadata analysis करता है, और shell execution, SSH key usage, network communication, decode+eval के इस्तेमाल जैसी 40 से अधिक विशेषताओं की जाँच करके risky packages को चिह्नित करता है
      https://github.com/ossillate-inc/packj
    • Trivy को देखना चाहिए
      अभी तक इसने काफ़ी अच्छा काम किया है
      https://trivy.dev/

  • यह सोच रहा हूँ कि क्या curl से shell install script लेकर उसे sudo के साथ चलाने की प्रथा जल्द ख़त्म होगी
    “हमारा software install करने के लिए curl [https://somesite/install.sh](<https://somesite/install.sh>;)' | sudo sh चलाइए” जैसी विधि लेख में बताए गए संक्रमित code के साथ बहुत अच्छी तरह मेल खाती है

    • इस research के लेखक के रूप में मैं इसकी पुष्टि कर सकता हूँ
      हमारा system हर हफ़्ते बताए गए pattern के लगभग 100 मामलों की सूची बनाता है, और उनमें से लगभग 3% malicious होते हैं
      मैं सच में चाहता हूँ कि यह प्रथा बंद हो
    • दुर्भाग्य से npm i के पास भी वही अधिकार होते हैं
      अभी के आम dependency download tools में, install या build के समय hostile code execute न होने वाला मुझे सिर्फ़ go get ही पता है
      कम-से-कम blast radius को सीमित करने के लिए sandbox में काम करने के बेहतर tools की ज़रूरत है
      ChromeOS का “virtual machine मुख्य desktop पर Wayland window खोल सकती है” वाला तरीका साफ़-सुथरा है, लेकिन जब मैंने आख़िरी बार देखा था, तब वह code इतना साफ़ या reusable नहीं था
    • ऐसे उदाहरणों में example.com का इस्तेमाल करना बेहतर है
      यह उसी उद्देश्य के लिए आरक्षित domain है: https://www.rfc-editor.org/rfc/rfc2606.html#section-3
    • यह व्यावहारिक विकल्पों जैसे “अपनी distribution के लिए repository जोड़ें और उस पर trust करें”, “.deb/.rpm/installer` डाउनलोड करें”, या सबसे बुरे रूप में “publisher नहीं बल्कि किसी third party द्वारा पैकेज की गई चीज़ पर trust करें” से ख़ास बुरा नहीं है

  • npm में --ignore-scripts के साथ malware execution को कम किया जा सकता है
    https://blog.uirig.com/getting-rid-of-npm-scripts

    • लेकिन तब डाउनलोड किया गया malicious code runtime environment में चल सकता है
      अगर किस्मत अच्छी हो, तो CI में अजीब व्यवहार करेगा और पकड़ा जा सकता है
      असली समाधान https://github.com/crev-dev/cargo-crev जैसे reputation system हैं, लेकिन अफ़सोस कि उनका इस्तेमाल लगभग नहीं के बराबर है
    • सुरक्षा के नज़रिए से यह default होना चाहिए
      Makefile की आवश्यकता वाले comment पर भी ध्यान देना चाहिए

  • ऐसी रिपोर्टें लगातार आती रहने के कारण, पिछले कुछ महीनों में मैं अपने development environment की security को धीरे-धीरे बेहतर कर रहा हूँ
    development के लिए VSCode dev containers इस्तेमाल कर रहा हूँ: https://code.visualstudio.com/docs/devcontainers/create-dev-...
    एक बार इसे बना लेने के बाद, Docker का बहुत ज़्यादा ज्ञान न हो तब भी इसे इस्तेमाल करना आसान है, और web/console app चलाने के लिए अच्छा है, लेकिन Flutter या Electron जैसी चीज़ों के लिए यह मुश्किल था
    छोटे projects के लिए GitHub Codespaces का भी अब काफ़ी अभ्यस्त हो गया हूँ: https://github.com/codespaces
    पहले एक interview में मैंने simple Node project को modify करने वाली live coding की थी, लेकिन आजकल अगर ऐसी स्थिति हो तो मैं container या Codespaces ज़रूर इस्तेमाल करूँगा: https://www.welivesecurity.com/en/eset-research/lazarus-luri...
    npm, Node, Docker की best practices के लिए मैं नियमित रूप से OWASP guidelines पढ़ता हूँ, और Docker में जहाँ तक संभव हो छोटे images और explicit image tags इस्तेमाल करने जैसी बातें लागू करता हूँ: https://cheatsheetseries.owasp.org/cheatsheets/NodeJS_Docker...
    npm/python packages को install करने से पहले socket.dev पर environment variable access, network calls, supply chain attacks, हालिया code ownership changes आदि देखता हूँ, और OWASP की सिफारिश के मुताबिक postinstall scripts को globally disable भी किया जा सकता है: https://cheatsheetseries.owasp.org/cheatsheets/NPM_Security_...

  • एक साल से भी कम पुराना एक मामला था, जिसमें Trojan horse वायरस वाला repository था: https://github.com/orgs/community/discussions/63603

    • repository ने दावा किया था कि वह password stealer है, और अगर आपने उसे download करके unzip किया और उसने personal data और files चुरा लीं, तो समझ नहीं आता कि समस्या क्या है
      उसने वही किया, जो repository ने दावा किया था

  • सिर्फ़ यह दिखा देना कि कोई repository official है, अपने-आप में कुछ हद तक ध्यान खींच सकता है

    • बाद में GitHub शायद उस blue check को बेचना भी शुरू कर दे
      भला इससे क्या गड़बड़ हो सकती है /s
      फिर भी, मैं इस बात से सहमत हूँ कि GitHub को यह बेहतर तरीके से दिखाना चाहिए कि कौन-सा repository किसी project का official repository है