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

 (samcurry.net)
3 คะแนน โดย GN⁺ 2024-06-05 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Sam Curry พบว่าคำขอ HTTP ที่ส่งจากเครือข่ายที่บ้านถูกเล่นซ้ำเหมือนเดิมจาก IP ของ DigitalOcean หลังผ่านไป 10 วินาที และหลังจากเปลี่ยนเกตเวย์ Cox Panoramic Wifi ปัญหาก็หายไป ทำให้สงสัยว่าโมเด็มเดิมถูกบุกรุก
  • IP ของทราฟฟิกที่ถูกเล่นซ้ำ 159.65.76.209 เชื่อมโยงกับโดเมนที่เกี่ยวข้องกับ Adidas, โดเมนฟิชชิงของ ISG Latam และโดเมนที่ดูเหมือนถูกสร้างด้วยอัลกอริทึมสำหรับ C&C แต่ยังไม่สามารถยืนยันเส้นทางการบุกรุกจริงได้
  • ระหว่างการวิเคราะห์พอร์ทัล Cox Business ในปี 2024 พบ API ที่ใช้ Spring และเอกสาร Swagger หลัง /api/cbma/ และ API บางส่วนจากทั้งหมดราว 700 รายการ แสดงปัญหาการข้ามสิทธิ์ โดยสลับกันตอบกลับข้อผิดพลาดการยืนยันตัวตนกับ 200 OK
  • การข้ามสิทธิ์นี้ทำให้สามารถค้นหาลูกค้า ดู PII ของบัญชี ดู MAC address ของอุปกรณ์ ดู IP ของโมเด็ม อ่าน/เขียนบัญชี Cox Business และ เปลี่ยนการตั้งค่าอุปกรณ์ เช่น เปลี่ยน WiFi SSID ได้ โดยใน PoC SSID ของเขาเองถูกเปลี่ยนเป็น Curry
  • Cox ปิด API ที่เปิดเผยภายใน 6 ชั่วโมงหลังได้รับรายงาน และในวันถัดมาก็ไม่สามารถทำซ้ำได้อีก โดยระบุว่าบริการ API ดังกล่าวเริ่มในปี 2023 จึงไม่เกี่ยวข้องกับการบุกรุกโมเด็มในปี 2021 และไม่พบประวัติการถูกใช้โจมตีในอดีต

ทราฟฟิกผิดปกติที่เริ่มจากโมเด็มที่บ้าน

  • เพื่อทดสอบช่องโหว่ blind XXE จากเครือข่ายที่บ้าน เขาเปิดเซิร์ฟเวอร์ Python HTTP แบบง่ายบนอินสแตนซ์ AWS และตรวจสอบว่ามีคำขอจากภายนอกเข้ามาหรือไม่
  • ทันทีหลังจากคำขอที่ส่งด้วย curl จากคอมพิวเตอร์ที่บ้านถูกบันทึกตามปกติ IP ไม่ทราบที่มา 159.65.76.209 ก็ร้องขอ พาธเดียวกัน อีกครั้งหลังผ่านไป 10 วินาที
  • เมื่อใช้ iPhone Safari ขอพาธอื่น IP เดียวกันก็เล่นซ้ำคำขอเดียวกัน ทำให้ดูเหมือนว่าทราฟฟิกของ ทั้งเครือข่ายที่บ้าน ถูกสังเกต ไม่ใช่แค่คอมพิวเตอร์เครื่องใดเครื่องหนึ่ง
  • ปรากฏการณ์เดียวกันเกิดซ้ำกับอินสแตนซ์ AWS ใหม่และ Nginx รวมถึงอินสแตนซ์ GCP ในภายหลัง จึงตัดความเป็นไปได้ที่ AWS ถูกบุกรุกออกไป
  • หลังนำเกตเวย์ Cox Panoramic Wifi เดิมไปคืนที่ร้านและเปลี่ยนเป็นอุปกรณ์ใหม่ ทราฟฟิกที่ถูกเล่นซ้ำก็หายไป และในล็อกไม่ปรากฏ “IP อื่น” อีก

การสืบสวน 159.65.76.209

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

การวิเคราะห์ที่กลับมาต่ออีกครั้งหลังผ่านไป 3 ปี

  • ต้นปี 2024 เพื่อนในวงการความปลอดภัยสังเกตรูปแบบของ limit742921.tokyo และ jingoism44769.xyz
  • เมื่อค้นหา reverse IP จาก IP ของซับโดเมน mx1 ของ limit742921.tokyo พบโดเมนที่มีรูปแบบเดียวกัน มากกว่า 1,000 โดเมน
  • ชื่อโดเมนทั้งหมดอยู่ในรูปแบบ [word][6 numbers].[TLD]
    • ตัวอย่าง: acquire543225.biz
    • ตัวอย่าง: battery935904.biz
    • ตัวอย่าง: grocery634272.biz
  • ด้วยการจดทะเบียนจำนวนมากและโครงสร้างที่ดูเป็นอัลกอริทึม ทำให้ดูเหมือน อัลกอริทึมสร้างโดเมน ที่ผู้ปฏิบัติการมัลแวร์ใช้เพื่อซ่อนที่อยู่เซิร์ฟเวอร์ C&C
  • โดเมนล่าสุดที่พบถูกจดทะเบียนเมื่อวันที่ 17 มีนาคม 2023 และในขณะนั้นไม่มีโฮสต์ใด resolve ได้อีกแล้ว อีกทั้งไม่พบโดเมนคล้ายกันที่จดทะเบียนบน IP เดียวกัน

สมมติฐานที่เริ่มจากฟังก์ชันจัดการของ ISP และ TR-069

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

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

  • ในไฟล์ JavaScript ฝั่งฟรอนต์เอนด์ main.36624ed36fb0ff5b.js ของพอร์ทัล Cox Business พบการเรียก API ที่อิงกับ /api/cbma/ มากกว่า 100 รายการ
  • พาธ /api/cbma/ มีพฤติกรรมการตอบกลับแตกต่างจากพาธ /api/ อื่น ๆ จึงดูเหมือนเป็น API ที่ถูกพร็อกซีไปยังแบ็กเอนด์แยกจากฟรอนต์เอนด์
    • /api/anything_else/example ส่งคืนการตอบกลับแบบ redirect
    • /api/cbma/example ส่งคืน 500 Internal Server Error
  • คำขอลงทะเบียนมีเฮดเดอร์อย่าง clientid, Apikey, Cb_session, Authorization และรูปแบบการตอบกลับดูเหมือนแบ็กเอนด์ที่ใช้ Spring
  • เมื่อเปลี่ยน HTTP method พบการตอบกลับข้อผิดพลาดของ Spring ยืนยันว่าแบ็กเอนด์ API ใช้ Spring
  • ไม่พบพาธ actuator แต่พบพาธ Swagger UI

การโหลดเอกสาร Swagger แบบข้ามข้อจำกัดและ API 700 รายการ

  • Swagger UI โหลดขึ้นมาได้ แต่ทรัพยากร static ติด redirect loop ทำให้เอกสารดูว่างเปล่า
  • คำขอทรัพยากร static เช่น .js, .css, .png ดูเหมือนถูก route ไปยังโฮสต์หลัก ไม่ใช่ API proxy
  • เมื่อเติม %2f ซึ่งเป็น / ที่ถูกเข้ารหัสไว้ท้าย URL ก็สามารถ โหลดทรัพยากร JavaScript แบบ static ผ่าน API proxy ได้
  • เมื่อใช้ match-and-replace ของ Burp เติม %2f ให้คำขอทรัพยากร static เอกสาร Swagger ก็แสดงได้ตามปกติ
  • โดยรวมพบการเรียก API ราว 700 รายการ และส่วนที่เกี่ยวข้องกับฟังก์ชันอุปกรณ์และบัญชีมาก ได้แก่ accountequipment, datainternetgateway, account

การข้ามการยืนยันตัวตนและการเข้าถึงข้อมูลลูกค้า

  • เมื่อลองส่งคำขอซ้ำไปยัง GET endpoint ทั้งหมด บางรายการตอบกลับข้อผิดพลาดการยืนยันตัวตน บางรายการตอบกลับ 200 OK และแม้แต่คำขอเดียวกันก็มีผลลัพธ์เปลี่ยนไปเมื่อส่งซ้ำ
  • endpoint profilesearch ตอนแรกส่งคืนผลการค้นหาว่าง และหลังจากนั้นคำขอเดิมก็สลับกันระหว่างข้อผิดพลาดการยืนยันตัวตนกับการตอบกลับสำเร็จ
  • เมื่อส่งคำขอซ้ำด้วยคำค้น cox ได้ผลลัพธ์ที่ดูเหมือนโปรไฟล์ลูกค้าธุรกิจของ Cox พร้อม profileGuid
  • เมื่อค้นคำว่า fbi ผลลัพธ์ที่ส่งคืนมี ที่อยู่จริง ของสำนักงานภาคสนาม FBI หลายแห่งที่เป็นลูกค้าธุรกิจของ Cox
  • ปัญหาสิทธิ์เดียวกันส่งผลต่อ API อื่น ๆ ด้วย และหากเล่นคำขอซ้ำหลายครั้ง ก็สามารถเข้าถึงฟังก์ชันผู้ดูแลระบบได้แม้อยู่ในสถานะที่ยังไม่ยืนยันตัวตน

การดู MAC address ของอุปกรณ์และข้อมูลบัญชี

  • เมื่อนำ MAC address ของโมเด็มตนเองจากบัญชี Cox ไปใส่ใน API ที่มีพารามิเตอร์ macAddress ระบบส่งคืน ที่อยู่ IPv4 ของอุปกรณ์นั้น
  • ผลลัพธ์นี้ยืนยันว่า API ของเว็บไซต์ Cox Business สามารถสื่อสารกับอุปกรณ์จริงได้
  • API รายการอุปกรณ์ที่ใช้ account ID ส่งคืนข้อมูลอุปกรณ์ที่ผูกกับบัญชี
    • หมวดหมู่อุปกรณ์
    • ชื่อรุ่น
    • MAC address
    • ข้อมูลพอร์ต
    • หมายเลขซีเรียล
  • API ค้นหาผู้ใช้ตามอีเมลส่งคืนข้อมูลบัญชีธุรกิจ เช่น ชื่อ หมายเลขโทรศัพท์ สถานะ ประเภทผู้ใช้ สถานะว่าเป็นเจ้าของโปรไฟล์หรือไม่ และอีเมลสำรอง
  • คำขอ POST สำหรับอัปเดตบัญชีที่คล้ายกันก็ทำงานได้ ยืนยันว่า อ่านและเขียน บัญชีธุรกิจได้

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

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

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

  • เขาส่งคำขอ POST เพื่อเปลี่ยน WiFi SSID โดยกำหนดเป้าหมายเป็น MAC address ของอุปกรณ์ตนเอง
  • การตอบกลับคือ 200 OK และ Success จากนั้นเครือข่ายออฟไลน์ชั่วคราว
  • ประมาณ 5 นาทีต่อมา เครือข่ายรีบูตและ SSID ถูกเปลี่ยนเป็น Curry
  • PoC นี้แสดงให้เห็นว่า API อัปเดตการกำหนดค่าอุปกรณ์ทำงานจริง และผู้โจมตีสามารถเขียนทับการตั้งค่าอุปกรณ์ผ่าน API ได้
  • สิทธิ์ดังกล่าวอยู่ในระดับคล้ายฝ่ายเทคนิคซัพพอร์ตของ ISP และอาจกระทบอุปกรณ์ Cox หลายล้านเครื่องที่เข้าถึงได้ผ่าน API

ขอบเขตผลกระทบและลำดับการโจมตีที่เป็นไปได้

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

การรายงาน แพตช์ และข้อสงสัยที่ยังเหลือ

  • ช่องโหว่ถูกรายงานผ่าน responsible disclosure program ของ Cox
  • Cox ปิดการเรียก API ที่เปิดเผยภายใน 6 ชั่วโมง และในวันถัดมาก็ไม่สามารถทำซ้ำช่องโหว่ได้อีก
  • จากการสืบสวนของ Cox ไม่พบประวัติการใช้เวกเตอร์นี้โจมตีในอดีต และบริการที่มีช่องโหว่เริ่มในปี 2023 จึงไม่สามารถถูกใช้ในการบุกรุกโมเด็มปี 2021 ได้
  • Cox แจ้งว่าไม่มีความเกี่ยวข้องใด ๆ กับ IP ของ DigitalOcean ดังนั้นโมเด็มเดิมจึงยังคงเป็นกรณีที่ถูกบุกรุกด้วยวิธีอื่น ไม่ใช่วิธีที่เปิดเผยในบทความนี้
  • เนื่องจากส่งคืนโมเด็มเดิมไปแล้ว จึงไม่สามารถทำ firmware dump หรือวิเคราะห์ forensic ได้ และยังไม่ทราบเหตุผลที่ต้องเล่นทราฟฟิกซ้ำ

ไทม์ไลน์การเปิดเผย

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

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-06-05
ความคิดเห็นบน Hacker News
  • albinowax_ โพสต์เรื่องนี้ก่อน แต่ผมติดใจที่เขาไม่ได้รับคาร์มา เลยย้ายความคิดเห็นไปที่ https://news.ycombinator.com/item?id=40560010
    หวังว่า xrayarx จะโอเคกับเรื่องนี้ เรามีแผนจะทำระบบ แบ่งคาร์มา สำหรับกรณีแบบนี้ให้ถูกต้อง แต่ก่อนจะถึงตอนนั้น บางครั้งก็ต้องพึ่งวิธีทำมือแบบทื่อ ๆ อย่างนี้
    • ตามระบบแล้ว ผมโพสต์เมื่อ 13 ชั่วโมงก่อน ส่วนเขาโพสต์เมื่อ 10 ชั่วโมงก่อน ดังนั้นผมไม่ค่อยเข้าใจที่บอกว่าเขาโพสต์ก่อน