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.
 Avvio delle iscrizioni al corso Cyber Offensive Fundamentals Vuoi smettere di guardare tutorial e iniziare a capire davvero come funziona la sicurezza informatica? La base della sicurezza informatica, al di là di norme e tecnologie, ha sempre un unico obiettivo: fermare gli attacchi dei criminali informatici. Pertanto "Pensa come un attaccante, agisci come un difensore". Ti porteremo nel mondo dell'ethical hacking e del penetration test come nessuno ha mai fatto prima. Per informazioni potete accedere alla pagina del corso oppure contattarci tramite WhatsApp al numero 379 163 8765 oppure scrivendoci alla casella di posta [email protected].
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.
Ti è piaciuto questo articolo? Ne stiamo discutendo nella nostra Community su LinkedIn, Facebook e Instagram. Seguici anche su Google News, per ricevere aggiornamenti quotidiani sulla sicurezza informatica o Scrivici se desideri segnalarci notizie, approfondimenti o contributi da pubblicare.
Vulnerabilità
Cultura
Cyberpolitica
Cybercrime
Cybercrime