远程代码执行 （RCE），解释：它是什么，以及如何防止它

• 原文地址：Remote code execution (RCE), explained: what it is and how to prevent it
• 原文作者：Tsviatko Yovtchev
• 译文出自：掘金翻译计划

原文链接：blog.sqreen.com/remote-code…

远程代码执行 （RCE） 是一类软件安全缺陷/漏洞。RCE 漏洞将允许恶意行为人通过 LAN、WAN 或 Internet 在远程计算机上执行自己选择的任何代码。RCE 属于更广泛的任意代码执行 （ACE） 漏洞类别。然而，随着互联网的普及，RCE漏洞的影响迅速扩大。因此，RCEs 现在可能是 ACE 最重要的漏洞类型。

由于是这样，我们希望更详细地研究各种类型的 RCE 漏洞和可能的对策。

按产地分类的 RCE 分类

大多数（如果不是全部）已知的 RCE 漏洞都有少量的根本原因。

动态代码执行

动态代码执行往往是导致 RCE 的最常见攻击载体。大多数编程语言都有某种方式使用代码生成代码并当场执行代码。这是一个非常强大的概念，有助于解决许多复杂的问题。但是，恶意第三方可以轻松地滥用它来获取 RCE 功能。

通常，运行时生成的代码基于某些用户输入。通常，代码以某种形式包含该输入。恶意行为者意识到动态代码生成将使用给定输入，可以提供有效的代码作为输入来攻击您的应用程序。如果不对用户输入进行审查，则该代码将在目标计算机上执行。

从广义上讲，动态代码执行会导致 RCE 漏洞的两大类：直接和间接。

直接

在直接动态代码执行的情况下，恶意行为人意识到其输入将被用于代码生成。

间接

间接案例，再次归结为动态代码生成，包括用户输入。但是，用户输入会通过一个或多个层。有些图层甚至可能在输入最终产生动态代码之前转换该输入。此外，动态代码生成可能是副作用，而不是输入的主要用法。因此，对于提供输入的用户来说，在远程计算机上执行的代码片段中，输入将用作构建基块并不明显。

反序列化

反序列化 是这种情况的一个很好的例子。在去隔离化上，似乎不应该产生动态代码。当序列化对象仅包含原始类型的数据字段或此类其他对象时，情况实际上就是这样。然而，当对象的方法/功能序列化时，事情变得更加复杂。然后，去航空化通常包括某种形式的动态代码生成。

您可能会认为动态语言是功能序列化唯一有意义的地方。届时问题的范围将有限。但它也是静态语言中的有用场景。用静态语言实现这个目标有点困难，但到目前为止并非不可能。

很多时候，实施由去隔离生成的代理对象/功能组成。在运行时生成对象/功能是动态代码生成的案例。因此，如果要去系统化的数据来自远程计算机的请求，恶意行为者可能会修改它。精心制作的序列化代码片段可以注入，从而在作为去序列化的一部分调用动态代码生成时执行它们。

内存安全

RCE 漏洞的另一个原因与内存安全有关。内存安全意味着阻止代码访问未初始化或作为输入获取的内存部分。直觉上，您可能会期望缺乏内存安全会导致未经授权的数据访问。但是，操作系统和基础硬件使用内存存储实际可执行代码。有关代码执行的元数据也存储在内存中。访问这种内存可能导致 ACE 和可能的 RCE。那么，记忆安全问题背后的主要原因是什么呢？

软件设计缺陷

软件设计缺陷是一种内存安全漏洞，其中某些基础组件存在设计错误。很多时候，这将是一个编译器，口译员，或虚拟机器，或潜在的操作系统内核或库。属于这个类有许多不同的缺陷。我们将更详细地研究什么是最常见的。

缓冲溢出或缓冲过度

缓冲溢出（也称为缓冲过度阅读）是一种相当简单和众所周知的技术，违反记忆安全。它利用设计缺陷或错误编写到记忆缓冲器实际结束后的内存单元。缓冲本身从向公共 API 发出的合法呼叫中返回。但是，缓冲器仅用作计算某些对象或程序计数器的私人字段/成员值的物理内存地址的原点。它们与缓冲器的相对位置是众所周知的，或者可能被猜到。如果可用，研究代码或在运行时调试程序执行可能有助于恶意行为人获得相对位置。

因此，缓冲溢出允许修改设计中无法访问的记忆。该缓冲器可能位于另一台机器的地址空间中，并通过调用远程 API 进行修改。这将允许访问远程机器内存。显然，在仪器 RCE 中使用这种类型的访问方式有很多种。一般假设是，如果存在缓冲溢出漏洞，则可能存在 RCE。因此，代码所有者应尽快修复缓冲溢出，远在实际 RCE 攻击出现之前。

范围

通常，缓冲溢出目标为 C/C++ 代码，因为这些语言没有内置缓冲器大小检查。许多其他流行的框架和技术最终使用 C/C++库在表面深处，自动使他们容易受到这种攻击。

Node.js 是一个很好的例子，因为除了基于C/C++，JavaScript运行时间还允许本地C/C++附加组件。因此，攻击者可以小心地将请求制作到节点.js服务器，以造成缓冲溢出，从而修改受影响计算机上的系统内存，从而执行任意代码。

硬件设计缺陷

有趣的是，由于硬件安全设计缺陷，可能会发生内存安全违规事件。虽然此类漏洞不太常见且更难发现，但通常具有极高的影响。

偏转 RCE 攻击

虽然每次 RCE 攻击的结果在攻击执行代码方面是相同的，但攻击载体的性质却大不相同。阻止所有这些需要付出巨大的努力。此外，努力与技术堆栈一起增长。这篇文章中描述的所有攻击载体都是技术不可知论者。不过，所有实施都是针对技术的，防御机制也是如此。

因此，传统的节省时间的方法是监控网络流量中的可疑内容，而不是用其特定技术监控每个端点。Web 应用程序防火墙 （WAF） 通常执行此工作。虽然这节省了时间，但它也以价格出现—WAF是一个网络性能瓶颈, 它缺乏在实际终点或应用程序和用户级别提供的所有背景信息。因此，WAF 流量分析永远不会完美。如果没有完整的数据，启发式是不可避免的，因此，不是所有的威胁都会出现，或者会出现误报，或者通常两者兼有。

在应用程序内移动：Sqreen 的方法

Sqreen 解决了这些 WAF 缺陷，而无需通过在应用程序内移动可见性来增加最终用户的开发成本，通过技术特定的 RASP 和 In-App WAF. 带来更完整的保护。Sqreen 的 RASP 和 WAF 运行在实际 Web 应用程序、API 或微服务接收网络流量内。不过，它不需要任何代码修改。它使用特定于每个技术的仪表点（例如 JJVM API for Java, v8 API for Node.js 等）在运行时间执行前修改代码。因此，它能够监控和修改系统和网络事件，同时拥有应用程序内发生的一切的完整上下文。

因此，Sqreen 可以检测到该应用正在使用具有已知内存安全问题的组件。它还可以检测实际用户输入，使其进入动态代码执行事件。当然，与仅访问网络流量的传统 WAF 相比，这是检测和防止 RCEs 的优越方法。

总结

显然，RCE 是一种非常强大的攻击载体。但是，幸运的是，也有可能保护自己免受 RCE 攻击。以上信息确实有助于构建您的防御战略。如果您对其他攻击载体和详细信息感兴趣，请查看我们以前关于 SQL 注入, XXE, 和 LFI.