网安瞭望台第6期 ：XMLRPC npm 库被恶意篡改、API与SDK的区别

国内外要闻

     XMLRPC npm 库被恶意篡改，窃取数据并部署加密货币挖矿程序

    网络安全研究人员发现了一起在 npm 包注册表上活跃了一年多的软件供应链攻击。名为 @0xengine/xmlrpc 的 npm 包最初是一个无害的库，基于 JavaScript，用于 Node.js 的 XML - RPC 服务器和客户端，2023 年 10 月 2 日发布，至今已被下载 1790 次。然而在发布一天后的 1.3.4 版本中被植入恶意代码。

    恶意行为如下：数据窃取，恶意代码每 12 小时收集一次诸如 SSH 密钥、bash 历史记录、系统元数据和环境变量等敏感信息，并通过 Dropbox 和 file.io 等服务将其泄露出去。传播途径，其攻击有多种传播途径，包括直接通过 npm 安装，以及作为隐藏依赖项存在于看似合法的存储库中。例如，GitHub 上一个名为 yawpp 的项目（声称是用于在 WordPress 平台上编程创建帖子的工具），其 “package.json” 文件将 @0xengine/xmlrpc 的最新版本列为依赖项，用户在安装 yawpp 工具时就会自动下载安装这个恶意 npm 包。目前尚不清楚 yawpp 工具的开发者是否故意添加此依赖项。

    该恶意软件一旦安装，就会收集系统信息，通过 systemd 在主机上建立持久性，并部署 XMRig 加密货币挖矿机。目前发现有多达 68 个受感染系统正在通过攻击者的门罗币钱包进行挖矿。

    它还能持续监控运行进程列表，若发现 top、iostat、sar、glances、dstat、nmon、vmstat 和 ps 等命令，就会终止所有与挖矿相关的进程，并且如果检测到用户活动，会暂停挖矿操作。

    与此同时，Datadog Security Labs 发现了一场针对 Windows 用户的恶意活动，涉及上传到 npm 和 Python Package Index（PyPI）存储库的假冒包，目的是部署 Blank - Grabber 和 Skuld Stealer 开源窃取恶意软件。上个月检测到该供应链攻击，将其命名为 MUT - 8694。攻击者上传了 18 个和 39 个假冒的独特包到 npm 和 PyPI，这些库试图通过拼写错误（typosquatting）技术伪装成合法包，且似乎在针对 Roblox 开发者。

网络犯罪分子利用热门游戏引擎Godot

分发跨平台恶意软件

    自2024年6月起，一种名为GodLoader的恶意软件活动正在滥用热门开源游戏引擎Godot Engine，感染了超过17000个系统。

    网络犯罪分子利用Godot Engine执行特制的GDScript代码，这些代码会触发恶意命令并传播恶意软件。而且这种技术在VirusTotal上几乎未被所有杀毒引擎检测到。

    Godot Engine支持多平台开发（包括Windows、macOS、Linux、Android、iOS、PlayStation、Xbox、Nintendo Switch和网页），这一特性使其成为攻击者手中极具吸引力的工具，能够大规模地针对和感染不同设备，拓宽了攻击面。

    该活动利用了“Stargazers Ghost Network”（大约200个GitHub仓库和225个以上虚假账号）来分发GodLoader。这些账号会给分发GodLoader的恶意仓库点赞，使其看起来合法且安全。这些仓库分四波发布，主要针对开发者、游戏玩家和普通用户。

    在2024年9月12日、9月14日、9月29日和10月3日观察到的攻击中，攻击者使用Godot Engine可执行文件（即.pck文件）来植入加载器恶意软件，然后该加载器从Bitbucket仓库下载并执行最终阶段的恶意负载，如RedLine Stealer和XMRig加密货币挖矿机。

    目前，这组攻击涉及攻击者构建自定义的Godot Engine可执行文件来传播恶意软件，但如果攻击者在获取用于提取.pck文件的对称加密密钥后篡改合法的Godot游戏，威胁可能会进一步升级。不过，通过切换到依赖公钥和私钥对来加密/解密数据的非对称密钥算法，可以避免这种攻击。

    这一恶意活动再次提醒我们，威胁行为者经常利用合法服务和品牌来逃避安全机制，因此用户必须只从可信来源下载软件。攻击者利用了Godot的脚本功能来创建未被许多常规安全解决方案检测到的自定义加载器，其跨平台的攻击方式增强了恶意软件的通用性，使威胁行为者能够轻易地针对多个操作系统进行攻击，更有效地在各种设备上传播恶意软件，扩大其影响范围。

ProjectSend关键漏洞在面向公众服务器遭主动利用       

    VulnCheck发现，影响ProjectSend开源文件共享应用程序的一个关键安全漏洞可能已在野外被主动利用。该漏洞早在 2023 年 5 月的一次提交中就已修复，但直到 2024 年 8 月 r1720 版本发布才正式公布。截至 2024 年 11 月 26 日，其 CVE 编号为 CVE - 2024 - 11680，CVSS 评分为 9.8。

    Synacktiv在 2023 年 1 月向项目维护者报告了此漏洞，称其为不当授权检查漏洞，可使攻击者在易受攻击的服务器上执行恶意代码。在 ProjectSend r1605 版本中存在不当授权检查，攻击者可执行诸如启用用户注册和自动验证，或在上传文件允许的扩展名白名单中添加新条目等敏感操作，最终能在托管应用程序的服务器上执行任意 PHP 代码。

    VulnCheck 观察到未知威胁行为者利用 Project Discovery 和 Rapid7 发布的漏洞利用代码，针对面向公众的 ProjectSend 服务器进行攻击，攻击可能始于 2024 年 9 月。这些攻击还启用了用户注册功能以获取身份验证后的权限用于后续利用，表明并非仅局限于扫描易受攻击的实例。VulnCheck 的 Jacob Baines 表示可能已发展到攻击者安装网页 shell 的阶段，且从技术上讲，漏洞还允许攻击者嵌入恶意 JavaScript，这可能是一种不同的有趣攻击场景。若攻击者上传了网页 shell，可在 webroot 下的 upload/files/ 中的可预测位置找到。

    对约 4000 个暴露在互联网上的 ProjectSend 服务器分析显示，仅有 1%使用了已修复的 r1750 版本，其余运行的是未命名版本或 2022 年 10 月发布的 r1605 版本。鉴于似乎广泛存在的利用情况，建议用户尽快应用最新补丁以缓解当前威胁。 

知识分享

HTTP/1 -> HTTP/1.1 -> HTTP/2 -> HTTP/3

    不少少侠提问过HTTP不同版本的差别，这里讲解一下。

1. HTTP/1

    在 HTTP/1 中，客户端和服务器之间的通信基于 TCP/IP 协议。通信开始时，客户端向服务器发送 TCP SYN 请求，服务器回复 TCP SYN + ACK，然后客户端再回复 ACK，建立起 TCP 连接。接着，客户端通过已建立的 TCP 连接发送 HTTP 请求，服务器处理请求后返回 HTTP 响应。每次请求 - 响应都需要建立一个新的 TCP 连接，这种方式效率较低。

2. HTTP/1.1

    HTTP/1.1 引入了持久连接（Persistent Connection）。在这种模式下，客户端和服务器之间的 TCP 连接在一次请求 - 响应后不会立即关闭，而是保持打开状态，以便后续的请求 - 响应可以复用这个连接，减少了建立连接的开销，提高了效率。

3. HTTP/2

    HTTP/2 进一步优化了连接机制，它在一个 TCP 连接上可以同时处理多个数据流（streams）。客户端和服务器之间通过一个 TCP 连接进行通信，每个数据流可以独立地发送请求和接收响应。例如，stream 1 可以发送请求头，stream 2 可以发送数据，stream 3 可以发送其他请求头或数据等，这些数据流可以并发地在同一个 TCP 连接上传输，提高了网络利用率和传输效率。

4. HTTP/3

    HTTP/3 则是基于 QUIC（Quick UDP Internet Connections）协议，使用 UDP 代替 TCP。图中显示客户端和服务器之间通过 UDP 连接进行通信。QUIC 协议在 UDP 之上实现了类似于 TCP 的可靠性和拥塞控制功能，同时还具有更低的延迟和更好的性能。图中的数字 1 - 7 可能表示 QUIC 连接中的不同数据包或数据流，展示了 HTTP/3 在 UDP 上实现高效数据传输的机制。

    从 HTTP/1 到 HTTP/3 的演变过程展示了网络协议在提高性能、降低延迟和优化资源利用方面的不断进步。少侠们一定要注意掌握计算机通信的基础知识，这样才能让自己的网安能力有坚实的底层支撑哦。

网络安全的人体类比：保障数字世界的健康

    少侠们经常在后台提问，如何给安全运营中接触到的安全平台、产品、能力进行定位，这里有一个非常形象的类比图。    

    在网络安全领域，各个组件的协同工作如同人体各器官维持健康一样重要。我们可以通过人体与网络安全的类比来更好地理解这一复杂的系统。

• 首先，安全运营中心（SOC）就像大脑。大脑控制着人体的功能和决策，而 SOC 则掌控着网络安全的运作，做出关键的判断和指挥。

• 安全信息和事件管理系统（SIEM Systems）如同眼睛和耳朵。眼睛和耳朵负责监测周围环境，察觉潜在的危险，SIEM Systems 则时刻监控网络活动，及时发现异常和可能存在的威胁。

• 数据加密好比心脏，心脏保障血液在身体内的安全循环，数据加密则确保信息在传输和存储过程中的安全性。

• 入侵检测系统类似神经系统，神经系统快速传递信号，让身体对危险做出迅速反应，入侵检测系统也是如此，它能对可疑活动及时发出信号，便于快速应对。

• IT 基础设施如同骨骼，骨骼为人体提供结构和支撑，基础设施则为网络安全提供基本的架构和支持。

• 安全策略类似于肝脏，肝脏负责解毒，保障身体的健康，安全策略通过强制实施安全规范来净化网络环境。

• 过滤系统好比肾脏，肾脏过滤血液中的有害物质，过滤系统则防止敏感信息被未经授权的访问。

• 数据流如同血液，血液在人体中运输各种重要物质，数据流则在网络中传递关键信息。

• 防病毒软件如同免疫系统，免疫系统抵御病菌的入侵，防病毒软件则检测并清除网络中的有害感染。

• 防火墙则像皮肤，皮肤是人体抵御外界威胁的第一道防线，防火墙也是阻挡外部网络威胁的首要屏障。

API（应用程序编程接口）VS SDK（软件开发工具包）

    没错，又有少侠问过我们，API和SDK到底有嘛区别，哪个更安全，这里讲一讲：    

    API用于在应用程序和服务之间进行通信。其请求结构包括HTTP方法（如GET、POST、PUT、DELETE）、端点（如https://gmap/json，表示API托管的位置）、查询参数（如 - address=ABC + CA和 - key=APP_API_KEY，用于指定请求条件）、状态码（如200 OK，表示请求成功）以及以json/XML格式返回的数据。其工作流程是客户端向API发送请求，API处理后返回包含数据（例如地图数据）的响应。

    SDK则是用于构建应用程序的工具箱。它由编程语言（如Java、.NET、Kotlin等）和SDK本身组成，SDK提供了帮助开发者集成APIs的工具和库。开发者选择编程语言后，使用SDK进行应用程序的构建，接着发布和交付应用程序，最终应用程序通过Web API与外部数据（如位置数据）交互。

    在网络安全方面，API和SDK存在以下差别：

    API的网络安全特点

    1. 暴露风险：API通常是对外暴露的接口，容易受到外部攻击。例如，如果没有适当的身份验证和授权机制，攻击者可能通过猜测端点和参数来获取敏感数据。

    2. 依赖于安全协议：API的安全性很大程度上依赖于使用的HTTP方法和传输协议（如HTTPS）。如果传输过程中没有加密，数据可能在传输过程中被窃取或篡改。

    3. 输入验证至关重要：由于API接收外部传入的参数，对输入参数的验证必须严格。若缺乏验证，可能会导致SQL注入、命令注入等攻击。    

    SDK的网络安全特点 

    1. 内部使用为主：SDK通常是供内部开发者使用的工具包，相对而言不容易直接受到外部攻击。但如果SDK被嵌入到发布的应用中，其安全性会影响应用的整体安全。

    2. 依赖于编程安全：SDK的安全性与所使用的编程语言的安全性密切相关。例如，某些编程语言如果存在内存管理漏洞，可能会被利用来进行攻击。

    3. 集成安全风险：当SDK集成各种APIs时，可能会引入新的安全风险。如果集成的API存在安全漏洞，可能会通过SDK传播到最终的应用程序中。