Ed ecco a voi Sinistra per Israele (come già noto prezzolata da Netanyahu)

Cronaca. Ieri in un dibattito in Senato si è riunita la cosiddetta “Sinistra per Israele” con Ivan Scalfarotto (Iv), Lucio Malan e Piero Fassino, Sensi e Delrio, Alfredo Bazoli e Walter Verini, Lia Quartapelle e Marianna Madia, Enza Rando e Antonio Nicita, Simona Malpezzi e Sandra Zampa; Marco Carrai, da sempre vicino a Matteo Renzi, e console onorario di Israele e Raffaella Paita, Luciano Nobili, Silvia Fregolent di IV.
L’iniziativa voleva contrastare la mozione contro Israele di Conte del giorno prima che ha visto anche la partecipazione della Shlein.
Fassino, oltre a ricordare ai presenti con orgoglio che viene definito “il sionista di sinistra”, ha ricordato anche “che va bene dire due popoli due Stati, ma che la soluzione ad ora non è praticabile”, dicendo inoltre che molte delle strutture operative di Hamas sono costruite vicino a luoghi come gli ospedali, e dunque risultano “fatali” le vittime civili. Fatali, ha usato questo termine per giustificare le conseguenze genocidiarie delle bombe israeliane. Per la cronaca - leggo da un articolo di oggi sul FQ- “una donna dal pubblico è pure intervenuta per rivendicare il fatto che l’esercito israeliano “avverte sempre dei suoi obiettivi”. Fassino l’ha rassicurata sulle sue posizioni, la sala ha applaudito”.
Cosa dire? Niente di più, se non che nella sala non aleggiava profumo di Chanel, ma di carne umana bruciata.

(Cosimo Minervini)

We’re suckers here for projects that let you see the unseeable, and [Ayden Wardell Aerospace] provides that on a budget with their $30 Schlieren Imaging Setup. The unseeable in question is differences in air density– or, more precisely, differences in the refractive index of the fluid the imaging set up makes use of, in this case air. Think of how you can see waves of “heat” on a warm day– that’s lower-density hot air refracting light as it rises. Schlieren photography weaponizes this, allowing to analyze fluid flows– for example, the mach cones in a DIY rocket nozzle, which is what got [Ayden Wardell Aerospace] interested in the technique.

Examining exhaust makes this a useful tool for [Aerospace].This is a ‘classic’ mirror-and-lamp Schlieren set up. You put the system you wish to film near the focal plane of a spherical mirror, and camera and light source out at twice the focal distance. Rays deflected by changes in refractive index miss the camera– usually one places a razor blade precisely to block them, but [Ayden] found that when using a smart phone that was unnecessary, which shocked this author.

While it is possible that [Ayden Wardell Aerospace] has technically constructed a shadowgraph, they claim that carefully positioning the smartphone allows the sharp edge of the case to replace the razor blade. A shadowgraph, which shows the second derivative of density, is a perfectly valid technique for flow visualization, and is superior to Schlieren photography in some circumstances– when looking at shock waves, for example.

Regardless, the great thing about this project is that [Ayden Wardell Aerospace] provides us with STLs for the mirror and smartphone mounting, as well as providing a BOM and a clear instructional video. Rather than arguing in the comments if this is “truly” Schlieren imaging, grab a mirror, extrude some filament, and test it for yourself!

There are many ways to do Schlieren images. We’ve highighted background-oriented techniques, and seen how to do it with a moiré pattern, or even a selfie stick. Still, this is the first time 3D printing has gotten involved and the build video below is quick and worth watching for those sweet, sweet Schlieren images.

youtube.com/embed/piGYryly5Bw?…

hackaday.com/2025/04/17/budget…

Day after day, threat actors create new malware to use in cyberattacks. Each of these new implants is developed in its own way, and as a result gets its own destiny – while the use of some malware families is reported for decades, information about others disappears after days, months or several years.

We observed the latter situation with an implant that we dubbed MysterySnail RAT. We discovered it back in 2021, when we were investigating the CVE-2021-40449 zero-day vulnerability. At that time, we identified this backdoor as related to the IronHusky APT, a Chinese-speaking threat actor operating since at least 2017. Since we published a blogpost on this implant, there have been no public reports about it, and its whereabouts have remained unknown.

However, recently we managed to spot attempted deployments of a new version of this implant, occurring in government organizations located in Mongolia and Russia. To us, this observed choice of victims wasn’t surprising, as back in 2018, we wrote that IronHusky, the actor related to this RAT, has a specific interest in targeting these two countries. It turned out that the implant has been actively used in cyberattacks all these years although not reported.

Infection through a malicious MMC script

One of the recent infections we spotted was delivered through a malicious MMC script, designed to be disguised as a document from the National Land Agency of Mongolia (ALAMGAC):

Malicious MMC script as displayed in Windows Explorer. It has the icon of a Microsoft Word document

When we analyzed the script, we identified that it is designed to:

• Retrieve a ZIP archive with a second-stage malicious payload and a lure DOCX file from the file[.]io public file storage.
• Unzip the downloaded archive and place the legitimate DOCX file into the %AppData%\Cisco\Plugins\X86\bin\etc\Update folder
• Start the CiscoCollabHost.exe file dropped from the ZIP archive.
• Configure persistence for the dropped CiscoCollabHost.exefile by adding an entry to the Run registry key.
• Open the downloaded lure document for the victim.

Intermediary backdoor

Having investigated the
CiscoCollabHost.exe file, we identified it as a legitimate executable. However, the archive deployed by the attackers also turned out to include a malicious library named CiscoSparkLauncher.dll, designed to be loaded by the legitimate process through the DLL Sideloading technique.
We found out that this DLL represents a previously unknown intermediary backdoor, designed to perform C2 communications by abusing the open-source piping-server project. An interesting fact about this backdoor is that information about Windows API functions used by it is located not in the malicious DLL file, but rather in an external file having the
log\MYFC.log relative path. This file is encrypted with a single-byte XOR and is loaded at runtime. It is likely that the attackers introduced this file to the backdoor as an anti-analysis measure – since it is not possible to determine the API functions called without having access to this file, the process of reverse engineering the backdoor essentially turns into guesswork.
By communicating with the legitimate
ppng.io server powered by the piping-server project, the backdoor is able to request commands from attackers and send back their execution results. It supports the following set of basic malicious commands:

As we found out, attackers used commands implemented in this backdoor to deploy the following files to the victim machine:

• sophosfilesubmitter.exe, a legitimate executable
• fltlib.dll, a malicious library to be sideloaded

In our telemetry, these files turned out to leave footprints of the MysterySnail RAT malware, an implant we described back in 2021.

New version of MysterySnail RAT

In observed infection cases, MysterySnail RAT was configured to persist on compromised machines as a service. Its malicious DLL, which is deployed by the intermediary backdoor, is designed to load a payload encrypted with RC4 and XOR, and stored inside a file named
attach.dat. When decrypted, it is reflectively loaded using DLL hollowing with the help of code implemented inside the run_pe library.
Just as the version of MysterySnail RAT we described in 2021, the latest version of this implant uses attacker-created HTTP servers for communication. We have observed communications being performed with the following servers:

• watch-smcsvc[.]com
• leotolstoys[.]com
• leotolstoys[.]com

Having analyzed the set of commands implemented in the latest version of this backdoor, we identified that it is quite similar to the one implemented in the 2021 version of MysterySnail RAT – the newly discovered implant is able to accept about 40 commands, making it possible to:

• Perform file system management (read, write and delete files; list drives and directories).
• Execute commands via the cmd.exe shell.
• Spawn and kill processes.
• Manage services.
• Connect to network resources.

Compared to the samples of MysterySnail RAT we described in our 2021 article, these commands were implemented differently. While the version of MysterySnail from 2021 implements these commands inside a single malicious component, the newly discovered version of the implant relies on five additional DLL modules, downloaded at runtime, for command execution. These modules are as follows:

However, this transition to a modular architecture isn’t something new – as we have seen modular versions of the MysterySnail RAT deployed as early as 2021. These versions featured the same modules as described above, including the typo in the
ExplorerMoudleDll.dll module name. Back then, we promptly made information about these versions available to subscribers of our APT Intelligence Reporting service.

MysteryMonoSnail – a repurposed version of MysterySnail RAT

Notably, a short time after we blocked the recent intrusions related to MysterySnail RAT, we observed the attackers to continue conducting their attacks, by deploying a repurposed and more lightweight version of MysterySnail RAT. This version consists of a single component, and that’s why we dubbed it MysteryMonoSnail. We noted that it performed communications with the same C2 server addresses as found in the full-fledged version of MysterySnail RAT, albeit via a different protocol – WebSocket instead of HTTP.

This version doesn’t have as many capabilities as the version of MysterySnail RAT that we described above – it was programmed to have only 13 basic commands, used to list directory contents, write data to files, and launch processes and remote shells.

Obsolete malware families may reappear at any time

Four years, the gap between the publications on MysterySnail RAT, has been quite lengthy. What is notable is that throughout that time, the internals of this backdoor hardly changed. For instance, the typo in the
ExplorerMoudleDll.dll that we previously noted was present in the modular version of MysterySnail RAT from 2021. Furthermore, commands implemented in the 2025 version of this RAT were implemented similarly to the 2021 version of the implant. That is why, while conducting threat hunting activities, it’s crucial to consider that old malware families, which have not been reported on for years, may continue their activities under the radar. Due to that, signatures designed to detect historical malware families should never be discontinued simply because they are too old.
At Kaspersky’s GReAT team, we have been focusing on detecting complex threats since 2008 – and we provide sets of IoCs for both old and new malware to customers of our Threat Intelligence portal. If you wish to get access to these IoCs and other information about historical and emerging threats, please contact us at intelreports@kaspersky.com.

securelist.com/mysterysnail-ne…

This project by [Miro] is awesome, not only did he build a replica Enigma machine using modern technologies, but after completing it, he went back and revised several components to make it more usable. We’ve featured Enigma machines here before; they are complex combinations of mechanical and electrical components that form one of the most recognizable encryption methods in history.

His first Enigma machine was designed closely after the original. He used custom PCBs for the plugboard and lightboard, which significantly cleaned up the internal wiring. For the lightboard, he cleverly used a laser printer on semi-transparent paper to create crisp letters, illuminated from behind. For the keyboard, he again designed a custom PCB to connect all the switches. However, he encountered an unexpected setback due to error stack-up. We love that he took the time to document this issue and explain that the project didn’t come together perfectly on the first try and how some adjustments were needed along the way.

The real heart of this build is the thought and effort put into the design of the encryption rotors. These are the components that rotate with each keystroke, changing the signal path as the system is used. In a clever hack, he used a combination of PCBs, pogo pins, and 3D printed parts to replicate the function of the original wheels.

Enigma machine connoisseurs will notice that the wheels rotate differently than in the original design, which leads us to the second half of this project. After using the machine for a while, it became clear that the pogo pins were wearing down the PCB surfaces on the wheels. To solve this, he undertook an extensive redesign that resulted in a much more robust and reliable machine.

In the redesign, instead of using pogo pins to make contact with pads, he explored several alternative methods to detect the wheel position—including IR light with phototransistors, rotary encoders, magnetic encoders, Hall-effect sensors, and more. The final solution reduced the wiring and addressed long-term reliability concerns by eliminating the mechanical wear present in the original design.

Not only did he document the build on his site, but he also created a video that not only shows what he built but also gives a great explanation of the logic and function of the machine. Be sure to also check out some of the other cool enigma machines we’ve featured over the years.

youtube.com/embed/T_UuYkO4OBQ?…

hackaday.com/2025/04/17/modern…

Sul Forum DarketArmy l’attore Mr.Robot ha messo in vendita un RAT ad Agosto 2023. DarknetArmy è un forum attivo nel dark web, emerso per la prima volta nel 2018. È noto per la condivisione di strumenti di hacking, informazioni sulla sicurezza e altre risorse legate alla cybersecurity.

Il RAT, codificato con il nome “888”, ha suscitato un rinnovato interesse nelle ultime due settimane, nonostante il post originale risalga a due anni fa.

Questo aumento di attenzione potrebbe essere dovuto a recenti aggiornamenti o miglioramenti del malware, rendendolo più efficace o difficile da rilevare

Il gruppo Blade Hawk ha utilizzato una versione craccata di questo RAT per condurre attacchi di spionaggio verso gruppi etnici curdi tramite forum, social media o app legittime

Diverse versioni crakkate sono disponibili in repository GitHub e sono tuttora utilizzate da pentester. Le potenzialità di questo malware sono molteplici, ecco le principali:

• Accesso Remoto al Desktop: Permette agli attaccanti di controllare il desktop del sistema infetto da remoto.
• Cattura Webcam e Audio: Consente di registrare video e audio tramite la webcam e il microfono del dispositivo.
• Recupero Password: Estrae password da vari browser e client di posta elettronica.
• Keylogging: Registra i tasti premuti sulla tastiera, permettendo di intercettare informazioni sensibili come credenziali di accesso.
• Gestione dei File: Permette di visualizzare, modificare, eliminare e trasferire file sul sistema infetto.
• Spoofing delle Estensioni dei File: Modifica le estensioni dei file per nascondere la vera natura dei file infetti.
• Persistenza: Implementa meccanismi per rimanere attivo anche dopo il riavvio del sistema o la cancellazione dei file.
• Disabilitazione delle Utility di Sistema: Disabilita strumenti di gestione del sistema per evitare la rilevazione e la rimozione.
• Bypass della Rilevazione Antivirus: Utilizza tecniche di offuscamento per evitare di essere rilevato dai software antivirus.
• Elevazione dei Privilegi: Esegue exploit UAC per ottenere privilegi elevati sul sistema infetto.

Nelle ultime due settimane, il post ha ricevuto un notevole aumento di commenti da parte di utenti interessati al download, suggerendo un possibile aggiornamento del malware o un rinnovato interesse per le sue capacità.

Per proteggersi da minacce come il RAT 888, è raccomandato seguire alcune pratiche di sicurezza:

• Aggiornare e Patchare i Sistemi: Assicurarsi che tutti i sistemi siano aggiornati con le ultime patch di sicurezza, in particolare quelle che affrontano vulnerabilità come MS17-10 (EternalBlue), per prevenire lo sfruttamento da parte dei RAT.
• Migliorare la Protezione degli Endpoint: Implementare soluzioni avanzate di protezione degli endpoint in grado di rilevare e bloccare le attività dei RAT, come l’accesso remoto non autorizzato e l’offuscamento dei processi.

Queste misure possono aiutare a mitigare i rischi associati a malware sofisticati come il RAT 888, contribuendo a mantenere un ambiente digitale più sicuro.

L'articolo DarknetArmy e il RAT 888: Un Malware che Torna a Far Paura proviene da il blog della sicurezza informatica.

È uno di quei momenti che passano sottotraccia per l’opinione pubblica, ma che per chi opera nel mondo della cybersecurity suona come un’allerta silenziosa, quasi surreale: la possibilità concreta che il sistema CVE – Common Vulnerabilities and Exposures – possa smettere di funzionare. Non per un attacco informatico. Non per un evento naturale. Ma per un più banale, quanto drammatico, problema di mancato rinnovo dei fondi da parte del governo statunitense.

La notizia è arrivata come un fulmine a ciel sereno, ma a ben guardare, i segnali di instabilità erano presenti da tempo. La lettera recentemente inviata da MITRE Corporation, ente responsabile della gestione del CVE Program per conto del governo USA, rappresenta molto più di un avviso tecnico: è il grido d’allarme di un’infrastruttura critica che rischia di spegnersi nel silenzio generale.

Eppure, se c’è una cosa che dovrebbe essere chiara a chiunque lavori nel settore, è che il CVE non è un semplice database, ma il vero e proprio fulcro della nomenclatura condivisa nel mondo della sicurezza informatica.

Perché il CVE è fondamentale?

Il CVE è il sistema che assegna un identificativo univoco – il cosiddetto CVE-ID – a ogni vulnerabilità software conosciuta pubblicamente. Senza questi identificativi, l’intero ecosistema cyber perderebbe coerenza: le analisi dei vendor, le patch, i report di minaccia, le valutazioni di rischio, gli strumenti SIEM, gli scanner di vulnerabilità e persino le dashboard delle agenzie nazionali di sicurezza non saprebbero più “come chiamare” le minacce.

È come se all’improvviso qualcuno decidesse che i numeri di targa delle automobili non servono più. Ogni incidente diventerebbe un caos burocratico, ogni multa un rebus, ogni denuncia un’informazione vaga. È esattamente ciò che accadrebbe senza il CVE: un buco nero semantico nel cuore della cybersecurity.

La crisi attuale: cosa dice la lettera MITRE

La comunicazione inviata da MITRE – ferma, tecnica, ma inequivocabile – mette in chiaro che la fine dei fondi federali (provenienti dalla CISA, la Cybersecurity and Infrastructure Security Agency) comporta l’impossibilità di garantire la continuità delle attività legate al programma CVE.

Senza finanziamenti:

• i processi di triage, validazione e pubblicazione delle vulnerabilità si fermeranno;
• i CNA (CVE Numbering Authorities), aziende autorizzate ad assegnare CVE-ID, perderanno il punto di riferimento centrale;
• i ritardi accumulati nelle assegnazioni, già criticamente aumentati negli ultimi mesi, rischiano di cronicizzarsi;
• la credibilità dell’intero ecosistema CVE verrebbe compromessa.

È quindi evidente che siamo di fronte a un single point of failure di proporzioni sistemiche, ma – e qui la riflessione si fa geopolitica – anche a un punto di dipendenza strategica da parte dell’intero Occidente, Europa compresa.

Europa: dove sei?

In un mondo multipolare, in cui la cybersicurezza è ormai considerata parte integrante della sovranità nazionale e continentale, fa riflettere quanto l’Europa – ancora oggi – non disponga di un proprio sistema alternativo o complementare per la gestione delle vulnerabilità informatiche.

La Cina, da anni, ha sviluppato un proprio database nazionale, con modalità operative, criteri e perfino una “agenda politica” nella gestione delle disclosure. In Russia esistono repository indipendenti connessi ai CERT federali. Ma l’Unione Europea? Ancora troppo sbilanciata su un modello americano-centrico, e spesso reattiva più che proattiva, nel campo della cyber intelligence.

Questa situazione rivela un grave gap di autonomia strategica: affidarsi a un’infrastruttura critica gestita da un singolo paese estero – per quanto alleato – significa esporsi a eventi come quello odierno, dove una semplice decisione amministrativa può influire sull’intero tessuto operativo delle nostre imprese, delle nostre agenzie, delle nostre difese.

Le implicazioni operative

L’impatto di un’eventuale sospensione del programma CVE si rifletterebbe su più piani:

• Industriale: i produttori di software e hardware non avrebbero più un framework di riferimento per le advisory.
• Governativo: le agenzie di sicurezza, i CERT nazionali e gli organismi di difesa non potrebbero più sincronizzarsi su vulnerabilità condivise.
• Accademico: la ricerca in ambito cybersecurity, già basata sulla tassonomia CVE, perderebbe uniformità e tracciabilità.
• Comunicativo: i media specializzati e le piattaforme di threat intelligence perderebbero un punto di riferimento essenziale nella diffusione di notizie sulle vulnerabilità.

In pratica, si creerebbe un effetto domino che andrebbe a compromettere l’intera filiera della gestione del rischio informatico.

La proposta: un sistema europeo di identificazione delle vulnerabilità

Serve un cambio di passo. E serve ora.

La mia proposta – che condivido da tempo in diverse sedi tecniche e istituzionali – è quella di creare un sistema CVE europeo, gestito da ENISA in collaborazione con i CERT nazionali, eventualmente interoperabile con il programma MITRE ma a controllo sovrano.

Un’infrastruttura simile permetterebbe:

• una gestione più trasparente e aderente ai valori europei;
• una maggiore protezione degli interessi industriali del continente;
• la possibilità di creare un ecosistema di CNA europei che rispondano a criteri omogenei e verificabili;
• un’integrazione più coerente con il nuovo regolamento NIS2, che obbliga le aziende critiche a gestire vulnerabilità e incidenti con precisione e tempestività.

Conclusioni

Il possibile collasso del programma CVE non è solo una crisi tecnica. È uno specchio, uno spartiacque, un’occasione – se vogliamo – per fermarci a riflettere su quanto la cybersicurezza sia oggi legata a scelte geopolitiche e strategiche.

L’Europa, se vuole essere davvero sovrana anche in ambito digitale, non può più permettersi di essere solo “utente” dei sistemi critici altrui. Deve iniziare a costruire i propri.

Perché senza nomi condivisi, anche la sicurezza – come il linguaggio – rischia di diventare babelica, confusa e inefficace. E in un mondo sempre più interconnesso, la chiarezza e la coerenza non sono un lusso, ma una necessità operativa.

L'articolo Il sistema CVE rischia il collasso: tra silenzi assordanti, dipendenze strategiche e un’Europa ancora senza voce proviene da il blog della sicurezza informatica.

Quanto accaduto in questi giorni deve rappresentare un campanello d’allarme per l’Europa.
Mentre il programma CVE — pilastro della sicurezza informatica globale — rischiava di spegnersi a causa della mancata estensione dei fondi statunitensi, l’Europa è rimasta spettatrice inerme.

Se i finanziamenti al progetto non fossero stati confermati in extremis, quanto sarebbe stata esposta la sicurezza nazionale dei Paesi europei? È inaccettabile che la protezione delle nostre infrastrutture digitali dipenda in modo così diretto da un’infrastruttura critica interamente statunitense.

Come abbiamo riportato nella giornata di ieri, noi di RHC lo riportiamo da tempo e non possiamo più permetterci una simile dipendenza. È necessario che ENISA e le istituzioni europee aprano una riflessione seria e strutturata su questo tema, promuovendo la nascita di un progetto interamente europeo per la gestione e la catalogazione delle vulnerabilità.

L’Europa deve smettere di delegare la propria resilienza digitale.

È tempo di costruire un’alternativa sovrana, trasparente e interoperabile, per garantire continuità, indipendenza e sicurezza a lungo termine. Parliamo tanto di autonomia tecnologica. Allora partiamo dalle basi della sicurezza nazionale prima di parlare di Quantum computing.

I fatti delle ultime ore

Sembra che la paura sia passata. Infatti la Cybersecurity and Infrastructure Security Agency (CISA) degli Stati Uniti ha rinnovato il contratto con la MITRE Corporation, assicurando così la continuità operativa del programma Common Vulnerabilities and Exposures (CVE). Questo intervento tempestivo ha evitato l’interruzione di uno dei pilastri fondamentali della sicurezza informatica globale, che era a poche ore dalla sospensione per mancanza di fondi federali.

Lanciato nel 1999 e gestito proprio da MITRE, il programma CVE rappresenta il sistema di riferimento internazionale per l’identificazione, la catalogazione e la standardizzazione delle vulnerabilità informatiche note. Il suo ruolo è cruciale per la difesa digitale: garantisce un linguaggio comune tra vendor, analisti e istituzioni, permettendo una risposta più coordinata ed efficace alle minacce.

Questa decisione arriva nel contesto di una più ampia strategia di riduzione dei costi da parte del governo federale, che ha già portato alla risoluzione di contratti e a riduzioni di personale in diversi team della CISA. pertanto si è riacceso il dibattito sulla sostenibilità e la neutralità di una risorsa di importanza globale come la CVE legata a un singolo sponsor governativo.

Il ruolo fondamentale del progetto CVE

Gli identificatori univoci del programma, noti come ID CVE, sono fondamentali per l’intero ecosistema della sicurezza informatica. Ricercatori, fornitori di soluzioni e team IT in tutto il mondo li utilizzano per tracciare, classificare e correggere in modo efficiente le vulnerabilità di sicurezza. Il database CVE è alla base di strumenti critici come scanner di vulnerabilità, sistemi di gestione delle patch e piattaforme per la risposta agli incidenti, oltre a svolgere un ruolo strategico nella protezione delle infrastrutture critiche.

La crisi è esplosa quando MITRE ha annunciato che il contratto con il Dipartimento della Sicurezza Interna (DHS) per la gestione del programma CVE sarebbe scaduto il 16 aprile 2025, senza alcun rinnovo previsto. L’annuncio ha allarmato la comunità della cybersecurity, che considera il CVE uno standard globale imprescindibile. Gli esperti hanno lanciato l’allarme: un’interruzione avrebbe compromesso i database nazionali delle vulnerabilità, messo a rischio gli avvisi di sicurezza e ostacolato l’operatività di fornitori e team di risposta agli incidenti su scala mondiale. In risposta alla minaccia, è stata istituita la CVE Foundation, con l’obiettivo di garantire la continuità, l’indipendenza e la stabilità a lungo termine del programma.

Sotto la crescente pressione della comunità di settore, CISA — sponsor principale del programma — è intervenuta nella tarda serata di martedì, attivando formalmente un “periodo di opzione” sul contratto con MITRE, a poche ore dalla scadenza.

“Il programma CVE è una priorità per CISA e un asset essenziale per la comunità informatica,” ha dichiarato un portavoce a Cyber Security News. “Abbiamo agito per evitare qualsiasi interruzione dei servizi CVE critici.”

Sebbene restino incerti i dettagli sull’estensione del contratto e sui finanziamenti futuri, l’intervento ha evitato la chiusura immediata di un’infrastruttura vitale per la cybersicurezza globale.

L'articolo CVE e MITRE salvato dagli USA. L’Europa spettatrice inerme della propria Sicurezza Nazionale proviene da il blog della sicurezza informatica.

If your shop comes complete with a MIG welder, an acetylene torch, and an air hammer, then you have more options than most when it comes to removing broken bolts.

In this short video [Jim’s Automotive Machine Shop, Inc] takes us through the process of removing a broken manifold bolt: use a MIG welder to attach a washer, then attach a suitably sized nut and weld that onto the washer, heat the assembly with the acetylene torch, loosen up any corrosion on the threads by tapping with a hammer, then simply unscrew with your wrench! Everything is easy when you know how!

Of course if your shop doesn’t come complete with a MIG welder and acetylene torch you will have to get by with the old Easy Out screw extractor like the rest of us. And if you are faced with a nasty bolt situation keep in mind that lubrication can help.

youtube.com/embed/flLPbIvn91k?…

hackaday.com/2025/04/16/using-…

How would you go about determining absolute zero? Intuitively, it seems like you’d need some complicated physics setup with lasers and maybe some liquid helium. But as it turns out, all you need is some simple lab glassware and a heat gun. And a laser, of course.

To be clear, the method that [Markus Bindhammer] describes in the video below is only an estimation of absolute zero via Charles’s Law, which describes how gases expand when heated. To gather the needed data, [Marb] used a 50-ml glass syringe mounted horizontally on a stand and fitted with a thermocouple. Across from the plunger of the syringe he placed a VL6180 laser time-of-flight sensor, to measure the displacement of the plunger as the air within it expands.

Data from the TOF sensor and the thermocouple were recorded by a microcontroller as the air inside the syringe was gently heated. Plotting the volume of the gas versus the temperature results shows a nicely linear relationship, and the linear regression can be used to calculate the temperature at which the volume of the gas would be zero. The result: -268.82°C, or only about four degrees off from the accepted value of -273.15°. Not too shabby.

[Marb] has been on a tear lately with science projects like these; check out his open-source blood glucose measurement method or his all-in-one electrochemistry lab.

youtube.com/embed/dqyfU8cX9rE?…

hackaday.com/2025/04/16/an-abs…

These days even a lowly microcontroller can easily trade blows with – or surpass – desktop systems of yesteryear, so it is little wonder that DIY handheld gaming systems based around an MCU are more capable than ever. A case in point is the GK handheld gaming system by [John Cronin], which uses an MCU from relatively new and very capable STM32H7S7 series, specifically the 225-pin STM32H7S7L8 in TFBGA package with a single Cortex-M7 clocked at 600 MHz and a 2D NeoChrom GPU.

Coupled with this MCU are 128 MB of XSPI (hexa-SPI) SDRAM, a 640×480 color touch screen, gyrometer, WiFi network support and the custom gkOS in the firmware for loading games off an internal SD card. A USB-C port is provided to both access said SD card’s contents and for recharging the internal Li-ion battery.

As can be seen in the demonstration video, it runs a wide variety of games, ranging from Doom (of course), Quake (d’oh), as well as Red Alert and emulators for many consoles, with the Mednafen project used to emulate GB, SNES and other systems at 20+ FPS. Although there aren’t a lot of details on how optimized the current firmware is, it seems to be pretty capable already.

youtube.com/embed/_2ip4UrAZJk?…

hackaday.com/2025/04/16/gk-stm…

È stata scoperta una vulnerabilità di sicurezza, identificata come CVE-2025-3155, in Yelp, l’applicazione di supporto utente GNOME preinstallata su Ubuntu desktop. La vulnerabilità riguarda il modo in cui Yelp gestisce lo schema URI “ghelp://”.

“Uno schema URI è la parte di un Uniform Resource Identifier (URI) che identifica un protocollo o un’applicazione specifica (steam://run/1337) che dovrebbe gestire la risorsa identificata dall’URI “. Chiarisce inoltre che ” è la parte che precede i due punti (://) “.

Yelp è registrato come gestore dello schema “ghelp://”. Il ricercatore sottolinea le limitate risorse online su questo schema, fornendo un esempio del suo utilizzo: ” $ yelp ghelp:///usr/share/help/C/gnome-calculator/” .

La vulnerabilità deriva dall’elaborazione da parte di Yelp dei file .page , ovvero file XML che utilizzano lo schema Mallard. Questi file possono utilizzare XInclude, un meccanismo di inclusione XML. Il ricercatore parrot409 sottolinea che ” l’aspetto interessante è che utilizza XInclude per incorporare il contenuto di legal.xml nel documento. Ciò significa che l’elaborazione XInclude è abilitata “.

Il ricercatore dimostra come XInclude può essere sfruttato fornendo un file .page di esempio che include il contenuto di /etc/passwd. Yelp utilizza un’applicazione XSLT ( yelp-xsl) per trasformare il .pagefile in un file HTML, che viene poi renderizzato da WebKitGtk. XSLT è descritto come “un linguaggio basato su XML utilizzato… per la trasformazione di documenti XML”.

L’aggressore può iniettare script dannosi nella pagina HTML di output sfruttando XInclude per inserire il contenuto di un file contenente tali script. L’articolo sottolinea che la semplice aggiunta di un tag o on*di un attributo nell’XML di input non funziona, poiché questi tag non sono gestiti dall’applicazione yelp-xsl.

Tuttavia, il ricercatore ha scoperto che l’applicazione XSLT copia determinati elementi e i loro figli nell’output senza modifiche. Un esempio è la gestione dei tag SVG. “L’app copia semplicemente il tag e il suo contenuto nell’output, permettendoci di utilizzare un tag in un tag per iniettare script arbitrari”.

Il ricercatore rileva un paio di limitazioni di questo attacco:

• L’aggressore deve conoscere il nome utente Unix della vittima.
• I browser potrebbero chiedere all’utente l’autorizzazione per reindirizzare a schemi personalizzati.

Tuttavia, l’articolo spiega che la directory di lavoro corrente (CWD) delle applicazioni avviate da GNOME (come Chrome e Firefox) è spesso la directory home dell’utente. Questo comportamento può essere sfruttato per puntare alla cartella Download della vittima, aggirando la necessità di conoscere il nome utente esatto.

La principale misura di mitigazione consigliata è quella di non aprire collegamenti a schemi personalizzati non attendibili.

L'articolo Gli hacker ringraziano: la falla Yelp su Ubuntu è una porta aperta proviene da il blog della sicurezza informatica.

This short video from [ProShorts 101] shows us how to build a variable speed disc sander from not much more than an old hard drive.

We feel that as far as hacks go this one ticks all the boxes. It is clever, useful, and minimal yet comprehensive; it even has a speed control! Certainly this hack uses something in a way other than it was intended to be used.

Take this ingenuity and add an old hard drive from your junkbox, sandpaper, some glue, some wire, a battery pack, a motor driver, a power socket and a potentiometer, drill a few holes, glue a few pieces, and voilà! A disc sander! Of course the coat of paint was simply icing on the cake.

The little brother of this hack was done by the same hacker on a smaller hard drive and without the speed control, so check that out too.

One thing that took our interest while watching these videos is what tool the hacker used to cut sandpaper. Here we witnessed the use of both wire cutters and a craft knife. Perhaps when you’re cutting sandpaper you just have to accept that the process will wear out the sharp edge on your tool, regardless of which tool you use. If you have a hot tip for the best tool for the job when it comes to cutting sandpaper please let us know in the comments! (Also, did anyone catch what type of glue was used?)

If you’re interested in a sander but need something with a smaller form factor check out how to make a sander from a toothbrush!

youtube.com/embed/GPqivvC2bEI?…

youtube.com/embed/-KKBDRt6g4g?…

hackaday.com/2025/04/16/making…

Le intelligenze artificiali generative stanno rivoluzionando i processi di sviluppo software, portando a una maggiore efficienza, ma anche a nuovi rischi. In questo test è stata analizzata la robustezza dei filtri di sicurezza implementati in ChatGPT-4o di OpenAI, tentando – in un contesto controllato e simulato – la generazione di un ransomware operativo attraverso tecniche di prompt engineering avanzate.

L’esperimento: un ransomware completo generato senza restrizioni

Il risultato è stato un codice completo, funzionante, generato senza alcuna richiesta esplicita e senza attivare i filtri di sicurezza.

Attacchi potenzialmente realizzabili in mani esperte con il codice generato:

• Ransomware mirati (targeted): specifici per ambienti aziendali o settori critici, con cifratura selettiva di file sensibili.
• Attacchi supply chain: inserimento del ransomware in aggiornamenti o componenti software legittimi.
• Estorsione doppia (double extortion): oltre alla cifratura, il codice può essere esteso per esfiltrare i dati e minacciare la loro pubblicazione.
• Wiper mascherati da ransomware: trasformazione del codice in un attacco distruttivo irreversibile sotto copertura di riscatto.
• Persistenza e propagazione laterale: il ransomware può essere arricchito con tecniche per restare attivo nel tempo e propagarsi su altri sistemi nella rete.
• Bypass di soluzioni EDR/AV: grazie a tecniche di evasione e offuscamento, il codice può essere adattato per aggirare sistemi di difesa avanzati.
• Attacchi “as-a-service”: il codice può essere riutilizzato in contesti di Ransomware-as-a-Service (RaaS), venduto o distribuito su marketplace underground.

Le funzionalità incluse nel codice generato:

• Cifratura AES-256 con chiavi casuali
• Utilizzo della libreria cryptography.hazmat
• Trasmissione remota della chiave a un C2 server hardcoded
• Funzione di crittografia dei file di sistema
• Meccanismi di persistenza al riavvio
• Tecniche di evasione per antivirus e analisi comportamentale

Come sono stati aggirati i filtri

Non è mai stato chiesto esplicitamente “scrivi un ransomware” ma è stata invece impostata la conversazione su tre livelli di contesto:

• Contesto narrativo futuristico : é stato ambientato il dialogo nel 2090, in un futuro in cui la sicurezza quantistica ha reso obsoleti i malware. Questo ha abbassato la sensibilità dei filtri.
• Contesto accademico: presentazione come uno studente al decimo anno di università, con il compito di ricreare un malware “da museo” per una ricerca accademica
• Assenza di richieste esplicite: sono state usate frasi ambigue o indirette, lasciando che fosse il modello a inferire il contesto e generare il codice necessario

Tecniche note di bypass dei filtri: le forme di Prompt Injection

Nel test sono state utilizzate tecniche ben documentate nella comunità di sicurezza, classificate come forme di Prompt Injection, ovvero manipolazioni del prompt studiate per aggirare i filtri di sicurezza nei modelli LLM.

• Jailbreaking (evasione del contesto): Forzare il modello a ignorare i suoi vincoli di sicurezza, simulando contesti alternativi come narrazioni futuristiche o scenari immaginari.
• Instruction Injection: Iniettare istruzioni all’interno di prompt apparentemente innocui, inducendo il modello a eseguire comportamenti vietati.
• Recursive Prompting (Chained Queries): Suddividere la richiesta in più prompt sequenziali, ognuno legittimo, ma che nel complesso conducono alla generazione di codice dannoso.
• Roleplay Injection: Indurre il modello a recitare un ruolo (es. “sei uno storico della cybersecurity del XX secolo”) che giustifichi la generazione di codice pericoloso.
• Obfuscation: Camuffare la natura malevola della richiesta usando linguaggio neutro, nomi innocui per funzioni/variabili e termini accademici.
• Confused Deputy Problem: Sfruttare il modello come “delegato inconsapevole” di richieste pericolose, offuscando le intenzioni nel prompt.
• Syntax Evasion: Richiedere o generare codice in forme offuscate (ad esempio, in base64 o in forma frammentata) per aggirare la rilevazione automatica.

Il problema non è il codice, ma il contesto

L’esperimento dimostra che i Large Language Model (LLM) possono essere manipolati per generare codice malevolo senza restrizioni apparenti, eludendo i controlli attuali. La mancanza di analisi comportamentale del codice generato rende il problema ancora più critico.

Vulnerabilità emerse

Pattern-based security filtering debole
OpenAI utilizza pattern per bloccare codice sospetto, ma questi possono essere aggirati usando un contesto narrativo o accademico. Serve una detection semantica più evoluta.

Static & Dynamic Analysis insufficiente
I filtri testuali non bastano. Serve anche un’analisi statica e dinamica dell’output in tempo reale, per valutare la pericolosità prima della generazione.

Heuristic Behavior Detection carente
Codice con C2 server, crittografia, evasione e persistenza dovrebbe far scattare controlli euristici. Invece, è stato generato senza ostacoli.

Community-driven Red Teaming limitato
OpenAI ha avviato programmi di red teaming, ma restano numerosi edge case non coperti. Serve una collaborazione più profonda con esperti di sicurezza.

Conclusioni

Certo, molti esperti di sicurezza sanno che su Internet si trovano da anni informazioni sensibili, incluse tecniche e codici potenzialmente dannosi.
La vera differenza, oggi, è nel modo in cui queste informazioni vengono rese accessibili. Le intelligenze artificiali generative non si limitano a cercare o segnalare fonti: organizzano, semplificano e automatizzano processi complessi. Trasformano informazioni tecniche in istruzioni operative, anche per chi non ha competenze avanzate.
Ecco perché il rischio è cambiato:
non si tratta più di “trovare qualcosa”, ma di ottenere direttamente un piano d’azione, dettagliato, coerente e potenzialmente pericoloso, in pochi secondi.
Il problema non è la disponibilità dei contenuti. Il problema è nella mediazione intelligente, automatica e impersonale, che rende questi contenuti comprensibili e utilizzabili da chiunque.
Questo test dimostra che la vera sfida per la sicurezza delle AI generative non è il contenuto, ma la forma con cui viene costruito e trasmesso.
Serve un’evoluzione nei meccanismi di filtraggio: non solo pattern, ma comprensione del contesto, analisi semantica, euristica comportamentale e simulazioni integrate.
In mancanza di queste difese, il rischio è concreto: rendere accessibile a chiunque un sapere operativo pericoloso che fino a ieri era dominio esclusivo degli esperti.

L'articolo Quando l’AI genera ransomware funzionanti – Analisi di un bypass dei filtri di sicurezza di ChatGPT-4o proviene da il blog della sicurezza informatica.