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

 (samcurry.net)
2 पॉइंट द्वारा GN⁺ 2024-06-05 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • घर के नेटवर्क से भेजे गए HTTP requests को करीब 10 सेकंड बाद DigitalOcean IP से ज्यों का त्यों replay किया गया, जिससे Cox Panoramic Wifi gateway के पीछे मौजूद कई devices का traffic बाहर expose होने के संकेत मिले
  • VirusTotal और URLscan tracking में पता चला कि वह IP पहले phishing domains और word+6 digits+TLD फॉर्मेट वाले बड़े पैमाने के domains से जुड़ा था, जिससे C&C के लिए domain generation algorithm की संभावना उठी
  • 2024 में Cox Business portal के analysis के दौरान /api/cbma/ के पीछे Spring-आधारित API और Swagger documentation expose हुए, और केवल repeated requests से authorization check bypass हो गया
  • Exposed API customers की खोज, account PII देखने, device MAC addresses देखने और WiFi settings बदलने तक की अनुमति देता था, और encryptedValue generation logic भी frontend JavaScript से call किया जा सकता था
  • Cox ने report के 6 घंटे के भीतर exposed API हटा दिया, लेकिन यह service 2023 में शुरू हुई थी, इसलिए 2021 में हुई पहली modem compromise की वजह अब भी अलग मुद्दा बनी हुई है

घर के नेटवर्क में मिले HTTP request replay

  • blind XXE vulnerability test करने के लिए AWS instance पर Python HTTP server चलाने के बाद, home computer से /test123 request भेजी
    • Original request home IP 98.161.24.100 से आई
    • करीब 10 सेकंड बाद unknown IP 159.65.76.209 ने उसी path पर request फिर से भेजी
  • iPhone Safari से भी वही URL request करने पर वही IP फिर से request replay करता दिखा
    • सिर्फ home computer नहीं, बल्कि घर के नेटवर्क के दूसरे devices पर भी यही behavior दोहराया गया
  • नए AWS instance और Nginx, GCP instance पर भी वही IP request replay कर रहा था, इसलिए AWS की अपनी समस्या होने की संभावना कम हो गई
    • बची हुई संभावनाएं ISP, modem या network path की compromise थीं
  • IP owner lookup में 159.65.76.209 DigitalOcean address निकला, ISP address नहीं था

DigitalOcean IP से जुड़ा पुराना malicious infrastructure

  • VirusTotal lookup में उस IP पर पहले resolve हुए domains मिले
    • हाल के 5 domains में से 3 phishing sites थे, और 2 mail servers जैसे दिख रहे थे
    • उदाहरण domains:
      • regional.adidas.com.py
      • isglatam.online
      • isglatam.tk
      • mx12.limit742921.tokyo
      • mx12.jingoism44769.xyz
  • isglatam.online और isglatam.tk दक्षिण अमेरिकी cybersecurity company isglatam.com को target करने वाली phishing sites थीं
    • असली ISG Latam website पर यह Paraguay-based company बताई गई है और Crowdstrike, AppGate, Acunetix, DarkTrace, ForcePoint के साथ partnerships की पुष्टि होती है
  • URLscan में दोनों domains पर सामान्य BeEF phishing site host किए जाने के निशान बचे थे
  • वही IP Adidas-related domain, ISG Latam phishing और modem traffic replay जैसी दिखने वाली activity, तीनों से जुड़ा था
    • यह भी संभव था कि IP कई owners के बीच rotate हुआ हो, लेकिन activities के बीच gap लंबा था, इसलिए तुरंत किसी दूसरे malicious user को reassign होने की संभावना कम दिखी

मॉडेम बदलना और 3 साल बाद दोबारा जांच

  • इस्तेमाल में मौजूद device Cox Panoramic Wifi gateway था, और Cox store में जाकर नया modem लिया गया
    • पुराना device ISP से rental पर था, इसलिए वापस करना पड़ा
    • Firmware dump या reverse engineering नहीं की जा सकी
  • नया modem install करने के बाद HTTP request replay पूरी तरह बंद हो गया
    • Logs में अब कोई दूसरा IP नहीं दिखा
    • उस समय पुराने modem के compromised होने के निष्कर्ष के अलावा आगे जांच करना मुश्किल था
  • 2024 की शुरुआत में, करीब 3 साल बाद security industry के परिचितों के साथ दोबारा investigation करते हुए limit742921.tokyo, jingoism44769.xyz जैसे domain formats पर ध्यान गया
    • संबंधित IPs पर reverse IP search करने पर उसी pattern के 1,000 से ज्यादा domains मिले
  • Domain format सभी में word + 6 numbers + TLD structure था
    • Bulk registration और algorithmic structure की वजह से यह malicious operator द्वारा C&C server address छिपाने के लिए इस्तेमाल किए जाने वाले domain generation algorithm जैसा दिखा
    • आखिरी observed domain 17 मार्च 2023 को registered था, और उसके बाद कोई host resolve नहीं हो रहा था
  • बदला गया नया modem भी वही model था, लेकिन Google search के आधार पर उस model की public vulnerabilities नहीं मिलीं

ISP support tools और TR-069 से शुरू हुई hypothesis

  • Cox modem को नई जगह ले जाने की प्रक्रिया में पता चला कि ISP support agent remotely device settings बदल सकता है
    • Support agent device settings update, WiFi password change और connected devices check कर सकता था
  • यह remote management 2004 में implement किए गए TR-069 protocol के जरिए होता है
    • ISP port 7547 के जरिए अपने network के अंदर devices manage करता है
    • यह protocol DEF CON presentation में भी cover हुआ था, लेकिन यह externally exposed surface नहीं था
  • Investigation का focus protocol से हटकर support agents द्वारा इस्तेमाल की जाने वाली internal device management website और उसके पीछे की API पर गया
    • अगर ऐसी API customer device settings read/change कर सकती है या commands execute कर सकती है, तो वह modem compromise path बन सकती है

Cox Business portal की API structure

  • Cox Business portal device remote management, firewall rules configuration और network traffic monitoring functions देता है
  • Login page की frontend JavaScript file main.36624ed36fb0ff5b.js से routes extract किए गए
    • /api/cbma/ based 100 से ज्यादा API calls मिलीं
    • उदाहरण:
      • /api/cbma/voicemail/services/voicemail/inbox/transcribeMessage/
      • /api/cbma/profile/services/profile/userroles/
      • /api/cbma/accountequipment/services/accountequipment/equipments/eligibleRebootDevice
  • /api/cbma/ सामान्य frontend से अलग response दिखा रहा था, इसलिए यह अलग backend की ओर जाने वाला reverse proxy जैसा लगा
    • /api/anything_else/example request 301 redirect लौटाती है
    • /api/cbma/example request 500 Internal Server Error लौटाती है
  • Registration request में authentication-related कई headers शामिल थे
    • Clientid: cbmauser
    • Apikey: 5d228662-aaa1-4a18-be1c-fb84db78cf13
    • Cb_session: unauthenticateduser
    • Authorization: Bearer undefined
  • HTTP method बदलकर देखने पर Spring-format error response मिला, जिससे backend के Spring based होने की पुष्टि हुई

Swagger documentation और static resource bypass

  • Spring actuator paths नहीं मिले, लेकिन Swagger UI paths में से कुछ accessible थे
    • /api/cbma/userauthorization/swagger-ui/index.html path ने response दिया
  • पहले load किया गया Swagger page खाली था
    • .png, .js, .css जैसे static resources API proxy के बजाय original host path पर route हो रहे थे, जिससे infinite redirect हो रहा था
  • Burp Intruder से URL के अंत में %00 से %FF तक जोड़कर test करने पर URL-encoded / यानी %2f को .js के बाद जोड़ने से 200 OK मिला
    • उदाहरण: /swagger-initializer.js%2f
  • Burp match-and-replace से सभी static resources में %2f जोड़ने पर Swagger documentation सही से load हुआ
  • कुल मिलाकर करीब 700 API calls मिलीं
    • account: 115
    • voiceutilities: 73
    • user: 70
    • datainternetgateway: 57
    • accountequipment: 55
    • billing: 53
    • ticket: 52
    • इनके अलावा profile, voicecallmanagement, voicemail, userauthorization, csr आदि
  • Devices और customer accounts से सीधे जुड़ी APIs में accountequipment, datainternetgateway, account सबसे महत्वपूर्ण दिखीं

Repeated requests से हुआ authorization check bypass

  • सभी GET endpoints पर बिना authentication access संभव है या नहीं, यह जांचने पर कुछ ने auth error लौटाया और कुछ ने 200 OK लौटाया
  • profilesearch endpoint ने शुरू में empty search results वाला success response लौटाया
    • वही request कभी Authorization Error-Invalid User Token लौटाती, और फिर भेजने पर success हो जाती थी
  • एक ही request को कई बार resend करने पर authorization error गायब हो गया और customer search results लौटने लगे
    • cox search पर 10000+ hits लौटे
    • fbi search पर Cox business customers FBI field offices के physical addresses वाले results लौटे
  • सिर्फ API request repeat करके authorization bypass संभव था, और यही समस्या 700 से ज्यादा APIs में फैली लग रही थी

Customer devices access और account lookup

  • Cox Business API residential network devices तक भी access कर सकती है या नहीं, यह देखने के लिए MAC address लेने वाली simple API test की गई
    • Endpoint: /api/cbma/accountequipment/services/accountequipment/ipAddress?macAddress=:mac
  • अपने Cox account से MAC address देखने के बाद request repeat करने पर अपने modem का IPv4 address लौटा
    • इससे पुष्टि हुई कि यह API सच में Cox devices से communicate कर सकती है
  • Account ID इस्तेमाल करने वाली device list API भी काम कर रही थी
    • Endpoint: /api/cbma/accountequipment/services/accountequipment/v1/equipments/{accountId}
    • Response में internet device, voice device और TV device information शामिल थी
    • Device model, device type, MAC address, port list और serial number लौटे
  • Email-based user lookup API ने भी business account information लौटाई
    • Example request: /api/cbma/user/services/user/admin@cox.net
    • Email, name, phone number, status, permissions, profile owner status, alternate email आदि शामिल थे
  • इसी तरह की POST account update request भी काम कर रही थी, जिससे business account पर read और write access संभव होने की पुष्टि हुई

encryptedValue और device settings बदलना

  • Hardware settings change requests में encryptedValue नाम का parameter चाहिए था
    • जैसे: device password change, WiFi settings change
  • Frontend JavaScript में encryptedValue generate/decrypt करने का logic trace किया गया
    • encryptWithSaltandPadding
    • decryptWithSaltandPadding
  • Account registration के दौरान set होने वाला 4-digit PIN भी इसी function से encrypt हो रहा था, इसलिए browser debugger में उस function call point पर breakpoint लगाकर console से सीधे call किया जा सकता था
  • Actual account response से मिले encryptedValue को decrypt करने पर इस format की values मिलीं
    • Cox account number
    • Device name
    • Device ID
    • Unknown value
    • MAC address
    • Label
  • Account number आदि में अधिकांश जगह arbitrary values डालकर और सिर्फ MAC address valid रखकर नया encryptedValue generate करने पर भी request successful रही
    • Server ने account ID और MAC address के match होने की जांच नहीं की

किसी भी modem की settings बदलने की संभावना

  • अपने device पर WiFi SSID को Curry में बदलने वाली POST request भेजी गई
    • Endpoint: /api/cbma/accountequipment/services/accountequipment/gatewaydevice/wifisettings
    • Request body में wifiSettings, additionalProperties, encryptedValue शामिल थे
  • Response {"message": "Success"} था, और बाद में network कुछ समय के लिए disconnect होकर करीब 5 मिनट बाद reboot हुआ
    • SSID सच में Curry में बदल गया
  • इस behavior ने दिखाया कि API के जरिए device configuration changes सच में device पर apply होते हैं
    • Attacker customer search से account UUID हासिल कर सकता है
    • Connected device का MAC address lookup कर सकता है
    • MAC address के आधार पर device settings read या change कर सकता है
  • यह permission ISP support team जैसी level की access थी, और Cox devices की लाखों units को affect कर सकने वाला path था

Impact scope और attack scenarios

  • Vulnerability combination दिखाता है कि external attacker बिना किसी precondition के ये कर सकता है
    • लाखों modems पर command execution और settings change
    • Cox Business customers की PII access
    • ISP support team जैसी permissions हासिल करना
  • Cox अमेरिका का सबसे बड़ा private broadband provider, तीसरा सबसे बड़ा cable TV provider और सातवां सबसे बड़ा telephone operator है, और 10 states में सबसे popular ISP है
  • Example attack flow:
    • Name, phone number, email, account number से Cox Business target search करना
    • Returned UUID से full account PII और device MAC address, email, phone number, address lookup करना
    • Hardware MAC address से WiFi password और connected devices lookup करना
    • Arbitrary command execution, device properties change, victim account takeover
  • 700 से ज्यादा exposed APIs में से काफी admin functions देती थीं, और repeated requests से वही permission issue होता था

Cox को report और fix

  • Vulnerability Cox के responsible disclosure program के जरिए report की गई
  • Cox ने report के 6 घंटे के भीतर exposed API calls हटा दिए और authorization vulnerability fix पर काम शुरू किया
    • अगले दिन vulnerabilities reproduce नहीं हो पा रही थीं
  • Public timeline:
    • 2024-03-04: Cox को vulnerability report की
    • 2024-03-05: hotpatch apply, non-essential business endpoints 403 लौटाते हुए बंद हुए
    • 2024-03-06: Cox को email से बताया कि vulnerability reproduce नहीं हो रही
    • 2024-03-07: Cox ने जवाब दिया कि comprehensive security review शुरू किया जा रहा है
    • 2024-04-10: Cox को report के 90 दिन बाद public disclosure की मंशा बताई
    • 2024-04-29: blog draft link Cox के साथ share किया

बाकी सवाल

  • Cox ने specific vulnerability path के past exploitation की जांच की और पुष्टि की कि exploitation history नहीं है
    • यह service 2023 में operation में आई थी
    • पहली modem compromise 2021 में हुई थी, इसलिए disclosed Cox Business API vulnerability उस समय की compromise का cause नहीं थी
  • Cox ने बताया कि DigitalOcean IP से उसका कोई संबंध नहीं है
    • Device सच में hack हुआ था, लेकिन disclosed API vulnerability से अलग तरीके से
  • Modem को externally accessible configure नहीं किया गया था, और घर के network से device में login भी नहीं किया गया था
    • संभावित दूसरे paths में local CSRF से RCE तक जाने वाला 0day जैसे तरीके का जिक्र हुआ
  • सबसे बड़ा सवाल यह है कि attacker ने HTTP requests replay क्यों किए
    • अगर वह network के अंदर था, तो बिना पकड़े access कर सकता था, फिर भी हर HTTP request replay करने की वजह पता नहीं चली

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

1 टिप्पणियां

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

  • अच्छा लेख था और समझने में आसान था। खास तौर पर यह अच्छा लगा कि Cox ने रिपोर्ट करने वाले पर हमला नहीं किया या समस्या से इनकार नहीं किया, बल्कि ऐसी स्थिति में जिस तरह की ज़िम्मेदार security response की उम्मीद की जाती है, उसका उदाहरण पेश किया
    मैं किसी follow-up लेख में देखना चाहूँगा कि वह bug क्या था जिसकी वजह से अनधिकृत API access बीच-बीच में allowed हो रहा था। ऐसी गलतियाँ हल्के-फुल्के testing में आसानी से छूट सकती हैं, या कारण पर निर्भर करते हुए test environment में शायद बिल्कुल reproduce ही न हों

    • Cox ने ज़िम्मेदारी से response दिया, यह सही है, लेकिन जब कोई शुरुआत में infected device लेकर आया था, तो अच्छा होता अगर वे उस मौके का और बेहतर इस्तेमाल करते
      पहले एक traditional telecom company में मुझे संयोग से एक गंभीर vulnerability मिली थी, लेकिन सिर्फ़ सामान्य customer support channel के ज़रिए सही व्यक्ति तक पहुँचने में लगभग एक हफ्ता लग गया, और support organization बिल्कुल escalation नहीं कर पाया। Cox के पास भी एक information security professional infected device लेकर सीधे आया था, लेकिन support organization उसे ठीक से handle नहीं कर पाया
    • लेख पढ़ने में भी आसान था और Cox का response भी अच्छा था। यह भी पसंद आया कि discovery process और bug को नकारात्मक या तिरस्कारपूर्ण अंदाज़ में पेश नहीं किया गया
    • कंपनियों को ऐसी चीज़ खोजने वाले व्यक्ति पर “hacking” का मुकदमा करने के बजाय उसे reward करना चाहिए
    • मुझे भी उत्सुकता है कि वह bug क्या था जिसने अनधिकृत API access को intermittent तरीके से allow किया। शायद हम कभी न जान पाएं, लेकिन हो सकता है कि load balancer configuration में गलती से कोई ऐसा test backend शामिल हो गया हो जो authorization checks नहीं करता
    • लेख अच्छा था, लेकिन “super curious”, “super interesting”, “super interested” जैसे super का बार-बार इस्तेमाल थोड़ा खटका

  • ऐसी स्थिति में झुंझलाहट तब होती है जब ISP अपने ही modem या router का इस्तेमाल जबरन करवाता है। उदाहरण के लिए AT&T fiber network access के लिए certificate-based 802.1X authentication करता है; इसके बिना ONT में कोई भी device plug किया जा सकता था
    bypass के तरीके हैं या थे, लेकिन सिर्फ़ internet इस्तेमाल करने के लिए वह प्रक्रिया अपनाना मुझे पसंद नहीं, इसलिए मैं AT&T router की सारी सुविधाएँ बंद करके अपने router को उसके पीछे लगाता हूँ, जिसे मैं updated रखता हूँ। अगर AT&T router hack हो जाए, तो service पर बुरा असर पड़ने तक शायद मुझे पता भी न चले। अच्छा है कि आजकल ज़्यादातर HTTPS इस्तेमाल होता है

    • अगर ONT modem से अलग AT&T fiber है, तो 802.1X bypass काफ़ी आसान है। modem और ONT के बीच एक unmanaged switch लगाइए, modem को authenticate करने दीजिए, फिर modem निकाल दीजिए
      ONT reboot हो जाए तो शायद यह फिर करना पड़े, लेकिन मेरे मामले में AT&T ने ONT के लिए UPS दिया है, इसलिए reboot कम होंगे। निजी तौर पर मैंने bypass NIC आधारित एक जटिल setup बनाया था, जिसमें firewall बंद हो या reboot हो रहा हो तो traffic AT&T modem से होकर जाता है, और चालू होने पर मेरा firewall traffic लेकर उसे चुनिंदा रूप से modem के ज़रिए आगे भेजता है; लेकिन सच कहें तो सिर्फ़ unmanaged switch भी पर्याप्त है
    • AT&T CPE router के hack होने की संभावना, अगर मेरे network और AT&T network के बीच मेरा router है, तो बहुत बड़ा फर्क नहीं डालती। AT&T CPE router हटाने पर भी अंततः आप एक ऐसे black box से जुड़े होते हैं जिसे आप control नहीं करते, और वह device भी hack हुआ हो सकता है या traffic को कई तरीकों से inspect कर सकता है
    • अच्छी बात है कि Cox ऐसा ISP नहीं है। आपके subscribed speed के हिसाब से पर्याप्त आधुनिक DOCSIS modem हो तो वे उसे accept कर लेते हैं
      लेकिन Cox की तारीफ़ यहीं तक है। मैं 2 साल से intermittent packet loss झेल रहा हूँ, और भले ही मैं यह data इकट्ठा कर लूँ कि कोई particular node शायद oversubscribed है, ऐसा support escalation path दिखता ही नहीं जिससे बात किसी ऐसे व्यक्ति तक पहुँचे जो इसे समझ सके
    • संदर्भ के लिए, xgspon में अब bypass प्रक्रिया automated है। यह बस “SFP+ लगाना, web interface से firmware upload करना, device serial number दर्ज करना” जितनी ही है, और इस्तेमाल किए जा रहे SFP module के आधार पर दूसरा step भी छोड़ा जा सकता है
      असल में 802.1X status server-side verify नहीं होता। standard कहता है कि अगर 802.1X required है और perform नहीं हुआ, तो modem को traffic आगे नहीं भेजना चाहिए, लेकिन ज़्यादातर device बस भेज देते हैं या ऐसा करने के लिए बदले जा सकते हैं। AT&T की तरफ verification नहीं होता और traffic हमेशा pass हो जाता है; internally भी यही हो रहा है
    • AT&T gateway के बिना connect करने के तरीके मौजूद हैं, और कई तरीके https://pon.wiki/ परまとめे गए हैं

  • लेख अच्छा और पढ़ने में सहज है, और investigation भी शानदार है। यह देखना भी अच्छा है कि कोई बड़ी company security researcher पर nuclear bomb नहीं गिरा रही
    पक्का नहीं कह सकता, लेकिन मुझे शक है कि इस Nokia router के local admin interface requests सही से authenticate होते हैं या नहीं। हाल ही में मुझे यही equipment मिला था, और कुछ settings ऐसी थीं जिन्हें general admin rights से बदला नहीं जा सकता था, और ISP ने super admin account नहीं दिया था। लेकिन page inspector से disabled fields को फिर enable करके values बदलने पर API ने उन्हें वैसे ही accept कर लिया। ऐसी स्थिति में अगर internal network के अंदर कोई application run हो सके, तो इस तरह router को takeover करना मुश्किल नहीं होगा, हालांकि यह काफी specific condition लगती है

    • Cox अमेरिका का सबसे बड़ा private broadband provider, तीसरा cable TV provider, सातवाँ telephone operator है और 10 राज्यों में सबसे लोकप्रिय ISP है—यह बात सोचने पर मजबूर करती है कि ISP इतने बड़े नहीं होने चाहिए
      Cox साफ़ तौर पर एक आकर्षक attack target है, और article के example की तरह एक single vulnerability से FBI field office तक खतरे में पड़ सकता है। “Cox ने past exploitation की जांच की और कोई record नहीं मिला” की जगह “जांच करने का दावा किया” लिखना शायद ज़्यादा सही होता

  • क्या “past exploitation history नहीं थी” वाली बात पर भरोसा किया जा सकता है? पूरा network Swiss cheese जैसा छेदों से भरा दिखता है

    • इसलिए सारे logs ऐसे AWS account के S3 bucket में भेजे जाते हैं जिसके पास सिर्फ़ write permission हो, और उस bucket पर अन्य operations कर सकने वाले account में जाने के लिए तीन लोगों की ज़रूरत बनाई जाती है। Cox ने ऐसा किया या नहीं, पता नहीं, लेकिन अगर आप इस तरह design करें कि “exploitation history नहीं है” कह सकें, तो architecture कुछ ऐसा ही होगा
    • अगर बातचीत शुरू करने वाली side आप हैं, तो आखिर तक participate न करना संभव नहीं। किसी point पर कहना ही पड़ता है, “हमारे पास जितनी जानकारी है वह यह है, और यह पहले से बेहतर है”
    • अगर वे “नहीं है” कहते हैं, तो इसका मतलब यह भी हो सकता है कि पहले से infected devices मिलने की स्थिति में Cox को ज्ञात या अज्ञात दूसरे attack paths मौजूद हैं

  • कई routers में firmware को manually update करना पड़ता है। GL.iNet routers में पिछले 6 महीनों में कई remote code execution vulnerabilities रही हैं, इसलिए जल्दी से जांच लेना बेहतर है कि आपका router hack तो नहीं हुआ, और संभव हो तो firmware upgrade कर लें
    आम user के नज़रिए से दिखने वाले symptoms थे internet speed कम होना, Wi-Fi signal टूटना और devices का connect न हो पाना, और router खुद internet से जुड़ा होने के बावजूद internal admin page (192.168.8.1) का respond न करना। मेरे मामले में attacker ने IPRoyal का Pawns app install करके router को proxy server बना दिया और पैसे कमाए; उसने usage time और NAS connection status वाले system logs भी चुराए, और उसके पास reverse shell भी था। समाधान के लिए बेहतर क्रम है: firmware update, router reset करके malware हटाना, SSH disable करना, और dynamic DNS जैसे remote access को बंद करना। अगर remote access चाहिए, तो Cloudflare Tunnel, Zero Trust, GoodCloud, ZeroTier, Tailscale जैसी चीज़ों पर विचार कर सकते हैं, लेकिन कौन-सा option सही है, यह मुझे ठीक से नहीं पता। GL.iNet least privilege principle का पालन नहीं करता और by default processes को root के रूप में चलाता है; SSH भी root access के साथ default enabled है, इसलिए इससे बचना बेहतर लगता है

  • “exploitation history नहीं थी” का मतलब यह भी हो सकता है कि शुरुआत से logs या audit material पर्याप्त नहीं थे, या hack के बाद logs बचे ही नहीं थे

    • लेख में जो देखा, उसके हिसाब से “unauthorized request को सफल होने तक retry” करने वाला खास attack path logs में बहुत आसानी से दिखता है। path, IP, status code ही दर्ज करने वाली basic logging policy भी काफी होती, और यह ज्यादातर web servers और frameworks के defaults के करीब है
    • “सबूत न होना, अनुपस्थिति का सबूत नहीं है” यहां ठीक बैठता है
    • या फिर उन्होंने झूठ बोला हो सकता है। Cox के दृष्टिकोण से सोचें तो अगर पहले exploitation history रही भी हो, तो वे company के बाहर किसी को क्यों बताएंगे? असल में कुछ भी disclose करने की कोई वजह नहीं है

  • कौन-सा authentication system calls को कभी-कभी random तरीके से pass कर देता है? सच में अक्षम लगता है

    • मैंने vendor API में ऐसा देखा है। current user provider को request-level पर नहीं बल्कि singleton के रूप में register कर दिया गया था, इसलिए कभी-कभी authenticated user की tail में साथ निकल जाना संभव था
    • इसी तरह का बड़ा bug देखा है। API ठीक 10 मिनट तक unauthenticated requests reject करती थी, फिर ठीक 1 मिनट के लिए allow करती थी, और यह cycle endlessly repeat होता था। backend में क्या हो रहा था, यह सच में जानना चाहूंगा
    • मेरे अनुभव में ऐसी चीज़ load balancer की वजह से हो सकती है। जैसे pool के servers तक सही routing न होना, या servers के बीच configuration या patch level अलग-अलग होना
    • जिन origin servers पर request route हो रही थी, उनमें से कुछ misconfigured भी हो सकते थे
    • अगर API reverse proxy के पीछे थी, तो यह cache issue भी हो सकता था

  • पैसे दिए क्या? इस व्यक्ति ने Cox को practically बचा लिया और security infrastructure के complete takeover के बारे में बताया, जिसे ढूंढना भी आसान नहीं था
    “सही काम” करने के बदले उसे कुछ नहीं मिला लगता है, जो काफी अपमानजनक है। महत्वपूर्ण जानकारी लेकर office तक पहुंचे व्यक्ति को company ने कैसे देखा होगा—उसकी अपनी self-perception और company की perception बहुत अलग रही होगी। ऐसे मामले साफ दिखाते हैं कि 0day कभी report क्यों नहीं करना चाहिए

    • Cox के लिहाज से, अपनी गलती सुधारने वाले व्यक्ति पर lawsuit न करना ही शायद उसका luck हो सकता है
    • Sam बहुत प्रसिद्ध security researcher हैं, इसलिए अगर वे सालाना 350,000 dollars से अधिक कमाते हों तो आश्चर्य नहीं होगा। ऐसे posts reputation boost के जरिए काफी पैसा बन जाते हैं
    • Cox bug bounty नहीं देता

  • अभी खुला सवाल यह है कि attackers ने उसका HTTP traffic कैसे पकड़ा
    कुछ CPE में debugging के लिए cloud Wireshark जैसी सुविधा होती है। Cox के production firmware image में ऐसी सुविधा है या नहीं, पता नहीं। आम तौर पर production firmware और test firmware अलग-अलग होते हैं, जिससे production issues को test करना और मुश्किल हो जाता है। Cox यह check कर सकता होगा कि field में कौन-कौन से firmware versions हैं; ISP किसी खास version से mismatch करने वाले firmware को auto-upgrade कर सकता है, और यह Cox modem है, इसलिए उनके पास firmware भी होने की काफी संभावना है। अगर यह debug firmware था, तो यह कैसे चढ़ा और लगातार कैसे बना रहा, यह जानना चाहूंगा

    • Linux में PF_PACKET से socket बनाने पर सभी interfaces का traffic intercept किया जा सकता है। इसे low-level tcpdump जैसा समझें
      port 80 का सारा data intercept करके HTTP headers parse करना और फिर जरूरी काम करना आसान है। हालांकि किसी ने requests replay क्यों कीं, यह मुझे ठीक से समझ नहीं आता
    • अगर HTTPS नहीं बल्कि HTTP है, तो wire पर मौजूद कोई भी व्यक्ति या कोई भी equipment request देख सकता है
    • ISP-provided equipment पर भरोसा न करने और उसे न इस्तेमाल करने की एक और वजह। ISP की remote management? नहीं चाहिए

  • Wi-Fi capability वाले ISP-provided cable modem का स्वागत नहीं करना चाहिए, और LAN के अंदर endpoints और services की security ठीक रखने की यह एक वजह है। कम से कम modem/ISP segment में TLS और DNS over TLS चाहिए
    मैं तो इसे बस bridge mode में रखता हूं, Wi-Fi बंद कर देता हूं, और सभी network functions मेरे अपने equipment को संभालने देता हूं। आखिरी बार ISP से rent किया modem ऐसा था जिसे ISP ने करीब 10 साल तक firmware update नहीं किया था; इससे वह काफी stable जरूर था

    • counterargument भी है। 10 लाख से ज्यादा customers वाले ISP के पास capex cost घटाने के लिए home gateways को “हमेशा” upgrade करते रहने की incentive होती है
      जहां मैं काम करता हूं, Free एक French ISP है और Iliad के जरिए Italy में भी home gateways देता है; 2011 में launch हुए devices को भी अभी तक update करता है। उन पर latest Linux 6.4 चलता है, airtime QoS जैसे modern features, mobile app updates और कई software features भी मिलते हैं
    • routers धरती पर सबसे ज्यादा exploited IoT devices में से हैं, और end users patch नहीं करते, इसलिए firmware vulnerabilities अक्सर सालों तक बची रहती हैं। अगर ISP routers पर patches push कर सके और unpatchable devices वापस ले सके, तो ownership ISP के पास होने की बात समेत, cybersecurity के लिए यह net positive है
    • मैं भी bridge mode में रखता हूं और Wi-Fi बंद रखता हूं। संयोग से मैंने ऐसा simple modem install करवा लिया जिसमें router और access point functions नहीं हैं; मुझे पता नहीं था कि ऐसे single-purpose devices अब भी मौजूद हैं
      मैंने comparatively decent router खरीदा, उस पर OpenWrt install किया, और ISP equipment के जरिए network से bridge के रूप में जोड़ा; यह अच्छी तरह काम करता है। अब मैं LAN के अंदर भी HTTPS इस्तेमाल करता हूं
    • मैंने ISP से कहा कि अगर वे मुझे अपना router इस्तेमाल नहीं करने देंगे, तो मैं किसी दूसरे ISP पर switch कर जाऊंगा