1 बिलियन डॉलर मूल्य वाले कानूनी AI टूल की रिवर्स इंजीनियरिंग के बाद 100,000 से अधिक गोपनीय फ़ाइलें एक्सपोज़

• कानूनी AI प्लेटफॉर्म Filevine के API का विश्लेषण करते समय बिना authentication के पूर्ण admin अधिकार देने वाली एक गंभीर सुरक्षा खामी सामने आई।
• शोधकर्ता ने subdomain enumeration की मदद से margolis.filevine.com subdomain खोजा और AWS API endpoint पहचानकर परीक्षण request भेजी।
• एक साधारण POST request पर authentication token के बिना response मिला, जिसमें Box फ़ाइल सिस्टम पर पूर्ण admin access देने वाला टोकन मौजूद था।
• इसी token की मदद से लगभग 100,000 “confidential” दस्तावेज़ खोजे जा सके, जिनमें healthcare, legal और payroll जैसे अत्यधिक संवेदनशील डेटा मौजूद था।
• Filevine ने रिपोर्ट के बाद तत्काल प्रतिक्रिया और फिक्स जारी की, और यह घटना AI-आधारित कानूनी सेवाओं में सुरक्षा प्रबंधन के महत्व को स्पष्ट करती है।

---

खामी खोजने और सार्वजनिक करने की टाइमलाइन

• शोधकर्ता ने 27 अक्टूबर 2025 को Filevine की security टीम को ईमेल द्वारा खामी की सूचना दी।
  • 4 नवंबर 2025: Filevine ने समस्या को स्वीकार कर तेज़ फिक्स प्लान भेजा।
  • 20 नवंबर 2025: शोधकर्ता ने patch लागू होने की पुष्टि की और तकनीकी ब्लॉग पर पोस्ट करने की सूचना दी।
  • 21 नवंबर 2025: Filevine ने सुधार पूरा होने की पुष्टि की और शोधकर्ता का धन्यवाद किया।
  • 3 दिसंबर 2025: तकनीकी ब्लॉग पोस्ट प्रकाशित।
• Filevine ने पूरी प्रक्रिया में तेज़ और प्रोफेशनल प्रतिक्रिया दी, इसलिए इसे जिम्मेदार security disclosure का एक मॉडल केस माना गया।

Filevine और कानूनी AI मार्केट का संदर्भ

• Filevine एक 1 बिलियन डॉलर से अधिक मूल्यांकन वाला कानूनी AI प्लेटफॉर्म है, जो तेजी से बढ़ रहा है।
• कानूनी फर्म इस प्लेटफॉर्म पर बहुत अधिक गोपनीय डेटा अपलोड करके अपना काम संभालती हैं।
• शोधकर्ता, Yale Law School के एक पूर्व प्रोजेक्ट अनुभव के आधार पर, Filevine की डेटा सुरक्षा संरचना की समीक्षा करने के लिए प्रेरित हुआ।

रिवर्स इंजीनियरिंग की प्रक्रिया

• Filevine के access controls के कारण शोधकर्ता ने सार्वजनिक डेमो वातावरण खोजने के लिए subdomain enumeration तकनीक अपनाई।
• उसने margolis.filevine.com subdomain खोज तो लिया, लेकिन पेज लोड नहीं हुआ; इसलिए Chrome Developer Tools से नेटवर्क requests की जांच की।
• JS फ़ाइल में POST await fetch(${BOX_SERVICE}/recommend) कोड मिला और BOX_SERVICE को AWS API endpoint पर सेट किया गया पाया।
• {"projectName":"Very sensitive Project"} फॉर्मेट का request /prod/recommend पर भेजने पर, बिना authentication के response वापस मिला।

admin token के खुलासे का प्रभाव

• response में Box API का व्यापक admin token (boxToken) शामिल था।
• इस token से किसी विधि फर्म के पूरे internal Box फ़ाइल सिस्टम तक पहुँचा जा सकता था।
  • दस्तावेज़, logs, उपयोगकर्ता जानकारी आदि सभी डेटा तक एक्सेस मिल सकता था।
• “confidential” keyword खोजने पर लगभग 100,000 परिणाम लौटते हुए देखे गए।
• शोधकर्ता ने तुरंत परीक्षण रोककर Filevine को vulnerability रिपोर्ट की।
• यदि कोई malicious attacker इस token का दुरुपयोग करता, तो HIPAA-protected दस्तावेज़, कोर्ट ऑर्डर दस्तावेज़, internal payroll डेटा जैसी जानकारी लीक हो सकती थी।

सुरक्षा से सीखे गए सबक

• AI अपनाने की दौड़ में कंपनियों के लिए डेटा सुरक्षा फ्रेमवर्क को मजबूत करना अनिवार्य है।
• खासकर कानून, स्वास्थ्य जैसे बहुत संवेदनशील क्षेत्रों की AI सेवाओं के लिए सख्त सुरक्षा verification जारी रखना होगा।
• यह केस साफ दिखाता है कि AI-आधारित SaaS में authentication और authorization के विफल होने से कितना बड़ा risk पैदा हो सकता है।

[GN⁺]

Hacker News टिप्पणी

• ऐसी स्पष्ट security vulnerability को classify करने और ठीक करने में इतना समय लगना हमेशा चौंकाता है
  27 अक्टूबर को disclosure हुआ और 4 नवंबर को email confirmation आई, यानी उस दौरान पूरा client file system exposed था
  असली fix शायद 1 घंटे के अंदर का patch रहा होगा, और QA testing जोड़ दें तब भी इतना समय लगने वाली बात नहीं है
  सोचता हूँ क्या security@ email कोई देखता ही नहीं, या कोई छुट्टी पर था, या spam इतना ज़्यादा है कि असली issue दिखता ही नहीं

  • मेरे अनुभव में ऐसी देरी की वजह अक्सर organizational structure और project management की समस्या होती है
    security team security@ email संभालती है, लेकिन bug ठीक करने वाली team अलग होती है, इसलिए handoff जटिल हो जाता है
    code owner team ढूँढने में ही कई हफ्ते लग जाते हैं, और schedule भरा होने से priority बढ़ाना मुश्किल होता है
    legal team की approval भी चाहिए होती है, इसलिए response और देर से होता है
    समझदार companies security team को emergency response authority देती हैं, लेकिन उसका misuse हो तो internal fatigue भी बढ़ती है
  • ज़्यादातर मामलों में “security mailbox कोई नहीं देखता” से ज़्यादा, उस हिस्से को जानने वाला एक ही व्यक्ति एक साथ 12 और काम संभाल रहा होता है
    security patch 1 घंटे का fix होता है, लेकिन internal approvals और code owner ढूँढने में 2 हफ्ते लग जाते हैं
    आखिरकार असली समस्या organization की entropy है
  • आजकल security@ mailbox में fake reports बहुत आते हैं
    LLM भरोसेमंद दिखने वाली vulnerability reports बना देता है, जिससे experts के कई घंटे बर्बाद हो जाते हैं
    इसलिए कुछ companies policy रखती हैं कि email सिर्फ working hours में review होगी
  • सच में spam बहुत आता है, लेकिन दिन में कुछ emails जितना ही, इसलिए इतनी गंभीर vulnerability को तुरंत patch न कर पाने का यह कारण नहीं हो सकता
    शायद जैसा कहा गया, ज़िम्मेदार व्यक्ति छुट्टी पर था
  • जिस global response center में मैं काम करता हूँ वहाँ 600 लोग हैं, और 26,000 priority issues हैं
    system जितना complex होता है, problems कम नहीं बल्कि और बढ़ती हैं
    आखिर में हम “हम इसे संभाल सकते हैं” वाले भ्रम में काम कर रहे होते हैं

• अगर इस company की $1 billion valuation थी, तो ऐसी एक बुनियादी vulnerability से उतना नुकसान हो सकता था
  अगर यह किसी malicious actor को मिलती, तो recovery नामुमकिन हो सकती थी
  पूरा customer data leak हो सकता था, इसलिए finder को reward मिलना चाहिए था

  • सही बात। ऐसी vulnerability ransomware groups को बेचकर सैकड़ों हज़ार डॉलर कमाए जा सकते थे
    उसके बाद data breach, extortion, lawsuits और fines तक बात जाती
    इसी वजह से कुछ hackers whitehat की बजाय gray market की ओर चले जाते हैं
  • सच में बहुत बड़ा reward देना चाहिए था

• मैं एक financial company में काम करता हूँ, और लोग हैरान होते हैं कि SaaS X को customer data दे देते हैं लेकिन AI SaaS Y पर tax documents upload नहीं कर सकते
  मेरे हिसाब से अभी AI industry एक तरह का Wild West है
  चीज़ें बहुत तेज़ी से बन रही हैं और security process skip हो रही है
  यह incident उसी का अच्छा उदाहरण है

  • FileVine एक legal AI tool है, लेकिन यह issue AI से जुड़ा हुआ नहीं लगता
    यह बस Box API integration की problem लगती है
  • जानकारी के लिए, यह company 2014 में founded हुई थी, और हाल में ही LLM features जोड़े हैं
    Reuters लेख लिंक
  • अगर SaaS X IAM features देता है और अपनी access policies लागू करता है, तो वह तुलनात्मक रूप से ज़्यादा safe है
    जबकि SaaS Y अगर सिर्फ “data हमें दे दीजिए, सुरक्षित रहेगा” कहता है, तो वह संदिग्ध है
  • लेकिन पहले यह पूछना चाहिए कि SaaS X पर भरोसा क्यों किया गया था
  • दिलचस्प बात यह है कि यह vulnerability AI से बिल्कुल जुड़ी नहीं है, बल्कि किसी भी SaaS company में होने वाली problem है

• यह incident “तेज़ी से API जोड़ने वाली startup culture” और “ऐसे legal/medical sectors जहाँ data leak से ज़िंदगी बर्बाद हो सकती है” के टकराव जैसा है
  समस्या 2010s वाले bug pattern की है, लेकिन उसे 2025 के AI marketing wrapper में ढक दिया गया है
  AI model training के लिए documents को centralize करने से incident होने पर damage scope बहुत बढ़ जाता है
  sales side पर deal जीतने के लिए data access आसान बनाना पड़ता है, इसलिए least privilege जैसी चीज़ें बाद में चली जाती हैं
  आखिरकार lawyers सोचते हैं कि वे “AI assistant” खरीद रहे हैं, लेकिन वास्तव में वे institutional memory पूरी की पूरी बाहर से access करने का अधिकार दे रहे होते हैं
  असली सवाल यह है कि “ऐसे systems में से कितने सही मायने में red team testing पास कर पाएँगे?”

  • थोड़ा मज़ेदार है। company cyber security का शो करती है, और साथ ही LLM wormhole बनाकर सब कुछ bypass कर देती है
    समस्या यह है कि non-technical executives AI को समझे बिना सिर्फ marketing चिल्लाते रहते हैं
    फिर भी मुझे अच्छा लगा कि मैंने space metaphor दो बार इस्तेमाल किया

• Filevine team ने disclosure process के दौरान पूरे समय professional और तेज़ response दिया
  उन्होंने issue की seriousness मानी, उसे fix किया, और transparently communicate किया
  इसलिए मुझे लगता है कि ऐसे cases में company का नाम ज़रूरी नहीं कि public किया जाए
  अगर issue हल हो गया है, तो बेवजह शर्मिंदा करने की ज़रूरत नहीं है

  • लेकिन responsible disclosure process में company का नाम बताना आम बात है
    तभी industry को पता चलता है कि कौन सी companies reports को गंभीरता से लेती हैं
  • ethical disclosure का मतलब है कि दोनों पक्ष मिलकर technical details public करें
    यह hackers और company दोनों के लिए अच्छा example बनता है
  • गलती छिपाने से transparency और trust खो जाते हैं
  • अगर issue इतना गंभीर था, तो customers को पता होना चाहिए
    और दूसरे AI SaaS vendors भी यह पढ़कर वही गलती करने से बच सकते हैं

• SOC2, HIPAA जैसी security certification processes एक तरह का ‘security theater’ लगती हैं
  वास्तव में महत्वपूर्ण चीज़ें नज़रअंदाज़ हो जाती हैं, और सिर्फ formal screenshots और paperwork भर रह जाता है

  • SemiAnalysis ने ऐसे certifications को FAA license जितना महत्वपूर्ण बताया था, लेकिन खुद वे एक साधारण security control failure से hack हो गए
    संबंधित लेख लिंक
    आखिर में यह असली security नहीं बल्कि पैसे से खरीदा गया checkbox भर है

• security software में अभी भी usability और complexity के मामले में बहुत सुधार की ज़रूरत है
  Google और Meta में काम करते समय ACL systems इतने complex थे कि उन्हें समझने में 4 साल लग गए
  ऐसे systems non-technical companies कभी इस्तेमाल नहीं कर सकतीं
  इसलिए कभी-कभी लगता है कि security को simplify करने वाला startup बनाना चाहिए
  यह AI से कहीं ज़्यादा कठिन problem लगती है

• अच्छी बात है कि इस company ने blog post publish करने दी
  मैंने भी पहले एक बड़ी vulnerability खोजी थी, लेकिन company ने disclosure रोक दिया था

  • “इजाज़त लेने की ज़रूरत है क्या?” बस responsibly disclose कर दो
  • disclosure control company के पास क्यों होना चाहिए? अगर reporting process follow कर ली गई, तो उसके बाद खुलकर लिखना चाहिए

• यह attack बिल्कुल sophisticated नहीं था
  Filevine ने website पर लिखा है कि वे penetration testing करते हैं, इसलिए यह miss कर देना यक़ीन करना मुश्किल है
  लगता है उन्होंने bug bounty को penetration testing समझ लिया
  सच में कोई बहाना नहीं है

• आजकल “healthcare + AI” startups बहुत ज़्यादा हैं, इसलिए डर है कि कुछ महीनों में HIPAA data का बड़ा breach सामने आ जाएगा
  संबंधित उदाहरण इस thread में भी देखे जा सकते हैं