AMF和跨站点脚本漏洞混淆

Posted 2021-05-06

我刚刚代表SFDC对Deloitte的安全审计工作进行了抨击。基本上我们使用flex并通过AMF进行​​通信。我们使用FluorineFX（而不是LCDS和Blaze）。我们被告知，因为AMF响应没有编码，有人可以操纵AMF参数并插入javascript，这是一个XSS漏洞。我正在努力理解AMF响应如何回复，这可以回应在错误消息中传递的JS，可以由浏览器或其他任何事情执行。我对使用html和JS的XSS非常有经验，但看到它被AMF标记有点意外。我与FluorineFx团队保持联系，他们也很困惑。

我很惊讶地看到AMF库对响应数据进行编码，Fluorine肯定没有。看起来像PortSwigger和IBM AppScan这样的安全应用程序在他们的工具箱中包含了这种类型的测试。您是否使用AMF遇到此漏洞并且能解释XSS问题如何表现出来？只是好奇。如果存在争论或者修补漏洞，我需要争论我的方法。考虑到使用Flex的AMF，我认为您可能有一些见解。

附加信息 ...

所以来自实际供应商PortSwigger的更多信息。我向他们提出了问题，网，网，他们承认这种类型的攻击非常复杂。最初他们将此归类为高严重性安全问题，但我认为他们的调整现在正在发生变化。我以为我会发布他们回复的内容，因为我觉得这个观点很有意思。

---来自PortSwigger的问题---

谢谢你的留言。我认为答案是这可能是一个漏洞，但开发并非易事。

你是对的，当AMF客户端使用响应时（除非它做了一些愚蠢的事情），问题不会出现，而是攻击者可以设计出浏览器使用响应的情况。大多数浏览器都会忽略HTTP Content-Type标头，并会查看实际的响应内容，如果它看起来像HTML一样会很乐意处理它。从历史上看，人们已经存在大量攻击，其中人们将HTML / JS内容嵌入到其他响应格式（XML，图像，其他应用程序内容）中，这是由浏览器执行的。

所以问题不在于响应的格式，而在于生成它所需的请求格式。攻击者设计包含有效AMF消息的跨域请求并非易事。 XML请求/响应也会出现类似的问题，其中包含类似XSS的行为。当然可以创建一个有效的XML响应，它被浏览器视为HTML，但挑战在于如何在HTTP体内跨域发送原始XML。这不能使用标准HTML表单来完成，因此攻击者需要找到另一种客户端技术或浏览器怪癖来执行此操作。从历史上看，这样的事情在不同的时间都是可能的，直到它们被浏览器/插件供应商修复。我现在还没有意识到任何允许它的东西。

简而言之，这是一种理论上的攻击，它取决于您可以完全忽略的风险配置文件或阻止使用服务器端输入验证，或者通过在服务器上编码输出并在客户端上再次解码。

我认为Burp应该将AMF请求格式标记为缓解此问题，并将影响降级为低 - 我将解决这个问题。

希望有所帮助。

干杯PortSwigger

---更多关于审计的信息---

portSwigger所做的并不一定是二进制有效负载的混乱，他们所做的是混淆了发布到处理程序以指导请求的实际AMF参数。例如，这里是审计的一个片段，它显示了AMF对请求的部分响应......

HTTP/1.1 200 OK
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 2.0.50727
P3P: CP="CAO PSA OUR"
Content-Type: application/x-amf
Vary: Accept-Encoding
Expires: Tue, 06 Apr 2010 18:02:10 GMT
Date: Tue, 06 Apr 2010 18:02:10 GMT
Connection: keep-alive
Content-Length: 2595

......../7/onStatus.......
.SIflex.messaging.messages.ErrorMessage.faultCode.faultString
.faultDetail.rootCause.extendedData.correlationId.clientId.destination
.messageId.timestamp.timeToLive    body.headers.#Server.Processing..kFailed 
to locate the requested type 
com.Analytics.ca.Services.XXX5c2ce<script>alert(1)</script>9ccff0bda62..
....I506E8A27-8CD0-598D-FF6E-D4490E3DA69F.Id95ab281-d83b-4beb-abff-c668b9fd42d5
..fluorine.I04165c8e-f878-447f-a19a-a08cbb7def2a.A.q..@............
.        DSId.Aeb5eeabcbc1d4d3284cbcc7924451711.../8/onRes
...[SNIP]...

注意那里的“alert”脚本......他们所做的是将一些脚本附加JS附加到传递的参数之一，其中包含要调用的方法即'com.Analytics.ca.Services.XXX'。通过这样做，JS返回了一条错误消息，但是有很多事情要发生在JS上以便接近执行。似乎是间接威胁。

- 安全审计员的最新观点 -

我和更大的团队讨论过，我们都认为这是一次有效的攻击。正如PortSwigger在他的第一段中提到的那样，理论上，因为你将内容类型设置为x-amf，并希望它不会在浏览器中呈现，大多数浏览器都会忽略此请求并无论如何呈现它。我认为供应商在很大程度上依赖于内容类型设置的事实;然而，像IE和某些版本的Safari这样的流行浏览器会忽略这一点。

通过利用CSRF或任何其他形式的发起XSS攻击可以轻松触发攻击。

答案

你好像在这里回答了你自己的疑问。

所以你有一个服务器端实现，它接受amf函数调用的参数，并在返回的输出中的某处包含输入数据。

我很欣赏这主要是理论上的攻击，因为它涉及让有效负载由浏览器呈现而不是amf客户端。可能还需要浏览器/插件中的其他漏洞才能启用此方案。也许只要浏览器将输出处理为html / js，通过gateway.php或类似网站的CSRF帖子就会很容易被滥用。

但是，除非您需要调用者能够将尖括号传递到响应中，否则只需html-encode或剥离它们，这种攻击方案就会消失。

这很有意思。通常，人们只会为预期的数据使用者执行输出编码，但有趣的是，浏览器通常可能是一种特殊情况。这真的是一个地狱般的案例，但我总是让人们习惯于消毒和编码他们不受信任的输入。

这在许多方面让我想起了跨协议注入可以用来滥用协议的反射功能的方式，例如smtp，以在浏览器中实现XSS。见http://i8jesus.com/?p=75

另一答案

1. 它不能是JavaScript注入，因为Flash Player会解释JS？如果我们在播放器中拥有本机JS甚至json支持，那么flash社区将会欣喜若狂。动作脚本没有eval函数，更不用说javascript了
2. 让我们假设它们意味着你可以用actionscript注入它。 AMF协议不发送代码，它以原始类型或通用或类型对象的形式发送数据模型。可能发生的最糟糕的事情是他们分析您的模型并添加其他数据。这将是非常难以做到的，因为您无法注入数据，但必须解析所有数据，添加新数据，解析并保留AMF标头。因为AMF在其数据序列化中使用引用，这意味着当您需要重复的对象类型时，您必须看到第一个对象。然后，引用是偏移量，这意味着添加代码的可能性很小，但只是将值更改为现有参数。
3. 远程对象有一个响应处理程序，它检查数据类型并期望将这些数据类型绑定到ui组件或您的代码所做的任何事情。如果这些数据类型错误，您将收到错误。如果AMF响应序列号错误，您将收到错误。如果在amf数据报中没有完美形成任何内容，您将收到错误。
4. 远程对象自动重试。如果“注入”代码需要很长时间，Flex将重新发送一条消息，并使那个花费很长时间的消息无效。

只是我的两分钱。作为一名AMF开发人员，我经常希望通过amf数据报进行调试和测试很容易。不幸的是，你会收到一个错误。

韦德阿诺德

另一答案

我无法解释有人会如何利用这个“漏洞”。

但是，您可以通过HTTPS连接而不是直接HTTP传递数据来解决问题吗？假设您的服务器上安装了SSL证书并启用了HTTPS，这应该是您编译到Flex应用程序中的services-config.xml文件中的一个小改动。

我捏了一个我的Adobe同事希望他能提供更多的见解。

另一答案

我认为这是一个有效的攻击场景。相关的攻击是GIFAR，其中JVM被欺骗以将gif文件视为jar。另外，我认为输出编码不是解决问题的正确方法。

攻击的前提是欺骗浏览器认为AMF响应是HTML或Javascript。这是可能的，因为一个名为MIME Type Detection的功能，它本质上是浏览器说“开发人员可能不知道内容类型，我会玩上帝和（可能不正确）找出MIME类型”。

为了实现这一点，以下需要成立 -

1. 攻击者应该能够使用<script>或<frame>或<a>标记等HTML技术向您的AMF服务器发出GET或POST请求。 XmlHttpRequest或Flash或Silverlight等技术不计算在内。
2. 攻击者应该能够将恶意内容插入到响应的前256个字节中。此外，这个恶意内容应该能够欺骗浏览器，认为其余的响应实际上是javascript或html。

那么，你如何预防呢？

最好确保攻击者无法首先提出请求。一种非常简单有效的方法是在发出AMF请求时添加http请求标头，检查它是否存在于服务器上，如果不存在则拒绝该请求。该值可以是硬编码值，不必是秘密的。这是有效的，因为没有已知的方法通过标准的html技术添加自定义请求标头。你可以通过XmlHttpRequest或flash或silverlight这样做，但是浏览器不会为你解释内容类型，所以没关系。

现在，我对AMF知之甚少，但如果它已经添加了请求标头 - 那么这种攻击方案是不可能的。如果不是，那就添加一个。

转义内容的HTML不是一个好的解决方案。据称，有各种方法可以让浏览器认为响应实际上是HTML。换句话说，恶意输入不需要格式良好的HTML。尝试谷歌搜索mime嗅探，你应该能够找到各种方法来欺骗浏览器。

另一答案

我不知道改变AMF响应流中的数据是多么可能，但您可能希望确保不能通过与浏览器和/或JavaScript的通信来操纵您的端点。在恶意数据注入部分下查看此article。