Áp dụng đủ 1.449 bản vá Oracle vẫn bị tấn công: Bài học về cấu hình bảo mật

25 tháng 8, 2026·5 phút đọc

Dù Oracle phát hành tới 1.449 bản vá vào cuối tháng 7, một cuộc tấn công mới cho thấy việc vá lỗi không thể thay thế các nguyên tắc bảo mật cơ bản. Kẻ tấn công đã lợi dụng tính năng hợp pháp của máy chủ Java trong Oracle Database để tải mã độc trực tiếp vào hệ thống. Chuyên gia cảnh báo các tổ chức cần siết chặt cấu hình thay vì chỉ tập trung vào vá lỗi.

Áp dụng đủ 1.449 bản vá Oracle vẫn bị tấn công: Bài học về cấu hình bảo mật

Áp dụng đủ 1.449 bản vá Oracle vẫn bị tấn công: Bài học về cấu hình bảo mật

Cuối tháng 7, Oracle phát hành gói vá lỗi khổng lồ với 1.449 bản vá trong một đợt cập nhật được đánh giá là “tồi tệ chưa từng thấy” đối với quản trị viên cơ sở dữ liệu. Tuy nhiên, một cuộc tấn công mới được phát hiện cho thấy, kể cả khi hệ thống đã được vá toàn bộ, nguy cơ vẫn hoàn toàn có thể xảy ra.

Theo chuyên gia Craig Savage, phụ trách an ninh mạng tại Spinnaker Support – đơn vị hỗ trợ bên thứ ba cho Oracle, cuộc tấn công này không phải do lỗi từ bản vá mà đến từ sự cấu hình thiếu an toàn của hệ thống.

Diễn biến cuộc tấn công

Hãng bảo mật Huntress cho biết vào tháng 7, họ phát hiện một vụ đánh cắp thông tin đăng nhập từ một máy chủ Oracle của một tổ chức nặc danh. Điểm khởi đầu là một cuộc tấn công SQL injection vào ứng dụng web công cộng của nạn nhân – kỹ thuật đã có từ lâu và thường có thể phòng tránh nếu làm tốt công tác vệ sinh thông tin.

Điều bất thường nằm ở bước tiếp theo sau khi kẻ tấn công giành được quyền truy cập ban đầu:

“Sau khi có quyền truy cập ban đầu, kẻ tấn công đã tải một bộ công cụ khai thác hậu khai thác (gọi là khunt) thông qua mã Java trong một cơ sở dữ liệu Oracle, đây là điểm mới của cuộc tấn công này.” – Huntress

Thay vì khai thác lỗ hổng, kẻ tấn công đã tận dụng tính năng hợp pháp của Oracle Database: máy chủ có một máy ảo Java (JVM) nhúng, cho phép người dùng lưu mã nguồn Java như một đối tượng trong cơ sở dữ liệu.

Chúng sử dụng lệnh CREATE JAVA SOURCE để đưa mã độc vào từ Tomcat thông qua kết nối cơ sở dữ liệu. Mã nguồn sau đó được biên dịch ngay bên trong cơ sở dữ liệu thành một đối tượng lược đồ.

Vấn đề không nằm ở bản vá

Theo ông Craig Savage, đây không phải là lỗ hổng của Oracle mà là sai lầm trong cấu hình:

“Oracle có JDK riêng. Bạn có thể xây dựng và chạy các chương trình Java trong cơ sở dữ liệu. Điều này không bao giờ nên nằm trong khả năng của một máy chủ web. Trong môi trường sản xuất thực tế, tính năng này cần phải bị khóa lại và chỉ được kích hoạt trong các cửa sổ phát triển hoặc bảo trì. Hệ thống này được cấu hình kém và bảo mật kém, nhưng đây không phải là lỗ hỏi của Oracle.”

Chuyên gia này nhấn mạnh rằng khả năng chạy Java trong cơ sở dữ liệu chỉ nên giới hạn ở tài khoản DBA và doanh nghiệp nên tắt chức năng biên dịch mã trên máy chủ sản xuất. Với những biện pháp này, mã Java tải xuống sẽ không thể được biên dịch.

Bài học cho doanh nghiệp Việt Nam

Savage cảnh báo rằng tội phạm mạng đang chuyển hướng sang khai thác các tính năng hợp pháp của phần mềm thay vì chỉ tìm kiếm lỗ hổng:

  • Chúng hiểu rõ sản phẩm và cách hoạt động của chúng.
  • Chúng biết cách tận dụng các chức năng bị bật sẵn nhưng không được kiểm soát.
  • Việc chỉ tập trung vào vá lỗi là không đủ.

“Chúng ta đang thấy ngày càng nhiều tình huống như thế này. Các băng nhóm tội phạm mạng giờ đây hiểu về các sản phẩm này. Họ không chỉ biết cách phá vỡ chúng mà còn biết các chức năng hợp pháp nào có thể lợi dụng nếu tính năng đó được bật. Đó là lời cảnh tỉnh.” – Craig Savage

Đối với cộng đồng quản trị cơ sở dữ liệu và an ninh mạng tại Việt Nam, câu chuyện này nhấn mạnh rằng patch management chỉ là một phần của bức tranh bảo mật tổng thể. Các doanh nghiệp cần:

  • Rà soát và vô hiệu hóa các tính năng không cần thiết trên máy chủ sản xuất.
  • Thiết lập nguyên tắc đặc quyền tối thiểu cho tài khoản cơ sở dữ liệu.
  • Kiểm tra định kỳ các cấu hình bảo mật của Oracle, đặc biệt là liên quan đến Java và các môi trường biên dịch.
  • Kết hợp giám sát hành vi bất thường bên cạnh việc quét lỗ hổng truyền thống.

Cuối cùng, bài học lớn nhất từ cuộc tấn công này: vá lỗi là cần thiết, nhưng chưa bao giờ là đủ. An toàn thông tin đòi hỏi một chiến lược toàn diện, bao gồm cấu hình an toàn, quản lý quyền truy cập và giám sát liên tục.

Minh họa tấn công SQL injection vào hệ thống OracleMinh họa tấn công SQL injection vào hệ thống Oracle

Kết luận

Sự việc do Huntress phát hiện một lần nữa cho thấy các giải pháp bảo mật truyền thống đang đối mặt với những thách thức mới khi kẻ tấn công ngày càng tinh vi hơn. Thay vì chỉ vội vàng áp dụng mọi bản vá, các tổ chức cần dành thời gian rà soát lại toàn bộ cấu hình hệ thống của mình – bởi đôi khi thứ tạo ra lỗ hổng lại là một tính năng hợp pháp tưởng chừng vô hại.

Ngành quản trị cơ sở dữ liệu tại Việt Nam nói riêng và thế giới nói chung cần ghi nhớ: bảo mật không chỉ là việc vá lỗi, mà còn là việc hiểu rõ và kiểm soát cách hệ thống vận hành.

Chia sẻ:FacebookX
Nội dung tổng hợp bằng AI, mang tính tham khảo. Xem bài gốc ↗