墨者防御联盟-提供超强DDoS高防/CC防护/大流量清洗服务!
当前位置:主页 > WEB安全 > 正文

聊聊配置文件 RCE 这件事

01-15 WEB安全

昨晚推特上一条博文引起了圈内的大量关注

图片

夭寿啦!log4j 2.17.0 能够RCE 啦!!

然鹅:

图片

嘘……

圈内人士嘘声一片……

修改配置文件 RCE??就这就这???

这么修改配置文件来RCE到底是如何“流行”起来的呢?

这件事还要从 Log4j 2 的 RCE 讲起

在log4j2 的 GitHub项目有个 Pull:

https://github.com/apache/logging-log4j2/pull/608

一位叫“TopStreamsNet”的老外提到:

图片

假如您查看 jndi 在 1.x 中的工作方式,您会发觉有两个地点能够完成寻找 - 即 JMSAppender.java:207 和 JMSAppender.java:222 - 假如您将 TopicBindingName 或 TopicConnectionFactoryBindingName 设置为 JNDI 能够处理的内容 - 例如“ldap://host:port/a”JNDI 将做与 2.x 彻底相同的情况 - 于是 1.x 是易受攻击的,不过攻击向量“更安全”,因为它取决于配置而不是用户 输入

接着经过配置文件 RCE 的这件事就开始讨论起来了

非常是 Log4j2 的作者回复到:

图片

假如攻击者能够修改某个系统 S 上的配置文件,这么能够假设 S 基本被特别大程度地渗透了。假如攻击者能够修改 log4j.properties (log4j 1.x),她就不需要下载恶意代码,她能够轻松地将恶意类文件放在类路径中并让它们执行。所以,高防cdn,在很严格的意义上,log4j 1.x 中存在漏洞,但与日志参数引起的 RCE 没有任何关系。

实际上能够看得出来,Log4j2 的作者一开始并不认同那个老外的观点,但故意思的来了

就在大伙儿以为那个“漏洞”不是漏洞的时候,RadHat 出来作妖了:

https://access.redhat.com/security/cve/CVE-2021-4104

图片

他们把那个由配置文件引起的 RCE 定义为漏洞,同时给了cvss v3 7.5的中危评分!

接着有人又在 log4j2 这个 pull 下面回复了:

图片

路人:看,你看,RedHat 发了一具 CVE,而且依旧7.5的评分!(实际上一开始给了 8.0)

固然,也有人回复到:

图片

路人:TMD,ReaHat 你不明晓规矩,不说武德,人家 log4j 官方都没发话呢,你出来搞啥情况

后来迫于压力下,log4j 认了那个 CVE

图片

我们决定保留 Red Hat 分配的 CVE,以节约创建另一具并拒绝他们的 CVE。

log4j 官方:行了行了,我认,我认还不好吗

至此,由log4j 在 pull 上讨论出的第一具 由配置文件引发 RCE的 CVE 被 RedHat折腾出来了

在log4j1 那个 CVE 公布前,实际上我就对“TopStreamsNet”这位老外提出的看法举行了研究:

TOP log4j 1.x 与 logback 的鸡肋RCE讨论:

https://www.cnpanda.net/sec/1131.html

同时我发觉实际上log4j 1.x 的配置文件 RCE 并不能立即生效,因为修改 log4j 1.x 的配置文件需要重新加载后才干够生效,在生产环境下谁闲着没事主动重启或者重新加载配置文件?

但 logback 不太一样,因为 logback 有个 scan 属性,能够自动扫描配置文件是否发生了改变,假如发生了改变,这么就会自动更新配置文件。于是研究的时候写了一具 SpringBoot 的演示Demo 发到了 GitHub 上。

凑巧的是,在 logback 的官方 issue 上看到一具提咨询,大意是 logback 中是否存在RedHat 公布的这个漏洞,接着我回复了之前这个SpringBoot 演示 Demo 的地址,后来 logback的作者也给分配了CVE-2021-42550,还发邮件咨询我要不要 credit

图片

老外依旧热心的,然而我觉得这漏洞本身限制特别大特别鸡肋,而且 @香依香偎 师傅在一年前就提出了那个利用方式:

https://xz.aliyun.com/t/7351

于是我拒绝了credit。

后来经过 @TiGer 师傅得知得知那个 logback 漏洞实际上浮上过实际例子的利用:

图片

能够参考:https://www.cnblogs.com/zpchcbd/p/15542705.html

总结

回过头来看看那个log4j 2.17.0 的配置文件 RCE,真的有些离谱,因为修改完配置文件后,它不像 logback 一样能够实时生效,属于鸡肋中的鸡肋了。

实际上 @pwntester 大神也讲了:

图片

图片

大多数使用数据库的 Java 应用程序都有配置文件,您能够在其中指定 JNDI 地址以猎取 JDBC 数据源

简单搜索发觉,能够经过 JNDI设置配置文件的部分应用如下:

jetty

Apache ODE
https://ode.apache.org/using-a-jndi-datasource-under-servicemix-jbi.html

Apache Shrio
https://shiro.apache.org/static/1.3.2/apidocs/org/apache/shiro/jndi/JndiTemplate.htmlhttps://www.programmerall.com/article/1371213168/

Tomcat
https://tomcat.apache.org/tomcat-8.0-doc/jndi-datasource-examples-howto.html

TomEE
https://tomee.apache.org/jndi-names.html

SpringBoot
https://blog.roncoo.com/article/133919

等等等

太多太多了,实际上正如@pwntester讲的那么,JNDI 类似于在一具中心注册一具东西,将来要用的时候,只需要依照名字去注册中心寻找,注册中心返回你要的东西。比如在 web应用中,我们能够将一些东西(最常用的算是数据库相关的配置信息)交给服务器软件去配置和治理,DDoS防护,在程序代码或者配置文件中只要经过名称寻找就能得到我们注册的东西,而且假如注册的东西有变,比如更换了数据库,DDoS防护,我们只需要修改注册信息,名称不改,所以代码也不需要修改。

这是SUN公司提供的一种标准的Java命名系统接口,是一种特性,所以普通来讲,只要存在 JNDI 的地点,都可以利用 ldap 协议去实现 RCE,固然,不仅仅是 ldap 协议,实际上还有特别多可用的协议:

图片

总之,我以为log4j 2.17.0那个 CVE,分配了就罢了,但过分的是,这老外还好意思发表在推特上来讲log4j 2.17.0又出 RCE 漏洞(刷洞就刷洞,还吆喝一嗓子,结果依旧这漏洞,不是让别人像吃了屎一样难受吗)

一句话总结:经过配置文件来实现 RCE,只能讲是一种攻击手段,而不能讲是一种常规漏洞。

Paper

版权保护: 本文由 主页 原创,转载请保留链接: /web/139366.html


QQ客服

400-0797-119