话题1：为什么OOD漏洞就一定修不完呢？是说只要有动态转换，就一定有各种编码来绕过各种各样的限制手段吗？
A1:ODD强调的是开放动态，还不只是动态。这个模式太灵活，在复杂程序中很难做到完善管控，出问题几乎是必然的，fastjson一而再再而三的验证了这个风险。
A2：ODD相当于实现了eval，然后将安全寄托于发现和过滤eval中的代码，所以永无止境。可以说是，一方面希望执行eval中的代码，一方面希望过滤eval中的恶意代码，就跟杀软一样。
此次log4j2漏洞不一样，lookup不相当于ODD，相当于eval代码中的file_get_contents，问题出现在这个函数或功能点上，把这个函数禁用了，所以这个风险点就消除了。建议复习一下16年pwntester的slides或者看下java EL的语法特性。
变量能够解析表达式这个问题存在太久了，未来还会继续发生。云是计算资源的基础设施，大量软件工程的通用模块也是基础设施。云被纳入CII关基了，通用软件不被列入进来，大家不会重视安全。
A3：和soc里面日志分析、关联分析类似，为了减少误报吕必须结合上下文（context）分析来做出是否攻击的判断，这种动态安全也符合零信任的理念。
话题2:log4j是完全开源的，代码进仓库，可以过代码检查，可以review，8年了，定怎样的基准才能提前发现没被使用且有危害的jndilookup方法类并规避呢？
A1：问题的原罪不在技术层面，今天你重视问题，问题迎刃而解，方法千千万。
把基线做好，解决80%的问题，不用讲那么多东西。做基线，做最基础的工作，不是安全团队能够搞定的。需要运维、架构、研发团队来主导，好的地方是后面的这3波团队是一家人。
安全不能高高在上，安全要双脚沾泥，搞架构和基线不比挖漏洞简单，要深入进去了解，做优先级排序，做重点取舍。
A2：安全大部分人没资格高高在上，因为很多时候都是资源不足，优先级排低的事情。安全给开发、运维赋能，提出安全要求的同时也尽量给予能落地的方法和手段，开发、运维主动或配合安全实现安全目标，应急时安全能充分调动开发、运维这就是一个比较好的协作机制。
对于安全来说，单体架构最好，系统少，暴露面少，关联关系少，但业务和研发就是要分布式，微服务。安全还是在配合业务上的前提下，辅助别人做的更好。安全不能独立做好，好的安全是架构运维开发做对了带来的一个结果。
A3：业务风险是讲不了，你只能说安全可能带来的破坏风险，而且也只能推测一下。有些业务线老板有时候会说，你上这上那的，是不是一定不会影响业务，你知道我停半小时会损失多少，让我效率变差，上线变慢又损失多少，再猛一点的还和你纠结一下要量化的数据，可能性x损失，安全消耗的其他团队人力和安全风险损失，哪个大。
A4：安全治理文化，安全主体责任，之后是工具、方法、协作机制。文化的影响和责任的影响更大些，个人的浅见。
总之，安全依赖于开发和运维，无论是哪种方案，如果能实现一键修改、一键测试、一键部署，才能适应日益复杂的生产环境需求，快速应急响应，并真正减少人力投入，同时此次log4j事件促进安全产业思考，以及在sca软件成分分析、rasp（Runtime Application Self-protect，即应用运行时自我保护系统）技术方面的投入和商业化推进。
话题2：关于MyLoBot僵尸网络病毒，我们发现的特征是受感染的终端发送大量的DNS请求去回连主控端，这些请求域名有较强的迷惑性，域名随时变化，无法分别真假。目前的检测是依赖于URL情报得出。我们目前只是在核心流量节点上捕捉到了这些恶意请求，但看到的是分支机构的DNS，而不是真实的受感染的终端。想请教的问题如下：
2、找到之后，除了系统重置之外，还可以采取哪些有针对性的措施？比如专杀工具。
3、该病毒的传播途径和感染机理是什么？网上公开的资料很少，希望能做好有针对性的预防措施。恳请赐教。
A1:分支机构如果没有检测设备，可以在分支dns服务器上抓包排查真实ip，专杀工具和传播感染机制及预防措施可以找合作安全公司问问。
Q:开启DNS的debug日志，会有比较大的性能消耗，暂时还不想动用这个，现在的想法是在DNS增加A记录，把已检测到的恶意域名指向诱捕的主机，根据后续的交互来抓取进一步的通信，从而找出相应的真实终端。
但问题在于不掌握回连端口信息，诱捕主机该如何监听，还是个麻烦事儿。此外，我们尝试过使用常见的杀毒软件去解决，但是基本上都杀不出来，据说目前还不掌握该病毒的特征。我看网上的消息，这个情况，早在2018年就有过报到，以为比较常见，所以在群里问问大佬们有没有相应的处置案例。
A2:这类病毒的特征会经常对外请求不规则的域名，这些域名不一定都会有正常的DNS结果返回。
1、平时需要注意从流量中观察全网是否会有请求量不大，但是看起来异常的域名请求记录；
2、传播的途径如果不是蠕虫就缺少主动感染性，一般就是通过U盘、共享目录或者下载传播；
3、这类病毒通常会通过定时计划任务，加载到内存里。如果杀毒软件对内存不进行彻底检测，很难发现。如果不把计划任务清除，也会一直杀不干净。
Q:前期的处置措施很粗暴，现在就想定位之后提取样本。请求量还是比较大的，虽然这类域名根本解析不出去，也没啥实质性危害。但是看着不舒服，对正常的网络监控产生比较大的干扰，总觉得这个问题还是得从根本上解决掉。尤其是在23：55分左右，会有一波小高峰.
A3:那大概率就是一些计划任务，可以在疑似的终端上部署流量抓取的工具，进行流量日志的获取。如果终端防病毒软件有类似的功能就更好了。
Q:我们通过桌管，桌面杀毒什么的，组织过几次专门的清理，好像还是没效果。现在也不好确定到底哪些才是疑似终端。
A4:可能是DGA,防火墙上面看不见哪些内部主机连接这些DGA的域名？
Q：可能是墙、邮件网关，现在这些恶意请求是出不去的，得不到DNS解析记录，不会发起实质性的连接请求。
A5:一般中毒的终端都可能会有异常的计划任务，如果可以监控计划任务，比如EDR。还有一种思路就是找到一台中毒的终端，通过全网反查只要有这个计划任务的终端，都是异常或潜伏的终端。
A6：这些域名会在某个时间点，把某一个域名开通解析，这个时候就是真正发起攻击的时候，通过链接上的地址再投递样本。定期查域名更新库。如果真的是晚上23：55分左右，那么大概率很多电脑都是关机下班了。只需要统计哪些电脑在这个时间段开着，再看剩下机器在这个时间段里的流量、CPU、内存信息，如果有超过一定平均值的，都可以加入异常列表中。
Q:怎么批量反查有异常计划任务的终端,还没条件实施全网的终端EDR，终端的桌面管控，就是个桌管和杀毒软件。
A7:有终端资产管理的话可以查计划任务，如果技术上不好搞，就只能用管理上去推动了。有没有流量探针设备，把终端、服务器与DNS服务器互访的链路流量镜像过去，然后在流量分析上面搜异常的DNS请求包，一般只要不是同网段，跨网段的都可以看到。
Q：骨干链路上都有，但我们看到的都是分支的DNS，看不到真实的受害终端。分支机构的技术力量薄弱,没这么好的条件了，另外调度起来，也要多方协调，费事儿。而且还会有很多其他的干扰因素。我现在只想搞定MyLoBot这一项问题。
A8：那就可以缩小范围了，源头就在某个分支机构里面。可以在分支机构的核心链路再部署探针抓一下包。如果没有设备那就只能在分支机构的dns服务器上面启DNS日志，如果是很平凡的请求，一般开10分钟的日志导出来就可以看到了，不会太影响性能。
本周群里共有 172 位群友参与讨论，群发言率为40.57%，群发言消息数为 1211 条，人均发言数为 7.04 条。
本周群里共有 130 位群友参与讨论，群发言率为28.32%，群发言消息数为 526 条，人均发言数为 4.04 条。
——————————————————————————–
【金融业企业安全建设实践群】和【企业安全建设实践群】每周讨论的精华话题会同步在本公众号推送（每周）。根据话题整理的群周报完整版——每个话题甲方朋友们的展开讨论内容——每周会上传知识星球，方便大家查阅。
如何进群？
原文始发于微信公众号（君哥的体历）：OOD漏洞、Log4j2漏洞的预防探讨及其事件思考，MyLoBot僵尸网络病毒如何快速有效的定位真实受害IP？| 总第125周
