From a4b8b494b28ef3d446527d93186e18360a5aa1e7 Mon Sep 17 00:00:00 2001
From: Lukas Arnold <lukas.arnold@stud.tu-darmstadt.de>
Date: Mon, 20 Jun 2022 11:11:22 +0200
Subject: [PATCH] Explains the choice of the used LDAP approach in more detail
---
.../src/main/java/de/seemoo/netsec/AttackInterceptor.java | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/ldap/src/main/java/de/seemoo/netsec/AttackInterceptor.java b/ldap/src/main/java/de/seemoo/netsec/AttackInterceptor.java
index 52398e9..fae77ef 100644
--- a/ldap/src/main/java/de/seemoo/netsec/AttackInterceptor.java
+++ b/ldap/src/main/java/de/seemoo/netsec/AttackInterceptor.java
@@ -44,14 +44,16 @@ public class AttackInterceptor extends InMemoryOperationInterceptor {
// Another approach would be to exploit (de-)serialization of objects which is also supported by LDAP,
// but for this the system property 'com.sun.jndi.ldap.object.trustURLCodebase' must
// have been set to 'true' for almost all Java versions.
+ // You can read more about it on https://www.innoq.com/en/articles/2022/04/java-jndi/.
+ // However, the approach can be used in combination with certain classes of libraries for RCE attacks.
+ // Those classes are also called gadgets, read more about it on: https://github.com/mbechler/marshalsec.
- // Other approach: https://www.innoq.com/en/articles/2022/04/java-jndi/
-
- // With this approach, it's not required to set the property for Java version <= 8u191.
+ // With the factory approach, it's not required to set the property for Java version <= 8u191.
// https://news.ycombinator.com/item?id=29505027
// https://www.lunasec.io/docs/blog/log4j-zero-day/
// We've confirmed this with JDK & JRE 1.8.0u111 available at
// https://www.oracle.com/de/java/technologies/javase/javase8-archive-downloads.html
+ // We suppose the problem is caused by CVE 2018-3149: https://bugzilla.redhat.com/show_bug.cgi?id=1639834.
try {
// Sends the newly generated malicious entry back to the requester
--
GitLab