Una vulnerabilità estremamente grave è stata recentemente scoperta in Veeam Backup & Replication, una delle soluzioni di backup più utilizzate in ambienti enterprise e non.. Se sfruttata, consente a un utente autenticato su Active Directory di eseguire codice arbitrario da remoto con privilegi SYSTEM, mettendo potenzialmente a rischio l’intera infrastruttura IT.

La vulnerabilità è tracciata come CVE-2025-23121, ha ricevuto un punteggio CVSS 9.9 (quasi massimo) ed è stata emessa diverso tempo fa, la quale colpisce tutte le versioni precedenti alla 12.3.1. Tale vulnerabilità è stata risolta con la versione 12.3.2, rilasciata da Veeam ma ancora molti apparati risultano privi di patch esponendoli a potenziali compromissioni.

Dettagli tecnici della vulnerabilità (CVE-2025-23121)

• Componente vulnerabile: backend RPC/API interne di Veeam
• Condizione necessaria: autenticazione su Active Directory con un account standard di dominio
• Vettore di attacco: invio di richieste appositamente costruite ai servizi interni di Veeam, sfruttando autorizzazioni mal configurate (es. tramite pipe nominate, API locali, gRPC)
• Impatto potenziale: Esecuzione di comandi arbitrari con privilegi SYSTEM, manipolazione dei job di backup, accesso non autorizzato a repository e snapshot, movimentazione laterale in ambienti AD

Scoperta e contesto

La vulnerabilità è stata identificata dai ricercatori di CodeWhite e watchTowr, già noti per le loro analisi avanzate sui prodotti enterprise. Secondo il report, il bug è strettamente collegato — o addirittura derivato — da una falla precedente, la CVE-2025-23120, chiusa a marzo 2025 ma aggirabile da un attaccante esperto.

Sebbene al momento non esistano PoC pubblici, la probabilità di un exploit in-the-wild è concreta. Le vulnerabilità Veeam sono storicamente molto ambite, come dimostrato dalla CVE-2023-27532, poi inclusa in tool offensivi privati usati da gruppi ransomware.

Altre vulnerabilità risolte nella versione 12.3.2

CVE-2025-23120 — Privilege Escalation da Backup Operator (CVSS 6.1)
Consente a un utente con ruolo “Backup Operator” di modificare job esistenti, impostare script post-job o destinazioni alterate, inducendo il server a eseguire codice arbitrario con privilegi elevati.

Scenario d’attacco:
1. L’attaccante crea o modifica un job inserendo un payload.
2. Il job viene eseguito da un servizio Veeam che gira come SYSTEM.
3. Il codice viene eseguito con privilegi amministrativi → escalation locale.

CVE-2025-2428 — Scrittura arbitraria su directory Veeam
A causa di permessi NTFS errati, un utente locale non admin può scrivere su directory monitorate da processi elevati, abilitando tecniche come DLL hijacking.

Tecnica sfruttabile:
– Un attaccante piazza una DLL malevola in una directory Veeam.
– Il processo SYSTEM carica la DLL all’avvio.
– L’attaccante ottiene esecuzione privilegiata e persistenza.

Implicazioni per la sicurezza aziendale

I server Veeam rappresentano obiettivi ad alto valore per gli attaccanti, poiché:
– Operano con privilegi SYSTEM
– Accedono a volumi di rete, NAS, repository cloud e host VM
– Gestiscono credenziali critiche per workload e backup
– Sono fondamentali nei piani di continuità operativa

Una compromissione di Veeam può:
– Rendere invisibile l’attacco usando snapshot o backup alterati
– Distruggere copie di backup o disattivarne l’esecuzione
– Abilitare ransomware su larga scala
– Consentire persistence anche dopo la rimozione del malware

Raccomandazioni operative

Aggiornamento urgente
– Installare Veeam Backup & Replication 12.3.2 su tutti i server e agent
– Testare l’update in ambiente di staging prima della distribuzione in produzione

Controllo degli accessi
– Rivedere i ruoli assegnati (in particolare “Backup Operator”)
– Limitare l’accesso al server Veeam a utenti e amministratori autorizzati
– Rimuovere o disabilitare account inutilizzati o obsoleti

Audit e hardening
– Analizzare i permessi NTFS delle directory Veeam
– Isolare il server backup in una VLAN dedicata
– Monitorare le richieste RPC e i processi Veeam con strumenti EDR

Protezione dei backup
– Verificare che esistano copie replicate offsite o in cloud
– Usare repository con WORM (Write Once Read Many)
– Validare che le credenziali nei job siano aggiornate e cifrate

Conclusioni

La CVE-2025-23121 rappresenta una minaccia critica per qualsiasi organizzazione che utilizzi Veeam in produzione. La sua combinazione di RCE, escalation e accesso privilegiato ai dati la rende un vettore ideale per attacchi mirati, ransomware e compromissioni su larga scala. L’aggiornamento a Veeam 12.3.2 è pertanto urgente e deve essere affiancato da una revisione completa della postura di sicurezza legata al backup.

L'articolo Vulnerabilità critiche in Veeam Backup! Un rischio di compromissione totale dei sistemi proviene da il blog della sicurezza informatica.

Un tag mancante su di un campo input di una api key può rappresentare un rischio?

Avrai sicuramente notato che il browser suggerisce i dati dopo aver compilato un form. L’autocompletamento è proprio la funzione di ricordare le cose che inseriamo.

Per impostazione predefinita, i browser ricordano le informazioni inserite dall’utente nei campi dei siti web. Questo consente loro di eseguire questi automatismi.

Come può rappresentare un pericolo?

Esaminiamo il Plugin di CloudFlare per WordPress:

In questo esempio prendiamo in analisi un plugin di CloudFlare, che permette di collegare un sito WordPress con un’istanza cloudflare.

Questo permette di eseguire varie attività come la pulizia della cache, molte volte utile dopo un aggiornamento del sito.

github.com/cloudflare/Cloudfla…

Una volta installato, nella configurazione è richiesto di inserire una mail e un api key.

L’api key è una stringa che viene generata. Ad essa possono essere assegnati una serie di permessi.

La webapp poi con quel codice potrà interfacciarsi con CloudFlare per eseguire diverse azioni, come detto prima per esempio lo svuotamento della cache.

Vediamo cosa succedere se in passato avevamo già inserito un apikey.

Il modulo ricorda la nostra apikey, ecco semplicemente spiegato la funzione di autocompletamento.

Cosa succede in realtà quando il browser salva queste informazioni?

Ogni browser dispone di un file locale, dove salva queste informazioni di autocompletamento.

In chrome, per esempio, questi dati sono salvati in un file a questo percorso:

C:\Users[user]\AppData\Local\Google\Chrome\User Data\Default\Web Data

Aprendo infatti il file è possibile riconoscere la chiave appena inserita nel form.

Perchè questo allora potrebbe rappresentare un rischio?

Questa chiave API può essere rubata se il sistema dell’utente è compromesso ed il file sottratto.

Questo è solo un esempio, in questi campi come detto prima potrebbe contenere anche per esempio dati di carte di credito e altro ancora.

Possiamo vedere che in questi rapporti di analisi di vari infostealer, proprio l’autocompletamento è uno degli obiettivi.

Leggendo alcuni report di SonicWall e Avira vediamo che molti di questi infostealer hanno come obiettivo questi file.

sonicwall.com/blog/infostealer…

Molto spesso gli infostealer vanno alla ricerca di questi file da infiltrare dal sistema attaccato.

[strong]Altre evidenze in questo rapporto di Avira:[/strong]

avira.com/en/blog/fake-office-…

In entrambi i report si vede chiaramente che questi file sono interessanti per gli infostealer.

Infine più a fondo e addirittura addentrarci su IntelX, per una ulteriore verifica a un vero leak..

Come mitigare questo rischio?

Gli input,come le password,non vengono salvate dai browser (più precisamente viene utilizzato invece il portachiavi del browser)

Nel caso invece delle apikey si utlizzi un input semplice, è possibile inserire un tag autocomplete-off, per informare il browser che questo dato non deve essere inserito nel file autocomplete.

es.

Username:

Password:

Login

Oppure

L’impostazione autocomplete=”off”sui campi ha due effetti:

Indica al browser di non salvare i dati immessi dall’utente per il completamento automatico successivo in moduli simili (alcuni browser fanno eccezioni per casi speciali, ad esempio chiedendo agli utenti di salvare le password).

Impedisce al browser di memorizzare nella cache i dati del modulo nella cronologia della sessione. Quando i dati del modulo vengono memorizzati nella cache della cronologia della sessione, le informazioni inserite dall’utente vengono visualizzate nel caso in cui l’utente abbia inviato il modulo e abbia cliccato sul pulsante Indietro per tornare alla pagina originale del modulo.

Analizzando infatti il codice html, non è presente questo tag per la api key.

Conclusioni

La maggior parte dei browser dispone di una funzionalità per ricordare i dati immessi nei moduli HTML.

Queste funzionalità sono solitamente abilitate di default, ma possono rappresentare un problema per gli utenti, quindi i browser possono anche disattivare.

Tuttavia, alcuni dati inviati nei moduli non sono utili al di là dell’interazione corrente (ad esempio, un PIN monouso) o contengono informazioni sensibili (ad esempio, un identificativo governativo univoco o un codice di sicurezza della carta di credito) oppure un token di un api.

I dati di autocompletamento archiviati dai vari browser possono essere catturati da un utente malintenzionato.

Inoltre, un attaccante che rilevi una vulnerabilità distinta dell’applicazione, come il cross-site scripting, potrebbe essere in grado di sfruttarla per recuperare le credenziali archiviate dal browser. JavaScript non può accedere direttamente ai dati dell’autofill del browser per motivi di sicurezza e privacy tuttavia Autofill può riempire i campi HTML automaticamente, e JavaScript può leggere i valori di quei campi solo dopo che sono stati riempiti.
const email = document.querySelector('#email').value;
console.log(email); // Se il browser ha già riempito il campo, questo valore sarà accessibile
Nonostante ciò esiste la possibilità che la mancata disabilitazione del completamento automatico possa causare problemi nell’ottenimento della conformità PCI (PortSwigger).

L'articolo CloudFlare, WordPress e l’API key in pericolo per colpa di un innocente autocomplete proviene da il blog della sicurezza informatica.

The aerospike engine holds great promise for spaceflight, but for various reasons, has remained slightly out of reach for decades. But thanks to Leap 71, the technology has moved one step closer to a spacecraft near you with the test fire of their generatively-designed, 3D printed aerospike.

We reported on the original design process of the engine, but at the time it hadn’t been given a chance to burn its liquid oxygen and kerosene fuel. The special sauce was the application of a computational physics model to tackle the complex issue of keeping the engine components cool enough to function while directing 3,500˚C exhaust around the eponymous spike.

Printed via a powder bed process out of CuCrZr, cleaned, heat treated, and then prepped by the University of Sheffield’s Race 2 Space Team, the rocket produced 5,000 Newtons (1,100 lbf) of thrust during its test fire. For comparison, VentureStar, the ill-fated aerospike single stage to orbit project from the 1990s, was projected to produce more than 1,917 kilonewtons (431,000 lbf) from each of its seven RS-2200 engines. Leap 71 obviously has some scaling up to do before this can propel any crewed spacecraft.

If you want to build your own aerospike or 3D printed rocket nozzles we encourage you to read, understand, and follow all relevant safety guidelines when handling your rockets. It is rocket science, after all!

hackaday.com/2025/07/10/genera…

Mentre alcuni dibattono sui potenziali rischi dell’intelligenza artificiale, altri la stanno integrando con fiducia nella vita di tutti i giorni. L’azienda americana Realbotix , specializzata nello sviluppo di robot umanoidi, ha presentato un importante aggiornamento: ora il suo umanoide parla fluentemente 15 lingue e ne comprende altre 147, grazie a un sistema di elaborazione vocale basato su cloud.

Questa tecnologia è concepita come un ponte tra macchine e persone. Un robot in grado di parlare la lingua madre dell’utente non è solo comodo, ma crea anche l’illusione di una comunicazione reale. Questa caratteristica è particolarmente rilevante per i settori in cui l’empatia e il contatto personale sono fondamentali: turismo, hotel, sanità, musei e persino parchi di divertimento.

Realbotix sottolinea che il multilinguismo permette di stabilire contatti con persone di culture e professioni diverse. La barriera linguistica rimane uno dei principali ostacoli al servizio, e un assistente universale che parla giapponese, arabo, francese, hindi e decine di altre lingue può sostituire decine di specialisti, senza bisogno di riqualificazione né di sostituzioni di personale .La paranoia digitale è il nuovo buon senso.

Un’altra importante innovazione è la possibilità di connettersi a piattaforme di intelligenza artificiale di terze parti. Grazie a questa, lo stesso robot può svolgere ruoli diversi e cimentarsi in centinaia di professioni. Basta semplicemente cambiare lo scenario del software.

Esternamente, l’androide ha un aspetto quasi umano: pelle, espressioni facciali, movimenti realistici. Il suo compito non è solo quello di fornire informazioni, ma di stabilire una sorta di contatto con la persona. In una clinica, ad esempio, può incontrare un paziente, porre domande, coglierne lo stato emotivo e trasmettere i dati al medico, risparmiando tempo e riducendo il carico di lavoro degli infermieri.

In spazi pubblici come hotel, terminal e centri informazioni, un umanoide può sostituire un banco informazioni: spiegare dove si trova l’uscita o il banco del check-in, nel linguaggio giusto e con indicazioni visive. E tutto questo senza affaticamento, errori o cattivo umore.

Gli sviluppatori sottolineano: l’obiettivo non è quello di sostituire le persone, ma di rendere la vita nella società il più confortevole possibile. I robot umanoidi possono compensare la carenza di personale e fornire un livello di servizio stabile. La filosofia di Realbotix è quella di creare tecnologie che rendano l’interazione più calorosa, non più fredda.

Secondo i dati di Research and Markets pubblicati da EE News Europe, il mercato globale dei robot umanoidi crescerà da 2,93 miliardi di dollari nel 2025 a 243,4 miliardi di dollari entro il 2035. Le ragioni di ciò sono la carenza di manodopera, la crescente domanda di automazione e la crescente richiesta di assistenza clienti.

Il costo di un dispositivo di questo tipo varia dai 20.000 ai 175.000 dollari, a seconda delle funzioni. Si tratta di un costo inferiore a quello di molti anni di stipendio nelle grandi città, e il dispositivo non chiederà mai ferie o malattia nel momento più critico.

L'articolo Sorride, parla 15 lingue e non ti risponderà mai ci sentiamo domani perché è fatto di plastica proviene da il blog della sicurezza informatica.

Il primo e più bel concerto della mia vita.

Siamo arrivati a S. Siro alle 15:00, io e un mio amico, a bordo della mia Guzzi V 35 II.

Quando hanno aperto i cancelli siamo corsi sotto al palco poi man mano che il tempo passava ci siamo spostati sempre più indietro in cerca di ombra e abbiamo visto il concerto dalle gradinate di S. Siro.

Casino Royale, poi i Ladri di biciclette e poi lui, Vasco.

Finale indimenticabile, Albachiara, gli accendini accesi, S. Siro è diventato un braciere.

Poi l'organizzazione ha fatto arrivare alle prime file dei dischi di stoffa tipo frisbee, centinaia, la gente ha cominciato a tirarli e lo stadio si è riempito di dischi volanti.

#vasco #SanSiro