APNIC phân tích BGP hijack nhắm Softaculous: vì sao route RPKI-valid vẫn có thể chuyển hướng update độc hại

Bài viết này do AI tạo ra, có thể mắc sai sót.

Một vụ BGP hijack nhằm vào Softaculous Ltd — đơn vị phát triển Softaculous auto-installer và nền tảng quản lý VM Virtualizor — cho thấy RPKI Route Origin Validation (ROV) không phải lá chắn tuyệt đối. Theo phân tích APNIC/Kentik, kẻ tấn công dùng route cụ thể hơn cùng đường AS giả mạo, kết hợp chứng chỉ TLS hợp lệ, để phát tán gói cập nhật Virtualizor độc hại đến một số lượng nhỏ cài đặt.

Tóm tắt nhanh

Prefix 162.55.80.0/24 xuất hiện lúc 20:57 UTC ngày 28/8/2026, nằm trong dải 162.55.0.0/16 của Hetzner Online (AS24940).
AS path quan sát được: … 6204 62390 24940. APNIC cho rằng route nhiều khả năng xuất phát từ NexonHost (AS62390), qua compromise hoặc khách hàng khai thác lỗ hổng bảo mật.
Route vẫn RPKI-valid vì ROA của Hetzner cho AS24940 và cho phép độ dài prefix từ /16 đến /24; AS24940 bị gắn ở cuối path giả mạo.
Route /24 được ưu tiên hơn /16 theo longest-prefix match, làm traffic tới phần dải bị chuyển hướng.
Sau sự cố, Hetzner thu hẹp maxLength của một số ROA; APNIC nhấn mạnh strict ROA, giám sát BGP/DNS và ASPA là các lớp bổ sung.

Chuỗi tấn công: BGP hijack không đứng một mình

Softaculous cho biết kẻ tấn công đã dùng BGP hijack cùng chứng chỉ TLS “technically valid” để đưa gói cập nhật Virtualizor độc hại tới một số cài đặt. Điểm cần chú ý: HTTPS không tự bảo vệ được người dùng nếu kẻ tấn công đồng thời có thể điều hướng traffic kiểm tra quyền kiểm soát tên miền rồi lấy chứng chỉ hợp lệ.

APNIC dẫn cơ chế Multi-Perspective Issuance Corroboration (MPIC) của Let’s Encrypt: CA kiểm tra từ nhiều vị trí mạng độc lập và đòi quorum đồng thuận. Cách này chống được hijack cục bộ. Tuy nhiên, route /24 cụ thể hơn trong vụ này lan truyền đủ rộng, khiến nhiều vantage point cùng nhìn thấy tuyến đường do kẻ tấn công kiểm soát.

Vì sao RPKI-valid vẫn bị chiếm tuyến?

ROV xác nhận AS nào được phép originate một prefix. Nó không xác nhận toàn bộ AS path có hợp lý hay không. Trong sự cố, ROA của 162.55.0.0/16 cho AS24940 nhưng maxLength cho tới /24. Kẻ tấn công quảng bá 162.55.80.0/24, rồi thêm AS24940 làm origin ở cuối path, nên bản công bố vượt qua kiểm tra origin.

Do /24 không có route hợp lệ cạnh tranh, quy tắc longest-prefix match khiến nó thắng route /16 hợp lệ. Đây là khác biệt quan trọng: một route có thể “valid” theo kiểm tra origin nhưng vẫn là bất thường theo ý đồ định tuyến và quan hệ upstream thực tế.

Dòng thời gian và mức lan truyền

APNIC ghi nhận tuyến bị hijack pulsed on/off từ 20:57 UTC ngày 28/8. Hetzner bắt đầu announce chính prefix /24 vào khoảng 08:44 UTC ngày 29/8; route bị rút 14:10 ngày hôm sau. Hijack quay lại lúc 19:55 ngày 29/8, đến 05:45 UTC ngày 30/8 Hetzner announce lại /24 và route độc hại bị rút.

Lan truyền thấp hơn route hợp lệ nhưng vẫn đủ lớn để tạo nguy cơ chuyển hướng traffic diện rộng. Với Internet-facing dependency như update endpoint, chỉ một khoảng thời gian ngắn cũng có thể đủ để phân phối payload độc hại.

Việc NetOps cần làm

Kiểm tra ROA: origin phải đúng, maxLength nên khớp prefix thực tế khi không có lý do vận hành rõ ràng để nới rộng.
Reject route RPKI-invalid, nhưng không xem đây là kiểm soát duy nhất.
Thiết lập cảnh báo khi xuất hiện more-specific prefix, origin/upstream mới, hoặc thay đổi lan truyền bất thường cho dải IP và dependency quan trọng.
Giám sát cả BGP lẫn DNS/TLS/certificate transparency với update server, API, SSO và CDN quan trọng.
Đánh giá ASPA/path validation khi hệ sinh thái thiết bị và upstream hỗ trợ; ASPA có thể phát hiện upstream không nằm trong danh sách provider được ủy quyền.

ASPA và thay đổi sau sự cố

Hetzner đã đổi ROA của 162.55.0.0/16 về maxLength /16, đồng thời siết hai dải khác: 213.133.96.0/19 và 213.239.192.0/18. APNIC lưu ý vẫn còn nhiều ROA của AS24940 có khoảng maxLength rộng hơn route đang dùng, vì vậy việc siết này mới là một phần.

Theo APNIC, Hetzner cũng thêm ASPA để liệt kê provider được ủy quyền cho AS24940. Các mạng kiểm tra ASPA có thể từ chối AS path chứa upstream ngoài danh sách, như AS62390 trong sự cố này. ASPA bổ sung cho ROA: ROA kiểm tra origin, ASPA kiểm tra tính hợp lý của quan hệ provider-customer trong path.

Phân tích

Sự cố này là bài học rõ về “độ đúng cú pháp” khác với “độ đúng vận hành”. RPKI-valid không đồng nghĩa route chắc chắn an toàn; maxLength quá rộng và path bị giả có thể tạo khe hở. Cần dùng phòng thủ theo lớp: strict ROA giảm cửa sổ lan truyền, ROV lọc lỗi origin, ASPA tăng kiểm tra đường đi, còn BGP monitoring giúp phát hiện những thay đổi mà policy vẫn cho qua.

Với đội vận hành self-hosted, trọng tâm không chỉ là prefix của mình. Update repository, DNS, CA validation, CDN và SaaS đều là dependency có thể bị chuyển hướng. Kiểm kê dependency, pin/sign package update, dùng kiểm tra chữ ký và có cảnh báo routing là cách giảm blast radius thực tế hơn là chỉ tin vào biểu tượng khóa HTTPS.