大家好，这里是安势信息。

随着DevOps在软件开发领域被大家接受和认同的程度越来越高，软件开发也越来越依赖于开源组件的使用。然而，开源组件并不是完美的，尤其是对于那些多版本，或没有对应团队专门维护的开源组件来说，其中的漏洞会对开源组件的使用方造成不可挽回的损失。

本文将基于Sonatype最新出具的【亚洲地区易受攻击的五大开源组件如何降低风险】白皮书，为大家带来这五大亚洲使用量遥遥领先并且脆弱性较高的五大组件的相关分析。

这些数据来源于Sonatype官方，且都基于使用Sonatype进行的扫描次数，这也是Sonatype将其列为亚洲地区易受攻击的五大组件的原因，其中：

• 有两个组件被扫描的次数都超过1000万次

• 其余三个组件被扫描次数皆超过了600万次

• 这5个组件已知的就有350个易遭到攻击的版本

同时本文也会列出基于CVSS系统下评级超过6分的组件版本。

第五名

Bouncycastle

BouncyCastle是一个提供了很多哈希算法和加密算法的第三方库。尤其是当我们所需要的算法无法在Java标准库里找到时（例如RipeMD160哈希算法），在这种情况下开发人员自己重新写一个的难度较大，所以很多开发人员选择使用现成的第三方库，这也是Bouncycastle使用如此普及的一个原因。

漏洞名称：CVE-2018-5382

漏洞类型：信息暴露

组件名称：org.bouncycastle:bcprov-jdk15on

受影响版本：

• org.bouncycastle:bcprov-jdk14:(,1.47)

• org.bouncycastle:bcprov-jdk15on:(,1.47)

• org.bouncycastle:bcprov-jdk16:(,)

危害程度：9.8

CVSS3.0Metrics:

CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

漏洞描述

由于加密强度不足,【bouncycastle】组件有信息暴露的风险。【JDKKeyStore.class】文件中的【engineLoad()】函数使用了不安全的BKS版本1（16位HMAC散列），该漏洞能被攻击者暴力破解并且取得敏感值，从而危害到安全性或者执行定时攻击。

攻击机制

定时和边信道攻击的工作原理是攻击者能够通过暴力破解多个值来推断出正确的加密值。只需要观察处理器从正确答案中验证错误答案并返回的所需的时间。随着时间的推移,就可以推断出加密值或者在攻击者有了足够的数据以后也可以推断出来。

修复建议

用了【org.Bouncycastle:bcprov-jdk14】和【org.Bouncycastle:bcprov-jdk15on】组件的用户建议升级到1.47版本。然而，对于【org.】组件的固定版本。在撰写本文时MavenCentral中还不存在【bouncycastle:bcprov-jdk16】组件。

第四名

Lodash

Lodash 是一个 JavaScript 工具库，提供了一系列实用的工具函数，用于简化 JavaScript 的开发。Lodash 旨在提高开发效率，减少代码量，提高代码可读性和可维护性。Lodash 的功能涵盖了 JavaScript 常见的操作，包括数组处理、对象处理、函数处理、字符串处理、日期处理等方面。其中，一些特别实用的函数如 map、reduce、filter、clone 等都得到了优化和扩展，可以快速地完成常见的任务。

漏洞名称：CVE-2018-16487

(因为对CVE-2018-3721进行的修复并不完整)

漏洞类型：DoS，远程代码执行

组件名称：lodash(现存在于npm)

受影响版本：4.17.5 , 4.17.11

危害程度：9.8

CVSS3.0Metrics:

CVSS:3.0/AV:N/AC:L/PR:N/ UI:N/S:U/C:H/I:H/A:H

备注：Sonatype安全研究团队发现,   由于对CVE-2018-3721进行了不完整的修复,  导致该漏洞的根本原因在4.17 .5版本中被引入。因此,  与公告所述相反,  CVE-2018-16487仅涉及4.17.5至4.17.11(独家)版本。4.17.5之前的易受攻击版本仍然被CVE-2018-3721覆盖。

漏洞描述

【lodash】组件容易受到原型链污染的攻击。【lodash.js 】文件中的【safeGet()】函数无法限制对象原型属性的添加或修改。远程攻击者可以通过向接受JSON数据的端点提交包含恶意JSON的请求来利用此漏洞。攻击者可以利用此漏洞修改对象原型属性, 根据应用程序中对象的行为, 可能导致DoS或潜在的远程代码执行(RCE)。

攻击机制

作为一种原型语言,  JavaScript具有与所有对象固有关联的  "prototype__" 属性和所有函数固有的 "prototype" 属性。简单地说,  它是语言提供的一种功能，用于轻松地向现有对象构造函数添加更多属性和方法。像这样的JavaScript原型攻击利用了这个"设计缺陷", 将不兼容的类型注入到现有对象中, 从而导致造成拒绝服务(DoS)的异常。通常, 发生这种情况是JavaScript引擎在解析不安全的递归"合并" 时，没有达到终止条件。

典型攻击示例：

通过调用lodash 的 "merge" 、"mergeWith"  或"defaultsDeep" 函数来处理用户提供的JSON数据,攻击者可能在应用程序中引起异常, 从而导致拒绝服务(DoS)。攻击者可以创建一个形式为{constructor: {prototype:{ … }}}并将其传递给_.merge。

例如：

var _ = require(‘lodash’);

var payload = JSON.parse(‘{“constructor”:

{“prototype”: {“isAdmin”: true}}}’);

_.merge({}, payload);

console.log({}.isAdmin); // true

这样的代码就将导致崩溃, 导致拒绝服务(DoS)攻击和其他意想不到的后果,  例如有人可以远程执行代码。值得注意的是(根据HackerOne报告中的开发人员), 对象、数组、函数、数字、字符串和布尔值中的原型也很容易受到攻击。仅仅因为一个属性是固定的,并不意味着其他属性不容易受到攻击。建议用户多多关注针对这种攻击向量的修复建议。

修复建议

建议相关用户升级到 " lodash" 4.17.11版本 ，其中包含了修复程序。

第三名

Spring Web Services

Spring Web是Spring框架中提供Web控制层功能,能够替代传统的Servlet功能,进行接收请求,处理数据,响应参数的处理，它与spring无需通过中间层进行整合,就能够进行配置直接使用。

漏洞名称：CVE-2019-3773

漏洞类型：XXE

危害程度：8.8

CVSS3.0METRICS:

CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

受影响版本：

org.springframework.ws:spring-ws-core-tiger

所有版本都受影响。

org.springframework.ws:spring-xml

3.x: 3.0.5.之前发布的版本都受影响

1.x and 2.x: 所有2.4.4.之前发布的版本都受影响

org.springframework.ws:spring-ws-core

3.x:  3.0.5.之前发布的版本都受影响

1.x and 2.x: 所有2.4.4.之前发布的版本都受影响

漏洞描述

Spring Web服务 "Spring -ws-core" 和 "Spring - XML" 包容易受到XML外部实体(XXE)攻击。整个组件中的多个文件无法有效限制恶意XML外部实体的攻击动作。远程攻击者可以通过制作和提交包含恶意外部实体引用的XML数据来利用此漏洞从而对服务器执行各种与XXE相关的攻击。

攻击机制

XXE攻击之所以有效, 是因为在应用程序预期的合法XML输入中, 攻击者设法将外部DTD链接注 入标签。应用程序解析标记时,  会根据应用程序中使用的上下文, 引发各种安全问题。XXE攻击一直是SSRF、代码注入或DoS等安全漏洞的载体。

典型攻击事例：

攻击者提供的XML输入，对于普通用户来说，它看起来像软件程序所期望的真实有效的XML文件。但是，请注意攻击者偷偷加入的" , 它将会指示XML解析器加载/etc/passwd"这种敏感的Unix系统文件。根据程序的上下文和注入被篡改XML的命令类型,  一个毫无戒心的用户最终可能会向攻击者透露很多信息,  攻击者现在可能会利用这些信息来实行进一步的安全攻击。【DocumentBuilderFactory】,【XMLInputFactory】和其他【*Factory】类型存在于Spring框架的易受攻击版本中, 以前没有限制输入中存在的外部XML实体的加载。这将使攻击者有可能进行XXE攻击。已经修复的版本(通常以  "Utils.class"结尾 )默认禁用外部XXE实体的加载。

修复建议

Sonatype建议把【org.spring-framework.ws:spring-ws-core】 升级到3.0.5或更高版本的, 这些版本已经修复了此漏洞。对于1.X或2.X这些无法升级到3.05的用户,  可以升级到固定的2.4.4版本。

第二名

Apache Tomcat

Apache Tomcat 包含了一个配置管理工具，也可以通过编辑 XML 格式的配置文件来进行配置。Apache，nginx，tomcat并称为网页服务三剑客，可见其应用度之广泛，但是它也极易受到攻击。

漏洞名称：CVE-2019-0232

漏洞类型：远程代码执行

受影响版本：

org.apache.tomcat:tomcat-catalina: [9.0.0.M1, 9.0.19)

org.apache.tomcat:tomcat-catalina:[8.0.0-RC1,8.5.40)

org.apache.tomcat : tomcat-catalina : [7.0.0, 7.0.94)

org.apache.tomcat.embed:tomcat-embed-core:[9.0.0.M1, 9.0.19)

org.apache.tomcat.embed:tomcat-embed-core: [8.0.0-RC1, 8.5.40)

org.apache.tomcat.embed:tomcat-embed-core: [7.0.0, 7.0.94) 

漏洞描述

CVE-2019-0232源于某些版本中错误配置的默认选项，以及缺乏适当的输入处理，这可能导致攻击者直接接管Windows系统。该漏洞使攻击者能够在Tomcat CGI Servlet某些易受攻击的组件运行时在Windows环境下执行任意的系统命令。必须注意的是，即使在Tomcat 9.0.X的版本中默认禁用了【enablecmdlineararguments】选项。但在配置时如果疏忽将导致此设置更改从而打开此漏洞。更重要的是，没有【enablecmdlineararguments】选项的旧版本仍然容易受到攻击，升级到固定版本是唯一的补救措施。

攻击机制

下面为大家用代码再现一个典型的攻击示例（简化版），在该段代码中对于该漏洞的介绍表面【command】变量并没有被清理：

修复建议

显然，要防止使用此特定向量的远程代码执行攻击的方法是升级到适当的版本, 并且在开发过程中遵守一定的规范从而避免因为更改了配置而无意中启用命令行参数。对于7.0.X的建议是升级到7.0.93, 但该建议似乎是一个格式错误, 因为7.0.93不是一个固定的版本。7.0.94版本已经发布, 其中已经对漏洞进行了修复。该版本包含【regex】模式匹配，以防止在Windows系统中输入命令执行。

“

第一名

Jackson-Databind

jackson-databind是一个Java库，用于将Java对象序列化为JASON格式，并将JASON格式的数据反序列为Java对象。它提供了一组API，可以轻松地将Java对象转换为JASON格式的数据，这个库非常的流行，广泛应用于Java开发中的数据交换喝数据存储。

漏洞名称：Sonatype-2017-0312

关联CVE：

CVE-2017-7525,CVE-2017-15095,

CVE-2017-17485,CVE-2018-5968,

CVE-2018-7489,CVE-2018-11307,

CVE-2018-12022,CVE-2018-12023,

CVE-2018-14718,CVE-2018-14719,

CVE-2018-14720,CVE-2018-14721,

CVE-2019-12086,CVE-2019-12384,

CVE-2019-12814,CVE-2019-14379,

CVE-2019-14439, CVE-2019-14540, 

sonatype-2019-0371, CVE-2019-16335.

漏洞类型:RCE反序列化

组件名称:com.fasterxml.jackson.core:jackson-databind

影响版本：( , 2.10.0)

危害程度：8.5

CVSS3.0Metrics:

CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H

漏洞描述

如果你认真查看了该组件会发现，针对该组件的攻击向量存在于那些未正确验证的对象反序列化而产生的不可信数据中,这些对象被作为输入提供给应用程序。如果攻击者能够影响序列化的对象数据并将恶意代码或逻辑注入其中, 则该代码可能会在反序列化时对应用程序环境造成严重破坏，具体表现为看似良性的崩溃到远程代码执行再到对整个系统造成危害。

修复建议

我们建议:

将【com.fasterxml.jackson.core:jackson-databind】升级到当前Maven Central中2.10.0以上的版本，同时将【enableDefaultTyping()】的所有用法更改为【activateDefaultTyping()】从而规避此漏洞。

总结

DevOps本身具有一定的自动化优势，其持续部署及发布的能力能让漏洞出现或发布后，较快的避免这些漏洞被黑客等恶意攻击者所利用，而在这一环节里，相关的自动化工具显得尤为重要，尤其是在面对庞大的代码量时，我们要采取一系列的手段来加强对代码的掌握，例如生成SBOM等，或者对自身代码定期开展扫描以确保那些有可能对企业造成不可逆伤害的漏洞（诸如前段时间闻名的log4j）能够及时被检测到，从而做出对应的反制手段。

本文为大家简单介绍了亚洲地区最易受攻击的五大开源组件，然而就不完全数据显示，很多大型企业的代码中开源代码占据了超过了50%的比例，相信这远远不止五个组件。如果再将视角放回软件供应链中会发现，开源组件更是一尊“庞然大物”，这从一些大型开源社区例如Github上的惊人下载量就可以见一般。所以在笔者看来，现代软件开发需要开源软件的同时，也需要对开源软件的风险进行把控，作为工具的使用者，开发人员的风险意识远比脆弱的开源组件有更大的风险。所以关注软件供应链安全，可以说是每一位开发者的必修课。