Spring漏洞问题之胡说八道

admin 2022年4月6日02:27:54评论9 views字数 2678阅读8分55秒阅读模式

 

题记

人类对未知事物的恐惧,远远大于未知事物的本身。

 

关于修漏洞这件事情

 

修漏洞这项工作应该是企业安全部门最本职的工作,应该说很多企业设立安全部门的初衷。

 

可是说起来安全部门好像一直都是被动修漏洞,睡觉都不安稳,一有风吹草动,就如同惊弓之鸟。

 

而且次出现漏洞时候修的千辛万苦,被所有部门骂不说,有没有修完估计只有天知道。有些时候运气不好还会被黑客抢个先手黑进来,安全部门也是被问责对象。

 

本文并不讨论Spring漏洞的本身的问题,写本文是想通过这个漏洞进行发散性思考,来看看我们能不能解决在类似漏洞出现以后,企业安全人员手忙脚乱的问题。

 

如何解决问题

 

不管是Spring还是log4j,本质来说都是安全漏洞。漏洞不可能消失,未来还是会不停出现,这个是无法改变的。

 

安全部门如果每次只是解决漏洞本身,每次修补漏洞都是简单的重复的工作,那我们每次依然手忙脚乱非常被动,所以我们必须想办法走到漏洞前面,这样才能在漏洞出现的时候能更好的应对。

感觉漏洞修补有点像疫情防控,可以参考一下近期新冠防控。如果想在疫情大规模扩散前控制,基本是从以下两个方面下手:

  • 疫苗,找到合适的针对病毒的疫苗,彻底免疫病毒,让病毒人类无害化。或者找到缓解病毒的杀伤力的方法,让病毒能被快速治疗或者轻伤害。
  • 管控,定位病毒位置,进行区域防控,控制病毒传播,再通过控制人员流动抑制病毒扩散,最终将病毒在这些区域里进行解决。

 

这么看如果对比防疫的方法和修漏洞,感觉也可以参考得出修补漏洞的工作需要努力的方向。

  • 建立对能免疫或者缓解漏洞的通用方法,例如使用rasp进行对web应用代码进行保护,拦截一些未知的web攻击。或者在一些系统层面采取例如内核加固技术保护,免疫某些提权漏洞
  • 对企业内的各种信息资产足够明确,每个地方用到的系统/代码都非能明确有对应信息,出现漏洞的时候能在第一时间把受影响的地方找出来,划出影响范围,将这些危险的区域标识出来,通过隔离或者监控控制这些区域,为修补赢得时间。

 

必须做好的资产管理

要想快速控制漏洞,前提就是要知道哪里存在漏洞,但是要知道哪里有漏洞,就要有足够的信息,就必须依靠完整的资产信息。

以前资产管理也就覆盖硬件资产,现在资产覆盖范围非常广,如网络资产,系统资产,大量的iot设备,大规模的虚拟化,还有业务系统中使用的各种软件资产。资产管理覆盖的范围现在远远超出了传统意义的资产管理。

简单整理罗列一下需要企业安全中需要资产管理覆盖的信息,感觉已经

Spring漏洞问题之胡说八道

要想建设一个完善资产管理系统并不容易,各种新技术新业务引入给信息收集的完整性和准确性带来很多难点。

难点1:虚拟化快速变更

现在企业云化、容器化与DevOps程度越来越高,特别是混合云,零信任让传统内网的界限越来越模糊。

devops,容器化进一步加剧了资产的碎片化,快速变化。以前感知到的一个资产,信息有效期很长,现在说不定一轮扫描还没结束,线上环境已经发生变化了。如何解决这些信息的准确性是个让人头疼的问题。

难点2:iot设备

现在各种智能化iot设备普及很快,这些智能化设备也会出现在网络内,对外提供服务,而且由于这些设备的黑匣子属性,让信息收集管理很困难。怎么做好这些iot设备的管理也是大难点。

难点3:开源软件信息

不仅仅需要在增加sdl的工作范围,加入对开发中引入框架和代码库进行信息收集。还要关注一些系统(IOT系统)或者软件使用的开源代码。如log4j时候很多iot系统都是重灾区。

难点4:三方资源

企业很多业务部署在第三方的资源平台上,这些跑在三方平台上的业务也经常因为某些原因成为资产信息管理的盲点。例如跑在某些云上的oss/bucket,还有cdn加速的域名,还有类似saas,小程序这些三方平台上跑的业务。

每次修漏洞时候最想知道的第一个问题就是这个漏洞影响我们哪些系统,但是每次好像都没有准确答案,不是没有记录就是遗漏,总不能做到准确的定位漏洞所影响的系统。

应该说没有准确的信息支持是安全工作者进行漏洞修补焦虑的最大根源之一,为了解决好这个痛点,我们应该建设好资产管理系统,才能为我们每次修补漏洞不会那么被动。

资产管理也算是一个老业务了,应该说是易学难精。但是这个系统的直接关系到漏洞修补进展的好坏。所以虽然有难度但是还是要花力气去做的事情。

 

免疫虽好但是门槛高

其实说了这么久各位看官可能都觉得,为啥有漏洞了才去修补,这样肯定是落后了,能不能在漏洞未知的情况下就能解决这些漏洞。这也是下面要讨论的免疫做法。

虽然建设一套解决所有漏洞攻击的系统还没有出现过,是做到解决某方面漏洞的方法还是有的。

 

比如在溢出漏洞攻击保护上有ASLR技术,linux内核上有PaX方案增加很多保护来缓解漏洞攻击。但是这些技术都对运维工作提高了很高的要求。记得很多运维文档第一句都说

在web年代,有了RASP技术,还有WAF都是用来防御未知web漏洞,只是很多时候部署这些系统都对业务有很多要求。

 

现在很多类似谷歌 amazon的巨头都开始走深度定制的路子,使用自己内部特制的系统和软件,再匹配自己安全研究团队对系统和代码的安全加固。做到很多漏洞出现后就能直接免疫。可是这样的投入是巨大的,在没有足够规模的业务支持投入产出完全不能成比例。

建立漏洞免疫机制,感觉和疫苗研发类似,不仅要投入巨大的研发力量,还要在研发出来以后进行长期的测试来确定不会对正常业务影响。

而如果想建立一套自我完善的系统,必须有足够大的业务体量,不然根本没法建立这样类似完全私有的系统环境。

 

突然觉得谷歌这样的方式类似建立了群体免疫,通过足够的多数的个体能抵御漏洞攻击,最终实现免疫漏洞攻击。其他实力不济的公司只能走动态清零的办法,一点点修补漏洞来解决漏洞攻击。

 

写在最后的话

说起来修补漏洞这件事情虽然说是大家都在修补同样的漏洞,但是真正比拼的还是基础工作谁做的足够扎实。例如完善的资产信息收集管理,靠谱的防御软件部署,这些看起来和漏洞没有相关的地方才是左右漏洞修补的最大影响因素。

写了这么多,想起来过去修漏洞的过程。

看见漏洞信息发布,风声鹤唳,草木皆兵。到处了解漏洞细节,各显神通的搞poc来进行验证。验证了不受影响还没高兴多久,突然传来消息某处偷偷上线的业务被漏洞打穿,忙乎了几个通宵,最后修了一个寂寞。

 

说起来大家害怕漏洞,也不是害怕漏洞本身,而是害怕不清楚漏洞危害有多大,影响多大范围。

 

最后放一个图吧版权属于煤老板,我这里引用一下。虽然是看着很郁闷,但是也的确说到了痛点。

Spring漏洞问题之胡说八道

 

 

 

原文始发于微信公众号(大海里的废话集合):Spring漏洞问题之胡说八道

免责声明:文章中涉及的程序(方法)可能带有攻击性,仅供安全研究与教学之用,读者将其信息做其他用途,由读者承担全部法律及连带责任,本站不承担任何法律及连带责任;如有问题可邮件联系(建议使用企业邮箱或有效邮箱,避免邮件被拦截,联系方式见首页),望知悉。
  • 左青龙
  • 微信扫一扫
  • weinxin
  • 右白虎
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2022年4月6日02:27:54
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                   Spring漏洞问题之胡说八道https://cn-sec.com/archives/942711.html
                  免责声明:文章中涉及的程序(方法)可能带有攻击性,仅供安全研究与教学之用,读者将其信息做其他用途,由读者承担全部法律及连带责任,本站不承担任何法律及连带责任;如有问题可邮件联系(建议使用企业邮箱或有效邮箱,避免邮件被拦截,联系方式见首页),望知悉.

发表评论

匿名网友 填写信息