CodeRabbit भेद्यता एक्सप्लॉइट: एक साधारण PR से 10 लाख repositories पर RCE और write access हासिल करने तक

 (research.kudelskisecurity.com)
1 पॉइंट द्वारा GN⁺ 2025-08-20 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • सुरक्षा शोध टीम ने CodeRabbit के production server पर remote code execution(RCE) और API token·secret information leak हासिल किया
  • Rubocop का उपयोग करने वाले PR के जरिए environment variables की चोरी हुई, और PostgreSQL access तथा 10 लाख repositories को read/write करना संभव था
  • GitHub App की private key लीक होने से public/private repos सहित बड़े पैमाने पर repositories में malicious code inject करना, source code बदलना जैसी वास्तविक क्षति संभव थी
  • CodeRabbit ने भेद्यता रिपोर्ट के कुछ घंटों के भीतर तुरंत प्रतिक्रिया दी और सुरक्षा उपायों को मजबूत किया
  • बाहरी tools चलाते समय sandbox isolation, least privilege, network blocking आदि से security incidents रोकने की आवश्यकता पर जोर दिया गया

परिचय

  • जनवरी 2025 में, Kudelski Security की शोध टीम ने CodeRabbit की गंभीर सुरक्षा भेद्यता सार्वजनिक की
  • PR review automation tool के रूप में व्यापक रूप से इस्तेमाल होने वाले CodeRabbit में remote code execution(RCE), environment variables और sensitive information leak, तथा 10 लाख से अधिक repositories पर Read/Write access हासिल करने जैसी गंभीर समस्याएँ पाई गईं
  • यह लेख Black Hat USA में प्रस्तुत सार्वजनिक भेद्यता के विस्तृत विश्लेषण को समेटता है, और code review tools तथा integrated systems की भेद्यताओं के वास्तविक उदाहरण के रूप में महत्वपूर्ण संदर्भ मूल्य रखता है
  • रिपोर्ट की गई भेद्यताओं को रिपोर्ट होते ही जल्दी patch कर दिया गया

CodeRabbit का अवलोकन

  • CodeRabbit GitHub/GitLab Marketplace में सबसे अधिक install किया गया AI-आधारित code review app है
  • यह दोनों प्लेटफॉर्म पर 10 लाख repositories और 50 लाख pull requests की समीक्षा करता है
  • जब भी उपयोगकर्ता PR बनाता या अपडेट करता है, AI engine code का विश्लेषण कर comments और suggestions अपने आप तैयार करता है
  • code summary, security vulnerability detection, improvements सुझाना, diagram generation जैसे कार्यों के जरिए developer productivity में बड़ा सुधार होता है

CodeRabbit का उपयोग और permission structure

  • Pro plan linter·SAST(static analysis) tools integration की सुविधा देता है
  • GitHub account authentication और app install करते समय चयनित repositories पर read/write permissions दी जाती हैं
  • यदि इस permission management का दुरुपयोग हो, तो install की गई सभी repositories के code पर सीधा प्रभाव डाला जा सकता है

बाहरी tools का execution और exploit की खोज

  • CodeRabbit PR में code changes का पता लगते ही कई बाहरी static analysis tools (जैसे Rubocop) अपने आप चलाता है
  • Rubocop .rubocop.yml configuration file का उपयोग कर बाहरी Ruby extension files (ext.rb आदि) को load कर सकता है
    • हमलावर .rubocop.yml और ext.rb में malicious code डालकर PR submit कर सकता है, जिससे CodeRabbit remote server पर वही code चला दे
  • इस तकनीक से चलाए गए code ने server के सभी environment variables हमलावर के server पर भेज दिए

environment variable leak का विश्लेषण

  • लीक हुए environment variables में विभिन्न services के API keys, tokens, passwords शामिल थे
    • Anthropic/OpenAI API keys, Encryption salt/password, GitHub App private key, PostgreSQL connection info आदि
  • RCE के जरिए database access, code changes, internal service information leak जैसी दूसरे स्तर की क्षति बहुत बड़ी और व्यापक हो सकती थी
  • production server पर और भी malicious exploration संभव था, लेकिन service operations को ध्यान में रखते हुए न्यूनतम पुष्टि के बाद इसे रोक दिया गया

10 लाख repositories पर Read/Write access हासिल करना

  • environment variables में शामिल GITHUB_APP_PEM_FILE(private key) का उपयोग करके GitHub API में authenticate करना संभव था
  • CodeRabbit जिन सभी repositories तक पहुँच सकता था (public/private सहित), उन पर
    • source code read/write, release files को replace करना(supply chain attack), git history बदलना जैसी बेहद शक्तिशाली permissions का इस्तेमाल संभव था
  • reproduction code(PoC) सार्वजनिक किया गया, जिससे वास्तविक exploitation की संभावना सिद्ध हुई

PoC सारांश

  • PyGitHub जैसी libraries का उपयोग करके लीक हुई private key, App ID आदि से किसी भी repository के लिए access token जारी किया जा सकता था
  • इस token के जरिए private repository clone करना, files बदलना, नए commits करना, release files में छेड़छाड़ करना आदि को automate किया जा सकता था

CodeRabbit की internal/private repositories के compromise की संभावना

  • CodeRabbit organization भी अपने service पर इसे install करके उपयोग कर रहा था, इसलिए CodeRabbit की internal source code repositories तक पहुँच और उन्हें clone करना भी संभव था
  • सिर्फ organization name पता हो तो install ID lookup के बाद सीधे उस repo list तक पहुँचना संभव था

प्रभाव का सारांश

  • private repositories तक unauthorized access और personal information leak
  • source code manipulation, malicious code/backdoor insertion जैसी supply chain attack की धमकी
  • GitHub Actions जैसी अतिरिक्त भेद्यताओं से chaining की संभावना
  • प्रत्यक्ष RCE के कारण data destruction, service outage, और अन्य services पर cascading damage की आशंका

संदर्भ और AI judgment की सीमाएँ

  • हमले के दौरान भी PR स्वयं CodeRabbit द्वारा सामान्य रूप से review किया गया, और भेद्यता चेतावनी comment छोड़ा गया था, लेकिन वास्तविक threat syntax को पहचान नहीं पाया
  • यह दिखाता है कि AI code review tools वास्तविक जोखिम वाली स्थिति के पूरे संदर्भ को समझ नहीं पाते

प्रतिक्रिया और सिफारिशें

  • CodeRabbit ने भेद्यता रिपोर्ट के कुछ घंटों के भीतर Rubocop disable किया, secrets rotate किए, और system audit किया
  • समस्या sandbox न लगे हुए tool(Rubocop) में हुई; कार्रवाई के बाद सभी बाहरी tools को isolated environment में चलाने के लिए सुधार किया गया
  • सुरक्षा मजबूत करने के लिए बाहरी tool execution environments में environment variables को न्यूनतम रखना, network access IP restrictions, internet access blocking जैसी defensive design की आवश्यकता पर जोर दिया गया

responsible disclosure और निष्कर्ष

  • जनवरी 2025 में रिपोर्ट के बाद तेज प्रतिक्रिया और remediation की गई
  • बात PoC तक सीमित रही, लेकिन यह पुष्टि हुई कि कोई malicious attacker high-value repos चुनकर बड़े पैमाने पर ransomware या विनाशकारी supply chain attacks में इसका आसानी से दुरुपयोग कर सकता था
  • बाहरी analysis tools और AI-आधारित automation services के साथ integration करते समय sandbox और least privilege principle लागू करने का महत्व फिर से स्पष्ट हुआ

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

1 टिप्पणियां

 
GN⁺ 2025-08-20
Hacker News की राय

  • ओह, यह सच में बहुत गंभीर vulnerability है। अच्छा है कि इसे इस बार ठीक कर दिया गया, लेकिन शुरुआत में ऐसा issue होना ही अपने आप में समस्या है। cloud platform पर user code analyze करने वाला system बनाते समय सबसे बुनियादी नियम यह है कि analyzer को हमेशा isolated environment में चलना चाहिए। plugin के जरिए सीधे code injection हो सकता है, और linter/analyzer/compiler जटिल software होते हैं जिनका attack surface बड़ा होता है। किसी भी arbitrary repository पर ऐसे tools को shared environment में चलाना सुरक्षित है, ऐसा कभी नहीं मानना चाहिए। मैंने भी एक code analysis platform चलाया है, और जब हम customer repositories पर अपने बनाए analyzers चलाते थे, तब भी उन्हें sandbox environment में चलने के लिए design किया गया था। environment variables या network request permissions भी शामिल नहीं थे, लेकिन analysis सिर्फ sandbox में ही चलता था। code analysis को सुरक्षित बनाने का यही एकमात्र तरीका है
    https://github.com/getgrit/gritql

  • मैंने Coderabbit की paid subscription cancel कर दी। यह बात हमेशा चिंता पैदा करती है कि किसी company को issue मानने के लिए HN पर इतना viral होना पड़े। official blog पर कहीं भी इस vulnerability का ज़िक्र नहीं है, और आज भी कोई नई post नहीं है। मेरा मानना है कि गलती किसी से भी हो सकती है, लेकिन ऐसी घटना होने पर उसे transparent तरीके से public न करना company की image को नुकसान पहुँचाता है

    • https://www.coderabbit.ai/blog/our-response-to-the-january-2025-kudelski-security-vulnerability-disclosure-action-and-continuous-improvement
    • दोनों articles आज ही publish हुए हैं। लगता है कि research team और coderabbit ने एक साथ disclosure करने पर सहमति बनाई थी। इस तरह का coordinated disclosure, जब तक customer data leak या उसके circumstantial evidence न हों, कोई अनिवार्य चीज़ नहीं है; vendor अगर खुद disclose करना चाहे तो यह एक आम practice है। security researchers उनका response सराह रहे हैं, यह अच्छा संकेत लगता है
    • ज़्यादातर security bugs बिना किसी announcement के quietly fix कर दिए जाते हैं। अगर customer data leak नहीं हुआ है (और आमतौर पर इसकी पुष्टि की जा सकती है), तो कानूनी रूप से disclosure अनिवार्य नहीं होता। इसका कोई खास फायदा भी नहीं है, इसलिए मुझे समझ नहीं आता कि लोग क्यों मानते हैं कि यह ज़रूरी ही होना चाहिए

  • यह बात कि "जब exploit चल रहा था, तब CodeRabbit खुद PR पर danger warning comment छोड़ रहा था, जबकि असल में उसी PR को चलाते हुए hack हो रहा था" सच में अजीब है। हम ऐसे समय में जी रहे हैं जहाँ AI खुद बता रहा है कि उसे hack किया जा रहा है, यह बात कुछ अवास्तविक सी लगती है। साथ ही, CodeRabbit team ने तेज़ी से response दिया, लेकिन उससे भी ज़्यादा चिंता की बात यह है कि "दूसरे vendors investigation contact का जवाब तक नहीं दे रहे थे और अब भी vulnerable हैं"। CodeRabbit team के लिए तालियाँ, लेकिन सभी को बहुत सावधानी से आगे बढ़ना चाहिए

    • यह मज़ेदार है कि CodeRabbit ने अपने ही system पर चला exploit खुद review किया
    • असल में exploit के बारे में anthropic model ने बताया था, और coderabbit system ने उसे ignore कर दिया
    • आख़िरकार यह फिर दिखाता है कि AI वास्तव में smart नहीं है, बस एक prediction-based reasoning system है जो अक्सर सही अनुमान लगा लेता है

  • CEO के official statement के एक हिस्से में कहा गया है कि "Rubocop sandbox environment के बाहर चल रहा था, इसलिए समस्या हुई", लेकिन सच कहूँ तो यह थोड़ा संदिग्ध लगता है। सिर्फ वही एक चीज़ पूरी तरह अलग तरह से क्यों चल रही थी, और वही breached task कैसे निकला?

    • मुझे समझ नहीं आता कि यह झूठ क्यों लगेगा। ऐसी गलतियाँ अक्सर होती हैं
    • शुरू से ही यह काफ़ी संभव है कि Kudelski Security के researchers ने कई static analysis tools आज़माए हों। Rubocop बस uniquely behave कर रहा था। article में भी कई approaches की कोशिश के संकेत दिखते हैं
    • "किसी एक task को अलग तरह से configure क्यों किया गया था" → किसी ने गलती की। ऐसा हो सकता है। "जो service vulnerable थी वही क्यों breach हुई" — मेरे हिसाब से vulnerable service का attack होना ही सबसे स्वाभाविक scenario है

  • लेख सच में दिलचस्प था, लेकिन वास्तव में यह कोई चौंकाने वाली बात नहीं है। users बिना सोचे-समझे बहुत सारे overly privileged apps जोड़ लेते हैं, और GitHub का permission system भी problematic है, इसलिए ऐसा होना लगभग अनिवार्य था। बहुत से लोग GitHub app को repository write access, यहाँ तक कि cloud permissions भी ज़रूरत से ज़्यादा दे देते हैं। branch protection होने पर भी pull request के ज़रिए GitHub Actions में privileged access मिल सकता है। इसे सही तरह से configure करने के लिए GitHub OIDC audience बदलनी पड़ती है, और documentation भी अच्छी नहीं है। अगर आप app vendor से कहें कि permissions कम करके कुछ features disable की हुई अलग version दे, तो ज़्यादातर को कोई दिलचस्पी नहीं होती और वे security issue समझते भी नहीं। GitHub को app access permissions को और granular बनाना चाहिए, और overall permissions भी काफ़ी अधिक granular होनी चाहिए

  • यह सच में भयावह है। मैंने अभी लेख पूरा भी नहीं पढ़ा है, और इसमें इतनी बातें हैं कि दिमाग सुन्न हो रहा है। जिस हिस्से में कहा गया कि hacker 1 लाख से 10 लाख के पैमाने पर open source tools/libraries/software distribution files में malware डाल सकता था, वहाँ तो लगा कि दुनिया ही खत्म हो सकती थी। आगे कितनी ऐसी समस्याएँ अब भी बाकी हैं, इसकी कल्पना करना भी मुश्किल है

    • अब मुझे लगता है कि 'GitHub Apps' अपने आप में ही जोखिम हैं। भले ही CodeRabbit breach न हुआ होता, इस बात की क्या गारंटी है कि ऐसी company हमेशा ईमानदारी से behave करेगी? कौन गारंटी देगा कि कोई insider malicious act नहीं करेगा? साधारण SaaS में personal data management एक अलग स्तर का risk है, लेकिन यहाँ targeted supply-chain attack की key उनके हाथ में होती है, जिससे बहुत बड़ा chaos हो सकता है
    • software industry में भी कम-से-कम basic safeguards या regulations होने चाहिए। अभी की तरह जहाँ कोई भी कोई भी गलती करे और उस पर कोई जवाबदेही न हो, यह सच में असामान्य है

  • मेरा मानना है कि इतनी गंभीर security failure को "breach incident" या "event" के रूप में classify किया जाना चाहिए, और media के जरिए उसका mandatory disclosure होना चाहिए। 7,000 से अधिक customers और 10 लाख repositories तक access रखने वाला tool, एक इतने simple exploit से टूट गया जिसे शायद 11 साल का बच्चा भी बना सकता था। अगर hack इतना आसान था, तो यह मानना तर्कसंगत है कि bots, black hats, APTs वगैरह शायद पहले ही घुस चुके होंगे और चुपचाप टिके हुए होंगे। अगर white hat के public करने से पहले कोई अंदर था, तो vulnerability patch सिर्फ नए attackers को रोकेगा; जो पहले से घुसे हुए हैं, वे शायद बने रहेंगे। मुझे पता है security कठिन है, लेकिन सच में अब संभलने की ज़रूरत है

    • अगर "mandatory disclosure होना चाहिए", तो Cyber Resilience Act देखा जा सकता है
    • Code Rabbit एक 'vibe coder' company है, तो इससे और उम्मीद भी क्या करें। security incident छिपाया गया, Google Cloud blog पर भी सिर्फ marketing post डाली गई, hack का ज़िक्र तक नहीं किया गया, और अब भी यह साबित नहीं किया गया कि कोई backdoor नहीं है
    • मेरे जैसे सामान्य user के लिए, यह बात कि इतने जटिल और शक्तिशाली services गलती से मेरा सारा कीमती data बाहर leak कर सकती हैं, मुझे सोचने पर मजबूर करती है कि क्या आगे भी ऐसी चीज़ें इस्तेमाल करनी चाहिए। organizations, governments, banks के contractors और न जाने कितनी जगह ऐसे apps इस्तेमाल होते हैं, और सिर्फ T&C मान लेने से third-party access दे दिया जाता है। >>“यह आश्वासन कि ऐसा किसी भी company के साथ हो सकता है”<< provider को सुकून दे सकता है, लेकिन user के लिए यह और बड़ी चिंता बन जाता है

  • समस्याओं में से एक यह है कि तरह-तरह के code analyzers, bundlers, compilers (जैसे Rust compiler आदि) बिना किसी warning के arbitrary code execute कर सकते हैं। उदाहरण के लिए, कोई hacker hiring assignment बताकर मुझे एक repository भेज दे, और मैं “npm install” या Rust compile command चला दूँ, तो मेरा computer तुरंत hacker के हाथ में जा सकता है। या company के किसी एक colleague का PC hack हो जाए और malicious code repository में चला जाए, तो आखिरकार पूरा global enterprise किसी foreign hacker के कब्ज़े में जा सकता है। ऐसी संरचना npm और Rust compiler ने बनाई है। ऐसे tools को हर external command execution पर explicit confirmation माँगनी चाहिए (हालाँकि allowlist cache करके बार-बार पूछने से बचा जा सकता है)। Linux को भी ऐसा secure sandbox देना चाहिए जिसे developers आसानी से इस्तेमाल कर सकें, लेकिन अभी तो सब कुछ खुद बनाना पड़ता है। ऊपर से, कुछ कामों में जैसे JS package install, कई बार external code execution की ज़रूरत ही नहीं होती। और secrets व configuration को environment variables में रखना सच में बहुत बुरा तरीका है। "12-factor app" बनाने वाले लोगों को शायद पता ही नहीं कि command-line switches या config files जैसी चीज़ें भी होती हैं

    • हमेशा याद रखना चाहिए कि repository पर code analyzers/builders/linters चलाना, source code को सीधे चलाने से बिल्कुल भी ज़्यादा सुरक्षित नहीं है
    • Rust compiler (और LLVM-based compilers) में arbitrary code execution vulnerabilities मानकर चलना सुरक्षित है। लेकिन औपचारिक रूप से यह feature सिर्फ build system cargo से जुड़ा है, rustc (actual compiler) से नहीं
    • अगर environment variables की जगह command line/config files इस्तेमाल करें, तो values process table में expose हो जाती हैं। सिर्फ "ps" command चलाने पर सब दिख सकता है
    • यह विचार मज़ेदार है कि "ऐसा कीमती code भी हो सकता है जिसे कभी चलाया ही न जाए"
    • "हर external command execution पर explicit confirmation" वाला तरीका बेकार है। समस्या external commands नहीं, बल्कि arbitrary code execution ही है। ऐसे code के पास सभी system APIs और syscalls तक access हो सकता है, इसलिए confirmation से कुछ नहीं होगा। Python/pip में भी यही समस्या है, इसलिए अब बहुत देर हो चुकी है

  • environment variable में वह permission key (private key) रखना, जिससे कोई भी "मनचाहा GitHub app" बन सके, सच में सबसे खराब practice है। किसी का भी system compromise हो सकता है, लेकिन यह secret management का सबसे बुनियादी सिद्धांत है। GitHub की official documentation में भी साफ लिखा है कि private key को environment variables में नहीं रखना चाहिए। यह सच में बिल्कुल basic बात है
    https://docs.github.com/en/apps/creating-github-apps/authenticating-with-a-github-app/managing-private-keys-for-github-apps#storing-private-keys

    • अगर secret signing के लिए नहीं है, तो अंततः उसे vault से app तक लाना ही पड़ता है, इसलिए production system तक access होना लगभग उस secret तक access होने जैसा ही है। बेशक, untrusted code execution वाले scenario में environment isolate करना चाहिए था और ऐसी keys pass नहीं करनी चाहिए थीं, लेकिन आमतौर पर यह uncommon case होता है
    • मैं CodeRabbit का Howon हूँ। हम app secrets के लिए cloud provider का key vault इस्तेमाल करते हैं, और इसमें GH private key भी शामिल है

  • जैसे ही मैंने यह पढ़ा कि Rubocop config file से external Ruby file path specify किया जा सकता है, मेरे मन में तुरंत आया, "कहीं इन्होंने user extension tools सीधे production environment में तो नहीं चला दिए...?" और वही सच निकला। बेशक, सिर्फ यह एक छेद बंद कर देने से system सच में सुरक्षित नहीं हो जाता। ज़्यादातर linters शायद hostile input पर audited या fuzzed भी नहीं होते होंगे; यह तो बस दरवाज़ा खुला छोड़कर “hack me!” का neon sign जला देने जैसा है

    • CEO के official response में जो हिस्सा है — “Rubocop sandbox के बाहर चल रहा था” — उसे देखकर लगता है कि शायद वही असली जड़ समस्या नहीं है