If you’re into Macs, you’ll always remember your first. Maybe it was the revolutionary classic of 1984 fame, perhaps it was the adorable G3 iMac in 1998, or even a shiny OS X machine in the 21st century. Whichever it is, you’ll find it emulated in [Marcin Wichary]’s essay “Frame of preference: A history of Mac settings, 1984–2004” — an exploration of the control panel and its history.
That’s not a photograph, it’s an emulator. (At least on the page. Here, it’s a screenshot.)
[Marcin] is a UI designer as well as an engineer and tech historian, and his UI chops come out in full force, commenting and critiquing Curputino’s coercions. The writing is excellent, as you’d expect from the man who wrote the book on keyboards, and it provides a fascinating look at the world of retrocomputing through the eyes of a designer. That design-focused outlook is very apropos for Apple in particular. (And NeXT, of course, because you can’t tell the story of Apple without it.)

There are ten emulators on the page, provided by [Mihai Parparita] of Infinite Mac. It’s like a virtual museum with a particularly knowledgeable tour guide — and it’s a blast, getting to feel hands-on, the design changes being discussed. There’s a certain amount of gamification, with each system having suggested tasks and a completion score when you finish reading. There are even Easter eggs.

This is everything we wish the modern web was like: the passionate deep-dives of personal sites on the Old Web, but enhanced and enabled by modern technology. If you’re missing those vintage Mac days and don’t want to explore them in browser, you can 3D print your own full-size replica, or a doll-sized picoMac.

hackaday.com/2025/07/10/an-emu…

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.

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