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

 (samcurry.net)
2 điểm bởi GN⁺ 2024-06-05 | 1 bình luận | Chia sẻ qua WhatsApp
  • Các yêu cầu HTTP từ mạng gia đình được phát lại y nguyên khoảng 10 giây sau từ một IP DigitalOcean, cho thấy dấu hiệu lưu lượng của nhiều thiết bị phía sau gateway Cox Panoramic Wifi đã bị lộ ra bên ngoài
  • Kết quả truy vết trên VirusTotal và URLscan cho thấy IP này từng liên quan đến domain phishing và một lượng lớn domain dạng word+6 digits+TLD, làm dấy lên khả năng đây là thuật toán sinh domain dùng cho C&C
  • Trong quá trình phân tích cổng Cox Business năm 2024, các API dựa trên Spring phía sau /api/cbma/ cùng tài liệu Swagger bị lộ, và chỉ cần lặp lại yêu cầu đã có thể vượt qua kiểm tra quyền
  • Các API bị lộ cho phép tìm kiếm khách hàng, xem PII tài khoản, tra cứu địa chỉ MAC thiết bị, thậm chí thay đổi cấu hình WiFi; logic tạo encryptedValue cũng có thể được gọi từ JavaScript phía frontend
  • Cox đã gỡ các API bị lộ trong vòng 6 giờ sau khi được báo cáo, nhưng dịch vụ này bắt đầu từ năm 2023 nên nguyên nhân vụ modem đầu tiên bị xâm nhập năm 2021 vẫn là một vấn đề riêng

Phát hiện yêu cầu HTTP bị phát lại trong mạng gia đình

  • Để kiểm thử lỗ hổng blind XXE, tôi dựng một máy chủ HTTP Python trên một instance AWS rồi gửi yêu cầu /test123 từ máy tính ở nhà
    • Yêu cầu ban đầu đến từ IP nhà 98.161.24.100
    • Khoảng 10 giây sau, một IP không rõ 159.65.76.209 gửi lại yêu cầu tới cùng đường dẫn
  • Khi yêu cầu cùng URL bằng Safari trên iPhone, cùng IP đó lại phát lại yêu cầu
    • Hiện tượng này lặp lại không chỉ trên máy tính ở nhà mà cả trên các thiết bị khác trong mạng gia đình
  • Với instance AWS mới và Nginx, cũng như instance GCP, cùng IP đó vẫn phát lại yêu cầu, nên khả năng đây là vấn đề của riêng AWS giảm xuống
    • Các khả năng còn lại là ISP, modem hoặc tuyến mạng đã bị xâm nhập
  • Tra cứu chủ sở hữu IP cho thấy 159.65.76.209 là địa chỉ của DigitalOcean, không phải địa chỉ của ISP

Hạ tầng độc hại trước đây liên quan đến IP DigitalOcean

  • Tra cứu VirusTotal xác nhận các domain từng được phân giải về IP này
    • Trong 5 domain gần đây, 3 domain là trang phishing và 2 domain trông giống máy chủ mail
    • Ví dụ domain:
      • regional.adidas.com.py
      • isglatam.online
      • isglatam.tk
      • mx12.limit742921.tokyo
      • mx12.jingoism44769.xyz
  • isglatam.online và isglatam.tk là các trang phishing nhắm vào công ty an ninh mạng Nam Mỹ isglatam.com
    • Website thật của ISG Latam cho biết đây là công ty đặt tại Paraguay và là đối tác của Crowdstrike, AppGate, Acunetix, DarkTrace, ForcePoint
  • Trên URLscan còn dấu vết hai domain này từng lưu trữ một trang phishing BeEF điển hình
  • Cùng một IP liên quan đến cả domain liên quan Adidas, phishing ISG Latam và hoạt động có vẻ là phát lại lưu lượng modem
    • Cũng có khả năng IP đã xoay vòng qua nhiều chủ sở hữu, nhưng khoảng cách thời gian giữa các hoạt động khá dài nên khả năng nó được tái cấp ngay cho một người dùng độc hại khác có vẻ thấp

Thay modem và điều tra lại sau 3 năm

  • Thiết bị đang dùng là Cox Panoramic Wifi gateway, và tôi đã đổi sang modem mới tại cửa hàng Cox
    • Thiết bị cũ là thiết bị thuê từ ISP nên phải trả lại
    • Vì vậy không thể dump firmware hay reverse engineering
  • Sau khi lắp modem mới, hiện tượng phát lại yêu cầu HTTP dừng hẳn
    • Không còn IP khác xuất hiện trong log
    • Thời điểm đó, ngoài kết luận rằng modem cũ đã bị xâm nhập, rất khó điều tra thêm
  • Đầu năm 2024, khoảng 3 năm sau, khi điều tra lại cùng những người quen trong ngành bảo mật, chúng tôi chú ý đến định dạng domain như limit742921.tokyo, jingoism44769.xyz
    • Khi tìm reverse IP cho các IP liên quan, phát hiện hơn 1.000 domain có cùng mẫu
  • Định dạng domain đều có cấu trúc word + 6 numbers + TLD
    • Do đượ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 thuật toán sinh domain mà kẻ vận hành độc hại dùng để che giấu địa chỉ máy chủ C&C
    • Domain cuối cùng quan sát được đăng ký ngày 17/03/2023, và sau đó không còn host nào được phân giải nữa
  • Modem mới thay thế cũng cùng model, nhưng theo tìm kiếm Google thì không thấy lỗ hổng công khai nào của model này

Giả thuyết bắt đầu từ công cụ hỗ trợ của ISP và TR-069

  • Khi chuyển modem Cox sang địa điểm mới, tôi xác nhận rằng nhân viên hỗ trợ ISP có thể thay đổi cấu hình thiết bị từ xa
    • Nhân viên hỗ trợ có thể cập nhật cấu hình thiết bị, đổi mật khẩu WiFi và xem các thiết bị đang kết nối
  • Việc quản lý từ xa này được thực hiện qua giao thức TR-069, được triển khai từ năm 2004
    • Đây là cách ISP quản lý thiết bị trong mạng của họ qua cổng 7547
    • Giao thức này từng được đề cập trong các bài trình bày DEF CON, nhưng không phải bề mặt bị phơi ra bên ngoài
  • Trọng tâm điều tra chuyển từ chính giao thức sang website quản lý thiết bị nội bộ mà nhân viên hỗ trợ sử dụng và các API phía sau nó
    • Nếu các API này có thể xem/thay đổi cấu hình thiết bị của khách hàng hoặc thực thi lệnh, chúng có thể là đường xâm nhập modem

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

  • Cổng Cox Business cung cấp chức năng quản lý thiết bị từ xa, thiết lập quy tắc tường lửa và giám sát lưu lượng mạng
  • Từ file JavaScript frontend main.36624ed36fb0ff5b.js của trang đăng nhập, tôi trích xuất các route
    • Xác nhận hơn 100 lệnh gọi API dựa trên /api/cbma/
    • Ví dụ:
      • /api/cbma/voicemail/services/voicemail/inbox/transcribeMessage/
      • /api/cbma/profile/services/profile/userroles/
      • /api/cbma/accountequipment/services/accountequipment/equipments/eligibleRebootDevice
  • /api/cbma/ trả về phản hồi khác với frontend thông thường, trông như một reverse proxy trỏ tới backend riêng
    • Yêu cầu /api/anything_else/example trả về redirect 301
    • Yêu cầu /api/cbma/example trả về 500 Internal Server Error
  • Yêu cầu đăng ký có nhiều header liên quan đến xác thực
    • Clientid: cbmauser
    • Apikey: 5d228662-aaa1-4a18-be1c-fb84db78cf13
    • Cb_session: unauthenticateduser
    • Authorization: Bearer undefined
  • Khi thử đổi HTTP method, phản hồi lỗi theo kiểu Spring được trả về, xác nhận backend dựa trên Spring

Tài liệu Swagger và bypass tài nguyên tĩnh

  • Không tìm thấy đường dẫn Spring actuator, nhưng có thể truy cập một phần đường dẫn Swagger UI
    • Đường dẫn /api/cbma/userauthorization/swagger-ui/index.html có phản hồi
  • Trang Swagger tải lần đầu trống
    • Các tài nguyên tĩnh như .png, .js, .css bị route về đường dẫn host gốc thay vì API proxy, gây redirect vô hạn
  • Dùng Burp Intruder thử thêm %00 đến %FF vào cuối URL cho thấy nếu thêm %2f, tức / được URL-encode, sau .js thì nhận 200 OK
    • Ví dụ: /swagger-initializer.js%2f
  • Sau khi dùng match-and-replace của Burp để thêm %2f vào mọi tài nguyên tĩnh, tài liệu Swagger tải bình thường
  • Tổng cộng xác nhận khoảng 700 lệnh gọi API
    • account: 115
    • voiceutilities: 73
    • user: 70
    • datainternetgateway: 57
    • accountequipment: 55
    • billing: 53
    • ticket: 52
    • Cùng các nhóm khác như profile, voicecallmanagement, voicemail, userauthorization, csr
  • Các API liên quan trực tiếp đến thiết bị và tài khoản khách hàng có vẻ quan trọng nhất là accountequipment, datainternetgateway, account

Bypass kiểm tra quyền bằng cách lặp lại yêu cầu

  • Khi kiểm tra liệu tất cả endpoint GET có thể truy cập khi chưa xác thực hay không, một số trả về lỗi xác thực, một số trả về 200 OK
  • Endpoint profilesearch ban đầu trả về phản hồi thành công với kết quả tìm kiếm trống
    • Cùng một yêu cầu có lúc trả về Authorization Error-Invalid User Token, gửi lại thì thành công
  • Khi gửi lại cùng yêu cầu nhiều lần, lỗi quyền biến mất và kết quả tìm kiếm khách hàng được trả về
    • Tìm cox trả về 10000+ hits
    • Tìm fbi trả về kết quả gồm địa chỉ vật lý của các văn phòng hiện trường FBI là khách hàng doanh nghiệp của Cox
  • Chỉ bằng việc lặp lại yêu cầu API đã có thể bypass quyền, và cùng vấn đề dường như ảnh hưởng trên hơn 700 API

Truy cập thiết bị khách hàng và tra cứu tài khoản

  • Để kiểm tra liệu Cox Business API có thể truy cập cả thiết bị mạng dân dụng hay không, tôi thử một API đơn giản nhận địa chỉ MAC
    • Endpoint: /api/cbma/accountequipment/services/accountequipment/ipAddress?macAddress=:mac
  • Sau khi xác nhận địa chỉ MAC trong tài khoản Cox của mình rồi lặp lại yêu cầu, API trả về địa chỉ IPv4 của modem của tôi
    • Điều này xác nhận API có thể thực sự giao tiếp với thiết bị Cox
  • API danh sách thiết bị dùng account ID cũng hoạt động
    • Endpoint: /api/cbma/accountequipment/services/accountequipment/v1/equipments/{accountId}
    • Phản hồi gồm thông tin thiết bị internet, thiết bị thoại và thiết bị TV
    • Trả về model thiết bị, loại thiết bị, địa chỉ MAC, danh sách cổng và số serial
  • API tra cứu người dùng theo email cũng trả về thông tin tài khoản doanh nghiệp
    • Ví dụ yêu cầu: /api/cbma/user/services/user/admin@cox.net
    • Bao gồm email, tên, số điện thoại, trạng thái, quyền, trạng thái chủ sở hữu hồ sơ, email thay thế, v.v.
  • Các 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 tài khoản doanh nghiệp

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

  • Yêu cầu thay đổi cấu hình phần cứng cần một tham số tên encryptedValue
    • Ví dụ: đổi mật khẩu thiết bị, đổi cấu hình WiFi
  • Trong JavaScript frontend, tôi lần theo logic tạo và giải mã encryptedValue
    • encryptWithSaltandPadding
    • decryptWithSaltandPadding
  • PIN 4 chữ số đặt khi đăng ký tài khoản cũng được mã hóa bằng cùng hàm, nên có thể đặt breakpoint trong trình gỡ lỗi trình duyệt tại điểm hàm đó được gọi rồi gọi trực tiếp từ console
  • Khi giải mã encryptedValue lấy từ phản hồi tài khoản thực, thấy giá trị có định dạng sau
    • Số tài khoản Cox
    • Tên thiết bị
    • ID thiết bị
    • Giá trị không rõ
    • Địa chỉ MAC
    • Nhãn
  • Ngay cả khi điền phần lớn trường như số tài khoản bằng giá trị tùy ý và chỉ nhập địa chỉ MAC hợp lệ để tạo encryptedValue mới, yêu cầu vẫn thành công
    • Máy chủ không kiểm tra account ID có khớp địa chỉ MAC hay không

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

  • Tôi gửi một yêu cầu POST đổi WiFi SSID của thiết bị mình thành Curry
    • Endpoint: /api/cbma/accountequipment/services/accountequipment/gatewaydevice/wifisettings
    • Body yêu cầu gồm wifiSettings, additionalProperties, encryptedValue
  • Phản hồi là {"message": "Success"}, sau đó mạng bị ngắt trong chốc lát rồi khởi động lại sau khoảng 5 phút
    • SSID thực sự đã đổi thành Curry
  • Hành vi này cho thấy thay đổi cấu hình thiết bị qua API được áp dụng lên thiết bị thật
    • Kẻ tấn công có thể lấy UUID tài khoản bằng tìm kiếm khách hàng
    • Tra cứu địa chỉ MAC của thiết bị kết nối
    • Đọc hoặc thay đổi cấu hình thiết bị dựa trên địa chỉ MAC
  • Quyền này tương đương mức truy cập của đội hỗ trợ ISP, là một đường có thể ảnh hưởng đến hàng triệu thiết bị Cox

Phạm vi ảnh hưởng và kịch bản tấn công

  • Tổ hợp lỗ hổng cho thấy kẻ tấn công bên ngoài có thể thực hiện các việc sau mà không cần điều kiện tiên quyết
    • Thực thi lệnh và thay đổi cấu hình trên hàng triệu modem
    • Truy cập PII của khách hàng Cox Business
    • Có được quyền tương tự đội hỗ trợ ISP
  • Cox là nhà cung cấp băng rộng tư nhân lớn nhất, nhà cung cấp truyền hình cáp lớn thứ ba, nhà mạng điện thoại lớn thứ bảy tại Mỹ, và là ISP phổ biến nhất ở 10 bang
  • Ví dụ luồng tấn công:
    • 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ề để xem toàn bộ PII tài khoản, địa chỉ MAC thiết bị, email, số điện thoại, địa chỉ
    • Dùng địa chỉ MAC phần cứng để xem mật khẩu WiFi và các thiết bị kết nối
    • Thực thi lệnh tùy ý, thay đổi thuộc tính thiết bị, chiếm đoạt tài khoản nạn nhân
  • Trong hơn 700 API bị lộ, nhiều API cung cấp chức năng quản trị và cùng vấn đề quyền xảy ra khi lặp lại yêu cầu

Báo cáo cho Cox và bản sửa

  • Các lỗ hổng được báo cáo qua responsible disclosure program của Cox
  • Cox đã gỡ các lệnh gọi API bị lộ trong vòng 6 giờ sau khi được báo cáo và bắt đầu sửa lỗ hổng quyền
    • Đến ngày hôm sau không còn tái hiện được lỗ hổng
  • Timeline công khai:
    • 2024-03-04: Báo cáo lỗ hổng cho Cox
    • 2024-03-05: Áp dụng hotpatch; các endpoint business không thiết yếu trả về 403 và ngừng hoạt động
    • 2024-03-06: Gửi email cho Cox thông báo không thể tái hiện lỗ hổng
    • 2024-03-07: Cox hồi đáp rằng họ sẽ bắt đầu đánh giá 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ừ báo cáo
    • 2024-04-29: Chia sẻ link bản nháp blog với Cox

Những câu hỏi còn lại

  • Cox đã điều tra việc liệu đường lỗ hổng cụ thể này từng bị khai thác trong quá khứ hay chưa, và xác nhận không có lịch sử khai thác
    • Dịch vụ này bắt đầu vận hành từ năm 2023
    • Vụ modem đầu tiên bị xâm nhập xảy ra năm 2021, nên lỗ hổng Cox Business API được công bố không phải nguyên nhân của vụ xâm nhập khi đó
  • Cox cho biết họ không liên quan gì đến IP DigitalOcean
    • Thiết bị thực sự đã bị hack, nhưng bằng một phương thức khác với lỗ hổng API được công bố
  • Modem không được cấu hình để có thể truy cập từ bên ngoài, và tôi cũng chưa từng đăng nhập vào thiết bị từ mạng gia đình
    • Một đường khả dĩ khác được nhắc tới là kiểu 0day dẫn từ CSRF cục bộ tới RCE
  • Câu hỏi lớn nhất là vì sao kẻ tấn công lại phát lại các yêu cầu HTTP
    • Nếu đã ở trong mạng, họ có thể truy cập mà không bị phát hiện, nhưng vẫn chưa rõ vì sao họ phát lại mọi yêu cầu HTTP

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-06-05
Các ý kiến trên Hacker News

  • Bài viết hay và dễ theo dõi. Đặc biệt thích việc Cox không tấn công người báo cáo hay phủ nhận vấn đề, mà hành xử như một hình mẫu về phản ứng bảo mật có trách nhiệm có thể kỳ vọng trong tình huống như vậy
    Muốn được xem bài tiếp theo nói rõ lỗi đã cho phép truy cập API trái phép một cách không liên tục là gì. Những lỗi kiểu này rất dễ bị bỏ sót khi kiểm thử nông, hoặc tùy nguyên nhân mà có thể hoàn toàn không tái hiện được trong môi trường kiểm thử

    • Đúng là Cox đã phản ứng có trách nhiệm, nhưng giá mà họ tận dụng tốt hơn cơ hội khi người ta mang thiết bị bị nhiễm đến ngay từ đầu
      Trước đây tôi từng tình cờ phát hiện một lỗ hổng nghiêm trọng ở một nhà mạng truyền thống, nhưng chỉ qua kênh hỗ trợ khách hàng thông thường thì mất gần một tuần mới liên hệ được đúng người, và tổ chức hỗ trợ hoàn toàn không thể escalation. Cox cũng có một chuyên gia an ninh thông tin trực tiếp mang thiết bị bị nhiễm tới, nhưng bộ phận hỗ trợ đã không xử lý việc đó đúng cách
    • Bài viết dễ đọc và phản ứng của Cox cũng tốt. Tôi cũng thích việc quá trình phát hiện và bản thân lỗi không được trình bày theo kiểu tiêu cực hay coi thường
    • Các công ty không nên kiện người tìm ra những thứ này vì “hack”, mà nên thưởng cho họ
    • Tôi cũng tò mò lỗi đã cho phép truy cập API trái phép một cách không liên tục là gì. Có lẽ cuối cùng ta sẽ không bao giờ biết, nhưng cũng có thể là một backend thử nghiệm không kiểm tra ủy quyền đã bị đưa nhầm vào cấu hình load balancer
    • Bài viết hay, nhưng việc cứ liên tục dùng super như “super curious”, “super interesting”, “super interested” thì hơi khó chịu

  • Điều gây bực trong những tình huống như thế này là khi ISP ép dùng modem hoặc router của họ. Ví dụ AT&T fiber dùng xác thực 802.1X dựa trên chứng chỉ để truy cập mạng; nếu không có thứ đó thì lẽ ra có thể cắm bất kỳ thiết bị nào vào ONT
    Có hoặc từng có cách bypass, nhưng tôi không muốn phải làm những thủ tục đó chỉ để dùng Internet, nên tôi tắt hết mọi chức năng của router AT&T và đặt router của mình, vốn được tôi quản lý cập nhật, ở phía sau nó. Nếu router AT&T bị hack, có thể tôi sẽ không nhận ra cho đến khi dịch vụ bị ảnh hưởng xấu. May mà ngày nay phần lớn đều dùng HTTPS

    • Nếu là AT&T fiber với ONT tách rời modem thì bypass 802.1X khá dễ. Chỉ cần cắm một switch không quản lý giữa modem và ONT, để modem xác thực, rồi rút modem ra
      Nếu ONT khởi động lại thì nhiều khả năng phải làm lại, nhưng trong trường hợp của tôi AT&T cấp UPS cho ONT nên tần suất reboot chắc sẽ thấp. Cá nhân tôi đã dựng một cấu hình phức tạp dựa trên NIC bypass: khi firewall tắt hoặc đang reboot thì traffic đi qua modem AT&T, còn khi firewall bật thì firewall của tôi nhận traffic và chuyển có chọn lọc qua modem. Nhưng thật ra chỉ dùng switch không quản lý cũng đã đủ
    • Khả năng router CPE của AT&T bị hack không tạo ra khác biệt lớn nếu giữa mạng của tôi và mạng AT&T đã có router của tôi. Dù bỏ router CPE của AT&T đi thì cuối cùng tôi vẫn kết nối tới một hộp đen mà tôi không kiểm soát, và thiết bị đó cũng có thể đã bị hack hoặc có thể kiểm tra traffic theo nhiều cách
    • May là Cox không phải kiểu ISP như vậy. Họ chấp nhận miễn là đó là modem DOCSIS đủ hiện đại, phù hợp với tốc độ đã đăng ký
      Nhưng lời khen Cox chỉ dừng ở đó. Tôi đang bị mất gói gián đoạn suốt 2 năm, và dù đã thu thập dữ liệu cho thấy một node cụ thể có lẽ đang bị quá tải thuê bao, dường như không có đường escalation hỗ trợ nào để tới được người có thể hiểu vấn đề
    • Tham khảo thêm: với xgspon, quy trình bypass giờ đã được tự động hóa. Đại khái là “cắm SFP+, tải firmware qua giao diện web, nhập số sê-ri thiết bị”, và tùy module SFP đang dùng mà bước 2 cũng có thể bỏ qua
      Thực tế, trạng thái 802.1X không được xác minh phía server. Tiêu chuẩn nói rằng nếu yêu cầu 802.1X mà không thực hiện thì modem không được chuyển tiếp traffic, nhưng đa số vẫn cứ chuyển tiếp hoặc có thể chỉnh để làm vậy. Phía AT&T không xác minh và luôn cho traffic đi qua; nội bộ thực tế đang diễn ra như thế
    • Có các cách kết nối mà không cần gateway AT&T, và nhiều phương pháp đã được tổng hợp tại https://pon.wiki/

  • Bài viết dễ đọc và cuộc điều tra cũng xuất sắc. Cũng tốt khi thấy một tập đoàn lớn không ném bom hạt nhân vào nhà nghiên cứu bảo mật
    Không chắc lắm, nhưng tôi nghi ngờ việc các request tới giao diện quản trị cục bộ của router Nokia này có được xác thực đúng cách hay không. Gần đây tôi được cấp đúng thiết bị đó, có một số thiết lập không thể đổi bằng quyền quản trị viên thông thường và ISP không cấp tài khoản super admin. Nhưng nếu dùng trình kiểm tra trang để bật lại các trường bị vô hiệu hóa rồi đổi giá trị, API vẫn chấp nhận nguyên xi. Trong tình trạng như vậy, nếu một ứng dụng có thể chạy trong mạng nội bộ thì việc chiếm router theo cách này có lẽ không khó, dù có vẻ là một điều kiện khá đặc thù

    • Việc 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ứ 3, nhà mạng điện thoại lớn thứ 7 và là ISP phổ biến nhất ở 10 bang khiến tôi nghĩ rằng ISP không nên lớn đến mức này
      Cox rõ ràng là mục tiêu tấn công hấp dẫn, và như ví dụ trong bài, một lỗ hổng đơn lẻ cũng có thể khiến cả văn phòng hiện trường của FBI gặp nguy hiểm. Có lẽ nên viết là “Cox tuyên bố đã điều tra” chứ không phải “Cox đã điều tra việc có bị khai thác trong quá khứ hay không và không tìm thấy hồ sơ”

  • Có thể tin câu “không có lịch sử bị khai thác trong quá khứ” không? Toàn bộ mạng trông thủng lỗ chỗ như phô mai Thụy Sĩ

    • Vì vậy mới gửi toàn bộ log vào bucket S3 của một tài khoản AWS chỉ có quyền ghi, và để đăng nhập vào tài khoản có thể thực hiện các thao tác khác trên bucket đó thì cần ba người. Tôi không biết Cox có làm vậy không, nhưng nếu thiết kế để có thể nói “không có lịch sử bị khai thác”, thì kiến trúc sẽ như thế
    • Nếu đã là bên bắt đầu cuộc đối thoại thì không thể vắng mặt đến cùng. Đến một lúc nào đó phải nói rằng “thông tin chúng tôi có là như vậy, và nó tốt hơn trước”
    • Nếu nói “không có”, trong bối cảnh đã phát hiện thiết bị bị nhiễm, thì điều đó cũng có thể có nghĩa là có các đường tấn công khác mà Cox có thể biết hoặc không biết

  • Nhiều router phải cập nhật firmware thủ công. Router GL.iNet gần đây trong 6 tháng qua đã có nhiều lỗ hổng thực thi mã từ xa, nên tốt nhất là nhanh chóng kiểm tra xem router của mình có bị hack không và nâng cấp firmware nếu có thể.
    Các triệu chứng thấy được từ góc độ người dùng thông thường là tốc độ Internet giảm, tín hiệu Wi‑Fi bị ngắt và thiết bị không kết nối được, router thì vẫn kết nối Internet nhưng trang quản trị nội bộ (192.168.8.1) không phản hồi. Trong trường hợp của tôi, kẻ tấn công đã cài ứng dụng Pawns của IPRoyal để biến router thành proxy server và kiếm tiền, đồng thời đánh cắp cả system log có thông tin về thời gian sử dụng và việc có kết nối NAS hay không, và còn có cả reverse shell. Cách xử lý nên theo thứ tự: cập nhật firmware, reset router để loại bỏ mã độc, vô hiệu hóa SSH, tắt truy cập từ xa như dynamic DNS. Nếu cần truy cập từ xa, có thể cân nhắc Cloudflare Tunnel, Zero Trust, GoodCloud, ZeroTier, Tailscale, nhưng tôi không rõ cái nào phù hợp. GL.iNet không tuân theo nguyên tắc đặc quyền tối thiểu, mặc định chạy tiến trình bằng root, và SSH cũng được bật mặc định với quyền truy cập root, nên có vẻ tốt hơn là nên tránh

  • Việc nói “không có lịch sử bị khai thác” có thể là vì ngay từ đầu không có đủ log hay dữ liệu audit, hoặc vì sau khi bị hack log không còn được lưu lại

    • Theo những gì thấy trong bài, đường tấn công cụ thể kiểu “thử lại yêu cầu trái phép cho đến khi được” rất dễ thấy trong log. Chỉ cần chính sách log cơ bản ghi lại path, IP, status code là đủ, và điều này gần với mặc định của hầu hết web server và framework
    • “Không có bằng chứng không phải là bằng chứng của sự không tồn tại” rất đúng trong trường hợp này
    • Hoặc cũng có thể họ đã nói dối. Nghĩ từ góc nhìn của Cox, tại sao họ lại công khai với người ngoài công ty rằng trước đây đã từng bị khai thác? Thực ra họ chẳng có lý do gì để công khai bất cứ điều gì

  • Hệ thống xác thực kiểu gì mà thỉnh thoảng lại cho cuộc gọi đi qua một cách ngẫu nhiên? Trông thật sự bất tài

    • Tôi từng phát hiện chuyện như vậy ở API của một vendor. Họ đăng ký current user provider dưới dạng singleton thay vì theo từng request, nên thỉnh thoảng có thể bám theo đuôi một người dùng đã xác thực
    • Tôi từng thấy một bug lớn tương tự. API từ chối request chưa xác thực đúng 10 phút, rồi cho phép đúng 1 phút, và chu kỳ này lặp vô tận. Tôi thật sự tò mò backend lúc đó đã xảy ra chuyện gì
    • Theo kinh nghiệm của tôi, chuyện này có thể do load balancer gây ra. Ví dụ như không route đúng tới server trong pool, hoặc cấu hình hay mức patch giữa các server khác nhau
    • Một số origin server mà request được route tới có thể đã bị cấu hình sai
    • Nếu API nằm sau reverse proxy thì cũng có khả năng là vấn đề cache

  • Họ có trả tiền không? Người này về cơ bản đã cứu Cox, và báo cho họ biết về việc hạ tầng bảo mật bị chiếm toàn quyền vốn không hề dễ phát hiện.
    Trông như anh ta chẳng nhận được gì vì đã làm “điều đúng đắn”, khá là xúc phạm. Việc công ty nhìn nhận một người mang thông tin quan trọng đến tận văn phòng có lẽ rất khác với cách người đó tự nhìn nhận bản thân. Trường hợp như thế này cho thấy rất rõ vì sao tuyệt đối không nên báo cáo 0day

    • Với Cox thì chỉ riêng việc không kiện người đã sửa sai cho họ đã có thể xem là may mắn rồi
    • Sam là một nhà nghiên cứu bảo mật rất nổi tiếng, nên dù kiếm hơn 350.000 USD mỗi năm cũng không có gì đáng ngạc nhiên. Những bài viết như thế này có thể mang lại khá nhiều tiền thông qua việc tăng uy tín
    • Cox không trả bug bounty

  • Câu hỏi còn bỏ ngỏ là những kẻ tấn công đã bắt HTTP traffic của anh ta bằng cách nào
    Một số CPE có tính năng kiểu cloud Wireshark để debug. Tôi không biết image firmware vận hành của Cox có tính năng như vậy hay không. Thường thì firmware vận hành và firmware thử nghiệm tách riêng, khiến việc kiểm thử vấn đề trong môi trường production khó hơn. Cox hẳn có thể kiểm tra ngoài hiện trường đang có những phiên bản firmware nào; ISP có thể tự động nâng cấp firmware không khớp với phiên bản cụ thể, và vì đây là modem của Cox nên nhiều khả năng họ cũng có firmware. Nếu đó là debug firmware thì tôi tò mò nó đã được đưa lên như thế nào và vì sao vẫn tiếp tục tồn tại

    • Trên Linux, nếu tạo socket bằng PF_PACKET thì có thể chặn bắt traffic trên mọi interface. Có thể hiểu như một tcpdump cấp thấp
      Chặn tất cả dữ liệu trên port 80, parse HTTP header rồi làm việc cần làm là khá dễ. Tuy nhiên tôi không rõ vì sao ai đó lại replay request
    • Nếu là HTTP chứ không phải HTTPS, thì bất kỳ ai hay thiết bị nào trên đường truyền cũng có thể thấy request
    • Đây là một lý do nữa để không tin và không dùng thiết bị do ISP cung cấp. Quản lý từ xa của ISP ư, xin miễn

  • Đây là một trong những lý do không nên vui mừng với cable modem do ISP cung cấp có Wi‑Fi, và nên bảo mật tốt các endpoint cũng như dịch vụ trong LAN. Tối thiểu, giữa modem/ISP cần có TLS và DNS over TLS
    Tôi thì chỉ để bridge mode, tắt Wi‑Fi, rồi để thiết bị của mình đảm nhiệm mọi chức năng mạng. Chiếc modem cuối cùng tôi thuê từ ISP đã không được ISP cập nhật firmware gần 10 năm, nhưng nhờ vậy mà nó rất ổn định

    • Cũng có ý kiến phản biện. Một ISP có hơn 1 triệu khách hàng có động lực nâng cấp home gateway “mãi mãi” để giảm chi phí đầu tư thiết bị
      Free, nơi tôi làm việc, là ISP ở Pháp và cũng cung cấp home gateway tại Ý qua Iliad; ngay cả thiết bị ra mắt năm 2011 vẫn còn được cập nhật. Nó chạy Linux 6.4 mới nhất, cung cấp các tính năng hiện đại như airtime QoS, cập nhật ứng dụng di động và nhiều tính năng phần mềm khác
    • Router là thiết bị IoT bị khai thác nhiều nhất trên Trái Đất, và vì người dùng cuối không vá nên lỗ hổng firmware thường tồn tại suốt nhiều năm. Nếu ISP có thể đẩy bản vá vào router và thu hồi thiết bị không thể vá, thì xét cả việc quyền sở hữu thuộc về ISP, đó là lợi ích ròng cho an ninh mạng
    • Tôi cũng để bridge mode và tắt Wi‑Fi. Tình cờ tôi đã yêu cầu lắp một modem đơn giản không có chức năng router và access point, và không biết rằng loại thiết bị đơn mục đích như vậy vẫn còn tồn tại
      Tôi mua một router tương đối ổn, cài OpenWrt, rồi nối bridge vào mạng thông qua thiết bị của ISP và nó hoạt động tốt. Giờ tôi dùng HTTPS cả trong LAN
    • Tôi đã nói với ISP rằng nếu họ không cho tôi dùng router của mình thì tôi sẽ chuyển sang ISP khác