LiteLLM सप्लाई चेन हमले पर मिनट-दर-मिनट प्रतिक्रिया रिकॉर्ड

 (futuresearch.ai)
3 पॉइंट द्वारा GN⁺ 2026-03-28 | अभी कोई टिप्पणी नहीं है. | WhatsApp पर शेयर करें
  • PyPI के जरिए वितरित LiteLLM 1.82.8 malicious package के संक्रमण को रियल-टाइम में डिटेक्ट और विश्लेषित करने वाली मिनट-दर-मिनट प्रतिक्रिया डायरी
  • संक्रमण Cursor IDE auto update के दौरान हुआ, और litellm_init.pth फ़ाइल चलकर credentials theft और system infection का कारण बनी
  • malicious code ने SSH keys और cloud credentials collection, Kubernetes में फैलने की कोशिश, fork bomb बनाना जैसी कई तरह की गतिविधियाँ कीं
  • PyPI security team और LiteLLM maintainers को तुरंत रिपोर्ट किया गया, जिसके बाद package quarantine और CVE registration हुआ
  • Claude Code जैसे AI-आधारित code analysis tools ने हमले की पहचान में अहम भूमिका निभाई और AI ecosystem supply chain security को मज़बूत करने की ज़रूरत को उजागर किया

LiteLLM सप्लाई चेन हमले की प्रतिक्रिया का रिकॉर्ड

  • LiteLLM 1.82.8 version को PyPI के जरिए वितरित malicious package के रूप में पहचाना गया, और संक्रमण की पहचान से लेकर quarantine तक की प्रक्रिया को मिनट-दर-मिनट दर्ज किया गया
  • संक्रमण Cursor IDE के auto update process के दौरान हुआ, और Claude Code तथा uv package manager के जरिए इंस्टॉल की गई dependencies में मौजूद litellm_init.pth फ़ाइल के चलने से system infection हुआ
  • हमले में credentials theft, system persistence installation, Kubernetes propagation attempt, और fork bomb सहित कई तरह की गतिविधियाँ शामिल थीं
  • PyPI security team और LiteLLM maintainers को तुरंत रिपोर्ट किया गया, जिसके बाद package quarantine और CVE issuance हुआ
  • AI-आधारित code analysis tools ने रियल-टाइम malicious activity detection और analysis में मुख्य भूमिका निभाई

शुरुआती पहचान और सिस्टम असामान्यता के संकेत

  • 11:13 UTC के आसपास macOS laptop पर 11,000 से अधिक Python processes बन गए, जिससे सिस्टम लगभग ठप हो गया
    • exec(base64.b64decode('...')) जैसे command बार-बार चल रहे थे, जिससे CPU और memory पूरी तरह भर गए
    • force quit और reboot के बाद persistence से जुड़े निशान नहीं मिले
  • शुरुआत में इसे Claude Code के internal loop या uv run script error से पैदा हुई non-malicious loop phenomenon माना गया
  • बाद में htop screenshot और logs से यह पुष्टि हुई कि base64-encoded Python script बार-बार चल रही थी

संक्रमण के कारण की पहचान

  • 11:40 UTC के आसपास इंस्टॉल किए गए Python tools में litellm_init.pth फ़ाइल मिली, जिससे इसे malicious activity के रूप में पहचाना गया
    • .pth फ़ाइलें Python startup पर अपने-आप चलती हैं और हर Python process में काम करती हैं
    • यह SSH keys, cloud credentials, database passwords, environment variables, shell history आदि इकट्ठा करती थी
    • इकट्ठा किया गया डेटा RSA encryption के बाद https://models.litellm.cloud/ पर भेजा जाता था
    • ~/.config/sysmon/sysmon.py में persistence install करने की कोशिश की गई, लेकिन force reboot के कारण यह रुक गया
  • संक्रमण Cursor IDE के auto update (10:58 UTC) के दौरान हुआ
    • futuresearch-mcp-legacy extension ने uvx के जरिए litellm 1.82.8 डाउनलोड किया
    • यह version सिर्फ PyPI पर मौजूद था और GitHub release tag मौजूद नहीं था
    • PyPI upload time 10:52 UTC था, यानी संक्रमण से ठीक पहले इसे वितरित किया गया था

malicious code की संरचना

  • Stage 1 (litellm_init.pth): Python startup पर अपने-आप चलकर base64-encoded payload को decode कर execute करता है
  • Stage 2: इसमें RSA public key शामिल थी, जिसका उपयोग चोरी किए गए डेटा को encrypt करने में होता था
  • Stage 3 (B64_SCRIPT): असली credentials collection और transmission करता था
  • Persistence installation: sysmon.py को systemd service के रूप में register करने की कोशिश
  • Kubernetes propagation code: alpine:latest image का उपयोग कर हर node पर privileged pod बनाने की कोशिश
  • Fork bomb का कारण: subprocess.Popen([sys.executable, "-c", ...]) call ने child processes में भी .pth को फिर से चलाया, जिससे infinite loop बना

नुकसान का दायरा और प्रतिक्रिया कदम

  • उजागर हुए credentials

    • SSH keys, GCloud और Kubernetes authentication info, .env फ़ाइलों में API keys, Supabase·ClickHouse·Grafana passwords आदि
    • तुरंत सुझाए गए कदम
    1. सभी SSH और cloud credentials rotate करें
    2. .env और .mcp.json में मौजूद secret keys फिर से जारी करें
    3. ~/.cache/uv cache हटाएँ
    4. PyPI security team (security@pypi.org) और LiteLLM maintainers को रिपोर्ट करें

  • Kubernetes cluster inspection results

    • malicious pod (node-setup-*, sysmon) नहीं मिले
    • macOS environment में execution होने के कारण cluster के अंदर propagation असफल रहा
    • लेकिन ~/.kube/config के exposed होने की संभावना के कारण credentials rotation ज़रूरी है

PyPI और सार्वजनिक प्रतिक्रिया

  • 11:58 UTC पर Docker-isolated environment में PyPI से litellm 1.82.8 डाउनलोड कर malicious .pth फ़ाइल की मौजूदगी फिर से पुष्टि की गई
  • PyPI security team और BerriAI/litellm repository को तुरंत रिपोर्ट किया गया
    • बाद में इसे PYSEC-2026-2 (CVE) के रूप में दर्ज किया गया
  • 12:01 UTC पर FutureSearch blog में supply chain attack disclosure post लिखकर प्रकाशित किया गया
    • 3 मिनट के भीतर PR लिखकर merge भी कर दिया गया
  • 12:04 UTC पर r/Python, r/netsec, r/LocalLLaMA, r/MachineLearning, r/devops communities में साझा करने का प्रस्ताव दिया गया
    • इससे Python और security communities में तेज़ प्रतिक्रिया को बढ़ावा मिला

इस घटना का महत्व

  • AI-आधारित code analysis tool Claude Code ने रियल-टाइम में malicious activity की पहचान की और security researcher के हस्तक्षेप से पहले ही warning बनाई
  • यह supply chain attack का ऐसा मामला था जिसने AI developer ecosystem को सीधे निशाना बनाया, और PyPI account security तथा auto update verification को मज़बूत करने की ज़रूरत को रेखांकित किया
  • यह दिखाता है कि AI tools सिर्फ development assistance तक सीमित नहीं हैं, बल्कि cyber threat detection और response automation में भी उपयोग किए जा सकते हैं

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

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.