Un nuovo capitolo si aggiunge alla lista degli attacchi informatici contro grandi aziende: il threat actor “LaFouine” ha dichiarato di essere in possesso di un database Carrefour Francia e di averlo messo in vendita su un forum dedicato alle violazioni di dati. Se confermata, questa fuga di informazioni rappresenterebbe un disastro senza precedenti per l’azienda e i suoi clienti.

Questo accade dopo che un altra grande distribuzione è stata colpita da un attacco ransomware da parte di criminali informatici di Lynx che hanno preso di mira la Conad qualche giorno fa.

Al momento, non possiamo confermare la veridicità della notizia, poiché l’organizzazione non ha ancora rilasciato alcun comunicato stampa ufficiale sul proprio sito web riguardo l’incidente. Pertanto, questo articolo deve essere considerato come ‘fonte di intelligence’.

La violazione

Secondo le informazioni fornite dall’attore malevolo, il presunto dataset comprende dati personali e sensibili di oltre 13 milioni di clienti che hanno effettuato ordini sul sito web di Carrefour. Tra i dettagli rubati spiccano:

• Nome e cognome
• Indirizzo, CAP, città e stato
• Numero di telefono e email
• Informazioni sul profilo utente
• Data di nascita
• Preferenze di acquisto
• ID carrello, totale spese, sconti e risparmi accumulati

Si tratterebbe, se confermato, di un vero tesoro per i cybercriminali, che potrebbero sfruttare questi dati per furti di identità, frodi finanziarie e campagne di phishing mirate.

Come potrebbe essere avvenuto l’attacco?

Sebbene i dettagli tecnici del breach non siano stati ancora divulgati, le dinamiche suggeriscono alcune ipotesi sulle TTPs (Tactics, Techniques, Procedures) potenzialmente utilizzate:

• SQL Injection: sfruttando vulnerabilità nei database del sito web.
• Accesso non autorizzato: tramite credenziali rubate o deboli associate ai sistemi di gestione.
• Phishing mirato: colpendo dipendenti o fornitori con email fraudolente e successivamente attraverso movimenti laterali nella rete.
• Esfiltrazione di dati: sfruttando endpoint non adeguatamente protetti.

Nonostante le ipotesi, una domanda cruciale resta: Carrefour ha sottovalutato i rischi di sicurezza?

Raccomandazioni

Per limitare i danni e prevenire futuri incidenti, è necessario adottare azioni decisive.

Per l’Azienda

• Effettuare un’analisi interna per identificare la fonte del breach e collaborare con esperti di cybersecurity per risolvere le vulnerabilità.
• Informare tempestivamente i clienti sull’accaduto, fornendo indicazioni su come proteggere i propri dati.
• Migliorare la sicurezza con standard di crittografia avanzati, controlli di accesso più rigidi e audit regolari per prevenire ulteriori minacce.

Per i clienti coinvolti

• Monitorare regolarmente i propri conti bancari e account online per rilevare eventuali attività sospette.
• Cambiare immediatamente le password associate agli account Carrefour e adottare credenziali uniche e robuste.
• Prestare attenzione a email o messaggi sospetti che richiedano informazioni personali o finanziarie

Conclusione

Questo attacco dimostra ancora una volta come le grandi aziende siano bersagli ambiti per i cybercriminali. Tuttavia, non si tratta solo di una questione aziendale: ogni individuo coinvolto rischia conseguenze reali e tangibili.

La vicenda deve servire da monito per tutte le organizzazioni, grandi e piccole: investire in sicurezza informatica non è solo una scelta strategica, ma una responsabilità imprescindibile in un mondo digitale sempre più vulnerabile.

Come nostra consuetudine, lasciamo sempre spazio ad una dichiarazione da parte dell’azienda qualora voglia darci degli aggiornamenti sulla vicenda. Saremo lieti di pubblicare tali informazioni con uno specifico articolo dando risalto alla questione.

RHC monitorerà l’evoluzione della vicenda in modo da pubblicare ulteriori news sul blog, qualora ci fossero novità sostanziali. Qualora ci siano persone informate sui fatti che volessero fornire informazioni in modo anonimo possono utilizzare la mail crittografata del whistleblower.

L'articolo 13 milioni di clienti Carrefour a Rischio: Il Threat Actors li mette in vendita nel Dark Web proviene da il blog della sicurezza informatica.

I ricercatori di Positive Technologies hanno studiato il mercato della darknet e hanno analizzato i prezzi dei servizi e dei beni informatici illegali, nonché i costi sostenuti dagli aggressori per effettuare attacchi. Per questo studio, gli esperti hanno analizzato 40 fonti in russo e inglese, inclusi i più grandi forum e mercati della darknet, nonché canali Telegram su vari argomenti. In totale sono stati studiati più di 20.000 messaggi che parlavano di malware, vulnerabilità, accesso alle reti aziendali e servizi della criminalità informatica.

I risultati della ricerca nelle underground

A quanto pare, il tipo di malware più costoso è il ransomware, con un costo medio di 7.500 dollari. Di particolare valore sono anche gli exploit 0-day, che spesso vengono venduti per milioni di dollari. Tuttavia, i ricercatori scrivono che il profitto netto di un attacco riuscito può essere in media cinque volte superiore al costo della sua preparazione, anche a prezzi elevati.

Secondo gli esperti, organizzare uno scenario popolare di attacchi di phishing utilizzando ransomware costa ai criminali informatici alle prime armi almeno 20.000 dollari.

Se la preparazione per un attacco inizia da zero, gli hacker criminali affittano server dedicati, acquistano abbonamenti a servizi VPN e altri strumenti per creare un’infrastruttura di controllo sicura e anonima. Tra i costi rientrano anche l’acquisto tramite abbonamento del codice sorgente del malware o del malware già pronto, i programmi per scaricarlo sul sistema della vittima e per camuffarlo dalle misure di sicurezza.
Costo della preparazione di un attacco?
Inoltre, gli hacker criminali possono acquistare l’accesso dagli Initial Access Broker (IaB) scegliendo l’azienda presa di mira e quindi utilizzare servizi per aumentare i privilegi sul sistema compromesso. Va notato che l’elenco dei prodotti e delle opzioni, nonché il malware e le relative istruzioni, possono semplificare il più possibile le attività dei principianti.

Loader, Ransomware, infostealer. Tutto serve per un attacco riuscito

Il malware è uno degli strumenti principali nell’arsenale di un hacker. Pertanto, il 53% degli annunci pubblicitari riguardanti tali programmi sono in vendita.

Nel 19% dei casi sono stati messi in vendita infostealer progettati per rubare dati, nel 17% cryptolocker e strumenti di offuscamento del codice che consentono di nascondersi dalle misure di sicurezza, nel 16% downloader / loader.

Il costo medio di questo tipo di malware è rispettivamente di 400, 70 e 500 dollari. Il malware più costoso è il ransomware, il cui costo medio è di 7.500 dollari (ci sono anche offerte per 320.000 dollari). Questo malware viene distribuito principalmente attraverso un programma di affiliazione (RaaS, Ransomware-as-a-Service), i cui partecipanti ricevono il 70–90% del riscatto della vittima. Per diventare un “affiliato” di solito è necessario versare un contributo di 0,05 Bitcoin (da 5.000 dollari) e avere una buona reputazione sulla darknet.

Un altro strumento di attacco popolare sono gli exploit: il 69% degli annunci su questo argomento sono legati alle vendite, mentre i messaggi relativi alle vulnerabilità zero-day guidano con una quota del 32%. Nel 31% dei casi, il costo degli exploit supera i 20.000 dollari e talvolta può raggiungere diversi milioni.

I prezzi più bassi sono inerenti all’accesso alle reti aziendali delle aziende: il 72% degli annunci in questo segmento sono in vendita e il 62% di essi arriva fino a 1.000 dollari.

0day ed exploit fanno la differenza

Tra i servizi hacker, il più popolare è l’hacking di risorse (49% dei messaggi): ad esempio, i prezzi per compromettere un account di posta elettronica personale partono da 100 dollari e per una casella di posta aziendale da 200 dollari.

“Sulle piattaforme underground, i prezzi si formano principalmente in due modi: o i venditori stessi determinano un prezzo fisso, oppure si tengono aste. Questi ultimi sono rilevanti per prodotti esclusivi, ad esempio per gli exploit zero-day. Guadagnano denaro anche le risorse su cui si svolgono le transazioni, anche con l’aiuto dei propri servizi di garante, che trattengono temporaneamente i fondi dell’acquirente fino a quando non conferma la ricezione del prodotto o del servizio. Su molti siti tali servizi sono forniti da uno degli amministratori o da utenti con una buona reputazione. Per questo ricevono almeno il 4% dell’importo della transazione: le tariffe sono stabilite dai forum stessi“, commenta Dmitry Streltsov, analista del dipartimento di ricerca analitica di Positive Technologies.

L'articolo Quanto Costa Un Attacco Ransomware? Ai Black Hacker bastano 20.000 Dollari! proviene da il blog della sicurezza informatica.

Una nuova ricerca ha identificato problemi in diversi protocolli di tunneling. Più di 4 milioni di sistemi sono vulnerabili a questi bug, inclusi server e router VPN. Gli esperti hanno avvertito che gli host che accettano pacchetti tunnel senza verificare il mittente potrebbero essere hackerati e utilizzati per effettuare attacchi anonimi e ottenere l’accesso alle reti.

Lo studio è stato pubblicato da Top10VPN ed è stato realizzato in collaborazione con la professoressa e rinomata ricercatrice di sicurezza informatica della KU Leuven Mathy Vanhoef e lo studente laureato Angelos Beitis. Si noti che Vanhof è ampiamente noto per le sue ricerche nel campo della sicurezza Wi-Fi. Così è stato lui a scoprire e descrivere problemi sensazionali come SSID Confusion, Frag AttacksDragonblood e KRACK .

La ricerca e il bug rilevato

Questa volta gli esperti hanno studiato i protocolli di tunnelingche vengono utilizzati per trasferire dati tra reti diverse e consentono di trasferire dati che potrebbero non supportare (ad esempio, lavorando con IPv6 su una rete IPv4). Per fare ciò, incapsulano alcuni pacchetti all’interno di altri.

Sulla base di ricerche precedenti che hanno dimostrato che gli host IPv4 accettano traffico IPIP non autenticato da qualsiasi fonte, Vanhoof e Baitis hanno identificato diversi protocolli di tunneling (inclusi IPIP/IP6IP6, GRE/GRE6, 4in6 e 6in4) che sono vulnerabili agli abusi perché non forniscono l’autenticazione e crittografare il traffico senza applicare la sicurezza adeguata (ad esempio, utilizzando IPsec).

Gli esperti spiegano che i sistemi configurati in modo errato accettano i pacchetti tunnel senza verificare il mittente. Ciò consente agli aggressori di inviare pacchetti appositamente predisposti contenenti l’indirizzo IP della vittima a un host vulnerabile, costringendo l’host a inoltrare un pacchetto interno alla vittima, che apre la porta agli aggressori per lanciare ulteriori attacchi.

“Gli aggressori devono semplicemente inviare un pacchetto incapsulato utilizzando uno dei protocolli interessati con due intestazioni IP. L’intestazione esterna contiene l’indirizzo IP di origine dell’aggressore e la destinazione è l’indirizzo IP dell’host vulnerabile. L’intestazione interna contiene l’indirizzo IP dell’host vulnerabile, non dell’aggressore”, spiegano gli esperti.

Pertanto, dopo aver ricevuto un pacchetto dannoso, l’host vulnerabile rimuove automaticamente l’intestazione esterna e inoltra il pacchetto interno alla sua destinazione. Dato che l’indirizzo IP nel pacchetto interno appartiene a un host vulnerabile ma affidabile, riesce a bypassare i filtri di rete.

Non solo VPN

È stato riferito che gli aggressori possono utilizzare questa tecnica per condurre attacchi anonimi, incluso l’utilizzo di host come proxy unidirezionali, conducendo attacchi DoS e spoofing DNS, nonché per ottenere l’accesso alle reti interne e ai dispositivi IoT.

I ricercatori hanno scansionato Internet e hanno scoperto che 4,26 milioni di host sono vulnerabili a questi problemi, inclusi server VPN, router (che i provider forniscono ai propri abbonati), router backbone, gateway, nodi di rete mobile e CDN. Va notato che più di 1,8 milioni di questi host vulnerabili possono essere utilizzati per lo spoofing.

La maggior parte degli appliance vulnerabili è stata trovata in Cina, Francia, Giappone, Stati Uniti e Brasile.

4 CVE emesse dai ricercatori

“Tutti gli host vulnerabili possono essere compromessi per effettuare attacchi anonimi perché le intestazioni dei pacchetti esterni contenenti il ​​vero indirizzo IP dell’aggressore vengono rimosse. Tuttavia, questi attacchi possono essere facilmente ricondotti a un host compromesso, che può quindi essere protetto, scrivono i ricercatori. Gli host adatti allo spoofing possono utilizzare qualsiasi indirizzo IP come indirizzo di origine nel pacchetto interno, quindi non solo l’aggressore rimane anonimo, ma l’host compromesso diventa molto più difficile da rilevare e proteggere.”

Di conseguenza, alle vulnerabilità identificate sono stati assegnati gli identificatori CVE CVE-2024-7595 (GRE e GRE6), CVE-2025-23018 (IPv4-in-IPv6 e IPv6-in-IPv6), CVE-2025-23019 (IPv6- in-IPv4) e CVE-2024-7596 (UDP generico Incapsulamento).

“Gli aggressori possono sfruttare queste vulnerabilità per creare proxy unidirezionali e falsificare gli indirizzi di origine IPv4/6”, aggiunge il Centro di coordinamento CERT (CERT/CC). “I sistemi vulnerabili potrebbero anche consentire l’accesso alla rete privata di un’organizzazione o essere utilizzati per condurre attacchi DDoS”.

Per protezione, gli esperti consigliano di utilizzare IPSec o WireGuard per fornire autenticazione e crittografia e di accettare pacchetti sottoposti a tunnel solo da fonti attendibili. Si consiglia inoltre di implementare il filtraggio del traffico a livello di rete su router e nodi intermedi, utilizzare DPI e bloccare tutti i pacchetti sottoposti a tunnel non crittografati.

Dettagli tecnici più approfonditi dello studio sono disponibili in un articolo scientifico già pubblicato da Vanhoof e Baitis.

L'articolo Gravi Vulnerabilità nei Protocolli VPN: 4 Milioni di Sistemi Vulnerabili a Nuovi Bug di Tunneling! proviene da il blog della sicurezza informatica.

L’intelligenza artificiale (AI) applicata alla programmazione sta vivendo una trasformazione epocale, inaugurando una nuova fase che ridefinisce il processo di sviluppo del software. Questi strumenti non si limitano più a supportare gli sviluppatori, ma assumono sempre più responsabilità dirette, rivoluzionando i paradigmi tradizionali. Colossi come Google sfruttano l’AI per generare codice in modo autonomo, velocizzando enormemente i cicli di sviluppo grazie all’analisi contestuale e all’addestramento su vasti set di dati.

Questa rivoluzione tecnologica sta modificando profondamente la professione del programmatore.

Sviluppatori AI: La svolta tecnologica che ci aspetta

Gli sviluppatori si stanno trasformando in supervisori del codice, focalizzandosi sull’ottimizzazione e sull’adattamento dei risultati prodotti dai modelli AI. Gli strumenti avanzati sono ora in grado di analizzare repository contenenti migliaia di file, suggerire miglioramenti e testare ipotesi con una precisione senza precedenti. Modelli di nuova generazione non si limitano a replicare soluzioni esistenti, ma comprendono anche i processi creativi alla base del codice, una competenza cruciale nei progetti complessi.

Le startup tecnologiche, come Cosine, Poolside e Zencoder, sono all’avanguardia nell’implementazione di approcci innovativi per migliorare l’efficienza del codice generato dall’AI. Grazie alla raccolta di dati strutturati sui processi di sviluppo, queste aziende stanno sviluppando modelli capaci di creare soluzioni personalizzate basate su principi logici e di ottimizzazione. La comprensione del contesto progettuale diventa centrale, poiché solo così è possibile produrre codice affidabile e funzionale.

Tra le tecniche di addestramento emergenti spicca la “ricostruzione del processo”, che consente ai modelli di apprendere seguendo i passaggi logici che un programmatore umano compirebbe. Questo approccio, combinato con metodologie di apprendimento per rinforzo come RLCE (Running Code Execution Learning), permette agli algoritmi di testare rapidamente molteplici ipotesi e trovare soluzioni ottimali in tempi ridotti.

Modelli linguistici addestrati sullo sviluppo del codice

Un’altra tendenza significativa è la creazione di modelli linguistici specificamente addestrati sui dati di programmazione. Questo approccio elimina informazioni non pertinenti, migliorando la precisione e le performance rispetto ai modelli generici. Tali innovazioni non solo ottimizzano il processo di sviluppo, ma riducono anche gli errori, consentendo di creare codice di qualità superiore.

L’automazione sta già trasformando il settore, permettendo lo sviluppo simultaneo di più versioni di un prodotto, il testing e la correzione dei bug senza intervento umano. Questo sta spingendo le aziende a ridurre la dimensione dei team di sviluppo, concentrandosi su piccoli gruppi di specialisti altamente qualificati che si dedicano alla gestione del processo piuttosto che alla sua esecuzione.

Il futuro del settore sembra destinato a dipendere meno dal numero di sviluppatori e più dalla potenza dei sistemi di AI. Molte aziende stanno quindi investendo nello sviluppo di modelli specializzati capaci di risolvere problemi complessi e, in prospettiva, di automatizzare interamente il processo di sviluppo del software.

L’AI nella programmazione rappresenta non solo un risparmio di tempo e risorse, ma anche una pietra miliare verso l’innovazione tecnologica e la soluzione di sfide globali. Il software sta diventando sempre più autonomo, aprendo scenari rivoluzionari per l’intero settore e ridefinendo i confini della creatività e dell’ingegneria informatica.

Cosa ne sarà dei programmatori umani?

Con l’introduzione massiccia dell’intelligenza artificiale nello sviluppo del software, una domanda cruciale emerge: quale sarà il futuro dei programmatori umani? Contrariamente alla paura diffusa che l’AI possa rendere obsoleto il lavoro umano, la realtà è più sfumata e complessa.

L’intelligenza artificiale non è un sostituto diretto, ma uno strumento che cambia radicalmente il ruolo dei programmatori. Piuttosto che scrivere manualmente ogni riga di codice, gli sviluppatori stanno diventando supervisori del processo di creazione del software, gestendo modelli AI e perfezionando i loro risultati. In questo contesto, competenze come il debugging, la revisione del codice generato e la comprensione dei requisiti di progetto diventano centrali.

L’introduzione sempre più diffusa dell’intelligenza artificiale nello sviluppo software comporterà inevitabilmente una flessione nel numero complessivo di addetti ai lavori. Compiti di routine come la scrittura di codice standard, la creazione di test unitari e la gestione di configurazioni sono ora automatizzabili grazie ai modelli AI avanzati. Questo riduce la necessità di grandi team di programmatori e orienta il settore verso una maggiore efficienza con un numero inferiore di risorse umane.

Di conseguenza, molte posizioni di livello base, che un tempo rappresentavano un punto d’ingresso per i nuovi sviluppatori, potrebbero gradualmente scomparire, lasciando spazio a ruoli più specializzati e qualificati.

L'articolo Verso lo Sviluppo Autonomo del Software: Come l’AI sta cambiando la Programmazione proviene da il blog della sicurezza informatica.

WhatsApp dichiara di adottare un meccanismo di crittografia end-to-end (E2E) basato sul Protocollo Signal (noto precedentemente come “TextSecure Protocol”). L’assunto di fondo di un sistema E2E è che soltanto i dispositivi dei due interlocutori gestiscano le chiavi di crittografia necessarie alla cifratura e decifratura dei messaggi, escludendo chiunque altro (inclusi i server dell’azienda fornitrice).

Tuttavia, i test sperimentali condotti suggeriscono che Meta potrebbe conservare le chiavi utilizzate per crittografare e decrittare i messaggi degli utenti. Questa ipotesi si basa su un’osservazione specifica: la capacità di ricevere messaggi da nuovi contatti su WhatsApp Web o sull’app desktop anche quando lo smartphone è spento.

Questo comportamento indica che le chiavi crittografiche non sono archiviate esclusivamente sugli smartphone, un requisito fondamentale per garantire la crittografia ‘End-to-End’. Infatti, se le chiavi fossero presenti solo sui dispositivi mobili, sarebbe tecnicamente e logicamente impossibile comunicare con nuovi contatti senza il telefono connesso.

Di conseguenza, il fatto che questa comunicazione avvenga anche a telefono spento dimostra che le chiavi crittografiche potrebbero essere conservate in altri sistemi, non limitandosi ai nostri dispositivi personali.

Queste assunzioni generano forti dubbi sulla reale efficacia del canale E2E e sulla conformità alla stessa Privacy Policy di WhatsApp.

1. Meccanismi di scambio delle chiavi simmetriche (Diffie-Hellman)

1.1 Diffie-Hellman “classico”

Per lo scambio di chiavi simmetriche abbiamo tendenzialmente tre tecniche:

• Offline Distribution
• Public Key Tunneling
• Diffie-Hellman

Usiamo l’offline distribution quando possiamo comunicare verbalmente con un altro soggetto, fornendogli la credenziale senza l’uso di supporti elettronici. Questo chiaramente non è applicabile per comunicazioni da remoto, quindi la quasi totalità.

Per questo motivo è necessario usare una delle altre due opzioni, per la public key tunneling serve un certificato X.509 che contenga la chiave pubblica (come nel caso di HTTPS) o un meccanismo di exchange della chiave pubblica compatibile per entrambi i dispositivi.

Siccome i nostri dispositivi non posseggono un certificato, l’unica tecnica applicabile è la terza, che permette di sfruttare un algoritmo matematico in grado di scambiare chiavi crittografiche senza la necessità di acquistare un certificato firmato da una CA (Certificate Authority) riconosciuta.

Il protocollo Diffie-Hellman (DH) consente a due entità (in questo esempio Alice e Bob) di stabilire una chiave simmetrica condivisa su un canale insicuro:

1. Si sceglie un numero primo p di grandi dimensioni e una radice primitiva g modulo p.
2. Alice genera un valore privato a e calcola la chiave pubblica A=gamod p
3. Bob genera un valore privato b e calcola la chiave pubblica B=gbmod p
4. Alice e Bob si scambiano le chiavi pubbliche A e B rispettivamente.
5. Alice calcola K = Ba mod p, Bob calcola K = Ab mod p. Entrambi ottengono la medesima chiave condivisa K=gab mod p.

In un contesto di crittografia moderna, questa chiave simmetrica K è poi utilizzata (ad esempio) da un algoritmo AES-256 in modalità GCM o CTR per cifrare il traffico.

1.2 Codice Python esplicativo

#!/usr/bin/env python3

import random

def diffie_hellman_demo():
# Scelta di un numero primo p e di una radice primitiva g (esempio didattico)
p = 23
g = 5

print(f"Valore di p (primo): {p}")
print(f"Valore di g (radice primitiva modulo p): {g}\n")

# Alice genera il proprio valore privato a
# (in uno scenario reale si utilizzano valori molto più grandi e sicuri)
a = random.randint(2, p-2)
print(f"Alice sceglie il valore privato a: {a}")

# Alice calcola la propria chiave pubblica A = g^a mod p
A = pow(g, a, p)
print(f"Alice calcola la chiave pubblica A = g^a mod p: {A}\n")

# Bob genera il proprio valore privato b
b = random.randint(2, p-2)
print(f"Bob sceglie il valore privato b: {b}")

# Bob calcola la propria chiave pubblica B = g^b mod p
B = pow(g, b, p)
print(f"Bob calcola la chiave pubblica B = g^b mod p: {B}\n")

# Alice e Bob si scambiano le chiavi pubbliche A e B (canale insicuro)

# Alice calcola la chiave condivisa K_A = B^a mod p
K_A = pow(B, a, p)
print(f"Alice calcola la chiave condivisa K_A = B^a mod p: {K_A}")

# Bob calcola la chiave condivisa K_B = A^b mod p
K_B = pow(A, b, p)
print(f"Bob calcola la chiave condivisa K_B = A^b mod p: {K_B}\n")

# Verifica che le due chiavi coincidano
if K_A == K_B:
print(f"Chiave condivisa K calcolata correttamente: {K_A}")
else:
print("ERRORE: le chiavi non corrispondono!")

if __name__ == "__main__":
diffie_hellman_demo()

RUNTIME OUTPUT :

Valore di p (primo): 23
Valore di p (primo): 23
Valore di g (radice primitiva modulo p): 5
Valore di g (radice primitiva modulo p): 5

Alice sceglie il valore privato a: 19
Alice calcola la chiave pubblica A = g^a mod p: 7

Bob sceglie il valore privato b: 13
Bob calcola la chiave pubblica B = g^b mod p: 21
Alice sceglie il valore privato a: 19
Alice calcola la chiave pubblica A = g^a mod p: 7

Bob sceglie il valore privato b: 13
Bob calcola la chiave pubblica B = g^b mod p: 21
Alice calcola la chiave pubblica A = g^a mod p: 7

Bob sceglie il valore privato b: 13
Bob calcola la chiave pubblica B = g^b mod p: 21

Bob sceglie il valore privato b: 13
Bob calcola la chiave pubblica B = g^b mod p: 21
Bob sceglie il valore privato b: 13
Bob calcola la chiave pubblica B = g^b mod p: 21
Bob calcola la chiave pubblica B = g^b mod p: 21

Alice calcola la chiave condivisa K_A = B^a mod p: 20
Alice calcola la chiave condivisa K_A = B^a mod p: 20
Bob calcola la chiave condivisa K_B = A^b mod p: 20

Chiave condivisa K calcolata correttamente: 20

1.3 Varianti e Double Ratchet

WhatsApp si basa su un’implementazione evoluta del Protocollo Signal, che sfrutta:

• X3DH (Extended Triple Diffie-Hellman) per la fase di handshake iniziale, in cui si combinano chiavi “a lungo termine” (Identity Key), chiavi “semi-persistenti” (Signed PreKeys) e chiavi effimere (One-Time PreKeys).
• Double Ratchet per la fase di aggiornamento continuo delle chiavi a ogni messaggio o gruppo di messaggi, garantendo forward secrecy e post-compromise security.

Nel modello teorico, l’utente (sul proprio dispositivo) dovrebbe detenere tutte le chiavi private necessarie, mentre il server memorizza soltanto le chiavi pubbliche (prekey) per favorire la consegna dei messaggi offline. L’esperimento mostrato più avanti, però, insinua che WhatsApp gestisca in modo meno trasparente parte delle chiavi di sessione, specie in ambienti multi-dispositivo (app, web, desktop).

2. Architettura di WhatsApp dal punto di vista crittografico

2.1 Struttura multi-dispositivo

In passato, WhatsApp Web agiva come semplice “mirror” dello smartphone primario, richiedendo la connessione attiva del telefono. Con le versioni più recenti, è ora possibile utilizzare WhatsApp Web (O l’app per Desktop) anche se il telefono risulta offline, a patto che sia stato registrato il dispositivo prima dello spegnimento dello smartphone.

Questo cambio di paradigma potrebbe permettere a Meta di memorizzare le chiavi crittografiche degli utenti, rompendo di fatto il vincolo di confidenzialità delle chat propugnato nella Privacy Policy.

2.2 Sincronizzazione chiavi e potenziale “key escrow”

Per rendere operativo questo meccanismo, WhatsApp (Meta) deve memorizzare o sincronizzare parte del materiale crittografico su server propri. Questo processo potrebbe includere alcune PSK (chiavi crittografiche simmetriche) utilizzate per stabilire una chat con un contatto con cui non si sono mai scambiati messaggi prima di spegnere il telefono e messaggiare su whatsapp web.

Se tali chiavi sono accessibili ai server, allora la promessa di una crittografia end-to-end “pura” viene quantomeno scalfita, poiché l’intermediario (Meta) può intervenire o ricostruire una parte delle chiavi.

Le chiavi di cui stiamo parlando sono diverse per ogni contatto e vengono negoziate e scambiate nel primo messaggio ricevuto o inviato da e ad un contatto nuovo.

2.3 Implicazioni di sicurezza

Un server che disponga delle chiavi può, di fatto, decriptare i messaggi o fornirne il contenuto a terze parti. Nel contesto legale, si tratta di una forma non dichiarata di “escrow”. In termini tecnici, questa gestione potrebbe essere giustificata come “necessaria per il multi-device”, ma non rispetterebbe l’idea di E2E in senso stretto.

Meta quindi potrebbe essere in grado di decriptare le nostre conversazioni, le nostre telefonate e persino le nostre foto e video. Questo costituisce un rischio enorme per la privacy degli utenti della piattaforma.

3. Proof of Concept (PoC)

3.1 Scenario

Si vuole mostrare come, per un nuovo contatto (un utente che non ha mai inviato prima messaggi), sia possibile ricevere il primo messaggio direttamente su WhatsApp Web, mentre lo smartphone rimane spento.

3.2 Passi sperimentali

1. Autenticazione su WhatsApp Web: prima di spegnere lo smartphone, si effettua il login a WhatsApp Web (QR code).
2. Spegnimento del telefono.
3. Invio del messaggio: un contatto “mai visto prima” invia il primo messaggio verso l’account WhatsApp in questione.
4. Osservazione: su WhatsApp Web, il messaggio appare correttamente, nonostante l’assenza di qualsivoglia scambio di chiavi dal telefono spento.
5. Cattura di rete: con Wireshark si analizza il flusso tra il PC e i server WhatsApp, evidenziando che si instaura una sessione cifrata (TLS) ma non risulta alcuna negoziazione implicita con il dispositivo mobile per la generazione di nuove chiavi.

3.3 Conclusioni del test

È evidente che i server di WhatsApp consentano la creazione di una sessione (o il recupero di chiavi preesistenti) anche per i contatti non precedentemente in chat, senza alcuna “nuova” partecipazione del telefono primario. In un sistema E2E puro, invece, la negoziazione iniziale dovrebbe avvenire direttamente tra i due dispositivi coinvolti (mittente e destinatario).

4. Discrepanze rispetto alla Privacy Policy

La Privacy Policy di WhatsApp dichiara testualmente:

“I messaggi e le chiamate rimangono tra te e chi li riceve. Nemmeno WhatsApp può leggerli o ascoltarli, perché sono protetti dalla crittografia end-to-end.”

Tuttavia, il PoC dimostra:

1. Possibile conservazione delle chiavi: Le prove indicano che Meta gestisca o memorizzi chiavi (o prekey) in un modo che consenta l’attivazione di nuove sessioni con contatti “mai visti” anche a telefono offline.
2. “Key escrow” non dichiarato: Se i server possono ricostruire le chiavi necessarie a decrittare i messaggi, la confidenzialità end-to-end “piena” non è più rispettata.
3. Gestione multi-dispositivo poco trasparente: La documentazione fornita da WhatsApp non spiega in dettaglio come e dove vengano mantenute le chiavi.

Conclusioni

L’esperimento illustrato dimostra una caratteristica preoccupante nella gestione delle chiavi crittografiche di WhatsApp. Nel momento in cui si riceve un messaggio da un contatto “mai visto” su WhatsApp Web con il telefono spento, si evidenzia che Meta conserva o è in grado di rigenerare la chiave necessaria all’avvio della sessione cifrata, senza richiedere la partecipazione del dispositivo mobile.

Sebbene WhatsApp affermi di utilizzare il Signal Protocol (rinomato per la robusta E2E) — e in effetti ne adotti gran parte delle tecniche (X3DH e Double Ratchet) — la gestione del multi-dispositivo non è documentata in modo trasparente.Gli utenti non sanno esattamente dove vengano conservate le chiavi, né con quale logica vengano sincronizzate o replicate.

Implicazioni:

• Si configura un potenziale “key escrow” non dichiarato, per cui Meta può (forse su richiesta legale, o per finalità di debug e controllo) accedere al contenuto dei messaggi.
• Questo contrasta con l’idea di un E2E “assoluto”, in cui solo gli endpoint (i dispositivi dei due interlocutori) possiedono i segreti per decrittare i messaggi.
• Vi è una discrepanza evidente con la Privacy Policy di WhatsApp, che suggerisce un’impossibilità da parte di WhatsApp di accedere ai contenuti delle conversazioni.

L'articolo I Messaggi WhatsApp Sono Veramente Privati? Ecco Cosa Abbiamo Scoperto proviene da il blog della sicurezza informatica.

L'opposizione slovacca ha ritirato la propria partecipazione alla seduta parlamentare straordinaria in cui si sarebbe dovuta votare la mozione di sfiducia al governo.



La decisione è stata presa in segno di protesta nei confronti del premier Robert Fico, che in mattinata aveva stabilito che la seduta si sarebbe dovuta tenere a porte chiuse. 

Fico aveva motivato questa mossa sulla base di alcune informazioni ricevute dai servizi segreti slovacchi secondo cui ci sarebbero delle influenze che vorrebbero destabilizzare la Slovacchia e organizzare una sorta di Maidan. 



La decisione, la prima di questo tipo nella storia della Slovacchia democratica, ha creato un grande clima di tensione e per tale motivo la seduta è stata annullata. Probabilmente verrà riprogrammata nei prossimi giorni.


Domani il presidente Peter Pellegrini si recherà nella sede dei servizi segreti per ottenere maggiori informazioni.

🇸🇰 La notizia di oggi in questa parte d'Europa è il voto sulla mozione di sfiducia al governo slovacco che si terrà nelle prossime ore. Difficile che passi, ma è il sintomo che per Fico le cose non stanno andando proprio benissimo.

A portare al voto di oggi è stato il viaggio a Mosca prima di Natale, in cui il premier slovacco è andato a chiedere aiuto a Putin a fronte dell'imminente stop al transito del gas russo, deciso da Kyiv, attraverso il territorio ucraino.

La mossa di Fico non è piaciuta a Hlas, il partito del presidente Pellegrini, alleato di governo, che teme una deriva antieuropa e anti NATO. Le opposizioni hanno come si suol dire, fiutato il sangue, e annunciato la mozione di sfiducia.

Una decina di giorni fa una partecipata manifestazione, a Bratislava ma anche in altre città della Slovacchia, aveva manifestato aperto dissenso verso le politiche di Fico, più preoccupato ad accattivarsi il benvolere di Putin che a governare il Paese.

A cavalcare questo momento è Michal Šimečka, leader di Slovacchia Progressista, principale partito di opposizione, che secondo i sondaggi oggi sarebbe il primo partito con il 23,9% delle preferenze. (Smer il partito di Fico è al 18%).

Come detto, è difficile che la mozione di oggi passi. I deputati di Hlas non sembrano intenzionati ad appoggiarla, tuttavia le possibilità non stanno a zero.

Formalmente oggi la maggioranza è di un solo deputato (76 su 150), per quanto i tre ribelli ultranazionalisti continuino comunque a votare in linea col governo.

Insomma, nella piccola Slovacchia non ci si annoia mai.