Negli ultimi anni, la digitalizzazione crescente del settore ferroviario ha portato all’introduzione di dispositivi sempre più complessi per la gestione dei treni, migliorando l’efficienza operativa ma, al tempo stesso, ampliando la superficie di attacco potenziale per minacce informatiche.

Nello specifico i ricercatori Neil Smith ed Eric Reuter hanno segnalato una vulnerabilità di CWE-1390: Weak Authentication, monitorata con il codice CVE-2025-1727, che riguarda i protocolli di collegamento remoto End-of-Train e Head-of-Train utilizzati nell’infrastruttura di trasporto degli Stati Uniti. Lo sfruttamento di questa vulnerabilità potrebbe consentire a un aggressore di inviare i propri comandi di controllo dei freni al dispositivo di fine treno, provocando un arresto improvviso del treno che potrebbe causare un’interruzione delle operazioni o un guasto dei freni.

Il bollettino pubblicato da CISA il 10 luglio 2025 richiama l’attenzione sulle vulnerabilità individuate nei protocolli ferroviari gestiti dal Comitato per gli Standard Elettronici Ferroviari (RESC) dell’AAR, coinvolgendo fornitori del calibro di Hitachi Rail STS USA, Wabtec e Siemens.

Sebbene non siano stati segnalati exploit pubblici o casi concreti di compromissione, il documento fornisce raccomandazioni pratiche per ridurre i rischi, invitando le organizzazioni ferroviarie a rafforzare le misure difensive, limitare l’esposizione dei dispositivi alle reti pubbliche e adottare strategie di sicurezza proattive.

L’Associazione delle Ferrovie Americane (AAR) sta sviluppando nuove apparecchiature e protocolli che dovrebbero sostituire i tradizionali dispositivi di fine treno e di testa treno. I comitati di standardizzazione coinvolti in questi aggiornamenti sono consapevoli della vulnerabilità e stanno studiando soluzioni per mitigarla. CISA consiglia agli utenti di dispositivi EoT/HoT di contattare i rispettivi produttori per eventuali domande.

La CISA raccomanda agli utenti di adottare misure difensive per ridurre al minimo il rischio di sfruttamento di questa vulnerabilità, come ad esempio:

• Ridurre al minimo l’esposizione alla rete per tutti i dispositivi e/o sistemi del sistema di controllo, assicurandosi che non siano accessibili da Internet .
• Individuare le reti dei sistemi di controllo e i dispositivi remoti dietro i firewall e isolarli dalle reti aziendali.
• Quando è necessario l’accesso remoto, utilizzare metodi più sicuri, come le reti private virtuali (VPN), tenendo presente che le VPN potrebbero presentare vulnerabilità e dovrebbero essere aggiornate alla versione più recente disponibile. È inoltre importante ricordare che una VPN è sicura quanto lo sono i dispositivi connessi.

CISA incoraggia le organizzazioni a implementare le strategie di sicurezza informatica consigliate per la difesa proattiva delle risorse ICS. Le organizzazioni che osservano sospette attività dannose devono seguire le procedure interne stabilite e segnalare i risultati alla CISA affinché possano essere monitorati e correlati ad altri incidenti.

L'articolo Il CISA Avverte che un bug critico nei treni USA potrebbe portare all’arresto improvviso proviene da il blog della sicurezza informatica.

After the fire and fury of liftoff, when a spacecraft is sailing silently through space, you could be forgiven for thinking the hard part of the mission is over. After all, riding what’s essentially a domesticated explosion up and out of Earth’s gravity well very nearly pushes physics and current material science to the breaking point.

But in reality, getting into space is just the first on a long list of nearly impossible things that need to go right for a successful mission. While scientific experiments performed aboard the International Space Station and other crewed vehicles have the benefit of human supervision, the vast majority of satellites, probes, and rovers must be able to operate in total isolation. With nobody nearby to flick the power switch off and on again, such craft need to be designed with multiple layers of redundant systems and safe modes if they’re to have any hope of surviving even the most mundane system failure.

That said, nobody can predict the future. Despite the best efforts of everyone involved, there will always be edge cases or abnormal scenarios that don’t get accounted for. With proper planning and a pinch of luck, the majority of missions are able to skirt these scenarios and complete their missions without serious incident.

Unfortunately, Lunar Trailblazer isn’t one of those missions. Things started well enough — the February 26th launch of the SpaceX Falcon 9 went perfectly, and the rocket’s second stage gave the vehicle the push it needed to reach the Moon. The small 210 kg (460 lb) lunar probe then separated from the booster and transmitted an initial status message that was received by the Caltech mission controllers in Pasadena, California which indicated it was free-flying and powering up its systems.

But since then, nothing has gone to plan.

Spotty Communications

According to NASA’s blog for Lunar Trailblazer, Caltech first heard from the spacecraft about 12 minutes after it separated from the second stage of the Falcon 9. At this point the spacecraft was at an altitude of approximately 1,800 kilometers (1118 miles) and had been accelerated by the booster to a velocity of more than 33,000 km/h (20,500 mph). The craft was now committed to a course that would take it away from Earth, although further course correction maneuvers would be required to put it into its intended orbit around the Moon.

The team on the ground started to receive the expected engineering telemetry data from the vehicle, but noted that there were some signals that indicated intermittent issues with the power supply. Around ten hours later, the Lunar Trailblazer spacecraft went completely silent for a short period of time before reactivating its transmitter.

At this point, it was obvious that something was wrong, and ground controllers started requesting more diagnostic information from the spacecraft to try and determine what was going on. But communication with the craft remained unreliable, at best. Even with access to NASA’s powerful Deep Space Network, the controllers could not maintain consistent contact with the vehicle.

Tumbling and Off-Course

On March 2nd, ground-based radars were able to get a lock on Lunar Trailblazer. The good news was that the radar data confirmed that the spacecraft was still intact. The bad news is that the team at Caltech now had a pretty good idea as to why they were only getting sporadic communications from the vehicle — it was spinning in space.

This might not seem like a problem at first, indeed some spacecraft use a slight spin to help keep them stabilized. But in the case of Lunar Trailblazer, it meant the vehicle’s solar arrays were not properly orientated in relation to the sun. The occasional glimpses of sunlight the panels would get as the craft tumbled explained the sporadic nature of its transmissions, as sometimes it would collect just enough power to chirp out a signal before going dead again.
Lunar Trailblazer was designed to scan the lunar surface for signs of water from an altitude of 100 km (62 miles).
But there was a now a new dimension to the problem. By March 4th, the the spacecraft was supposed to have made the first of several trajectory correction maneuvers (TCMs) to refine its course towards the Moon. As those TCMs never happened, Lunar Trailblazer was now off-course, and getting farther away from its intended trajectory every day.

By now, ground controllers knew it was unlikely that Lunar Trailblazer would be able to complete all of the mission’s science goals. Even if they could reestablish communication, the vehicle wasn’t where it was supposed to be. While it was still theoretically possible to compute a new course and bring the vehicle into lunar orbit, it wouldn’t be the one that the mission’s parameters called for.

A Data-Driven Recovery Attempt

The mission was in a bad place, but the controllers at Caltech still had a few things going in their favor. For one, they knew exactly what was keeping them from communicating with the spacecraft. Thanks to the ongoing radar observations, they also had highly-accurate data on the velocity, position, and rotation rate of the craft. Essentially, they knew what all the variables were, they just needed to figure out the equation that would provide them with a solution.

Over the next couple of months, the data from the radar observations was fed into a computer model that allowed ground controllers to estimate how much sunlight would hit Lunar Trailblazer’s solar array at a given time. Engineers worked with a replica of the spacecraft’s hardware to better understand not only how it operated while in a low-power state, but how it would respond when it got a sudden jolt of power.

The goal was to find out exactly how long it would take for the spacecraft to come back to a workable state when the solar array was lit, and then use the model to find when the vehicle and the sun would align for long enough to make it happen.

It was originally believed that they only had until June for this celestial alignment to work in their favor, but refined data allowed NASA and Caltech to extend that timetable into the middle of July. With that revised deadline fast approaching, we’re eager to hear an update from the space agency about the fate of this particularly tenacious lunar probe.

hackaday.com/2025/07/15/the-fi…

Una nuova forma di attacco digitale chiamata RenderShock ha colpito i sistemi Windows aziendali Non richiede clic o l’apertura di allegati: tutto avviene completamente in background, tramite meccanismi di anteprima e indicizzazione affidabili integrati nel sistema operativo stesso. A differenza dei malware classici, RenderShock utilizza le cosiddette superfici di esecuzione passive, ovvero servizi che vengono eseguiti automaticamente ed elaborano i file senza l’intervento dell’utente. Tra questi collegamenti vulnerabili figurano i pannelli di anteprima di Explorer, gli scanner antivirus, i servizi di indicizzazione e gli strumenti di sincronizzazione cloud.

L’idea principale dell’attacco è quella di utilizzare processi di sistema affidabili per elaborare file palesemente dannosi. È sufficiente che un file di questo tipo finisca in una cartella disponibile per l’anteprima o l’indicizzazione, perché il meccanismo di infezione venga immediatamente attivato. Questo può accadere se il file finisce nella posta aziendale, su un’unità condivisa, in una cartella cloud o tramite un’unità flash. Anche il semplice passaggio del cursore sul file può portare a un tentativo di connessione a un server remoto.

RenderShock funziona secondo uno schema chiaramente strutturato in cinque fasi. Innanzitutto, viene creato un file dannoso, che può essere un documento, un’immagine, un collegamento. In seguito, gli aggressori inseriscono tali file in posizioni in cui i sistemi hanno la certezza di rilevarli. Successivamente, l’attivazione automatica avviene quando il file interagisce con uno dei componenti passivi del sistema. A questo punto inizia la raccolta di informazioni, ad esempio inviando richieste DNS o catturando hash NTLM per rubare le credenziali. La fase finale è l’esecuzione di codice remoto o l’ulteriore penetrazione nell’infrastruttura.

Il pericolo particolare di RenderShock è che l’attacco si maschera come un’attività standard dei processi di sistema. I processi explorer.exe, searchindexer.exe o l’anteprima dei documenti di Microsoft Office eseguono “azioni normali” e rimangono inosservati dalla maggior parte dei sistemi di sicurezza. La maggior parte degli antivirus aziendali non monitora l’attività di rete di tali processi, il che significa che non possono reagire in tempo.

Un esempio mostra come un file LNK infetto all’interno di un archivio ZIP possa forzare Windows Explorer a scaricare un’icona tramite SMB da un server remoto. Il sistema trasmette automaticamente i dati di autenticazione, anche se l’utente non ha aperto nulla. Tali azioni avvengono istantaneamente e in modo occulto.

Il nuovo schema RenderShock dimostra chiaramente come anche le operazioni di routine e apparentemente sicure stiano diventando vulnerabili negli ambienti aziendali odierni. Le organizzazioni che si affidano ad anteprime integrate e indicizzazione automatica dovrebbero riconsiderare le proprie pratiche di sicurezza.

Gli esperti raccomandano di disabilitare le anteprime dei file, limitare il traffico SMB in uscita, rafforzare le impostazioni di sicurezza di Office e monitorare le attività atipiche dei processi relativi alle anteprime. RenderShock mette in discussione i principi fondamentali della fiducia nei propri sistemi e richiede un approccio completamente nuovo all’igiene digitale nelle aziende.

L'articolo RenderShock: la nuova minaccia digitale che colpisce i sistemi Windows con un passaggio del mouse proviene da il blog della sicurezza informatica.

Questa mattina, gli hacker di NoName057(16) hanno sferrato attacchi DDoS contro diversi obiettivi italiani. Name057(16) è un gruppo di hacker che si è dichiarato a marzo del 2022 a supporto della Federazione Russa.

Hanno rivendicato la responsabilità di attacchi informatici a paesi come l’Ucraina, gli Stati Uniti e altri vari paesi europei. Questi attacchi vengono in genere eseguiti contro agenzie governative, media e siti Web di società private.

Di seguito quanto riportato dagli hacktivisti filorussi sul proprio canale Telegram e le vittime rivendicate:
They made a noise in the Italian Internet segment😈

❌tiscali Italy (dead in ping)
check-host.net/check-report/29b6543ak8e6

❌ Khoster Tiscali (dead in ping)
check-host.net/check-report/29b6547ak35d

❌Tessellis Telecommunication company (dead in ping)
check-host.net/check-report/29b654a2kaf2

❌ACANTHO Italy
check-host.net/check-report/29b651d1k6fa

❌ Corps of Parma (dead in ping)
check-host.net/check-report/29b65605kf26

❌ Horode Revo-Nel-Emilia (dead in ping)
check-host.net/check-report/29b65425k336

❌ Gorod Rimini
check-host.net/check-report/29b651fck15f

❌ Minority of infrastructure and transport of Italy (dead in ping)
check-host.net/check-report/29b65512k538

❌minist economic development (dead in ping)
check-host.net/check-report/29b6553ak8c1

#OpItaly
Il gruppo hacktivista filorusso NoName057(16) ha pubblicato un messaggio rivolto ai propri follower, avvisandoli di ignorare eventuali comunicazioni sospette provenienti dal loro bot ufficiale. Secondo quanto dichiarato dal gruppo, questi messaggi sarebbero il frutto di un’operazione di disinformazione orchestrata dai “servizi speciali occidentali” nel tentativo di ostacolare le loro attività e creare confusione tra i sostenitori. Nel messaggio, NoName057(16) minimizza l’accaduto, liquidandolo come “un altro giro di macchinazioni” e rassicura che presto verranno ripristinate le normali operazioni.

Allo stesso tempo, il gruppo mette in guardia i propri follower dal seguire link provenienti dal vecchio bot @DBNNMBot o dal comunicare con chiunque cerchi di contattarli spacciandosi per membri ufficiali. Questo messaggio conferma come anche ambienti hacktivisti siano esposti a operazioni di infiltrazione, social engineering e takeover di infrastrutture digitali critiche per la propaganda e il coordinamento delle campagne.

Che cos’è un attacco Distributed Denial of Service

Un attacco DDoS (Distributed Denial of Service) è un tipo di attacco informatico in cui vengono inviate una grande quantità di richieste a un server o a un sito web da molte macchine diverse contemporaneamente, al fine di sovraccaricare le risorse del server e renderlo inaccessibile ai suoi utenti legittimi.

Queste richieste possono essere inviate da un grande numero di dispositivi infetti da malware e controllati da un’organizzazione criminale, da una rete di computer compromessi chiamata botnet, o da altre fonti di traffico non legittime. L’obiettivo di un attacco DDoS è spesso quello di interrompere le attività online di un’organizzazione o di un’azienda, o di costringerla a pagare un riscatto per ripristinare l’accesso ai propri servizi online.

Gli attacchi DDoS possono causare danni significativi alle attività online di un’organizzazione, inclusi tempi di inattività prolungati, perdita di dati e danni reputazionali. Per proteggersi da questi attacchi, le organizzazioni possono adottare misure di sicurezza come la limitazione del traffico di rete proveniente da fonti sospette, l’utilizzo di servizi di protezione contro gli attacchi DDoS o la progettazione di sistemi resistenti agli attacchi DDoS.

Occorre precisare che gli attacchi di tipo DDoS, seppur provocano un disservizio temporaneo ai sistemi, non hanno impatti sulla Riservatezza e Integrità dei dati, ma solo sulla loro disponibilità. pertanto una volta concluso l’attacco DDoS, il sito riprende a funzionare esattamente come prima.

Che cos’è l’hacktivismo cibernetico

L’hacktivismo cibernetico è un movimento che si serve delle tecniche di hacking informatico per promuovere un messaggio politico o sociale. Gli hacktivisti usano le loro abilità informatiche per svolgere azioni online come l’accesso non autorizzato a siti web o a reti informatiche, la diffusione di informazioni riservate o il blocco dei servizi online di una determinata organizzazione.

L’obiettivo dell’hacktivismo cibernetico è di sensibilizzare l’opinione pubblica su questioni importanti come la libertà di espressione, la privacy, la libertà di accesso all’informazione o la lotta contro la censura online. Gli hacktivisti possono appartenere a gruppi organizzati o agire individualmente, ma in entrambi i casi utilizzano le loro competenze informatiche per creare un impatto sociale e politico.

È importante sottolineare che l’hacktivismo cibernetico non deve essere confuso con il cybercrime, ovvero la pratica di utilizzare le tecniche di hacking per scopi illeciti come il furto di dati personali o finanziari. Mentre il cybercrime è illegale, l’hacktivismo cibernetico può essere considerato legittimo se mira a portare all’attenzione pubblica questioni importanti e a favorire il dibattito democratico. Tuttavia, le azioni degli hacktivisti possono avere conseguenze legali e gli hacktivisti possono essere perseguiti per le loro azioni.

Chi sono gli hacktivisti di NoName057(16)

NoName057(16) è un gruppo di hacker che si è dichiarato a marzo del 2022 a supporto della Federazione Russa. Hanno rivendicato la responsabilità di attacchi informatici a paesi come l’Ucraina, gli Stati Uniti e altri vari paesi europei. Questi attacchi vengono in genere eseguiti su agenzie governative, media e siti Web di società private

Le informazioni sugli attacchi effettuati da NoName057(16) sono pubblicate nell’omonimo canale di messaggistica di Telegram. Secondo i media ucraini, il gruppo è anche coinvolto nell’invio di lettere di minaccia ai giornalisti ucraini. Gli hacker hanno guadagnato la loro popolarità durante una serie di massicci attacchi DDOS sui siti web lituani.

Le tecniche di attacco DDoS utilizzate dal gruppo sono miste, prediligendo la “Slow http attack”.

La tecnica del “Slow Http Attack”

L’attacco “Slow HTTP Attack” (l’articolo completo a questo link) è un tipo di attacco informatico che sfrutta una vulnerabilità dei server web. In questo tipo di attacco, l’attaccante invia molte richieste HTTP incomplete al server bersaglio, con lo scopo di tenere occupate le connessioni al server per un periodo prolungato e impedire l’accesso ai legittimi utenti del sito.

Nello specifico, l’attacco Slow HTTP sfrutta la modalità di funzionamento del protocollo HTTP, che prevede che una richiesta HTTP sia composta da tre parti: la richiesta, la risposta e il corpo del messaggio. L’attaccante invia molte richieste HTTP incomplete, in cui il corpo del messaggio viene inviato in modo molto lento o in modo incompleto, bloccando la connessione e impedendo al server di liberare le risorse necessarie per servire altre richieste.

Questo tipo di attacco è particolarmente difficile da rilevare e mitigare, poiché le richieste sembrano legittime, ma richiedono un tempo eccessivo per essere elaborate dal server. Gli attacchi Slow HTTP possono causare tempi di risposta molto lenti o tempi di inattività del server, rendendo impossibile l’accesso ai servizi online ospitati su quel sistema.

Per proteggersi da questi attacchi, le organizzazioni possono implementare soluzioni di sicurezza come l’uso di firewall applicativi (web application firewall o WAF), la limitazione delle connessioni al server e l’utilizzo di sistemi di rilevamento e mitigazione degli attacchi DDoS

L'articolo NoName057(16) sferra nuovi attacchi DDoS contro organizzazioni italiane e avverte su Telegram proviene da il blog della sicurezza informatica.

When buying used cars there are plenty of ways to check on their history. In many countries there are systems, like Carfax for parts of North America and Europe, that can provide crash history in some situations and alert a potential buyer of hidden damage. Not so for computers, where anyone can run an intensive mining, gaming, rendering, or AI application for years on hardware which might not otherwise show any outward signs of heavy use. And that’s just for hard use; there’s all kinds of other ways of damaging hardware. HP is hoping to solve this problem with a PC history report of sorts.

Aimed at the enterprise or business arena, where companies tend to follow replacement schedules for laptops and other hardware which might get discarded before reaching a true end-of-life, HP is suggesting adding a data recorder at the firmware level of some computers. This software would monitor the computer’s temperatures, SSD wear, and other telematics on the computer and store a record that could be viewed by a potential buyer when the IT department is ready to take them out of service. And, since it’s 2025, HP is also claiming that this system needs and uses an AI of some sort.

Although HP is billing this as a way to improve sustainability and limit e-waste, we’d theorize that even with a report like this available, the economic gain of a program like this would be marginal at best. While the idea of giving each decommissioned laptop a clean bill of health is noble, it’s hard to imagine overworked IT staff carefully curating device histories when most used enterprise machines are already sold by the pallet.

HP is also proposing something that sounds a lot like Intel’s Management Engine, which we’re not too thrilled about around here. And also keep in mind that this is a company that has failed to innovate in any industry-leading way for as long as we can remember so we won’t expect this system to be widely adopted anytime soon.

hackaday.com/2025/07/15/will-h…

(di Carlo Rovelli)

"Libertà è stata la parola d’ordine della mia generazione, che rifiutava ipocrisie e imposizioni di un mondo dominato da minoranze, e voleva cercare la sua strada."

"Che tristezza, mezzo secolo più tardi, vedere questa parola luminosa usata come bandiera dai privilegiati per giustificare il diritto di opprimere."

"Un magazine clandestino ciclostilato nella Russia Sovietica aveva un potere dirompente: nessuno poteva parlare e chi osava aveva una voce possente. Una rivista pacifista nell’Occidente liberale non ha alcun peso: tutti possono parlare; il potere non ha bisogno di opprimere voci dissenzienti, tanto ha il controllo delle narrazioni che dominano."

"L’ipocrita religione occidentale della libertà si giustifica con il ridicolo argomento che “in Occidente si sta meglio, perché c’è la libertà”. Poche affermazioni sono altrettanto ipocrite. In Occidente si sta meglio perché l’Occidente è ricco; e l’Occidente è ricco perché ha raccolto l’eredità dello strapotere dell’Europa coloniale ottocentesca sul mondo intero. Uno strapotere che non è certo stato costruito sulla libertà. È stato costruito sulla soppressione della libertà dei popoli colonizzati, sulla razzie delle loro risorse, sulla riduzione in schiavitù di milioni di africani.
Questa rapina è chiamata libertà."

"Per salvare il mondo [...] l’ultima cosa di cui abbiamo bisogno è più libertà per l’arroganza dei poteri che ci hanno portato a questo.
Abbiamo bisogno, al contrario, di riconoscere che il bene comune, il bene di tutti noi, deve essere più importante dell’arroganza dei singoli. Abbiamo bisogno di accordarci su regole condivise. Di lavorare insieme, non gli uni contro gli altri.
Quando gli oppressi parlano di libertà, il mio cuore è con loro. Quando i ricchi e i potenti del mondo parlano di libertà, hanno tutto il mio disprezzo."

Per seguire l'account X dal Fediverso: @carlo rovelli

(Mi piacerebbe davvero tanto che almeno lui si affacciasse nel Fediverso...)

facebook.com/carlo.rovelli.7/p…

#rovelli #iostoconrovelli

Among this crowd, it’s safe to say that the original 68000 Macintosh computers need no introduction, but it’s possible some of you aren’t familiar with Chip8. It was an interpreted virtual machine originally created for the COSMAC VIP microcomputer by [Joe Weisbecker] way back in 1977. It enabled coding simple games on the COSMAC VIP without getting into machine code on the VIP’s CDP1802 processor. For the obvious reason of “Why not?” [KenDesigns] decided to put the two together with Chip4Mac68000, a Chip8 emulator for the original Macintosh.

Chip4Mac68000 is not actually a Macintosh program; it doesn’t run in the System Software. Instead, it is a bootdisk that runs bare-metal on the 68000 processor, bypassing Apple’s ROM completely. Doing that is probably more impressive than emulating Chip8 — anyone who wants to get into writing emulators starts with Chip8. That’s not to knock on anyone who goes to the effort of writing an emulator, it’s just that given its origins in a 1970s micro, it’s understandably a very simple system. Not many people do bare-metal coding on this sort of hardware anymore; it’s not like there’s an SDK you can go grab.

Or there wasn’t, anyway, because in order to get this emulator to work, [KenDesigns] wrote a bare-metal SDK for 68000-based Macs. Note that when he says 68000, he does mean 68000 — anything newer than a Macintosh Classic is out. It’s 68000, not 680xx. It was not a trivial endeavour. In the demo video embedded below, you can see his 512k Macintosh in pieces because he’s been poking at it with a logic analyzer to verify the hardware does what he thinks it’s being told.

If you want to try it out, apparently you don’t need real hardware: [KenDesigns] says MAME is accurate enough to make it all work, but miniVmac is not. No word if it would work on the RP2040-based PicoMac; if you try it, let us know how it works out.

This isn’t the first time we’ve seen people writing new software for old Macs of late. If you’re working new magic on very old machines, drop us a line. We’d love to hear about it.

youtube.com/embed/CWS06LjBWHs?…

hackaday.com/2025/07/15/a-chip…

Questo strumento è destinato esclusivamente a scopi didattici e di penetration testing autorizzati. L’autore non si assume alcuna responsabilità per eventuali usi impropri o danni causati da questo software. Assicurarsi sempre di avere un’autorizzazione esplicita e scritta prima di eseguire qualsiasi test su un sistema.

Negli ultimi giorni è stata portata all’attenzione della comunità infosec una grave vulnerabilità di tipo Remote Code Execution (CVE‑2025‑47812) nel software Wing FTP Server, ampiamente utilizzato per offrire servizi FTP, FTPS e HTTP a migliaia di aziende.

L’exploit per questa vulnerabilità, caratterizzata da una grave manipolazione di byte NULL e iniezione di codice Lua, è stata provata da Manuel Roccon, root del gruppo HackerHood di Red Hot Cyber, che ha creato recentemente un sotto gruppo chiamato Hackerhood Pwned dove verranno testati dagli esperti di sicurezza, i principali exploit che vengono pubblicati.

La vulnerabilità CVE‑2025‑47812 — con CVSSv3 = 10.0 — coinvolge una falla nella gestione di stringhe terminate da byte NULL in loginok.html, consentendo a un attaccante non autenticato di iniettare codice Lua arbitrario e tale exploit si è rilevato come esecuzione molto facile (3 in scala da 1 a 10) confermando quanto riportato dal NIST come LOW.

youtube.com/embed/Y56WF1XeyJ0?…

Questa vulnerabilità è dovuta alla gestione impropria da parte di Wing FTP Server dei byte NULL nel parametro username durante il processo di autenticazione. Ciò consente agli aggressori di iniettare codice Lua direttamente nei file di sessione. Questi file di sessione dannosi vengono quindi eseguiti al caricamento di una sessione valida, causando l’esecuzione di comandi arbitrari sul server.

Le caratteristiche principali di questo exploit includono:

• Esecuzione di codice remoto: esegui qualsiasi comando tu scelga sul server di destinazione.
• Privilegi Root/SYSTEM: spesso ottiene una RCE con i privilegi di sistema più elevati grazie alle configurazioni predefinite di Wing FTP Server.
• Sfruttamento dell’accesso anonimo: può essere sfruttato anche se sul server sono consentiti solo accessi anonimi.
• Scansione batch: esegue la scansione di più destinazioni fornendo un elenco di URL da un file.
• Esecuzione di comandi personalizzati: specifica ed esegui qualsiasi comando necessario sul server vulnerabile.

La vulnerabilità CVE-2025-47812 è un problema critico derivante da molteplici debolezze nel modo in cui Wing FTP Server gestisce l’autenticazione degli utenti e le sessioni:

1. Troncamento del byte NULL in c_CheckUser(): la c_CheckUser()funzione, responsabile dell’autenticazione dell’utente, utilizza internamente strlen()il nome utente fornito. Quando un byte NULL ( %00) viene iniettato nel nome utente (ad esempio, anonymous%00...), strlen() e tronca la stringa in questo punto. Ciò significa che l’autenticazione riesce per la parte del nome utente prima del byte NULL, bypassando di fatto la convalida corretta.
2. Nome utente completo nella creazione della sessione: nonostante il troncamento dell’autenticazione, la rawset(_SESSION, "username", username)chiamata all’interno loginok.html utilizza l’ intero nome utente non purificato direttamente dai parametri GET o POST. Questo include il byte NULL e tutti i caratteri successivi.
3. Iniezione di codice Lua: poiché i file di sessione vengono archiviati come script Lua, l’iniezione di codice Lua dopo il byte NULL nel nome utente (ad esempio, anonymous%00]]%0dlocal+h+%3d+io.popen("id")%0dlocal+r+%3d+h%3aread("*a")%0dh%3aclose()%0dprint(r)%0d--) fa sì che questo codice dannoso venga scritto direttamente nel file di sessione.
4. Esecuzione del file di sessione: la funzione SessionModule.load(), invocata quando si accede a una funzionalità autenticata (come /dir.html), esegue direttamente il file di sessione utilizzando loadfile(filepath) seguito da f(). Questo passaggio cruciale attiva il codice Lua iniettato, portando all’esecuzione di codice remoto (RCE).

Il gruppo Hackerhood/pwned ha replicato in laboratorio la stessa tecnica, creando una dimostrazione visiva dell’attacco, e l’ha resa pubblica in rete. Nel video si apprezza in modo chiaro l’iniezione Lua, il download del payload, e l’esecuzione che apre una shell con privilegi elevati. «Ecco come un attaccante non autenticato può, in pochi secondi, ottenere pieno controllo di un server Wing FTP.»

Misure urgenti suggerite alle organizzazioni:

L'articolo Tasting the Exploit: HackerHood testa l’exploit su Wing FTP Server del CVE‑2025‑47812 da Score 10 proviene da il blog della sicurezza informatica.

redhotcyber.com/post/tasting-t…

GMX, uno dei principali protocolli DeFi per il trading con leva, è stato recentemente colpito da un attacco che ha portato alla sottrazione di circa 42 milioni di dollari. L’exploit ha sfruttato i meccanismi interni del protocollo legati allo slippage e alla gestione dei prezzi. Gli aggressori, invece di scomparire, hanno scelto di avviare una trattativa diretta con il team di GMX, accettando di restituire il 90% dei fondi in cambio del riconoscimento come white-hat e di una ricompensa pari al 10% dell’importo.

GMX è noto per offrire trading con leva, ovvero la possibilità per gli utenti di moltiplicare la propria esposizione di mercato rispetto al capitale effettivamente investito. L’accordo con gli hacker ha avuto un impatto immediato sul mercato. Il token GMX, crollato dopo l’incidente, ha recuperato rapidamente circa il 15% in seguito alla notizia del rimborso.

Il team di GMX ha trasmesso agli hacker un messaggio on-chain, offrendo una bounty del 10% in cambio della restituzione del resto. In cambio, nessuna azione legale sarebbe stata intrapresa. Gli autori dell’attacco hanno accettato, restituendo la stragrande maggioranza degli asset in poco tempo. Il denaro è rimasto on-chain, e non è stato convertito in fiat.

Nonostante l’esito apparentemente positivo, la dinamica dell’attacco resta ancora poco chiara. GMX non ha ancora fornito una spiegazione dettagliata sull’origine esatta dell’errore di logica sfruttato, lasciando aperti diversi interrogativi sullo stato della sicurezza del protocollo. L’incertezza potrebbe influenzare la fiducia degli utenti e degli investitori fino a quando non verranno rese pubbliche ulteriori informazioni tecniche e non sarà chiaro se le vulnerabilità sono state effettivamente risolte.

Questo episodio rappresenta un caso esemplare di come nella DeFi gli exploit non derivano sempre da bug del codice, ma da debolezze nei modelli economici e nella logica operativa. Il fatto che gli aggressori abbiano accettato il dialogo e si siano mossi come white-hat non li esonera dal fatto di aver comunque sfruttato un sistema per generare profitto. Ma, allo stesso tempo, dimostra come i meccanismi di bounty e comunicazione on-chain possano diventare strumenti concreti per limitare i danni e gestire incidenti critici con pragmatismo.

Nel contesto attuale, dove gli attacchi alla DeFi sono sempre più frequenti, la trasparenza post-incident è fondamentale. GMX dovrà ora dimostrare di aver appreso la lezione, rafforzando non solo la propria sicurezza, ma anche la fiducia di chi sceglie ogni giorno di utilizzare i suoi servizi.

L'articolo GMX Hacked: restituiti il 90% dei fondi rubati dopo trattativa on-chain proviene da il blog della sicurezza informatica.