Oracle công bố 1.295 bản vá bảo mật, GMO bị tấn công: Doanh nghiệp Nhật cần nhìn lại rủi ro công nghệ

Ngày 20/10, Oracle công bố Critical Patch Update (CPU) với 1.295 bản vá bảo mật, liên quan đến 1.209 mã CVE riêng biệt. Các cập nhật trải rộng trên Oracle Database, Fusion Middleware, E-Business Suite, Java SE, MySQL cùng nhiều dòng sản phẩm khác. Con số 1.295 là số bản vá, không phải số lỗ hổng độc nhất. [1][2]

Oracle Fusion Middleware có 206 bản vá, trong đó 134 lỗ hổng được đánh giá có thể bị khai thác từ xa không cần xác thực. Oracle E-Business Suite nhận 194 bản vá; 31 lỗ hổng trong nhóm này thuộc diện có thể bị khai thác từ xa không cần đăng nhập. Đây là những sản phẩm có thể phục vụ kế toán, tài chính, đơn hàng, mua sắm và các quy trình trọng yếu. [1]

CVE-2026-101809 nằm trong thành phần Workflow Notification Mailer của E-Business Suite, được chấm CVSS 3.1 là 10,0/10. Theo Oracle, phiên bản 12.2.3–12.2.15 bị ảnh hưởng và điều kiện khai thác có thể bao gồm truy cập HTTP qua mạng không cần xác thực. Tuy nhiên, điểm CVSS cao không chứng minh mọi tổ chức dùng sản phẩm đều phơi nhiễm trực tiếp trước Internet: cần xét phiên bản, cấu hình và đường truy cập thực tế. [1]

Với các hệ thống ERP và ứng dụng nghiệp vụ đã triển khai lâu năm, vấn đề không đơn thuần là cài bản vá. Một ứng dụng có thể phụ thuộc middleware hoặc cơ sở dữ liệu cũ; cập nhật một thành phần đòi hỏi kiểm thử tương thích và điều phối với nhà cung cấp. Oracle cũng lưu ý E-Business Suite có thể chịu ảnh hưởng của lỗ hổng trong Database hoặc Fusion Middleware mà không xuất hiện trực tiếp trong bảng riêng của E-Business Suite. Vì thế, kiểm kê phải đi xuống các thành phần nền tảng. [1]

GMO Internet cho biết bắt đầu điều tra từ ngày 19/10 sau thông tin từ khách hàng và ngày 20/10 xác nhận mã trái phép trong một số môi trường máy chủ của Onamae.com Desktop Cloud. Đến 4 giờ sáng 21/10, công ty bắt đầu dừng máy chủ thuộc toàn bộ các gói dịch vụ để hạn chế thiệt hại. Dịch vụ này cung cấp môi trường máy tính từ xa, được một số khách hàng sử dụng để vận hành giao dịch ngoại hối tự động. [3]

GMO xác định 26.739 máy chủ thuộc phạm vi có thể bị ảnh hưởng. Đây không phải số máy chủ đã xác nhận bị xâm nhập. Đến ngày 24/10, công ty xác nhận dữ liệu khách hàng đã bị đưa ra ngoài và nhận được báo cáo về các giao dịch tài khoản mà khách hàng không cho phép; thông tin đăng nhập giao dịch lưu trong môi trường dịch vụ là một trong các loại dữ liệu có khả năng bị ảnh hưởng. [3][4]

Công ty cho biết phía tấn công yêu cầu khoảng 8 tỷ yen tiền chuộc. Ngày 27/10, GMO xác nhận đối tượng được cho là thủ phạm đã công khai thông tin tự nhận là của công ty và khách hàng; nội dung vẫn phải được kiểm chứng và không thể mặc nhiên coi toàn bộ tuyên bố của đối tượng tấn công là đúng. Họ cũng từng đe dọa phát tán dữ liệu và tấn công ransomware vào thiết bị khách hàng. [5]

Đến ngày 28/10, việc kiểm tra các thiết bị khách hàng đã tiếp nhận chưa phát hiện dấu vết ransomware; công tác phân tích vẫn tiếp tục, nên không thể kết luận tất cả thiết bị đều an toàn. GMO đồng thời cho biết tên miền dùng để công khai thông tin của phía tấn công đã bị đình chỉ. Chương trình treo thưởng tối đa 1 triệu USD được GMO mở ngày 28/10; đến 29/10, công ty cho biết đã tiếp nhận 270 thông tin và đang chuyển các manh mối đáng chú ý tới cơ quan chức năng. [6][7]

GMO công bố khoản hỗ trợ 5.000 yen cho khách hàng đang dùng dịch vụ và chính sách bồi thường một số tổn thất giao dịch trái phép theo điều kiện xác minh. Sự cố cho thấy chi phí không dừng ở việc sửa hệ thống: còn có gián đoạn vận hành, điều tra, hỗ trợ khách hàng, xử lý khiếu nại và rủi ro đối với tài khoản bên ngoài hạ tầng ban đầu. [4]

Ngày 27/10, Sony Network Communications công bố truy cập trái phép vào cơ sở dữ liệu hội viên So-net. Cuộc xâm nhập được xác định xảy ra 19/10 và được phát hiện 23/10. Thông tin có khả năng bị ảnh hưởng liên quan 2.585.481 hồ sơ So-net và plala (S course), gồm tên, số điện thoại, email và các mã định danh. Riêng 54.401 địa chỉ email thuộc một số dịch vụ bị lộ cả mật khẩu, khiến công ty phải đặt lại thông tin xác thực liên quan. [8]

Rakuten Travel ngày 26/10 thông báo hai sự cố. Một sự cố phát hiện từ ngày 10/9 tại một số trang đặt khách sạn nước ngoài do Rakuten Travel Xchange quản lý, với phạm vi truy cập trái phép có thể liên quan tới khoảng 2,6 triệu tài khoản đăng nhập và một nhóm nhỏ hơn liên quan đến dữ liệu đặt chỗ. Sự cố khác được phát hiện ngày 20/10 tại website đặt phòng đa ngôn ngữ, với tối đa khoảng 860.000 tài khoản trong phạm vi. Không thể cộng hai con số thành tổng số khách hàng riêng biệt. [9]

Ngày 28/10, JAL thông báo khoảng 92.000 khách hàng có dấu hiệu dữ liệu đặt chỗ bị truy cập qua hệ thống Amadeus của đối tác cung cấp dịch vụ. Trong đó khoảng 90.000 trường hợp liên quan các thông tin như tên, mã đặt chỗ, hành trình và ngày bay; khoảng 2.000 trường hợp có thể bao gồm email, số điện thoại, số hộ chiếu và những trường dữ liệu khác. JAL cho biết chưa ghi nhận việc lộ dữ liệu thẻ tín dụng hoặc mật khẩu và không có tác động đến hoạt động bay. [10]

Các sự cố có thời điểm xảy ra, thời điểm phát hiện và ngày công bố khác nhau. Chúng cũng không chứng minh mọi doanh nghiệp đang chịu cùng một chiến dịch tấn công. Nhưng chúng cho thấy mức độ rủi ro phụ thuộc rất lớn vào loại dữ liệu bị ảnh hưởng, quyền truy cập của đối tác và biện pháp bảo vệ sau sự cố.

Từ các diễn biến trên, Automize chia vấn đề thành ba lớp liên kết. Lớp thứ nhất là phần mềm và hạ tầng kỹ thuật: doanh nghiệp cần biết hệ thống nào đang dùng sản phẩm, phiên bản và thành phần nào, cùng khả năng bị truy cập từ bên ngoài. Đó là bài học trực tiếp từ bản cập nhật Oracle.

Lớp thứ hai là nhà cung cấp cloud, SaaS và các đối tác vận hành. Một phần của quy trình kinh doanh có thể nằm ngoài mạng nội bộ, nhưng hậu quả khi nhà cung cấp bị tấn công vẫn có thể quay về phía khách hàng. Cần xác định quyền truy cập, trách nhiệm bảo mật, cơ chế thông báo sự cố và phương án vận hành thay thế.

Lớp thứ ba là dữ liệu và tính liên tục kinh doanh. Hệ thống có thể vẫn hoạt động khi dữ liệu bị lộ, hoặc buộc phải dừng để điều tra dù chưa xác nhận thiệt hại trên toàn bộ phạm vi. Cách đánh giá đúng phải xem xét loại dữ liệu, khả năng lạm dụng thông tin xác thực, thời gian gián đoạn và tác động đối với khách hàng.

Định hướng này phù hợp với Cybersecurity Management Guidelines v3.0 của METI, nhấn mạnh trách nhiệm của lãnh đạo, quản lý rủi ro chuỗi cung ứng và khả năng ứng phó, phục hồi. Việc quyết định vá ngay hay bảo trì có kiểm soát cần dựa trên nguy cơ phơi nhiễm, tác động kinh doanh và các biện pháp giảm thiểu tạm thời, không chỉ theo điểm CVSS. [11]

Với hệ thống Oracle, hãy đối chiếu bản kiểm kê tài sản công nghệ với thông báo CPU tháng 10: phiên bản nào bị ảnh hưởng, thành phần nào phơi nhiễm mạng, ứng dụng nghiệp vụ nào phụ thuộc và ai chịu trách nhiệm cập nhật. Các hệ thống Internet-facing hoặc giữ dữ liệu, nghiệp vụ trọng yếu cần được đánh giá trước. Khi chưa thể vá ngay, cần giảm quyền truy cập, cô lập đường kết nối không cần thiết và tăng cường giám sát; đây chỉ là biện pháp tạm thời, không thay thế bản vá. [1]

Với dịch vụ cloud và thuê ngoài, cần lập danh mục dữ liệu đang giao cho bên thứ ba, quyền quản trị và tài khoản dùng chung. Áp dụng xác thực đa yếu tố nếu khả thi, thu hồi các quyền không cần thiết và chuẩn bị thay đổi mật khẩu hoặc token khi có sự cố. Đồng thời, phải biết sẽ duy trì hoạt động bằng cách nào nếu một dịch vụ quan trọng phải dừng đột ngột.

Bản sao lưu chỉ có giá trị khi việc phục hồi đã được kiểm chứng. Doanh nghiệp nên diễn tập thời gian khôi phục và trách nhiệm giữa IT, vận hành, nhà cung cấp và bộ phận chăm sóc khách hàng. Khi có dữ liệu cá nhân bị ảnh hưởng, quy trình cần bảo toàn chứng cứ, đánh giá nghĩa vụ thông báo và truyền đạt thông tin chính xác, tránh suy đoán trước khi điều tra hoàn tất.

Ở cấp quản lý, một báo cáo an ninh hữu ích cần trả lời: hệ thống trọng yếu nào đang có rủi ro, tổn thất kinh doanh có thể là gì, ai sở hữu hành động khắc phục, hạn chót ở đâu và phần rủi ro còn lại được ai chấp nhận.

Oracle cho thấy độ phức tạp của việc duy trì bảo mật phần mềm doanh nghiệp. GMO minh họa cách một sự cố nhà cung cấp có thể kéo theo gián đoạn, nguy cơ lạm dụng thông tin xác thực và chi phí hỗ trợ khách hàng. So-net, Rakuten Travel và JAL nhắc rằng dữ liệu có thể nằm trong nhiều hệ thống và đối tác khác nhau, với hệ quả không giống nhau.

Không doanh nghiệp nào bảo đảm loại bỏ mọi rủi ro tấn công. Nhưng việc hiểu hệ thống đang phụ thuộc vào đâu, giới hạn phạm vi ảnh hưởng khi có sự cố và kiểm thử khả năng khôi phục giúp giảm hậu quả có thể tránh được. Đối với doanh nghiệp Nhật Bản, bảo mật cần được đưa vào quyết định quản trị công nghệ, vận hành và lựa chọn nhà cung cấp, thay vì chỉ giao cho IT vào những ngày có bản vá mới.