问题描述:
部署在用户的服务器,扫描系统服务的时候,发现服务器上有weblogic的CVE-2018-3252的漏洞。经过在公司反复验证和查找大量资料最后确认是端口的问题。weblogic默认是7001的端口,项目的端口默认是7001。然后扫描软件一般会有固定的验证方式确认是否存在该漏洞,比如3252的POC(观点证明),就是向7001发起一个固定地址的请求如果成功了就说明有漏洞。
解决过程:
因为这个扫描程序是第三方提供的,而且扫描的报告中并没有说明CVE-2018-3252是在服务器新项目中的多少行,所以排查问题的时候一开始都是再猜是哪里的问题。 1.因为扫描报告并没有什么有用的信息,除了知道漏洞的编号是多少,于是先去查找资料看是什么领域的漏洞,发现是weblogic的反序列化的漏洞,官方补丁链接
2.然后就想去官网上下载补丁去修复(实际上我们项目根本就没用到weblogic),oralce官网的补丁下载也是一个坑,必须有oracle的support identifier的账号才能下载,那么这个账号要怎么获取呢?简单明了的方法就是你要购买oralce的产品,付费才有这个账号(真的坑,用个开源的java,修复补丁还要收费的账号才能下载补丁)。于是想了一招去万能的淘宝上看看有没有这种账号可以租,搜索到淘宝可以有帮忙下载的补丁的服务,加了商家的微信问了一下,下载一次补丁要80RMB。
3.如果不是同事提醒我,可能我还真买了下载补丁的服务了。同事说咱们根本就没用weblogic的服务,为啥会有weblogic的漏洞,这句话把我点醒了,于是就想是不是俺们项目中引用了weblogic的jar包之类导致的。找了一圈,实在是没找到weblogic服务的包,有几个带有weblogic名字的方法和类,但是应该不会导致CVE-2018-3252这种发序列化的漏洞。
4.后来又想到一个方法,就是既然有着漏洞出现的话那么我们用同样的服务器,代码应该在测试服务器上也会扫描出漏洞,所以就去网上找了下扫描weblogic的工具,在github上找到了一个python的脚本。因为代码是开源的所以看到了python脚本是怎么检测有没有CVE-2018-3252的漏洞。
这个POC(安防领域的专有名词,用来扫描漏洞的特定脚本,查看返回结果是否符合预期,符合的话就是由漏洞),是给服务器的7001端口发送带有账密信息的请求,如果返回的是401或者500就说明是有漏洞的,这里为啥401和500是确认是有漏洞的可能是因为401未验证,说明这个请求的路是通的,只是没有登录;而500说明这个路径的请求也是通的,只是可能参数错误或者内部处理异常。但是只有检测出401或者500,攻击者就可以用这个路径反复的尝试去攻击服务器。所以导致这个POC返回预期的结果是因为我们项目设置的端口恰好就是7001,而拦截器里面也设置了没有登录就会返回401,所以刚好两者条件都符合就被扫描出CVE-2018-3252的漏洞了,闹了个乌龙。
解决方式:
1.将后端项目中的config的application.yaml里面的端口从7001改为7003,保存退出重启后端。
2.将nginx中映射到后端服务器的配置中的7001改为7003,保存退出文件,重启nginx。
总结:
1.解决这次漏洞收获了很多新的知识,比如安全领域的一些名词POC,CVE等,和扫描漏洞的方式,还知道了oracle要修复补丁是要收费的等
2.发现原来扫描漏洞就是用一组特定的方式去试验返回结果,如果是符合预期的结果就是有漏洞。所以网上的安全工具可能也是这样去检索漏洞,但是实际上未必有漏洞,因为可能被检测的电脑就有各种奇奇怪怪的组合刚好让检测工具误以为是有漏洞。如果确定没有漏洞却扫描出奇怪的漏洞要具体问题具体分析,去看扫描漏洞的POC是怎么验证的。
参考资料:
1.安防领域名词解释
2.python3的weblogic漏洞检测脚本
3.oracle的weblogic升级补丁
4.公共漏洞库
5.国家信息安全库
6.CVE-2018-3252的POC
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
如需转载请保留出处:https://bianchenghao.cn/16094.html