Trivy पर फिर हमला: व्यापक GitHub Actions टैग छेड़छाड़ से secrets लीक

 (socket.dev)
2 पॉइंट द्वारा GN⁺ 2026-03-24 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • आधिकारिक GitHub Action को tag force-update करके छेड़छाड़ की गई, जिससे malware तैनात करने वाला supply chain attack हुआ
  • हमलावरों ने 76 में से 75 tags को malicious commit से बदल दिया, जिससे करीब 10,000 से अधिक workflows प्रभावित हुए
  • छेड़छाड़ की गई script secrets का संग्रह, encryption और exfiltration — इन 3 चरणों में काम करती है, और इसमें TeamPCP Cloud stealer कोड शामिल है
  • संक्रमित tags अब भी सक्रिय हैं, और @0.35.0 या specific commit SHA ही सुरक्षित माने गए हैं
  • सभी credentials को बदलना और commit SHA pinning का उपयोग अनिवार्य है; Docker Hub images में भी यही संक्रमण पाया गया है

Trivy GitHub Actions supply chain attack का अवलोकन

  • Trivy के आधिकारिक GitHub Action (aquasecurity/trivy-action) के साथ हमलावरों ने tag force-update (force-push) के जरिए छेड़छाड़ की, जिससे malicious code तैनात हुआ
  • हमलावरों ने 76 version tags में से 75 को malicious commit से बदल दिया, ताकि वे CI/CD pipelines में अपने-आप चलें
  • करीब 10,000 से अधिक GitHub workflow files इस action को refer करती हैं, इसलिए असर का दायरा बहुत बड़ा है
  • संक्रमित tags अब भी सक्रिय हैं, और @0.35.0 ही एकमात्र सुरक्षित version के रूप में पुष्टि हुई है
  • Socket ने 19:15 UTC से real time में 182 malicious GitHub Action events detect किए, जिन्हें Backdoor, Infostealer, और Reconnaissance प्रकार में वर्गीकृत किया गया

हमले का कारण और तरीका

  • Trivy maintainers के अनुसार, यह हमला write permission वाले credentials की चोरी के कारण हुआ
    • मार्च की शुरुआत में हुई पिछली breach में CI environment के secrets लीक हुए थे, और rotation प्रक्रिया पूरी तरह सफल नहीं रही, इसलिए कुछ नए credentials भी हमलावरों के पास रह गए
    • हमलावरों ने इन्हीं credentials का उपयोग कर GitHub की किसी vulnerability के बिना authenticated tag updates किए
  • हमलावरों ने branch push या release creation के बजाय, मौजूदा tags को force करके नए commits से overwrite किया
    • हर tag को असली commit की metadata — author, email, timestamp, commit message — कॉपी करके वैध जैसा दिखाया गया
    • लेकिन मूल commits GPG-signed थे, जबकि हमलावरों के commits में signature नहीं थी, और parent commit की तारीख 2026 होने जैसी असंगति थी
  • GitHub पर Immutable Release दिखने पर भी संभव है कि हमलावरों ने malicious state में publish करके बाद में lock कर दिया हो
    • इसलिए “Immutable” badge पर भरोसा न करें; सुरक्षित consumption का एकमात्र तरीका commit SHA pinning है

tag छेड़छाड़ की संरचना

  • हमलावरों ने master branch के latest commit (57a97c7e) के आधार पर नए commits बनाए
    • केवल entrypoint.sh file को malicious version से बदला गया और बाकी files जस की तस रखी गईं
    • हर tag में मूल PR number, commit message, और author info को ज्यों का त्यों कॉपी करके forged बनाया गया
  • GitHub release page पर अगर “0 commits to master since this release” दिखता है, तो इसे छेड़छाड़ किए गए tag का visual indicator माना जा सकता है
  • 0.35.0 tag के न बदले जाने की वजह यह थी कि वह पहले से ही master HEAD को point कर रहा था

malicious payload की संरचना

  • छेड़छाड़ किया गया entrypoint.sh कुल 204 lines का है; line 4~105 में Infostealer code है, और उसके बाद सामान्य Trivy scan code शामिल है
  • malicious code 3 चरणों में बना है
    • चरण 1: Collection — runner process memory और filesystem से secrets निकालना
    • चरण 2: Encryption — AES-256-CBC और RSA-4096 से collected data encrypt करना
    • चरण 3: Exfiltration — attacker-controlled domain या victim के GitHub account पर data भेजना

  • चरण 1: secrets का संग्रह

    • GitHub Actions runner processes (Runner.Worker, Runner.Listener, runsvc, run.sh) के environment variables को /proc/<pid>/environ से पढ़कर env, ssh keyword वाले entries निकाले जाते हैं
    • GitHub-hosted runners पर Python-आधारित memory dump script को sudo से चलाकर Runner.Worker process memory में "isSecret":true pattern खोजा जाता है
    • self-hosted runners पर TeamPCP Cloud stealer के रूप में पहचाना गया filesystem credential collector चलाया जाता है
      • इसमें SSH keys, AWS/GCP/Azure credentials, Kubernetes tokens, Docker config, DB passwords, environment files, TLS keys, VPN settings, Webhook URLs, wallet keys आदि जैसे व्यापक targets शामिल हैं

  • चरण 2: Encryption

    • openssl rand से 32-byte session key बनाकर AES-256-CBC से data encrypt किया जाता है
    • session key को RSA-4096 public key से OAEP padding के साथ encrypt किया जाता है
    • encrypted data (payload.enc) और session key (session.key.enc) को tpcp.tar.gz में bundle किया जाता है

  • चरण 3: data exfiltration

    • पहला channel: https://scan[.]aquasecurtiy[.]org पर HTTPS POST (aquasecurity की typo domain का उपयोग)
    • दूसरा channel: failure होने पर victim के GitHub Personal Access Token का उपयोग करके tpcp-docs नाम का public repository बनाया जाता है
      • release asset के रूप में tpcp.tar.gz upload किया जाता है → हमलावर GitHub search से repository खोजकर data इकट्ठा करते हैं
    • GitHub infrastructure का उपयोग करके firewall bypass की कोशिश की जाती है, जिससे detection से बच निकलने की संभावना बढ़ती है
    • अंत में temporary files delete करके traces कम किए जाते हैं

हमलावर और पृष्ठभूमि

  • malicious code की comments में “TeamPCP Cloud stealer” स्पष्ट रूप से लिखा है
    • TeamPCP (DeadCatx3, PCPcat, ShellForce) एक cloud-native environment पर हमला करने वाला group है, जिसके Docker API, Kubernetes, Redis, और Ray dashboard vulnerabilities के दुरुपयोग के उदाहरण मौजूद हैं
    • फरवरी 2026 में Flare और The Hacker News ने इसे ransomware, data theft, और cryptocurrency mining campaigns से जोड़ा था
  • Solana validator keys और cryptocurrency wallets को इकट्ठा करने की क्षमता इसके वित्तीय उद्देश्य से मेल खाती है

response और सिफारिशें

  • Trivy Action के सभी version tags का उपयोग बंद करें, और केवल commit SHA 57a97c7e7821a5776cebc9bb87c984fa69cba8f1 या tag 0.35.0 का उपयोग करें
  • संक्रमित pipelines को पूर्ण secret compromise मानें; सभी cloud credentials, SSH keys, API tokens, DB passwords, और Docker tokens को तुरंत rotate करना आवश्यक है
  • GitHub organization में tpcp-docs repository की मौजूदगी जांचने और 19 मार्च 19:00 UTC के बाद चले trivy-action logs की समीक्षा करने की सिफारिश की गई है

समझौते के संकेतक (IOCs)

  • network indicator: scan[.]aquasecurtiy[.]org
  • file hash: 18a24f83e807479438dcab7a1804c51a00dafc1d526698a66e0640d1e5dd671a (entrypoint.sh)
  • संक्रमित GitHub Actions: aquasecurity/trivy-action@0.0.1 ~ @0.34.2 के सभी versions शामिल (कुल 75 tags)

अतिरिक्त अपडेट (22 मार्च)

  • Docker Hub में भी Trivy images (0.69.4, 0.69.5, 0.69.6, latest) के उसी Infostealer payload से संक्रमित होने की पुष्टि हुई
  • latest tag को malicious image पर सेट किया गया था, जिससे exposure period के दौरान यह users तक वितरित हुआ
  • संबंधित विस्तृत जानकारी Socket की अलग रिपोर्ट “Trivy Docker Images Compromised” में देखी जा सकती है

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

1 टिप्पणियां

 
GN⁺ 2026-03-24
Hacker News की राय

  • यह जानने की उत्सुकता है कि GitHub Actions में immutable versioning को अनिवार्य क्यों नहीं किया जाता
    security guide कहती है कि commit SHA पर pin करो, लेकिन अगर pin किए बिना Action publish ही न किया जा सके, तो ऐसी समस्याएँ कम हो सकती हैं

    • ऐसी चर्चा में हमेशा दो पहलू होते हैं
      security team के नज़रिए से fixed version सुरक्षित है, लेकिन साथ ही अगर security updates अपने-आप लागू न हों तो वह भी जोखिम है
      आखिरकार ऐसी राह चाहिए जो productivity को नुकसान पहुँचाए बिना दोनों बातों को संतुलित करे
      इसे “Pinning का paradox” कहना ठीक लगेगा
    • लगता है GitHub Actions git tag model का पालन करता है, इसलिए मौजूदा संरचना बदलना कठिन है
      फिर भी, कभी न कभी इसे बदलने का काम शुरू करना होगा
    • अगर pin किया गया version पहले से ही compromised हो तो?
      updates की अनुमति देना उल्टा security को और मजबूत कर सकता है
      यह static linking vs dynamic linking बहस जैसा सवाल है
      ऊपर से Trivy Action वैसे भी latest version लाने के लिए बनाया गया था

  • यह घटना इस बात की चेतावनी है कि “supply chain security” products भी व्यवहार में उतने ही कमज़ोर हो सकते हैं जितने उस stack को वे बचाने का दावा करते हैं
    खासकर वे security tools जो “हर जगह चलो(run us everywhere)” मॉडल पर काम करते हैं, एक ही हमले से असंख्य users को खतरे में डाल सकने वाला नया attack vector बन जाते हैं

  • पहले लगा था कि Trivy ने credential rotation सही ढंग से नहीं किया
    लेकिन उनका कहना है कि “non-atomic rotation प्रक्रिया के दौरान attacker ने नया token जान लिया होगा”
    GitHub token जारी होने के बाद उसे दोबारा नहीं दिखाता, हालांकि इस्तेमाल किए गए authentication method के हिसाब से फर्क हो सकता है

    • OpenClaw के निर्माता ने भी कहा कि उन्हें ऐसा ही अनुभव हुआ था
      नया GitHub organization बनते ही उसका नाम hijack हो गया, और उन्हें GitHub से atomic creation handling की माँग करनी पड़ी

  • “vulnerabilities को scan करना चाहिए, खुद vulnerability नहीं बनना चाहिए” — इस घटना पर यह बात बिल्कुल फिट बैठती है

    • यहाँ तक कि मज़ाक भी हुआ: “अगर तुम vulnerability में झाँकोगे, तो vulnerability भी तुममें झाँकेगी”

  • संबंधित घटना के रूप में Trivy supply-chain का temporary compromise भी हुआ था

    • “temporary” शब्द कुछ ज़्यादा ही नरम अभिव्यक्ति लगता है

  • 22 मार्च को attacker ने चुराए गए credentials से malicious Trivy v0.69.5, v0.69.6 DockerHub images publish किए
    (security advisory link)
    19 मार्च और 22 मार्च को दो अलग घटनाएँ हुईं, और लगता है कि attacker ने credentials को दो बार rotate किए जाने के बाद भी लगातार access बनाए रखा

    • वास्तव में फरवरी से ही पूरे repository का compromise हो चुका था, और यह उसी attacker का तीसरा सफल हमला था

  • “पिछले 2 हफ्ते सबसे बुरे रहे”
    Trivy के compromise होने की वजह से ढेर सारी security reports और meetings संभालनी पड़ रही हैं

  • इससे यह सबक मिलता है कि “security software बनाना, ज़रूरी नहीं कि competency की गारंटी हो”
    हमारी security team भी हर महीने नया scanner लाने की कोशिश करती है, लेकिन अगर हमने उनकी माँगी हुई व्यापक access permissions दे दी होतीं, तो शायद हम कई बार compromise हो चुके होते

    • पहले Trivy के GitHub Actions का audit किया था, और setup-trivy Action main branch को सीधे clone करके shell script चलाता था
      यानी हर CI workflow में arbitrary code execution संभव था
      Aqua इस महीने की शुरुआत में compromise हुआ, फिर isolation failure दो बार हुई और आखिर Docker Hub account भी टूट गया
      अब लगता है कि उन्हें बाहरी विशेषज्ञों की मदद चाहिए
    • “security tool” को व्यापक access permissions देना risk कम करना नहीं, risk फैलाना है
      ज़्यादातर सिर्फ शोर मचाने वाले report generators होते हैं, और attacker अंदर घुस जाए तो कोई रक्षा नहीं कर पाते
      नए scanners को isolated sandbox में केवल read-only data तक पहुँच मिलनी चाहिए, और पर्याप्त जाँच से पहले production permissions नहीं देनी चाहिए
      नहीं तो यह लगभग secret keys को pastebin पर डालने जैसा है
    • आजकल enterprise security का मतलब हर device पर endpoint security solution डालना और सारे logs को AI dashboard में भेज देना रह गया है
      security culture “तेज़ी से आगे बढ़ो और सब कुछ तोड़ दो” जैसी बन गई है
    • security department के पास व्यवहार में यह विकल्प नहीं होता कि “market में ठीक-ठाक product ही नहीं है, इसलिए हम कुछ भी इस्तेमाल नहीं करेंगे”
      इसी वजह से low-quality security software को भी हर हाल में अपनाने वाली संस्कृति बन जाती है
      Trivy खुद बुरा नहीं लगता, और हमारी company भी इसका इस्तेमाल करती है
      बस हमने Nix से version pin किया हुआ है और Actions workflow खुद लिखे हैं, इसलिए इस compromise का असर नहीं पड़ा

  • attacker authenticated स्थिति में tag force-update कर सकता था
    GitHub की पुरानी setting “tag overwrite निषिद्ध” सिर्फ चालू होती, तो यह रोका जा सकता था
    ऐसी घटनाएँ जितनी बढ़ती हैं, उतना ही लगता है कि Software Building Code जैसे standards की ज़रूरत है
    सोच रहा हूँ 2026 तक ऐसे कारण और कितने जुड़ जाएँगे