java-exploit-chain

Java exploit chain assembly

White-box exploit chain assembly = verifying the feasibility of chaining multiple vulnerabilities at the source code level. The scope of work is: starting from discovered single-point vulnerabilities, analyzing the causal relationships and data flow connections between them, and assessing the actual severity level after combination. Runtime black-box exploitation techniques such as constructing remote exploits, sending payloads, and bypassing WAFs fall under the corresponding exploit skill scope.

In-depth reference

• Exploit chain methodology / Dependency audit table / Gadget analysis / Detailed explanation of 5 typical chains → references/chain-patterns.md

---

Exploit chain assembly principles

Three-stage model: information gathering (INFO) → privilege acquisition (AUTH) → code execution (RCE)

Each exploit chain is broken down into three stages, and the output of each stage must satisfy the preconditions of the next stage. If any link is broken, the chain does not hold.

Scoring rules: overall chain severity = final effect severity x chain feasibility coefficient (0.6-1.0)

• Full path feasible, no additional conditions: coefficient 1.0
• Requires specific configuration or low-probability conditions: coefficient 0.8
• Strong environment dependency (specific JDK version, SecurityManager disabled, etc.): coefficient 0.6

Evidence requirements: each link must be supported by EVID evidence (code location, configuration item, data flow truncation point); the chain must not be completed based on speculation.

Maven/Gradle dependency CVE audit

Dependency inventory extraction:

• Maven: mvn dependency:tree -DoutputType=dot generate a complete dependency graph
• Gradle: gradle dependencies --configuration runtimeClasspath list runtime dependencies
• Automation: OWASP Dependency-Check plugin integrated into CI, generating HTML/JSON reports

NVD/GitHub Advisory cross-referencing: use the NVD API or GitHub Advisory Database to query the CPE-matched CVEs of dependencies.

Key judgment — having a CVE does not mean it is exploitable:

1. Version matching: confirm that the version used by the project is indeed within the affected range (note that transitive dependencies may introduce different versions)
2. Code path reachable: whether the vulnerability-triggering code is in the project's actual call chain (depending on a library but not using the vulnerable function means it is not exploitable)
3. Attack surface exposure: whether the vulnerability entry point is externally reachable (internal utility class vs user-facing API)

High-frequency dangerous dependencies: commons-collections 3.x、fastjson <1.2.83、log4j-core 2.0-2.17.0、shiro <1.2.5、struts2 2.0-2.5.30、spring-cloud-gateway <3.1.1、jackson-databind <2.13.4

Gadget Chain analysis method

• classpath scanning: from pom.xml/build.gradle and WEB-INF/lib confirm which available Gadget libraries and versions exist in the target environment
• ysoserial payload selection: match available chains based on classpath dependencies (CommonsCollections1-7, BeanShell, Groovy, Spring, Hibernate, etc.), and select the trigger effect (command execution / JNDI lookup / file write)
• marshalsec for JNDI exploitation: set up a malicious LDAP/RMI service → target JNDI lookup triggers remote class loading → RCE; note JDK version restrictions
• Custom Gadget discovery: when standard chains are unavailable, search the project code for readObject/readResolve/readExternal Rewrite, trace the dangerous operations within it (reflective calls, file I/O, Runtime.exec, JNDI lookup), and attempt to construct project-specific Gadget Chains

Typical exploit chain patterns (5 types)

No.	Chain	Final effect	Typical coefficient
1	Actuator information disclosure → key extraction → forge JWT → administrator privilege escalation → RCE	Critical	0.8
2	Shiro RememberMe default key → deserialization → RCE	Critical	1.0
3	File read (path traversal) → configuration disclosure (DB credentials) → SQL injection file write → WebShell	Critical	0.8
4	SSRF → intranet service probing → unauthorized Redis → write crontab → reverse Shell	High	0.6
5	SpEL injection → RCE (single-point chain, strict conditions require verifying the EvaluationContext type)	Critical	0.8

For the preconditions, complete steps, evidence requirements, and fallback plans of each chain, see chain-patterns.md。

Chain feasibility verification checklist

• The preconditions of each step have been satisfied by the output of the previous step (the data flow can connect)
• Network reachability has been confirmed (firewalls/ACLs/security groups do not block the network requests in the chain)
• Runtime environment constraints have been evaluated (JDK version, whether SecurityManager is enabled, container sandbox restrictions)
• The restrictions of the JDK version on JNDI remote class loading have been considered (8u121+ RMI / 8u191+ LDAP)
• The Gadget Chain used in the chain actually exists in the target classpath and the version matches
• Fallback plans have been noted: whether an alternative path exists when a certain step is infeasible (such as switching to LDAP/local Gadget when RMI is unavailable)
• The overall chain score has been calculated using the 最终效果严重度 x 可行性系数 formula
• The EVID evidence for all steps has been collected completely, with no speculative completion
• The three-step verification of dependency CVE auditing has been completed (version match → code path reachable → attack surface exposed)

Detection checklist

• All vulnerabilities discovered in the P4 phase have been classified by attack phase (INFO/AUTH/EXEC)
• The causal relationships and data flow connections between vulnerabilities have been analyzed
• The Maven/Gradle dependency tree has been extracted and cross-referenced with NVD/GitHub Advisory
• The version ranges of high-frequency dangerous dependencies have been checked one by one
• The available Gadget Chains in the classpath have been scanned and confirmed
• All feasible exploit chains have been recorded according to the template (preconditions / steps / EVID / score)
• The feasibility coefficient of each chain has been reasonably assigned based on environmental constraints
• Infeasible chains have been annotated with reasons and fallback plans
• The severity score is consistent with the pipeline