In una realtà interconnessa come quella odierna, la sicurezza informatica non riguarda solo la protezione delle informazioni. Oggi la maggior parte dei devices e degli strumenti fisici viene in qualche modo connessa in rete. Che sia per il suo funzionamento strutturale o per attività di manutenzione o monitoraggio da remoto, tutti gli strumenti sono ormai connessi e interdipendenti.

Questa realtà, se da un lato ne ha aumentato la produttività e l’efficienza, anche e soprattutto in ambito industriale, dall’altro ha ampliato le minacce su cui intervenire per attenuarne la probabilità di accadimento e l’impatto.

Tanti sono i framework e i lavori già noti sulla messa in sicurezza dell’ambiente OT e IoT ad applicazione industriale, in questo contributo ci si vuole tuttavia focalizzare su un documento lavorato a più mani da Agenzie e organizzazioni statunitensi.

In particolare il documento è stato sviluppato dacisa.gov/sites/default/files/2…Cybersecurity and Infrastructure Security Agency (CISA), Federal Bureau of Investigation (FBI), Environmental Protection Agency (EPA), and Department of Energy (DOE), le quali si dicono allarmate dai potenziali pericoli che potrebbero derivare da un malfunzionamento delle Tecnologie Operative (OT) e dei sistemi industriali di controllo (ICS) delle infrastrutture critiche.

Le misure di mitigazione più basilari per la messa in sicurezza degli apparati OT e ICS consigliate nel documento sono:

• Rimuovere le connessioni delle tecnologie OT dall’internet pubblico. Una prima attività utile è quella di mappare e identificare i propri asset esposti su rete pubbliche e, laddove tale esposizione non sia voluta e non necessaria, rimuoverla. La tecnologia OT, infatti, tendenzialmente non gode di metodi di autorizzazione e autenticazione degli accessi particolarmente evoluti e sufficientemente forti da contrastare le moderne minacce informatiche. I criminali informatici, infatti, possono ricorrere a strumenti semplici e diffusi che gli consentono di trovare rapidamente accessi su IP pubblici e da lì ottenere l’accesso ai devices OT.
• Cambiare immediatamente le password di default e usare una password forte, diversa per ciascuno strumento. Questa è una procedura di igiene informatica consigliata anche per i devices domestici, quale ad esempio la rete wi-fi di casa. Il problema del password reuse, per cui si tende ad utilizzare più chiavi di accesso per diversi strumenti, è a sua volta un grosso problema a tutti i livelli poiché la compromissione di una password può portare alla compromissione di più strumenti, in un rapporto uno a molti che avvantaggia enormemente i criminali informatici.

Dallo studio svolto in occasione della redazione del documento in analisi è emerso che molti sistemi utilizzano password di default o facilmente indovinabili. L’utilizzo di Rainbow Table e di strumenti open source facilmente reperibili rende molto semplice, agli attaccanti, compromettere gli accessi a strumenti operativi che siano esposti su reti internet pubbliche.

• Sicurezza dell’accesso remoto alle reti OT. Molte Organizzazioni, nella loro valutazione del rischio, adottano o hanno adottato soluzioni di compromesso nell’implementazione delle misure di sicurezza e delle politiche di accesso agli strumenti OT. Con le nuove consapevolezze sui rischi legati agli strumenti OT, queste politiche andrebbero aggiornate avendo cura di spostare queste connessioni su reti IP private e non più pubbliche e di utilizzare VPN con password forti e un sistema MFA che sia resistente al phishing. Dal punto di vista organizzativo è utile documentare e adottare politiche ispirate al principio dell’accesso minimo per le tipologie di funzioni e di attività dell’utente e mantenere una politica che consenta di monitorare e disabilitare in tempo utile tutti gli account dormienti.
• Segmentare reti IT e OT. Questa misura può contribuire a ridurre l’impatto potenziale delle minacce e i rischi di interruzioni delle operazioni OT. La segmentazione, infatti, riduce la possibilità di diffusione di una compromissione.
• Mantenere gli accessi e gli utilizzi manuali. Fondamentale in ottica di disaster recovery e business continuity è la possibilità di intervenire rapidamente accedendo al controllo manuale dei devices. Questa misura di sicurezza rende possibile una reazione pressoché immediata ad un incidente. Le diverse politiche di business continuity, disaster recovery, le capacità di isolamento e i backup dovrebbero essere testati regolarmente per garantire la sicurezza delle operazioni manuali in caso di incidente.

Le Organizzazioni dovrebbero inoltre mantenere regolari comunicazioni con i propri fornitori di servizi e sistemi che possono assisterle nel configurare i devices nel modo più adeguato a garantire le specifiche esigenze di sicurezza dell’Organizzazione. I problemi di errata configurazione, infatti, possono accadere in ogni momento. Mantenere dei canali di comunicazione con i propri fornitori può facilitare la tracciabilità e la gestione di questi eventi, riducendo la probabilità di futuri problemi e vulnerabilità.

Queste sono alcune misure base, di facile attuazione e quindi urgenti, che possono essere adottate dalle Organizzazioni che adottano strumenti e soluzioni OT.

L'articolo Connessi e vulnerabili: come mettere in sicurezza OT e ICS nel 2025 proviene da il blog della sicurezza informatica.

Ancora niente contratto.
Anche se ieri il mio superiore mi ha garantito che è stato firmato dal capo supremo mercoledì sera. Siamo d'accordo che se non mi arriva per posta oggi, non mi presenterò al lavoro nemmeno lunedì.
Intanto ieri sono passata in ufficio per liberare la scrivania e i cassetti, visto che lunedì ritorna la signora in congedo maternità. Io mi metterò nella postazione dell'apprendista che nel frattempo ha cambiato ufficio (e dipartimento) a causa di malessere psicologico.
Per fortuna sono passata prima dell'ora di chiusura perché il mio badge é già stato disattivato e non apre più le porte. Mi sono annunciata allo sportello come se fossi un cliente o fornitore.

Efficienza dello Stato. 🤐

#lavoro #contratto #attesa #Stato

Have you ever finished up a bit of code and thought that typing “git push” in a terminal is just not a satisfying finish? So did [penumbriel], so he built a big red button he could smash instead.

This is a very simple hack: an Arduino sits inside a 3D-printed case that holds a big, red button. The case itself is very sturdily made to withstand a good satisfying smack: it has thick walls, brass insets, and rubber feet to protect the de The code for the Arduino is very, very simple: it spoofs a USB HID using the standard keyboard library, and automatically types out “git push” whenever the button is pressed. Or smashed, because you know you’re going to want to slam that thing. So far, so good– very innovative for 2006, right?

The detail that made this project stand out in 2025 was the technique [penumbriel] used for lettering– we’re always looking
With a simple soap-and-water mask, the cured silicone peels right off, leaving a clean label.
for new ways to make a good front panel. In this case, the letters were printed as a valley, and filled with silicone adhesive. To protect the top surface of the print, soapy water was used as a mask. The silicone would not adhear to the wet plastic, so all [penumbriel] had to do was peel it off after it had cured, leaving solid white inside. It’s a neat trick, and a great way to use up an old tube of silicone before it goes hard. You could also use it for injection molding, but this is a great use for the dregs.

This might go well next to the programmer’s macro pad we featured a while back, but it really needs to stay as a big red button for maximum satisfaction.

hackaday.com/2025/06/20/the-mo…

The last time we checked in with the ELIZA archeology project, they had unearthed the earliest known copy of the code for the infamous computer psychiatrist written in MAD-SLIP. After a lot of work, that version is now running again, and there were a number of interesting surprises.

While chatbots are all the modern rage, [Joseph Weizenbaum] created what could be the first one, ELIZA, in the mid-1960s. Of course, it wasn’t as capable as what we have today, but it is a good example of how simple it is to ape human behavior.

The original host was an IBM 7094, and MAD-SLIP fell out of favor. Most versions known previously were in Lisp or even Basic. But once the original code was found, it wasn’t enough to simply understand it. They wanted to run it.

Fortunately, there is an emulator for the IBM 7094. MAD-SLIP is around, too, but for whatever reason, didn’t support all the functions that [Weizenbaum] had used. The 2,600 lines of code are mostly undocumented, and the only copy was on fanfold printer paper, so the first step was getting the text in digital form.

Once it was manually transcribed, they found some functions were missing in their MAD-SLIP version. Rewriting the functions and correcting a typo made everything work.

The original version had a learning mode that did not carry over to the later clones. There’s an example of how to teach new rules in the paper. You can also see a video (below) of the original code duplicating (nearly) the original published conversations from the 1966 paper.

We have been following the team for some time and they’ve made their work available if you want to try it. We have thought a lot about Eliza since the chatbots have started taking over.

youtube.com/embed/j5Tw-XVcsRE?…

hackaday.com/2025/06/20/eliza-…

PVA filament with a core. (Credit: Lost In Tech)
PVA filament is an interesting filament type, for the reason that while it can be printed with any FDM printer, it supposedly readily dissolves in water, which is also the reason why PVA glue sticks are so popular when doing crafts and arts with young children. This property would make PVA filament ideal for printing supports if your printer can handle two different materials at the same time. So surely you can just pick any old PVA filament spool and get to printing, right? As [Lost in Tech] found out, this is not quite the case.

As an aside, watching PVA supports dissolve in water set to classical music (Bach’s Air from Orchestral Suite No. 3) is quite a pleasant vibe. After thus watching the various PVA prints dissolve for a while, we are left to analyze the results. The first interesting finding was that not every PVA filament dissolved the same way, or even fully.

The first gotcha is that PVA can stand for polyvinyl acetate (the glue stick) or polyvinyl alcohol (a thickener and stabilizer) , with the ‘PVA’ filament datasheets for each respective filament showing various combinations of both types of PVA. This results in wildly different properties per filament, both in terms of Shore hardness, their printability, as well as their ability to dissolve in water. Some of the filament types (Yousu, Reprapper) also have an outer layer and inner core for some reason.

Ultimately the message appears to be that ‘PVA’ filament requires a fair bit of research to have any chance of having a relatively trouble-free printing experience.

youtube.com/embed/2zQ6tGXKEUk?…

hackaday.com/2025/06/20/pva-fi…

AND gate implemented as diode-resistor logic. (Credit: Anthony Francis-Jones)
The fun part about logic gates is that there are so many ways to make them, with each approach having its own advantages and disadvantages. Although these days transistor-transistor logic (TTL) is the most common, diode-transistor logic (DTL) once was a regular sight, as well as diode-resistor logic (DRL). These logic gates are the topic of a recent video by [Anthony Francis-Jones], covering a range of logic gates implemented using mostly diodes and resistors.

Of note is that there’s another class of logic gates: this uses resistors and transistors (RTL) and preceded DTL. While DRL can be used to implement AND and OR logic gates, some types of logic gates (e.g. NOT) require an active (transistor) element, which is where DTL comes into play.

In addition to the construction of a rather demonstration system and explanation of individual logic gates, [Anthony] also shows off a range of DTL cards used in the Bendix G-15 and various DEC systems. Over time TTL would come to dominate as this didn’t have the diode voltage drop and other issues that prevented significant scaling. Although the rise of VLSI has rendered DRL and DTL firmly obsolete, they still make for a fascinating teaching moment and remind us of the effort over the decades to make the computing device on which you’re reading this possible.

youtube.com/embed/bK0qKcZQLQQ?…

hackaday.com/2025/06/20/buildi…

If you have ever played around with lenses, you’ll know that a convex lens can focus an image onto a target. It can be as simple as focusing the sun with a magnifying glass to burn a hole in a piece of paper, but to achieve the highest quality images in a camera there is a huge amount of optical engineering and physics at play to counteract the imperfections of those simple lenses.

Many of us in the hardware world aren’t optical specialists but our work frequently involves camera modules, so [Matt Williams]’ piece for PetaPixel laying out a primer on lens design should be essential reading well beyond its target audience of photographers.

In it we learn how a photographic lens is assembled from a series of individual lenses referred to as elements, combined together in groups to lend the required properties to the final assembly. We are introduced to the characteristics of different types of glass, and to the use of lens coatings to control reflections. Then we see examples of real lens systems, from some famous designs with their roots in the 19th century, to the lenses of today.

Sometimes a piece written for an entirely different audience can bring really useful insights into our field, and this is one of those times. We learned something, and we think you will too.

Header image: 4300streetcar, CC BY 4.0.

hackaday.com/2025/06/20/all-yo…

This week, Hackaday’s Elliot Williams and Al Williams caught up after a week-long hiatus. There was a lot to talk about, including clocks, DIY USB cables, and more.

In Hackaday news, the 2025 Pet Hacks Contest is a wrap. Winners will be announced soon, so stay tuned. Meanwhile, how’d you like a free ticket to attend Supercon? Well, free if you submit a talk and get accepted. November is right around the corner, so get those talks ready.

Hackaday is a big fan of the NOAA Polar sats, and it looks like they are on their last figurative legs. The agency has left them up for now, but won’t be keeping them in shape, and if they misbehave, they may be neutralized for safety.

Since Elliot was off, Al supplied the sound, and in a bout of karma, Elliot had to do the guessing this week. How’d he do? Not bad, but there’s room to do better. If you do better, there could be a coveted Hackaday Podcast T-shirt in your future.

Moving on the hacks, the guys were interested in magnets, clocks, cables, 3D printed machine tools, and even old moonbase proposals. For the can’t miss articles, Al took the bifecta, since Elliot picked a piece on the machine that generated laugh tracks in the latter part of the 20th century and Al shamelessly picked his own article about the role of British ham radio operators during WWII.

Miss anything? Check out the links below and catch up. As always, drop a comment and tell us what you think about the week in Hackaday.

html5-player.libsyn.com/embed/…

Download in DRM-free MP3 unencrypted and oxygen-free.

Where to Follow Hackaday Podcast

Places to follow Hackaday podcasts:

• iTunes
• Spotify
• Stitcher
• RSS
• YouTube
• Check out our Libsyn landing page

Episode 325 Show Notes:

News:

• 2025 Pet Hacks Contest
• NOAA Polar Satellites

What’s that Sound?

• Know what the sound was? [Elliot] got close! Let’s see if you can do better.

Interesting Hacks of the Week:

• Iron Nitride Permanent Magnets Made With DIY Ball Mill
• This Thermochromic Clock Is A Ray Of Sunshine
  
  • What Happened To Duracell PowerCheck?

  
  

• The Most Trustworthy USB-C Cable Is DIY
  
  • All About USB-C: Cable Types

  
  

• A Concentric Clock With Multiple Modes
• Compound Press Bends, Punches And Cuts Using 3D Printed Plastic
• History Of Forgotten Moon Bases

Quick Hacks:

• Elliot’s Picks:
  
  • Expanding Racks In The Spirit Of The Hoberman Sphere
  • The Switch 2 Pro Controller: Prepare For Glue And Fragile Parts
  • Watkin’s Tower: London’s Failed Eiffel Tower
  • BhangmeterV2 Answers The Question “Has A Nuke Gone Off?”

  
  

• Al’s Picks:
  
  • Building A Cyberpunk Modular Keyboard
  • Split Keyboard Uses No PCB
  • LED Probe: A Smart, Simple Solution For Testing LEDs

  
  

Can’t-Miss Articles:

• Just For Laughs: Charlie Douglass And The Laugh Track
• Crowdsourcing SIGINT: Ham Radio at War
  
  • High-Stakes Fox Hunting: The FCC’s Radio Intelligence Division In World War II

  
  

hackaday.com/2025/06/20/hackad…

USB audio is great, but what if you needed to use it and had no budget? Well, depending on the contents of your parts bin, you might be able to use [Veyniac]’s Pico-Audio-Interface as a free (and libre! It’s GPL3.0) sound capture device.

In the project’s Reddit thread, [Veyniac] describes needing audio input for his homemade synth, but having no budget. Necessity being the mother of invention, rather than beg borrow or steal a device with a working sound card, he hacked together this lovely device. It shows up as a USB Audio Class 2.0 device so should work with just about anything, and offers 12-bit resolution and 4x oversampling to try and deal with USB noise with its 2-channel, 44.1 kHz sample rate.

Aside from the Pico, all you need is an LM324 op-amp IC and a handful of resistors and capacitors — [Veyniac] estimates about $10 to purchase the whole BOM. He claims that the captured audio sounds okay in his use, but can’t guarantee it will be for anyone else, noise being the fickle beast that it is. We figure that sounding “Okay” has got to be pretty good, given that you usually get what you pay for — and again, [Veyniac] did build this in a cave with a box of scraps. Well, except for the cave part. Probably.

While the goal here was not to rival a commercial USB sound card, we have seen projects to do that. We’re quite grateful to [Omadeira] for the tip, because this really is a hack. If you, too, want a share of our undying gratitude (which is still worth its weight in gold, despite fluctuations in the spot price of precious metals), send in a tip of your own.

hackaday.com/2025/06/20/pi-pic…

Nelle ultime ore, un’ondata massiccia di defacement ha preso di mira almeno una quindicina di siti web italiani. L’attacco è stato rivendicato dal threat actor xNot_RespondinGx (team xnot_respondingx), che ha lasciato un messaggio in un file readme.txt presente su ciascun dominio compromesso.

Tra i siti sfregiati figurano realtà di vario tipo: agenzie di servizi, istituzioni private e-commerce e portali tecnici, di seguito gli obiettivi colpiti dal defacement da parte degli hacker di xNot_RespondinGx.

• hxxps://www.languageteam.it/readme.txt
• hxxps://www.ficusbarbistrot.it/readme.txt
• hxxps://giuliettaallago.it/readme.txt
• hxxps://www.servicewebsrl.it/readme.txt
• hxxps://shoptechim.joyadv.it/readme.txt
• hxxps://www.techimgroup.it/readme.txt
• hxxps://prenotazioni.ristopollicino.it/readme.txt
• hxxps://www.sape.it/readme.txt
• hxxps://shop.speedyblock.it/readme.txt
• hxxps://www.simasrl.it/readme.txt
• hxxps://www.service3cleaning.it/readme.txt
• hxxps://www.vistadarsena.it/readme.txt
• hxxps://mymi.it/readme.txt
• hxxps://www.strumentidiserraggio.it/readme.txt
• hxxps://www.vinoungherese.it/readme.txt

Tutti quanti i siti rispondono con lo stesso messaggio di errore. La frase “menikmati sisa hidup sebelum ajal menjemputku”. In lingua indonesiana e può essere tradotta in italiano come: “Godermi il resto della vita prima che la morte venga a prendermi.”. È una frase esistenziale e malinconica, spesso usata per esprimere la consapevolezza della mortalità e il desiderio di vivere intensamente ciò che resta della propria vita. Potrebbe anche essere un modo per attirare attenzione, aggiungendo un tono oscuro o introspettivo al gesto.

In passato lo stesso gruppo aveva realizzato deface riportando il messaggio “L’amore può dare forza alle persone, ma a volte le rende deboli”.

L’ondata coordinata di defacement firmata da xNot_RespondinGx è un chiaro segnale del livello di vulnerabilità dei sistemi web in Italia. Se da una parte i defacement non puntano a furti o interruzioni di servizi, dall’altra mostrano debolezze reali nel presidio della sicurezza digitale.

Aziende, enti e gestori di siti web devono considerare questo fenomeno con la massima attenzione, aggiornando regolarmente il proprio stack, blindando gli accessi e attivando un monitoraggio h24. Solo così si potrà recuperare la fiducia degli utenti e prevenire attacchi con conseguenze più gravi.

Che cosa si intende per deface di un sito web

Il deface (o defacement) di un sito web è una tecnica di attacco informatico in cui un attore malevolo riesce ad alterare il contenuto visibile di una pagina web, sostituendolo con messaggi propri, immagini, video o link. In molti casi, si tratta di una forma di protesta (hacktivism), propaganda politica o dimostrazione di forza tecnica da parte di un gruppo o singolo hacker.

A differenza di attacchi volti al furto di dati o alla compromissione economica di un sistema, il defacement ha uno scopo prevalentemente comunicativo. Gli attaccanti vogliono essere visti e lasciare un messaggio, spesso rivolto a un pubblico specifico, a un governo, o per rivendicare un’ideologia.

Il deface avviene in genere sfruttando vulnerabilità note o configurazioni errate del server web o del CMS (Content Management System) utilizzato. I metodi più comuni includono:

• Accesso via FTP o SSH compromesso: password deboli o credenziali trafugate (ad esempio dagli infostealer) permettono agli attaccanti di caricare file o modificare quelli esistenti.
• Sfruttamento di vulnerabilità CMS: molti siti si basano su CMS come WordPress, Joomla o Drupal. Se questi non vengono aggiornati regolarmente, possono essere soggetti a exploit noti.
• Injection di codice via upload: caricamento di file dannosi tramite moduli vulnerabili che non controllano correttamente il tipo di file.
• Escalation di privilegi: un utente con accesso limitato riesce a ottenere privilegi amministrativi tramite bug nel software.

Solitamente l’attaccante sostituisce:

• La homepage del sito o altre pagine di alto profilo.
• File specifici come index.html, index.php o file appositamente caricati come readme.txt, come accaduto nel recente caso italiano.
• Testi, immagini, stili CSS e script JavaScript, spesso con contenuti provocatori, insulti o rivendicazioni politiche.

Anche se non sempre causa danni diretti a livello economico, un deface può:

• Minare la credibilità e la reputazione dell’organizzazione colpita.
• Indicare vulnerabilità latenti nella sicurezza del sito o dell’infrastruttura.
• Essere un campanello d’allarme per attacchi più gravi imminenti, come ransomware o data breach.

In definitiva, un defacement non è solo un atto di vandalismo digitale, ma una chiara indicazione che la sicurezza del sito è stata compromessa e deve essere immediatamente rivista.

Questo articolo si basa su informazioni, integralmente o parzialmente tratte dalla piattaforma di intelligence di Recorded Future, partner strategico di Red Hot Cyber e punto di riferimento globale nell’intelligence sulle minacce informatiche. La piattaforma fornisce analisi avanzate utili a individuare e contrastare attività malevole nel cyberspazio.

L'articolo 15 Deface in poche ore di siti italiani! Gli hacker: “Godermi la vita prima che la morte venga a prendermi” proviene da il blog della sicurezza informatica.

Nel mezzo degli intensi combattimenti tra Iran e Israele, il cyberspazio è stato coinvolto in una nuova fase di conflitto. Con il lancio dell’operazione israeliana Rising Lion, mirata all’infrastruttura nucleare iraniana, lo scontro tra i due Paesi ha smesso di essere nascosto e si è trasformato in una vera e propria guerra informatica. Centinaia di vittime da entrambe le parti non sono state solo il risultato di attacchi missilistici, ma sono state anche accompagnate da attacchi devastanti nello spazio digitale.

In questo contesto, decine di gruppi di hacktivistisi sono attivati, scegliendo rapidamente da che parte stare nel conflitto e lanciando attacchi contro la parte avversa. Gli analisti hanno registrato la partecipazione di oltre cento diverse formazioni digitali, che agiscono o nell’interesse di Israele o, più spesso, a sostegno dell’Iran. securitylab.ru/news/560464.php

La parte iraniana ha reagito agli eventi con una severità senza precedenti. Le autorità del Paese hanno quasi completamente isolato il Paese dal mondo esterno: dal 13 giugno sono iniziate le massicce restrizioni all’accesso a Internet e, pochi giorni dopo, la capacità di traffico è stata ridotta di circa l’80%. I residenti sono stati costretti a passare all’intranet statale, mentre le autorità hanno raccomandato ai funzionari di interrompere l’utilizzo di qualsiasi dispositivo connesso e persino di WhatsApp .

I media statali hanno diffuso notizie di un massiccio attacco informatico da parte di Israele. Secondo i rapporti ufficiali, alcuni attacchi sono stati respinti, mentre altri hanno causato interruzioni all’infrastruttura digitale, che ora è in fase di ripristino da parte di team tecnici. Come alternativa al blocco di Internet e delle comunicazioni internazionali, si è registrato interesse per l’uso illegale dei terminali Starlink nel contesto delle restrizioni. Sebbene il loro utilizzo sia vietato in Iran, si stima che nel Paese possano essere presenti decine di migliaia di dispositivi di questo tipo.

D’altro canto, Israele si è dimostrato il principale bersaglio degli attacchi degli hacktivisti, sia in termini di numero di attacchi che di entità dei danni informatici. Secondo Radware, solo dal 13 giugno, il Paese ha subito più di 30 attacchi DDoS al giorno, e il numero ha continuato a crescere nei giorni successivi. Quasi il 40% di tutti gli attacchi DDoS degli hacktivisti registrati a livello mondiale è attualmente rivolto a Israele.

Ma gli attacchi DDoS sono solo la punta dell’iceberg. Il livello di protezione è crollato, fughe di dati, infezioni da malware e disinformazione si stanno diffondendo. Ad esempio, il 18 giugno, il gruppo Handala ha annunciato una fuga di dati di 425 GB dall’azienda di logistica israeliana Mor Logistics e ha ottenuto l’accesso a 4 TB di documenti classificati del Weizmann Institute of Science, colpito da un attacco missilistico iraniano il giorno prima.

Handala è solo uno delle decine di gruppi che prendono parte all’attacco a Israele. Oltre a quelli iraniani, sono diventati attivi anche gruppi provenienti dall’Asia meridionale e da altre regioni. Non si tratta solo di azioni caotiche di singoli gruppi, ma di un fronte informatico sincronizzato con una base ideologica comune e una propaganda mirata.

Tracker dei gruppi coinvolti nel conflitto militare Iran-Israele (CyberKnow)

Gli hacktivisti israeliani sono molto meno attivi, ma un recente attacco ha mostrato il loro potenziale distruttivo. Il gruppo Predatory Sparrow ha rivendicato la responsabilità di aver bloccato il sito web e gli sportelli bancomat della banca iraniana Bank Sepah, un’istituzione che gli Stati Uniti hanno precedentemente collegato al programma nucleare iraniano.

Il conflitto nel cyberspazio non si è limitato ai due Paesi. Gli attacchi si sono estesi anche a Stati formalmente neutrali, come Egitto, Arabia Saudita e soprattutto Giordania. Quest’ultima è diventata il bersaglio principale di attacchi al di fuori di Israele, presumibilmente per la sua “posizione morbida” nell’attuale conflitto. Gli attacchi informatici sono stati accompagnati da post di propaganda e hashtag che collegavano direttamente la neutralità di questi Paesi al tradimento della causa palestinese.

Gli esperti non escludono un’ulteriore escalation, soprattutto alla luce delle voci di un possibile coinvolgimento militare statunitense. Gli hacktivisti stanno già attivamente discutendo la possibilità di attacchi alle strutture digitali americane su Telegram. In risposta ai possibili rischi, i centri di scambio di informazioni di settore IT-ISAC e Food and Ag-ISAC hanno emesso un avviso congiunto, invitando le aziende americane a studiare urgentemente le tattiche e i comportamenti dei gruppi associati all’Iran.

La guerra digitale tra Iran e Israele non si limita più ad attacchi segreti. Tra esplosioni, morti e distruzione reali, si sta svolgendo nello spazio digitale uno scontro altrettanto feroce e pericoloso, con fronti ideologici, distruzione di infrastrutture e conseguenze imprevedibili per l’intera regione.

L'articolo I Cyber attacchi potrebbero diventare missili. L’escalation tra Iran e Israele e 100 gruppi di hacker in campo proviene da il blog della sicurezza informatica.

Meshtastic just released an eye-watering 9.5 CVSS CVE, warning about public/private keys being re-used among devices. And I’m the one that wrote the code. Not to mention, I triaged and fixed it. And I’m part of Meshtastic Solutions, the company associated with the project. This is is the story of how we got here, and a bit of perspective.

First things first, what kind of keys are we talking about, and what does Meshtastic use them for? These are X25519 keys, used specifically for encrypting and authenticating Direct Messages (DMs), as well as optionally for authorizing remote administration actions. It is, by the way, this remote administration scenario using a compromised key, that leads to such a high CVSS rating. Before version 2.5 of Meshtastic, the only cryptography in place was simple AES-CTR encryption using shared symmetric keys, still in use for multi-user channels. The problem was that DMs were also encrypted with this channel key, and just sent with the “to” field populated. Anyone with the channel key could read the DM.

I re-worked an old pull request that generated X25519 keys on boot, using the rweather/crypto library. This sentence highlights two separate problems, that both can lead to unintentional key re-use. First, the keys are generated at first boot. I was made painfully aware that this was a weakness, when a user sent an email to the project warning us that he had purchased two devices, and they had matching keys out of the box. When the vendor had manufactured this device, they flashed Meshtastic on one device, let it boot up once, and then use a debugger to copy off a “golden image” of the flash. Then every other device in that particular manufacturing run was flashed with this golden image — containing same private key. sigh

There’s a second possible cause for duplicated keys, discovered while triaging the golden image issue. On the Arduino platform, it’s reasonably common to use the random() function to generate a pseudo-random value, and the Meshtastic firmware is careful to manage the random seed and the random() function so it produces properly unpredictable values. The crypto library is solid code, but it doesn’t call random(). On ESP32 targets, it does call the esp_random() function, but on a target like the NRF52, there isn’t a call to any hardware randomness sources. This puts such a device in the precarious position of relying on a call to micros() for its randomness source. While non-ideal, this is made disastrous by the fact that the randomness pool is being called automatically on first boot, leading to significantly lower entropy in the generated keys.

Release 2.6.11 of the Meshtastic firmware fixes both of these issues. First, by delaying key generation until the user selects the LoRa region. This makes it much harder for vendors to accidentally ship devices with duplicated keys. It gives users an easy way to check, just make sure the private key is blank when you receive the device. And since the device is waiting for the user to set the region, the micros() clock is a much better source of randomness. And second, by mixing in the results of random() and the burnt-in hardware ID, we ensure that the crypto library’s randomness pool is seeded with some unique, unpredictable values.

The reality is that IoT devices without dedicated cryptography chips will always struggle to produce high quality randomness. If you really need secure Meshtastic keys, you should generate them on a platform with better randomness guarantees. The openssl binary on a modern Linux or Mac machine would be a decent choice, and the Meshtastic private key can be generated using openssl genpkey -algorithm x25519 -outform DER | tail -c32 | base64.

What’s Up with SVGs?

You may have tried to share a Scalable Vector Graphics (SVG) on a platform like Discord, and been surprised to see an obtuse text document rather than your snazzy logo. Browsers can display SVGs, so why do many web platforms refuse to render them? I’ve quipped that it’s because SVGs are Turing complete, which is almost literally true. But in reality it’s because SVGs can include inline HTML and JavaScript. IBM’s X-Force has the inside scoop on the use of SVG files in fishing campaigns. The key here is that JavaScript and data inside an SVG can often go undetected by security solutions.

The attack chain that X-Force highlights is convoluted, with the SVG containing a link offering a PDF download. Clicking this actually downloads a ZIP containing a JS file, which when run, downloads and attempts to execute a JAR file. This may seem ridiculous, but it’s all intended to defeat a somewhat sophisticated corporate security system, so an inattentive user will click through all the files in order to get the day’s work done. And apparently this tactic works.

*OS Spyware

Apple published updates to its entire line back in February, fixing a pair of vulnerabilities that were being used in sophisticated targeted attacks. CVE-2025-43200 was “a logic issue” that could be exploited by malicious images or videos sent in iCloud links. CVE-2025-24200 was a flaw in USB Restricted Mode, that allowed that mode to be disabled with physical access to a device.

What’s newsworthy about these vulnerabilities is that Citizen Lab has published a report that CVE-2025-43200 was used in a 0-day exploitation of journalists by the Paragon Graphite spyware. It is slightly odd that Apple credits the other fixed vulnerability, CVE-2025-24200, to Bill Marczak, a Citizen Lab researcher and co-author of this report. Perhaps there is another shoe yet to drop.

Regardless, iOS infections have been found on the phones of two separate European Journalists, with a third confirmed targeted. It’s unclear what customer contracted Paragon to spy on these journalists, and what the impetus was for doing so. Companies like Paragon, NSO Group, and others operate within a legal grey area, taking actions that would normally be criminal, but under the authority of governments.

A for Anonymous, B for Backdoor

WatchTowr has a less-snarky-than-usual treatment of a chain of problems in the Sitecore Experience that take an unauthenticated attacker all the way to Remote Code Execution (RCE). The initial issue here is the pre-configured user accounts, like default\Anonymous, used to represent unauthenticated users, and sitecore\ServicesAPI, used for internal actions. Those special accounts do have password hashes. Surely there isn’t some insanely weak password set for one of those users, right? Right? The password for ServicesAPI is b.

ServicesAPI is interesting, but trying the easy approach of just logging in with that user on the web interface fails with a unique error message, that this user does not have access to the system. Someone knew this could be a problem, and added logic to prevent this user from being used for general system access, by checking which database the current handler is attached to. Is there an endpoint that connects to a different database? Naturally. Here it’s the administrative web login, that has no database attached. The ServicesAPI user can log in here! Good news is that it can’t do anything, as this user isn’t an admin. But the login does work, and does result in a valid session cookie, which does allow for other actions.

There are several approaches the WatchTowr researchers tried, in order to get RCE from the user account. They narrowed in on a file upload action that was available to them, noting that they could upload a zip file, and it would be automatically extracted. There were no checks for path traversal, so it seems like an easy win. Except Sitecore doesn’t necessarily have a standard install location, so this approach has to guess at the right path traversal steps to use. The key is that there is just a little bit of filename mangling that can be induced, where a backslash gets replaced with an underscore. This allows a /\/ in the path traversal path to become /_/, a special sequence that represents the webroot directory. And we have RCE. These vulnerabilities have been patched, but there were more discovered in this research, that are still to be revealed.

The Day the Internet Went Down

OK, that may be overselling it just a little bit. But Google Cloud had an eight hour event on the 12th, and the repercussions were wide, including taking down parts of Cloudflare for part of that time on the same day.

Google’s downtime was caused by bad code that was pushed to production with insufficient testing, and that lacked error handling. It was intended to be a quota policy check. A separate policy change was rolled out globally, that had unintentional blank fields. These blank fields hit the new code, and triggered null pointer de-references all around the globe all at once. An emergency fix was deployed within an hour, but the problem was large enough to have quite a long tail.

Cloudflare’s issue was connected to their Workers KV service, a Key-Value store that is used in many of Cloudflare’s other products. Workers KV is intended to be “coreless”, meaning a cascading failure should be impossible. The reality is that Workers KV still uses a third-party service as the bootstrap for that live data, and Google Cloud is part of that core. When Google’s cloud starting having problems, so did Cloudflare, and much of the rest of the Internet.

I can’t help but worry just a bit about the possible scenario, where Google relies on an outside service, that itself relies on Cloudflare. In the realm of the power grid, we sometimes hear about the cold start scenario, where everything is powered down. It seems like there is a real danger of a cold start scenario for the Internet, where multiple giant interdependent cloud vendors are all down at the same time.

Bits and Bytes

Fault injection is still an interesting research topic, particularly for embedded targets. [Maurizio Agazzini] from HN Security is doing work on voltage injection against an ESP32 V3 target, with the aim of coercing the processor to jump over an instruction and interpret a CRC32 code as an instruction pointer. It’s not easy, but he managed 1.5% success rate at bypassing secure boot with the voltage injection approach.

Intentional jitter is used in many exploitation tools, as a way to disguise what might otherwise be tell-tale traffic patterns. But Varonis Threat Labs has produced Jitter-Trap, a tool that looks for the Jitter, and attempts to identify the exploitation framework in use from the timing information.

We’ve talked a few times about vibe researching, but [Craig Young] is only tipping his toes in here. He used an LLM to find a published vulnerability, and then analyzed it himself. Turns out that the GIMP despeckle plugin doesn’t do bounds checking for very large images. Back again to an LLM, to get a Python script to generate such a file. It does indeed crash GIMP when trying to despeckle, confirming the vulnerability report, and demonstrating that there really are good ways to use LLMs while doing security research.

hackaday.com/2025/06/20/this-w…