Lỗ hổng MongoDB nghiêm trọng: CVE-2025-14847 rò rỉ dữ liệu

Một khai thác Proof-of-Concept (PoC) có tên “mongobleed” đã được công bố cho CVE-2025-14847, một lỗ hổng MongoDB nghiêm trọng liên quan đến rò rỉ bộ nhớ chưa xác thực trong quá trình xử lý giải nén zlib của MongoDB. Lỗ hổng này là một CVE nghiêm trọng với điểm CVSS cao.

Tổng Quan về Lỗ Hổng CVE-2025-14847

Lỗ hổng CVE-2025-14847 cho phép kẻ tấn công trích xuất từ xa dữ liệu bộ nhớ chưa được khởi tạo mà không cần thông tin xác thực. Điều này có nguy cơ làm lộ các nhật ký nội bộ, số liệu thống kê hệ thống, và nhiều thông tin nhạy cảm khác, gây ra rủi ro bảo mật nghiêm trọng.

Cơ Chế Khai Thác Rò Rỉ Bộ Nhớ

Lỗ hổng này phát sinh từ lỗi trong quá trình xử lý các thông điệp nén của MongoDB. Kẻ tấn công gửi một thông điệp được tạo dựng đặc biệt, tuyên bố một “uncompressedSize” đã bị thổi phồng.

MongoDB cấp phát một bộ đệm lớn dựa trên yêu cầu này. Tuy nhiên, zlib chỉ giải nén dữ liệu thực tế vào phần đầu của bộ đệm.

Điểm mấu chốt là máy chủ coi toàn bộ bộ đệm là hợp lệ. Điều này khiến quá trình phân tích BSON diễn giải bộ nhớ chưa được khởi tạo là tên trường cho đến khi nó gặp các byte null.

Bằng cách dò tìm các offset khác nhau, kẻ tấn công có thể rò rỉ các khối bộ nhớ một cách có hệ thống. Joe Desimone, tác giả của “mongobleed”, giải thích rằng công cụ này quét các vùng bộ nhớ bằng cách tạo ra các tài liệu BSON bị lỗi với các trường có độ dài khác nhau.

Dữ Liệu Bị Rò Rỉ Tiềm Ẩn

Mỗi lần dò tìm có thể tiết lộ các đoạn thông tin quan trọng. Các loại dữ liệu đã được chứng minh là có thể bị rò rỉ bao gồm:

• Cấu hình MongoDB WiredTiger
• Thống kê /proc/meminfo
• Đường dẫn Docker
• UUID kết nối
• Địa chỉ IP của máy khách
• Các thông số hệ thống như “MemAvailable: 8554792 kB”
• Thống kê mạng như “SyncookiesFailed EmbryonicRsts”

Trong các bản demo, tổng số dữ liệu bị rò rỉ lên tới hơn 8.700 byte trên 42 đoạn khác nhau, cho thấy mức độ nghiêm trọng của rò rỉ dữ liệu nhạy cảm này.

Các Phiên Bản MongoDB Bị Ảnh Hưởng

Lỗ hổng này ảnh hưởng đến nhiều phiên bản MongoDB. Cụ thể, các phiên bản dưới đây cần được cập nhật ngay lập tức:

• MongoDB 7.0 trước 7.0.8
• MongoDB 6.0 trước 6.0.15
• MongoDB 5.0 trước 5.0.24
• MongoDB 4.4 trước 4.4.29
• MongoDB 4.2 trước 4.2.29

Chi Tiết Khai Thác và PoC Mongobleed

Khai thác “mongobleed” được thiết kế để dễ dàng triển khai, giúp các nhà nghiên cứu bảo mật và quản trị viên hệ thống đánh giá rủi ro một cách hiệu quả.

Công Cụ Khai Thác Python

Công cụ PoC được viết bằng Python. Cách sử dụng cơ bản khá đơn giản, cho phép quét các offset từ 20 đến 8192.

python3 mongobleed.py --host <target_ip_hoac_hostname>

Để thực hiện các quét sâu hơn và thu thập nhiều dữ liệu rò rỉ hơn, có thể mở rộng phạm vi quét lên đến 50.000 offset. Dữ liệu sau đó sẽ được xuất ra một tệp nhị phân để phân tích.

Môi Trường Thử Nghiệm

Joe Desimone đã cung cấp một thiết lập Docker Compose để dễ dàng tạo các phiên bản MongoDB dễ bị tổn thương, nhấn mạnh khả năng tái tạo lỗ hổng một cách dễ dàng cho mục đích thử nghiệm và nghiên cứu. Điều này giúp các chuyên gia hiểu rõ hơn về cách thức khai thác và tác động của lỗ hổng MongoDB này.

Biện Pháp Khắc Phục và Giảm Thiểu Rủi Ro

Đối với các tổ chức đang vận hành các phiên bản MongoDB dễ bị tổn thương, việc áp dụng các bản vá và biện pháp giảm thiểu là cực kỳ cấp bách.

Cập Nhật Bản Vá Bảo Mật

MongoDB đã vá lỗi này trong các bản commit upstream bằng cách xác thực độ dài đã giải nén trước khi xử lý bộ đệm. Việc này giúp ngăn chặn việc cấp phát bộ đệm quá lớn và đọc vào bộ nhớ chưa được khởi tạo.

Việc cập nhật lên các phiên bản đã vá lỗi là biện pháp phòng ngừa hiệu quả nhất. Các tổ chức nên ưu tiên triển khai các bản vá bảo mật này ngay lập tức.

Lỗ hổng ban đầu được công ty OX Security tiết lộ, với cảnh báo về rủi ro trích xuất dữ liệu trong các triển khai đám mây và container hóa.

Khuyến Nghị An Toàn

Các tổ chức chạy các phiên bản MongoDB bị phơi bày, thường thấy trong các ứng dụng web, phân tích và ngăn xếp NoSQL, phải đối mặt với áp lực vá lỗi khẩn cấp.

Ngoài việc cập nhật bản vá, cần thực hiện các biện pháp bổ sung:

• Vô hiệu hóa truy cập không xác thực: Đảm bảo rằng không có phiên bản MongoDB nào có thể truy cập được mà không cần xác thực.
• Giám sát lưu lượng mạng: Theo dõi các hoạt động quét bất thường trên cổng 27017, là cổng mặc định của MongoDB.

Việc rò rỉ bộ nhớ như CVE-2025-14847 đang ngày càng phổ biến, đặc biệt là các lỗi liên quan đến giải nén. Điều này nhấn mạnh tầm quan trọng của việc kiểm tra kỹ lưỡng các cơ chế xử lý dữ liệu đầu vào trong bảo mật cơ sở dữ liệu. Joe Desimone (@dez__) đã phát hành kho lưu trữ GitHub của mình để tăng cường nhận thức về mối đe dọa này.