【翻译】CVE-2023-36899 ASP.NET框架IIS验证绕过与提权

最初，我想寻找一种很新的技术来改进我的IIS短文件名泄露利用程序，在这个过程中，我发现CookieLess可以在URI中使用两次，这样就可以绕过一些WAF策略了。很快啊，我直接将这个发现发布到了推特(X)上。链接：https://twitter.com/irsdl/status/1640390106312835072

然而事情并没有我想的那么简单，这个会话ID可以重复两次的问题最终让我向微软报告了两个漏洞：IIS路径绕过导致潜在的身份验证绕过；APP应用池混乱导致潜在提权。之后微软在一个补丁中修复了这两个漏洞，并且分配了CVE编号：CVE-2023-36899

当然我很疑惑微软为啥把两个漏洞合并成一个，只给了一个漏洞的奖金。微软的回复是：这是我们这边的一个技术原因导致的。是故意不小心的。

IIS路径验证绕过

我们可以尝试利用.NET 框架的CookieLess特性绕过IIS针对某些路径的访问限制，例如以下场景：

1、/webform/protected/target1.aspx中，/protected/路径配置了HTTP Basic认证，需要经过身份认证才能访问target1.aspx页面。
2、target2.aspx页面有一个已知问题暂时未修复，于是运维将它移动到了/webform/bin/target2.aspx位置。

https://victim.com/webform/protected/target1.aspxhttps://victim.com/webform/bin/target2.aspx

通常，访问以上两个页面时会被IIS拦截。但是我们可以利用CookieLess特性构造如下URL绕过限制进行访问：

https://victim.com/webform/(S(X))/prot/(S(X))ected/target1.aspxhttps://victim.com/webform/(S(X))/b/(S(X))in/target2.aspx

在IIS中对目录启用HTTP Basic认证的配置如下：

我们使用普通的请求访问会被拦截：

但是在URL中插入CookieLess代码，就可以绕过了

造成这个漏洞的根本原因是，.NET Framework处理包含CookieLess的请求时会重写URL。

internal String RemoveAppPathModifier(string virtualPath) {    if (String.IsNullOrEmpty(_appPathModifier))        return virtualPath;
    int pos = virtualPath.IndexOf(_appPathModifier, StringComparison.Ordinal);
    if (pos <= 0 || virtualPath[pos-1] != '/')        return virtualPath;
    return virtualPath.Substring(0, pos-1) + virtualPath.Substring(pos + _appPathModifier.Length);}

RemoveAppPathModifier()方法是在CookielessHelperClass类中的RemoveCookielessValuesFromPath ()方法调用的，代码链接：https://referencesource.microsoft.com/#System.Web/Security/CookielessHelper.cs,113

在方法调用时，URL中的CookieLess被清除，并且不会继续进行URL身份校验。

APP池提权

CookieLess的特性还可能导致应用直接使用父级应用的权限运行。演示环境如下：

网站的根目录 (/) 与 DefaultAppPool 应用程序池一起运行

/classic/ 应用程序使用 .NET v4.5 经典应用程序池

/classic/nodotnet/ 应用程序使用 NoManagedCodeClassic 应用程序池，不支持托管代码。

在每个应用程序下编写可访问的aspx文件，用于输出当前应用程序池

<%@ Page Language="C#" %><%string appPoolName = System.Environment.GetEnvironmentVariable("APP_POOL_ID");Response.Write("App Pool Name: " + appPoolName);%>

理想情况下访问这三个页面得到的结果应该是

/AppPoolPrint.aspx -> DefaultAppPool/classic/AppPoolPrint.aspx -> .NET v4.5 Classic/classic/nodotnet/AppPoolPrint.aspx -> Error: 404 Not Found (as Managed Code isn't supported)

然而，当我们在URL中插入CookieLess代码时得到的访问结果如下：

/(S(X))/(S(X))/classic/AppPoolPrint.aspx -> DefaultAppPool/(S(X))/(S(X))/classic/nodotnet/AppPoolPrint.aspx -> DefaultAppPool/classic/(S(X))/(S(X))/nodotnet/AppPoolPrint.aspx -> .NET v4.5 Classic

这样我们甚至可以在不支持托管代码的/classic/nodotnet/应用下使用其父应用程序运行aspx。进而导致权限提升。