有可能突破虚拟机并在主机上执行,这通常是特定于版本和软件的,因此这是实际攻击的范围,但我相信你会猜到它的可能性非常低,但不容忽视。
如果您非常偏执并且想要最安全的,那么没有软件可以为您提供完全隔离。使用无法访问任何能够向任何远程设备输出任何信号的设备的物理计算机。
如果无法使用物理机,那么是的,VM 是最好的解决方案。只需确保您限制执行实际 VM 的用户没有实际需要的更多权限(DACL 等),以最大限度地降低在 VM 外部执行的恶意软件的安全风险。
编辑:
对不起,我误读了 OP 的要求。如果有人在做相反的事情,我会留下上面的答案。
话虽如此,当然可以闯入VM。我使用 Visual Studio,它是一个编程 IDE,并且有一个 VMWare 插件,您可以将您的软件调试到运行由 VMWare 创建的 VM 中。因此,如果 VMWare 插件可以看到所有正在运行的 VM,那么它们一定是使用 IPC 到 VMWare 本身的某些导出。
即使 VM 供应商没有内置功能,如果恶意软件可以执行 OpenProcess(或 NtOpenProcess 等较低 API)、ReadProcessMemory (NtReadVirtualMemory)、WriteProcessMemory (NtWriteVirtualMemory):
http://msdn.microsoft.com/en-us/library/windows/desktop/ms684320%28v=vs.85%29.aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/ms681674(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/ms680553%28v=vs.85%29.aspx
好吧,这个列表可以继续讨论其他形式的代码注入。从主机变成来宾必须更容易,因为您可以直接访问内存。
为了保护您的软件,您需要在另一个用户下执行它,并拒绝所有其他使用 DACL 的用户执行以下操作:
- PROCESS_VM_OPERATION
- PROCESS_VM_READ
- PROCESS_VM_WRITE
- WRITE_DAC
- WRITE_OWNER
- PROCESS_DUP_HANDLE
http://msdn.microsoft.com/en-us/library/windows/desktop/ms684880%28v=vs.85%29.aspx
最后确保使用监控 IPC 以及虚拟和物理内存的 AV。
@Comment 是的,除非您以个人为目标,否则风险真的很小。如果攻击者可以破坏主机,那么您的虚拟机很容易受到威胁,除非您已执行上述任务以减少攻击的规模。但是,如果恶意软件设法进入内核,那么无论您采用何种安全措施,游戏都结束了。主机上的恶意软件访问来宾机器是一个完全不同的领域。
为了更好地解释这一点,我将制作这个场景:
- 您的 VM 软件是 Oracle VirtualBox
- 您的主机是感染了 x 恶意软件的 Windows 操作系统。
- 您的客户机与当前无病毒的任何远程连接等隔离(这就是它与主机攻击规模不同的原因)
利用软件的内置组件(简单方法):
- 在不了解 Windows 内部原理的情况下解释这一点的最简单方法是有一个名为 VBoxManage.exe 的可执行文件,它能够管理 VM 的硬件和整个 VM 本身。因此,恶意软件只是调用将恶意命令传递给 VBoxManage.exe 以将恶意软件复制并执行到客户机上。不过,请注意恶意软件需要管理员权限。如果您让我知道您正在使用虚拟机,那么我可以为您提供更准确的攻击范围。VMWare 具有与 Oracle VirtualBox 几乎相同的功能,而无需深入了解所有核心。我有一段时间没有使用 VirtualBox,所以情况可能略有不同,但您可以使用名为 VBoxManage.exe guestcontrol 的命令。
内存黑客
- 让我们为论证起见,说没有命令行可执行文件来管理 VM 和/或 SDK 以了解如何与 VM 通信。如果恶意软件进程可以使用带有 PROCESS_VM_OPERATION、PROCESS_VM_READ 和 PROCESS_VM_WRITE 的 OpenProcess API,则恶意软件可以执行多种不同的方式来从您的 VM 进程中注入代码或读取数据。这可能是一项非常具有挑战性或简单的任务,但如果不亲自尝试就很难说,尽管我确信一开始就需要管理员权限。
我不知道您是否要我详细介绍流程安全和对软件进行逆向工程?或者你只是坚持上面关于如何减少关于进程权限和用户权限的攻击范围。