Registrati al webinar: La sicurezza delle API nell’era dell’intelligenza artificiale

Il nuovo report State of Apps and API Security 2025: How AI Is Shifting the Digital Terrain, parte della serie State of the Internet Report (SOTI) di Akamai, fotografa uno scenario preoccupante per la sicurezza digitale globale: nel 2024 gli attacchi web sono aumentati del 33%, raggiungendo la cifra record di 311 miliardi rispetto all’anno precedente. Un trend in forte ascesa, spinto dalla rapida adozione di applicazioni basate sull’intelligenza artificiale, che stanno ampliando le superfici di attacco e introducendo nuove criticità per la sicurezza. Il report si basa sull’analisi di oltre un terzo del traffico web globale gestito dall’infrastruttura di Akamai, offrendo insight di valore per comprendere le evoluzioni delle minacce e delle vulnerabilità.

API nel mirino: oltre 150 miliardi di attacchi in 12 mesi

Tra i dati più allarmanti emerge la centralità delle API come vettori di attacco: solo tra gennaio 2023 e dicembre 2024 Akamai ha documentato 150 miliardi di attacchi contro le API. In particolare, le API legate a soluzioni di AI sono risultate tra le più esposte, complice una maggiore apertura verso l’esterno e l’utilizzo di sistemi di autenticazione spesso inadeguati. Questa vulnerabilità è aggravata dalla crescente sofisticazione degli attacchi condotti proprio grazie all’intelligenza artificiale, che consente ai cybercriminali di migliorare continuamente le proprie tecniche.

Attacchi DDoS Layer 7: +94% in un anno

Il report segnala anche un’escalation impressionante degli attacchi DDoS a livello applicativo (Layer 7), che nel 2024 hanno superato i 1,1 trilioni a trimestre, con un incremento del 94% rispetto all’inizio del 2023. Un fenomeno favorito dalla persistenza dell’HTTPS flooding come principale vettore di attacco e dalla continua evoluzione dei bot.

Settori più colpiti: e-commerce e high-tech sotto assedio

Non sorprende che i settori più bersagliati siano e-commerce e high-tech:

• Oltre 230 miliardi di attacchi web hanno colpito le aziende e-commerce, rendendolo il settore più esposto.
• Il settore high-tech, invece, è quello più colpito dagli attacchi DDoS Layer 7, con circa 7.000 miliardi di attacchi registrati in 24 mesi.

Tra gli altri trend rilevati:

• Incidenti correlati alla OWASP API Security Top 10 in crescita del 32%.
• Aumenti del 30% negli avvisi di sicurezza legati al framework MITRE, a conferma del crescente uso di tecniche avanzate, automazione e AI per violare le API.
• Sempre più critiche le vulnerabilità legate a API shadow e zombie, in ecosistemi API sempre più complessi e difficili da mappare.

Le raccomandazioni di Akamai per difendersi

Il report include anche una panoramica sulle strategie di mitigazione consigliate, offrendo alle aziende indicazioni pratiche per rafforzare la protezione delle API e delle applicazioni web, nonché strumenti per la valutazione dei rischi e il contrasto alle minacce avanzate basate su AI. Per approfondire, registrati al webinar sulla Sicurezza delle API nell’era dell’AI, live il 29 maggio alle ore 11:30.

L'articolo Attacchi web in aumento del 33%! Le API sono l’obiettivo principale. Iscriviti al Webinar di Akamai proviene da il blog della sicurezza informatica.

Un’onda d’urto tra vulnerabilità, webshell e gruppi ransomware

Il 14 maggio 2025, il team di intelligence di ReliaQuest ha aggiornato la propria valutazione su una pericolosa vulnerabilità: CVE-2025-31324, una falla di tipo “unrestricted file upload” nel componente SAP NetWeaver Visual Composer, che consente l’esecuzione remota di codice (Remote Code Execution – RCE). Sebbene inizialmente classificata come una semplice “remote file inclusion”, ulteriori analisi hanno rivelato che la natura della falla era decisamente più pericolosa: chiunque, senza autenticazione, poteva caricare file JSP malevoli sul server SAP e ottenere l’accesso remoto.

La piattaforma Recorded Future, in una nota pubblicata il 15 maggio, ha confermato che le campagne di attacco condotte dai gruppi ransomware BianLian e RansomEXX (Defray777) hanno sfruttato attivamente questa vulnerabilità, nonostante SAP avesse già rilasciato una patch il 24 aprile. Il componente coinvolto, va detto, è deprecato dal 2015. Ma come sappiamo bene, nella sicurezza informatica ciò che è vecchio non muore mai… spesso resta esposto, ignorato, e tremendamente vulnerabile.

Cosa dicono i dati: IP, domini e infrastrutture dannose

Secondo l’analisi condotta da Insikt Group (Recorded Future), le infrastrutture dannose riconducibili agli attacchi includono:

• Gli indirizzi IP 184.174.96.70 e 184.174.96.74, entrambi classificati con un rischio moderato (30/100).
• Il dominio dns.telemetrymasterhostname.com, associato alle fasi C2 (command and control) dell’attacco, valutato con un rischio molto alto (66/100).
• Il prodotto coinvolto: SAP NetWeaver Visual Composer, con un indice di rischio di 66, e classificato come obiettivo critico dell’infrastruttura malevola.
• La vulnerabilità principale: CVE-2025-31324, che raggiunge un punteggio di rischio massimo pari a 99.

Tutti questi elementi compongono il mosaico tecnico che ha permesso l’esecuzione remota di codice nei sistemi compromessi.

La dinamica dell’attacco: dalle JSP ai payload modulari

Gli attori della minaccia hanno sfruttato l’endpoint /developmentserver/metadatauploader per caricare JSP webshell come helper.jsp, cache.jsp, rrx.jsp, dyceorp.jsp all’interno della directory:

j2ee/cluster/apps/sap.com/irj/servlet_jsp/irj/root/

Queste webshell consentivano il controllo remoto tramite richieste HTTP GET, permettendo una piena esecuzione di comandi sul server vittima.

Nel caso specifico di RansomEXX, l’infrastruttura di attacco si è dimostrata particolarmente sofisticata: dopo l’upload iniziale, gli attori hanno utilizzato MSBuild per compilare e attivare un backdoor modulare denominata PipeMagic. Questa, a sua volta, ha consentito l’iniezione in memoria del noto framework di red-teaming Brute Ratel, all’interno del processo dllhost.exe. Tutto questo è stato eseguito in modalità stealth, grazie alla tecnica Heaven’s Gate, che permette di passare da 32-bit a 64-bit mode aggirando le difese basate su syscall.

Il ruolo della Cina e la minaccia APT sulle infrastrutture critiche

Non meno rilevante è l’altra faccia di questa minaccia: la componente APT (Advanced Persistent Threat). Il gruppo cinese Chaya_004, secondo Forescout, avrebbe compromesso oltre 581 sistemi SAP NetWeaver non aggiornati e individuato altri 1.800 domini in fase di targeting, inclusi ICS (sistemi di controllo industriale) situati in Stati Uniti, Regno Unito e Arabia Saudita. Altri tre gruppi APT, UNC5221, UNC5174 e CL-STA-0048, avrebbero partecipato a campagne simili, come riportato da EclecticIQ.

Questi attacchi indicano un chiaro interesse geopolitico e strategico nei confronti di infrastrutture industriali e sistemi critici occidentali, aggravando l’urgenza di mitigare la vulnerabilità CVE-2025-31324. SAP, parallelamente, ha rilasciato una patch anche per la vulnerabilità CVE-2025-42999, che veniva utilizzata in combinazione per ottenere un impatto maggiore.

Tecniche MITRE ATT&CK associate

Le TTP (Tactics, Techniques, and Procedures) osservate fanno riferimento a una lunga lista di tecniche MITRE ATT&CK, tra cui:

• T1055.003 – Inject into Process
• T1202 – Indirect Command Execution
• T1548.002 – Bypass User Account Control
• T1071.001 – Application Layer Protocol: Web Protocols
• T1190 – Exploit Public-Facing Application
• T1140 – Deobfuscate/Decode Files or Information

Schermata prelevata dalla piattaforma di intelligence di Recorded Future, partner strategico di Red Hot Cyber
Il vettore d’attacco è chiaro: esposizione pubblica, upload di codice malevolo, comandi remoti, iniezione in memoria e persistente presenza in sistemi compromessi. Una perfetta catena d’infezione in stile APT mista a dinamiche ransomware.

Il prezzo della trascuratezza

Questa campagna mostra, ancora una volta, come l’inerzia nella gestione dei software deprecati e il ritardo nell’applicazione delle patch di sicurezza rappresentino il terreno fertile per minacce sempre più sofisticate. Che si tratti di ransomware o cyber spionaggio, la porta d’ingresso è sempre la stessa: vulnerabilità note, ma ignorate.

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 Ransomware su SAP NetWeaver: sfruttato il CVE-2025-31324 per l’esecuzione remota di codice proviene da il blog della sicurezza informatica.

A terrarium is a little piece of the living world captured in a small enclosure you can pop on your desk or coffee table at home. If you want to keep it as alive as possible, though, you might like to implement some controls. That’s precisely what [yotitote] did with their smart terrarium build.

At the heart of the build is an ESP32 microcontroller. It’s armed with temperature and humidity sensors to detect the state of the atmosphere within the terrarium itself. However, it’s not just a mere monitor. It’s able to influence conditions by activating an ultrasonic fogger to increase humidity (which slightly impacts temperature in turn). There are also LED strips, which the ESP32 controls in order to try and aid the growth of plants within, and a small OLED screen to keep an eye on the vital signs.

It’s a simple project, but one that serves as a basic starting point that could be readily expanded as needed. It wouldn’t take much to adapt this further, such as by adding heating elements for precise temperature control, or more advanced lighting systems. These could be particularly useful if you intend your terrarium to support, perhaps, reptiles, in addition to tropical plant life.

Indeed, we’ve seen similar work before, using a Raspberry Pi to create a positive environment to keep geckos alive! Meanwhile, if you’re cooking up your own advanced terrarium at home, don’t hesitate to let us know.

hackaday.com/2025/05/15/smart-…

Vi segnalo questo podcast in cui se n'è parlato:

Lo trovate un po' su tutte le piattaforme, compreso su Antenna Pod.

In particolare, si spiega perché il testo legato alla raccolta firme che sta girando non è accurato.

open.spotify.com/episode/2QAdk…

#MatrimonioEgualitario #matrimonio #diritti #EQUITA #referendum #gaymarriage #samesexmarriage #Matrimoniogay #lgbtquia #lgbt #italia #repubblicadellebanane

Un nuovo referendum in vista

Closer · Episode

^{Un nuovo referendum in vista (Spotify)}

I ricercatori di sicurezza hanno individuato un nuovo metodo d’attacco in cui i cybercriminali sfruttano gli inviti di Google Calendar per veicolare malware. La tecnica impiegata si basa su un sistema di offuscamento avanzato, dove un solo carattere apparentemente innocuo cela codice malevolo pronto a colpire.

Questa tecnica sottolinea come gli attori delle minacce continuino a raffinare le proprie strategie, puntando su servizi considerati affidabili per bypassare le difese di sicurezza tradizionali. Nel marzo 2025, gli analisti di sicurezza di Aikido hanno individuato un pacchetto npm sospetto, denominato “os-info-checker-es6”. Sebbene apparisse come un modulo legittimo per la raccolta di informazioni sul sistema operativo, il pacchetto nascondeva codice potenzialmente dannoso.

Ciò che catturò la loro attenzione fu quello che sembrava essere solo un carattere di barra verticale (“|”) nel codice, ma che in realtà nascondeva qualcosa di molto più sinistro.

“Ciò che abbiamo scoperto è stato affascinante: quel singolo carattere non era in realtà un semplice simbolo di pipe, ma conteneva caratteri Unicode Private Use Area (PUA) invisibili”, hanno spiegato i ricercatori nella loro analisi. Questi caratteri PUA sono riservati nello standard Unicode alle applicazioni personalizzate e sono intrinsecamente non stampabili, il che li rende perfetti per nascondere codice dannoso.

Una volta decodificato, questo carattere apparentemente innocuo si trasformava in istruzioni codificate in base64 che alla fine si collegavano a Google Calendar per operazioni di comando e controllo. L’indagine ha rivelato che il malware era progettato per recuperare payload dannosi tramite un URL di invito di Google Calendar. L’invito del calendario conteneva stringhe codificate in base64 che, una volta decodificate, indirizzavano le vittime a un server controllato dall’aggressore.

Una volta che un bersaglio interagisce con questi inviti del calendario, può essere indirizzato a siti Web fraudolenti progettati per rubare credenziali o informazioni finanziarie. Gli aggressori non si sono fermati a un solo pacchetto. Tutti questi pacchetti hanno aggiunto il dannoso “os-info-checker-es6” come dipendenza, creando una superficie di attacco più ampia.

Come Proteggersi

Google ha riconosciuto la minaccia e consiglia agli utenti di abilitare l’impostazione “mittenti noti” in Google Calendar per difendersi da questo tipo di phishing. Gli esperti di sicurezza consigliano inoltre:

• Diffidate degli inviti inaspettati nel calendario, soprattutto quelli programmati per un futuro molto lontano.
• Verifica l’identità del mittente prima di accettare inviti o cliccare sui link.
• Mantenere il software aggiornato per correggere le vulnerabilità della sicurezza.
• Segnala gli inviti sospetti al calendario come spam tramite la funzione di segnalazione di Google Calendar.

Questo attacco dimostra come i criminali informatici continuino a trovare modi innovativi per diffondere payload dannosi, sfruttando piattaforme affidabili e sofisticate tecniche di offuscamento.

L'articolo Google Calendar Sotto Tiro! Un Solo Carattere Nasconde Un Attacco Malware Avanzato proviene da il blog della sicurezza informatica.

E' stata denominata “Petrolio dorato” l’operazione dei carabinieri che ha condotto ad arresti e perquisizioni - non solo in Italia - su mandato del gip di Bologna, consentendo di scoprire un sistema illegale di commercio di oli vegetali esausti utili per produrre biodiesel.

Nell’ambito delle attività, i Carabinieri del Gruppo per la tutela ambientale e la sicurezza energetica di Venezia, con il supporto di diversi reparti dell’Arma, sono stati coordinati dalla Procura della Repubblica – Direzione distrettuale antimafia e antiterrorismo – di Bologna.

L’inchiesta ha consentito di documentare l’operatività di un sodalizio che, attraverso società autorizzate alla raccolta di oli vegetali esausti, traeva ingiusti profitti dagli introiti derivanti dal trattamento e dalla rivendita di questo rifiuto pregiato, utilizzato per la produzione del biodiesel. Attualmente sono iscritte nel registro degli indagati 22 persone e 2 società, a vario titolo ritenute responsabili dei reati di associazione a delinquere, attività organizzate per il traffico illecito di rifiuti, favoreggiamento personale, falsità ideologica commessa dal privato in atto pubblico e abuso d’ufficio, in relazione ai fatti accertati in Emilia-Romagna, Veneto, Trentino Alto-Adige e Campania nel periodo 2021 – 2022.

L’indagine ha visto il coinvolgimento nelle varie fasi di Europol per quanto riguarda la cooperazione internazionale di polizia, visto che gli indagati risultano gestire attività economiche anche in Grecia e Spagna, nonché commerciare con Austria, Belgio, Ungheria, Bulgaria, Repubblica Slovacca, Malta e Libia.

Accogliendo le richieste del Pm, il Gip ha disposto la misura cautelare nei confronti di 11 indagati (5 dei quali agli arresti domiciliari, 3 con obbligo di dimora e 3 con divieto di esercitare imprese o uffici direttivi in società del settore della gestione dei rifiuti) e il sequestro preventivo dei compendi societari e delle strutture aziendali delle due società al centro delle investigazioni. Nel corso dell’operazione verranno anche eseguite 17 perquisizioni personali e locali e svolte ispezioni ambientali a impianti di raccolta, gestione e trattamento di oli vegetali esausti.

#Armadeicarabinieri #carabinierinoe #carabinieritase #biodiesel #olivegetaliesausti #ambiente #europol

@Ambiente

Un grave bug di sicurezza è stato risolto da Microsoft nel suo client di posta elettronica Outlook durante il Patch Tuesday di maggio 2025. Si tratta del CVE-2025-32705, che consente l’esecuzione di codice remoto (RCE) in Microsoft Outlook, causato da una debolezza di lettura fuori dai limiti.

Questa vulnerabilità evidenzia ancora una volta i rischi legati agli errori di memoria fuori limite in software ampiamente utilizzati come Microsoft Outlook.

L’anteprima della email di Outlook in questa CVE non consente l’esecuzione dell’exploit ma occorre una interazione attiva dell’utente. Microsoft ha attribuito ad Haifei Li di EXPMON il merito di aver scoperto la vulnerabilità e ha riconosciuto il ruolo svolto dalla più ampia comunità della sicurezza nella divulgazione coordinata delle vulnerabilità.

La vulnerabilità, classificata come High nello score CVSSv3, deriva da una gestione non corretta della memoria in Outlook. Un aggressore potrebbe sfruttare CVE-2025-32705 inviando un file appositamente creato all’utente bersaglio tramite e-mail o altri mezzi.

Quando l’utente apre il file dannoso in una versione interessata di Microsoft Outlook, può essere causato un errore di lettura fuori limite, che consente all’aggressore di eseguire codice arbitrario sul sistema locale. Ciò potrebbe portare alla compromissione totale del sistema, al furto di dati o all’ulteriore distribuzione di malware.

Gli aggiornamenti riguardano più edizioni di Microsoft Office LTSC 2021 e 2024, nonché Microsoft 365 Apps for Enterprise, sia per sistemi a 32 bit che a 64 bit. I prodotti interessati e i link per l’aggiornamento includono:

• Microsoft Office LTSC 2024 (32 bit e 64 bit).
• Microsoft Office LTSC 2021 (32 bit e 64 bit).
• App Microsoft 365 per le aziende (32 bit e 64 bit).

Tutti gli aggiornamenti sono classificati come importanti e risolvono vulnerabilità di esecuzione di codice remoto. Utenti e organizzazioni sono vivamente invitati ad applicare immediatamente queste patch per mitigare i potenziali rischi di sfruttamento. Microsoft ha riportato di alcune mitigazione all’impatto di questo exploit che sono:

• Applica immediatamente gli aggiornamenti di sicurezza: distribuisci le patch ufficiali dal portale degli aggiornamenti di sicurezza di Microsoft a tutte le installazioni di Outlook interessate.
• Prestare attenzione agli allegati e-mail: gli utenti dovrebbero evitare di aprire file inaspettati o sospetti, anche se provenienti da contatti noti.
• Mantenere la sicurezza degli endpoint: utilizzare soluzioni antivirus e di rilevamento degli endpoint aggiornate per identificare e bloccare potenziali tentativi di sfruttamento.
• Monitora gli avvisi di sicurezza: rimani informato sulle minacce emergenti e sugli aggiornamenti da parte di Microsoft e delle community sulla sicurezza informatica.

La combinazione di un vettore di attacco locale con il requisito di interazione dell’utente sottolinea l’importanza della consapevolezza dell’utente insieme alla gestione tempestiva delle patch per prevenire attacchi basati sull’esecuzione di codice arbitrario.

L'articolo Nuova RCE in Microsoft Outlook. La tua azienda compromessa con un semplice click proviene da il blog della sicurezza informatica.

Quando tecnologia e geopolitica si intersecano, il vincitore non è chi ha il chip più potente, ma chi riesce a riscrivere le regole in tempo e ad adattarsi più velocemente degli altri.

Nei prossimi due mesi Nvidia lancerà in Cina una versione ridotta del suo chip AI H20. Secondo quanto riferito da alcune fonti a Reuters, si prevede che il modello modificato sarà disponibile già a partire da luglio; i principali clienti cinesi, tra cui i fornitori di cloud computing, sono già stati avvisati.

La versione rivisitata di H20 rappresenta il tentativo di Nvidia di mantenere la propria posizione in una delle regioni più strategiche, nonostante la crescente pressione di Washington. Inizialmente, l’H20 era il più potente dei chip AI di Nvidia approvati per l’esportazione in Cina, ma il mese scorso le autorità statunitensi hanno inasprito le normative, richiedendo anche una licenza speciale per esportarlo. Ciò di fatto bloccò le forniture.

Successivamente, l’azienda ha rivisto i parametri tecnici della linea e ha sviluppato un piano per lanciare una nuova versione, con caratteristiche significativamente inferiori all’originale. Una fonte sostiene che il taglio principale sarà in termini di capacità di memoria. Si prevede inoltre che gli acquirenti stessi saranno in grado di adattare la configurazione modulare per ottimizzare le prestazioni in base alle proprie esigenze. La protezione non è un’opzione. È una necessità.

La posizione di Nvidia in Cina è difficile: nell’ultimo anno fiscale, il Paese ha garantito all’azienda un fatturato di 17 miliardi di dollari, pari al 13% del suo fatturato totale. Per sottolineare l’importanza dell’attenzione rivolta alla Cina, il CEO di Nvidia Jensen Huang ha visitato personalmente Pechino il mese scorso, subito dopo l’annuncio delle nuove restrizioni. Nei colloqui con i funzionari locali, ha sottolineato l’importanza della Cina come mercato chiave per l’azienda.

Dal 2022 sono in vigore restrizioni all’esportazione dei chip più avanzati di Nvidia verso la Cina, poiché le autorità statunitensi temono il loro utilizzo per scopi militari. In risposta a ciò, nell’ottobre 2023, Nvidia ha presentato l’H20, un processore appositamente adattato alle nuove regole. Tuttavia questa versione alla fine venne vietata.

Ciononostante, l’interesse per l’H2O in Cina è stato enorme. Aziende di primo livello come Tencent, Alibaba e ByteDance hanno iniziato ad acquistare chip per soddisfare la domanda di modelli di intelligenza artificiale a basso costo, popolari tra le startup come DeepSeek. Secondo Reuters, ad aprile Nvidia aveva ricevuto ordini per un valore di circa 18 miliardi di dollari solo attraverso la linea H20.

L'articolo Nvidia sfida le restrizioni USA: in arrivo il chip AI H20 ridotto per la Cina proviene da il blog della sicurezza informatica.

Has anybody heard of the ATW800 transputer workstation? The one that used a modified Atari ST motherboard as a glorified I/O controller for a T-series transputer? No, we hadn’t either, but transputer superfan [Axel Muhr] has created the ATW800/2, an Atari Transputer card, the way it was meant to be.

The transputer was a neat idea when it was conceived in the 1980s. It was designed specifically for parallel and scientific computing and featured an innovative architecture and dedicated high-speed serial chip-to-chip networking. However, the development of more modern buses and general-purpose CPUs quickly made it a footnote in history. During the same period, a neat transputer-based parallel processing computer was created, which leveraged the Atari ST purely for its I/O. This was the curious ATW800 transputer workstation. That flopped as well, but [Axel] was enough of a fan to take that concept and run with it. This time, rather than using the Atari as a dumb I/O controller, the card is explicitly designed for the Mega-ST expansion bus. A second variant of the ATW800/2 is designed for the Atari VME bus used by the STe and TT models—yes, VME on an Atari—it was a thing.

The card hosts an FPGA module, specifically the Tang 20k, that handles the graphics, giving the Atari access to higher resolutions, HDMI output, and GPU-like acceleration with the right code. The FPGA also contains a ‘synthetic’ transputer core, compatible with the Inmos T425, with 6Mb of RAM to play with. Additionally, the board contains an original Inmos C011 link adapter chip and a pair of size-1 TRAM slots to install two physical transputer cards. This allows a total of two transputers, each with its dedicated RAM, to be installed and networked with the synthetic transputer and the host system. The FPGA is configured to allow the host CPU and any of the transputers direct access to the video RAM, so with proper coding, the same display can mix 68K and parallel computing applications simultaneously. The original ATW800 couldn’t do that!

In addition to the transputer support and boosted graphics, the card also provides a ROM big enough to switch between multiple Atari TOS versions, USB loop-through ports to hook up to a lightning-ST board, and a MicroSD slot for extra local storage. What a project!

If you don’t know what the transputer is (or was), read our quick guide. Of course, forty-year-old silicon is rare and expensive nowadays, so if you fancy playing with some hardware, might we suggest using a Pi Pico instead?

Thanks to [krupkaj] for the tip!

hackaday.com/2025/05/14/fancy-…

If you talk about Starlink, you are usually talking about the satellites that orbit the Earth carrying data to and from ground stations. Why not? Space is cool. But there’s another important part of the system: the terminals themselves. Thanks to [DarkNavy], you don’t have to tear one open yourself to see what’s inside.

The terminal consists of two parts: the router and the antenna. In this context, antenna is somewhat of a misnomer, since it is really the RF transceiver and antenna all together. The post looks only at the “antenna” part of the terminal.

The unit is 100% full of printed circuit board with many RF chips and a custom ST Microelectronics Cortex A-53 quad-core CPU. There was a hack to gain root shell on the device. This led to SpaceX disabling the UART via a firmware update. However, there is still a way to break in.

[DarkNavy] wanted to look at the code, too, but there was no easy way to dump the flash memory. Desoldering the eMMC chip and reading it was, however, productive. The next step was to create a virtual environment to run the software under Qemu.

There were a few security questions raised. We wouldn’t call them red flags, per see, but maybe pink flags. For example, there are 41 trusted ssh keys placed in the device’s authorized_keys file. That seems like a lot for a production device on your network, but it isn’t any smoking gun.

We’ve watched the cat-and-mouse between Starlink and people hacking the receivers with interest.

hackaday.com/2025/05/14/inside…

Plywood is an interesting material: made up of many layers of thin wood plys, it can be built up into elegantly curved shapes. Do you need to limit it to just wood, though? [Zach of All Trades] has proved you do not, when he embedded a light guide, LEDs, microcontrollers and touch sensors into a quarter inch (about six millimeter) plywood layup in the video embedded below.

He’s using custom flexible PCBs, each hosting upto 3 LEDs and the low-cost PY32 microcontroller. The PY32 drives the RGB LEDs and handles capacitive touch sensing within the layup. In the video, he goes through his failed prototypes and what he learned: use epoxy, not wood glue, and while clear PET might be nice and bendy, acrylic is going to hold together better and cuts easier with a CO2 laser.

The wood was sourced from a couple of sources, but the easiest was apparently skateboard kits– skateboards are plywood, and there’s a market of people who DIY their decks. The vacuum bag setup [Zach] used looks like an essential tool to hold together the layers of wood and plastic as the epoxy cures. To make the bends work [Zach] needed a combination of soaking and steaming the maple, before putting it into a two-part 3D printed mold. The same mold bends the acrylic, which is pre-heated in an oven.

Ultimately it didn’t quite come together, but after some epoxy pour touch-up he’s left with a fun and decorative headphone stand. [Zach] has other projects in mind with this technique, and its got our brains percolating as well. Imagine incorporating strain gauges to drive the LEDs so you could see loading in real time, or a sound-reactive speaker housing. The sky’s the limit now that the technique is out there, and we look forward to see what people make of it.

The last time we heard from [Zach of All Trades] he was comparing ten cent micro-controllers; it looks like the PY32 came out on top. Oddly enough, this seems to be the first hack we have featuring it. If you’ve done something neat with ten cent micros (or more expensive ones) or know someone who did, don’t forget to let us know! We love tips. [Zach] sent in the tip about this video, and his reward is gratitude worth its weight in gold.

youtube.com/embed/VsFqkddhs3w?…

hackaday.com/2025/05/14/led-la…

If you want read-only memory today, you might be tempted to use flash memory or, if you want old-school, maybe an EPROM. But there was a time when that wasn’t feasible. [Igor Brichkov] shows us how to make a core rope memory using a set of ferrite cores and wire. This was famously used in early UNIVAC computers and the Apollo guidance computer. You can see how it works in the video below.

While rope memory superficially resembles core memory, the principle of operation is different. In core memory, the core’s magnetization is what determines any given bit. For rope memory, the cores are more like a sensing element. A set wire tries to flip the polarity of all cores. An inhibit signal stops that from happening except on the cores you want to read. Finally, a sense wire weaves through the cores and detects a blip when a core changes polarity. The second video, below, is an old MIT video that explains how it works (about 20 minutes in).

Why not just use core memory? Density. These memories could store much more data than a core memory system in the same volume. Of course, you could write to core memory, too, but that’s not always a requirement.

We’ve seen a resurgence of core rope projects lately. Regular old core is fun, too.

youtube.com/embed/cdeHAdR83b8?…

youtube.com/embed/ndvmFlg1WmE?…

hackaday.com/2025/05/14/your-o…

Treat dispensers are old hat around here, but what if kitty doesn’t need the extra calories — and actually needs to drop some pounds? [MethodicalMaker] decided to link the treat dispenser to a cat wheel, and reward kitty for healthy behaviors. The dispenser can be programmed to make the cat run long enough to burn the calories of its treat. Over time, kitty can be trained to run longer between treats to really melt off the pounds.

The wheel itself is an off the shelf model called “One Fast Cat”; apparently these are quite cheap second hand as most cats don’t really see the point in exercise. [MethodicalMaker] glued evenly-spaced magnets along the rim in order to track the rotation with a hall effect sensor. A microcontroller is watching said sensor, and is programmed to release the treats after counting off a set number of revolutions. Control over the running distance and manual treat extrusion is via web portal, but the networking code had difficulty on the Arduino R4 [MethodicalMaker] started with, so he switched to an ESP32 to get it working.

The real interesting part of this project is the physical design of the treat dispenser: it uses a double-auger setup to precisely control treat release. The first auger lives inside a hopper that holds a great many treats, but it tended to over-dispense so [MethodicalMaker] methodically made a second auger that sits beneath the hopper. The handful of treats extruded by the first auger are dispensed individually by the second auger, aided by a photosensor inside the exit chute to count treats. This also lets the machine signal when it needs refilled. For precise control, continuous servos are used to drive the augers. Aside from the electronics, everything is 3D printed; the STLs are on Printables, and the code is on GitHub.

If you don’t have a cat wheel, DIY is an option. If you don’t have a cat, we’ve also highlighted dog treat dispensers. If you don’t have either, check with your local animal shelter; we bet good money there are oodles ready to adopt in your town, and then you’ll have an excuse to enter one of your projects into our ongoing Pet Hacks Contest.

youtube.com/embed/nUOUaUAySG0?…

hackaday.com/2025/05/14/2025-p…

Negli Stati Uniti è emerso un nuovo potenziale rischio per la sicurezza delle infrastrutture energetiche.

Alcuni esperti del settore hanno scoperto dispositivi di comunicazione non documentati all’interno di inverter solari di produzione cinese, componenti fondamentali utilizzati per connettere pannelli solari e turbine eoliche alla rete elettrica. Questi dispositivi non erano elencati nella documentazione ufficiale e potrebbero rappresentare una minaccia se utilizzati per accedere da remoto ai sistemi energetici.

Gli inverter di potenza, prodotti principalmente in Cina, sono utilizzati in tutto il mondo per collegare pannelli solari e turbine eoliche alla rete elettrica. Sono presenti anche in batterie, pompe di calore e caricabatterie per veicoli elettrici.

Gli inverter, infatti, sono progettati per permettere aggiornamenti e manutenzione a distanza, ma negli Stati Uniti le aziende di servizi pubblici installano firewall per bloccare le comunicazioni dirette con server cinesi. Tuttavia, la presenza di apparecchiature di comunicazione non autorizzate – tra cui radio cellulari – aggira potenzialmente questi controlli. Negli ultimi nove mesi, componenti simili sono stati rinvenuti anche in batterie e altri dispositivi provenienti da diversi fornitori cinesi.

Il timore degli esperti è che questi sistemi possano essere utilizzati per interferire con la rete elettrica nazionale, causando malfunzionamenti o blackout mirati. Un precedente caso nel novembre 2024, in cui alcuni inverter sono stati disattivati da remoto dalla Cina, ha rafforzato i sospetti e spinto le autorità statunitensi a intensificare le ispezioni su tutte le tecnologie connesse alla rete.

A livello internazionale, alcuni paesi stanno già adottando misure concrete. La Lituania, ad esempio, ha introdotto una nuova legislazione che vieta l’accesso remoto ai produttori cinesi di inverter nei siti con capacità superiore a 100 kilowatt. La norma si applica alle nuove installazioni dal 1° maggio 2025, e richiede agli impianti esistenti di adeguarsi entro maggio 2026, rafforzando così la protezione della propria infrastruttura energetica.

Questa vicenda sottolinea quanto sia cruciale garantire la sicurezza dei dispositivi collegati alla rete, soprattutto in un contesto di transizione energetica globale sempre più dipendente dalla tecnologia digitale.

La trasparenza nella produzione e nella documentazione tecnica dei componenti elettronici sarà fondamentale per prevenire rischi futuri e tutelare la sovranità tecnologica delle nazioni.

L'articolo Infrastrutture Energetiche Nel Mirino! Gli Inverter Cinesi Sono Controllati Da Remoto proviene da il blog della sicurezza informatica.

Earlier this month we covered the brewing controversy over libogc, the community-developed C library that functions as the backbone for GameCube and Wii homebrew software. Questions about how much of the library was based on leaked information from Nintendo had been circulating for decades, but the more recent accusations that libogc included code from other open source projects without proper attribution brought the debate to a head — ultimately leading Wii Homebrew Channel developer Hector Martin to archive the popular project and use its README as a central point to collect evidence against libogc and its developers.

At the time, most of the claims had to do with code being taken from the Real-Time Executive for Multiprocessor Systems (RTEMS) project. Martin and others in the community had performed their own investigations, and found some striking similarities between the two codebases. A developer familiar with both projects went so far as to say that as much as half the code in libogc was actually lifted from RTEMS and obfuscated so as to appear as original work.

While some of these claims included compelling evidence, they were still nothing more than accusations. For their part, the libogc team denied any wrongdoing. Contributors to the project explained that any resemblance between libogc code and that of either leaked Nintendo libraries or other open source projects was merely superficial, and the unavoidable result of developing for a constrained system such as a game console.

But that all changed on May 6th, when the RTEMS team released an official statement on the subject. It turns out that they had been following the situation for some time, and had conducted their own audit of the libogc code. Their determination was that not only had RTEMS code been used without attribution, but that it appeared at least some code had also been copied verbatim from the Linux kernel — making the license dispute (and its solution) far more complex.

Permissive vs Restrictive

At first glance, this all might seem like something of a non-issue. After all, libogc, RTEMS, and the Linux kernel are all open source projects. Surely, the point of releasing these projects as open source in the first place was to facilitate and even encourage the sharing of source code. In a sense, this could be looked at as the system working as intended.

Indeed, it’s not the reuse of code that’s really the issue here. The problem stems from the licenses by which the respective projects have made their source code available, and more specifically, how well those licenses integrate with each other.

When the complaint was that libogc was using large swaths of code from RTEMS, the path towards compliance was simple as latter project was released under what’s known as a permissive license, namely, the 2-Clause BSD License. As the name implies, permissive licenses such as this give the user broad rights on how they can reuse the code

For example, one could take BSD-licensed code, merge it as-is into a closed source project, and sell the resulting software for profit without violating the license. All the original project asks in return is that you give proper attribution. In this case, that means acknowledging you used code from said project in the documentation, and including a copy of the license.

Returning to libogc, the issue at hand could be resolved with a single commit to the project’s GitHub repository. A simple notice that the project used code from RTEMS and a copy of the BSD license is all it would take to satisfy the requirements. That the libogc developers will not make even such a simple concession in the face of overwhelming evidence that they did indeed reuse code is frankly indefensible; a sentiment expressed in the statement from the RTEMS developers:

RTEMS is open source and this means RTEMS can be copied and used as long as the license conditions are met and copyright is maintained. We are at a loss why there has been removal of license details and copyright and a general disregard to apply appropriate attributions. As a result the RTEMS license and copyright holders reserve their rights in relation to the copying of RTEMS code.

That being said, the revelation that libogc would appear to include code from the Linux kernel complicates matters considerably. Unlike RTEMS, Linux is licensed under the GPL v2 — a license that is not only far more restrictive, but viral in nature.

The Case for Kernel Code

It’s that viral aspect of the license that promises to give libogc the most trouble. If they did indeed use code from the Linux kernel, that would mean there are only two solutions. Either the offending code must be removed, or the entire project will need to be re-licensed under the GPL v2.

For a codebase as old as libogc, changing the license would be a massive undertaking, as every person who’s added code to the project would have to agree to have their individual contribution re-licensed. The libogc repository lists dozens of contributors, and that’s only since project was added to GitHub. As there appears to be no CREDITS file that lists the contributions before the advent of Git, there may be no way to know at this point how many contributors there actually are and what they added.

So the question of whether or not libogc uses Linux code is going to be critical to determining how the project moves forward. The RTEMS statement doesn’t go into great detail about this claim, simply stating that the “spinlock implementation is copied directly from Linux circa 2.4 or 2.6 release series.” Sure enough, when comparing the file spinlock.h file from the latest version of libogc to linux-2.6.0/include/asm-ppc/spinlock.h there are indeed functions which are nearly identical:

That said, this may not be as damning as it seems. To play Devil’s advocate, one could argue that the terse nature of assembly code means that a certain level of similarity is unavoidable between the two implementations. Of course, convention can only get you so far. It’s one thing to independently arrive at the same assembly code, but this explanation becomes harder to believe when you consider the identical variable names and comments.

What’s Next?

As of this writing, the libogc project has not made an official statement on the situation. We reached out to maintainer Dave [WinterMute] Murphy before going to press with this article, but he declined to comment, saying that he first needed to confer with the original developer of the library, Michael [shagkur] Wiedenbauer.

At the same time, our contacts within the RTEMS project have indicated they believe they have sufficient evidence to have libogc removed from GitHub if necessary. However, they’re understandingly hesitant to disrupt the Wii homebrew community over an issue that could ultimately be resolved with a simple discussion. While the potential use of Linux code does add a considerable wrinkle to the overall situation, if the libogc project would at least acknowledge the use of RTEMS code and properly attribute it after all these years, it would at least be a step in the right direction.

We’ll continue to keep an eye on the situation, and bring you updates as we have them. In the meantime, we think the final line of the RTEMS statement nicely summarizes the biggest takeaway from this whole mess:

Our goal now is to provide education on how the behavior engaged in by the devkitPro/libOGC project is a very good example of what not to do.

hackaday.com/2025/05/14/rtems-…

When [Kasyan] was six years old, he saw a RADUGA computer, a Russian unit from the 1990s, and it sparked his imagination. He has one now that is a little beat up, but we feel like he sees it through his six-year-old eyes as a shiny new computer. The computer, which you can see in the video below, was a clone of the Spectrum 48K.

The box is somewhat klunky-looking, and inside is also a bit strange. The power supply is a — for the time — state-of-the-art switching power supply. Since it wasn’t in good shape, he decided to replace it with a more modern supply.

The main board was also not in good shape. A Zilog CPU is on a large PCB with suspicious-looking capacitors. The mechanical keyboard is nothing more than a array of buttons, and wouldn’t excite today’s mechanical key enthusiast.

The computer isn’t working yet. [Kasyan] is looking for someone who has the exact schematic, although he’s found a similar one and identified at least some of the problems on the board.

The USSR did a lot of work with early computing, but we don’t hear as much about it. That’s surprising, as they had a very active home computer scene.

youtube.com/embed/HxvSitPXkg4?…

hackaday.com/2025/05/14/raduga…

I ricercatori hanno individuato una nuova campagna malware che sfrutta gli attacchi ClickFix. Ora gli aggressori prendono di mira anche gli utenti Linux.

Gli attacchi ClickFix sono una forma di ingegneria sociale. Di recente si sono diffuse diverse varianti di tali attacchi. In genere, le vittime vengono attirate su siti truffaldini e indotte con l’inganno a eseguire comandi PowerShell dannosi, infettando di fatto manualmente il loro sistema con un malware. Ad esempio, gli aggressori giustificano la necessità di eseguire determinati comandi risolvendo problemi di visualizzazione del contenuto nel browser oppure chiedendo all’utente di risolvere un CAPTCHA falso.

In genere, tali attacchi prendono di mira i sistemi Windows e inducono la vittima a eseguire uno script di PowerShell, che provoca l’infezione da malware. Tuttavia, in una nuova campagna individuata dai ricercatori di Hunt.io, gli aggressori hanno adattato per la prima volta questa tecnica ai sistemi Linux.

La campagna, che gli esperti attribuiscono al gruppo di hacker pakistano APT36 (noto anche come Transparent Tribe), utilizza un falso sito web del Ministero della Difesa indiano contenente un collegamento a un presunto comunicato stampa ufficiale. Quando i visitatori arrivano su questo sito, la piattaforma rileva il loro sistema operativo e lancia un attacco appropriato.

In questo modo, agli utenti Windows viene mostrata una pagina a schermo intero con un avviso sui diritti limitati per l’utilizzo del contenuto. Facendo clic sul pulsante Continua viene avviato JavaScript che copia il comando dannoso MSHTA negli appunti della vittima, invitandola a incollarlo ed eseguirlo in un terminale Windows.

Questo avvia un loader basato su .NET che si connette all’indirizzo dell’attaccante e l’utente visualizza un file PDF che dovrebbe indurlo in un falso senso di sicurezza e far sembrare la situazione più plausibile.

Se il visitatore utilizza Linux, viene reindirizzato a una pagina con un CAPTCHA falso, dove, premendo il pulsante “Non sono un robot“, un comando shell viene copiato negli appunti. Alla vittima viene quindi chiesto di premere ALT+F2, incollare il comando e premere Invio per eseguirlo.

Il comando avvia il payload mapeal.sh sul sistema dell’utente, il quale, secondo i ricercatori, non esegue ancora alcuna azione dannosa, limitandosi a ricevere in background un’immagine JPEG dal server degli aggressori (trade4wealth[.]in).

Gli esperti ritengono che i membri di APT36 stiano attualmente semplicemente testando l’efficacia di tali attacchi su Linux, poiché è sufficiente sostituire l’immagine con uno script shell per installare il malware ed eseguire altre azioni dannose.

L’adattamento di ClickFix a Linux è un’ulteriore prova dell’efficacia di tali attacchi. Le varianti di ClickFix sono ora disponibili per tutti e tre i principali sistemi operativi desktop. La versione di ClickFix per macOS è stata individuata già nell’ottobre dell’anno scorso.

L'articolo ClickFix Sbarca su Linux! Il Malware ora si installa anche per gli utenti del Pinguino proviene da il blog della sicurezza informatica.