Un hacker ha minacciato di divulgare 106 GB di dati presumibilmente rubati alla compagnia di telecomunicazioni spagnola Telefónica. L’azienda nega l’attacco informatico e la fuga di dati. L’aggressore, soprannominato Rey, sostiene che l’attacco sia avvenuto il 30 maggio e che abbia impiegato più di 12 ore a estrarre dati dalla rete aziendale prima che il suo accesso venisse bloccato.

Ha ora pubblicato un archivio di 2,6 GB di pubblico dominio, che contiene circa cinque gigabyte di dati e oltre 20.000 file dopo la decompressione. Rey è un membro del gruppo ransomware Hellcat, che si è assunto la responsabilità di un altro attacco informatico ai danni di Telefónica nel gennaio 2025, che ha compromesso il server interno di sviluppo e ticketing di Jira.

Rey ha dichiarato ai giornalisti di aver rubato 385.311 file, per un totale di 106,3 GB, dalla rete aziendale. I file contenevano presumibilmente comunicazioni interne (inclusi ticket ed email), ordini di acquisto, registri interni, registri dei clienti e dati dei dipendenti. L’hacker sostiene inoltre che il nuovo attacco è stato nuovamente causato da impostazioni Jira errate e che si è verificato dopo il primo attacco.

Rey ha condiviso con la pubblicazione campioni di dati e un albero di file presumibilmente rubati a Telefónica. Alcuni dei file contenevano fatture di clienti aziendali in paesi come Ungheria, Germania, Spagna, Cile e Perù. I file contenevano anche indirizzi email di dipendenti in Spagna, Germania, Perù, Argentina e Cile, nonché fatture emesse a partner commerciali in paesi europei.

Nonostante i giornalisti abbiano ripetutamente tentato di contattare i rappresentanti di Telefónica, l’unica risposta ricevuta è stata che il presunto incidente era un tentativo di estorsione e che gli aggressori stavano utilizzando informazioni obsolete ottenute durante un attacco precedente.

Il file più recente che i giornalisti sono riusciti a trovare tra i campioni di dati forniti dall’hacker è datato 2021, il che conferma le parole del rappresentante dell’azienda. Tuttavia, Rey continua a sostenere che i dati siano stati ottenuti in seguito a un nuovo attacco informatico avvenuto il 30 maggio. Per dimostrare la sua tesi, ha iniziato a pubblicare i dati dell’azienda nel pubblico dominio.

“Dato che Telefónica nega la recente fuga di notizie di 106 GB contenenti dati provenienti dalla sua infrastruttura interna, pubblicherò 5 GB come prova. Pubblicherò presto l’intero archivio e, se Telefónica non ottempera, l’intero archivio sarà pubblicato nelle prossime settimane”, scrive Rey.

Inizialmente, i dati presumibilmente rubati sono stati distribuiti tramite il servizio PixelDrain, ma sono stati rimossi poche ore dopo per motivi legali. In seguito, l’aggressore ha distribuito un altro link per il download del dump, questa volta dal servizio Kotizada, che Google Chrome contrassegna come pericoloso e consiglia vivamente agli utenti di evitarlo.

Sebbene Telefónica non abbia rilasciato dichiarazioni ufficiali, i giornalisti sottolineano che alcuni degli indirizzi e-mail inclusi nella fuga di notizie appartengono ad attuali dipendenti dell’azienda.

L'articolo Un Criminal Hacker minaccia di divulgare 106 GB di dati rubati a Telefónica proviene da il blog della sicurezza informatica.

De Algemene Ledenvergadering van de Piratenpartij Nederland heeft Matthijs Pontier uit Amsterdam opnieuw tot lijsttrekker gekozen. Voor de rol van lijsttrekker hadden zich acht kandidaten verkiesbaar gesteld. De Piratenpartij is een internationale politieke beweging die zich inzet voor mensenrechten, democratie, transparantie en vrije toegang tot informatie. Pontier was eerder lijsttrekker bij de landelijke verkiezingen in […]

Het bericht Matthijs Pontier verkozen tot lijsttrekker Piratenpartij verscheen eerst op Piratenpartij.

Gli esperti hanno identificato gravi vulnerabilità in SMBClient per macOS che interessano sia lo spazio utente che il kernel del sistema operativo. Queste vulnerabilità consentono potenzialmente l’esecuzione remota di codice arbitrario e l’interruzione di processi di sistema critici. Durante l’analisi, è emerso chiaramente che un’ampia gamma di utenti è a rischio, dato che a partire da macOS Big Sur, il protocollo SMB è diventato il metodo preferito per organizzare la condivisione di file in rete.

SMBClient è un insieme di componenti, che include sia processi utente che driver del kernel, progettati per funzionare con file system accessibili tramite risorse di rete. Una parte significativa del codice client SMB interagisce direttamente con il kernel del sistema, il che apre ulteriori vettori di attacco. Inoltre, è possibile sfruttare le vulnerabilità con un intervento minimo dell’utente: è sufficiente costringere una persona a seguire un collegamento appositamente predisposto del tipo smb://.

La prima delle vulnerabilità scoperte è il CVE-2025-24269 (punteggio CVSS: 9,8) ed è correlata al componente smbfs.kext, il driver del kernel macOS per l’utilizzo di SMB. Il problema risiede nella funzione di elaborazione dei dati compressi smb2_rq_decompress_read, dove in alcuni casi la lunghezza dei dati in ingresso viene verificata in modo errato. Se viene utilizzato uno degli algoritmi di compressione supportati – LZNT1, LZ77 o LZ77_Huffman – il campo speciale compress_len viene letto dal pacchetto di rete, ma il suo valore non viene convalidato in alcun modo prima di copiare i dati nel buffer compress_startp. Allo stesso tempo, la macro SMB_MALLOC_DATA, utilizzata per allocare la memoria, consente a un aggressore di controllare la dimensione del blocco allocato, che può raggiungere fino a 16 megabyte.

Di conseguenza, si verifica un overflow di memoria dinamica all’interno dell’heap dati xnu, un’area della memoria del kernel in cui la presenza di puntatori di controllo è limitata da meccanismi di protezione aggiuntivi, ma è impossibile escludere completamente la possibilità di sfruttare tale difetto. Gli esperti sottolineano che, per un attacco riuscito, è sufficiente convincere l’utente a cliccare su un collegamento smb:// dannoso, che consentirà all’attaccante di avviare l’interazione con il server vulnerabile e attivare la trasmissione di pacchetti appositamente preparati.

La seconda vulnerabilità, identificata come CVE-2025-24235 (punteggio CVSS: 5,5), riguarda la libreria Kerberos Helper utilizzata per stabilire una sessione SMB. Qui è stato rilevato un classico errore di sicurezza: la liberazione di una variabile di stack non inizializzata. Durante l’analisi dei token di autenticazione nella funzione _KRBDecodeNegTokenInit, potrebbe verificarsi una situazione in cui la chiamata interna a _gss_decapsulate_token fallisce. Tuttavia, anche in questo caso, il controllo viene trasferito al blocco di rilascio della memoria, dove la funzione _free_NegotiationToken opera con un’area di stack non inizializzata.

Un’analisi più approfondita ha mostrato che il processo di liberazione della memoria richiama la funzione _asn1_free della libreria Heimdal, progettata per analizzare e cancellare le strutture ASN.1. Poiché la struttura da liberare non è stata inizializzata, sussiste il rischio di un accesso incontrollato alla memoria, che potrebbe potenzialmente portare all’esecuzione di codice arbitrario sul dispositivo della vittima. Per un attacco riuscito, è sufficiente utilizzare meccanismi di connessione standard, ad esempio seguendo un collegamento smb:// o montando una risorsa tramite mount_smbfs.

La terza vulnerabilità, sebbene non abbia ricevuto un identificativo CVE ufficiale, è comunque considerata critica. È correlata a un’implementazione errata del meccanismo di registrazione del processo mc_notifier nel modulo smbfs. Questo servizio è responsabile delle notifiche quando le risorse di rete vengono smontate. Un utente con qualsiasi livello di privilegio può registrare un identificativo di processo arbitrario utilizzando la richiesta ioctl SMBIOC_UPDATE_NOTIFIER_PID. Se la risorsa viene quindi smontata, il kernel di sistema invierà al processo registrato un segnale SIGTERM, ovvero la terminazione standard.

Il problema è che il kernel non verifica i permessi del processo chiamante né la correttezza dell’identificatore specificato. Ciò consente a un aggressore di terminare quasi tutti i processi del sistema, incluso il processo critico launchd, responsabile dell’avvio e della gestione di tutti i servizi utente e di sistema. Di conseguenza, il sistema si trova in uno stato inoperativo e richiede un riavvio. Allo stesso tempo, per sfruttare questa vulnerabilità, è sufficiente avere accesso al dispositivo e la possibilità di aprire il dispositivo /dev/nsmb, operazione possibile nella maggior parte degli scenari anche senza uscire dall’isolamento utente (sandbox).

Apple ha già risolto tutte e tre le vulnerabilità. In particolare, è stato aggiunto un controllo della lunghezza del blocco di dati compressi alla funzione di elaborazione dei pacchetti SMB per prevenire la possibilità di un overflow di memoria. Inoltre, la libreria Kerberos Helper ora pulisce preventivamente la struttura NegotiationToken prima di utilizzarla e liberarla, impedendo così lo sfruttamento del difetto. Per il meccanismo di registrazione mc_notifier, è stato implementato un controllo dei permessi dell’utente che richiama l’ioctl SMBIOC_UPDATE_NOTIFIER_PID, che elimina la possibilità di terminazione incontrollata di processi arbitrari.

L'articolo Vulnerabilità critiche in SMBClient per macOS. 9.8 su 10 per una efficace RCE proviene da il blog della sicurezza informatica.

😁😁😁

#Musk #Tesla #teslashares

Aside from GPUs, you don’t hear much about co-processors these days. [bitluni] perhaps missed those days, because he found a way to squeeze a 160 core RISC V supercluster onto a single m.2 board,and shared it all on GitHub.

OK, sure, each core isn’t impressive– he’s using CH32V003, so each core is only running at 48 MHz, but with 160 of them, surely it can do something? This is a supercomputer by mid-80s standards, after all. Well, like anyone else with massive parallelism, [bitluni] decided to try a raymarcher. It’s not going to replace RTX anytime soon, but it makes for a good demo.

Like his previous m.2 project, an LED matrix, the cluster is communicating over PCIe via a WCH CH382 serial interface. Unlike that project, blinkenlights weren’t possible: the tiny, hair-thin traces couldn’t carry enough power to run the cores and indicator LEDs at once. With the power issue sorted, the serial interface is the big bottleneck. It turns out this cluster can crunch numbers much faster than it can communicate. That might be a software issue, however, as the cluster isn’t using all of the CH382’s bandwidth at the moment. While that gets sorted there are low-bandwidth, compute-heavy tasks he can set for the cluster. [bitluni] won’t have trouble thinking of them; he has a certain amount of experience with RISCV microcontroller clusters.

We were tipped off to this video by [Steven Walters], who is truly a prince among men. If you are equally valorous, please consider dropping informational alms into ourever-present tip line.

youtube.com/embed/HRfbQJ6FdF0?…

hackaday.com/2025/07/07/160-co…