Vụ hack hàng triệu modem và cuộc điều tra modem của tôi bị xâm nhập

• Sam Curry phát hiện các yêu cầu HTTP gửi từ mạng gia đình của mình bị phát lại nguyên vẹn từ một IP DigitalOcean sau 10 giây, và hiện tượng biến mất sau khi thay gateway Cox Panoramic Wifi, làm dấy lên nghi ngờ modem cũ đã bị xâm nhập
• IP phát lại 159.65.76.209 được liên kết với các tên miền liên quan đến Adidas, các tên miền phishing của ISG Latam, và các tên miền có vẻ dùng cho C&C được tạo theo thuật toán, nhưng con đường xâm nhập thực tế vẫn chưa được xác định
• Khi phân tích cổng Cox Business năm 2024, ông phát hiện API nền Spring và tài liệu Swagger nằm sau /api/cbma/; trong khoảng 700 API, một số cho thấy lỗi bỏ qua phân quyền khi luân phiên trả về lỗi xác thực và 200 OK
• Việc bỏ qua phân quyền này cho phép tìm kiếm khách hàng, xem PII tài khoản, tra địa chỉ MAC thiết bị, tra IP modem, đọc/ghi tài khoản Cox Business và thay đổi cấu hình thiết bị như đổi SSID WiFi; trong PoC, SSID của chính ông đã bị đổi thành Curry
• Sau khi nhận báo cáo, Cox gỡ API bị lộ trong vòng 6 giờ và đến hôm sau thì không thể tái hiện lỗi; công ty cho biết dịch vụ API này bắt đầu từ năm 2023, tách biệt với vụ modem bị xâm nhập năm 2021, và không có dấu hiệu từng bị khai thác trước đó

---

Lưu lượng bất thường bắt đầu từ modem tại nhà

• Để thử lỗ hổng blind XXE trên mạng gia đình, ông dựng một máy chủ HTTP Python đơn giản trên một instance AWS và kiểm tra xem có nhận được yêu cầu từ bên ngoài hay không
• Ngay sau khi yêu cầu gửi bằng curl từ máy tính ở nhà được ghi nhận bình thường, một IP lạ 159.65.76.209 lại gửi chính cùng đường dẫn đó sau 10 giây
• Khi dùng Safari trên iPhone để gọi một đường dẫn khác, cùng IP đó cũng phát lại cùng yêu cầu, cho thấy dường như không phải một máy cụ thể mà là toàn bộ lưu lượng mạng gia đình đang bị quan sát
• Hiện tượng tương tự tiếp diễn với instance AWS mới và Nginx, rồi cả instance GCP, nên khả năng AWS bị xâm nhập bị loại trừ
• Sau khi trả lại gateway Cox Panoramic Wifi cũ tại cửa hàng và thay bằng thiết bị mới, lưu lượng phát lại biến mất và log không còn xuất hiện “IP khác” nữa

Điều tra 159.65.76.209

• IP này được xác nhận thuộc DigitalOcean, không phải địa chỉ của ISP Cox
• Trong lịch sử VirusTotal, 3 trong 5 tên miền được liên kết gần đây là trang phishing, 2 tên miền còn lại trông như máy chủ mail
  • regional.adidas.com.py
  • isglatam.online
  • isglatam.tk
  • mx12.limit742921.tokyo
  • mx12.jingoism44769.xyz
• isglatam.online và isglatam.tk từng là website phishing nhắm vào công ty an ninh mạng Nam Mỹ isglatam.com
• Theo bản ghi URLscan, hai tên miền liên quan ISG Latam này host các trang phishing BeEF thông thường; có thể xem chi tiết tại kết quả urlscan.io
• Cùng một IP có liên hệ với Adidas, ISG Latam và việc phát lại lưu lượng modem, nhưng cũng không thể hoàn toàn loại trừ khả năng IP này đã được cấp phát lại giữa nhiều chủ sở hữu khác nhau

Phân tích được nối lại sau 3 năm

• Đầu năm 2024, bạn bè trong lĩnh vực bảo mật chú ý đến định dạng của limit742921.tokyo và jingoism44769.xyz
• Khi thực hiện tra cứu reverse IP dựa trên IP của subdomain mx1 của limit742921.tokyo, ông tìm thấy hơn 1.000 tên miền có cùng mẫu
• Tất cả tên miền đều có dạng [word][6 numbers].[TLD]
  • Ví dụ: acquire543225.biz
  • Ví dụ: battery935904.biz
  • Ví dụ: grocery634272.biz
• Vì được đăng ký hàng loạt và có cấu trúc mang tính thuật toán, chúng trông giống như thuật toán tạo tên miền mà tác nhân malware dùng để che giấu địa chỉ máy chủ C&C
• Tên miền được quan sát lần cuối được đăng ký vào ngày 17/03/2023; lúc đó host không còn phân giải được nữa và cũng không tìm thấy các tên miền tương tự mới đăng ký trên cùng IP

Giả thuyết bắt nguồn từ tính năng quản trị của ISP và TR-069

• Nhân viên hỗ trợ của Cox có thể cập nhật modem từ xa, đổi mật khẩu WiFi và xem các thiết bị đã kết nối
• Việc quản trị từ xa này gắn với giao thức TR-069 được triển khai từ năm 2004, cho phép ISP quản lý thiết bị trong mạng qua cổng 7547
• Bản thân TR-069 không bị lộ ra ngoài và đã từng được đề cập trong các bài nói chuyện tại DEF CON, nên trọng tâm chuyển sang công cụ hỗ trợ và API nội bộ mà nhân viên hỗ trợ sử dụng
• Ông cho rằng nếu kẻ tấn công muốn xâm nhập modem, chúng có thể nhắm vào hạ tầng nền của công cụ hỗ trợ, đặc biệt là các API có thể thay đổi cấu hình thiết bị khách hàng hoặc thực thi lệnh tùy ý
• Hướng điều tra này không nhằm khẳng định chính xác đường xâm nhập năm 2021, mà để kiểm tra tầng tin cậy giữa ISP và thiết bị khách hàng

Cấu trúc API của cổng Cox Business

• Trong file JavaScript frontend main.36624ed36fb0ff5b.js của cổng Cox Business, ông tìm thấy hơn 100 lời gọi API dựa trên /api/cbma/
• Đường dẫn /api/cbma/ có hành vi phản hồi khác với các đường dẫn /api/ khác, trông giống một API được proxy tới backend riêng biệt so với frontend
  • /api/anything_else/example trả về phản hồi chuyển hướng
  • /api/cbma/example trả về 500 Internal Server Error
• Yêu cầu đăng ký có các header như clientid, Apikey, Cb_session, Authorization, và hình dạng phản hồi cho thấy đây là backend dựa trên Spring
• Khi thay đổi HTTP method, phản hồi lỗi kiểu Spring xuất hiện, xác nhận backend API được xây dựng trên Spring
• Không tìm thấy đường dẫn actuator, nhưng có phát hiện đường dẫn Swagger UI

Tải vòng tài liệu Swagger và 700 API

• Swagger UI có tải lên nhưng tài nguyên tĩnh rơi vào vòng lặp chuyển hướng nên tài liệu trông như trống rỗng
• Có vẻ các yêu cầu tài nguyên tĩnh như .js, .css, .png bị định tuyến tới host mặc định thay vì qua API proxy
• Khi thêm %2f, tức ký tự / đã được mã hóa, vào cuối URL, ông có thể tải tài nguyên JavaScript tĩnh qua API proxy
• Dùng match-and-replace của Burp để thêm %2f vào các yêu cầu tài nguyên tĩnh giúp tài liệu Swagger hiển thị bình thường
• Tổng cộng xác nhận được khoảng 700 lời gọi API; trong đó các khu vực liên quan nhiều nhất tới chức năng thiết bị và tài khoản là accountequipment, datainternetgateway, và account

Bỏ qua xác thực và truy cập dữ liệu khách hàng

• Khi lặp lại yêu cầu với toàn bộ endpoint GET, một số endpoint trả lỗi xác thực còn một số trả 200 OK; thậm chí cùng một yêu cầu cũng cho kết quả thay đổi giữa các lần lặp
• Endpoint profilesearch ban đầu trả về kết quả tìm kiếm rỗng, sau đó cùng yêu cầu lại luân phiên giữa lỗi xác thực và phản hồi thành công
• Khi lặp lại yêu cầu với từ khóa cox, kết quả trả về giống hồ sơ khách hàng Cox Business kèm profileGuid
• Khi dùng từ khóa fbi, phản hồi trả về các kết quả chứa địa chỉ thực tế của nhiều văn phòng hiện trường FBI là khách hàng Cox Business
• Vấn đề phân quyền tương tự cũng ảnh hưởng các API khác; phát lại yêu cầu nhiều lần cho phép truy cập chức năng quản trị ngay cả khi chưa xác thực

Tra địa chỉ MAC thiết bị và thông tin tài khoản

• Sau khi lấy địa chỉ MAC modem của chính mình từ tài khoản Cox và đưa vào API có tham số macAddress, phản hồi trả về địa chỉ IPv4 của thiết bị đó
• Kết quả này xác nhận API của website Cox Business thực sự có thể giao tiếp với thiết bị thật
• API liệt kê thiết bị theo account ID trả về thông tin các thiết bị gắn với tài khoản
  • Danh mục thiết bị
  • Tên model
  • Địa chỉ MAC
  • Thông tin cổng
  • Số serial
• API tra người dùng theo email trả về thông tin tài khoản doanh nghiệp như tên, số điện thoại, trạng thái, loại người dùng, có phải chủ hồ sơ hay không và email thay thế
• Một yêu cầu POST cập nhật tài khoản tương tự cũng hoạt động, xác nhận có thể đọc và ghi trên tài khoản doanh nghiệp

encryptedValue và thay đổi cấu hình thiết bị

• Các yêu cầu thay đổi cấu hình thiết bị cần tham số encryptedValue
• Hai hàm encryptWithSaltandPadding và decryptWithSaltandPadding trong JavaScript nội bộ được dùng để mã hóa/giải mã giá trị bằng AES
• Mã PIN 4 chữ số được thiết lập khi đăng ký tài khoản cũng được mã hóa bằng cùng các hàm này, nên có thể lấy được ngữ cảnh thực thi của hàm trong trình gỡ lỗi của trình duyệt
• Khi giải mã encryptedValue có trong phản hồi thiết bị từ tài khoản của một người quen dùng Cox Business, ông thấy các thành phần sau
  • Số tài khoản Cox
  • Tên thiết bị
  • ID thiết bị
  • Một giá trị chưa rõ
  • Địa chỉ MAC
  • Nhãn
• Ngay cả khi thay số tài khoản và ID thiết bị bằng giá trị tùy ý, rồi mã hóa lại chuỗi với duy nhất địa chỉ MAC là hợp lệ, yêu cầu vẫn thành công, cho thấy máy chủ không kiểm tra tính khớp giữa địa chỉ MAC và tài khoản

Khả năng thay đổi cấu hình modem tùy ý

• Ông gửi một yêu cầu POST đổi WiFi SSID đối với địa chỉ MAC của chính thiết bị mình
• Phản hồi là 200 OK và Success, sau đó mạng tạm thời bị offline
• Khoảng 5 phút sau, mạng khởi động lại và SSID đã đổi thành Curry
• PoC này cho thấy API cập nhật cấu hình thiết bị thực sự hoạt động và kẻ tấn công có thể ghi đè cấu hình thiết bị qua API
• Mức quyền này tương đương hỗ trợ kỹ thuật của ISP và có thể ảnh hưởng tới hàng triệu thiết bị Cox có thể truy cập qua API

Phạm vi ảnh hưởng và luồng tấn công khả dĩ

• Tổ hợp lỗ hổng này tạo ra một con đường để kẻ tấn công từ bên ngoài, không cần điều kiện tiên quyết, có thể thay đổi cấu hình của hàng triệu modem, truy cập PII của khách hàng doanh nghiệp và giành quyền ở mức đội hỗ trợ ISP
• Cox là nhà cung cấp băng rộng tư nhân lớn nhất nước Mỹ, nhà cung cấp truyền hình cáp lớn thứ ba và nhà mạng điện thoại lớn thứ bảy, với hàng triệu khách hàng và là ISP phổ biến nhất tại 10 bang
• Luồng tấn công khả dĩ như sau
  • Tìm kiếm mục tiêu Cox Business bằng tên, số điện thoại, email, số tài khoản
  • Dùng UUID trả về để tra PII tài khoản, địa chỉ MAC thiết bị, email, số điện thoại, địa chỉ
  • Dùng địa chỉ MAC thiết bị để xem mật khẩu WiFi và các thiết bị đã kết nối
  • Thực thi lệnh tùy ý, cập nhật thuộc tính thiết bị, chiếm đoạt tài khoản nạn nhân
• Có hơn 700 API bị lộ và nhiều API trong số đó cung cấp chức năng quản trị như xem thiết bị kết nối với modem
• Mỗi API đều gặp cùng một vấn đề phân quyền, cho phép thực thi lệnh trái phép bằng cách lặp lại yêu cầu

Báo cáo, vá lỗi và những câu hỏi còn lại

• Lỗ hổng đã được báo qua responsible disclosure program của Cox
• Cox gỡ các lời gọi API bị lộ trong vòng 6 giờ và đến hôm sau thì không thể tái hiện lỗ hổng nữa
• Theo điều tra của Cox, vector này không có lịch sử bị khai thác trước đó, và dịch vụ chứa lỗ hổng chỉ bắt đầu từ năm 2023 nên không thể là nguyên nhân vụ modem bị xâm nhập năm 2021
• Cox cho biết họ không hề liên quan đến IP DigitalOcean, nên modem cũ có thể đã bị xâm nhập theo cách khác chứ không phải bằng phương pháp được công bố trong bài viết này
• Vì modem ban đầu đã bị trả lại nên không thể dump firmware hoặc phân tích pháp y, và lý do kẻ tấn công cố tình phát lại lưu lượng cũng vẫn chưa được làm rõ

Mốc thời gian công bố

• 2024-03-04: Báo cáo lỗ hổng qua chương trình công bố có trách nhiệm của Cox
• 2024-03-05: Áp dụng hotpatch, các endpoint doanh nghiệp không thiết yếu bắt đầu trả 403 và ngừng hoạt động
• 2024-03-06: Gửi email cho Cox rằng không thể tái hiện lỗ hổng nữa
• 2024-03-07: Cox phản hồi rằng họ sẽ bắt đầu một đợt rà soát bảo mật toàn diện
• 2024-04-10: Thông báo cho Cox ý định công bố sau 90 ngày kể từ khi báo cáo
• 2024-04-29: Chia sẻ liên kết bản nháp blog với Cox

[GN⁺]

Các ý kiến trên Hacker News

• albinowax_ đã đăng bài này trước, nhưng tôi thấy áy náy vì anh ấy không nhận được karma, nên tôi đã chuyển bình luận sang https://news.ycombinator.com/item?id=40560010
  Hy vọng xrayarx không phiền. Chúng tôi có kế hoạch triển khai đúng cách tính năng chia sẻ karma cho những trường hợp như thế này, nhưng cho đến lúc đó, đôi khi chúng tôi vẫn phải dựa vào cách thủ công khá thô sơ như vậy
  • Theo hệ thống thì tôi đăng 13 giờ trước, còn anh ấy đăng 10 giờ trước. Vì vậy tôi không hiểu lắm khi nói rằng anh ấy đã đăng trước