Postmark backdoor ईमेल डाउनलोड कर रहा है

 (koi.security)
2 पॉइंट द्वारा GN⁺ 2025-09-28 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • हाल ही में postmark-mcp मॉड्यूल में दुर्भावनापूर्ण गतिविधि पाई गई
  • version 1.0.16 से ईमेल को डेवलपर के बाहरी सर्वर पर कॉपी करने वाला कोड जोड़ा गया
  • सैकड़ों संगठनों के संवेदनशील ईमेल लीक होने लायक एक संरचनात्मक कमजोरी सामने आई
  • MCP server में trust model की कमी के कारण supply chain attack का जोखिम बढ़ रहा है
  • सभी MCP उपयोगकर्ताओं को तुरंत जांच और removal कार्रवाई करने की आवश्यकता है

MCP server की वास्तविकता और postmark-mcp घटना का सार

  • MCP server ऐसे टूल हैं जो AI assistant को ईमेल भेजना, database query चलाना जैसी दोहराई जाने वाली प्रक्रियाएं अपने-आप संभालने देते हैं
  • ये टूल बहुत ऊंचे privilege के साथ चलते हैं, और डेवलपर-लिखित कोड को लगभग केवल भरोसे के आधार पर install किया जाता है; व्यावहारिक रूप से कोई verification system नहीं है
  • लोकप्रिय पैकेज postmark-mcp ने आधिकारिक Postmark GitHub repository से source code लिया, उसमें एक malicious BCC लाइन जोड़कर npm पर उसी नाम से publish किया
  • version 1.0.16 से सामान्य रूप से काम करने वाले कोड में एक लाइन जोड़ी गई, जिससे सभी ईमेल डेवलपर के निजी सर्वर (giftshop.club) पर कॉपी होने लगे
  • यानी password reset, invoice, internal memo, confidential documents तक सारी ईमेल जानकारी उजागर होने वाली यह एक गंभीर घटना है

असामान्य गतिविधि की पहचान और attack structure

  • Koi के Risk Engine ने version 1.0.16 में असामान्य संकेत पकड़े
  • डेवलपर की पहचान GitHub आदि पर सामान्य दिखती थी, और शुरुआती 15 versions बिना समस्या के चलकर भरोसा बना चुके थे
  • 1.0.16 में केवल एक लाइन के कोड से महत्वपूर्ण जानकारी को बाहर भेजने की क्षमता जोड़ दी गई
  • हमलावर ने कोड कॉपी करने के साथ-साथ मौजूदा डेवलपर की नकल करने की तकनीक (Classic impersonation) भी इस्तेमाल की
  • पहले से सामान्य रूप से इस्तेमाल हो रहा टूल एक समय पर trust-based infrastructure का हिस्सा बन गया और बाद में malicious behavior करने लगा

ईमेल लीक का प्रभाव और तरीका

  • लगभग हर हफ्ते 1,500 downloads और उनमें से करीब 20% सक्रिय उपयोग मानें तो सैकड़ों संगठन exposure के दायरे में आते हैं
  • अनुमान है कि हर दिन 3,000~15,000 ईमेल giftshop.club को भेजे जा रहे थे
  • उपयोगकर्ता टूल के behavior की अलग-अलग जांच नहीं करते और अधिकतर automatic execution AI assistant पर छोड़ देते हैं
  • कोई अलग security model, sandbox, या verification process नहीं है
  • डेवलपर ने npm से पैकेज हटा दिया, लेकिन जिन environments में यह पहले से installed है वहां removal का असर नहीं, इसलिए डेटा का लीक जारी रह सकता है

attack चरणों का विश्लेषण

  • चरण 1: सामान्य टूल का वितरण

    • 1.0.0~1.0.15 तक यह बिना समस्या के चलता रहा और भरोसा बनाता रहा

  • चरण 2: malicious code insertion

    • 1.0.16 में एक BCC लाइन जोड़ी गई, जिससे ईमेल बाहरी जगह कॉपी होने लगे

  • चरण 3: जानकारी संग्रह

    • giftshop.club पर password, API key, वित्तीय/ग्राहक डेटा आदि लीक हुए

  • डेवलपर से संपर्क नहीं हो सका, और npm से पैकेज हटाने के बावजूद पहले से installed environments में नुकसान जारी है

MCP ecosystem की संरचनात्मक खामियां

  • MCP server सामान्य npm packages से अलग हैं; ये उच्च-जोखिम वाले टूल हैं जिन्हें AI assistant अपने-आप सैकड़ों या हजारों बार call कर सकता है
  • कोड malicious है या नहीं, इसे AI या मौजूदा security solutions पहचान नहीं पा रहे और पूरा ढांचा भरोसे पर निर्भर है
  • पूरा MCP ecosystem एक जोखिमपूर्ण संरचना है जिसमें anonymous developers को high-risk assets पर पूरा अधिकार सौंप दिया जाता है
  • behavior change detection के जरिए attack पहचानना और supply chain gateway जैसे security controls जरूरी हैं
  • Koi अपने Risk Engine और gateway के जरिए ऐसे समान malicious packages की घुसपैठ रोकने और verification को आगे बढ़ा रहा है

response उपाय और IOC

  • malicious package: postmark-mcp (npm)
  • malicious versions: 1.0.16 और उससे ऊपर
  • लीक ईमेल: phan@giftshop[.]club
  • domain: giftshop[.]club

detection method

  • ईमेल logs में giftshop.club को BCC के रूप में भेजे जाने के निशान देखें
  • MCP server settings में अप्रत्याशित email forwarding parameters की जांच करें
  • postmark-mcp 1.0.16 या उससे ऊपर के version installation history की बारीकी से समीक्षा करें

response और recovery

  • postmark-mcp को तुरंत हटाएं
  • compromise अवधि के दौरान ईमेल से साझा किए गए सभी credentials rotate करें
  • चोरी हुई संवेदनशील जानकारी से जुड़े email logs की पूरी जांच करें
  • नुकसान की पुष्टि होने पर संबंधित प्राधिकरण को तुरंत रिपोर्ट करें

निष्कर्ष और सिफारिश

  • सभी MCP servers के लिए डेवलपर पहचान, code verification, और security review प्रक्रियाएं अनिवार्य रूप से लागू की जानी चाहिए
  • MCP (automation AI support infrastructure) की प्रकृति को देखते हुए कम-से-कम distrust model और लगातार monitoring आवश्यक है
  • postmark-mcp 1.0.16 या उससे ऊपर उपयोग करने वालों के लिए तुरंत removal और security action अनिवार्य हैं
  • यह याद रखना जरूरी है कि trust-based usage सीधे supply chain attack के जोखिम की ओर ले जा सकता है
  • MCP उपयोग के लिए Paranoia (अविश्वास/संदेह) को डिफ़ॉल्ट नीति मानना एक व्यावहारिक रणनीति है

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

1 टिप्पणियां

 
GN⁺ 2025-09-28
Hacker News टिप्पणियाँ
  • मुझे जिज्ञासा है कि Thunderbird extension वाले backdoor और इस घटना में क्या फर्क है। मैं पहले एक Thunderbird extension maintain करता था, और जब मेरी उसमें दिलचस्पी खत्म हो गई, तो किसी व्यक्ति ने कुछ असली contributions करने के बाद अचानक project takeover करने के लिए बहुत जोर देना शुरू कर दिया। आखिर मैंने सोचा कि किसी अनजान व्यक्ति को हज़ारों mailbox keys सौंप देना बिल्कुल बेतुका है, इसलिए मना कर दिया। वैसे यह भी मज़ेदार है कि लोगों ने शुरू में मुझ पर इतना भरोसा किया, लेकिन कम से कम मैं एक अच्छा इंसान हूँ
    • मैं भी बिल्कुल यही सोचता हूँ। यह MCP की वजह से नहीं है, बल्कि हर software पर समान रूप से लागू होने वाली समस्या है। अंत में आपको developers और providers पर भरोसा करना ही पड़ता है। मैं Microsoft को मेरे Outlook mails कॉपी करने से नहीं रोक सकता, और Google को Gmail कॉपी करने से नहीं रोक सकता। भले ही open source होने पर कहा जाए कि 'बहुत सारी निगाहें' code को review करती हैं, तो भी यह शायद लोकप्रिय projects पर ही लागू होगा, और तब भी जोखिम बना रहता है। आखिरकार ज़्यादातर लोग developers पर बस भरोसा ही करते हैं। यह समस्या software जितनी पुरानी एक पुरानी, जिद्दी समस्या है
    • तुम्हारी बात से Zuckerberg का privacy पर दिया गया एक बयान बार-बार याद आता है। हमें सोचना चाहिए कि हम आखिर क्यों बिना सोचे-समझे किसी व्यक्ति को अपना data और privacy सौंप देते हैं
    • मैंने कई बार नशे में धुत अनजान लोगों को अपनी car में बैठाकर घर छोड़ा है। मैं हमेशा उन्हें बताता हूँ कि किसी ऐसे अजनबी से ride लेना सच में ख़तरनाक है। सच कहूँ तो यह उनका सौभाग्य था कि संयोग से उन्हें मेरी तरह समय वाला भला इंसान मिल गया। मैं अक्सर मोहल्ले के छोटे bar में देर से जाता हूँ, शायद इसलिए ऐसा अक्सर हो जाता है
  • मैं इस धारणा से सहमत नहीं हूँ कि NPM का एक download मतलब एक unique organization है। यह संख्या सच में बढ़ा-चढ़ाकर पेश की गई है। npm में एक download का मतलब सिर्फ इतना है कि किसी ने (npm i command चलाकर) या किसी चीज़ ने (automation environment) install किया। असली काम में अगर CI ढीला-ढाला configured हो, तो हर run पर, नहीं तो हर step पर npm i चल जाता है। इसलिए 1,500 downloads भी शायद असल में सिर्फ 2 companies से आए हों। एक जगह कोई developer PoC के लिए इस्तेमाल कर रहा हो, और दूसरी जगह CI setup खराब हो। आधिकारिक repo भी देखें तो सिर्फ watch 1, fork 0, star 2 हैं https://github.com/ActiveCampaign/postmark-mcp. MCP और supply-chain समस्याएँ अपने आप में गंभीर हैं, लेकिन इस case में वास्तविक impact लगभग 0 है
    • इसी logic से देखें तो popular python package downloads भी जल्द ही इस स्तर पर पहुँच जाएँगे कि धरती पर हर इंसान—बच्चे, बुज़ुर्ग, और वे लोग जिन्हें computer क्या होता है यह भी नहीं पता—हर किसी ने एक-एक download किया होगा। https://pypistats.org/top
  • यह लेख अपने आप में अच्छा है, लेकिन समझ नहीं आता कि ChatGPT से summarize किया हुआ AI translation version क्यों पढ़ना चाहिए। काश उन्होंने बस original prompt ही दिखा दिया होता। अभी की तरह यह बेवजह धीमा लगता है और user को dismissive तरीके से treat करता है
    • अच्छा लगा कि तुम्हें भी ऐसा लगा। मुझे AI-हस्तक्षेप वाली writing style बहुत नापसंद है, लेकिन मेरे कुछ दोस्त या तो इसे बिल्कुल महसूस नहीं करते, या उन्हें फर्क नहीं पड़ता
  • आजकल यह बार-बार दिख रहा है, लेकिन मुझे लगता है कि हम इस पर पर्याप्त बात नहीं कर रहे कि हम ऐसे tools को लगभग ईश्वर जैसी powers दे रहे हैं। यह ऐसे tools हैं जिनके creators का चेहरा तक हम नहीं जानते, फिर भी हम इन्हें भरोसे से सौंप देते हैं। AI assistants भी ऐसे ही हैं। सब लोग बस 100% trust कर देते हैं। इस तरह की बात उठाने वाले लेख हैं, लेकिन उनका एहसास कुछ ऐसा होता है: "क्या आपको पता है कि अगर आप बंदूक की नली अपने पैर पर तानकर trigger दबाएँगे, तो पैर में गोली लग सकती है??" बात इतनी obvious है कि लगता है लेखों ने लगभग बिना substance की चीज़ से content बना लिया है। सोचता हूँ, क्या सच में इतने लोग यह नहीं समझते, या फिर बस लिखने के लिए ज़बरदस्ती बनाया गया है
    • कुछ समय पहले एक लेख आया था जिसमें AI code assistant ने कंपनी का production database उड़ा दिया था https://fortune.com/2025/07/23/ai-coding-tool-replit-wiped-database-called-it-a-catastrophic-failure/. इसमें कई परतें हैं: 1) उस founder ने AI tool पर पूरी तरह भरोसा किया और खुद उसका शिकार बना। यानी वह सच में अनजान था। 2) ऊपर से उसने production DB को development environment से सीधे access करने के लिए खुला छोड़ रखा था। वैसे भी वह ऐसा setup था जिसमें कभी न कभी हादसा होना ही था
    • HN users को जो बात obvious लगती है, दुनिया के ज़्यादातर लोगों के लिए वह बिल्कुल obvious नहीं होती। ऐसे लेख उन्हीं लोगों के लिए ज़रूरी content हैं। वास्तव में MCP servers और AI agents का design ऐसा है जिसमें security पर शुरुआत में चर्चा तक नहीं हुई, इसलिए वे मूल रूप से सुरक्षित नहीं हैं। आगे यह बदलेगा या नहीं, पता नहीं, लेकिन तब तक बार-बार लोगों को चेताते रहना ही सबसे अच्छा है
    • “क्या लोग सच में इतने असावधान हैं?” basic SQL injection भी हर साल भारी नुकसान कराता रहता है, और अब भी OWASP top में है। SQL injection भी आखिर database को लगभग ईश्वर जैसी powers दे देता है, और यह इसलिए होता है क्योंकि लोग उसके काम करने के तरीके को नहीं समझते। AI agents की action permissions भी user के नज़रिए से आसानी से दिखाई नहीं दे सकतीं
    • MCP के ज़रिए इस तरह की लापरवाह पहुँच बड़े पैमाने पर हो रही है, इस पर और व्यापक चर्चा होनी चाहिए। आम तौर पर सतर्क रहने वाले लोग भी कई बार जोखिम को ठीक से समझ नहीं पाते
    • पहले email clients का इंटरनेट पर किसी के भी भेजे गए embedded script वाले mail को चला देना “automation revolution” कहा जाता था। और पहले यह भी माना जाता था कि बच्चों को TV की जगह internet इस्तेमाल करने देना ज़्यादा healthy है, लेकिन हम सब जानते हैं कि उसका अंत कैसा हुआ, है न?
  • इसमें कहा गया है कि “random किसी व्यक्ति द्वारा बनाया गया tool install करना सामान्य हो गया है”, लेकिन सच यह है कि Windows XP के समय से ही हम CD ripping software या Bonzi Buddy जैसी चीज़ें बिना किसी चिंता के install करते आए हैं। convenience हमेशा security से ऊपर रही है। आखिर सबसे बड़ा सबक यही है कि अब तक ‘sandbox, sandbox, sandbox’ असलियत क्यों नहीं बन पाया। इस मामले में तो लगता है AI ने मौजूदा सभी security principles को पूरी तरह factory reset कर दिया है
    • “लोग convenience को security पर चुन लेते हैं। अब तक sandbox हक़ीक़त क्यों नहीं बन पाया?” इसका जवाब है कि sandbox implement करना आसान नहीं है। और यहाँ ‘आसान’ से मतलब है कि OS इसे default के रूप में उपलब्ध कराए
  • कोई user GMail में AI को prompt injection किया हुआ spam mail भेज सकता है, चाहे इंसान उसे खोले भी नहीं https://www.linkedin.com/posts/eito-miyamura-157305121_we-got-chatgpt-to-leak-your-private-email-activity-7372306174253256704-xoX1/
  • यह blog post पढ़ने में बहुत कठिन है। इसमें AI का हाथ लगा हुआ लगता है। बेवजह के वाक्य और सजावट बहुत ज़्यादा हैं। अफ़सोस की बात है कि विषय अपने आप में दिलचस्प है
  • supply-chain security मुद्दों में npm packages का ज़िक्र लगभग हमेशा आता है। शायद इसलिए कि npm सबसे व्यापक रूप से इस्तेमाल होता है और attackers के लिए incentive भी बड़ा है, लेकिन फिर भी इसमें एक कड़वाहट तो रहती ही है
    • OpenAI भी Codex CLI को npm के ज़रिए distribute करता है। वह Rust में बना है, फिर भी npm package इस्तेमाल करता है। व्यक्तिगत रूप से मुझे यह समझ से परे लगता है। लेकिन शायद alternatives और भी असुविधाजनक हैं
    • इसी वजह से मैं stdio MCP servers नहीं चलाता। मेरे सारे MCP एक VM host पर isolated Docker containers के भीतर, untrusted VLAN में चलते हैं। और मैं सिर्फ SSE के ज़रिए connect करता हूँ। हाँ, prompt injection के लिए यह अब भी vulnerable है, लेकिन मैं इसे अपने मुख्य browser profile, email, या cloud accounts से connect नहीं करता। इसे sensitive information से पूरी तरह अलग रखता हूँ
    • यह ठीक नहीं होगा अगर ऊपर वाली टिप्पणी को बहुत ज़्यादा upvotes मिल जाने से लोग इसे इस article का मुख्य takeaway समझ लें। अगर इसे उसी तरह लिया गया, तो बात का सार ही छूट जाएगा
  • संभव है कि developer ने सच में जानबूझकर ऐसा न किया हो। मैंने भी कभी-कभी debugging code के साथ release कर दिया है। अगर plain bcc था, तो यह सच में debugging code हो सकता है
    • मैं भी यही कहने आया था। ईमानदारी से कहूँ तो कोई अपने email को इस तरह इतना खुला छोड़कर नहीं जाएगा। 2025 में भी test के लिए personal Gmail इस्तेमाल करना शर्मनाक है। और यह सिर्फ MCP की समस्या नहीं है; किसी भी package में ऐसा हो सकता है
    • package delete कर देना भी सच कहूँ तो security issue से पहली बार जूझ रहे किसी नए developer की एक typical reaction लगती है। अगर यह दुर्भावना नहीं, बल्कि सिर्फ debugging की गलती थी, तो communication ही सबसे अहम है: malicious version हटाना, patch deploy करना, और blog/यहाँ HN/social media जैसे public channels पर संवाद करना ही भरोसा लौटाने का रास्ता है। घटना की सटीक timeline भी (और OP की तरह AI से लिखवाया गया summary नहीं) भरोसा बहाल करने में मदद करती है
  • MCP server की समस्या भी ख़तरनाक है, लेकिन मुझे लगता है कि इस तरह का हमला smtp package जैसी external dependencies इस्तेमाल होने वाली हर स्थिति में हो सकता है
    • फिर भी smtp package के मामले में आम तौर पर अच्छी तरह जाँची-परखी, लंबे समय से विश्वसनीय libraries इस्तेमाल की जाती हैं। MCP में सब कुछ नया है और trust का इतिहास जमा नहीं हुआ है, यही समस्या है। यह एक तरह का software frontier है जहाँ आपको छह-गोली वाली बंदूक (6-shooter) भरकर चलना पड़ता है