demining/pixnapping-attack-on-android# Attacco Pixnapping: compromettere chiavi private e seed phrase attraverso la vulnerabilità CVE-2025-48561 rappresenta una nuova minaccia critica per la rete Bitcoin e l'infrastruttura Android
Questo articolo esamina l'evoluzione delle minacce alla sicurezza nel settore dello stoccaggio delle criptovalute, concentrandosi sui metodi moderni per compromettere chiavi private e frasi seed, che proteggono i portafogli digitali. L'ecosistema moderno delle criptovalute affronta una minaccia crescente di attacchi informatici volti a compromettere chiavi private e frasi seed, che costituiscono il fondamento della sicurezza dei portafogli digitali. La complessità e la sofisticazione degli attacchi, che sfruttano non solo il software ma anche l'hardware dei moderni dispositivi mobili, aumenta ogni anno. Oltre alle minacce tradizionali come il dirottamento degli appunti, il keylogging, lo spoofing dei codici QR e lo sfruttamento delle vulnerabilità nelle implementazioni dei portafogli BIP32/BIP39, i ricercatori identificano sempre più spesso nuovi modi per compromettere i dati crittografici memorizzati sugli smartphone.
All'inizio di ottobre 2025, i ricercatori della Carnegie Mellon University e di diverse università americane hanno presentato i risultati di uno studio che ha suscitato scalpore nelle comunità scientifiche e crittografiche. Hanno scoperto una vulnerabilità critica nel sistema operativo Android, soprannominata "Pixnapping" e registrata con l'identificativo CVE-2025-48561. Questa vulnerabilità consente agli aggressori di ricostruire passo dopo passo il contenuto dello schermo dei dispositivi Android, estraendo così informazioni visive sensibili, tra cui chiavi private, frasi seed e codici di autenticazione 2FA monouso da app come Google Authenticator.
La minaccia identificata dai ricercatori si basa sulla profonda interazione tra i livelli software e hardware di Android, dalle API di sistema al motore di compressione grafica della GPU. Pixnapping combina le tecniche del canale laterale GPU.zip con l'uso legittimo degli Android Intents e dell'API di sfocatura delle finestre, consentendo una ricostruzione pixel per pixel nascosta dello schermo. Questo approccio trasforma uno smartphone standard in una fonte di potenziale perdita di informazioni chiave utilizzate per gestire asset digitali, tra cui Bitcoin (BTC), Ethereum (ETH), Litecoin (LTC), XRP e altre criptovalute.
Il pericolo risiede nel fatto che l'utente non deve concedere all'aggressore alcuna autorizzazione: l'app dannosa può essere eseguita in background, rimanendo invisibile al sistema di sicurezza di Android. Di conseguenza, l'aggressore può ottenere accesso visivo alle frasi seed durante i backup o i prelievi dei portafogli, il che equivale di fatto al controllo completo degli asset crittografici della vittima.
La combinazione di tali minacce, dagli attacchi Pixnapping alle perdite hardware tramite Rowhammer, Spectre, Meltdown e altri metodi di canale laterale correlati, evidenzia la necessità di ripensare le strategie di sicurezza all'intersezione tra sistemi operativi mobili e tecnologie finanziarie. Ogni nuova vulnerabilità come CVE-2025-48561 dimostra quanto possa essere fragile l'equilibrio tra la comodità dell'accesso mobile alle criptovalute e la garanzia di una sicurezza crittografica fondamentale.
La transazione decodificata 816760531f334651d711909a93a5959e74b3dbe126f50dbb6efb3e7d61f224ba rappresenta una prova documentata del lavoro di ricerca, registrata nel registro immutabile della blockchain di Bitcoin. Un'analisi strutturale di RawTX rivela l'architettura classica di una transazione Bitcoin versione 1, contenente un elemento critico: il campo OP_RETURN con un URL incorporato che punta alla ricerca sull'attacco Pixnapping.
https://github.com/zoeir/Bitcoin-Message-Transaction
Scomposizione della struttura della transazione:
La transazione utilizza un singolo input (UTXO) dalla transazione precedente e crea tre output: il primo output, con valore zero, contiene il messaggio OP_RETURN (77 byte di dati), il secondo output trasferisce 1000 satoshi (0.00001 BTC) all'indirizzo del destinatario 12ib7dApVFvg82TXKycWBNpN8kFyiAN1dr , e il terzo output restituisce il resto di 22.500 satoshi all'indirizzo del mittente 1G84gkhBsBM9B5Xsqw2s9b6H1oqg4nPEiW . La commissione di transazione è di 1000 satoshi, il che garantisce l'elaborazione prioritaria da parte dei miner della rete.
010000000147ac1bf5cff92293f1244c141103dd1ec46ce260f117a8f8df00e6ad0cd4d15a000000008a47304402204f0c3c52b5941993d92e85bda70f93d15b76ad3af6ceab4a1bbb9b33f5432f38022079458bd4071e7c9ab7a3a9d6872083218becb935dbe8eba7862cc30d59db1da10141049a296066ca26625e22c5759a0ed00120e0183b52454b4e6155cd3855bd689f5231497de3552b9a7b976933a803b76632f6f2ac1134acf9af248e697d19a15abbffffffff0300000000000000004d6a4b7777772e626974636f696e6d6573736167652e72752f536f757263655f436f64652f5069786e617070696e675f41747461636b5f746f5f457874726163745f507269766174655f4b657973e8030000000000001976a91412d5a845f2b212ce0c3bd65a4035881d9219090e88ace4570000000000001976a914a5dfdff9f85277310a40d2978fb7040f7af8ca4b88ac00000000
Firma crittografica e autenticazione:
Il campo ScriptSig di 138 byte contiene una firma ECDSA basata sulla curva secp256k1, che conferma il possesso della chiave privata del mittente. Ciò verifica la legittimità della transazione e previene spese non autorizzate. Il messaggio decodificato in OP_RETURN: " www.bitcoinmessage.ru/Source_Code/Pixnapping_Attack_to_Extract_Private_Keys " funge da marcatore permanente sulla blockchain, collegando la transazione alla ricerca scientifica sulla vulnerabilità critica.
CVE-2025-48561 è una vulnerabilità critica ad alta gravità scoperta da un team di ricerca dell'Università della California Berkeley, UC San Diego, dell'Università di Washington e della Carnegie Mellon University nel febbraio 2025. L'attacco Pixnapping dimostra una violazione fondamentale del modello di sicurezza di Android, consentendo a un'app arbitraria, senza alcuna autorizzazione speciale, di eseguire la ricostruzione bit per bit del contenuto visivo di altre app.
Un diagramma delle tre fasi di un attacco Pixnapping sui dispositivi Android.Pixnapping utilizza una combinazione di API Android e canale laterale hardware GPU (zip) per estrarre informazioni visive dagli schermi dei dispositivi. L'attacco sfrutta tre meccanismi chiave di Android: la capacità di inviare le attività di altre app alla pipeline di rendering tramite Android Intents, l'esecuzione di operazioni grafiche (sfocatura) sui pixel di altre app e la misurazione degli effetti collaterali di queste operazioni, che dipendono dal colore del pixel. cylab.cmu+ 2
Pixnapping si basa sulla vulnerabilità GPU.zip, scoperta dallo stesso gruppo di ricerca nel 2023. Questo attacco sfrutta la compressione dei dati grafici basata su hardware nelle GPU moderne, che è dipendente dai dati, trasparente al software e presente in quasi tutte le GPU moderne. cylab.cmu+ 2
La compressione dei dati grafici è un'ottimizzazione nelle GPU integrate (iGPU) che consente di risparmiare larghezza di banda della memoria e migliorare le prestazioni di rendering dei fotogrammi. L'attacco GPU.zip consente a un sito web dannoso di estrarre pixel dagli iframe nell'ultima versione di Google Chrome, violando il modello di sicurezza del browser. hertzbleed+ 1
Pixnapping sfrutta SurfaceFlinger, un processo di sistema Android responsabile della visualizzazione e della disposizione degli elementi grafici. L'app dannosa utilizza Android Intents per avviare le app target, facendo sì che visualizzino informazioni sensibili sullo schermo. Viene quindi creata una "attività di mascheramento": una sovrapposizione traslucida che nasconde l'app target, lasciando trasparente solo un singolo pixel selezionato. bleepingcomputer+ 1
L'attacco Pixnapping viene eseguito in tre fasi principali, ciascuna delle quali utilizza API Android specifiche e chiamate di sistema: pixnapping+ 1
Fase 1: Invocazione dell'app target:
L'app dannosa utilizza Android Intents per invocare le attività esportate delle app target, come Google Authenticator o Signal. Questo processo fa sì che le informazioni sensibili (codici 2FA, seed) vengano visualizzate sullo schermo e passate alla pipeline di rendering di SurfaceFlinger. bleepingcomputer+ 1
Fase 2: Induzione di operazioni grafiche
: Questa fase crea una pila di attività Android traslucide che utilizzano tecniche di mascheramento, potenziamento e codifica per manipolare i singoli pixel della vittima. L'attacco utilizza l'API di sfocatura delle finestre di Android per eseguire operazioni grafiche sui pixel e i callback VSync per misurare i tempi di rendering con sufficiente precisione per estrarre i singoli valori dei pixel. theregister+ 2
Fase 3: Estrazione tramite canale laterale.
La fase finale utilizza il canale laterale GPU.zip per rubare i pixel elaborati nella fase 2, un pixel alla volta. Misurando le differenze nei tempi di rendering causate da ottimizzazioni GPU dipendenti dal modello, come la compressione dei dati delle immagini, l'attacco può determinare le informazioni sul colore dei pixel. gbhackers+ 1
L'API di sfocatura delle finestre di Android, disponibile da Android 12, fornisce funzionalità per implementare effetti di sfocatura delle finestre. Esistono due tipi di sfocatura delle finestre: sfocatura dello sfondo (crea un effetto vetro smerigliato) e sfocatura dietro (sfoca l'intero schermo dietro la finestra). source.android
Pixnapping abusa di queste API nei seguenti modi:
// Esempio di codice utilizzato nell'attacco (concettuale)
window.setBackgroundBlurRadius(blurRadius);
window.addFlags(WindowManager.LayoutParams.FLAG_BLUR_BEHIND);
WindowManager.LayoutParams.setBlurBehindRadius(blurRadius);
L'attacco crea attività traslucide utilizzando windowIsTranslucent e manipola il canale alfa di un drawable di sfondo per isolare i singoli pixel. source.android
Per misurare con precisione i tempi di rendering, Pixnapping utilizza i callback VSync. VSync (sincronizzazione verticale) è un segnale che sincronizza la frequenza dei fotogrammi con la frequenza di aggiornamento del display. Su Android, questo viene implementato tramite Choreographer.VsyncCallback. blurbusters+ 1
// Esempio concettuale di utilizzo dei callback VSync
Choreographer.getInstance().postVsyncCallback(new Choreographer.VsyncCallback() {
@Override
public void onVsync(long frameTimeNanos) {
// Misurazione del tempo per estrarre il colore del pixel
measureRenderingTime(frameTimeNanos);
}
});
I ricercatori hanno testato Pixnapping su cinque dispositivi con versioni Android 13-16: cylab.cmu+ 1
Risultati dei test della vulnerabilità Pixnapping su vari dispositivi Android
L'attacco è risultato più efficace su Google Pixel 6, con un tasso di successo del 73% per il recupero dei codici 2FA. Il Samsung Galaxy S25 ha dimostrato resistenza all'attacco a causa del "rumore significativo" nel segnale. bleepingcomputer+ 1
Una versione ottimizzata dell'attacco è in grado di estrarre codici 2FA a 6 cifre da Google Authenticator in meno di 30 secondi. Questo lasso di tempo rientra nel periodo di validità standard di 30 secondi dei codici TOTP, rendendo l'attacco pratico. cylab.cmu+ 2
Dati più complessi richiedono più tempo per essere estratti:
Pixnapping rappresenta una minaccia particolare per gli utenti di criptovalute. Le seed phrase dei portafogli rimangono visibili sullo schermo più a lungo dei codici 2FA temporanei, rendendole vulnerabili allo swipe dei pixel. Sebbene il recupero dell'intera seed phrase di 12 parole richiederebbe un tempo considerevole, l'attacco rimane fattibile se l'utente lascia la seed phrase visibile mentre la annota. currently.att.yahoo+3
I ricercatori hanno fornito diversi video che dimostrano l'attacco Pixnapping:
1. Demo di base di Pixnapping
2. Demo tecnica di Tweakers
I risultati della ricerca sono stati presentati formalmente alla 32ª Conferenza ACM su Sicurezza Informatica e delle Comunicazioni (ACM CCS 2025) a Taipei, Taiwan, dal 13 al 17 ottobre 2025. La presentazione includeva un'analisi dettagliata degli aspetti tecnici dell'attacco e una dimostrazione di esempi pratici. cylab.cmu+ 2
Ad ottobre 2025, Google e i ricercatori non hanno trovato prove che la vulnerabilità Pixnapping sia stata sfruttata in natura. Google ha dichiarato: "Non abbiamo visto alcuna prova di sfruttamento in natura". Tuttavia, ciò non esclude la possibilità di un uso occulto da parte degli aggressori. bleepingcomputer+ 1
I ricercatori hanno identificato diversi scenari potenziali per lo sfruttamento della vulnerabilità:
1. Furto di codici 2FA.
Lo scenario più comune prevede il furto di codici di autenticazione temporanei da Google Authenticator, Authy e altre app 2FA. Un aggressore può utilizzare i codici rubati per bypassare l'autenticazione a due fattori e ottenere accesso non autorizzato agli account della vittima. cylab.cmu+ 1
2. Compromissione dei portafogli di criptovalute.
Uno scenario particolarmente pericoloso è il furto delle seed phrase dei portafogli di Bitcoin e altre criptovalute. Se un utente visualizza la propria seed phrase sullo schermo per registrarla o verificarla, un'applicazione dannosa può estrarre gradualmente l'intera frase, ottenendo il controllo completo del portafoglio. currently.att.yahoo+ 2
3. Intercettazione di corrispondenza privata.
L'attacco può essere utilizzato per estrarre messaggi da app di messaggistica crittografata come Signal, anche con Screen Security abilitato. Ciò rappresenta una seria minaccia per gli utenti che fanno affidamento sulla sicurezza della crittografia end-to-end. bleepingcomputer+ 1
Sebbene non siano stati rilevati campioni di malware specifici che utilizzano Pixnapping, la tecnica potrebbe essere integrata nelle famiglie di Trojan Android esistenti. Ad esempio, la famiglia di malware SpyAgent utilizza già il riconoscimento delle immagini per rubare chiavi mnemoniche, e l'aggiunta delle capacità di Pixnapping potrebbe espandere significativamente le sue funzionalità. currently.att.yahoo+ 1
Un'app dannosa che esegue Pixnapping non richiede alcuna autorizzazione dichiarata nel file manifest Android. Ciò la rende indistinguibile dalle app benigne durante i controlli di sicurezza degli app store. pixnapping+ 1
Struttura di base del manifest:
xml:
<manifest xmlns:android="http://schemas.android.com/apk/res/android">
<application>
<activity android:name=".MaliciousActivity">
<!-- Senza dichiarare alcuna autorizzazione -->
</activity>
</application>
</manifest>
Un componente chiave dell'attacco è l'uso degli Intent Android per avviare le applicazioni target:
java:
// Esempio concettuale del codice di attivazione dell'applicazione target
Intent intent = new Intent();
intent.setAction("com.google.android.apps.authenticator2.AUTHENTICATE");
intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
startActivity(intent);
I ricercatori hanno analizzato quasi 100.000 app nel Google Play Store e hanno trovato centinaia di migliaia di azioni invocate tramite Intent Android, indicando l'ampia applicabilità dell'attacco. bleepingcomputer
Il processo di estrazione dei singoli pixel prevede la creazione di activity traslucide con una configurazione specifica:
java:
// Esempio concettuale di creazione di un'activity di mascheramento
Window window = getWindow();
WindowManager.LayoutParams params = window.getAttributes();
params.alpha = 0.99f; // Quasi completamente trasparente
params.flags |= WindowManager.LayoutParams.FLAG_NOT_TOUCHABLE;
window.setAttributes(params);
// Impostazione della sfocatura per indurre operazioni grafiche
window.setBackgroundBlurRadius(20);
Dopo l'estrazione dei pixel, viene utilizzata una tecnica simile al riconoscimento ottico dei caratteri (OCR) per ricostruire il contenuto originale. L'algoritmo analizza i pattern dei pixel estratti e ricostruisce caratteri e numeri. pixnapping+ 1
Google ha tentato per la prima volta di correggere la vulnerabilità nell'aggiornamento di sicurezza Android di settembre 2025 limitando il numero di activity che un'app poteva attivare per innescare la sfocatura. L'azienda ha osservato in un bollettino di sicurezza: "Un'app che richiede più sfocature: (1) consente il furto di pixel misurando il tempo di sfocatura tra le finestre, e (2) è probabilmente non valida." bleepingcomputer+ 2
I ricercatori hanno rapidamente scoperto una soluzione alternativa che ha ripristinato l'efficacia dell'attacco alterando le caratteristiche temporali. Questa soluzione alternativa è ancora sotto embargo e non è stata divulgata pubblicamente. pixnapping+ 2
Google sta sviluppando una patch più completa, che sarà rilasciata nel bollettino di sicurezza Android di dicembre 2025. Tuttavia, i ricercatori notano che una correzione efficace per Pixnapping richiederà modifiche ai meccanismi core di Android, come consentire alle app di impedire ad altre app di sovrapporre i propri contenuti sensibili. cylab.cmu+ 2
Il problema fondamentale è che il canale laterale sottostante GPU.zip rimane non corretto. Ad ottobre 2025, nessun produttore di GPU si è impegnato a correggere GPU.zip. Ciò significa che anche con le patch Android, la vulnerabilità hardware rimane esposta a nuovi metodi di attacco. pixnapping+ 1
Samsung è stata informata della vulnerabilità e avvisata che la patch di Google non era sufficiente a proteggere i dispositivi Samsung. L'azienda ha riconosciuto il problema ma lo ha classificato come "gravità bassa" a causa della complessità hardware. currently.att.yahoo+ 2
1. Aggiornamenti tempestivi:
La raccomandazione principale dei ricercatori è installare le patch Android il prima possibile dopo il loro rilascio. Gli utenti dovrebbero abilitare gli aggiornamenti di sicurezza automatici e controllare regolarmente la presenza di nuove patch. cylab.cmu+ 1
2. Utilizzo di portafogli hardware.
Per gli utenti di criptovalute, la protezione più efficace è l'uso di portafogli hardware. I portafogli hardware memorizzano chiavi private e seed phrase offline, eliminando la possibilità di compromissione tramite attacchi screen-to-screen. tradingview+ 1
3. Evitare di visualizzare informazioni sensibili.
Si consiglia agli utenti di evitare di visualizzare seed phrase o altri dati altamente sensibili su dispositivi connessi a Internet. Se è necessario memorizzare seed phrase, utilizzare dispositivi offline. currently.att.yahoo+1
1. Protezione dalle sovrapposizioni:
Gli sviluppatori possono implementare la protezione dalle sovrapposizioni rilevando quando altre applicazioni tentano di creare layer traslucidi sopra le proprie. Ciò può essere fatto utilizzando bitdefenderWindowManager.LayoutParams.FLAG_SECURE .
2. Ridurre al minimo il tempo di visualizzazione.
Le informazioni critiche dovrebbero essere visualizzate sullo schermo per il minor tempo possibile. Ad esempio, i codici 2FA possono essere nascosti automaticamente dopo brevi intervalli. bitdefender
3. Rilevamento di attività anomale:
Le applicazioni possono monitorare pattern di attività anomale, come chiamate frequenti all'API di sfocatura o comportamenti di sovrapposizione insoliti. bitdefender
1. Il potenziamento delle autorizzazioni di Android potrebbe richiedere permessi speciali per accedere all'API di sfocatura e ad altre operazioni grafiche che possono essere sfruttate negli attacchi. cylab.cmu
2. Isolamento delle applicazioni
Rafforzare l'isolamento tra le applicazioni può impedire ad altre applicazioni di accedere ai pixel tramite operazioni grafiche. bitdefender
3. Soluzioni hardware
Una soluzione a lungo termine potrebbe richiedere modifiche a livello di GPU per eliminare il canale laterale GPU.zip. pixnapping+1
Nel contesto dell'attacco Pixnapping (CVE-2025-48561), che sfrutta i meccanismi hardware e software di Android per intercettare visivamente le seed phrase e le chiavi private, è fondamentale considerare un vettore d'attacco aggiuntivo che opera a un livello hardware più fondamentale. L'attacco Phoenix Rowhammer (CVE-2025-6202) rappresenta una nuova generazione di sfruttamento delle proprietà fisiche della memoria DRAM, consentendo agli aggressori di manipolare singoli bit di dati nella RAM DDR5, incluse le strutture dati crittografiche critiche dei portafogli Bitcoin. github+ 4
Uno studio congiunto del Computer Security Group (COMSEC) dell'ETH di Zurigo e di Google, pubblicato a settembre 2025, ha dimostrato che la memoria DDR5 di SK Hynix—il più grande produttore mondiale di DRAM—rimane vulnerabile agli attacchi Rowhammer nonostante l'implementazione di avanzati meccanismi di protezione Target Row Refresh (TRR). Phoenix rappresenta il primo attacco Rowhammer a livello di sistema in grado di bypassare tutti gli schemi TRR moderni implementati nei dispositivi DDR5 utilizzando una rivoluzionaria tecnica di sincronizzazione auto-correttiva. linkedin+ 7
Rowhammer è una vulnerabilità hardware nella memoria dinamica ad accesso casuale (DRAM) che sorge a causa dei limiti fisici della moderna tecnologia di produzione dei chip di memoria. Con la riduzione degli standard di produzione della DRAM (a 10 nm, 7 nm e inferiori), la distanza fisica tra le singole celle di memoria diminuisce significativamente, portando a un aumento dell'interferenza elettromagnetica tra righe di memoria adiacenti. kaspersky+ 6
Meccanismo di induzione del bit flip:
Ogni cella DRAM è un condensatore che immagazzina una carica elettrica corrispondente a un valore logico di 0 o 1. Per leggere o scrivere dati su una specifica riga di memoria, viene eseguita un'operazione ACTIVATE, che eleva il livello di tensione della riga target (riga aggressore/riga target) a un livello alto mentre le righe vicine (righe vittima) rimangono a un livello di tensione basso. L'attivazione ripetuta della stessa riga di memoria in rapida successione crea interferenza elettromagnetica, che accelera la scarica dei condensatori nelle righe vicine, portando potenzialmente a cambiamenti spontanei nei valori dei bit (bit flip) prima del successivo ciclo di refresh. tomshardware+ 6
Modello matematico del degrado della carica:
La ricerca mostra che la probabilità di un bit flip PflipP_{flip}Pflip in una riga vittima dipende dal numero di attivazioni della riga aggressore NactN_{act}Nact, dal tempo tra le operazioni di refresh tREFt_{REF}tREF e dalla distanza tra le celle dcelld_{cell}dcell:
dove VaggrV_{aggr}Vaggr è la tensione di attivazione della riga aggressore. I moduli DDR5 moderni richiedono comandi di refresh ogni 3,9 µs in media per impostazione predefinita, il doppio rispetto alla DDR4, proprio per contrastare il crescente effetto Rowhammer. arxiv+ 4
DDR4 TRR: Protezione di prima generazione
A partire dalla DDR4, i produttori di DRAM hanno implementato il meccanismo Target Row Refresh (TRR)—un insieme di contatori hardware e logica integrata direttamente nei chip DRAM per rilevare schemi di accesso alla memoria sospetti. TRR opera sulla base di due parametri chiave: il Maximum Activate Count (MAC)—il numero massimo di attivazioni di riga—e la Maximum Activate Window (t~MAW~)—la finestra temporale durante la quale vengono conteggiate le attivazioni. csdn+4 youtube
Quando il numero di attivazioni di una particolare riga raggiunge la soglia MAC entro una finestra temporale t~MAW~, TRR avvia automaticamente un'operazione di refresh per le righe vittima adiacenti, prevenendo i bit flip. Tuttavia, lo studio TRRespass (2020) ha dimostrato una vulnerabilità critica di questo schema: il meccanismo TRR utilizza il campionamento —monitorando solo un sottoinsieme limitato di righe di memoria, piuttosto che tutte le righe simultaneamente. L'attacco Many-Sided Rowhammer sfrutta questa limitazione attivando simultaneamente più righe aggressore (fino a 19 in alcuni casi), sovraccaricando il meccanismo di campionamento TRR e consentendo alle righe "non osservate" di continuare l'hammering senza essere contrastate dalle operazioni di refresh. usenix+4 youtube
DDR5 TRR potenziato: Protezione di seconda generazione migliorata
La DDR5 ha introdotto circuiti TRR in-DRAM significativamente migliorati con algoritmi di rilevamento e contromisure più sofisticati. I produttori hanno implementato comandi di refresh più frequenti (ogni 3,9 µs rispetto ai 7,8 µs della DDR4), codice di correzione errori (ECC) integrato sul die e meccanismi di tracciamento delle attivazioni più avanzati. Prima della pubblicazione di Phoenix a settembre 2025, si riteneva che la DDR5 dimostrasse una maggiore resistenza agli attacchi Rowhammer negli ambienti di produzione e, "inaspettatamente, la DDR5 raggiunge questo risultato senza comandi di controllo del refresh aggiuntivi". comsec-files.ethz+5
Il problema della sincronizzazione e il meccanismo auto-correttivo
Una scoperta chiave dei ricercatori dell'ETH di Zurigo è che gli attuali metodi di sincronizzazione all'avanguardia perdono regolarmente i comandi di refresh, rendendoli inadatti per attacchi Rowhammer efficaci sulla DDR5. Phoenix affronta questo problema con due tecniche rivoluzionarie: securityweek+ 2.
La prima tecnica: la suddivisione dei thread. L'hammering e gli accessi di sincronizzazione vengono suddivisi in thread di esecuzione diversi per migliorare il rilevamento del refresh. Sebbene sia un miglioramento rispetto allo stato dell'arte, questo approccio non riesce comunque a mantenere la sincronizzazione su un numero sufficientemente elevato di intervalli di refresh, impedendo l'induzione di bit flip. github+ 1
La seconda tecnica è la sincronizzazione auto-correttiva. Invece di cercare di prevenire i comandi di refresh mancati, Phoenix rileva un refresh mancato e risincronizza l'esecuzione del pattern di conseguenza. Questa tecnica consente a Phoenix di rimanere sincronizzato con i comandi di refresh per intere finestre di refresh, il che è sufficiente per indurre bit flip con nuovi pattern. security.googleblog+ 4
Modello matematico della sincronizzazione auto-correttiva:
Bypass del TRR sfruttando i punti ciechi
Phoenix sfrutta i punti ciechi nel meccanismo TRR—finestre temporali e spaziali in cui il monitoraggio delle attivazioni di riga è indebolito. I ricercatori hanno scoperto che il campionatore TRR deve campionare costantemente gli accessi allo stesso insieme di righe, consentendo agli accessi (non campionati) ad altre righe di continuare l'hammering senza l'intervento delle operazioni di refresh TRR. Phoenix sincronizza i pattern di accesso con i comandi di refresh in modo che le righe vittima siano al di fuori della zona di monitoraggio TRR attiva nei momenti critici. vusec+ 7
Configurazione del test e dispositivi interessati
I ricercatori dell'ETH di Zurigo hanno testato Phoenix su 15 moduli UDIMM DDR5 prodotti da SK Hynix, fabbricati tra il 2021 e il 2024. Tutti i dispositivi testati hanno dimostrato vulnerabilità a Phoenix, inducendo con successo bit flip entro secondi su ciascun modulo. Il test è stato condotto su una piattaforma con processore AMD Zen 4 e piattaforme di test Rowhammer specializzate basate su FPGA sviluppate in collaborazione con Antmicro. theregister+ 8
Уязвимость CVE-2025-6202 зарегистрирована с базовым CVSS-скором 7.1 (High severity). Vulnerability description: «Vulnerability in SK Hynix DDR5 on x86 allows a local attacker to trigger Rowhammer bit flips impacting the Hardware Integrity and the system’s security. This issue affects DDR5: DIMMs produced from 2021-1 until 2024-12».thehackernews+5
Elenco dei processori AMD interessati con supporto DDR5: amd
Processori AMD EPYC serie 8004, 9004, 9005; AMD EPYC serie 9004, 9005 Embedded; AMD Ryzen serie 6000, 7000, 7035, 7040, 7045, 8000, 8040, 9000; AMD Ryzen serie 9000HX; AMD Ryzen AI serie 300, AI Max 300; AMD Ryzen Threadripper 7000, 9000; AMD Ryzen Embedded serie 7000, 8000, 9000.amd
Scenari di attacco pratici e caratteristiche temporali
I ricercatori hanno dimostrato tre scenari di sfruttamento end-to-end per Phoenix: techradar+ 5
1. Manipolazione delle Page Table Entries (PTE) per l'escalation dei privilegi: Phoenix esegue con successo bit flip sulle Page Table Entries con un tasso di successo del 100%, ottenendo accesso non autorizzato ad aree di memoria riservate. Ciò consente a un aggressore locale senza privilegi di modificare la propria page table, ottenendo accesso in lettura-scrittura a tutta la memoria fisica del sistema. pmc.ncbi.nlm.nih+ 4
2. Estrazione di chiavi SSH da macchine virtuali: Phoenix dimostra un tasso di successo del 73% nell'estrazione di chiavi private SSH RSA-2048 da una macchina virtuale co-localizzata sullo stesso server fisico. Questa è una minaccia critica per gli ambienti di cloud computing in cui più VM condividono la stessa memoria fisica. kaspersky+ 5
3. Escalation dei privilegi a root tramite manipolazione del binario sudo: Phoenix raggiunge una probabilità del 33% di ottenere accesso root tramite la manipolazione del binario in memoria di sudo. L'escalation completa dei privilegi a root su un sistema commerciale con impostazioni predefinite viene raggiunta in circa 109 secondi (meno di 2 minuti). linkedin+5
Fondamenti teorici di un attacco di fault injection ECDSA
L'algoritmo di firma digitale a curva ellittica (ECDSA) è una primitiva crittografica fondamentale in Bitcoin, che fornisce autenticazione delle transazioni e prova di proprietà degli asset digitali. La chiave privata in ECDSA è un valore scalare ddd (256 bit per secp256k1), da cui viene calcolata la chiave pubblica: Q = d⋅GQ = d \cdot GQ = d⋅G, dove GGG è il punto base della curva ellittica. digital.wpi+ 7
Struttura della firma ECDSA:
Per un messaggio mmm con hash h=H(m)h = H(m)h=H(m), la firma consiste nella coppia (r,s)(r, s)(r,s), dove:
dove kkk è un nonce casuale, nnn è l'ordine del gruppo di punti sulla curva secp256k1. securityboulevard+ 4
Attacco di fault injection tramite bit flip indotti da Rowhammer
La ricerca di Rubber Mallet (arXiv:2505.01518, maggio 2025) ha dimostrato che le tecniche Rowhammer avanzate possono indurre bit flip multipli adiacenti a un tasso significativamente più elevato rispetto a quanto documentato in precedenza. In modo critico, questi flip correlati consentono attacchi efficaci di correzione delle firme crittografiche, dimostrando come tali flip possano consentire il recupero di chiavi private ECDSA da implementazioni OpenSSL dove gli approcci a bit singolo sarebbero impraticabili. arxiv+ 2
Meccanismo dell'attacco bit-flipping su una chiave privata:
Supponiamo che un aggressore possa indurre un bit flip nel bit meno significativo (LSB) della chiave privata ddd memorizzata nella RAM prima dell'operazione di firma. Un bit flip nel LSB porterà a uno dei due risultati: trailofbits+ 2
Caso 1: Bit 0 → 1, che equivale a d′=d+1d’ = d + 1d′=d+1
Caso 2: Bit 1 → 0, che equivale a d′=d−1d’ = d − 1d′=d−1
Una firma creata con la chiave modificata d′d’d′ può essere verificata utilizzando la chiave pubblica modificata:
Un aggressore genera una firma con una chiave privata flippata, quindi verifica la verifica della firma utilizzando Q + GQ + GQ + G e Q − GQ − GQ − GQ − G. Se la firma viene verificata con Q + GQ + GQ + G, il bit originale era 0; se con Q − GQ − GQ − G, il bit era 1. Ripetendo questo processo per altre posizioni di bit (flippando i bit alle posizioni 20, 21, 22, …, 2255 2^0, 2^1, 2^2, …, 2^{255} 20, 21, 22, …, 2255 e verificando con Q ±2i⋅GQ \pm 2^i \cdot GQ ±2i⋅G), l'aggressore può ricostruire bit per bit l'intera chiave privata ddd. arxiv+ 5
Dimostrazione sperimentale su OpenSSL ECDSA
Nell’articolo di Kwong et al. (arXiv:2505.01518), i ricercatori hanno dimostrato con successo l’estrazione end-to-end della chiave privata ECDSA da un’implementazione OpenSSL tramite bit-flipping Rowhammer. Gli esperimenti sono stati condotti su diverse configurazioni di DRAM DDR4 (Corsair Vengeance, G.SKILL Ripjaws) utilizzando gli strumenti Rowhammer TRRespass e BlackSmith. Una scoperta critica è l’elevata frequenza di bit flip localizzati —più bit flip raggruppati all’interno della stessa riga di DRAM. arxiv+ 2
Uno studio di Rahman et al. (2023) (digital.wpi.edu) ha dimostrato un attacco al recupero della chiave segreta ECDSA nella DRAM Samsung M378B5773DH0-2GB tramite iniezione di guasti in un server TLS. I ricercatori hanno avviato 29.918 connessioni al server iniettando guasti nella memoria del server e hanno raccolto con successo firme difettose per recuperare la chiave privata. Anche se la dimensione della chiave ECDSA a 256 bit è significativamente più piccola della dimensione della pagina di memoria di 32.768 bit (la maggior parte dei bit flippati è al di fuori della chiave), l’attacco ha comunque successo con un numero sufficiente di tentativi. digital.wpi
Memorizzazione delle chiavi private nella RAM e vettori di attacco
I portafogli Bitcoin, sia software che alcuni hardware, caricano inevitabilmente le chiavi private nella RAM quando eseguono operazioni critiche: firma delle transazioni, inizializzazione del portafoglio, derivazione delle chiavi dalle frasi seed e decrittazione dei file wallet.dat. Anche quando si utilizza la crittografia AES-256-CBC per proteggere wallet.dat (come in Bitcoin Core), la chiave privata deve essere temporaneamente decrittata e memorizzata nella RAM per firmare una transazione. cryptodeeptech+ 6
Modello di minaccia per gli attacchi Rowhammer sui portafogli Bitcoin:
Scenario 1: Attaccante locale su un sistema desktop. L’attaccante esegue un’applicazione dannosa sullo stesso computer del portafoglio Bitcoin della vittima. Il processo dannoso induce bit flip Rowhammer nelle regioni di memoria in cui Bitcoin Core o un altro portafoglio memorizza le chiavi private decrittate durante le operazioni di firma. Phoenix ha dimostrato la capacità di leggere e scrivere dati arbitrari dalla memoria ad alta precisione sui sistemi DDR5. github+ 9
Scenario 2: Attacco di co-locazione Cloud/VPS. Molti utenti di nodi e portafogli Bitcoin ospitano i propri servizi su server privati virtuali (VPS) su piattaforme cloud. Phoenix ha dimostrato un tasso di successo del 73% nell’estrazione di chiavi SSH RSA-2048 da una VM co-locata. Un attacco simile potrebbe prendere di mira le chiavi private Bitcoin memorizzate nella memoria di una VM che esegue un nodo Bitcoin Core o altri servizi di portafoglio. tomshardware+ 5
Scenario 3: Rowhammer su dispositivi Android per portafogli Bitcoin mobili. La combinazione di Pixnapping (CVE-2025-48561) e potenziali varianti Rowhammer per LPDDR4/LPDDR5 mobili crea una minaccia multilivello. Sebbene Phoenix sia specifico per DDR5 desktop, la ricerca mostra che LPDDR4 include anche meccanismi TRR ed è potenzialmente vulnerabile ad attacchi Rowhammer adattati. wikipedia+ 1
Modello matematico per l’estrazione di una chiave privata Bitcoin tramite bit flip:
Supponiamo che una chiave privata Bitcoin a 256 bit ddd sia memorizzata in memoria all’indirizzo AkeyA_{key}Akey. Un attaccante rowhammer può indurre un bit flip nel bit iii (dove 0≤i≤2550 \le i \le 2550≤i≤255), modificando la chiave in d′=d⊕2id’ = d \oplus 2^id′=d⊕2i (XOR con 2i2^i2i). Per recuperare la chiave originale, l’attaccante raccoglie molte firme difettose {(rj,sj)}\{(r_j, s_j)\}{(rj,sj)}, ciascuna creata con una versione diversa della chiave con bit flippati dj′d_j’dj′.
Utilizzando metodi di attacco a reticolo (ad es. risolutore del problema del numero nascosto), un attaccante può recuperare ddd con probabilità di successo:
dove PflipP_{flip}Pflip è la probabilità di flippare con successo il bit desiderato, NsamplesN_{samples}Nsamples è il numero di firme difettose raccolte. pmc.ncbi.nlm.nih+ 3
ATTACKSAFE SOFTWARE e strumento rowhammer_attack
L’ecosistema di sicurezza delle criptovalute include programmi specializzati per l’analisi delle vulnerabilità legate a Rowhammer. Il repository GitHub demining/Rowhammer-Attack dimostra l’applicazione pratica dell’analisi differenziale dei guasti delle firme per ECDSA per derivare chiavi private dalle transazioni in cinque diversi portafogli Bitcoin .
Esempio pratico di utilizzo:
./attacksafe -tool rowhammer_attack -open RawTX.txt -save SecretKey.txtLo strumento analizza le transazioni Bitcoin RawTX ed estrae i parametri della firma ECDSA (r,s)(r,s)(r,s). Se viene rilevato un pattern che indica una firma difettosa o un riutilizzo del nonce, lo strumento applica tecniche crittanalitiche per recuperare la chiave segreta KKK (nonce) o la chiave privata ddd. github
Esempio di estrazione riuscita: github
Deployments ECDSA:
SecretKey = 0xe5fa9dccef88781e25e77bd1ea7830c0b33c57481b79007cda117da8139ea7c3
RawTX = 010000000104118e34a0d3c06c842d14707ed5f333d3ba1d35240086a4b5738a2fa810abec1d0000006a473044022004b1d0c7d278439811c27d9ff06b3bb0fd20d5cc90d97083266bdba7d0693bb20220282c6cea6b9ad6f4633596204ebad4716e2a086090faf62a6908bf63a1724ad501210335a395eca8191c43ccee4d91e98b9baef39476d7482cf636e5b71975c69feebdffffffff014e020000000000001976a914154813f71552c59487efa3b16d62bfb009dc5f1e88ac00000000L’etichetta “Deployments ECDSA” indica una vulnerabilità critica nella transazione della blockchain Bitcoin. La chiave segreta “K” in formato HEX rappresenta il nonce utilizzato per generare la firma. github
Piattaforme di test Rowhammer open-source basate su FPGA
Google e ETH Zürich hanno sviluppato piattaforme di test open-source specializzate basate su FPGA per analizzare le vulnerabilità Rowhammer della DDR5. In collaborazione con Antmicro, sono state create due piattaforme: security.googleblog
Piattaforma DDR5 RDIMM: Nuova scheda DDR5 Tester per testare la memoria Registered DIMM (RDIMM), comunemente presente nei computer server. security.googleblog
Piattaforma SO-DIMM: Una versione che supporta i pinout SO-DIMM standard, compatibile con i moduli di memoria DDR5 SO-DIMM disponibili in commercio, comuni nelle workstation e nei dispositivi utente finali. security.googleblog
Queste piattaforme sono disponibili su GitHub (comsec.ethz.ch/phoenix) e consentono ai ricercatori di sicurezza di condurre analisi dettagliate della suscettibilità a Rowhammer di varie configurazioni DRAM. comsec.ethz+1
Aumento della frequenza di refresh: un compromesso tra sicurezza e prestazioni
I ricercatori di Phoenix raccomandano di aumentare la frequenza di refresh di un fattore 3 (da 3,9 µs a ~1,3 µs) come contromisura efficace. Tuttavia, ciò comporta una riduzione delle prestazioni dell’8,4% , rappresentando un compromesso significativo per i sistemi di produzione. In modo critico, i dispositivi DRAM non possono essere corretti tramite aggiornamenti firmware: la natura hardware della vulnerabilità significa che i moduli interessati rimarranno vulnerabili per tutto il loro ciclo di vita. techradar+ 5
Efficacia limitata di ECC e ECC on-die
Phoenix ha dimostrato che il codice di correzione degli errori (ECC) on-die integrato nella DDR5 non ferma Rowhammer . L’ECC on-die è progettato per correggere errori a bit singolo e alcuni errori a bit multipli derivanti dal naturale degrado delle celle DRAM. Tuttavia, Rowhammer può indurre molteplici bit flip correlati nella stessa regione di memoria, superando la capacità correttiva dell’ECC. reddit+ 7
Impossibilità di correzioni hardware retroattive
A differenza delle vulnerabilità software che possono essere corrette con patch di sicurezza, Rowhammer rappresenta un problema fisico fondamentale dell’architettura DRAM. Ad ottobre 2025, nessun produttore di GPU o DRAM si è impegnato a correggere la vulnerabilità hardware a livello di progettazione dei chip. Ciò significa che miliardi di dispositivi che utilizzano la memoria interessata rimarranno potenzialmente vulnerabili per anni a venire. pixnapping+12
Strategia di sicurezza multilivello per i detentori di criptovalute:
1. Portafogli hardware con memoria isolata. Utilizzare portafogli hardware (Ledger, Trezor, BC Vault One) con memoria ferroelettrica (FeRAM) o elementi sicuri che isolano le chiavi private dalla DRAM principale del sistema. BC Vault One utilizza FeRAM per memorizzare la chiave privata, fornendo isolamento fisico dagli attacchi Rowhammer sulla memoria di sistema. youtube itnext+ 3
2. Evitare di conservare grandi quantità in portafogli hot su sistemi DDR5. Gli utenti che eseguono Bitcoin Core o altri portafogli software su sistemi SK Hynix DDR5 (2021-2024) dovrebbero ridurre al minimo l’esposizione spostando i propri asset principali in cold storage. github+ 3
3. Isolare le operazioni di firma in ambienti air-gapped. Per transazioni di alto valore, utilizzare la firma offline su sistemi isolati che non si connettono mai alla rete e non eseguono codice non attendibile. itnext+ 2
4. Audit regolare della memoria e rilevamento delle anomalie. Monitorare la memoria di sistema per pattern di accesso sospetti caratteristici degli attacchi Rowhammer (attivazioni di riga ad alta frequenza, pattern di refresh anomali). pmc.ncbi.nlm.nih+ 3
5. Aggiornare a sistemi corretti quando disponibili. Sebbene una correzione hardware non sia possibile, i futuri chip DDR5 (post-2024) potrebbero includere meccanismi TRR migliorati. Gli utenti dovrebbero monitorare i bollettini di sicurezza dei produttori di DRAM e aggiornare il proprio hardware quando vengono rilasciati moduli più sicuri. github+4
La combinazione degli attacchi Pixnapping (CVE-2025-48561) e Phoenix Rowhammer (CVE-2025-6202) dimostra un’evoluzione critica nel panorama delle minacce alla sicurezza delle criptovalute. Pixnapping attacca il livello hardware e software di Android tramite canali laterali GPU.zip e l’API di sfocatura delle finestre per intercettare visivamente le frasi seed. Phoenix attacca il livello fisico fondamentale della DRAM tramite l’induzione di interferenze elettromagnetiche, consentendo la manipolazione diretta dei bit delle chiavi crittografiche in memoria. bleepingcomputer+ 10
Entrambi gli attacchi bypassano le protezioni software tradizionali sfruttando caratteristiche hardware dei dispositivi che non possono essere corrette. Per gli utenti Bitcoin, ciò significa che è necessario un ripensamento fondamentale del modello di minaccia: la sicurezza crittografica non è più garantita esclusivamente dalla complessità matematica di ECDSA o dall’affidabilità delle frasi seed—le proprietà fisiche dell’hardware diventano la superficie di attacco critica. arxiv+ 9
Il recupero delle chiavi private da portafogli Bitcoin persi sfruttando queste vulnerabilità rappresenta sia un compito legittimo per i servizi di recupero sia un pericoloso vettore di attacco per gli aggressori. Il futuro della sicurezza delle criptovalute richiede un approccio olistico che integri garanzie di sicurezza a livello hardware, implementazioni crittografiche con verifica formale e monitoraggio continuo delle minacce emergenti tramite canali laterali. trailofbits+ 7
La vulnerabilità Pixnapping rappresenta un’evoluzione significativa negli attacchi mobili, dimostrando come le moderne ottimizzazioni delle prestazioni possano essere sfruttate. L’attacco è particolarmente pericoloso per gli utenti di criptovalute, poiché la compromissione della frase seed può portare alla perdita completa dei fondi. gbhackers
La natura fondamentale delle vulnerabilità sfruttate—l’uso di API Android legittime e ottimizzazioni hardware GPU—indica che una soluzione completa richiederà uno sforzo coordinato da parte di Google, dei produttori di dispositivi e dei fornitori di GPU. pixnapping+ 1
La ricerca di Pixnapping evidenzia l’importanza critica di considerare le implicazioni di sicurezza quando si implementano nuove funzionalità di sistema e ottimizzazioni hardware. Poiché i dispositivi mobili diventano lo strumento principale per la gestione degli asset digitali, la protezione da attacchi così sofisticati diventa vitale per la sicurezza dell’ecosistema.
Si prevede che la patch di dicembre di Google fornisca una protezione più robusta, ma una soluzione a lungo termine richiederà cambiamenti fondamentali nell’architettura di Android e possibilmente nell’hardware GPU. Fino ad allora, gli utenti dovrebbero seguire le raccomandazioni di sicurezza e prestare particolare cautela nella gestione degli asset in criptovaluta sui dispositivi Android.
Pertanto, la vulnerabilità Pixnapping (CVE-2025-48561) non è solo un altro esempio di difetto software, ma la dimostrazione di una classe fondamentalmente nuova di attacchi che minacciano le fondamenta della sicurezza crittografica degli asset digitali. Lo studio ha mostrato che anche elementi visivamente inviolabili dell’interfaccia utente Android possono diventare una fonte di perdita critica di dati—dalle chiavi private e frasi seed ai codici 2FA monouso che proteggono i portafogli di criptovalute. In sostanza, ogni pixel sullo schermo diventa un anello debole nella catena di autenticazione crittografica.
Pixnapping è particolarmente pericoloso per la sua furtività e versatilità . L’attacco non richiede privilegi, sfugge all’utente ed è in grado di ricostruire l’immagine dello schermo fino ai singoli pixel utilizzando il canale laterale hardware GPU.zip . Ciò rende qualsiasi dispositivo Android una potenziale fonte di compromissione per dati sensibili, inclusi Bitcoin (BTC), Ethereum (ETH), XRP, Litecoin (LTC), e altre criptovalute conservate nei portafogli mobili.
Il fatto che questo attacco funzioni anche con le ultime versioni di Android e GPU moderne indica una vulnerabilità fondamentale nell’architettura dei sistemi mobili , dove le ottimizzazioni delle prestazioni e visive entrano in conflitto con i requisiti di privacy. Pixnapping infrange l’illusione dell’isolamento visivo tra le app, dimostrando che la protezione delle informazioni crittografiche deve considerare non solo le vulnerabilità di rete e logiche, ma anche gli effetti collaterali fisici e grafici del calcolo .
Per garantire la stabilità dell’ecosistema delle criptovalute, sono necessarie misure sistemiche: inasprire le policy di sicurezza di Android, limitare l’accesso delle app di terze parti alle API grafiche di basso livello e rivedere i principi architetturali della compressione dei dati GPU. Senza tali barriere, anche gli algoritmi di crittografia più sicuri potrebbero essere vulnerabili ad attacchi in grado di rubare le chiavi letteralmente dallo schermo.
In definitiva, Pixnapping è servito come un serio monito per l'intero settore: la protezione crittografica è priva di significato senza isolamento hardware e visivo . Se i dati visivi visualizzati su uno schermo possono essere ricostruiti da un processo esterno, allora ogni animazione sullo schermo, ogni frase seed o codice QR diventa un canale diretto per la fuga di fondi. Per gli utenti di criptovalute, questo significa una cosa: anche la comparsa istantanea di una chiave privata sullo schermo può ora costare loro l'intero capitale digitale.
Questo materiale è stato creato per il portale CRYPTO DEEP TECH per garantire la sicurezza dei dati finanziari e la crittografia a curva ellittica (secp256k1) contro le firme ECDSA deboli nella criptovaluta BITCOIN . Gli sviluppatori del software non sono responsabili dell’uso di questo materiale.
Telegram: https://t.me/cryptodeeptech
Video: https://youtu.be/qZvJUonp228
Video tutorial: https://dzen.ru/video/watch/68ff42ad9f0528014a4b1cf8
Fonte: https://cryptodeeptech.ru/phoenix-rowhammer-attack