WhatsApp संदेशों और संपर्कों को इकट्ठा करने वाला Lotusbail npm पैकेज मिला

• Lotusbail पैकेज वैध WhatsApp Web API लाइब्रेरी Baileys का एक fork है, और यह 6 महीनों में npm पर 56 हज़ार से अधिक बार डाउनलोड किया गया malware-युक्त पैकेज है
• यह सामान्य रूप से काम करने वाली API सुविधाएँ देता है, लेकिन साथ ही WhatsApp authentication जानकारी, संदेश, संपर्क और media files चुराकर हमलावर के सर्वर पर भेजता है
• डेटा को RSA, AES, Base-91, LZString जैसी कई encryption और obfuscation परतों से गुज़ारकर भेजा जाता है, जिससे security monitoring से बचना संभव हो जाता है
• यह पैकेज hardcoded pairing code के ज़रिए हमलावर के डिवाइस को उपयोगकर्ता के WhatsApp खाते से स्थायी रूप से जोड़ने वाला backdoor इंस्टॉल करता है
• यह मामला supply chain attack के उन्नत रूप को दिखाता है और केवल static analysis से पता न चलने वाली behavior-based security monitoring की ज़रूरत पर ज़ोर देता है

---

Lotusbail पैकेज का अवलोकन

• lotusbail वैध @whiskeysockets/baileys का fork है और WhatsApp Web API की वही सुविधाएँ प्रदान करता है
  • संदेश भेजना और प्राप्त करना सामान्य रूप से काम करता है, इसलिए डेवलपर बिना शक के इसे इंस्टॉल कर सकते हैं
  • यह npm पर 6 महीनों से पंजीकृत है और लिखे जाने के समय तक अभी भी डाउनलोड के लिए उपलब्ध है
• लेकिन इसके वास्तविक व्यवहार के पीछे WhatsApp credentials की चोरी, संदेशों की interception, संपर्कों का संग्रह और backdoor इंस्टॉल करना जैसी malicious गतिविधियाँ छिपी हुई हैं

कौन-सी जानकारी चुराई जाती है

• इसमें authentication token और session key, पूरा message history, फोन नंबर सहित contact list, media files और documents, और स्थायी backdoor access शामिल हैं
• सारा डेटा हमलावर के सर्वर पर भेजे जाने से पहले encrypt किया जाता है

काम करने का तरीका

वास्तव में काम करने वाला छद्म फीचर

• ज़्यादातर malicious npm पैकेज खराब काम करते हैं या संदिग्ध code की वजह से आसानी से पहचाने जाते हैं, लेकिन Lotusbail सामान्य रूप से काम करने वाली API के रूप में छिपता है
• यह वैध Baileys लाइब्रेरी पर आधारित है और message send/receive functionality पूरी तरह लागू है
• इसी कारण डेवलपर “सही से काम करने वाले code” में malicious behavior पर शक नहीं करते, और यहाँ social engineering तकनीक का इस्तेमाल होता है

डेटा चोरी और ट्रांसमिशन

• यह पैकेज WhatsApp से संचार करने वाले WebSocket client को wrap करके काम करता है
  • authentication के समय credentials को capture करता है, और संदेश receive/send होने पर उनकी पूरी सामग्री की copy बना लेता है
  • सामान्य functionality जस की तस रहती है, बस सारा डेटा हमलावर को भी दूसरी बार भेजा जाता है
• चोरी किए गए डेटा को custom RSA implementation से encrypt करके भेजा जाता है
  • यह WhatsApp की अपनी end-to-end encryption से अलग होता है और network monitoring से बचने वाली encryption के रूप में इस्तेमाल किया जाता है
• सर्वर address code में सीधे दिखाई नहीं देता, बल्कि encrypted configuration string के भीतर छिपा होता है
  • Unicode variable manipulation, LZString compression, Base-91 encoding, AES encryption जैसी 4-स्तरीय obfuscation लागू की गई है

Backdoor इंस्टॉल करना

• यह WhatsApp के device pairing code फीचर का दुरुपयोग करके हमलावर के डिवाइस को उपयोगकर्ता के खाते से जोड़ देता है
  • पैकेज में AES से encrypt किया गया hardcoded pairing code शामिल है
  • उपयोगकर्ता के authenticate करते समय हमलावर का डिवाइस भी साथ में connect हो जाता है और स्थायी account access हासिल कर लेता है
• इसके बाद हमलावर संदेश देख सकता है, भेज सकता है, media डाउनलोड कर सकता है, संपर्कों तक पहुँच सकता है, यानी पूरे खाते पर नियंत्रण पा सकता है
• npm पैकेज हटाने पर भी हमलावर का डिवाइस जुड़ा रहता है, और इसे रोकने के लिए WhatsApp settings में जाकर सभी linked devices को manually disconnect करना पड़ता है

Analysis से बचने की तकनीकें

• code में 27 infinite loop trap शामिल हैं, जो debugging tool का पता चलते ही execution रोक देते हैं
  • debugger, process arguments, sandbox environment आदि का पता लगाकर dynamic analysis में बाधा डाली जाती है
  • malicious code सेक्शन पर comments लगे हुए हैं, जिससे व्यवस्थित development management के संकेत मिलते हैं

निष्कर्ष और सुरक्षा संकेत

• supply chain attack अब और अधिक परिष्कृत हो रहे हैं, और सामान्य रूप से काम करने वाले code के रूप में छिपे उदाहरण बढ़ रहे हैं
• केवल static analysis और reputation-based verification से इन्हें पकड़ना कठिन है, इसलिए runtime behavioral analysis की ज़रूरत है
• Lotusbail का मामला उस security gap का फायदा उठाता है जिसमें “code काम कर रहा है, इसलिए सुरक्षित है” मान लिया जाता है, और यह runtime behavior monitoring system बनाने के महत्व को दिखाता है
• Koi Security की research team ने ऐसी runtime-based detection techniques के ज़रिए उन खतरों की पहचान की, जो मौजूदा verification प्रक्रियाओं को bypass कर जाते हैं

[GN⁺]

Hacker News की राय

• हर बार जब कोई malware incident होता है, तो security team का डेटा को ज़रूरत से ज़्यादा lock down करने की तरफ जाना परेशान करता है
  WhatsApp messages लीक होना ट्रिगर था, लेकिन अंत में वे कुछ और भी चुरा लेते
  अगर ऐप्स को इस तरह रोक दिया जाए कि केवल खास signatures ही पढ़ सकें, तो वैध backup या data access भी असंभव हो जाता है
  security मज़बूत होना अच्छी बात है, लेकिन सब कुछ बंद कर देने वाली overreaction भी अपने आप में एक समस्या है

  • सहमत हूँ। संदर्भ के लिए, यह package official WhatsApp API का wrapper नहीं है, बल्कि reverse-engineered WhatsApp Web client है
    user ऐसे access करता है जैसे WhatsApp account से कोई दूसरा client जोड़ा गया हो, और नतीजतन पूरे data तक access मिल जाता है
    अगर WhatsApp ने ठीक-ठाक official API दिया होता, तो ऐसी घटनाएँ कम होतीं
    संबंधित दस्तावेज़: Baileys Wiki
  • मेरा मानना है कि OS को apps के बीच data access को mediate करना चाहिए, और user से साफ़ तौर पर permission request करनी चाहिए
  • मुझे लगता है कि WhatsApp ऐसी पाबंदियाँ security नहीं बल्कि competition को सीमित करने के लिए लगाता है
  • apps को lock करना आखिरकार companies के लिए ज़्यादा control और revenue पाने का तरीका है
    पहले malware ज़्यादा था, लेकिन उतनी ही ज़्यादा आज़ादी और interoperability भी थी
  • इस स्थिति पर एक बढ़िया व्यंग्य xkcd comic है

• अब ऐसी attacks मुझे predictable outcome लगती हैं
  NPM जैसे package managers build से ठीक पहले dependencies खींचते हैं, इसलिए वे मूल रूप से कमजोर हैं
  version control system को bypass करते हुए, अनगिनत dependencies को बिना verification के स्वीकार करने वाली संस्कृति ही समस्या है

  • धीरे-धीरे एहसास हो रहा है कि हम developers security में सचमुच कमज़ोर हैं
    सिर्फ NPM नहीं, Cargo, Docker, CI/CD — हर ecosystem में लगभग यही समस्या है
    “नाम से install करो और खत्म” वाला ढाँचा trust पर बहुत ज़्यादा टिका है
    कोई आसान solution नहीं है — न collaboration छोड़ी जा सकती है, न पूरी security हासिल की जा सकती है
    आखिरकार राक्षस पहले से ही घर के अंदर है
  • सहमत, लेकिन यह सिर्फ package managers की समस्या नहीं है
    सीधे git URL specify करने पर भी नतीजा वही होगा
    आखिरकार यह dependency management की संरचनात्मक समस्या है
  • हर platform पर package managers बहुत ज़्यादा हैं
    language-agnostic standardized package manager की ज़रूरत महसूस होती है
    signature verification, provenance guarantee, API standardization जैसी सुविधाएँ अनिवार्य होनी चाहिएँ
  • apt या rpm जैसे system package managers भी perfect नहीं हैं
    xz incident की तरह infected package वैसे ही वितरित हो सकते हैं
    ऊपर से system package managers latest versions को support करने में धीमे होते हैं, इसलिए development के लिए अनुपयुक्त हैं
    यही वजह है कि npm, cargo, pip जैसे tools की ज़रूरत पड़ती है
  • यह dependency संक्रमित होने का मामला नहीं था, बल्कि शुरू से ही malicious package था
    package manager की गलती नहीं, बल्कि शुरुआत से untrusted code था

• यह मज़ेदार है कि malware लेखक ने function का नाम exfiltrateCredentials जैसा इतना खुल्लमखुल्ला रखा
  debugger detection तक डाल दी, लेकिन code obfuscation नहीं की — यही विडंबना है

  • असल में code obfuscated था, और लेखक ने demo के लिए restored version प्रकाशित किया था
  • 27 debugging traps को test करने के लिए काफ़ी test coverage चाहिए होगी
    अब malware testing भी development का ही एक रूप बन चुकी है

• “ऐसी dependencies जिन्हें developers बिना सोचे install कर लेते हैं” — यह बात डरावनी है

  • ज़्यादातर developers बस npm install चला देते हैं
    जब तक संगठन की security policy बहुत सख्त न हो, इसे व्यवहारिक रूप से रोकना मुश्किल है
    शायद आखिरकार समाधान बस npm का कम इस्तेमाल करना ही हो
  • Docker images के साथ भी यही बात है
    अगर tags के आधार पर specify करें, तो कभी भी supply chain attack का शिकार हो सकते हैं
    industry हमारी सोच से कहीं ज़्यादा blind trust पर चल रही है
    automated deployment systems के पास “दोबारा सोचने” की भी फुर्सत नहीं होती
  • डरावना है, लेकिन ज़्यादातर developers के लिए यह कड़वी सच्चाई है
  • मुझे लगता है इसमें थोड़ी अतिशयोक्ति भी मिली हुई है

• अच्छा होता अगर JavaScript में भी Apache Commons जैसी कोई भरोसेमंद बड़ी library होती
  Apache Commons परिचय

  • लेकिन library चाहे जितनी बड़ी हो, उसमें WhatsApp API शायद शामिल नहीं होगा

• lotusbail package, WhatsApp Web API का रूप धरने वाला एक malicious npm package है
  यह 6 महीने तक वितरित हुआ, और credential theft, message interception, backdoor installation जैसे कई हमले करता रहा

• JS ecosystem पर निर्भर developers को व्यवहारिक रूप से risk mitigation strategy चाहिए
  Docker या VM के इस्तेमाल जैसे तरीकों का ज़िक्र हुआ

  • पिछली नौकरी में मैं DevOps और security संभालता था
    हमने सारे development environments को containerize किया और dependencies को pinned versions पर lock किया
    global installs पर रोक, automatic updates पर रोक, manual verification अनिवार्य
    sensitive projects के लिए dedicated workstations को नियमित रूप से reset किया जाता था
    झंझट है, लेकिन वही यथार्थवादी security है
    नहीं तो JS ecosystem छोड़ना भी एक तरीका है
  • लेकिन इस मामले में user ने package जानबूझकर install किया था, इसलिए ऐसे उपायों से रोकना मुश्किल है
    OS या Docker स्तर पर यह पुष्टि करने की क्षमता होनी चाहिए कि network connection की अनुमति देनी है या नहीं
  • मैं Incus OS इस्तेमाल करता हूँ और हर project के लिए नया container उठाकर development करता हूँ
    kernel shared होता है, लेकिन JS ecosystem के attacks को रोकने के लिए यह काफ़ी है
    अगर कभी container escape attack npm पर दिखा, तब VM पर जाऊँगा
    शुरू में यह overkill security लगी थी, लेकिन अब तेज़ और स्थिर लगती है
  • ऐसे packages वितरित किए जाएँ तो जोखिम सिर्फ developers तक नहीं, बल्कि सभी users तक फैलता है
  • कुछ companies सिर्फ वही npm packages allow करती हैं जो कुछ महीनों से ज़्यादा पुराने हों
    क्योंकि तब तक उनके malicious होने का पता चल जाता है

• यह package शुरू से ही security failure था
  इसमें official API नहीं, बल्कि client authentication का reimplementation इस्तेमाल हुआ, और user secret keys को third party ने handle किया
  user को भी सावधान रहना चाहिए था, लेकिन पूरी तरह उसी को दोष देना मुश्किल है

  • वास्तव में WhatsApp का public API है ही नहीं
    API access पाने के लिए “WhatsApp Business Platform” में register करना पड़ता है
    अगर कोई असली API होती, तो शायद यह घटना नहीं होती
  • अगर official API में features कम हों, तो reimplementation अपने आप में समस्या नहीं है
    लेकिन authentication के दौरान secret keys तीसरे पक्ष को देना जोखिमभरा है
    आम तौर पर लोग अपना account automate करने के लिए ऐसे packages install करते हैं

• आजकल LLM-generated blog posts की भरमार है
  quality कम है, लेकिन cost लगभग शून्य होने से marketers के लिए यह असरदार है
  पारंपरिक writing अब मानो legacy बनती जा रही है

  • मगर मज़े की बात है कि यह comment भी LLM द्वारा लिखा हुआ लगता है

• लगता है supply chain attacks बढ़ रही हैं। developers को कैसे जवाब देना चाहिए?

  • mitigation के लिए random packages का इस्तेमाल बंद करना होगा, और मूल रूप से npm जैसे ecosystem से बाहर निकलना होगा
  • जिन packages में server URL obfuscated या encrypted हो, वे warning sign हैं
    automated scanning से ऐसे patterns पकड़कर verification process को सख्त करना चाहिए
  • 1999 की तरह dependencies को सीधे review करके vendor करना चाहिए
  • आज dependencies बहुत ज़्यादा हैं, और कोई code देखता ही नहीं
    containerization, dependency locking, security scanning, delayed updates — सब अनिवार्य हैं
    npm global install सबसे खराब विकल्प है
  • अगर चलाना ही पड़े, तो उसे जितना संभव हो उतने isolated environment में चलाना चाहिए
    rootless podman जैसे containers या VM का इस्तेमाल करके जोखिम को न्यूनतम करना चाहिए