City-Forum अभियान: कैसे एक सर्वर ने 17 महीने तक बिना किसी कमजोरी के Salesforce और ServiceNow से डेटा चुराया

कैसे काम करता है यह हमला: कोई वल्नरेबिलिटी जरूरी नहीं

Salesforce और ServiceNow दोनों में ही अनऑथेंटिकेटेड विजिटर्स के लिए स्थायी गेस्ट यूज़र अकाउंट होते हैं। इन गेस्ट यूज़र्स को डिलीट नहीं किया जा सकता। उनकी परमिशन हर संगठन खुद सेट करता है। अगर गेस्ट प्रोफाइल के पास किसी रिकॉर्ड को पढ़ने की अनुमति है, तो इंटरनेट पर कोई भी व्यक्ति उसे पूरी तरह से कानूनी API एंडपॉइंट्स के जरिए हासिल कर सकता है।

Salesforce (Aura फ्रेमवर्क) पर:

• टूल /aura या /s/sfsites/aura एंडपॉइंट पर POST रिक्वेस्ट भेजता है।
• यह पहले HostConfigController.getConfigData को कॉल करके यह पता लगाता है कि गेस्ट के लिए कौन से ऑब्जेक्ट (Account, Contact, Case, Lead, User, ContentDocument, आदि) एक्सेसिबल हैं।
• फिर यह SelectableListDataProviderController.getItems का इस्तेमाल करके हर एक्सेसिबल ऑब्जेक्ट पर सभी रिकॉर्ड्स को पेज करके निकालता है।
• अब तक के सबसे बड़े टार्गेट ने हैकर के IP से 560,000 से ज्यादा इवेंट लॉग किए हैं, जिनमें से लगभग सभी गेस्ट Aura एनुमरेशन थे।

Salesforce (LWR फ्रेमवर्क — Lightning Web Runtime) पर:

• यह Salesforce के LWR साइट्स पर UI-API गेस्ट सरफेस का पहला इन-द-वाइल्ड एक्सप्लॉइटेशन है।
• टूल GraphQL एंडपॉइंट

  POST /webruntime/api/services/data/{version}/graphql?asGuest=true

  को टार्गेट करता है, पहले EntityDefinition के जरिए स्कीमा का पता लगाता है, फिर कर्सर-बेस्ड पेजिनेशन से रिकॉर्ड पढ़ता है।
• यह हर खोजे गए LWR साइट के खिलाफ API वर्जन v56.0 से v66.0 तक को क्रम से स्कैन करता है।

ServiceNow पर:

• टूल /api/now/sp/search एंडपॉइंट को टार्गेट करता है—यह ServiceNow का एक नेटिव सर्च API है जो काफी हद तक अनप्रलेखित है और इसका ऑनलाइन कोई डॉक्यूमेंटेशन या ओपन-सोर्स टूल नहीं है।
• यह एंडपॉइंट डिफ़ॉल्ट रूप से पब्लिक है। यह कौन सा डेटा लौटाता है, यह पूरी तरह से इस बात पर निर्भर करता है कि गेस्ट-फेसिंग पोर्टल से कौन से सर्च सोर्स जुड़े हैं और क्या वे सोर्स एक्सेस कंट्रोल लागू करते हैं।

सेल्फ-रजिस्ट्रेशन प्रोबिंग (Salesforce):

• टूल हर खोजे गए एक्सपीरियंस साइट पथ पर /SiteRegister और /CommunitiesSelfReg जोड़कर जांचता है कि सेल्फ-रजिस्ट्रेशन चालू है या नहीं। अगर है, तो एक गेस्ट खुद को एक ऑथेंटिकेटेड एक्सटर्नल यूज़र में बदल सकता है और कहीं ज्यादा डेटा तक पहुंच सकता है।

कस्टम टूलसेट और इंफ्रास्ट्रक्चर

• सोर्स IP: 158.220.87.79, जो जर्मन होस्टिंग प्रोवाइडर Contabo के VPS पर होस्ट है और डोमेन city-forum.com पर रिज़ॉल्व होता है (2002 में रजिस्टर किया गया, फिर छोड़ दिया गया और अब दोबारा इस्तेमाल किया गया डोमेन)
• यही IP मार्च 2025 से बिना किसी बदलाव के एक ही डोमेन लिए हुए है—कम से कम 17 महीने एक ही एड्रेस पर।
• कस्टम Go बाइनरी: यह एक Go कंपाइल्ड टूल है जो एक साथ Salesforce के Aura और LWR दोनों फ्रेमवर्क्स और ServiceNow को हिट करता है—सब एक ही सर्वर से। यह एक कस्टम मल्टी-प्लेटफॉर्म टूलसेट है, न कि कोई रेडीमेड टूल जैसे AuraInspector।
• टूल Go के डिफ़ॉल्ट Go-http-client User-Agent स्ट्रिंग का इस्तेमाल करता है, जिससे इसे लॉग्स में पहचानना आसान है।

किन संगठनों को निशाना बनाया गया

Reco की रिपोर्ट के अनुसार, मुख्य लक्ष्यों में शामिल हैं:

• दूरसंचार ऑपरेटर (टेलीकॉम कंपनियां)
• बैंक और वित्तीय-सेवा फर्में
• एंटरप्राइज सॉफ्टवेयर विक्रेता (सुरक्षा और डेटा-प्राइवेसी कंपनियों सहित)
• सरकारी पोर्टल्स

क्यों स्टैंडर्ड ऑडिट लॉग्स यह नहीं बता सकते कि कौन सा डेटा चुराया गया

ServiceNow के लिए: प्लेटफॉर्म के ट्रांजैक्शन लॉग्स (syslog_transaction) /api/now/sp/search रिक्वेस्ट का POST बॉडी रिकॉर्ड नहीं करते। डिफेंडर यह तो देख सकते हैं कि ऑटोमेटेड सर्च हुई और कितना डेटा वापस आया (आउटपुट लेंथ कॉलम से), लेकिन सटीक सर्च टर्म या कौन से रिकॉर्ड हासिल किए गए, यह नहीं जान सकते।

Salesforce के लिए: गेस्ट एनुमरेशन ट्रैफिक में पूरी तरह से वैध, प्रोटोकॉल-कंप्लाइंट API कॉल होते हैं जो सामान्य साइट ट्रैफिक जैसे दिखते हैं। हालांकि इवेंट मॉनिटरिंग गेस्ट यूज़र्स से AuraRequest और Sites इवेंट्स की मात्रा दिखा सकती है, लेकिन लॉग्स यह नहीं दिखाते कि GraphQL या Aura रिस्पॉन्स में कौन सा कंटेंट वापस आया।

दूसरे शब्दों में, आप देख सकते हैं कि हैकर वहां था और उसने कितना डेटा खींचा, लेकिन आप यह पता नहीं लगा सकते कि उसने वास्तव में कौन से रिकॉर्ड या फील्ड निकाले।

अनुशंसित उपाय

Salesforce के लिए (Reco की सिफारिशें):

1. गेस्ट शेयरिंग रूल्स को कड़ा करें — सबसे अधिक प्रभाव वाला नियंत्रण। किसी भी शेयरिंग रूल को हटा दें जो गेस्ट यूज़र के साथ ऐसे रिकॉर्ड शेयर करता हो जो साइट को सार्वजनिक रूप से उपलब्ध कराने के लिए जरूरी न हों।
2. गेस्ट प्रोफाइल से ऑब्जेक्ट- और फील्ड-लेवल की परमिशन हटाएं। उन ऑब्जेक्ट्स पर रीड एक्सेस हटा दें जिनकी साइट को अज्ञात विजिटर्स के लिए जरूरत नहीं है।
3. गेस्ट प्रोफाइल से "Access Activities" परमिशन हटाएं (इससे Tasks और Events एक्सपोज़ होते हैं)।
4. गेस्ट यूज़र पर "API Enabled" बंद करें।
5. सेल्फ-रजिस्ट्रेशन बंद करें जब तक कि साइट को वास्तव में इसकी आवश्यकता न हो।
6. गेस्ट फाइल एक्सेस और मेंबर विजिबिलिटी बंद करें ताकि मेहमान ContentDocument फाइलें न निकाल सकें या साइट के अन्य सदस्यों की सूची न बना सकें।
7. सिर्फ LWR साइट्स के लिए: Experience Builder → Workspaces → Administration → Preferences में जाकर "Allow guest users to access public APIs" को अनचेक करें। इससे एक झटके में GraphQL और UI-API REST एंडपॉइंट बंद हो जाएंगे।

ServiceNow के लिए (Reco की सिफारिशें):

1. गेस्ट-फेसिंग पोर्टल्स को उनके सर्च सोर्सेज से मैप करें। sp_portal, m2m_sp_portal_search_source और sp_search_source टेबल देखें। किसी भी सर्च सोर्स को डिटैच करें जिसकी पब्लिक पोर्टल को जरूरत नहीं है।
2. प्रत्येक सर्च सोर्स के लॉजिक की समीक्षा करें — खासकर is_scripted_source, data_fetch_script, और यह कि वह GlideRecordSecure (ACL-एंफोर्सिंग) का उपयोग करता है या सादे GlideRecord (जो सुरक्षित नहीं है) का।
3. नॉलेज बेस "Can Read" यूज़र क्राइटेरिया की समीक्षा करें — ऐसे अनियंत्रित "Any User" एक्सेस की तलाश करें जो गेस्ट सर्च के जरिए संवेदनशील KB को एक्सपोज़ करता हो।
4. शेयरिंग रूल्स को आंख मूंदकर एडिट करने के बजाय खराब kb_uc_can_read_mtom लिंक को हटाएं।

डिटेक्शन गाइडेंस:

• Salesforce इवेंट मॉनिटरिंग:

  USER_TYPE = 'Guest'

  से getItems और getConfigData की अधिक मात्रा, /webruntime/.../vNN.0/graphql वर्जन स्वीप, और /SiteRegister और /CommunitiesSelfReg पर हिट्स देखें।
• ServiceNow syslog_transaction: गेस्ट के रूप में किए गए /api/now/sp/search रिक्वेस्ट देखें। आउटपुट लेंथ के हिसाब से सॉर्ट करें—जो पंक्तियां छोटी खाली-परिणाम बेसलाइन से काफी अधिक लौटाती हैं, वे संकेत हैं कि सर्च ने कंटेंट वापस किया।