1

我目前正在执行 ASP.NET 应用程序的渗透测试，并试图利用 Padding Oracle Attack。此 AFAIK 是基于响应代码分析，但被测系统的 ScriptResource 和 WebResource axds 始终以 200 OK 响应，即使密码已无效。但是，在这种情况下，响应的内容是一个空字符串。

在这种情况下，是否可以使用任何 axd 作为预言机？也许基于响应内容的差异。

4

3 回答 3

3

Padding Oracle Attack 能够区分两种情况：

  • 服务器未能解密数据，因为在解密时，它没有找到格式正确的填充。
  • 服务器找到了正确的填充，但解密的数据原来是随机垃圾。

攻击者可能有多种方法来获得这种区分。来自服务器的特定错误代码是最容易利用的；但任何可检测的差异就足够了。该攻击于 2002 年首次发布（是的，人们花了 8 年时间才注意到它可以应用于 ASP！）并且已经在 SSL 连接上进行了演示，只有时间差异：服务器正在解密数据，并且然后仅在解密正常时才验证 MAC；MAC 计算所花费的额外 2ms 足以让攻击者知道填充是否有效，从而允许直接应用 Padding Oracle Attack。

于 2011-05-04T19:15:14.513 回答
1

要回答您的原始问题，可以使用内容长度。Padbuster 记录了状态代码，但我认为它完全检测到响应长度。

要回答您对 Troy 的回复，长密文长度并不表示它们容易受到攻击。通常，较短的密文长度确实表明它们易受攻击，但您需要对值进行 dot net url 解码，然后查看模数 8=0 是否易受攻击。换句话说，长度将是 8 的倍数。通常我会看到一个密文块（16 个字节）一旦被点网 url 编码，最终会变成大约 25 个字节。该修复程序包括一个 HMAC（我认为），它扩展了长度并且应该使一个块密文成为不可能。我不能肯定地说，因为我不确定 HMAC 有多长，以及它在填充后是否有效。

于 2012-06-06T12:27:40.703 回答
0

在我看来，可能已经安装了 padding oracle 补丁，因此您没有得到您期望的错误代码。看看您是否信任您的托管服务提供商，他们是否真的安装了 padding oracle 补丁，看看您是否可以建立这一点。

于 2011-04-26T01:51:31.940 回答