Vulnerabilità in .NET: eseguire codice remoto tramite messaggi SOAP

Redazione RHC : 14 Dicembre 2025 08:26

I ricercatori di sicurezza hanno scoperto una vulnerabilità in .NET che potrebbe colpire diversi prodotti aziendali e causare l’esecuzione di codice remoto. Il problema deriva dal modo in cui le applicazioni Microsoft basate su .NET gestiscono i messaggi SOAP e Microsoft, secondo i ricercatori, si rifiuta di risolvere il problema, scaricando la colpa su sviluppatori e utenti.

Piotr Bazydło di watchTowr ha segnalato la scoperta alla conferenza Black Hat Europe . Ha affermato che diverse soluzioni commerciali e interne sono vulnerabili agli attacchi di esecuzione di codice remoto ( RCE ) a causa di errori nella gestione dei messaggi SOAP nelle applicazioni .NET.

Il problema chiave era la classe SoapHttpClientProtocol. Il ricercatore ha spiegato che può essere utilizzata dagli aggressori in vari modi, a seconda dei loro obiettivi. Questa classe eredita da HttpWebClientProtocol, come altri client proxy, ma SoapHttpClientProtocol è la più comune nel codice sorgente, quindi watchTowr si è concentrato su di essa.

Christmas Sale -40% 𝗖𝗵𝗿𝗶𝘀𝘁𝗺𝗮𝘀 𝗦𝗮𝗹𝗲! Sconto del 𝟰𝟬% 𝘀𝘂𝗹 𝗽𝗿𝗲𝘇𝘇𝗼 𝗱𝗶 𝗰𝗼𝗽𝗲𝗿𝘁𝗶𝗻𝗮 del Corso "Dark Web & Cyber Threat Intelligence" in modalità E-Learning sulla nostra Academy!🚀 Fino al 𝟯𝟭 𝗱𝗶 𝗗𝗶𝗰𝗲𝗺𝗯𝗿𝗲, prezzi pazzi alla Red Hot Cyber Academy. 𝗧𝘂𝘁𝘁𝗶 𝗶 𝗰𝗼𝗿𝘀𝗶 𝘀𝗰𝗼𝗻𝘁𝗮𝘁𝗶 𝗱𝗲𝗹 𝟰𝟬% 𝘀𝘂𝗹 𝗽𝗿𝗲𝘇𝘇𝗼 𝗱𝗶 𝗰𝗼𝗽𝗲𝗿𝘁𝗶𝗻𝗮. Per beneficiare della promo sconto Christmas Sale, scrivici ad [email protected] o contattaci su Whatsapp al numero di telefono: 379 163 8765. Supporta Red Hot Cyber attraverso:  L'acquisto del fumetto sul Cybersecurity Awareness Ascoltando i nostri Podcast Seguendo RHC su WhatsApp Seguendo RHC su Telegram Scarica gratuitamente “Byte The Silence”, il fumetto sul Cyberbullismo di Red Hot Cyber Se ti piacciono le novità e gli articoli riportati su di Red Hot Cyber, iscriviti immediatamente alla newsletter settimanale per non perdere nessun articolo. La newsletter generalmente viene inviata ai nostri lettori ad inizio settimana, indicativamente di lunedì.

Sulla carta, tutto sembra innocuo: sia il nome della classe che la documentazione ufficiale indicano che dovrebbe gestire messaggi SOAP tramite HTTP. Uno scenario “semplice, prevedibile e sicuro” , come osserva ironicamente Bazydło. In pratica, le cose sono più complicate.

La classe è responsabile dell’impostazione dell’URL di destinazione del servizio SOAP e dell’invocazione del metodo SOAP. La vulnerabilità si verifica quando un aggressore riesce a influenzare questo URL e il modo in cui SoapHttpClientProtocol crea il client. Sebbene sia progettata per funzionare con richieste HTTP, utilizza internamente un meccanismo generalizzato che supporta più protocolli: HTTP/HTTPS, FTP e persino FILE.

Se un aggressore sostituisce l’indirizzo web con un URL del file system, la classe non genererà un errore, ma scriverà semplicemente la richiesta SOAP (inviata tramite il metodo POST) direttamente nel file. “Perché un proxy SOAP dovrebbe ‘inviare’ richieste a un file locale? Nessuna persona sana di mente si aspetterebbe di ricevere una risposta SOAP valida dal file system“, osserva il ricercatore.

Questo comportamento può essere sfruttato per scrivere file arbitrari, inclusi dati XML da una richiesta SOAP. Uno scenario meno distruttivo, ma comunque spiacevole, potrebbe riguardare attacchi di relay NTLM.

Bazydło ha inizialmente segnalato il problema a Microsoft tramite la Zero Day Initiative (ZDI). Secondo lui, l’azienda ha risposto che non avrebbe risolto il bug perché gli sviluppatori non dovrebbero consentire l’utilizzo di dati di input non attendibili.

“Come prevedibile, Microsoft ha considerato questa una ‘funzionalità’ piuttosto che una vulnerabilità “, scrive. “La risposta ha attribuito la colpa agli sviluppatori e agli utenti. Secondo Microsoft, l’URL passato a SoapHttpClientProtocol non dovrebbe mai essere controllato dall’utente e la convalida dell’input è interamente responsabilità dello sviluppatore.”

Bazydło aggiunge sarcasticamente che, ovviamente, “tutti gli sviluppatori decompilano regolarmente gli assembly .NET Framework e studiano l’implementazione interna, ben sapendo che un ‘proxy client HTTP’ può essere convinto a scrivere dati su disco. Come potrebbe essere altrimenti? “

Un anno dopo, il team di watchTowr ha iniziato ad analizzare Barracuda Service Center , una “piattaforma RMM ampiamente utilizzata”, anch’essa risultata vulnerabile alla tecnica descritta in precedenza. I ricercatori hanno scoperto che la sua API SOAP poteva essere chiamata senza autenticazione e hanno quindi trovato una via di exploit alternativa: importando file WSDL (Web Services Description Language).

Il punto chiave è che un aggressore può fornire a un’applicazione un URL che punta a un file WSDL sotto il suo controllo. L’applicazione vulnerabile utilizza questa descrizione per generare un proxy client HTTP, dopodiché Bazydło è riuscito a ottenere l’esecuzione di codice remoto in due modi: caricando una web shell ASPX sul server e inserendo il payload (una web shell CSHTML o uno script PowerShell) nello spazio dei nomi del corpo della richiesta SOAP.

Questa tecnica basata sullo spazio dei nomi, afferma, ha consentito lo sfruttamento efficace di Ivanti Endpoint Manager e Umbraco 8 CMS. Sebbene il rapporto di WatchTowr menzioni specificamente questi prodotti, i ricercatori sottolineano che l’elenco effettivo delle soluzioni interessate è molto più ampio.

Redazione
La redazione di Red Hot Cyber è composta da un insieme di persone fisiche e fonti anonime che collaborano attivamente fornendo informazioni in anteprima e news sulla sicurezza informatica e sull'informatica in generale.

Lista degli articoli