本文讲了常见沙箱绕过技术,沙箱技术与容器。

常见沙箱绕过技术

延迟执行

有许多恶意软件都使用基于时间的绕过技术，主要是利用已知的Windows API来延迟恶意代码的执行，常用的API有NtDelayExecution, CreateWaitTableTImer, SetTimer。这些技术在沙箱识别出来之前非常流行。

GetTickCount

沙箱可以识别出恶意软件并通过加速代码执行的方式来进行应对，可以使用多种方法来进行加速检查。其中一种方法就是使用Windows API GetTickCount和一行检查使用时间的代码。研究人员发现多种恶意软件家族使用的方法的变种。

沙箱厂商可以通过创建超过20分钟的简介使机器多次运行来轻易绕过反逃逸技术。

API洪泛

另一种更加流行的方法是在循环中调用垃圾API来引入延迟，即所谓的API flooding。

Inline Code

因为沙箱无法很好地处理行内代码，因此会产生DOS条件。另一方面，许多沙箱无法检测此类行为。

现在的沙箱能力更加多样化，并有代码插入和全模拟的能力，可以识别和报告暂停代码（stalling code）。因此，有了一个可以绕过大多数高级沙箱的方法。

下面是恶意软件在过去纪念使用的基于时间的绕过技术增长图：

硬件检测

恶意软件广泛使用的另一类绕过技术就是对硬件进行指纹操作，尤其是对物理内存的大小、可用HD大小/类型和可用CPU核数进行检查。

这些方法在Win32/Phorpiex, Win32/Comrerop, Win32/Simda和相关的恶意软件家族中非常流行。研究人员对这些变种进行追踪分析发现，Windows API DeviceIoControl()和一些控制代码被用来提取存储类型和大小的信息。

勒索软件和加密货币挖矿恶意软件也用GlobalMemoryStatusEx ()方法来检查可用的物理内存。

内存大小检查

下面的沙箱中实现的API拦截代码示例，可以对返回的存储大小进行操作：

因为现有的调用无法在已有的沙箱中拦截，因此基于Windows Management Instrumentation (WMI)的方法就非常流行。

下面是恶意软件家族检查存储类型和大小的路径图：

CPU检查

温度检查

恶意软件作者还在不断地添加新的方法来绕过沙箱系统。另一个检查就是检查执行的处理器的温度。
示例代码如下：

检查是通过系统中的WMI调用实现的。该调用后，虚拟机系统是永远不会返回结果的，因此可以很容易地确定是都在沙箱中运行。

CPU数

Win32/Dyreza这样主流的恶意软件都使用CPU数作为绕过的方法。许多恶意软件家族最初都使用简单的基于API的方法。之后，大多数恶意软件开始使用WMI和基于PEB访问的方法。

恶意软件中的绕过代码不依赖于API来识别沙箱环境，恶意软件作者也开始更频繁地使用该方法。下面是类似的检查示例:

实际上有很多方法可以获取CPU核心数，访问PEB的方式虽然比较静默，但是可以通过内联程序集代码或使用固有函数的方式来实现。

获取CPU核心数的恶意软件绕过沙箱方法发展图如下

用户交互

另一种恶意软件广泛使用的绕过沙箱的方法就是利用“自动分析系统（沙箱）无法与人类交互”。一般的沙箱都不会模拟用户行为，恶意软件可以加入自动分析系统和其他真实系统的差别的代码来实现。事实上有多款恶意软件已经通过监控windows事件和停止执行来识别沙箱。

下图是使用GetForeGroundWindow来确定调用相同的API是否会修改Windows handle的Win32/Gataka变种。类似技术也出现在 Lockiny勒索软件变种中。下面是另一个Win32/Sazoora 恶意软件的截图，通过检查鼠标的移动来识别沙箱，也有很多恶意软件通过这种方法来识别沙箱。

恶意软件还会部署大量的技术来检查与受感染系统的历史交互信息。比如，Dridex恶意软件就使用Auto Execution宏，该宏只有在文件关闭时才触发。下面是VB代码的示例：

还有恶意软件攻击活动在MRU文件中引入注册表键值检查来验证有受感染机器的历史交互。该方法中的验证也做了类似的检查。
使用注册表key来检查MRU：\HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Word\User MRU

以上检查的代码版本：

环境检查

恶意软件还会对目标环境进行指纹处理，这样就可以利用沙箱的错误配置。开始的时候，使用Red Pill 技术就可以检测虚拟环境，直到沙箱开始加固架构。恶意软件作者开始使用新的技术，比如检查主机名或注册表来验证安装的程序。

Locky和Dridex恶意软件使用检测网络的方法：

结论

传统沙箱通过运行虚拟化解决方案来构建沙箱环境，比如VMware, VirtualBox, KVM, Xen。这给了恶意软件很多的漏洞来绕过沙箱。恶意软件作者不断加入新的技术和方法来绕过传统的安全解决方案以更好地检测沙箱。

随着 IT 技术的发展，AI、区块链和大数据等技术提升了对应用毫秒级扩展的需求，开发人员也面临着的功能快速推出的压力。混合云是新常态，数字化转型是保持竞争力的必要条件，虚拟化成为这些挑战的基本技术。

在虚拟化的世界，有两个词耳熟能详：虚拟机和容器。前者是对硬件的虚拟化，后者则更像是操作系统的虚拟化。两者都提供了沙箱的能力：虚拟机通过硬件级抽象提供，而容器则使用公共内核提供进程级的隔离。有很多人将容器看成是“轻量化的虚拟机”，通常情况下我们认为容器是安全的，那到底是不是跟我们想象的一样？

容器：轻量化的虚拟机？

容器是打包、共享和部署应用的现代化方式，帮助企业实现快速、标准、灵活地完成服务交互。容器化是建立在 Linux 的命名空间（namespace）和控制组（cgroup） 的设计之上。

命名空间创建一个几乎隔离的用户空间，并为应用提供专用的系统资源，如文件系统、网络堆栈、进程ID和用户ID。随着用户命名空间的引入，内核版本 3.8 提供了对容器功能的支持：Mount（mnt）、进程 ID（pid）、Network（net）、进程间通信（ipc）、UTS、用户 ID（user）6 个命名空间（如今已达 8 个，后续加入了 cgroup 和 time 命名空间）。

cgroup 则实施对应用的资源限制、优先级、记账和控制。cgroup可以控制 CPU、内存、设备和网络等资源。

同时使用 namespace 和 cgroup 使得我们可以在一台主机上安全地运行多个应用，并且每个应用都位于隔离的环境中。

虚拟机提供更强大的隔离

虽然容器很棒，足够轻量级。但通过上面的描述，同一个主机上的多个容器其实是共享同一个操作系统内核，只是做到了操作系统级的虚拟化。虽然命名空间提供了高度的隔离，但仍然有容器可以访问的资源，这些资源并没有提供命名空间。这些资源是主机上所有容器共有的，比如内核 Keyring、/proc、系统时间、内核模块、硬件。

我们都知道没有 100% 安全的软件，容器化的应用也一样，从应用源码到依赖库到容器 base 镜像，甚至容器引擎本身都可能存在安全漏洞。发生容器逃逸的风险远高于虚拟机，黑客可以利用这些逃逸漏洞，操作容器的外部资源也就是宿主机上的资源。除了漏洞，有时使用的不当也会带来安全风险，比如为容器分配了过高的权限（CAP_SYS_ADMIN 功能、特权权限），都可能导致容器逃逸。

而虚拟机依靠硬件级的虚拟化，实现的硬件隔离比命名空间隔离提供了更强大的安全边界。与容器相比，虚拟机提供了更高程度的隔离，只因其有自己的内核。

由此可见，容器并不是真正的“沙盒”，也并不是轻量化的虚拟机。有没有可能为容器增加一个更安全的边界，尽可能的与主机操作系统隔离，做到类似虚拟机的强隔离，使其成为真正的“沙盒”？

沙盒化容器

答案是有，就是沙盒容器。这种容器就像虚拟机一样有自己的内核，这层内核成为用户空间内核。这层内核要保持容器的轻量级，使用现代编程技术编写，本身非常轻，仅用于作为容器和主机之间的强隔离层。

并且还要支持 OCI 和 CRI 规范，可以与 Docker 和 Kubernetes 等容器工具很好的集成。

这里简单介绍下 gVisor 和 Kata Containers。

gVisor

gVisor

[1]

是使用 Go 编写的应用内核，实现了 Linux 操作系统的大部分接口。其包含了一个叫做runsc的 OCI 运行时，提供了应用和宿主机内核间的隔离层。runsc也实现了与 Docker 和 Kubernetes 的集成，可以很容易的运行沙盒容器。

gVisor 为每个容器提供了独立的操作系统内核。应用与 gVisor 内核提供的虚拟环境进行交互，不是直接访问宿主机的内核。gVisor 还限制和管理文件和网络操作，确保容器化应用和主机操作系统之间有两个隔离层。通过减少和限制应用与主机内核的交互，尽可能减小攻击者绕过容器隔离机制的攻击面。

与大部分内核不同，gVisor 不需要固定的物理资源；相反，其利用现有的主机内核功能，并作为一个正常进程运行。换句话说，gVisor 以 Linux 的方式实现了 Linux。

gVisor 沙盒由多个进程组成，这些进程共同构成了可以运行一个或多个容器的环境。

每个沙盒都有其独立的实例：

•Sentry：运行容器的内核，拦截并响应应用的系统调用。

沙盒中的每个容器都有其独立的实例：

•Gofer：提供容器文件系统的访问。

Kata Containers

Kata Containers

[2]

与容器一样轻量级且快，并与容器管理层集成-- 包括 Docker 和 Kubernetes 等流行的容器编排工具 -- 同时还提供了与虚拟机一样的安全。

Kata Containers 与 OCI、容器运行时接口（CRI）和容器网络接口（CNI）完全集成。它支持各种类型的网络模型（例如，passthrough、MacVTap、桥接、tc 镜像）和可配置的访客内核，以便需要特殊网络模型或内核版本的应用都可以在上面运行。上图显示了 Kata VM 中的容器如何与现有编排平台交互。

Kata 在主机上有一个 kata 运行时来启动和配置新容器。对于 Kata VM 中的每个容器，主机上都有一个相应的 Kata Shim。Kata Shim 接收来自客户端（例如 docker 或 kubectl）的 API 请求，并通过 VSock 将请求转发给 Kata VM 内的代理。Kata 容器进一步进行了几项优化，以减少 VM 启动时间。

Kata Containers 由两个开源项目合并而来：Intel 的 Clear containers 和 Hyper runV。前者注重性能（引导时间小于 100ms）和安全；而后者通过支持不同的 CPU 架构和管理系统，将技术无关放在首位。Kata Containers 可以说集二者之大成。

与传统的容器相比，Kata Container 做到了虚拟机的隔离，集虚拟机的安全性和容器的性能于一身。

总结

与普通容器相比，沙盒容器提供了更强的隔离性，这种强隔离提供了更高的安全性。同时这类容器技术支持 OCI 和 CRI 规范，可以与现有的容器工具以及 Kubernetes 很好的集成。

上文就是小编为大家整理的常见沙箱绕过技术,沙箱技术与容器。

国内(北京、上海、广州、深圳、成都、重庆、杭州、西安、武汉、苏州、郑州、南京、天津、长沙、东莞、宁波、佛山、合肥、青岛)Finclip软件分析、比较及推荐。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。