从Log4shell事件看资产风险运营工程化的困局与盲点

0x00 前言

这几天想必各位同行都被这个漏洞折腾疯了，不管是甲方的同学还是乙方的同学，毫不夸张的这个漏洞应该是近五六年以来仅次于永恒之蓝事件的安全事件了，只要你是Java公司，或多或少都会收到这个漏洞的影响。从上周五开始，几乎所有的小伙伴们都开始在群里喊应急了，我本人也是因为这个事儿毁了一个周末，本来还约了人去滑雪。但是周一一看国内基本上收敛了，但是国外开始了，各种黑产和僵尸网络开始层出不穷的出现。根据360netlab那边的数据，最早从12月1号开始就有黑产开始利用这个漏洞摸鱼了，并且各个厂商也不断的去更新各种各样的IoC，有趣的事情是，卡巴斯基旗下SecureList更新了差不多10几个IoCs，紧接着趋势马上把这个数量拉到了将近100个，可见黑产有多么的狂欢（IP大多数来自于俄罗斯）。

在这篇文章中，我们不会讨论是谁泄露了漏洞的信息，也不讨论各家的修复建议是不是靠谱等一些技术性的问题。单纯就说从这次推修的过程中，我们如何去重新思考整个资产风险运营体系和工程化这件事情。

0x01 到底发生了什么事情

为了防止有圈外的人不知道发生了什么，我先用一个通俗易懂的例子来说一下这几天发生了啥。

你们镇上有一个远近闻名的砖厂，因为物美价廉而且质量稳定可靠，生产出来的成品砖畅销海内外。有一天有一个韩国人发现自己用这个砖厂生产的砖盖房子的时候发现可以添加一些物质使得砖搭起来更容易，成本能降低。然后这个韩国人就找到了砖厂厂长说了自己的方案，连原材料配方啥的都拿过来了。厂长一听这事儿靠谱，然后就把这个整个厂的生产线全都应用了这个技术。过了很久之后，有一个大爷在遛狗的时候，不小心磕到了墙上，结果发现墙裂了一块，因为大爷是一个已经退休的质检科科长，于是他便去分析了一下情况。好么，这一分析发现这个韩国人给的东西完全不靠谱，只要碰的角度和方向对了，可以不费吹灰之力直接把墙撞塌了。大爷直接急了，把情况反馈给了厂长，然后经过厂内技术专家的反复确认，这个东西确实有问题。然后便把这件事儿同步给了应急管理相关的机关单位。机关单位听完之后当场说出**俩字，然后经过一轮排查后发现，不仅是最近几年盖得楼房，连学校、医院、政府大楼这些事业单位的建筑都用了这批砖，而且厂房的二期工程用的也有这批砖，不但如此，好多宅基地上自建的一些平房也都用了这批砖，可以说没有不用的。结果应急管理相关的同志们开始评估并制定加固方案，但是因为影响范围巨大，导致全量处置完需要的时间可能不是一点半点，至少今年是没戏了。除此之外，应急管理部门还发现这个配方只有在韩国本土才有人用，连他北边的邻居都不用。最后砖厂花了几天时间把生产线又改回了原样。

回归到事件本身，针对这个事件本身而言，实际上现在还在处于控制损失的阶段，因为你只能保证你自己不用有问题的版本，并不能保证你用的组件里面用的开源组件不用有问题的版本，也不能保证你买的商业产品里面用的开源技术不用有问题的版本。所以这个漏洞的修复肯定不是一时半会儿能够解决的，未来估计会和新冠病毒一样与信息基础设施长期共存。

0x02 资产风险运营工程化的若干点忠告

（1）尽量避免“单线作战”，要进行“多线作战”，重视对抗工作但不要为主

首先先来阐述一个观点，对于Log4shell这种事儿而言，不要把它当成一个常规的资产风险推修事情去处理。我非常能理解企业内部建设资产风险运营相关的流程、能力和平台这件事儿是为了去更好的解决资产风险运营的事情，但是我还是想说这件事情应该当做一个专项来处置。因为这种类型的事件往往不是“单线作战”，而是“两线作战”甚至是“三线作战”，仅仅依靠把握修复进度而言是远远不够的，对于这种热度很高且利用难度极低的漏洞而言，入侵对抗层面也是有着非常大的压力。所以要在运营修复质量的同时，也要注意对抗层面的工作，具体对抗层面的工作包含：

• 缓解与修复方案的制定与研究
• 补丁绕过的机制与分析
• 流量侧风险利用感知
• 终端侧风险利用感知
• 风险威胁情报/IoCs/ByPass检测策略的信息收集

虽然说要强调对抗工作的重要性，但是不能以其为主，工作的人力、资源和重心一定要放在push风险修复进度这件事儿上，毕竟人家打不打你是一个概率事件，风险的存在是必然事件。

（2）专项启动前对修复需要用到基础设施进行性能勘测和评估

平台化解决资产风险运营工作的思路是对的，但是在设计的时候有没有仔细考虑过运营平台的上限是什么？因为当前风险超过产品本身的性能指标的case有一个比较经典的：2011年岛国大地震的时候直接把福岛核电站震塌了，抛开实际操作不当这些运营层面上的事儿不谈，这个核电站在设计的时候最多只能扛得住8级地震，但是2011年的那次遇到的是9级的超级地震，导致核电站直接芭比Q了。所以平台在设计的时候，设计指标并不一定能扛得住Log4Shell这种影响范围的漏洞，严格意义上来讲也没有必要。这件事儿对于资产风险运营平台来说，甚至对于企业内部的代码仓库、CI/CD平台、发版系统来说也是个不小的挑战（毕竟要频繁改代码、编译、上线调试，对于平台的压力可想而知）。所以资产风险运营平台需要提供必要的工具链，在平台失效的情况下也可以利用工具链完成风险运营SOP进行风险事件的处置，当然扩容能解决的问题，扩容就好了。我估计至少有90%以上的企业在修Log4Shell之前都不会去评估自己的基础设施是否能扛得住大规模推修，然后等要出数据的时候发现数据有延迟、计算的不对的情况，那个时候已经晚了。

（3）风险信息获取要前置，只简单同步风险数据库很危险

这个问题其实我在ISC2019的时候强调过一次，从xcodeghost带火供应链攻击这件事情以后，资产风险信息的获取工作就不能是去同步NVD、CNVD这些成品漏洞库了，一定要去分析在用组件的commit、issue和jira等PR材料，这样才能提前获取高危风险的修复版本，甚至我还在公司的技术博客上又强调了一遍：《美团安全应急响应中心》。且不说慢不慢的问题，漏洞其实只是风险的一小部分，现在马上就2202年了，如果要是在仅仅凭借爬朋友圈、同步漏洞数据库这种简单的操作去做外部风险识别与发现，已经完全不能cover的住这种风险的运营工作了，现在还这么干相当于是50年加入国民党还在留守大陆。奉劝各位搞个Apache的ICLA吧，真的不难。

除了风险信息之外，要及时的建立起来风险运营的一整套体系，最少应该包含资产-风险关联规则、配套中间件和SDK、关联规则插件和引擎、外部配套的API

（4）SCA/RASP在这类风险面前的作用可能比黑盒扫描器更安全好用

之前很多企业都不重视RASP和SCA这两个产品，实际上在这类场景中，SCA作为分析项目的依赖情况可以迅速判断出来哪些项目有问题，结合HIDS的进程数据、环境变量数据，可以很轻松的排查出来那些项目受影响。RASP这种东西实际上在检测这种JNDI注入的攻击时候成功率非常的高。但是看一下企业内部SCA/RASP的覆盖度，大家就明白我在说什么了，不出意外的话明年3月我会分享一下我在SCA层面上的一些建设。为什么不要用黑盒扫描器，在你对你的PoC能够说出不会影响业务并且有benchmark之前，不要乱用黑盒扫描器，因为你也不知道业务的实现逻辑，很容易扫挂了，扫挂的后果轻则业务打电话直接喷人，重则。。。你懂的吧。此外你在企业内部有大把的数据可以用，为什么非要采取这种白帽子或者是黑产才会用的手段为主呢？

（5）不要盲目听信升级版本可以解决问题，有时候缓解可能会更好

升级版本可以解决问题么？当然可以解决，但前提条件是你要能保证你升级的版本是对的。何为对的版本，彻底解决该类风险，比如2.16.0-rc版本中彻底移除lookup功能，当然算是一个正确的版本(截止到目前这个选项也不对了，因为盲目删除了lookup功能，目前引发了大量的兼容性问题，比如说ES 7.9.1版本引用了lookup功能，导致无法启动)。但是，很遗憾，绝大多数企业内的情况并不适合直接升级版本，虽然我在给Log4J2作者发邮件询问patch的时候，Log4J2的作者表示升级版本这件事儿是一件非常smooth的事情，但是实际情况是，升级版本会引来很多的兼容性问题，严重的会直接导致业务崩溃起都起不来了。这是一件很严重的事情，甲方公司内部安全部门存在的价值就是为了保障业务的安全，你给出的Solution直接把业务弄死了，你还好意思说自己有存在的价值吗？在没有出现彻底的解决方案之前，缓解才是第一要素，缓解可以提高攻击成本，能够给你争取更多的修复窗口时间。而不是一上来就去直接升级版本，企业内部升级版本又不是2.14.1->2.15.0-rc这么简单，而是2.1.x\2.2.x\2.3.x\2.4.x\2.5.x\2.6.x\2.7.x\2.8.x\2.9.x…..->2.16.0-rc这样，而且你会发现各个分支版本所占比重都差不太多，这个时候如果盲目强推新版本，你觉得不会有兼容性问题么？所以选择最适合企业内部情况的才是最好的，没必要纠结是不是升级版本，财大气粗的企业自己写一套不香么？

（6）需要有“一言堂”的人出现，高效分配手头资源

何为一言堂，敢在团队面前说“你们要听我指挥，出了问题我来背锅”。当然说前半句的人有而且还挺多的，完整说出来的人不多。这个时候需要有人去全局统筹研发资源、运营资源等现有的资源来更高效的去解决这个case，如果没有这种人，就会出现胡乱争抢资源的情况，有一些鸡毛蒜皮的小事儿完全可以通过FAQ或者迭代检测规则就能完事儿，非要上升到给平台的PM提需求，导致资源被浪费，拖慢了修复进度。这个时候大量的资源要倾斜到推送漏洞修复和迭代入侵对抗策略上，恶意争抢资源的需求这个时候需要被一票否决，等以后再说。

0x03 总结

希望这种事儿以后能少一点是一点吧，我要先去睡觉了，有想深入交流这一部分的，可以加微信e1knot

原文始发于知乎（elknot）：从Log4shell事件看资产风险运营工程化的困局与盲点