如何对IIS中托管的此服务执行路径遍历攻击？

Question

背景

我试图对IIS中托管的易受攻击的服务执行路径遍历攻击。

这项服务是这样的：

GET /api/download/{file-name}

底层代码如下所示：

return File.Read("some/directory/" + fileName);

如前所述，此服务显然易受攻击。

红隼攻击

使用dotnet run在本地运行时，我可以执行路径遍历攻击，据我所知，该攻击使用的是Kestrel服务器。我的攻击负载是..\..\secret.txt，它被编码并在日志中可见：

Request starting HTTP/1.1 GET http://localhost/api/download/..%5C..%5Csecret.txt

IIS攻击

在IIS中托管时，我无法在同一应用程序上复制此攻击。似乎IIS以某种方式通过解释..\来规范URI，这意味着它永远不会访问我的API。换句话说，它试图到达以下端点：

GET http://localhost/secret.txt

我为..\字符序列尝试了各种不同的编码，但没有成功。

问题

如何绕过此IIS行为对此易受攻击的应用程序执行路径遍历攻击，该应用程序托管在IIS中？

Answer 1

似乎有几件事可以阻止我的路径遍历攻击。我能够执行路径遍历攻击：(1)对有效载荷进行双重编码；(2)删除或破坏IIS中的RequestFilteringModule和UrlRoutingModule模块。如果这些模块中的任何一个都存在并完全启用，我就无法复制攻击。

编码

首先，我必须在我的攻击负载中编码\字符。

当我只对URL进行一次编码时，IIS (我假设)会使URI正常化，正如我前面所观察到的：

浏览器中观察到的http://localhost/api/download/..%5C..%5Csecret.txt

• URI

• 请求:服务器上的IIS日志中的：http://localhost/secret.txt

当我执行两次编码时，我的有效载荷确实通过IIS：

浏览器中观察到的http://localhost/api/download/..%255c..%255csecret.txt

• URI

• 请求:服务器上的IIS日志中的：http://localhost/api/download/..%5C..%5Csecret.txt

RequestFilteringModule

RequestFilteringModule模块以404响应响应我的攻击：

请求过滤模块被配置为拒绝包含双重转义序列的请求。

我们可以通过删除模块或在allowDoubleEscaping或IIS中设置web.config标志来禁用此功能：

<system.webServer>
  <security>
    <requestFiltering allowDoubleEscaping="true" />
  </security>
</system.webServer>

UrlRoutingModule

UrlRoutingModule模块对我的攻击做出了400响应：

从客户端(%)检测到潜在危险的

值。

我们可以通过删除模块或修改requestPathInvalidCharacters设置来禁用此功能。

<system.web>
  <httpRuntime requestPathInvalidCharacters="" />
</system.web>

结论

所涉代码显然易受攻击，应予以修正。也就是说，在IIS中使用RequestFilteringModule或UrlRoutingModule模块似乎有效地防止了我的路径遍历攻击，前提是该模块完全启用。

Answer 2

这在IIS内核级别被阻止。

以下是相关的文本：

不安全：

由于多种原因，字符可能是不安全的。空间字符是不安全的，因为重要的空格可能会消失，当URL被转录或排版或接受文字处理程序处理时，可能会引入不重要的空间。字符"<“和">”是不安全的，因为它们被用作自由文本中URL周围的分隔符；在某些系统中，引号(“”)用于分隔URL。字符"#“是不安全的，应该始终对其进行编码，因为它在万维网和其他系统中用于分隔可能后面的片段/锚标识符的URL。字符"%“不安全，因为它用于对其他字符进行编码。其他字符是不安全的，因为网关和其他传输代理有时会修改这些字符。这些字符是"{“、"}”、“x”、"\“、"^”、"~“、"”、"“和"`”。

所有不安全字符必须始终在URL中编码。例如，字符"#“必须在URL中编码，即使在通常不处理片段或锚标识符的系统中也是如此，因此，如果URL被复制到使用它们的另一个系统中，则无需更改URL编码。

因此IIS在核心级别主动阻止了这一点，这是一种主动的安全措施，可以最大限度地减少它们的攻击面。

在这个link中也有一个类似的问题。