CVE-2025-49704 và CVE-2025-49706 là hai lỗ hổng được nhà nghiên cứu Đinh Hồ Anh Khoa đến từ Công ty An ninh mạng Viettel (VCS) phát hiện tại cuộc thi Pwn2Own Berlin 2025, chúng đã được vá trong bản cập nhật Patch Tuesday tháng 7/2025. Đến nay, Microsoft đã phát hành bản cập nhật bảo mật bổ sung nhằm bảo vệ toàn diện cho tất cả các phiên bản SharePoint bị ảnh hưởng bởi CVE-2025-53770 và CVE-2025-53771.

Số liệu thống kê của Kaspersky cho thấy hoạt động khai thác trên diện rộng bắt đầu từ ngày 18/7/2025, những kẻ tấn công đã nhắm mục tiêu vào các máy chủ trên khắp thế giới tại Ai Cập, Jordan, Nga, Việt Nam và Zambia.

Trong quá trình phân tích, Kaspersky đã tìm thấy một bản sao lưu của các yêu cầu POST được xác định là chứa payload độc hại được sử dụng trong các cuộc tấn công, việc gửi một yêu cầu duy nhất này đến máy chủ cài đặt SharePoint bị ảnh hưởng là đủ để thực thi payload độc hại tại đó.

Phân tích của Kaspersky về lỗ hổng này cho thấy nó dựa vào các lỗ hổng đã được khắc phục trong CVE-2025-49704 và CVE-2025-49706 trong bản vá Patch Tuesday tháng 7/2025, nhưng chỉ bằng cách thay đổi một byte trong yêu cầu, các nhà nghiên cứu đã có thể bypass qua bản vá này.

Khai thác lỗ hổng

Nghiên cứu của Kaspersky bắt đầu bằng việc phân tích một yêu cầu POST liên quan đến làn sóng tấn công này vào máy chủ SharePoint.

Hình 1. Code trong yêu cầu POST

Trên Hình 1, có thể thấy yêu cầu POST này nhắm đến điểm cuối “/_layouts/15/ToolPane.aspx” và nhúng hai tham số: “MSOtlPn_Uri” và “MSOtlPn_DWP”. Khi kiểm tra code của ToolPane[.]aspx, bản thân tệp này không chứa nhiều chức năng và hầu hết code của nó nằm trong lớp ToolPane của namespace Microsoft[.]SharePoint[.]WebPartPages trong Microsoft[.]SharePoint[.]dll.

Khi phân tích lớp này, code hoạt động với hai tham số có trong lỗ hổng. Tuy nhiên, việc truy cập điểm cuối này trong điều kiện bình thường là không thể nếu không bypass xác thực trên máy chủ SharePoint bị tấn công. Đây chính là lúc lỗ hổng giả mạo Microsoft SharePoint Server đầu tiên CVE-2025-49706 phát huy tác dụng.

CVE-2025-49706

Lỗ hổng này nằm trong phương thức PostAuthenticateRequestHandler của Microsoft[.]SharePoint[.]dll. SharePoint yêu cầu Internet Information Services (IIS) phải được cấu hình ở chế độ tích hợp. Trong chế độ này, các giai đoạn xác thực IIS và ASP.NET được hợp nhất. Do đó, kết quả xác thực IIS không được xác định cho đến giai đoạn PostAuthenticateRequest, tại thời điểm cả hai phương thức xác thực ASP.NET và IIS đều đã hoàn tất. Do đó, phương thức PostAuthenticateRequestHandler sử dụng một loạt cờ để theo dõi các vi phạm xác thực tiềm ẩn. Một lỗi logic trong phương thức này cho phép bypass xác thực nếu tiêu đề “Referrer” của yêu cầu HTTP thiết lập bằng giá trị “/_layouts/SignOut.aspx”, “/_layouts/14/SignOut.aspx” hoặc “/_layouts/15/SignOut.aspx”.

Hình 2. Code dễ bị tấn công trong phương thức PostAuthenticateRequestHandler

Trong Hình 2, code xử lý yêu cầu đăng xuất và cũng được kích hoạt khi trang đăng xuất được chỉ định là trang giới thiệu. Khi flag6 được đặt thành false và flag7 được đặt thành true, cả hai nhánh có điều kiện có khả năng gây ra ngoại lệ “Unauthorized Access” đều bị bypass.

Hình 3. Kiểm tra truy cập trái phép bị bypass

Vào ngày 8/7/2025, Microsoft đã phát hành bản cập vá giải quyết lỗ hổng bảo mật này bằng cách giới thiệu các biện pháp kiểm tra bổ sung để phát hiện việc sử dụng điểm cuối “ToolPane.aspx” với trang đăng xuất được chỉ định là trang giới thiệu.

Hình 4. Bản vá lỗ hổng CVE-2025-49706

Kiểm tra bổ sung sử dụng phép so sánh không phân biệt chữ hoa, chữ thường để xác minh xem đường dẫn được yêu cầu có kết thúc bằng “ToolPane[.]aspx” hay không. Liệu có thể bypass kiểm tra này bằng cách sử dụng một điểm cuối khác không? Thử nghiệm của Kaspersky đã chỉ ra rằng kiểm tra này có thể dễ dàng bị bypass.

CVE-2025-53771

Kaspersky đã thành công trong việc bypass bản vá cho lỗ hổng CVE-2025-49706 bằng cách chỉ thêm một byte vào yêu cầu POST trong quá trình thử nghiệm khai thác. Để bypass, các nhà nghiên cứu chỉ cần thêm dấu “/” vào cuối đường dẫn “ToolPane[.]aspx” được yêu cầu.

Hình 5. Bypass qua bản vá lỗ hổng CVE-2025-49706

Vào ngày 20/7/2025, Microsoft đã phát hành bản cập nhật khắc phục lỗ hổng bypass này (CVE-2025-53771). Bản vá đã thay thế lệnh kiểm tra “ToolPane[.]aspx” để kiểm tra xem đường dẫn được yêu cầu có nằm trong danh sách các đường dẫn được phép sử dụng với trang đăng xuất làm liên kết giới thiệu hay không.

Hình 6. Bản vá lỗ hổng CVE-2025-53771

Danh sách cho phép này bao gồm các đường dẫn sau: “/_layouts/15/SignOut.aspx”, “/_layouts/15/1033/initstrings.js”, “/_layouts/15/init.js”, “/_layouts/15/theming.js”, “/ScriptResource.axd”, “/_layouts/15/blank.js”, “/ScriptResource.axd”, “/WebResource.axd”, “/_layouts/15/1033/styles/corev15.css”, “/_layouts/15/1033/styles/error.css”, “/_layouts/15/images/favicon.ico”, “/_layouts/15/1033/strings.js”, “/_layouts/15/core.js” và có thể chứa các đường dẫn bổ sung do quản trị viên thêm vào.

Khi kiểm tra việc bypass CVE-2025-49706 với bản cập nhật ngày 8/7 được cài đặt trên nền tảng debug SharePoint của Kaspersky, các nhà nghiên cứu nhận thấy một số hành vi kỳ lạ. Không chỉ việc bypass CVE-2025-49706 thành công, mà toàn bộ chuỗi khai thác cũng vậy. Tuy nhiên, có một câu hỏi đặt ra là, chẳng phải kẻ tấn công đã thêm một lỗ hổng thực thi mã từ xa Microsoft SharePoint khác là CVE-2025-49704, vốn được cho là đã được khắc phục trong cùng một bản cập nhật sao? Để hiểu tại sao toàn bộ chuỗi khai thác lại thành công trong trường hợp này, hãy cùng xem xét lỗ hổng CVE-2025-49704 và cách nó được khắc phục.

CVE-2025-49704

CVE-2025-49704 là một lỗ hổng giải tuần tự hóa dữ liệu không đáng tin cậy, tồn tại do xác thực nội dung XML không đúng cách. Khi xem xét yêu cầu POST khai thác, các nhà nghiên cứu cho biết, yêu cầu này chứa hai tham số được mã hóa URL: “MSOtlPn_Uri” và “MSOtlPn_DWP”. Có thể kiểm tra cách chúng được xử lý bằng cách kiểm tra code của phương thức GetPartPreviewAndPropertiesFromMarkup trong Microsoft.SharePoint.dll.

Một phân tích nhanh cho thấy “MSOtlPn_Uri” là một trang URL có thể trỏ đến bất kỳ tệp nào trong thư mục CONTROLTEMPLATES, trong khi đó tham số “MSOtlPn_DWP” chứa WebPart markup với định dạng rất giống với XML.

Hình 7. WebPart markup được kẻ tấn công sử dụng

Mặc dù “XML” này có trong tham số “MSOtlPn_DWP” không chứa lỗ hổng bảo mật, nhưng nó cho phép kẻ tấn công khởi tạo control ExcelDataSet từ Microsoft[.]PerformancePoint[.]Scorecards[.]Client[.]dll với thuộc tính CompressedDataTable được đặt thành payload độc hại, đồng thời kích hoạt quá trình xử lý bằng cách sử dụng getter thuộc tính DataTable.

Hình 8. Phương thức xử lý nội dung của thuộc tính CompressedDataTable

Khi xem xét code của phương thức getter thuộc tính DataTable của ExcelDataSet trong Microsoft[.]PerformancePoint[.]Scorecards[.]Client[.]dll, các nhà nghiên cứu tìm thấy phương thức GetObjectFromCompressedBase64String, chịu trách nhiệm giải tuần tự hóa nội dung thuộc tính CompressedDataTable. Dữ liệu dưới dạng chuỗi Base64 được giải mã, giải nén và truyền đến phương thức BinarySerialization[.]Deserialize từ Microsoft[.]SharePoint[.]dll.

Hình 9. Bộ dữ liệu Dataset khai thác lỗ hổng CVE-2025-49704

Kẻ tấn công sử dụng phương pháp này để cung cấp một DataSet độc hại có nội dung được giải tuần tự hóa như Hình 9, nó chứa một tệp XML với phần tử thuộc loại nguy hiểm “System[.]Collections[.]Generic[.]List`1[[System.Data[.]Services[.]Internal[.]ExpandedWrapper`2[...], System[.]Data[.]Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]]”, cho phép kẻ tấn công thực thi các phương thức tùy ý với sự trợ giúp của kỹ thuật ExpandedWrapper, nhằm khai thác việc giải tuần tự hóa XML không an toàn trong các ứng dụng dựa trên .NET framework.

Trên thực tế, điều này là không thể, vì BinarySerialization[.]Deserialize trong Microsoft[.]SharePoint[.]dll sử dụng một XmlValidator đặc biệt được thiết kế để bảo vệ chống lại kỹ thuật này, bằng cách kiểm tra kiểu của tất cả các phần tử có trong XML được cung cấp và đảm bảo rằng chúng nằm trong danh sách các kiểu được cho phép. Tuy nhiên, lỗ hổng này bypass bước kiểm tra này bằng cách đưa đối tượng ExpandedWrapper vào danh sách.

Bây giờ, để tìm hiểu lý do tại sao khai thác lại có hiệu quả trên nền tảng debug SharePoint của Kaspersky, hãy cùng xem cách khắc phục lỗ hổng bảo mật này. Trong bản vá Patch Tuesday, Microsoft không thực sự khắc phục lỗ hổng mà chỉ giảm thiểu bằng cách thêm lớp AddExcelDataSetToSafeControls mới vào namespace Microsoft[.]SharePoint[.]Upgrade. Lớp này chứa code mới sửa đổi tệp web[.]config và đánh dấu  control Microsoft[.]PerformancePoint[.]Scorecards[.]ExcelDataSet là không an toàn.

Vì SharePoint không tự thực thi code này sau khi cài đặt các bản cập nhật, nên cách duy nhất để đạt được hiệu quả bảo mật là chạy thủ công nâng cấp cấu hình bằng công cụ SharePoint Products Configuration Wizard. Đáng chú ý, hướng dẫn bảo mật cho CVE-2025-49704 không đề cập đến nhu cầu thực hiện bước này, điều đó có nghĩa là ít nhất một số quản trị viên SharePoint có thể bỏ qua nó. Trong khi đó, bất kỳ ai đã cài đặt bản cập nhật này nhưng không thực hiện nâng cấp cấu hình thủ công vẫn có nguy cơ bị tấn công.

CVE-2025-53770

Vào ngày 20/7/2025, Microsoft đã phát hành bản cập nhật với bản vá lỗ hổng CVE-2025-53770. Bản vá này giới thiệu một XmlValidator được cập nhật, hiện có thể xác thực chính xác các kiểu phần tử trong XML, ngăn chặn việc khai thác lỗ hổng mà không cần nâng cấp cấu hình, quan trọng hơn là giải quyết nguyên nhân gốc rễ và ngăn chặn việc khai thác lỗ hổng này thông qua các biện pháp kiểm soát khác ngoài Microsoft[.]PerformancePoint[.]Scorecards[.]ExcelDataSet.

Hình 10. Code xác minh kiểu phần tử mới trong XmlValidator được cập nhật

CVE-2020-1147

Nhiều nhà nghiên cứu quen thuộc với các khai thác SharePoint trước đây có thể cảm thấy rằng lỗ hổng CVE-2025-49704, CVE-2025-53770 và các khai thác được kẻ tấn công sử dụng khá giống với lỗ hổng thực thi mã từ xa .NET Framework, SharePoint Server và Visual Studio (CVE-2020-1147). Trên thực tế, nếu chúng ta so sánh CVE-2020-1147 và CVE-2025-49704/CVE-2025-53770, có thể thấy rằng chúng gần như giống hệt nhau. Sự khác biệt duy nhất là trong khai thác cho lỗ hổng CVE-2025-49704/CVE-2025-53770, đối tượng ExpandedWrapper nguy hiểm được đặt trong danh sách. Điều này làm cho CVE-2025-53770 có thể vá được lỗ hổng CVE-2020-1147.

Hình 11. Bộ dữ liệu Dataset khai thác lỗ hổng CVE-2020-1147

Kết luận

Mặc dù các bản vá cho lỗ hổng ToolShell hiện đã có sẵn để triển khai, các nhà nghiên cứu đánh giá rằng chuỗi khai thác này sẽ tiếp tục bị kẻ tấn công lợi dụng trong một thời gian dài. Kaspersky đã quan sát thấy tình trạng tương tự với các lỗ hổng bảo mật khác, chẳng hạn như ProxyLogon, PrintNightmare hoặc EternalBlue. Mặc dù đã được biết đến từ nhiều năm trước, nhiều tác nhân đe dọa vẫn tiếp tục lợi dụng chúng trong các cuộc tấn công để xâm nhập vào các hệ thống chưa được vá.

Để được bảo vệ tốt hơn trước các mối đe dọa như ToolShell, các tổ chức nên chú ý rằng, tốc độ áp dụng các bản vá bảo mật hiện nay là yếu tố quan trọng nhất khi xử lý các lỗ hổng. Vì các lỗ hổng bảo mật nghiêm trọng này thường bị khai thác công khai ngay sau khi được công bố, việc cài đặt bản vá càng sớm là điều vô cùng quan.