覆盖面太大,Log4j漏洞弥补工作十分艰难
更新时间:2021-12-20
浏览量:898
由于需要持续监测攻击者试图利用漏洞的迹象,或者监测自身可能已经遭到入侵的指标,这项任务会变得更加复杂。

Log4j漏洞所藏身的组件并不总是易于检测,且该组件的使用范围远不止企业自己的网络和系统。

如果想要缓解公司的Log4j漏洞暴露问题,安全团队需要克服很多难题,比如确定暴露的全部范围,找出变通方法堵上无补丁系统的漏洞,以及确保第三方产品和服务有所防护。

安全专家本周表示,对于许多人来说,由于需要持续监测攻击者试图利用漏洞的迹象,或者监测自身可能已经遭到入侵的指标,这项任务会变得更加复杂。

Log4j是一种日志工具,几乎存在于所有Java应用中。从2.0-beta9到2.14.1的多个Log4j版本中存在关键远程代码执行漏洞(CVE-2021-44228),攻击者可利用该漏洞完全控制易受攻击的系统。上周,Apache基金会发布了该工具的更新版本 (Apache Log4j 2.15.0),但由于原始补丁未能完全防止拒绝服务(DoS)攻击和数据盗窃,本周二又发布了第二次更新。

很多人都觉得这个漏洞是近期最危险的漏洞之一,因为实在是太容易被利用了,而且普遍存在于每个IT环境中。举个例子,Veracode就发现其客户中88%都在使用某个版本的Log4j,而58%的客户环境中存在带漏洞的版本。

自上周该漏洞首次披露以来,世界各地的攻击者一直在尝试利用这个漏洞。多家安全供应商观测到攻击者试图利用该漏洞投放加密货币挖矿机、勒索软件、远程访问木马、Web shell和僵尸网络恶意软件。12月15日,Armis报告称,其客户中大约35%正遭受经由该漏洞发起的主动攻击,31%则面临托管设备上的Log4j漏洞相关威胁。这家安全供应商表示,针对其客户的漏洞利用攻击尝试次数高达3万次之多。其他几家供应商也报告了类似的活动。

Armis发现,迄今为止,IT环境中最容易被攻击者盯上的资产是服务器、虚拟机和移动设备。而在OT网络中,49%的被黑设备都是虚拟机,43%是服务器。OT网络中的其他目标设备还有联网摄像头、人机界面(HMI)和数据采集与监视控制(SCADA)系统。

界定问题范围

安全专家表示,在防御针对Log4j漏洞的攻击时,企业面临的一项主要挑战是摸清自身的整个暴露面。该漏洞不仅存在于企业面向互联网的资产中,还广泛存在于内部与后端系统、网络交换机、安全信息与事件管理(SIEM)及其他日志记录系统、内部开发应用与第三方应用、软件即服务(SaaS)和云服务,以及自身甚至可能毫无所觉的环境中。而且,不同应用和组件之间存在相互依赖,这意味着即使组件不直接存在漏洞,也仍然可能受到漏洞影响。

Noname Security表示,Java程序包打包机制通常会增加受影响应用的识别难度。例如,Java存档(JAR)文件可能包含特定组件的所有依赖项,包括Log4j库。但JAR文件还可能包含其他JAR文件(该JAR文件可能又包含另一个JAR文件)。基本上,这个漏洞可能嵌套了很多层。

Netskope威胁研究工程师Gustavo Palazolo表示:“企业在缓解Log4j漏洞时面临的主要挑战之一,是识别所有受损资产。”他补充道,基Log4j Apache Java的日志库非常流行,许多应用,还有物联网设备和为了向后兼容而维护的老旧系统,都在使用此类日志库。

即使发现应用存在漏洞,更新应用也可能很困难,因为企业可能无法承受宕机的代价,或者缺乏合适的补丁管理控制措施。

Palazolo称:“因此,在某些情况下,识别所有受损系统和修复问题之间的耗时可能会很长。”

API和第三方风险

应用还不是唯一的问题。Log4j漏洞也会影响应用编程接口(API)环境。Noname Security表示,包含该漏洞的API服务器提供了诱人的攻击渠道,因为许多企业其实对其API清单和API行为的可见性有限。没使用Log4j日志框架的公司可能在用含有Log4j漏洞的受信第三方API,同样面临Log4j漏洞利用风险。

Noname Security技术副总裁 Aner Morag表示:“对于企业而言,想要最大限度地降低遭遇API型[Log4j漏洞]利用的风险,需要采取几个步骤。”这些步骤包括:映射使用任何Java服务提供API的所有服务器,不允许任何用户输入接触到API服务器上的日志消息,使用代理或其他机制来控制后端服务可以连接到哪些服务器,并将API置于API网关或负载均衡器之后。

企业面临的另一个Log4j漏洞缓解挑战是,要确保他们使用的所有第三方产品和服务都打上了合适的补丁,或者设置了针对该漏洞的缓解措施。

Alert Logic安全运营副总裁Tom Gorup称:“许多供应商产品受到影响,[并且]受影响供应商的数量每天都在增加。不是所有供应商都有补丁可用。”

Gorup建议安全团队检查其供应商的网站,或者直接与供应商联系,好了解他们的产品是否受到影响。供应商可能易受此漏洞影响,但已发布缓解措施来保护其客户。

Gorup指出:“至少,你得清楚怎么验证自己的资产已经接收到更新了。”他还建议安全团队检查过去几天公布出来的易受攻击产品列表,比如GitHub上发布的那个(URL:https://github.com/NCSC-NL/log4shell/tree/main/software)。

Gorup表示:“对此漏洞的回应可能是,‘我们不使用Java’。尽管情况可能真是这样,但你的第三方软件或许早已嵌入了Java,导致你的漏洞扫描压根儿没显示出这一[威胁]。”

由于需要持续监测攻击者试图利用漏洞的迹象,或者监测自身可能已经遭到入侵的指标,这项任务会变得更加复杂。

Log4j漏洞所藏身的组件并不总是易于检测,且该组件的使用范围远不止企业自己的网络和系统。

如果想要缓解公司的Log4j漏洞暴露问题,安全团队需要克服很多难题,比如确定暴露的全部范围,找出变通方法堵上无补丁系统的漏洞,以及确保第三方产品和服务有所防护。

安全专家本周表示,对于许多人来说,由于需要持续监测攻击者试图利用漏洞的迹象,或者监测自身可能已经遭到入侵的指标,这项任务会变得更加复杂。

Log4j是一种日志工具,几乎存在于所有Java应用中。从2.0-beta9到2.14.1的多个Log4j版本中存在关键远程代码执行漏洞(CVE-2021-44228),攻击者可利用该漏洞完全控制易受攻击的系统。上周,Apache基金会发布了该工具的更新版本 (Apache Log4j 2.15.0),但由于原始补丁未能完全防止拒绝服务(DoS)攻击和数据盗窃,本周二又发布了第二次更新。

很多人都觉得这个漏洞是近期最危险的漏洞之一,因为实在是太容易被利用了,而且普遍存在于每个IT环境中。举个例子,Veracode就发现其客户中88%都在使用某个版本的Log4j,而58%的客户环境中存在带漏洞的版本。

自上周该漏洞首次披露以来,世界各地的攻击者一直在尝试利用这个漏洞。多家安全供应商观测到攻击者试图利用该漏洞投放加密货币挖矿机、勒索软件、远程访问木马、Web shell和僵尸网络恶意软件。12月15日,Armis报告称,其客户中大约35%正遭受经由该漏洞发起的主动攻击,31%则面临托管设备上的Log4j漏洞相关威胁。这家安全供应商表示,针对其客户的漏洞利用攻击尝试次数高达3万次之多。其他几家供应商也报告了类似的活动。

Armis发现,迄今为止,IT环境中最容易被攻击者盯上的资产是服务器、虚拟机和移动设备。而在OT网络中,49%的被黑设备都是虚拟机,43%是服务器。OT网络中的其他目标设备还有联网摄像头、人机界面(HMI)和数据采集与监视控制(SCADA)系统。

界定问题范围

安全专家表示,在防御针对Log4j漏洞的攻击时,企业面临的一项主要挑战是摸清自身的整个暴露面。该漏洞不仅存在于企业面向互联网的资产中,还广泛存在于内部与后端系统、网络交换机、安全信息与事件管理(SIEM)及其他日志记录系统、内部开发应用与第三方应用、软件即服务(SaaS)和云服务,以及自身甚至可能毫无所觉的环境中。而且,不同应用和组件之间存在相互依赖,这意味着即使组件不直接存在漏洞,也仍然可能受到漏洞影响。

Noname Security表示,Java程序包打包机制通常会增加受影响应用的识别难度。例如,Java存档(JAR)文件可能包含特定组件的所有依赖项,包括Log4j库。但JAR文件还可能包含其他JAR文件(该JAR文件可能又包含另一个JAR文件)。基本上,这个漏洞可能嵌套了很多层。

Netskope威胁研究工程师Gustavo Palazolo表示:“企业在缓解Log4j漏洞时面临的主要挑战之一,是识别所有受损资产。”他补充道,基Log4j Apache Java的日志库非常流行,许多应用,还有物联网设备和为了向后兼容而维护的老旧系统,都在使用此类日志库。

即使发现应用存在漏洞,更新应用也可能很困难,因为企业可能无法承受宕机的代价,或者缺乏合适的补丁管理控制措施。

Palazolo称:“因此,在某些情况下,识别所有受损系统和修复问题之间的耗时可能会很长。”

API和第三方风险

应用还不是唯一的问题。Log4j漏洞也会影响应用编程接口(API)环境。Noname Security表示,包含该漏洞的API服务器提供了诱人的攻击渠道,因为许多企业其实对其API清单和API行为的可见性有限。没使用Log4j日志框架的公司可能在用含有Log4j漏洞的受信第三方API,同样面临Log4j漏洞利用风险。

Noname Security技术副总裁 Aner Morag表示:“对于企业而言,想要最大限度地降低遭遇API型[Log4j漏洞]利用的风险,需要采取几个步骤。”这些步骤包括:映射使用任何Java服务提供API的所有服务器,不允许任何用户输入接触到API服务器上的日志消息,使用代理或其他机制来控制后端服务可以连接到哪些服务器,并将API置于API网关或负载均衡器之后。

企业面临的另一个Log4j漏洞缓解挑战是,要确保他们使用的所有第三方产品和服务都打上了合适的补丁,或者设置了针对该漏洞的缓解措施。

Alert Logic安全运营副总裁Tom Gorup称:“许多供应商产品受到影响,[并且]受影响供应商的数量每天都在增加。不是所有供应商都有补丁可用。”

Gorup建议安全团队检查其供应商的网站,或者直接与供应商联系,好了解他们的产品是否受到影响。供应商可能易受此漏洞影响,但已发布缓解措施来保护其客户。

Gorup指出:“至少,你得清楚怎么验证自己的资产已经接收到更新了。”他还建议安全团队检查过去几天公布出来的易受攻击产品列表,比如GitHub上发布的那个(URL:https://github.com/NCSC-NL/log4shell/tree/main/software)。

Gorup表示:“对此漏洞的回应可能是,‘我们不使用Java’。尽管情况可能真是这样,但你的第三方软件或许早已嵌入了Java,导致你的漏洞扫描压根儿没显示出这一[威胁]。”