Laboratorio di Ricerca CVE-2025-53770

Questo repository sembra essere un progetto di ricerca proof-of-concept per validare un problema di deserializzazione e di elaborazione del riquadro strumenti (tool-pane) in stile SharePoint in un laboratorio controllato. Include un driver Python, un'applicazione vulnerabile simulata e asset container per test isolati.

[!WARNING] Questo progetto deve essere utilizzato esclusivamente su sistemi, container o reti di tua proprietà o per i quali hai esplicita autorizzazione ai test. Non eseguire questo codice contro infrastrutture pubbliche, servizi di terze parti, ambienti di produzione o qualsiasi target senza autorizzazione scritta. I test di sicurezza non autorizzati possono violare leggi, contratti, policy o termini di utilizzo accettabile.

I contenuti di questo repository devono essere trattati come materiale sensibile di ricerca sulla sicurezza. Se utilizzi questo progetto per attività di assessment, mantieni l'esecuzione isolata, registra tutte le attività e coordina la verifica con il proprietario del sistema prima di testare.

Ambito del Progetto

Il repository contiene attualmente:

• sploit.py: driver Python asincrono che invia richieste appositamente costruite a un endpoint ToolPane.
• lab/mock_vulnerable_app.cs: applicazione ASP.NET simulata che riflette un marcatore di validazione e, nella sua forma attuale, può eseguire un comando fornito all'interno del container di laboratorio.
• lab/docker-compose.yml: laboratorio locale a due container che separa il target simulato dal terminale dell'attaccante.
• lab/Dockerfile: build .NET multi-stage che pubblica l'applicazione vulnerabile simulata in un'immagine runtime ASP.NET più piccola e la esegue come utente non root.
• lab/attacker.Dockerfile: definizione del container attaccante Python che preinstalla il set di dipendenze dello script necessario per il terminale di laboratorio.
• lab/vulnerable.csproj: file di progetto web .NET 6 per l'applicazione vulnerabile simulata.
• lab/genGadget.py: script ausiliario per generare un payload Base64 compresso per test di deserializzazione solo in laboratorio.

Setup e Utilizzo

Questo flusso di lavoro è pensato esclusivamente per il laboratorio locale.

Prerequisiti:

• Docker Engine con supporto Compose
• Una shell locale con permessi per eseguire comandi Docker

Avvia il laboratorio dalla directory lab/:

cd lab
docker-compose up --build -d

Se la tua configurazione Docker richiede privilegi elevati, esegui gli stessi comandi con sudo.

Conferma che entrambi i container siano in esecuzione:

docker-compose ps

Logging in caso di problemi o per la validazione dell'exploit:

docker logs sp_attacker
docker logs sp_vulnerable_lab

Il laboratorio è intenzionalmente isolato:

• il container target gira sulla rete interna lab_net;
• nessuna porta è pubblicata sull'host;
• il container attaccante è fornito come terminale usa e getta all'interno della stessa rete privata.

Apri una shell nel container attaccante:

docker exec -it sp_attacker bash

Dall'interno del container attaccante, puoi eseguire controlli sicuri per il laboratorio, come verificare che il target sia raggiungibile e testare lo script in modalità di verifica contro il target simulato:

python3 sploit.py http://sp_vulnerable_lab/
# Se la risoluzione DNS del nome del servizio fallisce nel tuo ambiente, usa l'IP del lab:
# python3 sploit.py http://10.10.10.5
# Se vuoi andare oltre la validazione base puoi includere i comandi desiderati.
python3 sploit.py http://sp_vulnerable_lab whoami

Comportamento atteso nell'ambiente simulato locale:

• il target dovrebbe essere raggiungibile come http://sharepoint-target dal container attaccante;
• l'applicazione simulata restituisce un marcatore deterministico per la verifica;
• eventuali artefatti di risultato prodotti dallo script rimangono all'interno del workspace del laboratorio montato.

Note operative:

• mantieni il laboratorio scollegato dalle reti esterne e non pubblicare il servizio target sull'host;
• non riutilizzare questo ambiente per assessment di produzione;
• se modifichi l'applicazione simulata o le definizioni dei container, ricostruisci le immagini prima di ritestare.

Pulizia

Ferma e rimuovi i container e la rete del laboratorio:

cd lab
docker-compose down

Se vuoi rimuovere anche le immagini costruite:

docker-compose down --rmi local

Se vuoi un reset completo degli artefatti del workspace di laboratorio, rimuovi gli eventuali file di risultato generati dopo lo spegnimento:

rm -f vuln.lst

Pratica di pulizia consigliata dopo ogni esercizio:

1. spegnere il laboratorio con docker-compose down;
2. rimuovere gli artefatti di risultato che non dovrebbero persistere;
3. ricostruire il laboratorio prima dell'esecuzione successiva se hai modificato codice, dipendenze o impostazioni dei container.

Riepilogo della Validazione

Il progetto è strutturalmente valido come laboratorio di ricerca locale, ma non dovrebbe essere trattato come un validatore sicuro per la produzione nella sua forma attuale.

Cosa funziona:

• La topologia del laboratorio è semplice e riproducibile.
• Il driver Python può testare un singolo target o un elenco di target.
• L'applicazione simulata fornisce indicatori di successo deterministici per la verifica in laboratorio.

Cosa richiede cautela:

• Lo script principale include un comportamento esplicito di esecuzione comandi quando viene fornito un secondo argomento.
• La verifica TLS è disabilitata nelle richieste in uscita.
• I risultati positivi vengono scritti in vuln.lst, il che può creare dati sensibili residui non necessari.
• L'applicazione simulata esegue direttamente l'input di shell e non dovrebbe mai essere esposta al di fuori di un laboratorio isolato.

Metodologia

Usa questo progetto solo per la validazione controllata di rilevamento ed esposizione, non per lo sfruttamento operativo.

Metodologia consigliata:

1. Costruisci un ambiente di laboratorio isolato senza esposizione esterna.
2. Valida i confini di rete in modo che solo il ricercatore possa raggiungere il servizio simulato.
3. Avvia il target di laboratorio e conferma che l'applicazione risponda all'endpoint previsto.
4. Usa il driver solo in modalità di verifica non distruttiva per confermare se il target riflette il marcatore atteso.
5. Cattura gli artefatti di richiesta e risposta per la documentazione, poi distruggi l'ambiente di laboratorio dopo il test.

Per il lavoro di assessment nel mondo reale, lo standard più sicuro è sostituire la validazione di tipo exploit con uno o più dei seguenti:

• verifica della versione e del livello di patch;
• revisione autenticata della configurazione;
• analisi dei log a livello web;
• revisione della telemetria EDR, SIEM e WAF;
• indicatori di compromissione e health check forniti dal vendor.

Impatto

Se un target è realmente vulnerabile a una falla di deserializzazione in un componente applicativo privilegiato, l'impatto potenziale può essere grave:

• esecuzione remota di codice nel contesto di sicurezza del servizio interessato;
• perdita di riservatezza per dati applicativi, credenziali e segreti;
• perdita di integrità tramite manomissione di contenuti o configurazione;
• degrado della disponibilità a causa di comandi distruttivi o azioni successive;
• opportunità di movimento laterale se l'host dispone di ampi privilegi di rete o identità.

Anche in un laboratorio, la semantica di esecuzione dei comandi aumenta significativamente il rischio perché normalizza flussi di lavoro che dovrebbero essere riservati a indagini strettamente controllate e autorizzate.

Mitigazioni