लाखों मॉडेम हैकिंग और मेरे मॉडेम से समझौते की जांच

• Sam Curry ने देखा कि उनके घर के नेटवर्क से भेजी गई HTTP request 10 सेकंड बाद DigitalOcean IP से उसी तरह replay हो रही थी, और Cox Panoramic Wifi gateway बदलने के बाद यह समस्या खत्म हो गई, जिससे पुराने मॉडेम के compromise होने का संदेह हुआ
• replay ट्रैफिक का IP 159.65.76.209 Adidas-संबंधित domain, ISG Latam phishing domain, और algorithmically generated लगने वाले C&C domains से जुड़ा मिला, लेकिन वास्तविक compromise path की पुष्टि नहीं हो सकी
• 2024 में Cox Business portal के विश्लेषण के दौरान /api/cbma/ के पीछे Spring-आधारित API और Swagger docs मिले, और लगभग 700 APIs में से कुछ ने auth error और 200 OK को बारी-बारी से लौटाने वाली authorization bypass समस्या दिखाई
• इस authorization bypass से customer search, account PII lookup, equipment MAC address lookup, मॉडेम IP lookup, Cox Business account read/write, और WiFi SSID बदलने जैसे equipment configuration changes संभव थे; PoC में उनका अपना SSID Curry में बदल गया
• Cox ने रिपोर्ट मिलने के 6 घंटे के भीतर exposed API हटा दिए और अगले दिन issue reproduce नहीं हो सका; कंपनी ने कहा कि यह API service 2023 में शुरू हुई थी, इसलिए 2021 के मॉडेम compromise से अलग थी, और इसके पुराने exploitation का कोई सबूत नहीं मिला

---

घर के मॉडेम से शुरू हुआ असामान्य ट्रैफिक

• घर के नेटवर्क में blind XXE vulnerability test करने के लिए AWS instance पर एक simple Python HTTP server चलाया गया और यह देखा गया कि कोई external request आती है या नहीं
• घर के कंप्यूटर से curl द्वारा भेजी गई request log होने के तुरंत बाद, अज्ञात IP 159.65.76.209 ने उसी path को 10 सेकंड बाद फिर request किया
• iPhone Safari से दूसरा path request करने पर भी उसी IP ने वही request replay की, जिससे लगा कि किसी एक कंप्यूटर की नहीं बल्कि पूरे home network traffic की निगरानी हो रही है
• नए AWS instance और Nginx, फिर GCP instance पर भी वही व्यवहार दिखा, इसलिए AWS compromise की संभावना खारिज हुई
• पुराना Cox Panoramic Wifi gateway स्टोर में लौटाकर नया device लगाने के बाद replay ट्रैफिक गायब हो गया और logs में “दूसरा IP” फिर नहीं दिखा

159.65.76.209 की जांच

• यह IP DigitalOcean का निकला, Cox ISP address नहीं था
• VirusTotal records में हाल में जुड़े 5 domains में 3 phishing site जैसे और 2 mail server जैसे दिखे
  • regional.adidas.com.py
  • isglatam.online
  • isglatam.tk
  • mx12.limit742921.tokyo
  • mx12.jingoism44769.xyz
• isglatam.online और isglatam.tk कभी दक्षिण अमेरिकी cyber security कंपनी isglatam.com को निशाना बनाने वाली phishing websites थीं
• URLscan records के अनुसार, ये दोनों ISG Latam-संबंधित domains सामान्य BeEF phishing sites host कर रहे थे; संबंधित रिकॉर्ड urlscan.io result में देखा जा सकता है
• वही IP Adidas, ISG Latam, और मॉडेम ट्रैफिक replay से जुड़ा दिखा, लेकिन यह भी पूरी तरह खारिज नहीं किया जा सका कि IP अलग-अलग owners के बीच reassign हुआ हो

3 साल बाद फिर जुड़ी जांच

• 2024 की शुरुआत में, security क्षेत्र के दोस्तों ने limit742921.tokyo और jingoism44769.xyz के format पर ध्यान दिया
• limit742921.tokyo के mx1 subdomain IP के आधार पर reverse IP lookup करने पर, इसी pattern के 1,000 से अधिक domains मिले
• सभी domain names का format [word][6 numbers].[TLD] था
  • उदाहरण: acquire543225.biz
  • उदाहरण: battery935904.biz
  • उदाहरण: grocery634272.biz
• बड़े पैमाने पर registration और algorithmic structure को देखते हुए, यह malware operators द्वारा C&C server addresses छिपाने के लिए इस्तेमाल किए जाने वाले domain generation algorithm जैसा लगा
• आखिरी बार देखा गया domain 17 मार्च 2023 को register हुआ था, और तब तक host resolve नहीं हो रहा था; उसी IP पर register हुए वैसे ही domains भी फिर नहीं मिले

ISP management features और TR-069 से शुरू हुई परिकल्पना

• Cox support agent मॉडेम को remotely update कर सकता था, WiFi password बदल सकता था, और connected devices देख सकता था
• यह remote management 2004 में लागू किए गए TR-069 protocol से जुड़ा था, जिसके जरिए ISP port 7547 पर network के devices manage करता है
• TR-069 खुद externally exposed नहीं था और उस पर DEF CON talk भी हो चुकी थी, इसलिए ध्यान agent द्वारा इस्तेमाल किए जाने वाले support tools और internal APIs की ओर गया
• यह माना गया कि अगर कोई attacker मॉडेम compromise करना चाहे, तो वह support tools के underlying infrastructure, खासकर उन APIs को target कर सकता है जो customer equipment settings बदल सकती हैं या arbitrary command चला सकती हैं
• यह जांच 2021 के वास्तविक compromise path को साबित करने से ज्यादा ISP और customer equipment के बीच trust layer की जांच की दिशा में बढ़ी

Cox Business portal की API संरचना

• Cox Business portal की frontend JavaScript file main.36624ed36fb0ff5b.js में /api/cbma/ आधारित 100 से अधिक API calls मिलीं
• /api/cbma/ path का response behavior बाकी /api/ paths से अलग था, इसलिए यह frontend से अलग backend पर proxy की जा रही API जैसा लगा
  • /api/anything_else/example redirect response देता था
  • /api/cbma/example 500 Internal Server Error लौटाता था
• registration request में clientid, Apikey, Cb_session, Authorization जैसे headers थे, और response format Spring-आधारित backend जैसा दिखा
• HTTP method बदलने पर Spring error response मिला, जिससे पुष्टि हुई कि API backend Spring आधारित है
• actuator path नहीं मिला, लेकिन Swagger UI path मिल गया

Swagger docs का bypass loading और 700 APIs

• Swagger UI load तो हुआ, लेकिन static resources redirect loop में फंस गए, इसलिए docs खाली दिखीं
• .js, .css, .png जैसे static resource requests API proxy की बजाय default host पर route होती दिखीं
• URL के अंत में encoded / यानी %2f जोड़ने पर static JavaScript resources को API proxy के जरिए load किया जा सका
• Burp के match-and-replace से static resource requests में %2f जोड़ने पर Swagger docs सही दिखने लगीं
• कुल मिलाकर लगभग 700 API calls दिखीं, जिनमें equipment और account functions से सबसे अधिक जुड़े हिस्से accountequipment, datainternetgateway, और account थे

authentication bypass और customer data access

• सभी GET endpoints पर बार-बार request भेजने पर कुछ auth error और कुछ 200 OK लौटाते रहे, और एक ही request पर repeated attempts में result बदलता रहा
• profilesearch endpoint ने पहले empty search result लौटाया, फिर वही request auth error और success response के बीच बारी-बारी से बदलती रही
• cox search term के साथ request दोहराने पर Cox business customer profiles जैसे results और profileGuid मिला
• fbi search term पर request करने से कई FBI field offices के physical addresses वाले results मिले, जो Cox business customers थे
• यही authorization issue दूसरी APIs को भी प्रभावित कर रही थी, और request कई बार replay करने पर unauthenticated स्थिति में भी admin functions तक पहुंच मिल सकती थी

equipment MAC address और account information lookup

• अपने मॉडेम का MAC address Cox account से लेकर macAddress parameter वाली API में देने पर उस device का IPv4 address मिला
• इससे पुष्टि हुई कि Cox Business website API वास्तव में physical equipment से communicate कर सकती है
• account ID इस्तेमाल करने वाली equipment list API ने account से जुड़े devices की जानकारी लौटाई
  • device category
  • model name
  • MAC address
  • port information
  • serial number
• email-आधारित user lookup API ने name, phone number, status, user type, profile owner status, और alternate email जैसी business account details लौटाईं
• इसी तरह के POST account update requests भी काम कर रहे थे, जिससे business accounts पर read और write access की पुष्टि हुई

encryptedValue और equipment configuration changes

• equipment settings बदलने वाली requests में encryptedValue parameter जरूरी था
• JavaScript के अंदर encryptWithSaltandPadding और decryptWithSaltandPadding functions AES-आधारित value encryption/decryption के लिए इस्तेमाल हो रहे थे
• account registration के समय सेट किया जाने वाला 4-digit PIN भी इन्हीं functions से encrypt होता था, इसलिए browser debugger में इनके execution context तक पहुंच मिल सकी
• Cox Business इस्तेमाल करने वाले एक परिचित के account में equipment response से मिले encryptedValue को decrypt करने पर ये तत्व मिले
  • Cox account number
  • device name
  • device ID
  • अज्ञात value
  • MAC address
  • label
• account number और device ID में arbitrary values डालकर, सिर्फ MAC address को valid रखते हुए string को दोबारा encrypt करने पर भी request सफल रही; इससे पता चला कि server MAC address और account consistency verify नहीं कर रहा था

arbitrary मॉडेम configuration change की संभावना

• अपने device MAC address पर WiFi SSID बदलने वाली POST request भेजी गई
• response 200 OK और Success था, और उसके बाद network कुछ समय के लिए offline हो गया
• लगभग 5 मिनट बाद network reboot हुआ और SSID Curry में बदल गया
• इस PoC ने दिखाया कि equipment configuration update API वास्तव में काम करती है और attacker API के जरिए device settings overwrite कर सकता है
• यह privilege ISP tech support के समान स्तर का था और API तक पहुंच वाले लाखों Cox devices को प्रभावित कर सकता था

impact scope और संभावित attack flow

• vulnerabilities के इस संयोजन ने बिना किसी precondition वाले external attacker के लिए लाखों मॉडेम configurations बदलने, business customer PII तक पहुंचने, और ISP support team-स्तर के privileges पाने का रास्ता बनाया
• Cox अमेरिका का सबसे बड़ा privately held broadband provider, तीसरा सबसे बड़ा cable TV provider, और सातवां सबसे बड़ा telephone operator है; इसके लाखों customers हैं और 10 राज्यों में यह सबसे लोकप्रिय ISP है
• संभावित attack flow इस प्रकार था
  • name, phone number, email, account number के आधार पर Cox Business targets खोजें
  • returned UUID से account PII, device MAC address, email, phone number, address प्राप्त करें
  • device MAC address से WiFi password और connected devices देखें
  • arbitrary command execution, device property updates, और victim account takeover करें
• exposed APIs की संख्या 700 से अधिक थी, और कई APIs मॉडेम से जुड़े devices देखने जैसे admin features देती थीं
• हर API repeated requests के जरिए unauthorized commands चलाने वाली इसी authorization समस्या से प्रभावित थी

रिपोर्ट, patch, और बचे हुए सवाल

• vulnerability को Cox के responsible disclosure program के जरिए report किया गया
• Cox ने 6 घंटे के भीतर exposed API calls बंद कर दिए, और अगले दिन vulnerability reproduce नहीं हो सकी
• Cox की जांच के अनुसार इस vector के historical exploitation का कोई रिकॉर्ड नहीं मिला, और vulnerable service 2023 में शुरू हुई थी, इसलिए 2021 के मॉडेम compromise में इसका इस्तेमाल नहीं हुआ हो सकता
• Cox ने कहा कि उसका DigitalOcean IP से कोई संबंध नहीं है; इसलिए पुराना मॉडेम इस लेख में बताए गए तरीके से नहीं बल्कि किसी और तरीके से compromise हुआ था
• चूंकि मूल मॉडेम वापस कर दिया गया था, firmware dump या forensic analysis संभव नहीं था, और ट्रैफिक को replay करने की वजह भी स्पष्ट नहीं हो सकी

public timeline

• 2024-03-04: Cox के responsible disclosure program के जरिए vulnerability report की गई
• 2024-03-05: hot patch लागू किया गया; non-essential business endpoints ने 403 लौटाना शुरू किया और काम बंद हो गया
• 2024-03-06: Cox को email भेजी गई कि vulnerability अब reproduce नहीं हो रही
• 2024-03-07: Cox ने जवाब दिया कि वह comprehensive security review शुरू कर रहा है
• 2024-04-10: Cox को बताया गया कि disclosure report के 90 दिन बाद किया जाएगा
• 2024-04-29: blog draft link Cox के साथ साझा की गई

[GN⁺]

Hacker News टिप्पणियाँ

• albinowax_ ने इसे पहले पोस्ट किया था, और मुझे यह ठीक नहीं लगा कि उसे karma न मिले, इसलिए मैंने टिप्पणी को https://news.ycombinator.com/item?id=40560010 पर स्थानांतरित कर दिया।
  उम्मीद है xrayarx इसे सहजता से लेगा। ऐसे मामलों के लिए karma sharing को ठीक से लागू करने की योजना है, लेकिन तब तक हमें कभी-कभी ऐसे ही कुछ भद्दे मैन्युअल तरीकों पर निर्भर रहना पड़ता है
  • सिस्टम के हिसाब से मैंने 13 घंटे पहले पोस्ट किया था, और उसने 10 घंटे पहले। इसलिए यह बात कि उसने पहले पोस्ट किया, मेरी समझ में नहीं आती