解释器将人类可读的软件代码翻译为字节码。由NTT 安全控股公司和东京大学组成的研究团队将在下周举行的美国黑帽大会上展示如何成功在字节码执行前将恶意指令插入内存中的字节码，以及如何利用多数安全软件不会扫描字节码的方式逃避检测。攻击者可利用这一技术将恶意活动隐藏在多数端点安全软件的视野之外。

研究人员已证实称该技术也适用于在 Python 和 Lua 解释器的内存进程中插入恶意代码。

研究人员表示，“恶意软件常常通过将恶意代码注入非恶意进程中的方式隐藏行为，但目前的注入攻击类型具有相关特征，可被安全产品轻松检测到。该解释器并不关心覆写远程进程，因此我们可用恶意代码轻松替换所生成的字节码，而这就是我们所利用的特性。”

字节码攻击并非新事物，不过相对具有创新性。2018年，加利福尼亚大学尔湾分校的研究人员发布了一篇名为《字节码损坏攻击是真实的——以及如何防御》的论文，介绍了字节码攻击及其防御措施。去年，PyPI管理员删除了恶意包 fshec2。由于该包的所有恶意代码是通过字节码编译的，因此逃逸了初始检测。Python 将字节码编译到 PYC 文件，从而被 Python 解释器执行。

ReversingLabs 公司的逆向工程师 Karlo Zanki 在2023年6月分析该事件时提到，“这可能是利用 Python 字节码文件可被直接执行这一事实的首个供应链攻击，而它发生在 PyPI 恶意提交激增的时刻。如果情况属实，未来可能会再施加供应链风险，因为这种攻击类型可能会被多数安全工具错过，它们只会扫描 Python 源代码文件。”

预编译恶意软件之外

初始攻陷后，攻击者可选择多种方式对目标系统的控制进行扩展：他们可执行侦查活动、尝试通过恶意软件进一步攻陷系统或者运行系统上的已有工具，即所谓的‘飞地’策略。

NTT研究人员将要展示的字节码攻击技术属于最后一类。该攻击并未使用预编译的字节码文件，而是将恶意字节码插入正在运行的解释器的内存空间。由于多数安全工具并不会检查内存中的字节码，因此该攻击可躲避恶意命令遭检测。

该方法可导致攻击者跳过其它更加明显的恶意步骤，如调用可疑 API 创建线程、分配可执行内存，以及修改指令指针。研究人员提到，“原生代码具有由 CPU 直接执行的指令集，字节码只是CPU的数据，并由解释器解释和执行。因此，和原生代码不同，字节码并不要求执行权限，而我们的技术并不需要以执行权限准备内存区域。”

更好的解释器防御措施

解释器开发人员、安全工具开发人员以及操作系统架构均可受影响。虽然针对字节码的攻击并不会利用解释器中的漏洞，而是利用它们执行代码的方式。论文提到，可采取一些安全修改如指针校验和的方式缓解该风险。

NTT 安全研究人员提到校验和防御措施对于他们提到的攻击技术并不奏效，并建议开发人员执行写保护措施以消除该风险。研究人员提到，“最终的应对措施是限制内存写入解释器。”展示新攻击技术的目的是向安全研究员和防御人员展示可能发生的情况，而不是知会攻击者的技术。研究人员提到，“我们的目标不是滥用防御技术，而是引起全球安全研究人员的警惕。”

奇安信代码卫士 (codesafe)

国内首个专注于软件开发安全的产品线。

    觉得不错，就点个 “在看” 或 "赞” 吧~