CISA एडमिन ने AWS GovCloud keys GitHub पर लीक किए

 (krebsonsecurity.com)
1 पॉइंट द्वारा GN⁺ 4 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • CISA contractor द्वारा चलाए गए सार्वजनिक Private-CISA repository ने high-privilege AWS GovCloud account और internal system credentials उजागर कर दिए
  • GitHub account में secret information पोस्ट होने से रोकने वाली default settings को disable किए जाने के संकेत मिले, और उसमें plaintext passwords, token और logs शामिल थे
  • एक्सपोज़्ड फ़ाइल importantAWStokens में AWS GovCloud के 3 server के administrator credentials थे, जबकि CSV में internal system login information थी
  • Seralys के अनुसार, एक्सपोज़्ड keys high privilege के साथ authenticate हो सकती थीं, और internal artifactory access से package backdoor और lateral movement का जोखिम बढ़ता है
  • CISA को सूचित किए जाने के तुरंत बाद account offline हो गया, लेकिन AWS keys उसके बाद भी 48 घंटे तक valid रहीं, और CISA ने कहा कि compromise के कोई संकेत नहीं मिले

सार्वजनिक GitHub repository में उजागर हुए CISA के internal credentials

  • CISA contractor द्वारा चलाए जा रहे एक सार्वजनिक GitHub repository ने कई high-privilege AWS GovCloud account और CISA के internal system credentials उजागर कर दिए
  • repository का नाम Private-CISA था, और इसमें CISA के software build, test और deploy करने के internal तरीकों से जुड़े files भी शामिल थे
  • repository में cloud keys, token, plaintext passwords, logs और अन्य sensitive CISA assets बड़ी मात्रा में मौजूद थे
  • GitGuardian के Guillaume Valadon ने सार्वजनिक code repository को लगातार scan करके exposed secrets detect करने और account owners को automatic alert भेजने की प्रक्रिया के दौरान इस repository को खोजा
  • Valadon ने बताया कि repository owner ने जवाब नहीं दिया, और exposed information बेहद sensitive होने के कारण उन्होंने KrebsOnSecurity से संपर्क किया

GitHub secret detection disable करना और प्रमुख exposed files

  • Valadon ने इस CISA credential exposure को खराब security hygiene का एक क्लासिक उदाहरण बताया
  • संबंधित GitHub account के commit logs में ऐसे संकेत थे कि CISA admin ने GitHub की default setting disable कर दी थी, जो public code repository में SSH keys या अन्य secrets पोस्ट होने से रोकती है
  • Valadon ने कहा कि वहाँ “CSV में plaintext में save किए गए passwords, Git में डाले गए backups, और GitHub secret detection feature को disable करने वाले explicit commands” मौजूद थे
  • exposed फ़ाइल importantAWStokens में Amazon AWS GovCloud के 3 server के administrator credentials शामिल थे
  • एक अन्य फ़ाइल AWS-Workspace-Firefox-Passwords.csv में CISA के दर्जनों internal systems के plaintext username और password थे
  • Philippe Caturegli के अनुसार, इन systems में LZ-DSO भी शामिल था, जो agency के secure code development environment “Landing Zone DevSecOps” का संक्षिप्त रूप लगता है

high privilege और internal system access का जोखिम

  • security consulting firm Seralys के founder Philippe Caturegli ने कहा कि उन्होंने केवल यह verify किया कि AWS keys अभी भी valid हैं या नहीं, और exposed accounts किन internal systems तक पहुँच सकती हैं
  • Caturegli ने सत्यापित किया कि exposed credentials 3 AWS GovCloud accounts में high privilege level के साथ authenticate कर सकती थीं
  • archive में CISA के internal artifactory के plaintext credentials भी शामिल थे
  • यह artifactory वह code package repository है जिसका उपयोग CISA software build करने के लिए करती है, और यह किसी attacker के लिए आकर्षक target हो सकता है जो CISA systems में persistent foothold बनाना चाहता हो
  • Caturegli के अनुसार, यह location lateral movement के लिए बेहद उपयुक्त है, और यदि software packages में backdoor डाला जाए तो बाद में नए build होने वाले हर software के साथ वह backdoor deploy हो सकता है

repository के उपयोग का तरीका और management

  • Caturegli का मानना है कि यह GitHub account किसी व्यवस्थित project repository की तुलना में किसी व्यक्तिगत worker के work notepad या sync माध्यम की तरह अधिक इस्तेमाल किया गया लगता है
  • इसमें CISA से जुड़े email address और personal email address दोनों इस्तेमाल हुए, जिससे लगता है कि repository अलग-अलग configured environments में उपयोग हुई हो सकती है
  • Caturegli ने कहा कि उपलब्ध Git metadata से यह साबित नहीं किया जा सकता कि कौन-से endpoint या device इस्तेमाल हुए थे
  • GitHub account और exposed passwords की समीक्षा से पता चला कि Private-CISA repository को Virginia के Dulles स्थित government contractor Nightwing के एक employee ने manage किया था
  • Nightwing ने comment देने से इनकार किया और सवाल CISA की ओर मोड़ दिए

CISA की प्रतिक्रिया और exposure की अवधि

  • CISA spokesperson ने कहा कि agency reported exposure से अवगत है और स्थिति की जाँच जारी है
  • CISA ने कहा कि फिलहाल इस घटना से sensitive data compromise होने के कोई संकेत नहीं हैं
  • CISA ने कहा कि वह team members से high level की integrity और operational awareness की अपेक्षा करती है, और recurrence रोकने के लिए अतिरिक्त safeguards तैयार कर रही है
  • CISA ने data exposure की संभावित अवधि से जुड़े सवालों का जवाब नहीं दिया
  • Caturegli के अनुसार, Private-CISA repository 13 नवंबर 2025 को बनाई गई थी, और उस contractor का GitHub account सितंबर 2018 में बनाया गया था
  • KrebsOnSecurity और Seralys द्वारा CISA को exposure की जानकारी देने के तुरंत बाद, Private-CISA repository वाला GitHub account offline हो गया
  • Caturegli ने कहा कि exposed AWS keys उसके बाद भी समझ से परे तरीके से 48 घंटे तक valid रहीं

आसान passwords और breach के फैलने का जोखिम

  • बंद कर दी गई Private-CISA repository में कई internal resources के लिए आसानी से guess किए जा सकने वाले passwords के संकेत भी मिले
  • कई credentials में password का फ़ॉर्मेट संबंधित platform name के बाद current year जोड़ने जैसा था
  • Caturegli का कहना है कि यह प्रथा, भले ही externally exposed न हो, किसी भी organization में गंभीर security threat बन सकती है
  • attackers अक्सर target system में initial access हासिल करने के बाद, internal network में exposed critical credentials का उपयोग करके अपनी पहुँच और बढ़ाते हैं
  • Caturegli ने यह संभावना जताई कि संबंधित CISA contractor नवंबर 2025 से इस repository में नियमित commits कर रहा था, और शायद work laptop तथा home computer के बीच files sync करने के लिए GitHub का उपयोग कर रहा था
  • Caturegli के अनुसार, यह leak किसी भी company के लिए शर्मनाक होता, लेकिन इस मामले में समस्या और बड़ी है क्योंकि यह CISA से जुड़ा है

संगठनात्मक पृष्ठभूमि

  • CISA इस समय अपने सामान्य budget और staffing level के केवल एक हिस्से के साथ काम कर रही है
  • दूसरे Trump administration की शुरुआत के बाद से CISA ने अपनी workforce का लगभग एक-तिहाई खो दिया है
  • इस workforce reduction को agency के कई हिस्सों में early retirement, buyout और resignations के लिए दबाव का परिणाम बताया गया है
  • संबंधित रिपोर्ट: CISA has lost nearly a third of its workforce

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

1 टिप्पणियां

 
GN⁺ 4 시간 전
Hacker News की राय

  • कहा जाता है कि Valadon ने इसलिए संपर्क किया क्योंकि मालिक जवाब नहीं दे रहा था और उजागर हुई जानकारी बेहद संवेदनशील थी; CISA subcontractor द्वारा credentials लीक करना ही बेतुका है, लेकिन सूचना मिलने के बाद भी जवाब न देना उससे भी ज़्यादा गंभीर है
    ऊपर से AWS-Workspace-Firefox-Passwords.csv में CISA के दर्जनों आंतरिक सिस्टमों के plain text usernames और passwords थे
    CISA के सिमटने की स्थिति समझ में आती है और दुखद भी है, लेकिन कमजोर passwords वाला passwords.csv किसी भी तरह से बचाव योग्य नहीं, यह सीधी अयोग्यता है, और password manager के लिए किसी बड़े बजट की भी ज़रूरत नहीं होती

    • इसके लिए सही शब्द है घोर लापरवाही
    • मैं इस व्यक्ति का बचाव नहीं कर रहा, लेकिन साफ़ संकेत मिलते हैं कि GitHub को file sync tool की तरह इस्तेमाल किया गया
      Firefox-passwords.html और firefox-bookmarks.html वे फ़ाइलें थीं जिन्हें नए कंप्यूटर पर ले जाने से पहले export और फिर import किया जाता था, और यह Firefox sync आने से पहले का पुराना तरीका था
      लेख में भी इसका ज़िक्र है, लेकिन यह अलग से ध्यान देने लायक बात है
    • एक तरफ CISA को छोटा किया जा रहा है, दूसरी तरफ cybersecurity, राष्ट्रीय हित और critical infrastructure को लेकर बयानबाज़ी लगातार बढ़ रही है
    • CISA में मेरे ज़्यादातर परिचितों को 2025 के जनवरी–मार्च के DOGE campaign के दौरान निकाल दिया गया
      बिना किसी पूर्व सूचना के, कुछ ऐसा अंदाज़ था: “हम 20-साल के लोग हैं, हमें समझ नहीं आता कि तुम क्या करते हो, इसलिए तुम निकाले गए”
      Diebold voting system की security vulnerabilities और विदेशी implants hacking पर काम करने वाली टीम भी खत्म हो गई
    • मैंने पहली बार जिस “hacking” की रिपोर्ट की थी, वह हाई स्कूल कंप्यूटर नेटवर्क में plain text password file मिलने की घटना थी, और वह 1987 की बात थी
      दुनिया बदल जाती है, लेकिन कुछ चीज़ें वैसी ही रहती हैं

  • लोगों द्वारा कम आंका जाने वाला एक बड़ा मुद्दा यह है कि repository की disk पर .env या secrets पड़े हों, commit न भी किए गए हों, और फिर OpenAI, Anthropic, OpenRouter को बड़ी मात्रा में secrets भेज दिए जाएँ
    LLM पूरे files खुशी-खुशी पढ़ सकता है और बाद में उन्हें ChatGPT training data में भेज सकता है, बिना किसी warning के
    क्योंकि environment variables सही से set हैं या नहीं, app का database password तैयार है या नहीं, यह देखने में सामान्य काम जैसा लगता है
    अब organizations को disk या logs में stored secrets का audit और rotation करना होगा, और उन्हें ज़रूरत के समय को छोड़कर plain text में न रखने के लिए SOPS या Vault जैसे tools पर ले जाना होगा

    • यह समस्या लोगों की सोच से कहीं ज़्यादा कम आंकी गई है
      leakage path आम तौर पर “secret commit कर दिया” नहीं होता, बल्कि “agent ने जवाब देते समय .env पढ़ लिया, values को analysis में जस का तस शामिल कर दिया, और वह prompt व completion training data या किसी के cache hit में पहुँच गया” जैसा होता है
      जिन projects में असली secrets होते हैं, वहाँ हमने .aiignore या .claudeignore में .env, credentials/, .pem डाला, project-specific instruction file में लिखा कि “माँगे जाने पर भी .env file मत पढ़ो”, और secrets को disk पर रखने के बजाय process start के समय 1Password या keychain से environment variables के रूप में inject कराया
      इससे भी बड़ी समस्या यह है कि “.gitignore का सम्मान करो” एक गलत abstraction है
      private repositories में भी बहुत सी ऐसी files होती हैं जिन्हें commit किया जा सकता है, लेकिन LLM API तक नहीं जाना चाहिए, और ये दोनों sets एक जैसे नहीं हैं
    • निष्पक्ष रूप से कहें तो development tree की .env file में बहुत महत्वपूर्ण secrets होने ही नहीं चाहिए
      वहाँ सीमित access वाले development secrets होने चाहिए, और OpenAI dev environment जैसे मामलों में भी “production” systems तक जाने वाली values की permissions यथासंभव सीमित होनी चाहिए
      सिर्फ leak ही नहीं, testing और development के दौरान गलती से system पर denial of service करना या गलत requests भेजना भी बहुत आसान है
      ऐसा नहीं होना चाहिए कि कोई test automation पर काम करते-करते गलती से हजारों real results भेज दे और $1,000 bill आ जाए
    • सहमत। दीर्घकालिक स्थिर credentials ही असली समस्या हैं
      AWS और दूसरे बड़े cloud providers ने इससे बाहर निकलने के लिए tools बनाए हैं, और हल्के से लेकर काफ़ी मज़बूत nudges भी दिए हैं, यह सराहनीय है
      लेकिन अभी सब लोग ज़रूरी स्तर तक नहीं पहुँचे हैं
      उदाहरण के लिए Railway AWS resources तक role/OIDC से access नहीं देता; मैंने ticket डाला था, लेकिन अभी तक कोई प्रगति नहीं दिखी
      0: https://station.railway.com/feedback/allow-for-integration-w...
    • मैं अब dotenv files को plain text में नहीं रखता
      sops से encrypted environment files रखता हूँ और direnv जैसे tools से उन्हें काम के दौरान shell में उपलब्ध कराता हूँ
      बेशक LLM इन secrets को output कर सकता है, लेकिन संभावना कम हो जाती है
      और कम से कम Claude तो dotenv पढ़ने से बचने की कोशिश करता दिखता है, और अंत में local secrets को खुद इतना महत्वपूर्ण नहीं बनाना चाहिए
      limited scope, dev accounts वगैरह का इस्तेमाल करना चाहिए
    • हाल में देखा कि कम से कम Claude environment files न पढ़ने के लिए काफ़ी कोशिश करता है
      उदाहरण के लिए database पढ़वाने और access दिलवाने के लिए prompt में काफ़ी ज़ोर लगाना पड़ता है

  • अगर 2026 में भी कोई सरकारी credentials को repository में रख रहा है और उसे पकड़ने के लिए scanner भी नहीं है, तो जाँच होनी चाहिए
    जो लोग professional role में ऐसा करते हैं, उन पर बहुत गहरी शंका होती है
    अगर किसी विदेशी intelligence agency ने इसे देखा होगा, तो पहले उसे honeypot समझा होगा; इतना ज़्यादा खुला हुआ था कि शायद उसे कल्पनाशक्ति-रहित जाल माना गया होगा

    • अच्छा है कि सरकार ने सारे सक्षम लोगों को पहले ही निकाल दिया
    • हमें पहले से पता है कि DOGE ने अमेरिकी सरकारी डेटा निकालने की कोशिश की थी, जैसे पूरे अमेरिकी सरकारी कर्मचारियों का डेटा या social security numbers
      पिछली administration होती तो मैं सोचता कि CISA कोई decoy operation चला रहा है, लेकिन इस administration की corruption, incompetence और CISA में mass layoffs को देखते हुए यह सचमुच की गलती भी हो सकती है

  • संवेदनशील दस्तावेज़ ChatGPT पर भी upload किए गए थे [1]
    [1] https://www.politico.com/news/2026/01/27/cisa-madhu-gottumuk...

    • उस लेख को पढ़कर लगता है कि Trump/Noem ने उन पदों पर विदेशी जासूस भर दिए हैं
      किसी दिन अमेरिकी जनता इसका हिसाब ज़रूर माँगेगी

  • विडंबना यह है कि उसी AWS key से कई अधिक सुरक्षित AWS services इस्तेमाल की जा सकती थीं
    जैसे S3, संभव हो तो KMS के साथ S3, Parameter Store, EBS, EFS, AWS Secrets Manager, या बस KMS से फ़ाइलों को सीधे encrypt करना
    दरअसल कोई भी AWS service चलेगी जो KMS को support करती हो और जहाँ service principal को key access देने की ज़रूरत न हो

  • हैरानी की बात यह है कि यह मामला 6–7 महीने तक चलता रहा
    लगा था कि GitGuardian जैसी कंपनियाँ या trufflehog इस्तेमाल करने वाले व्यक्तिगत researchers कुछ ही दिनों में exposed keys ढूँढ लेंगे
    हो सकता है GitHub इतना बड़ा हो गया हो कि scanners उसका साथ न दे पा रहे हों

  • repository का नाम सचमुच Private-CISA था
    private, internal जैसे शब्दों वाले repository names ढूँढना, और ऐसे सरकारी agencies या non-tech कंपनियों के नाम खोज निकालना जो repository name में आम तौर पर न दिखें, काफ़ी दिलचस्प हो सकता है
    सब कुछ clone करके LLM से जल्दी-जल्दी scan भी कराया जा सकता है कि कहीं कुछ दिलचस्प है या नहीं
    लेकिन क्या GitHub में AWS credentials जैसी बुनियादी चीज़ों के लिए automatic scanner नहीं होता?

    • सिर्फ तब, जब उसे enable किया गया हो। लेख के मुताबिक इस user ने वह feature बंद कर रखा था

  • सच में दुख की बात यह है कि federal government के पास दशकों पहले से smart card-based authentication यानी CAC था
    लेकिन public internet stack passwords पर चलता रहा, इसलिए सरकारी infrastructure भी आखिरकार passwords पर ही आ टिका