การแฮ็กโมเด็มนับล้านเครื่อง และการสืบสวนการบุกรุกโมเด็มของฉัน

• พบเบาะแสว่าทราฟฟิกจากอุปกรณ์หลายเครื่องหลังเกตเวย์ Cox Panoramic Wifi ถูกเปิดเผยออกไปภายนอก เมื่อคำขอ HTTP จากเครือข่ายที่บ้านถูกเล่นซ้ำแบบเดิมจาก IP ของ DigitalOcean หลังจากนั้นประมาณ 10 วินาที
• จากการติดตามผ่าน VirusTotal และ URLscan พบว่า IP ดังกล่าวเคยเชื่อมโยงกับ โดเมนฟิชชิง และโดเมนจำนวนมากในรูปแบบ word+6 digits+TLD ทำให้เกิดข้อสงสัยว่าอาจเป็นอัลกอริทึมสร้างโดเมนสำหรับ C&C
• ระหว่างการวิเคราะห์พอร์ทัล Cox Business ในปี 2024 มีการเปิดเผย API ที่ใช้ Spring หลัง /api/cbma/ และเอกสาร Swagger และเกิดการ บายพาสการตรวจสอบสิทธิ์ ได้เพียงส่งคำขอซ้ำ ๆ
• API ที่เปิดเผยอนุญาตให้ค้นหาลูกค้า ดู PII ของบัญชี ดู MAC address ของอุปกรณ์ ไปจนถึงเปลี่ยนการตั้งค่า WiFi ได้ และลอจิกสร้าง encryptedValue ก็สามารถเรียกจาก JavaScript ฝั่งฟรอนต์เอนด์ได้
• Cox ปิด API ที่เปิดเผยภายใน 6 ชั่วโมงหลังได้รับรายงาน แต่บริการนี้เริ่มในปี 2023 ดังนั้นสาเหตุของการบุกรุกโมเด็มครั้งแรกในปี 2021 จึงยังเป็นคนละประเด็นอยู่

---

การเล่นซ้ำคำขอ HTTP ที่พบในเครือข่ายบ้าน

• หลังจากเปิดเซิร์ฟเวอร์ HTTP ด้วย Python บนอินสแตนซ์ AWS เพื่อทดสอบช่องโหว่ blind XXE ก็ส่งคำขอ /test123 จากคอมพิวเตอร์ที่บ้าน
  • คำขอต้นทางมาจาก IP ที่บ้าน 98.161.24.100
  • ประมาณ 10 วินาทีต่อมา IP ไม่ทราบที่มา 159.65.76.209 ส่งคำขอไปยังพาธเดียวกันอีกครั้ง
• เมื่อเรียก URL เดียวกันจาก iPhone Safari ก็พบว่า IP เดิมเล่นซ้ำคำขออีกครั้ง
  • ปรากฏการณ์เดียวกันเกิดซ้ำไม่ใช่แค่จากคอมพิวเตอร์ที่บ้าน แต่รวมถึง อุปกรณ์อื่นในเครือข่ายบ้าน ด้วย
• แม้ใช้ AWS instance ใหม่พร้อม Nginx และ GCP instance ก็ยังมี IP เดิมเล่นซ้ำคำขอ ทำให้ความเป็นไปได้ว่าเป็นปัญหาของ AWS เองลดลง
  • ความเป็นไปได้ที่เหลือคือ ISP, โมเด็ม หรือเส้นทางเครือข่ายถูกบุกรุก
• จากการตรวจสอบเจ้าของ IP พบว่า 159.65.76.209 เป็นที่อยู่ของ DigitalOcean ไม่ใช่ที่อยู่ของ ISP

โครงสร้างพื้นฐานอันตรายในอดีตที่เชื่อมโยงกับ IP ของ DigitalOcean

• การค้นหาใน VirusTotal พบโดเมนที่เคย resolve ไปยัง IP ดังกล่าว
  • ใน 5 โดเมนล่าสุด มี 3 โดเมนเป็นเว็บฟิชชิง และ 2 โดเมนดูเหมือนเมลเซิร์ฟเวอร์
  • ตัวอย่างโดเมน:
    • regional.adidas.com.py
    • isglatam.online
    • isglatam.tk
    • mx12.limit742921.tokyo
    • mx12.jingoism44769.xyz
• isglatam.online และ isglatam.tk เป็นเว็บฟิชชิงที่มุ่งเป้าบริษัทไซเบอร์ซีเคียวริตี้ในอเมริกาใต้ isglatam.com
  • เว็บไซต์จริงของ ISG Latam ระบุว่าเป็นบริษัทในปารากวัย และเป็นพันธมิตรกับ Crowdstrike, AppGate, Acunetix, DarkTrace, ForcePoint
• ใน URLscan มีร่องรอยว่าโดเมนทั้งสองเคยโฮสต์ เว็บฟิชชิง BeEF ทั่วไป
  • บันทึกที่เกี่ยวข้อง: ผลลัพธ์ URLscan
• IP เดียวกันเชื่อมโยงกับทั้งโดเมนเกี่ยวกับ Adidas, ฟิชชิง ISG Latam และกิจกรรมที่ดูเหมือนการเล่นซ้ำทราฟฟิกโมเด็ม
  • แม้มีความเป็นไปได้ว่า IP ถูกหมุนเวียนระหว่างเจ้าของหลายราย แต่ช่วงเวลาระหว่างกิจกรรมค่อนข้างยาว จึงดูไม่น่าเป็นไปได้ว่าจะถูกจัดสรรใหม่ให้ผู้ใช้ประสงค์ร้ายรายอื่นทันที

การเปลี่ยนโมเด็มและการสืบสวนซ้ำหลังผ่านไป 3 ปี

• อุปกรณ์ที่ใช้อยู่คือ Cox Panoramic Wifi gateway และได้เปลี่ยนเป็นโมเด็มใหม่ที่ร้าน Cox
  • อุปกรณ์เดิมเป็นอุปกรณ์ที่เช่าจาก ISP จึงต้องส่งคืน
  • ไม่สามารถ dump เฟิร์มแวร์หรือทำ reverse engineering ได้
• หลังติดตั้งโมเด็มใหม่ ปรากฏการณ์เล่นซ้ำคำขอ HTTP ก็หยุดลงอย่างสมบูรณ์
  • ไม่มี IP อื่นปรากฏใน log อีก
  • ในตอนนั้นยากที่จะสืบสวนเพิ่มเติมนอกจากสรุปว่าโมเด็มเดิมถูกบุกรุก
• ต้นปี 2024 หรือประมาณ 3 ปีให้หลัง เมื่อกลับมาสืบสวนอีกครั้งกับคนรู้จักในวงการความปลอดภัย จึงสังเกตรูปแบบโดเมนอย่าง limit742921.tokyo, jingoism44769.xyz
  • เมื่อทำ reverse IP search กับ IP ที่เกี่ยวข้อง พบโดเมนรูปแบบเดียวกันมากกว่า 1,000 โดเมน
• รูปแบบโดเมนทั้งหมดเป็นโครงสร้าง word + 6 numbers + TLD
  • จากการจดทะเบียนจำนวนมากและโครงสร้างเชิงอัลกอริทึม จึงดูเหมือน อัลกอริทึมสร้างโดเมน ที่ผู้ปฏิบัติการประสงค์ร้ายใช้ซ่อนที่อยู่เซิร์ฟเวอร์ C&C
  • โดเมนล่าสุดที่พบถูกจดทะเบียนเมื่อวันที่ 17 มีนาคม 2023 และหลังจากนั้นก็ไม่มีโฮสต์ที่ resolve ได้อีก
• โมเด็มใหม่ที่เปลี่ยนก็เป็นรุ่นเดียวกัน แต่จากการค้นหา Google ไม่พบช่องโหว่สาธารณะของรุ่นดังกล่าว

สมมติฐานที่เริ่มจากเครื่องมือซัพพอร์ตของ ISP และ TR-069

• ระหว่างย้ายโมเด็ม Cox ไปยังสถานที่ใหม่ พบว่าเจ้าหน้าที่ซัพพอร์ตของ ISP สามารถเปลี่ยนการตั้งค่าอุปกรณ์จากระยะไกลได้
  • เจ้าหน้าที่ซัพพอร์ตสามารถอัปเดตการตั้งค่าอุปกรณ์ เปลี่ยนรหัสผ่าน WiFi และดูอุปกรณ์ที่เชื่อมต่อได้
• การจัดการจากระยะไกลลักษณะนี้ทำผ่านโปรโตคอล TR-069 ที่เริ่มใช้ตั้งแต่ปี 2004
  • เป็นวิธีที่ ISP ใช้จัดการอุปกรณ์ในเครือข่ายของตนผ่านพอร์ต 7547
  • โปรโตคอลนี้เคยถูกพูดถึงในงาน DEF CON แต่ไม่ได้เป็นพื้นผิวที่เปิดเผยต่อภายนอก
• จุดสนใจของการสืบสวนจึงย้ายจากตัวโปรโตคอลไปยังเว็บไซต์จัดการอุปกรณ์ภายในที่เจ้าหน้าที่ใช้ และ API เบื้องหลัง
  • หาก API เหล่านี้สามารถดูหรือเปลี่ยนการตั้งค่าอุปกรณ์ลูกค้า หรือสั่งรันคำสั่งได้ ก็อาจเป็นเส้นทางบุกรุกโมเด็มได้

โครงสร้าง API ของพอร์ทัล Cox Business

• พอร์ทัล Cox Business มีฟังก์ชันจัดการอุปกรณ์จากระยะไกล ตั้งกฎไฟร์วอลล์ และมอนิเตอร์ทราฟฟิกเครือข่าย
• แยก route จากไฟล์ JavaScript ฝั่งฟรอนต์เอนด์ของหน้าเข้าสู่ระบบ main.36624ed36fb0ff5b.js
  • พบการเรียก API ที่มีฐานเป็น /api/cbma/ มากกว่า 100 รายการ
  • ตัวอย่าง:
    • /api/cbma/voicemail/services/voicemail/inbox/transcribeMessage/
    • /api/cbma/profile/services/profile/userroles/
    • /api/cbma/accountequipment/services/accountequipment/equipments/eligibleRebootDevice
• /api/cbma/ แสดง response ต่างจากฟรอนต์เอนด์ทั่วไป จึงดูเหมือน reverse proxy ที่ชี้ไปยังแบ็กเอนด์แยกต่างหาก
  • คำขอ /api/anything_else/example คืนค่า 301 redirect
  • คำขอ /api/cbma/example คืนค่า 500 Internal Server Error
• คำขอลงทะเบียนมี header ที่เกี่ยวกับการยืนยันตัวตนหลายรายการ
  • Clientid: cbmauser
  • Apikey: 5d228662-aaa1-4a18-be1c-fb84db78cf13
  • Cb_session: unauthenticateduser
  • Authorization: Bearer undefined
• เมื่อเปลี่ยน HTTP method ได้รับ response ข้อผิดพลาดรูปแบบ Spring ยืนยันได้ว่าแบ็กเอนด์ใช้ Spring

เอกสาร Swagger และการบายพาส static resource

• ไม่พบพาธ Spring actuator แต่เข้าถึงบางส่วนของพาธ Swagger UI ได้
  • พาธ /api/cbma/userauthorization/swagger-ui/index.html ตอบกลับ
• หน้า Swagger ที่โหลดครั้งแรกว่างเปล่า
  • static resource เช่น .png, .js, .css ถูก route ไปยังพาธ host เดิม ไม่ใช่ API proxy ทำให้เกิด redirect วนไม่รู้จบ
• เมื่อใช้ Burp Intruder ทดสอบด้วยการต่อท้าย URL ด้วย %00 ถึง %FF พบว่าเมื่อใส่ %2f ซึ่งเป็น / แบบ URL-encoded ต่อหลัง .js จะได้ 200 OK
  • ตัวอย่าง: /swagger-initializer.js%2f
• เมื่อตั้ง Burp match-and-replace ให้เติม %2f ให้ static resource ทั้งหมด เอกสาร Swagger ก็โหลดได้ตามปกติ
• โดยรวมพบการเรียก API ประมาณ 700 รายการ
  • account: 115 รายการ
  • voiceutilities: 73 รายการ
  • user: 70 รายการ
  • datainternetgateway: 57 รายการ
  • accountequipment: 55 รายการ
  • billing: 53 รายการ
  • ticket: 52 รายการ
  • รวมถึง profile, voicecallmanagement, voicemail, userauthorization, csr และอื่น ๆ
• API ที่เกี่ยวข้องโดยตรงกับอุปกรณ์และบัญชีลูกค้าดูเหมือนจะเป็น accountequipment, datainternetgateway, account ซึ่งสำคัญที่สุด

การบายพาสการตรวจสอบสิทธิ์ที่เกิดจากการส่งคำขอซ้ำ

• เมื่อตรวจสอบว่า endpoint แบบ GET ทั้งหมดเข้าถึงได้โดยไม่ต้องยืนยันตัวตนหรือไม่ บางรายการคืนข้อผิดพลาดการยืนยันตัวตน และบางรายการคืน 200 OK
• endpoint profilesearch ช่วงแรกคืน response สำเร็จพร้อมผลค้นหาว่าง
  • คำขอเดียวกันบางครั้งคืน Authorization Error-Invalid User Token และเมื่อส่งใหม่ก็สำเร็จอีกครั้ง
• เมื่อส่งคำขอเดิมซ้ำหลายครั้ง ข้อผิดพลาดด้านสิทธิ์จะหายไปและคืนผลค้นหาลูกค้า
  • การค้นหา cox คืนค่า 10000+ hits
  • การค้นหา fbi คืนผลลัพธ์ที่มีที่อยู่จริงของสำนักงานภาคสนาม FBI ซึ่งเป็นลูกค้า Cox Business
• แค่ส่งคำขอ API ซ้ำก็สามารถ บายพาสสิทธิ์ ได้ และปัญหาเดียวกันดูเหมือนส่งผลกระทบต่อ API มากกว่า 700 รายการโดยรวม

การเข้าถึงอุปกรณ์ลูกค้าและการดูบัญชี

• เพื่อยืนยันว่า Cox Business API เข้าถึงอุปกรณ์เครือข่ายที่อยู่อาศัยได้หรือไม่ จึงทดสอบ API ง่าย ๆ ที่รับ MAC address
  • Endpoint: /api/cbma/accountequipment/services/accountequipment/ipAddress?macAddress=:mac
• หลังตรวจสอบ MAC address จากบัญชี Cox ของตนเองแล้วส่งคำขอซ้ำ ก็ได้รับ IPv4 address ของโมเด็มตนเอง
  • ยืนยันได้ว่า API นี้สามารถสื่อสารกับอุปกรณ์ Cox จริงได้
• API รายการอุปกรณ์ที่ใช้ account ID ก็ทำงานได้เช่นกัน
  • Endpoint: /api/cbma/accountequipment/services/accountequipment/v1/equipments/{accountId}
  • response มีข้อมูลอุปกรณ์อินเทอร์เน็ต อุปกรณ์เสียง และอุปกรณ์ทีวี
  • คืนค่ารุ่นอุปกรณ์ ประเภทอุปกรณ์ MAC address รายการพอร์ต และ serial number
• API ค้นหาผู้ใช้จากอีเมลก็คืนข้อมูลบัญชีธุรกิจ
  • ตัวอย่างคำขอ: /api/cbma/user/services/user/[e-mail]
  • มีอีเมล ชื่อ หมายเลขโทรศัพท์ สถานะ สิทธิ์ สถานะเจ้าของโปรไฟล์ และอีเมลสำรอง
• คำขออัปเดตบัญชีแบบ POST ที่คล้ายกันก็ทำงานได้ ยืนยันได้ว่าสามารถ อ่านและเขียน บัญชีธุรกิจได้

encryptedValue และการเปลี่ยนการตั้งค่าอุปกรณ์

• คำขอเปลี่ยนการตั้งค่าฮาร์ดแวร์ต้องมีพารามิเตอร์ชื่อ encryptedValue
  • เช่น เปลี่ยนรหัสผ่านอุปกรณ์ เปลี่ยนการตั้งค่า WiFi
• ติดตามลอจิกสร้างและถอดรหัส encryptedValue ใน JavaScript ฝั่งฟรอนต์เอนด์
  • encryptWithSaltandPadding
  • decryptWithSaltandPadding
• PIN 4 หลักที่ตั้งตอนลงทะเบียนบัญชีก็ถูกเข้ารหัสด้วยฟังก์ชันเดียวกัน จึงสามารถตั้ง breakpoint ใน browser debugger ณ จุดที่ฟังก์ชันนั้นถูกเรียก แล้วเรียกโดยตรงจากคอนโซลได้
• เมื่อถอดรหัส encryptedValue ที่ได้จาก response ของบัญชีจริง พบค่าในรูปแบบต่อไปนี้
  • หมายเลขบัญชี Cox
  • ชื่ออุปกรณ์
  • ID อุปกรณ์
  • ค่าที่ไม่ทราบ
  • MAC address
  • ป้ายกำกับ
• แม้ใส่ค่าตามอำเภอใจในช่องส่วนใหญ่ เช่นหมายเลขบัญชี แล้วใส่เฉพาะ MAC address ที่ถูกต้องเพื่อสร้าง encryptedValue ใหม่ คำขอก็สำเร็จ
  • เซิร์ฟเวอร์ไม่ได้ตรวจสอบว่า account ID และ MAC address ตรงกันหรือไม่

ความเป็นไปได้ในการเปลี่ยนการตั้งค่าโมเด็มใดก็ได้

• ส่งคำขอ POST เพื่อเปลี่ยน WiFi SSID ของอุปกรณ์ตนเองเป็น Curry
  • Endpoint: /api/cbma/accountequipment/services/accountequipment/gatewaydevice/wifisettings
  • body ของคำขอมี wifiSettings, additionalProperties, encryptedValue
• response คือ {"message": "Success"} และหลังจากนั้นเครือข่ายหลุดไปชั่วครู่ ก่อนรีบูตประมาณ 5 นาทีต่อมา
  • SSID ถูกเปลี่ยนเป็น Curry จริง
• พฤติกรรมนี้แสดงว่าการเปลี่ยนการกำหนดค่าอุปกรณ์ผ่าน API ถูกนำไปใช้กับอุปกรณ์จริง
  • ผู้โจมตีสามารถใช้การค้นหาลูกค้าเพื่อได้ UUID ของบัญชี
  • ดู MAC address ของอุปกรณ์ที่เชื่อมต่อ
  • และอ่านหรือเปลี่ยนการตั้งค่าอุปกรณ์โดยอิงจาก MAC address ได้
• สิทธิ์นี้อยู่ในระดับใกล้เคียงกับทีมซัพพอร์ตของ ISP และเป็นเส้นทางที่อาจกระทบอุปกรณ์ Cox หลายล้านเครื่อง

ขอบเขตผลกระทบและสถานการณ์โจมตี

• การผสมผสานของช่องโหว่แสดงให้เห็นว่าผู้โจมตีภายนอกสามารถทำสิ่งต่อไปนี้ได้โดยไม่ต้องมีเงื่อนไขล่วงหน้า
  • รันคำสั่งและเปลี่ยนการตั้งค่าโมเด็มนับล้านเครื่อง
  • เข้าถึง PII ของลูกค้า Cox Business
  • ได้สิทธิ์ระดับใกล้เคียงกับทีมซัพพอร์ตของ ISP
• Cox เป็นผู้ให้บริการบรอดแบนด์เอกชนรายใหญ่ที่สุดในสหรัฐอเมริกา ผู้ให้บริการเคเบิลทีวีรายใหญ่อันดับสาม และผู้ให้บริการโทรศัพท์รายใหญ่อันดับเจ็ด อีกทั้งเป็น ISP ที่ได้รับความนิยมที่สุดใน 10 รัฐ
• ตัวอย่างลำดับการโจมตี:
  • ค้นหาเป้าหมาย Cox Business ด้วยชื่อ เบอร์โทรศัพท์ อีเมล หมายเลขบัญชี
  • ใช้ UUID ที่ได้คืนมาเพื่อดู PII บัญชีทั้งหมด รวมถึง MAC address อุปกรณ์ อีเมล เบอร์โทรศัพท์ และที่อยู่
  • ใช้ MAC address ของฮาร์ดแวร์เพื่อดูรหัสผ่าน WiFi และอุปกรณ์ที่เชื่อมต่อ
  • รันคำสั่งตามอำเภอใจ เปลี่ยนคุณสมบัติอุปกรณ์ ยึดบัญชีเหยื่อ
• ใน API ที่เปิดเผยมากกว่า 700 รายการ มีจำนวนมากที่ให้ฟังก์ชันระดับผู้ดูแล และเกิดปัญหาสิทธิ์แบบเดียวกันเมื่อส่งคำขอซ้ำ

การรายงานต่อ Cox และการแก้ไข

• ช่องโหว่ถูกรายงานผ่าน responsible disclosure program ของ Cox
• Cox ปิดการเรียก API ที่เปิดเผยภายใน 6 ชั่วโมงหลังได้รับรายงาน และเริ่มแก้ไขช่องโหว่ด้านสิทธิ์
  • วันถัดมาไม่สามารถทำซ้ำช่องโหว่ได้อีก
• ไทม์ไลน์การเปิดเผย:
  • 2024-03-04: รายงานช่องโหว่ให้ Cox
  • 2024-03-05: ใช้ hotpatch และ endpoint ธุรกิจที่ไม่จำเป็นคืนค่า 403 พร้อมหยุดทำงาน
  • 2024-03-06: ส่งอีเมลแจ้ง Cox ว่าไม่สามารถทำซ้ำช่องโหว่ได้
  • 2024-03-07: Cox ตอบกลับว่าเริ่มการทบทวนความปลอดภัยแบบครอบคลุม
  • 2024-04-10: แจ้ง Cox ถึงความตั้งใจจะเปิดเผยหลังรายงานครบ 90 วัน
  • 2024-04-29: แชร์ลิงก์ร่างบล็อกกับ Cox

คำถามที่ยังเหลืออยู่

• Cox สืบสวนว่ามีการใช้ประโยชน์จากเส้นทางช่องโหว่เฉพาะนี้ในอดีตหรือไม่ และยืนยันว่าไม่มีประวัติการถูกใช้ประโยชน์
  • บริการดังกล่าวเริ่มดำเนินการในปี 2023
  • การบุกรุกโมเด็มครั้งแรกเกิดขึ้นในปี 2021 ดังนั้นช่องโหว่ Cox Business API ที่เปิดเผยจึงไม่ใช่สาเหตุของการบุกรุกครั้งนั้น
• Cox แจ้งว่าไม่มีความเกี่ยวข้องใด ๆ กับ IP ของ DigitalOcean
  • อุปกรณ์ถูกแฮ็กจริง แต่เป็นด้วยวิธีอื่นที่ไม่ใช่ช่องโหว่ API ที่เปิดเผย
• โมเด็มไม่ได้ตั้งค่าให้เข้าถึงได้จากภายนอก และไม่เคยล็อกอินเข้าอุปกรณ์จากเครือข่ายบ้าน
  • เส้นทางอื่นที่เป็นไปได้ถูกกล่าวถึง เช่น 0day ที่เริ่มจาก local CSRF ไปสู่ RCE
• คำถามใหญ่ที่สุดคือ ทำไมผู้โจมตีจึงเล่นซ้ำคำขอ HTTP
  • หากอยู่ในเครือข่ายอยู่แล้ว ก็สามารถเข้าถึงได้โดยไม่ถูกจับได้ แต่ยังไม่ทราบเหตุผลว่าทำไมจึงเล่นซ้ำคำขอ HTTP ทั้งหมด

[GN⁺]

ความคิดเห็นจาก Hacker News

• บทความดีและตามได้ง่าย โดยเฉพาะที่ Cox ไม่โจมตีผู้แจ้งหรือปฏิเสธปัญหา แต่ทำตัวเป็นตัวอย่างของ การตอบสนองด้านความปลอดภัยอย่างมีความรับผิดชอบ ที่ควรคาดหวังได้ในสถานการณ์แบบนี้
  อยากเห็นบทความติดตามว่าบั๊กที่ทำให้มีการเข้าถึง API โดยไม่ได้รับอนุญาตเป็นบางครั้งนั้นคืออะไร ความผิดพลาดแบบนี้อาจหลุดรอดจากการทดสอบแบบตื้น ๆ ได้ง่าย หรือขึ้นอยู่กับสาเหตุแล้วอาจไม่สามารถทำซ้ำในสภาพแวดล้อมทดสอบได้เลย

  • Cox ตอบสนองอย่างมีความรับผิดชอบจริง แต่ก็น่าเสียดายที่ตอนมีคนนำอุปกรณ์ที่ติดเชื้อมาหาตั้งแต่แรก พวกเขาน่าจะใช้โอกาสนั้นได้ดีกว่านี้
    ฉันเคยบังเอิญพบช่องโหว่ร้ายแรงในบริษัทโทรคมนาคมแบบดั้งเดิมแห่งหนึ่ง แค่จะติดต่อให้ถึงคนที่รับผิดชอบผ่านช่องทางสนับสนุนลูกค้าทั่วไปก็ใช้เวลาเกือบสัปดาห์ และองค์กรซัพพอร์ตก็ไม่สามารถเอสคาเลตเรื่องได้เลย Cox เองก็มีผู้เชี่ยวชาญด้านความมั่นคงปลอดภัยนำอุปกรณ์ที่ติดเชื้อมาส่งถึงมือ แต่ทีมซัพพอร์ตก็ยังจัดการได้ไม่ดี
  • บทความอ่านง่ายและ Cox ก็ตอบสนองได้ดี ฉันชอบที่การอธิบายกระบวนการค้นพบและตัวบั๊กเองไม่ได้ใช้โทน ในแง่ลบหรือดูถูก
  • บริษัทควร ให้รางวัล คนที่ค้นพบเรื่องแบบนี้ แทนที่จะฟ้องว่าเขา “แฮ็ก”
  • ฉันก็สงสัยเหมือนกันว่าบั๊กที่เปิดให้เข้าถึง API โดยไม่ได้รับอนุญาตเป็นบางครั้งนั้นคืออะไร สุดท้ายอาจไม่มีวันรู้ก็ได้ แต่ก็อาจเป็นกรณีที่ แบ็กเอนด์สำหรับทดสอบ ซึ่งไม่มีการตรวจสอบสิทธิ์ ถูกใส่รวมมาในการตั้งค่า load balancer โดยพลาด
  • บทความดี แต่การใช้คำว่า super ซ้ำ ๆ เช่น “super curious”, “super interesting”, “super interested” กวนใจอยู่หน่อย

• สิ่งที่น่าหงุดหงิดในสถานการณ์แบบนี้คือเวลาที่ ISP บังคับให้ใช้ โมเด็มหรือเราเตอร์ ของตัวเอง ตัวอย่างเช่น AT&T fiber ใช้การยืนยันตัวตน 802.1X แบบอิงใบรับรองเพื่อเชื่อมต่อเครือข่าย ซึ่งถ้าไม่มีสิ่งนี้ก็น่าจะเสียบอุปกรณ์อะไรก็ได้เข้ากับ ONT
  มีหรือเคยมีวิธีหลบเลี่ยงอยู่ แต่ฉันไม่อยากต้องผ่านขั้นตอนแบบนั้นแค่เพื่อใช้อินเทอร์เน็ต เลยปิดฟังก์ชันทั้งหมดของเราเตอร์ AT&T แล้วต่อเราเตอร์ของตัวเองที่คอยอัปเดตให้ทันสมัยไว้ด้านหลัง ถึงเราเตอร์ AT&T จะถูกแฮ็ก ฉันก็อาจไม่รู้ตัวจนกว่าจะเริ่มส่งผลเสียต่อบริการ โชคดีที่ทุกวันนี้ส่วนใหญ่ใช้ HTTPS กัน

  • ถ้าเป็น AT&T fiber ที่ ONT แยกจากโมเด็ม การเลี่ยง 802.1X ค่อนข้างง่าย แค่เสียบ สวิตช์แบบ unmanaged ไว้ระหว่างโมเด็มกับ ONT ปล่อยให้โมเด็มยืนยันตัวตน จากนั้นก็ถอดโมเด็มออก
    ถ้า ONT รีบูต ก็น่าจะต้องทำใหม่อีกครั้ง แต่กรณีของฉัน AT&T ให้ UPS สำหรับ ONT มา เลยไม่น่าจะรีบูตบ่อย ส่วนตัวฉันเคยทำคอนฟิกซับซ้อนโดยอาศัย NIC สำหรับ bypass ให้ทราฟฟิกวิ่งผ่านโมเด็ม AT&T ตอนที่ไฟร์วอลล์ปิดอยู่หรือกำลังรีบูต และเมื่อไฟร์วอลล์ทำงานก็ให้ไฟร์วอลล์ของฉันรับทราฟฟิกแล้วเลือกส่งต่อผ่านโมเด็ม แต่จริง ๆ ใช้แค่สวิตช์แบบ unmanaged ก็พอแล้ว
  • โอกาสที่เราเตอร์ AT&T CPE จะถูกแฮ็ก ไม่ได้สร้างความแตกต่างมากนักถ้ามี เราเตอร์ของฉัน คั่นอยู่ระหว่างเครือข่ายของฉันกับเครือข่าย AT&T ต่อให้เอาเราเตอร์ AT&T CPE ออกไป สุดท้ายก็ยังเชื่อมต่อเข้ากับกล่องดำที่ฉันควบคุมไม่ได้อยู่ดี และอุปกรณ์นั้นก็อาจถูกแฮ็กหรือถูกใช้ตรวจสอบทราฟฟิกได้หลายแบบเช่นกัน
  • โชคดีที่ Cox ไม่ใช่ ISP แบบนั้น ถ้าเป็น โมเด็ม DOCSIS ที่ทันสมัยพอและรองรับความเร็วตามแพ็กเกจที่สมัครไว้ ก็ใช้ได้
    แต่คำชมสำหรับ Cox ก็หมดแค่นั้น ฉันเจอ packet loss เป็นพัก ๆ มาสองปีแล้ว และถึงจะเก็บข้อมูลได้ว่าน่าจะมีบางโหนดที่ถูกขายเกินความจุ ก็เหมือนไม่มีเส้นทางเอสคาเลตผ่านซัพพอร์ตที่จะพาเรื่องนี้ไปถึงคนที่เข้าใจได้
  • เป็นข้อมูลประกอบว่าใน xgspon ตอนนี้ขั้นตอนการเลี่ยงถูกทำให้เป็นอัตโนมัติแล้ว ประมาณว่า “เสียบ SFP+, อัปโหลดเฟิร์มแวร์ผ่านเว็บอินเทอร์เฟซ, กรอก serial number ของอุปกรณ์” และขึ้นกับโมดูล SFP ที่ใช้ ขั้นตอนที่ 2 อาจข้ามได้
    ในทางปฏิบัติ สถานะ 802.1X ไม่ได้ถูกตรวจสอบฝั่งเซิร์ฟเวอร์ มาตรฐานบอกว่าถ้าต้องใช้ 802.1X แต่ไม่ได้ดำเนินการ โมเด็มไม่ควรส่งต่อทราฟฟิก แต่ส่วนใหญ่ก็ส่งต่ออยู่ดีหรือปรับให้เป็นแบบนั้นได้ ฝั่ง AT&T เองไม่ได้ตรวจสอบและปล่อยทราฟฟิกผ่านตลอด ซึ่งภายในก็เป็นแบบนั้นอยู่แล้ว
  • มีหลายวิธีในการเชื่อมต่อโดยไม่ต้องใช้เกตเวย์ของ AT&T และมีสรุปไว้หลายแบบที่ https://pon.wiki/

• เป็นบทความที่อ่านลื่นและสืบค้นได้ยอดเยี่ยม ดีเหมือนกันที่ได้เห็นกรณีที่บริษัทยักษ์ใหญ่ไม่ทิ้งระเบิดนิวเคลียร์ใส่นักวิจัยด้านความปลอดภัย
  ฉันไม่แน่ใจนัก แต่สงสัยว่าคำขอไปยังอินเทอร์เฟซผู้ดูแลระบบภายในเครื่องของเราเตอร์ Nokia นี้ได้รับการยืนยันตัวตนอย่างถูกต้องหรือไม่ เมื่อไม่นานมานี้ฉันเพิ่งได้อุปกรณ์แบบเดียวกันมาใช้ และมีการตั้งค่าที่สิทธิ์ผู้ดูแลระบบทั่วไปเปลี่ยนไม่ได้เพราะ ISP ไม่ให้บัญชีซูเปอร์แอดมิน แต่พอเปิดตัวตรวจสอบหน้าเว็บแล้วเปิดฟิลด์ที่ถูกปิดไว้กลับขึ้นมาเพื่อเปลี่ยนค่า API ก็รับค่าตามนั้นเลย ถ้าในสถานะนี้สามารถรันแอปพลิเคชันจากภายในเครือข่ายได้ ก็คงไม่ยากนักที่จะยึดเราเตอร์ด้วยวิธีนี้ แต่ก็ดูเหมือนต้องมีเงื่อนไขค่อนข้างเฉพาะ

  • ข้อเท็จจริงที่ว่า Cox เป็นผู้ให้บริการบรอดแบนด์เอกชนรายใหญ่ที่สุดในสหรัฐ เป็นผู้ให้บริการเคเบิลทีวีอันดับ 3 เป็นผู้ให้บริการโทรศัพท์อันดับ 7 และเป็น ISP ที่ได้รับความนิยมที่สุดใน 10 รัฐ กลับทำให้ฉันคิดว่า ISP ไม่ควรใหญ่ขนาดนี้
    Cox เป็น เป้าหมายการโจมตีที่น่าสนใจ อย่างชัดเจน และอย่างในตัวอย่างของบทความ ช่องโหว่เพียงจุดเดียวก็อาจทำให้ถึงขั้นสำนักงานภาคสนามของ FBI ตกอยู่ในความเสี่ยงได้ ฉันคิดว่าน่าจะเหมาะกว่าหากเขียนว่า “Cox อ้างว่าได้ตรวจสอบการถูกนำไปใช้โจมตีในอดีตและไม่พบบันทึก” แทนที่จะเขียนว่า “Cox ได้ตรวจสอบและไม่พบบันทึก”

• เชื่อได้แค่ไหนกับคำว่า “ไม่มีประวัติการถูกนำไปใช้โจมตีในอดีต”? ทั้งเครือข่ายดูเหมือน ชีสสวิส ที่พรุนไปหมด

  • นั่นจึงเป็นเหตุผลที่ต้องส่งล็อกทั้งหมดไปยัง บัคเก็ต S3 ในบัญชี AWS ที่เขียนได้อย่างเดียว และถ้าจะเข้าบัญชีที่ทำอย่างอื่นกับบัคเก็ตนั้นได้ก็ต้องใช้คนสามคน ฉันไม่รู้ว่า Cox ทำแบบนั้นไหม แต่ถ้าจะออกแบบระบบให้สามารถพูดได้ว่า “ไม่มีประวัติการถูกนำไปใช้โจมตี” ก็ประมาณนี้
  • ถ้าคุณเป็นฝ่ายเริ่มบทสนทนา ก็จะหายเงียบไปตลอดไม่ได้ สักจุดหนึ่งก็ต้องพูดว่า “ข้อมูลที่เรามีมีเท่านี้ และมันดีกว่าเดิม”
  • ถ้าพูดว่า “ไม่มี” ก็อาจหมายถึงว่า ในสถานการณ์ที่พบอุปกรณ์ติดเชื้อแล้ว Cox อาจรู้หรือไม่รู้ว่ามี เส้นทางการโจมตีอื่น อยู่ก็ได้

• เราเตอร์จำนวนมากต้องอัปเดตเฟิร์มแวร์ด้วยตนเอง เราเตอร์ GL.iNet มี ช่องโหว่การรันโค้ดจากระยะไกล หลายรายการในช่วง 6 เดือนที่ผ่านมา ดังนั้นควรรีบตรวจสอบว่าเราเตอร์ของตัวเองถูกแฮ็กหรือไม่ และถ้าทำได้ก็ควรอัปเกรดเฟิร์มแวร์
  อาการที่ผู้ใช้ทั่วไปสังเกตได้คือความเร็วอินเทอร์เน็ตลดลง สัญญาณ Wi‑Fi หลุดและอุปกรณ์เชื่อมต่อไม่สำเร็จ และแม้ตัวเราเตอร์จะยังเชื่อมต่ออินเทอร์เน็ตอยู่ แต่หน้าแอดมินภายใน (192.168.8.1) ไม่ตอบสนอง ในกรณีของฉัน ผู้โจมตีติดตั้งแอป Pawns ของ IPRoyal ทำให้เราเตอร์กลายเป็นพร็อกซีเซิร์ฟเวอร์เพื่อหารายได้ อีกทั้งยังขโมย system log ที่มีข้อมูลเวลาใช้งานและการเชื่อมต่อ NAS และยังมี reverse shell อยู่ด้วย วิธีแก้ที่เหมาะคืออัปเดตเฟิร์มแวร์ รีเซ็ตเราเตอร์เพื่อลบมัลแวร์ ปิด SSH และปิดการเข้าถึงจากระยะไกลอย่าง Dynamic DNS ตามลำดับ หากจำเป็นต้องเข้าถึงจากระยะไกล อาจพิจารณา Cloudflare Tunnel, Zero Trust, GoodCloud, ZeroTier, Tailscale แต่ไม่แน่ใจว่าแบบไหนเหมาะที่สุด GL.iNet ไม่ได้ยึดหลัก least privilege และรันโปรเซสเป็น root โดยปริยาย อีกทั้ง SSH ก็เปิดการเข้าถึงแบบ root มาเป็นค่าเริ่มต้น จึงดูเป็นตัวเลือกที่ควรหลีกเลี่ยง

• การบอกว่า “ไม่มีประวัติการถูกนำไปใช้โจมตี” อาจหมายความว่าแต่แรกมี log หรือข้อมูล audit ไม่เพียงพอ หรือหลังถูกแฮ็กแล้ว ไม่มี log เหลืออยู่ ก็ได้

  • จากที่เห็นในบทความ เส้นทางโจมตีเฉพาะที่ “ลองส่งคำขอที่ไม่ได้รับอนุญาตซ้ำไปเรื่อย ๆ จนกว่าจะผ่าน” นั้นมองเห็นได้ง่ายมากใน log แค่มีนโยบายบันทึก log พื้นฐานที่เก็บ path, IP และ status code ก็เพียงพอแล้ว และนี่ก็ใกล้เคียงกับค่าเริ่มต้นของเว็บเซิร์ฟเวอร์และเฟรมเวิร์กส่วนใหญ่อยู่แล้ว
  • วลี “การไม่มีหลักฐาน ไม่ได้แปลว่าเป็นหลักฐานว่าไม่มี” ใช้ได้ตรงนี้พอดี
  • หรืออาจโกหกก็ได้ ถ้าคิดจากมุมของ Cox ทำไมบริษัทต้องเปิดเผยให้คนนอกบริษัทรู้ว่ามีประวัติการถูกโจมตีมาก่อน? ที่จริงแล้วไม่มีเหตุผลต้องเปิดเผยอะไรเลย

• ระบบยืนยันตัวตนแบบไหนที่ปล่อยให้การเรียกผ่านได้แบบสุ่มเป็นบางครั้ง? ดู ไร้ความสามารถ มาก

  • เคยเจอแบบนี้ใน vendor API ที่ลงทะเบียน provider ของผู้ใช้ปัจจุบันเป็น singleton แทนที่จะเป็นต่อคำขอ ทำให้บางครั้งมีโอกาสอาศัยท้ายแถวของผู้ใช้ที่ยืนยันตัวตนแล้วได้
  • เคยเห็นบั๊กใหญ่คล้ายกัน API ปฏิเสธคำขอที่ไม่ได้ยืนยันตัวตนเป็นเวลา 10 นาทีพอดี จากนั้นกลับยอมให้ผ่านได้ 1 นาทีพอดี แล้ววงจรนี้ก็วนซ้ำไม่สิ้นสุด อยากรู้จริง ๆ ว่ามีอะไรเกิดขึ้นในแบ็กเอนด์
  • จากประสบการณ์ของฉัน เรื่องแบบนี้อาจเกิดจาก load balancer เช่น ส่งต่อไปยังเซิร์ฟเวอร์ในพูลไม่ถูกต้อง หรือมีความต่างกันของการตั้งค่าหรือระดับแพตช์ระหว่างเซิร์ฟเวอร์
  • อาจเป็นไปได้ว่าเซิร์ฟเวอร์ต้นทางบางตัวที่คำขอถูกส่งไปนั้นตั้งค่าผิด
  • ถ้า API อยู่หลัง reverse proxy ก็อาจเป็น ปัญหาแคช ได้เช่นกัน

• เขาได้เงินไหม? คนนี้แทบจะช่วย Cox ไว้ และยังชี้ให้เห็นการ ยึดครองโครงสร้างพื้นฐานด้านความปลอดภัยทั้งหมด ที่ค้นพบได้ยากมาก
  ดูเหมือนเขาไม่ได้อะไรตอบแทนเลยจากการทำ “สิ่งที่ถูกต้อง” ซึ่งค่อนข้างน่าดูหมิ่น ลองคิดว่าบริษัทมองคนที่หอบข้อมูลสำคัญไปถึงออฟฟิศอย่างไร ภาพที่เจ้าตัวมีต่อตัวเองกับภาพที่บริษัทมองคงต่างกันมาก กรณีแบบนี้แสดงให้เห็นชัดว่าทำไมไม่ควรรายงาน 0day เด็ดขาด

  • ถ้าเป็น Cox แค่ไม่ฟ้องคนที่มาช่วยแก้ความผิดพลาดของตัวเองก็นับว่าโชคดีแล้ว
  • Sam เป็นนักวิจัยความปลอดภัยที่มีชื่อเสียงมาก จึงไม่น่าแปลกถ้าจะมีรายได้มากกว่า 350,000 ดอลลาร์ต่อปี บทความแบบนี้สร้างรายได้ไม่น้อยผ่าน ชื่อเสียงที่เพิ่มขึ้น
  • Cox ไม่มีการจ่าย bug bounty

• คำถามที่ยังเปิดอยู่คือ ผู้โจมตีจับ ทราฟฟิก HTTP ของเขาได้อย่างไร
  CPE บางตัวมีฟังก์ชันคล้าย cloud Wireshark สำหรับดีบัก ไม่รู้ว่าในอิมเมจเฟิร์มแวร์ที่ Cox ใช้งานมีฟังก์ชันแบบนั้นอยู่หรือไม่ ปกติเฟิร์มแวร์สำหรับใช้งานจริงกับเฟิร์มแวร์สำหรับทดสอบจะแยกกัน ทำให้การทดสอบปัญหาในระบบจริงยากขึ้น Cox น่าจะตรวจสอบได้ว่าในภาคสนามมีเฟิร์มแวร์เวอร์ชันใดอยู่บ้าง และ ISP สามารถอัปเกรดเฟิร์มแวร์ที่ไม่ตรงตามเวอร์ชันที่กำหนดได้โดยอัตโนมัติ อีกทั้งนี่เป็นโมเด็มของ Cox เอง จึงมีความเป็นไปได้สูงว่าพวกเขาถือครองเฟิร์มแวร์ด้วย ถ้าเป็นเฟิร์มแวร์ดีบักจริง ก็ชวนสงสัยว่ามันถูกติดตั้งได้อย่างไรและทำไมยังคงอยู่ต่อไป

  • บน Linux ถ้าสร้างซ็อกเก็ตด้วย PF_PACKET ก็สามารถดักทราฟฟิกของทุกอินเทอร์เฟซได้ มองว่าเป็น tcpdump ระดับล่างก็ได้
    ดักข้อมูลทั้งหมดบนพอร์ต 80 แล้วพาร์ส HTTP header ก่อนทำสิ่งที่ต้องการต่อ เป็นเรื่องไม่ยากนัก เพียงแต่ไม่เข้าใจว่าทำไมใครสักคนถึงต้อง replay คำขอ
  • ถ้าเป็น HTTP ไม่ใช่ HTTPS ใครก็ตามหรืออุปกรณ์ใดก็ตามที่อยู่บนเส้นทางก็เห็นคำขอได้
  • นี่เป็นอีกเหตุผลที่ไม่ไว้ใจและไม่ใช้อุปกรณ์ที่ ISP จัดให้ เรื่อง การจัดการระยะไกล ของ ISP นี่ยิ่งไม่เอาใหญ่

• นี่เป็นหนึ่งในเหตุผลที่ไม่ควรยินดีกับเคเบิลโมเด็มที่ ISP ให้มาพร้อมฟังก์ชัน Wi‑Fi และควรดูแลความปลอดภัยของเอนด์พอยต์กับบริการภายใน LAN ให้ดี อย่างน้อยที่สุดในช่วงระหว่างโมเด็มกับ ISP ก็ควรใช้ TLS และ DNS over TLS
  ฉันตั้งเป็นโหมดบริดจ์ ปิด Wi‑Fi แล้วให้ฟังก์ชันเครือข่ายทั้งหมดเป็นหน้าที่ของอุปกรณ์ตัวเอง ส่วนโมเด็มที่เคยเช่าจาก ISP ตัวล่าสุดนั้น ISP ไม่อัปเดตเฟิร์มแวร์มาเกือบ 10 ปี แต่ข้อดีก็คือมันเสถียรมาก

  • ก็มีข้อโต้แย้งเหมือนกัน ISP ที่มีลูกค้ามากกว่าล้านรายมีแรงจูงใจที่จะอัปเกรดโฮมเกตเวย์ “ตลอดไป” เพื่อลดต้นทุนการลงทุนระบบ
    ฉันทำงานที่ Free ซึ่งเป็น ISP ในฝรั่งเศส และผ่าน Iliad ก็ให้บริการโฮมเกตเวย์ในอิตาลีด้วย อุปกรณ์ที่เปิดตัวในปี 2011 ก็ยังได้รับการอัปเดตอยู่ ใช้ Linux 6.4 รุ่นใหม่ มีฟีเจอร์สมัยใหม่อย่าง airtime QoS พร้อมทั้งอัปเดตแอปมือถือและฟีเจอร์ซอฟต์แวร์หลายอย่าง
  • เราเตอร์เป็น อุปกรณ์ IoT ที่ถูกนำไปใช้โจมตีมากที่สุดบนโลก และช่องโหว่เฟิร์มแวร์มักค้างอยู่นานหลายปีเพราะผู้ใช้ปลายทางไม่แพตช์ ถ้า ISP สามารถผลักแพตช์เข้ามายังเราเตอร์และเรียกคืนอุปกรณ์ที่แพตช์ไม่ได้ได้ นั่นถือเป็นผลบวกสุทธิต่อความมั่นคงปลอดภัยไซเบอร์ แม้จะรวมถึงข้อเท็จจริงที่ว่าอุปกรณ์เป็นของ ISP ก็ตาม
  • ฉันก็ใช้โหมดบริดจ์และปิด Wi‑Fi เหมือนกัน บังเอิญเคยได้ติดตั้งโมเด็มธรรมดาที่ไม่มีฟังก์ชันเราเตอร์และแอ็กเซสพอยต์ ไม่คิดเลยว่ายังมีอุปกรณ์ที่ทำหน้าที่เดียวแบบนี้อยู่
    ฉันซื้อเราเตอร์ที่ค่อนข้างโอเคมาตัวหนึ่ง ติดตั้ง OpenWrt แล้วต่อเป็นบริดจ์เข้ากับเครือข่ายผ่านอุปกรณ์ของ ISP ซึ่งทำงานได้ดี ตอนนี้ใช้ HTTPS แม้แต่ภายใน LAN แล้ว
  • ฉันบอก ISP ไปว่าถ้าไม่ยอมให้ใช้เราเตอร์ของฉันเอง ก็จะย้ายไปใช้ ISP เจ้าอื่น