Không cần hack server cập nhật: Hacker chiếm đường đi Internet để phát bản update độc hại

Một vụ BGP hijack cuối tháng 8/2026 đã chuyển hướng lưu lượng tới hạ tầng Softaculous/Virtualizor sang máy chủ của kẻ tấn công. Nhờ một tuyến giả nhưng vẫn vượt qua RPKI và một chứng chỉ TLS hợp lệ, hacker có thể phát bản cập nhật Virtualizor độc hại mà không cần xâm nhập trực tiếp máy chủ update chính thức.

Tháng 9 4, 2026

Không cần hack server cập nhật: Hacker chiếm đường đi Internet để phát bản update độc hại

Một cuộc tấn công chuỗi cung ứng phần mềm không nhất thiết phải bắt đầu bằng việc hack máy chủ build hoặc máy chủ cập nhật. Trong sự cố liên quan tới Softaculous và Virtualizor cuối tháng 8/2026, kẻ tấn công đi theo một con đường khác: chiếm quyền kiểm soát đường đi của lưu lượng Internet.

Bằng một cuộc BGP hijack, tuyến mạng dẫn tới một phần hạ tầng của Softaculous được chuyển hướng sang máy chủ do attacker kiểm soát. Máy chủ giả còn có được chứng chỉ TLS hợp lệ cho các domain liên quan. Khi một số hệ thống Virtualizor kiểm tra cập nhật trong đúng khoảng thời gian bị chuyển hướng, chúng có thể nhận về một package độc hại thay vì bản update chính thức.

Điểm đáng chú ý nhất là attacker không cần chứng minh đã xâm nhập máy chủ cập nhật thật của Softaculous. Họ tấn công lớp nằm thấp hơn DNS và HTTPS: hệ thống định tuyến toàn cầu quyết định gói tin sẽ đi tới đâu.

Sự cố xảy ra như thế nào?

Theo thông báo chính thức của Virtualizor, sự cố bắt đầu khoảng 20:57 UTC ngày 28/8/2026 và kết thúc khoảng 06:10 UTC ngày 30/8/2026. Prefix bị ảnh hưởng là 162.55.80.0/24, nằm bên trong dải địa chỉ lớn hơn 162.55.0.0/16 của Hetzner.

Dải /24 này chứa các địa chỉ phục vụ nhiều hệ thống Softaculous, bao gồm endpoint cập nhật phần mềm và khu vực client/billing.

Một tuyến BGP trái phép xuất hiện với đường đi có dạng:

... → AS6204 → AS62390 → AS24940

Trong đó AS24940 là ASN hợp lệ của Hetzner. Theo phân tích của Virtualizor, Kentik và BGPKIT, AS62390 đã quảng bá prefix 162.55.80.0/24 qua transit AS6204, đồng thời giữ AS24940 ở cuối AS path để Hetzner vẫn trông giống như origin của tuyến.

Vì /24 cụ thể hơn /16, những router chấp nhận cả hai tuyến sẽ ưu tiên /24 cho các địa chỉ nằm trong prefix đó.

Tại sao một prefix nhỏ hơn lại “thắng”?

Để hiểu vụ việc, cần tách hai khái niệm thường bị gộp chung: BGP path selection và longest-prefix match.

Giả sử Internet đang có một tuyến hợp lệ:

162.55.0.0/16 → Hetzner

Sau đó xuất hiện thêm:

162.55.80.0/24 → tuyến của attacker

Dải /24 chỉ chứa 256 địa chỉ, trong khi /16 chứa 65.536 địa chỉ. Nhưng với một IP nằm trong 162.55.80.0/24, tuyến /24 cụ thể hơn nên được ưu tiên trước tuyến /16.

Có thể hình dung /16 giống biển báo “đi hướng này để tới cả thành phố”, còn /24 giống biển báo “riêng con phố này hãy rẽ sang đường khác”. Đối với địa chỉ nằm trên con phố đó, chỉ dẫn cụ thể hơn sẽ thắng.

Đó là lý do attacker không cần chiếm toàn bộ không gian địa chỉ của Hetzner. Chỉ cần công bố một subnet đủ cụ thể bao quanh các IP quan trọng.

Đây không phải DNS hijack

Trong một cuộc DNS hijack, attacker làm thay đổi câu trả lời tên miền, ví dụ khiến update.example.com trỏ sang IP giả.

Ở đây, DNS có thể vẫn trả về đúng IP. Vấn đề nằm sau bước đó.

Máy chủ Virtualizor hỏi DNS và nhận địa chỉ chính xác. Nhưng khi hệ điều hành gửi packet tới IP đó, BGP của Internet đã dẫn packet sang một đường khác.

Vì vậy, DNSSEC một mình không giải quyết được tình huống này. Tên miền có thể được phân giải hoàn toàn chính xác nhưng traffic vẫn tới sai hạ tầng.

HTTPS cũng không cảnh báo

Thông thường, nếu attacker chuyển traffic tới một server giả rồi cố impersonate domain HTTPS, TLS sẽ trở thành lớp phòng thủ tiếp theo. Client sẽ kiểm tra certificate và từ chối kết nối nếu certificate không hợp lệ.

Nhưng trong sự cố này, attacker đã lấy được chứng chỉ TLS hợp lệ từ Let's Encrypt cho nhiều domain liên quan tới Softaculous và Virtualizor.

Nguyên nhân là quá trình xác minh quyền kiểm soát domain của Certificate Authority cũng đi qua Internet routing. Nếu CA cố kết nối tới IP của domain trong lúc tuyến đang bị hijack, request xác minh cũng có thể đi tới máy chủ của attacker.

Theo Virtualizor, certificate được cấp bao phủ nhiều tên miền, bao gồm virtualizor.com, api.virtualizor.com và files.virtualizor.com.

Kết quả là các connection bị chuyển hướng vẫn có thể thấy certificate hợp lệ và không xuất hiện cảnh báo TLS.

RPKI cũng không chặn được tuyến giả

Điểm kỹ thuật đáng chú ý nhất của vụ việc là tuyến hijack vẫn có thể được xem là RPKI-valid tại thời điểm tấn công.

RPKI, hay Resource Public Key Infrastructure, cho phép chủ sở hữu tài nguyên IP tạo Route Origin Authorization (ROA) để nói rằng một ASN cụ thể được phép originate một prefix nhất định.

ROA của Hetzner cho dải 162.55.0.0/16 cho phép origin AS24940 và cho phép prefix dài tới /24.

Attacker không quảng bá route với chính ASN của mình làm origin. AS path giả vẫn kết thúc bằng AS24940. Đồng thời prefix được quảng bá là /24, vẫn nằm trong giới hạn maxLength được ROA cho phép.

Với Route Origin Validation, hai câu hỏi cơ bản là:

ASN ở origin có được ROA cho phép không?
độ dài prefix có nằm trong giới hạn được ROA cho phép không?

Trong tuyến giả này, câu trả lời hình thức cho cả hai đều là “có”.

Điều RPKI origin validation không xác minh là: AS62390 có thực sự được phép tuyên bố rằng nó có kết nối tới AS24940 theo cách đó hay không?

Đây là một giới hạn quan trọng. RPKI ROV kiểm tra origin, không xác thực toàn bộ quan hệ giữa mọi ASN trong AS path.

Vì sao update độc hại lại được chấp nhận?

BGP hijack và TLS hợp lệ mới chỉ đưa client tới máy chủ của attacker. Vẫn còn một lớp phòng thủ cuối cùng có thể ngăn package giả: cryptographic code signing.

Nếu update client chỉ chấp nhận package được ký bằng private key của nhà phát triển, server giả có thể phân phối bất kỳ file nào nhưng client sẽ từ chối vì không có chữ ký hợp lệ.

Virtualizor xác nhận rằng tại thời điểm xảy ra sự cố, update client của sản phẩm chưa xác minh package bằng chữ ký mật mã. Vì vậy, nếu một installation kiểm tra cập nhật đúng lúc traffic bị divert, package đã sửa đổi từ máy chủ attacker không bị từ chối chỉ vì thiếu chữ ký chính thức.

Đây là mắt xích biến một sự cố routing thành một cuộc tấn công supply chain thực sự.

Một chuỗi lỗi phòng thủ xếp chồng lên nhau

Vụ việc đặc biệt đáng học vì attacker không cần phá một lớp bảo mật duy nhất theo kiểu “zero-day thần kỳ”. Thay vào đó, nhiều giả định tin cậy nhỏ đã xếp chồng lên nhau:

BGP chấp nhận một more-specific route giả;
AS path được dựng để origin vẫn trông như Hetzner;
ROA cho phép maxLength tới /24 nên route vượt Route Origin Validation;
CA validation đi qua chính tuyến mạng đang bị hijack;
attacker lấy được TLS certificate hợp lệ;
update client chưa kiểm tra chữ ký mật mã của package.

Không lớp nào tự nó đảm bảo attacker có thể cài malware. Nhưng khi tất cả cùng thất bại hoặc cùng có blind spot, kết quả cuối cùng là một update độc hại có thể được nhận như update hợp lệ.

Cuộc hijack kéo dài khoảng 33 giờ, nhưng không phải toàn Internet bị chuyển hướng liên tục

Virtualizor tái dựng sự cố từ dữ liệu RIPE RIS và cho biết cửa sổ tổng thể kéo dài khoảng 33,3 giờ, với hai đợt chính.

Đợt đầu bắt đầu khoảng 21:00 UTC ngày 28/8 và kéo dài tới khoảng 08:50 UTC ngày 29/8. Sau đó có khoảng 11 giờ diversion gần như biến mất khi Hetzner trực tiếp announce prefix /24 để đối phó. Đợt thứ hai bắt đầu khoảng 20:00 UTC ngày 29/8 và kéo dài tới khoảng 06:00 UTC ngày 30/8.

Trong các thời điểm tuyến giả lan truyền mạnh, gần như toàn bộ RIPE RIS peers đang giữ route /24 đều thấy đường đi qua hijacker. Nhưng Virtualizor nhấn mạnh đây là thước đo topology, không phải thống kê byte traffic thực tế.

Route cũng flap rất mạnh, vì vậy không phải mọi server Virtualizor đều bị divert liên tục trong suốt 33 giờ.

Chỉ một số ít Virtualizor installation được xác nhận nhận update độc hại

Theo Softaculous/Virtualizor, malicious package đã được giao tới một số lượng nhỏ Virtualizor installations. Công ty mô tả phạm vi là “a handful of servers”, không phải toàn bộ người dùng Virtualizor.

Lý do là để bị ảnh hưởng, một server phải đồng thời thỏa nhiều điều kiện: nó phải kiểm tra update trong đúng khoảng thời gian tuyến bị diverted, network của nó phải đang chấp nhận route giả và quá trình tải update phải hoàn tất.

Softaculous cũng cho biết họ không thể tạo danh sách chính xác tất cả server đã nhận malicious response vì các request đó đi tới hệ thống attacker và không xuất hiện trong log của server chính thức.

Do đó, vendor yêu cầu mọi operator Virtualizor đều thực hiện kiểm tra, kể cả khi không có dấu hiệu rõ ràng.

Dấu hiệu xâm nhập mà Virtualizor công bố

Một indicator of compromise quan trọng được Virtualizor đưa ra là systemd unit:

/etc/systemd/system/java-jre-update.service

Các phân tích sau đó cũng chỉ ra payload liên quan trong:

/usr/lib/jvm/.cache/jre-runtime.dat

Virtualizor khuyến cáo nếu phát hiện dấu hiệu compromise thì không nên chỉ xóa file ngay lập tức. Operator nên bảo toàn bằng chứng và liên hệ support trước khi remediation nếu có thể.

Vendor cũng khuyến nghị rotate toàn bộ Virtualizor API key, hạn chế API theo trusted IP, kiểm tra SSH key lạ, user mới, cron job hoặc scheduled task bất thường và outbound connection không mong đợi.

Tại sao đây là một supply-chain attack?

Supply-chain attack thường được hình dung như việc attacker xâm nhập repo source code, CI/CD pipeline hoặc server phát hành để chèn malware vào software chính thức.

Nhưng “chuỗi cung ứng” rộng hơn thế.

Từ nhà phát triển tới máy người dùng có nhiều mắt xích:

source code → build → signing → storage → DNS → routing → TLS → update client → installation

Nếu attacker không thể sửa package tại nơi nó được tạo ra, họ có thể thử thay package trên đường vận chuyển.

Trong trường hợp Virtualizor, điểm bị tấn công là routing. Nhưng vì package không có cơ chế xác minh mật mã độc lập ở phía client, việc thay đổi đường đi cũng đủ để thay đổi thứ mà client tin là “bản update chính thức”.

Bài học lớn nhất: HTTPS không nên là chữ ký phần mềm

HTTPS trả lời câu hỏi: kết nối hiện tại có được mã hóa tới endpoint sở hữu certificate hợp lệ cho domain hay không?

Code signing trả lời một câu hỏi khác: file này có thực sự được nhà phát triển được tin cậy ký hay không?

Hai lớp bảo vệ không thể thay thế nhau.

Nếu một package có chữ ký cryptographic được kiểm tra bằng public key đã pin hoặc được phân phối an toàn từ trước, attacker có thể chiếm DNS, routing hoặc mirror nhưng vẫn không thể tạo chữ ký mới nếu không có private signing key.

Đây là lý do các hệ thống update nhạy cảm thường cần:

signature cho package hoặc metadata;
key rotation có kiểm soát;
rollback protection;
hash hoặc manifest được ký;
cơ chế chống replay;
separation giữa server phân phối file và root of trust dùng để xác minh file.

RPKI vẫn quan trọng, nhưng không phải lá chắn hoàn chỉnh

Sự cố này không có nghĩa RPKI vô dụng. Ngược lại, RPKI chặn một lớp lớn các route leak và origin hijack đơn giản.

Nhưng thiết kế ROA rất quan trọng. Việc cấu hình maxLength rộng hơn mức thực sự cần thiết làm tăng số more-specific prefix có thể vẫn được coi là origin-valid nếu attacker giả được origin phù hợp.

Ngoài origin validation, giới routing còn phát triển các cơ chế khác để xác minh quan hệ giữa các AS, chẳng hạn ASPA, cùng với prefix filtering ở biên mạng.

Một transit provider nếu chỉ chấp nhận từ customer những prefix mà customer thực sự được phép announce có thể chặn loại route bất thường này ngay trước khi nó lan rộng.

BGP vẫn là một trong những lớp tin cậy cổ nhất của Internet

BGP được thiết kế trong một thời kỳ Internet nhỏ hơn rất nhiều và phần lớn các network operator có quan hệ tin cậy tương đối trực tiếp. Protocol này ưu tiên khả năng trao đổi route giữa các autonomous system hơn là xác minh mật mã mọi tuyên bố.

Internet hiện đại đã bổ sung nhiều lớp bảo vệ, nhưng phần lõi vẫn dựa đáng kể vào network policy và filtering đúng cách.

Đó là lý do một lỗi routing có thể tạo ảnh hưởng rất khác với một server bị hack. Nếu một máy chủ bị compromise, phạm vi thường gắn với hệ thống đó. Nếu một route quan trọng bị hijack và lan đủ rộng, hàng loạt client ở nhiều quốc gia có thể cùng bị dẫn tới sai destination.

“Ổ khóa xanh” không có nghĩa bạn đang nói chuyện với đúng hạ tầng

Với người dùng phổ thông, HTTPS thường được diễn giải đơn giản là “website an toàn”. Nhưng về kỹ thuật, certificate chỉ xác minh một chuỗi trust cụ thể.

Nếu attacker có thể thuyết phục CA rằng họ đang kiểm soát endpoint của domain trong đúng cửa sổ validation, họ có thể nhận certificate hoàn toàn hợp lệ mà không cần đánh cắp certificate cũ.

Vụ Virtualizor cho thấy routing security và PKI có thể tương tác theo cách nguy hiểm: CA sử dụng chính Internet mà nó đang cố xác minh.

Các CA hiện có nhiều biện pháp giảm rủi ro như multi-perspective validation, nhưng routing attack có phạm vi đủ rộng vẫn là một thách thức cần được thiết kế cẩn thận.

Virtualizor đã thay đổi gì sau sự cố?

Trong advisory ngày 31/8, Virtualizor cho biết đã phát hành phiên bản 3.2.9.9 kèm công cụ mitigation cho các exploit đã biết, báo cáo certificate để thu hồi và thông báo sự cố tới các network operator cùng CERT liên quan.

Công ty cũng tuyên bố sẽ triển khai code signing cho tất cả package và di chuyển sang hạ tầng tốt hơn.

Đây là thay đổi quan trọng nhất ở tầng software supply chain: ngay cả nếu routing bị tấn công lần nữa, client có thêm một root of trust độc lập để phân biệt package chính thức và package bị thay thế.

Nếu đang vận hành Virtualizor, nên làm gì?

Virtualizor yêu cầu operator coi mọi server là nằm trong phạm vi cần kiểm tra vì công ty không có log đầy đủ của những request đã bị chuyển hướng.

Các bước vendor khuyến nghị bao gồm:

kiểm tra indicator /etc/systemd/system/java-jre-update.service;
rotate toàn bộ Virtualizor API credentials và giới hạn API theo trusted IP;
audit SSH key, account, cron job, scheduled task và outbound connection bất thường;
sử dụng công cụ security scan chính thức của Virtualizor;
nếu phát hiện compromise, bảo toàn evidence và liên hệ support trước khi chỉ xóa dấu vết;
nếu đã đăng nhập client area hoặc nhập thông tin thanh toán trong cửa sổ sự cố, reset password và kiểm tra hoạt động tài khoản.

Trong môi trường sản xuất quan trọng, việc tìm thấy một IoC không nên được hiểu là chỉ cần xóa đúng file đó là server trở lại trạng thái đáng tin cậy. Cần đánh giá toàn bộ mức độ compromise, credential exposure và khả năng persistence khác.

Vụ việc cho thấy “đường vận chuyển” cũng là một phần của security boundary

Đây có lẽ là bài học rộng nhất của sự cố.

Một nhóm phát triển có thể bảo vệ source code, khóa CI/CD, bật MFA, harden máy chủ update và dùng HTTPS. Nhưng nếu phần mềm cuối cùng tin bất kỳ package nào đến từ một connection HTTPS tới đúng domain, thì trust boundary vẫn kéo dài ra ngoài data center.

Nó đi qua DNS, BGP, Certificate Authority, transit provider và ISP của client.

Security tốt không nên yêu cầu tất cả các lớp đó phải hoàn hảo cùng lúc. Một thiết kế robust cần giả định rằng ít nhất một lớp có thể thất bại.

Trong hệ thống update, chữ ký package chính là cơ chế tạo sự độc lập đó: network có thể nói “file này đến từ đâu”, nhưng cryptographic signature mới nên quyết định “file này có thực sự do nhà phát triển phát hành hay không”.