timeline

从12月9号开始忙于业务侧漏洞推动，极少有时间对自己的处置做复盘和思考，文章内会隐去公司层面的处置方式注重于个人。从12月9号以来的timeline

  • 2021-12-09:
    • 上午：获取apache log4j-core的commit，基于commit的分析和上层链路本地分析成功，确认存在jndi注入导致的RCE问题，复现成功后基于公司的场景认为该漏洞对业务代码影响有限，公司内部群抛出信息。
    • 晚饭后发现poc在网上被公开，且百度、微信、iclound均可浮现jndi lookup请求，影响面扩大后尝试确认漏洞在开源组件侧的影响，确认cas、es等基础服务、大数据平台受影响。
    • 确认脏数据进入内网数据流转体系后，被延时、重复触发的问题，且没有脏数据净化能力。
  • 2021-12-10:
    • 确认rc-1的修复绕过，但需要修改默认配置启动lookup功能即使用LookupMessagePatternConverter解析消息
    • 参与log4j2漏洞修复方案制定：确定LOG4J_formatMsgNoLookups=True参数对2.10上下版本的影响。
    • 跟进elastic公告：
      • 确认es 6.x 7.x版本使用java沙盒，无实际RCE的危害
      • [TODO]知晓logstsh jvm参数无效的公告，但未做根源分析
  • 2021-12-11:
    • poc在大数据体系下多次流转能以定位实际出发点，分析代码验证${sys:HOSTNAME}外带信息的可能，确认受log4-core版本影响，>= 2.8默认启用enableSubstitutionInVariables否则poc被截断触发失败。
  • <—业务推动—>
  • 2021-12-17:
  • 2021-12-18:
    • 跟进CVE-2021-45046 getHost()方法绕过但因uri authority中存在#特殊字符，只能在macos中触发

思考

在2周的应急响应时间中发现很多痛点，也边吐槽着不足边努力推动，“核弹”级别漏洞突然到来考验着安全的基础、个人能力，慌乱中才能更好的暴露问题。在漏洞推动过程中会受到大量不确定因素的影响，如基础能力、CI/CD成熟度、安全BP能力建设等等，而从我自身深度参与的三个方面需要做更深度的复盘。

威胁情报

  • 来源：威胁情报的来源基本为采购传统厂商的情报或者甲方侧自实现公开威胁情报、CVE等漏洞库的爬取、加工，而这次log4j漏洞可以看出公开威胁情报远远滞后于commit、poc泄漏事件节点。
    • 开源组件特性：提交issue/email -> 修复人commit -> MR -> release
    • 改进：对于常使用的基础组件应该讲信息来源前置到公开威胁情报、CVE之前，基于log4j-core漏洞完全可以前置到commit、issue截断
  • 风险识别、判断
    • timeline中对该漏洞的影响面分析仅从业务代码依赖引用分析，没有及时考虑其对开源组件影响。缺乏开源组件依赖的宏观视角导致仅聚焦于业务代码。

资产

  • SCA：业界真正做SCA还是少数，其中可以准确提供BoM更是少数。BoM的积累在漏洞爆发的时候可以快速定位受影响业务、收敛威胁面。避免临时通过白盒、HIDS、mvn依赖分析等多重能力东拼西凑受影响资产。

能力储备

  • 安全研究：在log4j漏洞爆发时，甲方、乙方都是忙于奔命的状态，威胁情报的快速迭代中也包含着模糊的建议、错误的资产等等，而甲方安全团队需要拿出最为准确、有效、切合自身公司的修复方案来提供到业务，避免业务侧无效、重复的情况。而在log4j中有最简单的两个例子：
    • 12-10号大量公众号提供的修复方案为LOG4J_formatMsgNoLookups=True参数，并没有说明对于2.10版本的要求
    • 大量公众号将redis列为受影响的组件，而redis为c语言实际不受影响，后续将redis更正为jedis，而实际jedis中的log4j-core仅作为<scope>test</scope>使用，如果甲方安全团队没有快速定位、确认问题，草率推送到业务侧，将大大消减安全团队的权威性。