2023 के Thanksgiving पर Cloudflare सुरक्षा घटना

 (blog.cloudflare.com)
1 पॉइंट द्वारा GN⁺ 2024-02-02 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Cloudflare ने घोषणा की कि 23 नवंबर 2023 को उसके self-hosted Atlassian server पर एक threat actor का पता चला, लेकिन customer data, customer systems, global network systems और configurations प्रभावित नहीं हुए
  • घुसपैठ का रास्ता 2023 के अक्टूबर Okta breach के बाद rotate न किए गए 1 access token और 3 service account credentials थे, और access मुख्य रूप से Jira, Confluence, Bitbucket जैसे Atlassian environment पर केंद्रित था
  • threat actor ने 14 से 17 नवंबर के बीच reconnaissance और internal documents तक access किया, फिर 22 नवंबर को ScriptRunner for Jira के ज़रिए Sliver इंस्टॉल कर persistent access हासिल किया
  • Cloudflare ने “Code Red” response के तहत 5,000 से अधिक production credentials rotate किए, 4,893 systems की forensic screening की, और global network की सभी machines तथा Atlassian products को reimage और reboot किया
  • CrowdStrike की independent investigation में भी कोई छूटी हुई activity नहीं मिली, और आखिरी threat activity का सबूत 24 नवंबर 2023 10:44 UTC पर पुष्टि किया गया

घटना का सार और प्रभाव का दायरा

  • Cloudflare ने 23 नवंबर 2023 को अपने self-hosted Atlassian server पर एक threat actor का पता लगाया
    • security team ने तुरंत जांच शुरू की और access block कर दिया
    • 26 नवंबर को CrowdStrike forensic team को बुलाकर independent analysis कराया गया
  • इस घटना से customer data या customer systems प्रभावित नहीं हुए
    • services इसमें शामिल नहीं थीं
    • global network systems या configuration changes भी नहीं हुए
    • access controls, firewall rules, और उसके अपने Zero Trust tools द्वारा enforce की गई hardware security keys ने lateral movement को सीमित किया
  • threat actor की पहुंच internal wiki Atlassian Confluence, bug database Jira, source code management system Bitbucket, और उन servers तक सीमित थी जिन पर Atlassian चल रहा था

घुसपैठ में इस्तेमाल किए गए credentials

  • घुसपैठ 2023 के अक्टूबर Okta breach के बाद लीक हुए लेकिन rotate न किए गए 1 service token और 3 service accounts से शुरू हुई
    • Moveworks service token: Atlassian systems तक remote access के लिए इस्तेमाल हुआ
    • Smartsheet service account: Atlassian Jira instance पर admin privileges थे
    • Bitbucket service account: source code management system access के लिए इस्तेमाल हुआ
    • AWS environment account: global network, customer data, या sensitive data तक access permission नहीं थी
  • इन token और accounts को गलती से unused माना गया, इसलिए rotation के दायरे से बाहर रह गए
  • Cloudflare ने स्पष्ट किया कि यह समस्या Atlassian, AWS, Moveworks, या Smartsheet की गलती नहीं थी, बल्कि Cloudflare द्वारा credentials rotate न कर पाने का परिणाम थी

हमले की timeline

  • 14 नवंबर 09:22:49 से threat actor ने system exploration और reconnaissance शुरू की
    • Okta instance login attempts reject कर दिए गए
    • Cloudflare Dashboard तक पहुंच भी block कर दी गई
    • Cloudflare Apps marketplace चलाने वाले AWS environment तक पहुंच मिली, लेकिन यह environment global network और customer data से अलग था
  • 15 नवंबर 16:28:38 पर Atlassian Jira और Confluence तक access सफल हुआ
    • Moveworks service token से gateway पार किया गया और Smartsheet service account से Atlassian suite तक पहुंच मिली
    • wiki में remote access, secret, client-secret, openconnect, cloudflared, token आदि खोजे गए
    • 2,059,357 Jira tickets में से 36 और 194,100 wiki pages में से 202 तक access किया गया
    • accessed Jira tickets में vulnerability management, secret rotation, MFA bypass, network access, और Okta incident response से जुड़े items शामिल थे
  • 16 नवंबर 14:36:37 पर Smartsheet credentials से एक Atlassian account बनाया गया जो एक सामान्य Cloudflare user जैसा दिखता था, और उसे कई groups में जोड़ा गया
    • यह कदम Smartsheet service account हटाए जाने के बाद भी Atlassian environment तक पहुंच बनाए रखने के लिए था
  • 17 नवंबर 14:33:52 से 20 नवंबर 09:26:53 तक, छोटे access tests को छोड़कर Cloudflare systems तक पहुंच रुक गई
  • 22 नवंबर 14:18:22 पर Smartsheet service account के Jira admin privileges का इस्तेमाल करके ScriptRunner for Jira plugin से Sliver Adversary Emulation Framework इंस्टॉल किया गया
    • Sliver एक tool और framework है जिसका इस्तेमाल red teams और attackers C2, connectivity, और persistent व stealthy access के लिए करते हैं
    • इसके ज़रिए Atlassian server पर persistent access बनाए रखने और lateral movement की कोशिश की गई
    • Brazil के São Paulo में स्थित उस data center के non-production console server तक पहुंचने की कोशिश विफल रही, जो अभी production में नहीं था

source code और documents तक access

  • threat actor ने 22 नवंबर के बाद एक दिन के दौरान 11,904 repositories में से 120 code repositories देखीं
    • इनमें से 76 repositories को Atlassian Bitbucket की git archive feature का उपयोग करके Atlassian server पर download किया गया
    • Cloudflare यह पुष्टि नहीं कर सका कि बाहरी exfiltration हुई या नहीं, लेकिन उसने इन्हें leaked मानकर response किया
  • ये 76 repositories मुख्य रूप से निम्न क्षेत्रों से संबंधित थीं
    • backups कैसे काम करते हैं
    • global network configuration और management
    • Cloudflare की ID systems
    • remote access
    • Terraform और Kubernetes का उपयोग
  • कुछ repositories में encrypted secrets थे, और Cloudflare ने उन्हें मजबूत encryption होने के बावजूद तुरंत rotate किया
  • Cloudflare ने source code से अधिक कोड में मौजूद embedded secrets, vulnerabilities, और उन paths पर ध्यान केंद्रित किया जिन्हें आगे के हमलों में इस्तेमाल किया जा सकता था
    • Cloudflare ने बताया कि वह पहले से अपने काफी source code को open source के रूप में जारी करता रहा है, और अपने blog में उपयोग किए जाने वाले algorithms और techniques को सार्वजनिक रूप से बताता रहा है

detection और containment

  • 23 नवंबर 16:00 पर security team को threat actor की मौजूदगी के बारे में alert मिला
    • 15:58: threat actor ने Smartsheet service account को admin group में जोड़ा
    • 16:00: इस बदलाव का automated alert security team तक पहुंचा
    • 16:12: Cloudflare SOC ने जांच शुरू की
    • 16:35: Smartsheet service account disable किया गया
    • 17:23: threat actor द्वारा बनाया गया Atlassian user account मिला और disable किया गया
    • 17:43: internal Cloudflare incident घोषित किया गया
    • 21:31: threat actor के known IP addresses को block करने वाला firewall rule लागू किया गया
  • 24 नवंबर को आखिरी activity और Sliver removal की पुष्टि हुई
    • 10:44: आखिरी ज्ञात threat actor activity
    • 11:59: Sliver हटाया गया
  • threat actor ने internal metrics, network settings, build systems, notification systems, release management systems सहित कई systems तक पहुंचने की कोशिश की, लेकिन सफल नहीं हुआ
  • global network, data centers, SSL keys, customer databases या configuration information, Cloudflare Workers, AI models, network infrastructure, Workers KV, R2, Quicksilver जैसे data stores तक access के कोई सबूत नहीं मिले

“Code Red” response और hardening work

  • Cloudflare ने 24 नवंबर को threat actor को environment से हटाने के बाद intrusion investigation और access scope की पुष्टि के लिए कंपनी-भर के लोगों को लगाया
  • 27 नवंबर से security team के अंदर और बाहर के कई technical staff ने Code Red project पर ध्यान केंद्रित किया
    • future intrusions की तैयारी के लिए environment controls को मजबूत, verify और fix किया गया
    • यह verify किया गया कि threat actor की ongoing access न हो
    • सभी systems, accounts, और logs की जांच कर persistent access, actual access और attempted targets की पुष्टि की गई
  • मुख्य कदम इस प्रकार थे
    • 5,000 से अधिक production credentials rotate किए गए
    • test और staging systems का physical separation
    • 4,893 systems की forensic screening
    • global network की सभी machines का reimage और reboot
    • Jira, Confluence, Bitbucket सहित सभी Atlassian products का reimage और reboot
  • São Paulo data center के उपकरण manufacturer को वापस भेजे गए
    • manufacturer forensic team ने access या persistence हासिल होने की जांच की
    • कुछ नहीं मिला, फिर भी Cloudflare ने hardware बदल दिया
  • इसके अलावा outdated software packages, बनाए गए हो सकने वाले user accounts, unused active employee accounts, Jira tickets या source code में रह गए secrets, और wiki पर upload की गई HAR files की जांच की गई
    • HAR files को इस आशंका में delete किया गया कि उनमें tokens हो सकते हैं
  • तात्कालिक Code Red work 5 जनवरी 2024 को समाप्त हो गया, लेकिन credential management, software hardening, vulnerability management, और alerts में अतिरिक्त सुधार का काम जारी है

CrowdStrike investigation और IOCs

  • CrowdStrike ने threat actor activity की सीमा और persistence के evidence का independent assessment किया
    • Cloudflare investigation से छूटी कोई activity नहीं मिली
    • आखिरी threat activity का evidence 24 नवंबर 2023 10:44 UTC पर conclude किया गया
  • Cloudflare ने industry और government peers के साथ सहयोग के आधार पर निष्कर्ष निकाला कि यह हमला Cloudflare global network तक persistent और व्यापक access हासिल करने की कोशिश करने वाले state-sponsored attacker द्वारा किया गया था
  • Cloudflare ने compromise indicators प्रकाशित किए ताकि Okta breach से प्रभावित हो सकने वाले अन्य organizations अपने logs की जांच कर सकें
    • 193.142.58[.]126: मुख्य threat actor infrastructure, M247 Europe SRL के स्वामित्व में
    • 198.244.174[.]214: Sliver C2 server, OVH SAS के स्वामित्व में
    • idowall[.]com: Sliver payload delivery infrastructure
    • jvm-agent: Sliver payload filename, SHA256 bdd1a085d651082ad567b03e5186d1d46d822bb7794157ab8cce95d850a3caaf

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

1 टिप्पणियां

 
GN⁺ 2024-02-02
Hacker News की राय

  • Cloudflare का यह public analysis और response ही वह वजह है जिसकी वजह से मुझे लगता है कि मैं अपना डेटा और बिज़नेस उस पर भरोसे से छोड़ सकता हूँ
    यह परफेक्ट नहीं है और कुछ बातों से मैं सहमत भी नहीं हूँ, लेकिन कंपनी भर में साझा engineering mindset और इस तरह की घटनाओं को गंभीरता से लेने का रवैया इसे भरोसेमंद बनाता है

    • तो फिर विज्ञापन सफल रहा
      वे इस बात पर ज़ोर दे रहे हैं कि उनकी integrity competitors से बेहतर है, और हाल की security incident के बाद कुछ operational investigations साझा कर रहे हैं
      लेकिन Cloudflare PCI/DSS payment card processor के रूप में SOC risk analysis नहीं देता, न ही यह बताता है कि elevated privilege वाले accounts क्यों छूट गए या वे accounts शुरू में compromise कैसे हुए। जवाबदेही से ज़्यादा remediation समझाई गई है
      वे third-party audit का ज़िक्र करते हैं, लेकिन वह users के लिए नहीं, बल्कि इसलिए है क्योंकि PCI/DSS payment card जानकारी compromise होने वाले संगठनों पर हर साल on-site audit अनिवार्य करता है। नहीं तो major card companies payment processing बंद कर देतीं
    • कोई भी कंपनी परफेक्ट नहीं होती, लेकिन Cloudflare निश्चित रूप से भरोसा देता है। खासकर यह अच्छा लगता है कि वे समस्या और उसके समाधान की प्रक्रिया छिपाते नहीं हैं, और मुझे लगता है कि ऐसी व्याख्याएँ ही दिखाती हैं कि वे किसी भी चुनौती से पार पा सकते हैं
    • हम Cloudflare के काफ़ी बड़े enterprise customer हैं, और इस तरह की प्रतिक्रिया की वजह से renewal approval लेना आसान हो जाता है। engineers को लगातार sharing list में शामिल रखना internal persuasion में बहुत मदद करता है
    • क्या सच में कोई मानता है कि attacker ने KB और tickets तक पहुँच कर भी valuable information हासिल नहीं की? अगर आपको पता है कि Jira किस काम आता है, और आप उसे on-premise चलाते हैं, तो इसका मतलब है कि वहाँ कुछ ऐसा है जिसे स्टोर करना क़ीमती है
      यह मानना मुश्किल है कि कुछ भी नहीं खोया, और मैंने जितने भी Jira/Confluence देखे हैं उनमें secrets भरे पड़े थे
    • Cloudflare के CEO को नापसंद आने वाली बातें मत कहो, बस उनकी good side में बने रहने की कोशिश करो

  • “हमने जिन wiki pages, bug database issues और source code repositories को access किया गया था उनका analysis किया, उससे लगता है कि वे global network की architecture, security और management से जुड़ी जानकारी ढूँढ़ रहे थे” — इसे देखकर लगता है कि किसी nation-state actor के लिए सबसे आसान तरीका है अपने वफ़ादार नागरिक को target company में employee बनवाना और उससे वह जानकारी भिजवाना
    एक दिलचस्प, हालांकि सत्यता अनिश्चित, किस्सा यह है कि 10 साल से भी पहले Google के SRE social gathering में कुछ लोगों ने माना था कि वे अपने देश की intelligence agencies से salary पाते हैं

    • क्या वे लोग Google की सहमति से government liaison work कर रहे थे, और यह रिश्ता आपस में खुले तौर पर बताने लायक था?
      अगर नहीं, तो सोचता हूँ उस gathering में कितनी तगड़ी drugs चल रही थीं कि इतनी भयानक operational security failure हो गई
    • salary मिलती है? तुम लोगों को पैसे भी मिलते हैं?
      ऑस्ट्रेलियाई लोगों को तो ऐसे जासूसी कामों में हिस्सा लेने का “मौक़ा” लगभग citizenship की बुनियादी शर्त की तरह मिलता है https://en.wikipedia.org/wiki/Mass_surveillance_in_Australia...
      फ़ायदा इतना हो सकता है कि zero trust procedures और system development में अच्छी practices लागू करवाने में मदद मिले
    • बिल्कुल। खासकर अगर यह कोई अमेरिकी कंपनी हो तो और भी ज़्यादा। जब चाबी भी है और अनुमति भी, तो ताला तोड़ने की क्या ज़रूरत?
    • अगर वह नागरिक sanctions list में हो, तो नहीं। Code Red. यही संकेत है

  • “हम Okta system compromise के दूसरी बार शिकार बने” — यह पढ़कर जिज्ञासा होती है कि क्या Cloudflare Okta के इस्तेमाल पर पुनर्विचार कर रहा है

    • यह मामला Okta की एक और नाकामी से ज़्यादा, उस credential leak से जुड़ा लगता है जो मूल Okta breach में हुआ था और जिसे Cloudflare rotate नहीं कर पाया
      Okta आलोचना का हकदार है, लेकिन यहाँ थोड़ा ऐसा लगता है जैसे Cloudflare अपनी गलती छिपाने के लिए ज़िम्मेदारी नीचे की ओर धकेल रहा हो
    • हमारी कंपनी सिर्फ़ वही नए laptops देती है जिनमें Okta management system पहले से install होता है
      मैं अब भी शुरुआती दिनों में मिला पुराना MacBook इस्तेमाल कर रहा हूँ, इसलिए उसमें कोई management software नहीं है। उस समय IT टीम थी ही नहीं, बस untouched नया laptop दे दिया गया था
      कंपनी ने M1/M2 Pro में upgrade देने की पेशकश की, लेकिन मैंने मना कर दिया क्योंकि अगर work computer में मेरा एक भी personal password या key है, तो मैं Okta login system इस्तेमाल नहीं करना चाहता
      इसलिए जब तक काम में बड़ी दिक्कत न हो, मैं upgrade नहीं कर सकता। शायद मैं इस incident को IT department के सामने अपने तर्क के समर्थन में इस्तेमाल कर सकूँ
    • असली समस्या यह है कि Cloudflare की requirements संभाल सकने वाला alternative है कौन। अगला कदम in-house build होगा, और वह स्वाभाविक रूप से बहुत कठिन विकल्प है

  • “एक service token और तीन accounts को इस्तेमाल में नहीं माना गया, इसलिए उन्हें rotate नहीं किया गया” — यह अजीब लगता है। अगर वे इस्तेमाल में नहीं थे, तो उन्हें सीधा revoke क्यों नहीं कर दिया गया?
    ज़रूर कुछ छूटा है या संप्रेषण में गुम हो गया है, लेकिन वाक्य को ज्यों का त्यों पढ़ने पर बात समझना मुश्किल है

    • यहाँ “माना गया” शायद किसी व्यक्ति के सक्रिय निर्णय से ज़्यादा configuration state जैसा अर्थ देता है
      उदाहरण के लिए, database में कहीं उस service account पर “retired” या “cleaned up” जैसी inactive status लगी हो सकती थी, लेकिन वह label ग़लत निकला। इसलिए active accounts के passwords तो rotate कर दिए गए, लेकिन inactive accounts छोड़ दिए गए
      जहाँ तक मेरी जानकारी वाले public key infrastructure और certificate revocation के संदर्भ की बात है, certificate को expire होने देना, उसे “अब उपयोग में नहीं” चिह्नित करना, और उसे पूरी तरह revoke करना — ये काफ़ी अलग बातें हैं। certificate authority को पहले मामले में कुछ करने की ज़रूरत नहीं, दूसरे में कुछ न करे या revoke करे, और तीसरे में revocation list को सक्रिय रूप से बनाए रखना और वितरित करना पड़ता है। अगर कोई कहे कि “मैंने private key गलती से overwrite कर दी, नई key के लिए certificate दे दो”, तो आमतौर पर पुराना certificate revocation list में नहीं डाला जाता
    • संभव है यह blameless postmortem हो
      यह साफ़ लिखना कि “यह AWS, Moveworks, Smartsheet की गलती बिल्कुल नहीं है, यह सिर्फ़ वह credential है जिसे हम rotate नहीं कर पाए” — अच्छी बात है
    • शायद rotation manual था और ज़िम्मेदार व्यक्ति समय बचाने की कोशिश कर रहा था। stress का असर भी रहा हो सकता है
    • अब incident response runbook में एक नया item जुड़ गया होगा :-)

  • Cloudflare का मानना था कि हमलावर की पहुंच सीमित थी, और बाद में इसकी पुष्टि भी हुई, फिर भी उसने 5,000 से अधिक production credentials सभी rotate किए, test·staging systems को physical रूप से अलग किया, 4,893 systems की forensic जांच की, और global network की सभी machines को reimage·reboot किया
    अभी production में शामिल भी न किए गए São Paulo data center के console server तक पहुंचने की कोशिश भी नाकाम रही, लेकिन ब्राज़ील data center के उपकरणों को forensic जांच के लिए vendor के पास वापस भेजा गया, और कुछ भी न मिलने पर भी hardware बदल दिया गया
    इतना सब करना ज़रूरी नहीं था, और न करना आसान भी होता, लेकिन वास्तव में यह किया गया — यह तारीफ़ के लायक है

    • बल्कि मुझे लगता है कि इतना करना ज़रूरी था
      नए data center के शुरुआती चरण में घुसपैठ करना लगभग ultimate exploit है। बस यह कल्पना करें कि कोई नए Meet-Me room(https://en.wikipedia.org/wiki/Meet-me_room) के ठीक बीच में पहुंच जाए और core switch पर persistent access हासिल कर ले
      Cloudflare data centers अक्सर बहुत बड़े data traffic hubs होते हैं। यह तथ्य कि हमलावर “production से पहले” वाले data center की value समझता था, शायद यह दिखाता है कि Cloudflare भी समझता था कि अगर वहां regular security व्यवस्था बनने से पहले foothold बन गया, तो 100% game over है। अगर कोई build-up·bring-up के दौरान data center के अंदर जमने में सफल हो जाए, तो यह कंपनी-खत्म कर देने वाली घटना हो सकती है
      यह भी याद रखना चाहिए कि data center निर्माण के शुरुआती दौर में सभी switches और equipment default या खाली root passwords (admin/admin) इस्तेमाल करते हैं, और firmware भी पुराना होता है, इसलिए vulnerabilities बहुत होती हैं। अगर यह हमला automation के पूरे firmware को patch करने से पहले हुआ हो, तो यह “सारा equipment वापस करो और vendor से नया भिजवाओ” स्तर की घटना है
    • “Vendor की forensic team ने सभी systems की जांच की और पुष्टि की कि कोई access या persistence नहीं थी। कुछ नहीं मिला, फिर भी hardware बदल दिया गया” — अरे, यह तो पुराना trusted hardware replacement trick है
    • मैंने बहुत ज़्यादा DEFCON talks नहीं देखी हैं, लेकिन मुझे लगता है कि कम-से-कम इतना तो करना ही चाहिए था
    • compromise पर nuclear-grade response standard business practice होनी चाहिए, और उससे कम करना अपवाद होना चाहिए
      अगर आप मान लें कि हमलावर सिर्फ वहीं तक पहुंचा जहां तक पहुंच साबित की जा सकती है, तो आप उसके बच निकलने की जगह छोड़ रहे हैं। यह न करने का फैसला लेने के लिए कई लोगों की quorum approval चाहिए होनी चाहिए
      बेशक, यह एक आदर्श दुनिया की बात है। मुझे तो यह भी सौभाग्य लगता है कि हमारी team को ऐसे features implement करने का समय मिलता है जिनका सीधा monetary·user benefit नहीं होता
    • इसी वजह से पुराने security ops·corporate security लोग tabletop exercises को लेकर इतने obsessed रहते हैं, और Twitter का BadThingsDaily† इतना शानदार है
      इस तरह के credential rotation को execute करने की तैयारी के लिए discipline और readiness चाहिए, और ईमानदारी से कहें तो ज़्यादातर teams यह investment नहीं करतीं। smart और resource-rich teams भी नहीं
      अगर Cloudflare security team यह तय कर सकती है कि सभी secrets rotate करने हैं और सभी machines को reimage करना है, और यह वाजिब समय में सचमुच हो भी जाए, तो यह काफ़ी प्रभावशाली है
      † https://twitter.com/badthingsdaily?lang=en

  • यहां सबसे चौंकाने वाली बात यह है कि Cloudflare Bitbucket इस्तेमाल करता है

    • इसमें चौंकने जैसा क्या है, समझ नहीं आता। यह पहले से इस्तेमाल हो रहे दूसरे Atlassian products के साथ अच्छी तरह integrate हो जाता है
    • यह Jira और दूसरे Atlassian tools के साथ integrate होता है, और आखिरकार यह भी बस एक Git server ही है
    • हो भी सकता है और नहीं भी। मुझे Bitbucket पसंद नहीं है, लेकिन काफ़ी बड़ी कंपनियां ऐसी हैं जो अपने business के किसी एक axis पर competitor के मालिकाने वाली service इस्तेमाल करने को लेकर चिंतित रहती हैं
    • मुझे जानना है कि Scriptrunner for Jira कितना powerful है। इसका security certification तो है, लेकिन यह कितना sandboxed है, पता नहीं
    • बहुत बड़ी कंपनियां Bitbucket का बहुत इस्तेमाल करती हैं। क्योंकि यह GitLab/GitHub की तुलना में काफ़ी ज़्यादा cost-effective है

  • एक बार data leak बाहर चला जाए, तो इस मामले में source code स्थायी रूप से बाहर ही माना जाएगा, और इस पर कोई नियंत्रण नहीं रहता कि उसे कौन ले जाता है
    incident के बाद आप जितनी चाहे hardening कर लें और उसके बारे में कितना भी कह लें, जिसे रोकना था वह तो हो चुका। गिरे हुए अंडे को वापस नहीं जोड़ा जा सकता

    • सहमत। मुझे लगता है कि यह Cloudflare के लिए काफ़ी बड़ी घटना है। खासकर अगर इसमें Confluence documents भी शामिल हों, तो उनमें future plans and designs, org charts, meeting notes होने की पूरी संभावना है
      पुराने code में और भी easter eggs मिल सकते हैं। लगभग हर कंपनी में undocumented backdoors होते हैं
      customer data leak इससे भी बदतर होता, लेकिन यह भी सच में अच्छा नहीं है
    • तो point क्या है?
    • अगले साल का source code इस साल के source code जैसा नहीं होगा
      अगले साल का customer data भी इस साल के customer data जैसा नहीं होगा

  • Atlassian के Confluence में built-in Apache Lucene search engine अकेले ही sensitive information leak करा सकता है, और इस तरह की पहुंच को track·identify करना बहुत मुश्किल हो सकता है
    अगर sensitive information पहले से ही search results page पर दिख रही हो, तो हमलावर को Confluence page खोलने की भी ज़रूरत नहीं होती

  • “एक service token और तीन accounts को गलती से इस्तेमाल में नहीं माना गया, इसलिए उन्हें rotate नहीं किया गया” — यह हिस्सा अजीब है। इस्तेमाल में न होने वाले credentials को rotate नहीं, शायद delete किया जाना चाहिए

    • इसमें कुछ गड़बड़ लगती है। मैं शायद देखता कि उन खास credentials को rotate न करने का फैसला किसने लिया
      “ये accounts क्या हैं?” “अरे, इस्तेमाल में नहीं हैं। logs में भी नहीं दिखते” “फिर भी rotate तो करना चाहिए” “नहीं, जिन random accounts के पास शायद compromise हो चुके पुराने credentials हैं, उन्हें ऐसे ही छोड़ देते हैं… वजह कुछ न कुछ होगी” — कुछ ऐसा?
    • सहमत। पूरा लेख “मैं पीड़ित हूं” जैसा पढ़ा जाता है, लेकिन snowball होकर बड़ी बनी एक अकेली गलती को स्वीकार नहीं करता

  • मेरा मानना है कि Okta incident के बाद leaked credentials को rotate कर देने के बाद, उनके ऊपर honeypot लगाकर यह इंतज़ार करना चाहिए था कि हमलावर क्या करते हैं
    honeypot का यह असर भी होता है कि पकड़े जाने के डर से हमलावर आगे बढ़ने की हिम्मत नहीं करता