Electronic Arts के 70 करोड़ खातों की हैकिंग घटना

 (battleda.sh)
1 पॉइंट द्वारा GN⁺ 2024-11-06 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • EA authentication और gateway API के exposed Swagger docs तथा persona update permission validation failure के मेल से, दूसरे users के account data और login flow तक प्रभावित हो सकते थे
  • मुख्य बात यह थी कि /identity/pids/{pidId}/personas/{personaId} का PUT request सामान्य EA Desktop OAuth client के dp.client.default scope से access किया जा सकता था, और body के pidId तथा path के personaId के ownership check में कमी थी
  • हमलावर persona username बदलने, BANNED status सेट करने, persona move करने, hidden account persona ID खोजने, और Xbox persona-based login bypass को मिलाकर account web login तक पहुँच सकता था
  • प्रभाव के दायरे में username और कुछ game data की चोरी, online game access block, game ban bypass, और Xbox के जरिए EA account login तक शामिल थे; severity CVSS 10.0 आंकी गई
  • vulnerability 16 जून 2024 को EA को report की गई, और EA ने 25 जून को इसे critical classify करने के बाद 8 जुलाई से 8 अक्टूबर तक persona ownership check और docs removal समेत patches deploy किए

EA authentication environment से शुरू हुआ API docs exposure

  • शुरुआत EA Desktop में मिले development environment integration test से हुई थी
    • production authentication API: accounts.ea.com
    • integration authentication host: accounts.int.ea.com
  • integration environment में privileged access token हासिल किया जा सकता था, और इस token से accessible APIs जाँचने के लिए exposed docs ढूँढना शुरू किया गया
  • authentication endpoints reverse proxy के पीछे थे; /connect path और सामान्य / path के 404 response format अलग थे, और server header istio-envoy था
  • /connect/api-docs ने अन्य /connect paths से अलग empty 404 return किया, जिससे अलग service routing की संभावना दिखी; /connect/api-docs/index.json पर Swagger 1.1 docs मिले
  • Swagger docs /api-docs/connect की ओर point कर रहे थे, जिन्हें swagger-codegen-cli से OpenAPI 3.0 spec में convert करके local Swagger UI में देखा गया

Gateway में सामने आई internal API list

  • EA Desktop “Service Aggregation Layer” नाम की GraphQL API इस्तेमाल करता है, लेकिन integration environment का SAL firewall के पीछे था
  • पुराने version जैसा दिखने वाला gateway.ea.com का gateway API proxy/{service}/{route} format के endpoints इस्तेमाल करता है
  • gateway.int.ea.com/proxy/api-docs/index.json ने 80 से अधिक service docs की list return की
    • इसमें addresses, agerequirements, billing, commerce जैसी कई services शामिल थीं
  • हर API doc download करके latest OpenAPI spec में convert किया गया, फिर accessible functions की जाँच की गई
  • कुछ endpoints ने EA game teams से जुड़े “projects” data return किए; इनके लिए basic.domaindata permission scope चाहिए था, और production में यह scope रखने वाला client भी मिला
    • example data में cancelled Star Wars game और Apex Legends को Titanfall3 related group name के साथ दिखाने वाले items थे
  • integration environment में custom game entitlement देने का तरीका भी documented था, लेकिन download और play के लिए जरूरी integration services firewall के पीछे थीं, इसलिए practical usefulness कम थी
  • Xbox Live Server Token return करने वाला endpoint भी था, लेकिन sandbox ID RETAIL नहीं था, इसलिए गहराई से investigate नहीं किया गया

Production account info और persona structure

  • docs के हर endpoint में required authentication scope दिखाया गया था, और verification मुख्य रूप से उन endpoints पर किया गया जिन्हें production OAuth client से access किया जा सकता था
  • /identity/pids/me account की general info return करता है
    • इसमें masked email value, email status, date of birth का हिस्सा, country, language, account status, terms version, creation/modification/last authentication time, 2FA enabled है या नहीं आदि शामिल थे
  • /identity/pids/me/personas account से जुड़ी persona list return करता है
    • default EA account cem_ea_id namespace इस्तेमाल करता है
    • Steam, Xbox जैसे connected external accounts भी अलग-अलग persona के रूप में दिखते हैं
  • Games आम तौर पर persona के नीचे statistics, inventory जैसे data store कर सकते हैं, इसलिए platform-specific data अलग रह सकता है
  • आगे cem_ea_id namespace की persona को “Origin” persona कहा गया

मुख्य vulnerability: persona update permission validation failure

  • /identity/pids/{pidId}/personas/{personaId} endpoint GET, PUT, DELETE requests accept करता है
  • PUT request ने dp.client.default और dp.server.default scopes allow किए, और सामान्य EA Desktop authentication client के पास dp.client.default था
  • request body displayName, namespaceName, status, statusReasonCode, lastAuthenticated, nickName, pidId आदि accept कर सकती थी
  • अपनी Origin persona के लिए displayName बदलने वाला PUT request सफल हुआ, और EA account website का username बदल गया
    • इस request ने username change cooldown और username change email verification को bypass किया
  • namespaceName change का कोई effect नहीं था
  • status value में ACTIVE, DISABLED, PENDING, DELETED, BANNED possible थे; अपनी Origin persona status को BANNED करने पर EA Desktop continue use किया जा सकता था, लेकिन game login block हो गया
  • बड़ा मुद्दा यह था कि request body का pidId किसी दूसरे account ID में बदला जा सकता था
    • अपनी Steam persona को friend के EA account में move करने वाला request successful रहा
    • बाद में उसे वापस अपने account में लौटाना भी possible था

Login verification और XSS attempt

  • अपनी Steam persona को friend account में move करने के बाद Steam से EA website login की कोशिश करने पर, new location और untrusted device based email verification दिखाई दिया
  • दिखाया गया partial email अपना नहीं था, यानी friend account में login flow तक पहुँचा गया, लेकिन location-based 2FA step पर रुक गया
  • persona username को BattleDash <script>alert(1)</script> रूप में बदलने वाला request भी successful रहा
  • account linking page पर alert execute हुआ, जिससे XSS possible था
    • यदि user EA account में logged in state में उस linking page पर redirect होता, तो browser में code execute करके session extract किया जा सकता था

दूसरे account persona की direct manipulation

  • path के personaId में भी ownership validation की कमी है या नहीं, यह जाँचने के लिए अपने ownership में न आने वाले persona ID पर username change try किया गया
  • नए test account का persona ID हासिल करने के बाद, victim account authentication के बिना उस account का username बदलने वाला request successful रहा
  • इसी तरीके से status को BANNED में बदला जा सकता था, और वह account game में login नहीं कर सका
  • /identity/personas displayName से persona search करता है और persona ID, account ID, creation date, last login time return करता है
    • हालांकि hidden account वाले users को नहीं दिखाता
  • /identity/namespaces/{namespace}/personas किसी specific namespace में search करता है, और सिर्फ username व persona ID return करता है, लेकिन hidden accounts भी return करता है
    • केवल इस endpoint से भी जरूरी persona ID मिल सकता था

Persona move की constraints और partial account takeover

  • दूसरे user की Origin persona को अपने account में move करने की कोशिश पर TOO_MANY_PERSONAS_FOR_NAMESPACE error आया
    • क्योंकि अपने account में पहले से Origin persona मौजूद थी
  • console से sign up किए account में केवल उस platform की persona हो सकती है और Origin persona नहीं हो सकती, ऐसा मानकर console account से namespace collision avoid किया गया
  • test account की Origin persona को console account में move करने के बाद, victim account की Origin persona को अपने account में move करना possible था
  • इस state में login करने पर victim का username, non-cross-platform game stats, और कुछ अन्य account details दिखाई दिए
  • victim account से login करने पर, जैसे नया account बनाया हो, username select करने को कहने वाला “Finish setting up my account” flow दिखाई दिया
  • Battlefield 2042 जैसे latest cross-platform games के entitlement, friends, saved data persona में नहीं बल्कि EA account itself में store थे, इसलिए transfer नहीं हुए
  • फिर भी attacker user ban, game ban bypass, username theft, और account data को hostage बनाना कर सकता था

Xbox persona से login bypass

  • existing state में possible actions थे: अपनी linked account persona को arbitrary EA account में move करना, arbitrary persona को अपने account में move करना, persona ban और username change
  • दूसरे user के account में login करने के लिए अपनी persona move करने पर email verification दिखाई देता था
  • console पर EA game खेलते समय 2FA prompt न देखने की बात से प्रेरित होकर Xbox/PSN token-based login की जाँच की गई
  • Nexus Connect API docs में Xbox/PSN token pass करने का तरीका था, और EA site के PSN login flow से PSN client ID लेकर PSN token login try किया गया
  • PSN token login ने ps3 namespace persona बनाई और 2FA के बिना account login possible था, लेकिन dp.client.default वाले client ps3 namespace handle नहीं कर सकते थे
  • /connect/tokeninfo में X-Include-Namespace header जोड़ने पर OAuth client के अनुसार manipulatable persona namespace list होने की पुष्टि हुई
    • example JUNO_PC_CLIENT में cem_ea_id, steam, epic, xbox namespaces शामिल थे
  • Xbox namespace allowed था, लेकिन manually game-valid Microsoft XSTS token नहीं बनाया जा सका, इसलिए actual Xbox पर test किया गया
  • नया Microsoft account बनाकर Xbox persona को test EA account से link किया गया, फिर उस Xbox persona को victim account में move किया गया
  • EA website पर Xbox account से login करने पर new location email verification आया, लेकिन Xbox पर Battlefield 2042 install करके game में login करने पर victim account में access हो गया
  • इसके बाद उसी Xbox account से EA website में login करने पर email verification के बिना victim account web login भी successful रहा

Impact scope और severity

  • attacker के लिए use करने लायक दो main paths थे
    • दूसरे व्यक्ति के persona data को account से बाहर move करके username और game data चुराना
    • अपनी Xbox persona को victim account में move करना, Xbox पर EA game में login करना, और network trusted होने के बाद Xbox account से EA website में login करना
  • additional impact भी बड़ा था
    • दूसरे person की persona को ban कर अधिकांश online games play करना रोक सकता था
    • दूसरे person का username बदलकर खुद ले सकता था
    • game ban account-wide game entitlement disable के रूप में process होता है, इसलिए persona को नए account में move करके game ban bypass किया जा सकता था
  • यह flow बिना user interaction के, मुख्यतः single API endpoint के जरिए possible था
  • severity AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H के आधार पर CVSS 10.0 आंकी गई

Fix timeline और follow-up comments

  • vulnerability 16 जून 2024 को EA को report की गई
  • EA ने 25 जून 2024 को acknowledgement भेजी और critical severity assign की
  • patch schedule इस प्रकार था
    • 8 जुलाई 2024: Patch 1 deployed, persona ownership check
    • 18 जुलाई 2024: Patch 2 deployed, details unknown
    • 6 सितंबर 2024: Patch 3 deployed, details unknown
    • 10 सितंबर 2024: Patch 4 deployed, docs removal
    • 8 अक्टूबर 2024: Patch 5 deployed, details unknown
  • EA का initial estimate था कि fix year-end तक लग सकता है, और exposed docs तथा single unsafe endpoint core issue होने के मामले में faster temporary patch बेहतर होता, ऐसा आकलन सामने आया
  • EA के पास अभी bug bounty program नहीं है, और यदि meaningful report reward न हो तो कुछ लोग vulnerabilities को private रख सकते हैं, ऐसी चिंता बनी हुई है
  • initial testing में इस्तेमाल friend account consent के साथ था

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

1 टिप्पणियां

 
GN⁺ 2024-11-06
Hacker News की राय

  • EA कई गेम्स में कॉमन सिस्टम इस्तेमाल करना पसंद करता है। Madden में खंगालते हुए पता चला कि blaze नाम का एक कॉमन बैकएंड है, और generic web/TCP endpoints भी हैं
    मैंने इस endpoint को call करने वाला tool बनाया था, जिसमें XML upload करना पड़ता था, और बाद में पता चला कि हर call पर EA का server crash हो रहा था
    हर request के लिए नया server allocate हो रहा था, इसलिए मैं Madden servers को एक-एक करके crash कर रहा था, और आखिरकार EA ने API बना दी ताकि लोग अंदर झांक-झांककर न देखें

    • Blaze online games के लिए custom backend बनाने का C++ framework/service का नाम है। यह game teams को online features standard तरीके से develop करने देता है, और पीछे MySQL support करता है
      याद पड़ता है कि हर 5,000–10,000 players पर करीब एक Blaze instance चाहिए होता था
    • मैं ही पोस्ट का लेखक हूं; पिछले साल मैंने अपने खोजे हुए ढेर सारे Blaze vulnerabilities पर एक लेख भी लिखा था, लेकिन उसे public नहीं किया
      लगता है वे अब proprietary format इस्तेमाल कर रहे थे और इस धारणा पर काफी आराम से बैठे थे कि कोई भी interface का तरीका नहीं निकाल पाएगा—यानी security through obscurity पर निर्भर सुरक्षा
      किसी दिन उस लेख पर वापस जाना चाहता हूं; कम से कम उसमें काफी मजेदार चीजें हैं
    • लगता है हाल ही में मैंने यह API किसी और game में देखी थी। GraphQL frontend ही है न? Introspection बंद था, लेकिन error messages गलत field name के लिए बड़े अच्छे से suggestions दे देते हैं
      ऐसी मशहूर services की API reverse engineer करते समय tip यह है कि GitHub code search इस्तेमाल करें। कोई unique endpoint name डालकर देखें; अक्सर ऐसे लोग मिल जाते हैं जिन्होंने खुद छोटा API client hack करके बनाया होता है, और वे मेरी जांच में ऐसे तरीकों से मदद करते हैं जिनके बारे में सोचा भी नहीं होता
    • PSN client ID के repeated values scan करते हुए EA gateway proxy में login की कोशिश करें, तो personal data से लिया गया namespacename value return होता है। 2FA token की जानकारी JUNO से आने वाले /tokeninfo/ endpoint में hash होनी चाहिए
      post-integration की कोशिश करने पर C++ API के लिए infrastructure अक्सर PSN user ID return कर देता था

  • किसी भी सामान्य इंसान की तरह जाहिर है मैंने next-day delivery से Xbox order किया, Battlefield 2042 install किया, फिर निर्णायक पल का इंतजार किया, और अंदर जा पाया
    hackers सच में कमाल होते हैं <3

  • एक point से दूसरे point तक कैसे पहुंचे, इसका detailed flow मजेदार था। यह blog post जैसा साफ-सुथरा linear तो शायद नहीं रहा होगा
    ऐसे attack में असल में कितना समय और मेहनत लगती है, यह दिखाने के लिए शायद notes का पहाड़ होगा; उसे देखना भी दिलचस्प होगा

  • इस पूरे मामले में सबसे अजीब बात यह है कि EA सालों से दावा करता रहा है कि existing Xbox account linking हटाकर नए account से फिर link करना technically impossible है। https://www.reddit.com/r/XboxGamePass/comments/12gsy4i/ea_xb... जैसी posts और EA forums की अनगिनत posts देख लें
    मैं भी इसी दीवार से टकराया था, और EA support के साथ कई घंटे call पर रहा, लेकिन वे मेरा बहुत पुराना Xbox account link नहीं कर पाए। इसलिए मैं Xbox पर किसी भी EA game में login नहीं कर सकता, और platform पर ज्यादातर games खेलना मेरे लिए बंद हो गया
    लेकिन यहां पता चला कि यह पूरी तरह संभव है

    • याद है 2004–2005 में मेरा Hotmail account सामान्य 4MB storage वाला था, और Microsoft सबको 250MB free upgrade roll out कर रहा था
      अजीब तरह से मेरे account में बहुत देर लगी, और 1–2 साल तक मैंने support team को कई बार mail किया, लेकिन हर बार जवाब मिला कि वे accounts को जितनी जल्दी हो सके upgrade कर रहे हैं, पर काम इतना बड़ा है कि इसमें कई साल लगेंगे
      बाद में किसी forum में एक workaround देखा कि account को थोड़ी देर के लिए बंद करके फिर खोलने से उसे 25MB तक बढ़ाया जा सकता है, हालांकि वादा किए गए 250MB तक नहीं
      existing accounts 2–4MB, नए accounts 25MB, और 250MB तक कई साल का rollout—इस हालत से लगा कि Microsoft spare storage ढूंढने में बहुत जूझ रहा है। लेकिन कुछ महीने बाद जब Gmail से compete करना पड़ा तो उन्होंने सबको 2GB देने का फैसला किया, और मेरे account समेत सभी Hotmail accounts पर यह एक साथ roll out हो गया। पक्का aliens hard disks से भरा UFO लेकर आए होंगे
      [1] उस workaround पर पुरानी forum post का उदाहरण, जिसमें नए GMail की तारीफ करते replies भी हैं: https://bimmersport.co.nz/topic/5232-hotmail-upgrade-2mb-to-...
    • यह attack दिखाता है कि linking बदलना और game play करना संभव है, लेकिन लेख में आसानी से verify किए गए scenario से बाहर कौन-से side effects होंगे, यह पता नहीं
      link change billing system में stored data को invalid कर सकता है, Microsoft Xbox division को जाने वाली monthly reports बिगाड़ सकता है, या internal admin page को load होते समय crash करा सकता है
      EA का बचाव करने की कोशिश नहीं कर रहा, लेकिन complex microservices systems से बहुत काम करने पर समझ आता है कि एक जगह की data structure बदलना हमेशा simple नहीं होता
    • शायद वे इसी समस्या को ठीक करने के लिए यह feature add कर रहे थे, लेकिन public release से पहले दुर्भाग्य से इसका दुरुपयोग हो गया
    • दुर्भाग्य से Battlefield 2042 जैसे modern cross-platform games में game entitlements, friends, save data persona में नहीं बल्कि EA account itself में store होते हैं, इसलिए वह data transfer नहीं होता
    • Technically impossible नहीं, शायद customer support team के लिए process करना impossible रहा होगा

  • सभी accounts को ban कर देना और उम्मीद करना कि DB backup न हो, यह भी शायद मज़ेदार होता

    • जिन भी 1 बिलियन डॉलर scale की कंपनियों के पास bug bounty program नहीं है, उन्हें ऐसा झेलते देखना चाहता हूँ। Vulnerability report करने पर अगर कोई reward नहीं है, तो यह hackers को अपने फायदे के लिए exploit करने या chaos मचाने के लिए उकसाने जैसा है
      Paying customer के तौर पर मैं इन कंपनियों से बेहतर attitude की उम्मीद करता हूँ, और अगर program नहीं है तो hackers जो खोजते हैं उसे exploit करें, तो निजी तौर पर मैं उन्हें दोष नहीं दूँगा
    • थोड़ी देर के लिए मज़ा आ सकता है, लेकिन उनके पास backup ज़रूर होगा
      400 मिलियन records को कोई single machine पर store नहीं करता, और अंत में बस service को पूरी दोपहर down करवाकर federal prison में 15 साल काटने पड़ेंगे
    • दुनिया ने tech industry से मुँह क्यों मोड़ लिया है, वजह ऐसी ही चीज़ें हैं
      लाखों लोगों को नुकसान पहुँचाकर उस company को सबक सिखाना जिससे वे deal कर रहे थे, यह “मज़ेदार होगा” — पहली reaction यही है, या कम-से-कम अभी top-rated comment यही है
    • सभी accounts पर सभी games activate करना कहीं ज़्यादा मज़ेदार होता। सचमुच सब कुछ। Imagination कम है
    • मैंने भी इस बारे में सोचा था। अगर report न करके सच में prank करने की ठान लेते तो क्या होता? क्या track हो जाते? क्या EA कई हफ्तों तक down रहता?

  • लेख में यह हिस्सा है:
    I had found a way to obtain a privileged access token within the environment (a story for another day, but a certain game's executable had hardcoded credentials!), but I wasn't sure what I could do with it.
    क्या कोई इस हिस्से को थोड़ा और समझा सकता है? मुझे लगता था कि executable binary से ऐसी credentials आसानी से पढ़ी नहीं जा सकनी चाहिए, और अगर game executable को remote server पर खुद को authenticate करना ही है, तो developer को अलग से क्या करना चाहिए यह भी साफ नहीं है

    • Credentials strings के रूप में store होते हैं, इसलिए binary में credential जैसी दिखने वाली patterns search करोगे तो वे कहीं न कहीं मिल जाएँगे
      Client-server architecture में client हमेशा भरोसेमंद नहीं होता। Executable को server पर खुद को authenticate करने की ज़रूरत नहीं होनी चाहिए। Executable को user द्वारा दी गई जानकारी से user या account के तौर पर authenticate करना चाहिए
      Telemetry जैसी चीज़ों में ऐसे endpoints आमतौर पर बिना authentication या weak authentication वाला data लेते हैं, और abuse रोकने के लिए कई levels की validation करते हैं। अक्सर वे write/add-only भी होते हैं
    • समझ नहीं आता कि binary को आसानी से पढ़ा नहीं जा सकेगा, यह assumption क्यों है। Unlocked platform पर binaries काफी पढ़ने योग्य होती हैं
      शायद आपको ऐसा system चाहिए होगा जिसमें executable encrypted हो और CPU die का secure area private key से decryption handle करे, लेकिन फिर भी किसी के chip को delid करके key हासिल कर लेने की बात शायद सिर्फ समय की होगी
    • अगर computer उसे पढ़ सकता है, और उस computer पर आपका पूरा control है, तो आप भी उसे पढ़ सकते हैं। Physical access हो तो खेल खत्म
      Encrypt करके encryption key को HSM में डाल भी दें, तो arbitrary client machine पर यह शायद संभव ही नहीं होगा, और किसी point पर game को उस string को decrypt करके memory में लाना ही पड़ेगा। और वह memory पढ़ी जा सकती है
    • अगर program credentials तक access कर सकता है और वह program मेरे computer पर चल रहा है, तो चाहे जिस तरह obfuscate किया जाए, मैं भी उन credentials तक access कर सकता हूँ
      Game developer को करना यह चाहिए कि backend में account system रखें, और player को game के अंदर अपनी credentials enter करने दें। फिर game backend server पर खुद को इस player के रूप में identify कर सकता है
      इससे backend पर actions को किसी specific player से जोड़ा जा सकता है, और security decisions लेने के लिए अच्छा आधार मिलता है
    • Executable binary में ऐसी credentials ढूँढना मुश्किल है, लेकिन नामुमकिन नहीं। Minified JavaScript file से strings निकालने से ज़्यादा झंझट है, लेकिन impossible से बहुत दूर है
      IDA जैसे tools हैं, इसलिए strings जैसी दिखने वाली हर चीज़ के बीच नंगी आँखों से credentials खोजनी नहीं पड़ती
      असली समस्या सिर्फ यह नहीं कि binary में hardcoded credentials हैं, बल्कि यह है कि उन credentials के पास privileged permissions हैं

  • ऐसी company के engineer के तौर पर कभी-कभी सोचता हूँ कि private APIs, अजीब bugs और गंदी internal details किसी public breach report में सामने आ जाएँ तो कैसा लगता होगा
    हालांकि ऐसे case में किसी एक individual के vulnerability के लिए जिम्मेदार होने की संभावना कम है। शायद 5–6 teams exploited हुए अलग-अलग हिस्सों की owner रही होंगी, और इसी वजह से exploit पहली जगह मौजूद था। यह एक विशाल और जटिल system है जहाँ हर कोई बस अपने छोटे हिस्से को समझता है

    • अगर आप team में emotionally, या सिर्फ financially ही सही, invested हैं तो बुरा लगता है, लेकिन जब मैं EA में था तो ऐसा लगता था कि वे emotional investment मुश्किल बनाने में लगभग effort लगा रहे हैं
      EA जितनी बड़ी company में यह लगभग पक्का है कि यह घटना internal politics में इस्तेमाल होगी, और भले ही इससे पूरी company को नुकसान हो, लोग इसे छोटी हो चुकी company पर ज़्यादा control हासिल करने के लिए इस्तेमाल करेंगे
    • इतनी बड़ी corporation में किसी को फर्क नहीं पड़ता। यह बस salary के लिए किया जाने वाला काम है
      जब हर कोई replaceable resource है, तो काम में emotionally invested क्यों होना
    • करीब 10 साल पहले शायद इसी team में, जो अभी भी यही exact code maintain कर रही है, काम कर चुके व्यक्ति के तौर पर मैंने post को जल्दी-जल्दी scan किया कि कहीं यह मेरा लिखा code या छुआ हुआ हिस्सा तो नहीं
      उस समय team का नाम Nucleus था, इसलिए post के responses में से एक में refType NUCLEUS था। यह team permissions, accounts और payments के लिए backend APIs बनाती और maintain करती थी
      वह summer internship थी, और एक साल बाद उस team से offer लेकर मैंने काम शुरू किया। तब तक team का नाम EADP हो गया था और वह धीरे-धीरे Origin के साथ merge हो रही थी। DP Data Platform था या नहीं, याद थोड़ा धुंधला है, लेकिन इसी वजह से endpoints में से एक dp. से शुरू होता है
      उस समय GraphQL database नहीं था; सब कुछ Enterprise Java, OCI, Spring, Hibernate वगैरह था, और मेरे जाने से पहले कुछ नया Groovy/SpringBoot भी था। Cloud नहीं, data center servers पर चलता था
      फिर भी मैंने मज़ेदार काम किया, और एक बड़े incident के 2–3 साल बाद छोड़ दिया, लेकिन अच्छे engineers से backend development बहुत सीखी
      अभी team कैसी है, engineers कौन हैं, क्या हो रहा है—मुझे बिल्कुल नहीं पता, लेकिन यह देखकर दुख होता है। उस समय हम security को लेकर बहुत conscious थे, और login page पर brute-force attempts detect और handle करने वाले systems पर भी काम किया था
      यह अभी active है या चल रहा है, नहीं जानता, लेकिन compromise की संभावना और attack surface कम करने के लिए security checks/reviews sprint work का हिस्सा थे
    • खासकर अगर मैं उस department में काम नहीं करता, इसलिए मेरे पास control नहीं है, लेकिन मुझे पता है कि मैं उस department से बेहतर कर सकता हूँ, तो बुरा लगता है
    • अगर मुझे पता हो कि मैंने वही API implement की थी, तो ऐसा post पढ़कर दिल धक से रह जाएगा

  • अगर आपको यह लेख रोचक लगा, तो HackerOne के Hacktivity जैसे bug bounty platforms पर ऐसी और चीज़ें देख सकते हैं: https://hackerone.com/hacktivity

    • यहां और भी बहुत कुछ है: https://pentester.land/writeups/
      हर कुछ हफ्तों या महीनों में अपडेट होता है

  • क्या bug bounty program सेट करने के लिए best practices guide कहीं उपलब्ध है?

    • मैं इसी क्षेत्र में काम करता/करती हूं, इसलिए यह समझना मुश्किल है कि कौन-सी जानकारी छूट रही है, लेकिन मुझे यह काफी सरल लगता है
      वेबसाइट पर कहीं यह प्रकाशित कर दें कि coordinated vulnerability disclosure प्रक्रिया का पालन करने की शर्त पर technical security जांची जा सकती है, और किस scope में किस तरह के bugs के लिए क्या rewards मिलेंगे, यह लिख दें। बेशक, इस एक वाक्य से थोड़ा अधिक विस्तार देना होगा
      अगर उम्र बहुत कम या बहुत ज्यादा है तो भुगतान नहीं करेंगे, या गलत देश में जन्म लेने की वजह से sanctions के दायरे में नहीं होना चाहिए—ऐसे exceptions भी पहले से लिख देना बेहतर है ताकि बाद में भावनाएं आहत न हों
      अगर कोई specific सवाल हो तो जवाब दे सकता/सकती हूं या अच्छे references ढूंढ सकता/सकती हूं

  • लेख के इस हिस्से को देखें:
    It's also disappointing that EA has yet to start a bug bounty program. Without any real incentive to report vulnerabilities, I know people who have instead chosen to keep them to themselves. I would love to see EA follow the rest of the industry's lead here.
    तो क्या लेखक ने यह report किया और कुछ भी नहीं मिला?

    • यह कहना सही नहीं कि कुछ भी नहीं मिला। Vulnerability report करने की वजह से legal action की धमकी मिलने की संभावना हमेशा रहती है
    • यह निराशाजनक है कि इतनी सारी companies bug bounty offer नहीं करतीं। वर्षों से खोजी गई vulnerabilities बस दिमाग में जमा होती जा रही हैं
      report करने में legal risk है, और यह भी मददगार नहीं कि technically company अंत तक मुकदमा चला सकती है। यह EU/UK के संदर्भ में है
    • ऐसे में लोग इंटरनेट के और shady हिस्सों में जाकर जानकारी सबसे ऊंची बोली लगाने वाले को बेचने लगते हैं
    • सही है, कुछ नहीं मिला