
CVE-2024-4577 RCE PoC
Durante l'implementazione di PHP, il team non ha notato la funzionalità Best-Fit della conversione di codifica all'interno del sistema operativo Windows. Questa svista consente a utenti non autenticati di bypassare la protezione precedente di CVE-2012-1823 tramite sequenze di caratteri specifiche. Un codice arbitrario può essere eseguito su server PHP remoti tramite l'attacco di injection di argomenti.
Questa PoC è solo a scopo di apprendimento e ricerca. Non utilizzarla per attività illegali; sei l'unico responsabile di eventuali conseguenze legali.
Questa vulnerabilità è stata scoperta da Orange Tsai (@orange_8361) di DEVCORE (@d3vc0r3). Assicurati di seguire la sua eccezionale ricerca; il nostro ruolo è stato solo quello di ricreare e sviluppare l'exploit per questo problema.
Perché è necessario riscrivere lo script exploit quando ci sono già molte PoC disponibili pubblicamente online?
Poiché molte PoC disponibili pubblicamente si basano sullo stesso exploit originale, molti vendor hanno utilizzato queste PoC come riferimento e hanno bloccato determinate parole chiave per impedirne lo sfruttamento. Tuttavia, spesso trascurano di bloccare tutti i potenziali vettori di exploit. Per risolvere questo problema, lo script include un semplice meccanismo per generare parametri casuali, oltre a diversi metodi di sfruttamento da LFI a RCE, per aumentare il tasso di successo dell'iniezione PHP CGI che porta a RCE.
Durante un test in cui cercavo di riprodurre una vulnerabilità ambientale, ho scoperto che la mia PoC generava costantemente un errore HTTP 500, indipendentemente dagli aggiustamenti. Poiché lavoravo in un ambiente vulnerabile, ho iniziato a indagare sulla causa dell'errore. Poi ho ricordato un articolo di Devcore in cui si menzionava che, in alcuni scenari di exploit, il server restituiva un errore HTTP 500, anche se l'attacco RCE aveva effettivamente successo. Con questo in mente, ho deciso di testare se potessi eseguire calc.exe localmente e, con mia sorpresa, ha funzionato: era una RCE cieca!
Tuttavia, quando ho controllato il log degli errori di Apache, ho trovato un errore che faceva riferimento a allow_url_include, nonostante l'attacco fosse stato eseguito con successo (e non comprendo ancora appieno la causa principale; se hai intuizioni, contattami). Questo mi ha portato a creare un exploit che include anche un'opzione per testare la RCE cieca😊.
Se il tuo target è una versione del sistema operativo precedente a Windows 7, puoi comunque passare a una RCE visibile o a una reverse shell tramite altri metodi. Tuttavia, queste tecniche esulano dallo scopo di questo articolo, quindi non entreremo nei dettagli. Come penetration tester o specialista red team, dovresti riuscire a trovare soluzioni alternative abbastanza rapidamente, il che può essere un processo interessante😉.
Aggiornato il 15 novembre 2024
A causa di esigenze lavorative, ho continuato a migliorare lo script per renderlo il più compatibile possibile con tutti gli ambienti e massimizzare le possibilità di ottenere RCE. Questo sforzo è stato motivato dal fatto che alcuni target non riuscivano a eseguire PHP con successo utilizzando molte PoC pubbliche. Alla fine, ho risolto inaspettatamente il problema, riuscendo a superare quasi tutti i casi di errore 500 e a visualizzare con successo i risultati dell'esecuzione di PHP. Di conseguenza, la RCE cieca non sembrava più così critica. 😧
Condizioni di sfruttamento
È necessario installare le dipendenze:
$ python3 -m pip install requests Esegui lo script direttamente per ottenere le istruzioni. Puoi eseguire il comando seguente per verificare se il target è vulnerabile.
$ python3 CVE-2024-4577.py <target> <php shell>

Se l'exploit esiste sul target, puoi salvare localmente i risultati dell'esecuzione PHP, utile per chi ha bisogno di visualizzare phpinfo.
$ python3 CVE-2024-4577.py <target> "phpinfo()" --save info.html

Quando il target è vulnerabile alla RCE cieca, lo script tenterà di mettersi in ascolto su una porta locale e farà in modo che il server target esegua PHP, inviando una richiesta per verificare l'esistenza dell'exploit. Quando la richiesta viene ricevuta, indica che il server target ha eseguito con successo il comando.
