वह घटना जिसमें अमेरिका की लगभग आधी fast-food chains एक साथ हैक हो गईं

• एक security researcher .ai TLD साइटों और JS bundles को खंगालते हुए Firebase initialization variables खोज रहा था, तभी उसे Chattr.ai की exposed configuration मिली
• Chattr.ai एक AI hiring system है जो दावा करता है कि यह hiring time को 88% कम करता है, और इसका उपयोग Applebees, Arbys, Chickfila, Dunkin, IHOP, KFC, Subway, Tacobell, Target, Wendys जैसी कई fast-food और hourly hiring कंपनियां कर रही थीं
• केवल JS bundle की Firebase settings से access blocked था, लेकिन Firebase की registration feature से नया user बनाते ही DB पर read/write permissions खुल गईं
• exposed जानकारी में names, phone numbers, emails, कुछ accounts के plain-text passwords, branch locations, confidential messages, और work shift information शामिल थी, जिससे Chattr कर्मचारियों, franchise managers, और job seekers प्रभावित हुए
• vulnerability 01/06 को मिली, 01/09 को report की गई, 01/10 को patch हुई, और 01/11 को support ticket बंद कर दिया गया, लेकिन स्पष्ट अनुरोध के बावजूद न तो कोई acknowledgement मिला और न ही आगे का संपर्क

---

Firebase scan से Chattr.ai तक

• researcher ने हाल ही में सैकड़ों AI startups में exposed Firebase credentials खोजने के लिए एक script चलाई
  • सार्वजनिक .ai TLD साइटों की सूची का इस्तेमाल किया गया
  • site data और referenced .js bundles को parse करके Firebase initialization variable references खोजे गए
• उसका लक्ष्य यह देखना था कि product को जल्दी ship करने की प्रक्रिया में कहीं किसी ने security rules सही तरह से लागू नहीं किए हों, लेकिन वास्तव में इससे भी गंभीर समस्या सामने आई
• Chattr.ai एक AI hiring system है जो दावा करता है कि यह नए hiring process का समय 88% घटाता है
  • hiring time reduction claim: {p:88}
• सेवा का उपयोग करने वाली कंपनियों के उदाहरण के रूप में ये brands सूचीबद्ध थे
  • Applebees
  • Arbys
  • Chickfila
  • Dunkin
  • IHOP
  • KFC
  • Shoneys
  • Subway
  • Tacobell
  • Target
  • Wendys

privilege escalation का तरीका और exposed data

• JS bundle से ली गई Firebase configuration को Firepwn में डालने पर शुरुआत में कोई permission नहीं थी
• इसके बाद Firebase की registration feature से नया user बनाते ही, जबकि Chattr.ai साइट पर signup संभव नहीं था, Firebase DB पर full read/write access मिल गया
• exposed data में ये शामिल थे
  • names
  • phone numbers
  • emails
  • कुछ accounts के plain-text passwords
  • branch locations
  • confidential messages
  • work shift information
• प्रभावित समूहों में Chattr कर्मचारी, franchise managers, और job seekers शामिल थे

disclosure और patch timeline

• 01/06: vulnerability मिली
• 01/09: तैयार की गई report ईमेल से Chattr.ai को भेजी गई
• 01/10: vulnerability patch की गई
• 01/11: support ticket बंद, स्पष्ट अनुरोध के बावजूद कोई acknowledgement या अतिरिक्त संपर्क नहीं

[GN⁺]

Hacker News की राय

• यह स्पष्ट नहीं है कि लेखक को यह penetration test करने के लिए नियुक्त किया गया था, या वे किसी गुरिल्ला-स्टाइल नेकनीयत third party थे
  अगर दूसरा मामला है, तो हैरानी है कि वे इतने बेखौफ कैसे हो सकते हैं। क्या chattr.ai की कोई responsible disclosure policy है? मेरा मानना है कि अगर नुकसान पहुँचाने का इरादा नहीं है और findings रिपोर्ट की जा रही हैं, तो किसी को भी स्वतंत्र रूप से penetration test करने की अनुमति होनी चाहिए। दुर्भाग्य से, कई कंपनियाँ इरादा नेक होने पर भी डर जाती हैं और कानूनी कार्रवाई की ओर बढ़ जाती हैं

  • “हाल ही में सैकड़ों AI startups में उजागर Firebase credentials खोज रहा था” वाला हिस्सा देखें तो बात काफी साफ लगती है। उन्होंने सैकड़ों startups को scan करने वाली script चलाई थी
    नेकनीयत third party होने पर भी कंपनी कानूनी कार्रवाई कर सकती है, लेकिन ऐसे मामलों में अक्सर बात कंपनी की सार्वजनिक रूप से काफी किरकिरी होने पर खत्म होती है
  • वेब पहले से ही काफी असुरक्षित है, इसलिए मैं बस इसे थोड़ा और सुरक्षित बनाने में अपना हिस्सा निभाना चाहता हूँ
  • ऐसे मामले regulators को कंपनियों को और बारीकी से देखने के लिए प्रेरित भी कर सकते हैं
    https://www.ftc.gov/news-events/news/press-releases/2023/11/...
  • सोचता हूँ कि क्या भौतिक सुरक्षा को लेकर भी आपका यही विचार है। क्या किसी का इमारत के आसपास घूमना, खिड़कियों में झाँकना, दरवाज़ों के ताले खोलना, यहाँ तक कि अंदर थोड़ा घूम लेना भी ठीक है, जब तक वह कुछ चुराता नहीं?
  • अगर सही regulation, engineering standards और वास्तविक fines नहीं हैं, तो आखिर में मौजूद इकलौता लोकतंत्र वही है जिसमें लोग खुद कार्रवाई करते हैं
    hack हुई कंपनियों में भी काफी दुर्भावना है, इसलिए ध्यान तो उसी तरफ होना चाहिए

• timeline में वह समय नहीं है जब post online डाली गई

  • Wayback Machine के मुताबिक यह पहली बार 10 जनवरी 2024 को दिखी
    http://web.archive.org/web/20240000000000*/https://mrbruh.co...
  • इसे आज पहले पोस्ट किया था (NZ time)। अगर वे संपर्क करते हैं, तो उस हिस्से को संशोधित वाक्य से बदल दूँगा :)

• अभी link खोलने पर ढेर सारे Prometheus metrics लौट रहे हैं। दिलचस्प है

  • अब ऐसा नहीं होगा। वह “production में deploy कर रहा था” वाला पल था
    site पर traffic उमड़ रहा था, इसलिए analytics की जरूरत थी

• सोच रहा हूँ कि क्या यह CFAA के तहत authorized access माना जाएगा
  जानना चाहता हूँ कि सीमा कहाँ है

• फिर से सोचने पर, असल में जोखिम में वे बेचारे लोग लगते हैं जो ऐसी कंपनियों में बहुत कम hourly wage पर नौकरी पाने की कोशिश कर रहे हैं
  यह कंपनी को ही किस तरह “p0wn” करता है, यह मुझे ठीक से समझ नहीं आता

• इस page को Safari में देखने पर यह सिर्फ text document जैसा दिखता है

  • images के लिए AVIF format इस्तेमाल किया गया है। मकसद PNG की तुलना में 2x compression advantage लेना और फिर भी JPG से बेहतर quality बनाए रखना है
    अगर images नहीं दिख रहीं, तो शायद आप पुराना browser इस्तेमाल कर रहे हैं। जहाँ तक मुझे पता है, Internet Explorer को छोड़कर browsers के मौजूदा versions सभी इसे support करते हैं। और अगर आप Internet Explorer इस्तेमाल कर रहे हैं, तो भगवान आपकी रक्षा करे
    [0] https://caniuse.com/avif
  • Mac के Safari 16.1 में ऐसा नहीं दिखता
  • चूँकि यह security पर लेख है, तो internet पर सुरक्षित रहने के लिए browser update करने की आज की reminder समझें
    नया Safari AVIF images support करता है, और पिछले साल Safari में ज्ञात कई remote code execution vulnerabilities को fix किया गया था