SAP risolve una vulnerabilità critica dopo averne scoperto lo sfruttamento

La società di software tedesca SAP ha finalmente rivelato e corretto una vulnerabilità altamente critica nel server di sviluppo NetWeaver Visual Composer, dopo averne riscontrato lo sfruttamento in natura.

NetWeaver Visual Composer è lo strumento di modellazione basato sul Web di SAP che consente agli esperti di processi aziendali e agli sviluppatori di creare componenti di applicazioni aziendali senza dover scrivere codice manuale.

La vulnerabilità, identificata come CVE-2025-31324, è una vulnerabilità di caricamento di file non autenticati nel componente Metadata Uploader di SAP NetWeaver Visual Composer Framework versione 7.50.

Se sfruttata, la vulnerabilità consente a un aggressore non autenticato di caricare file binari eseguibili potenzialmente dannosi, in grado di danneggiare gravemente il sistema host.

"Ciò potrebbe influire in modo significativo sulla riservatezza, l'integrità e la disponibilità del sistema preso di mira", si legge nella pagina CVE.org relativa a CVE-2025-31324.

Alla vulnerabilità è stato assegnato il punteggio di gravità più alto da SAP: 10.0 (CVSS v3.1).

Il fornitore di software tedesco ha inoltre rilasciato una correzione, pubblicata in un aggiornamento di sicurezza di emergenza accessibile solo ai clienti SAP .

Si invitano i clienti ad applicare le nuove versioni il prima possibile.

Prova di sfruttamento

La vulnerabilità è stata rilevata da ReliaQuest nell'aprile 2025 durante l'indagine su diversi incidenti dei clienti che interessavano la piattaforma di integrazione tecnologica SAP NetWeaver, che comportavano caricamenti di file non autorizzati e l'esecuzione di file dannosi.

In un articolo del 22 aprile in cui venivano condivisi i risultati della propria indagine, ReliaQuest ha affermato di aver inizialmente scoperto che gli aggressori avevano caricato "webshell JSP" in directory accessibili al pubblico, una mossa che ricorda una vulnerabilità di inclusione di file remoti (RFI).

Diversi sistemi interessati eseguivano già l'ultimo service pack SAP e avevano applicato le patch rese disponibili nell'aggiornamento mensile regolare di SAP, rilasciato l'8 aprile. Ciò indicava che i proprietari dei sistemi interessati erano stati presi di mira da un exploit zero-day.

Tuttavia, SAP ha successivamente confermato che si tratta di una vulnerabilità di caricamento file senza restrizioni, che consente agli aggressori di caricare file dannosi direttamente sul sistema senza autorizzazione", si legge nel rapporto di ReliaQuest.

ReliaQuest ha aggiunto che lo sfruttamento è probabilmente legato a una vulnerabilità precedentemente divulgata come CVE-2017-9844 o a un problema di inclusione di file remoti (RFI) non segnalato. Inoltre, gli aggressori hanno utilizzato strumenti come Brute Ratel e Heaven's Gate per l'esecuzione e l'elusione.

Dopo essere stata contattata da ReliaQuest, SAP, che è essa stessa una CVE Numbering Authority (CNA), ha segnalato pubblicamente la vulnerabilità il 24 aprile e ha rilasciato una correzione.

Secondo ReliaQuest, le soluzioni SAP rappresentano probabilmente un obiettivo allettante per gli autori delle minacce per due motivi principali.

"In primo luogo, sono spesso utilizzati da enti governativi, il che significa che una compromissione efficace delle vulnerabilità SAP faciliterebbe probabilmente l'accesso alle reti e alle informazioni governative. In secondo luogo, poiché le soluzioni SAP sono spesso implementate on-premise, le misure di sicurezza per questi sistemi sono lasciate agli utenti; aggiornamenti e patch non applicati tempestivamente esporrebbero probabilmente questi sistemi a un rischio maggiore di compromissione", hanno scritto i ricercatori di ReliaQuest.

https://www.infosecurity-magazine.com/news/sap-fixes-critical-vulnerability/

Microsoft avverte: il ransomware sfrutta gli ambienti cloud con nuove tecniche

Microsoft ha emesso un avviso riguardante sofisticati attacchi ransomware che prenderanno di mira gli ambienti cloud ibridi nel primo trimestre del 2025.

Questi attacchi sfruttano le vulnerabilità all'intersezione tra infrastrutture on-premise e servizi cloud, mettendo a dura prova le organizzazioni con configurazioni ibride.

In una svolta significativa, l'organizzazione statale nordcoreana Moonstone Sleet ha distribuito il ransomware Qilin in attacchi mirati.

Questa segna la loro prima operazione come affiliati al ransomware-as-a-service anziché utilizzare malware personalizzato, il che indica un'evoluzione tattica per aumentare l'efficienza mantenendo al contempo una plausibile negabilità.

I ricercatori di Microsoft Threat Intelligence hanno identificato l'autore della minaccia Storm-0501 che sfrutta capacità avanzate per lo spostamento laterale dai sistemi locali all'infrastruttura cloud.

La loro analisi ha scoperto tecniche che prendono di mira dispositivi non gestiti e sfruttano account ibridi non sicuri per accedere a risorse critiche, eliminare backup e distribuire ransomware.

Una fuga di notizie di febbraio nelle chat di gruppo del ransomware Black Basta ha svelato i loro metodi tecnici, tra cui lo sfruttamento delle vulnerabilità di Citrix, Jenkins e VPN.

Altri gruppi attivi erano Lace Tempest e Storm-1175; quest'ultimo sfruttò le nuove vulnerabilità di SimpleHelp subito dopo la divulgazione.

L'ingegneria sociale rimane prevalente, con gli autori che avviano i contatti tramite false chiamate di supporto IT prima di implementare strumenti di accesso remoto. Storm-1674 è stato osservato utilizzando false chiamate IT tramite Microsoft Teams, che hanno portato all'utilizzo di Quick Assist e PowerShell.

Tecniche di sfruttamento del cloud ibrido

La metodologia di compromissione del cloud di Storm-0501 inizia con uno spostamento laterale dai sistemi locali compromessi attraverso configurazioni di identità ibride non sicure.

Dopo aver ottenuto l'accesso iniziale, gli aggressori prendono di mira gli account con permessi eccessivi in ​​tutti gli ambienti. Questo approccio consente loro di passare agevolmente dall'infrastruttura tradizionale alle risorse cloud.

La catena di attacco in genere include richieste HTTP specifiche che prendono di mira i file di configurazione:

Questa tecnica di attraversamento del percorso espone i token di autenticazione e le impostazioni di federazione, consentendo agli aggressori di aggirare l'autenticazione a più fattori sfruttando le relazioni di fiducia tra i sistemi di identità.

Microsoft consiglia di implementare l'igiene delle credenziali, di applicare i principi dei privilegi minimi e di adottare architetture Zero Trust per proteggere gli ambienti ibridi.

Le organizzazioni dovrebbero inoltre monitorare attentamente i modelli di autenticazione insoliti che potrebbero indicare la compromissione dei sistemi di identità ibridi.

https://cybersecuritynews.com/microsoft-warns-of-ransomware-exploiting-cloud-environments/

La tua tecnologia di difesa dei confini e dei margini è vulnerabile? Cosa puoi fare al riguardo?

A seguito di una serie di recenti eventi di alto profilo, le tecnologie di difesa perimetrale e di confine, come firewall, gateway VPN e sistemi di prevenzione delle intrusioni, hanno ricevuto molta attenzione sia dai ricercatori sulla sicurezza che dagli autori delle minacce.

Tra queste, una campagna di sfruttamento di massa contro i firewall Fortinet, l'interruzione di CrowdStrike dell'estate 2024 e l'uso di una vulnerabilità per disabilitare i firewall di Palo Alto, tra le altre, ognuna delle quali ha causato diversi livelli di interruzione. Le problematiche sono particolarmente preoccupanti perché colpiscono specificamente i sistemi utilizzati per proteggere le nostre reti dalle minacce.

Alcuni report recenti hanno rivelato che gli attacchi zero-day contro tali dispositivi sono rimasti attivi e inosservati per mesi prima di essere scoperti, con vulnerabilità rimaste inalterate anche dopo l'emissione delle patch. Pertanto, la necessità di un approccio più proattivo alla protezione dei dispositivi è più urgente che mai. Questo perché, se i criminali informatici riuscissero a mettere piede in queste tecnologie, potrebbero potenzialmente controllare l'intera rete dietro il dispositivo, nonché il flusso di traffico in uscita.

È tempo di essere proattivi

Ma come affrontare questi problemi? Dal punto di vista di chi si occupa di sicurezza, è importante comprendere che i dispositivi di sicurezza edge e border non sono intrinsecamente sicuri. Certo, svolgono un ruolo fondamentale e lo fanno da molti anni – ad esempio, i firewall sono utilizzati dal 75% delle aziende del Regno Unito – ma per garantire che rimangano idonei allo scopo, richiedono un approccio basato sulle best practice e aggiornamenti regolari.

A livello pratico, ciò può includere il controllo delle configurazioni dei dispositivi, la revisione e la modifica delle impostazioni predefinite di registrazione e avviso e la limitazione dell'esposizione delle interfacce di gestione e dei servizi sensibili alla rete Internet pubblica. Le organizzazioni dovrebbero inoltre pianificare i possibili scenari , inclusi quelli che presuppongono la compromissione dei dispositivi.

Si considerino, ad esempio, i rischi associati a dispositivi non configurati correttamente, che possono esporre involontariamente interfacce e protocolli di gestione a Internet e renderli visibili a chiunque desideri trovarli. Questo nonostante il fatto che, a meno che il servizio fornito non sia destinato al pubblico generale, relativamente poche tecnologie di difesa edge e border debbano essere completamente accessibili da Internet. L'accesso dovrebbe invece essere limitato su base zero trust/ needs - must.

Portando questo concetto ancora più in là, è anche una buona idea limitare le posizioni da cui è possibile accedere a un dispositivo di difesa perimetrale o di confine a posizioni prevedibili. In questa situazione, i team di sicurezza possono applicare più facilmente regole, autorizzazioni e controlli di accesso che attivano avvisi in caso di tentativi di accesso anomali. Un esempio di questo approccio è quando l'accesso al dispositivo viene instradato tramite una VPN o un jump box, il che garantisce che la posizione sia sempre prevedibile e sotto controllo. Per le organizzazioni in cui l'uso di una VPN non è un'opzione, l'accesso può essere limitato a posizioni fisiche specifiche per mantenere questo prezioso livello di controllo.

Essere proattivi in ​​materia di sicurezza dei dispositivi di difesa edge e border si basa anche su processi come i penetration test, che possono aiutare a identificare configurazioni errate e casi di accesso diretto a Internet indesiderato. Un approccio olistico che testa il maggior numero possibile di dispositivi esterni può garantire ai team di sicurezza un quadro completo di eventuali vulnerabilità legate all'accesso. Grazie a queste informazioni, è molto più facile ed efficace migliorare la sicurezza e garantire che la porta non venga inavvertitamente lasciata aperta.

Non tornare al valore predefinito

Un altro aspetto della difesa edge e border spesso trascurato è quando le organizzazioni si affidano alle impostazioni di log predefinite sui propri dispositivi, o dimenticano di aggiornarle, spesso inadeguate per tracciare e analizzare potenziali exploit di minacce. Inoltre, molte organizzazioni conservano i log dei dispositivi e i dati di avviso solo per poche settimane, un approccio che, in caso di incidente di sicurezza, rende più difficile condurre le necessarie analisi forensi e comprendere l'origine dell'attacco. Ciò è particolarmente vero nel caso di attacchi zero-day, in cui gli exploit possono rimanere attivi e non rilevati per settimane e persino mesi. Per rimanere proattive, le organizzazioni dovrebbero condurre analisi di log regolari (e idealmente in tempo reale) per identificare comportamenti anomali sulla rete e rilevare potenziali minacce.

Il messaggio generale dietro queste best practice è che questi dispositivi di sicurezza critici non sono semplicemente plug-and-play. Sebbene siano sempre più sofisticati e offrano diverse funzionalità di automazione, rimangono vulnerabili agli attacchi. Gli aggressori si affidano alle organizzazioni per dimenticare, ignorare o de-priorizzare la configurazione, la manutenzione e gli aggiornamenti. Prenderanno di mira le organizzazioni con difese deboli, punti di ingresso vulnerabili e che sono esposte a rischi da exploit zero-day e altri problemi di sicurezza specifici dei fornitori. Al contrario, i team di sicurezza in grado di colmare ogni falla di sicurezza relativa ai dispositivi possono garantire che le loro difese edge e border siano robuste e all'altezza della sfida di mantenere le reti sicure.

https://cybersecurity-magazine.com/is-your-edge-and-border-defence-tech-vulnerable-and-what-to-do-about-it/

Gcore Super Transit offre protezione e accelerazione DDoS avanzate per una sicurezza e una velocità aziendali superiori

Gcore, fornitore globale di soluzioni di sicurezza, cloud, rete e intelligenza artificiale edge, ha lanciato Super Transit, una funzionalità di protezione e accelerazione DDoS all'avanguardia, progettata per salvaguardare l'infrastruttura aziendale garantendo al contempo una connettività ultraveloce.

Questo avviene in un momento in cui le organizzazioni si trovano ad affrontare un aumento del 56% anno su anno di attacchi DDoS complessi e di grande volume che interrompono le operazioni, aumentano la latenza e compromettono la sicurezza della rete. Le soluzioni tradizionali spesso richiedono integrazioni costose e complesse, ma Super Transit viene fornito come parte della Gcore DDoS Protection Suite. Utilizzando la rete globale Gcore di oltre 180 punti di presenza (PoP), il traffico viene automaticamente instradato attraverso il backbone Gcore Anycast e il traffico dannoso viene separato in modo intelligente dal traffico legittimo in tempo reale. Questo rilevamento proattivo, filtraggio e mitigazione degli attacchi DDoS garantisce un'esperienza utente ininterrotta, quindi anche durante un attacco, gli utenti non vengono colpiti e continuano a sperimentare una connettività stabile, sicura e ad alta velocità.

Gcore Super Transit, ora disponibile per tutti i clienti, ottimizza le prestazioni e la sicurezza attraverso i seguenti fattori distintivi chiave:

1. Mitigazione delle minacce DDoS in tempo reale: rileva e blocca il traffico dannoso in tempo reale al PoP Gcore più vicino, prima che possa raggiungere le reti degli utenti, riducendo al minimo l'impatto sulle prestazioni.

2. Protezione su scala globale: difesa completa contro attacchi DDoS di qualsiasi dimensione, supportata da una capacità di rete di filtraggio totale superiore a 200 Tbps.

3. Prestazioni costanti: il traffico viene filtrato ai margini, mentre il traffico legittimo viene instradato tramite il percorso ottimale all'interno del backbone ad alte prestazioni di Gcore, eliminando i reindirizzamenti non necessari verso centri di scrubbing esterni e riducendo la latenza.

4. Protezione conveniente: ottimizza la spesa per la sicurezza con opzioni di distribuzione flessibili e integrate che bilanciano prestazioni e convenienza.

Andrey Slastenov, Responsabile della Sicurezza di Gcore, ha commentato: "Si tratta di un lancio di enorme importanza per diversi motivi. In primo luogo, Super Transit consente un accesso rapido e globale ai nostri servizi di protezione DDoS, con analisi e filtraggio intelligenti dei dati in tempo reale, garantendo che i dati legittimi vengano indirizzati ai server in modo efficiente. Queste sono funzionalità cruciali, poiché la protezione DDoS avanzata per i servizi in tempo reale riduce la latenza e le interruzioni che incidono significativamente sull'esperienza utente e sul successo aziendale."

https://hackread.com/gcore-super-transit-brings-advanced-ddos-protection-and-acceleration-for-superior-enterprise-security-and-speed/

La Commissione europea punta alla crittografia end-to-end e propone che Europol diventi un FBI dell'UE

La Commissione europea ha annunciato martedì la sua intenzione di unirsi al dibattito in corso sull'accesso legale ai dati e sulla crittografia end-to-end, svelando al contempo una nuova strategia di sicurezza interna volta ad affrontare le minacce in corso.

ProtectEU, questo il nome della strategia, descrive gli ambiti generali che l'esecutivo dell'Unione vorrebbe affrontare nei prossimi anni, sebbene come strategia non offra proposte politiche dettagliate.

In quello che la Commissione ha definito “un mutato contesto di sicurezza e un panorama geopolitico in evoluzione”, ha affermato che l’Europa deve “rivedere il suo approccio alla sicurezza interna”.

Tra i suoi obiettivi c’è quello di istituire Europol come “un’agenzia di polizia veramente operativa per rafforzare il supporto agli Stati membri”, qualcosa di potenzialmente paragonabile all’FBI statunitense, con un ruolo “nell’indagine di casi transfrontalieri, su larga scala e complessi che rappresentano una seria minaccia per la sicurezza interna dell’Unione”.

Parallelamente al nuovo Europol, la Commissione ha affermato che avrebbe creato delle tabelle di marcia sia per quanto riguarda “l’accesso legittimo ed efficace ai dati per le forze dell’ordine” sia per quanto riguarda la crittografia.

L'obiettivo è "identificare e valutare soluzioni tecnologiche che consentano alle autorità di polizia di accedere ai dati criptati in modo lecito, salvaguardando la sicurezza informatica e i diritti fondamentali", ha affermato la Commissione. L'identificazione di tali soluzioni è stata oggetto di molte controversie quando è stata tentata altrove.

La strategia definisce inoltre obiettivi e azioni che riecheggiano valutazioni incontestabili sulle carenze dell'Unione europea, tra cui la mancanza di consapevolezza della situazione e di analisi delle minacce a livello esecutivo.

Il problema per l'Unione Europea è che la difesa, la sicurezza e l'intelligence sono sempre state questioni sovrane di ogni Stato membro e i governi di quegli Stati membri hanno poca voglia di donare le proprie capacità nazionali all'Unione.

ProtectEU invita la Commissione a migliorare la condivisione di intelligence attraverso la capacità unica di analisi dell'intelligence (SIAC) dell'UE, una struttura di fatto per la condivisione volontaria di intelligence da parte dei singoli Stati membri, dotata di una propria capacità di analisi completamente open source.

Un rapporto scritto per la Commissione Europea da Sauli Niinistö, l’ex Presidente della Finlandia, ha avvertito l’anno scorso che l’accordo esistente era “limitato da limiti istituzionali, legali e politici” e ha portato all’incapacità di affrontare in modo ottimale l’invasione russa dell’Ucraina.

Come ha osservato, il successo di qualsiasi cambiamento "dipende in ultima analisi dalla volontà politica, dall'impegno e dagli sforzi concertati degli Stati membri. A questo proposito, il rischio e, ahimè, troppo spesso la realtà del breve termine e degli interessi divergenti, delle priorità di sicurezza e delle opinioni politiche che ostacolano azioni e investimenti congiunti rimane reale, in particolare considerando il panorama sociale e politico polarizzato in tutta Europa".

La strategia annunciava inoltre che la Commissione avrebbe introdotto un nuovo Cybersecurity Act, pur riconoscendo che gli Stati membri non avevano ancora pienamente recepito le leggi vigenti in materia di sicurezza informatica nella propria legislazione nazionale.

"La sicurezza è una precondizione per la nostra democrazia e le nostre economie prospere. L'UE deve essere coraggiosa e proattiva nell'affrontare le complesse sfide alla sicurezza che ci troviamo ad affrontare", ha affermato Henna Virkkunen, vicepresidente esecutivo della Commissione per la sovranità tecnologica, la sicurezza e la democrazia.

"Renderemo l'UE più sicura rafforzando le nostre capacità, sfruttando la tecnologia, potenziando la sicurezza informatica e combattendo le minacce alla sicurezza in modo deciso. Questa strategia, insieme alla Preparedness Union [Strategia], al Libro bianco sulla difesa e al prossimo Democracy Shield, definisce la visione per un'Unione sicura, protetta e resiliente".

https://therecord.media/european-commission-takes-aim-encryp

Ivanti rilascia aggiornamenti di sicurezza per la vulnerabilità dei gateway Connect Secure, Policy Secure e ZTA (CVE-2025-22457). Hacker Stato-Nazione cinesi

Ivanti ha rilasciato aggiornamenti di sicurezza per risolvere le vulnerabilità (CVE-2025-22457) in Ivanti Connect Secure, Policy Secure e ZTA Gateway. Un cyber threat actor potrebbe sfruttare CVE-2025-22457 per prendere il controllo di un sistema interessato.

La CISA ha aggiunto CVE-2025-22457 al suo catalogo delle vulnerabilità note sfruttate. La CISA (Cybersecurity and Infrastructure Security Agency) ha recentemente emesso avvisi riguardanti una vulnerabilità nei prodotti firewall di Ivanti che sta essendo attivamente sfruttata da hacker sospettati di essere di origine cinese. Ecco alcuni punti chiave sulla situazione: Dettagli della vulnerabilità: Il bug colpisce alcune versioni di Ivanti Connect Secure ed è stato collegato a un gruppo di spionaggio informatico con legami con la Cina. 

Nel suo avviso, la CISA ha esortato le organizzazioni che utilizzano questi prodotti Ivanti a intraprendere azioni immediate, tra cui la disconnessione dei dispositivi interessati per mitigare i rischi. 

Minaccia in corso: Questa non è la prima volta che la CISA avvisa le organizzazioni sugli hacker sostenuti dallo stato che sfruttano le vulnerabilità di Ivanti. Dal 2020, ci sono stati numerosi avvisi riguardanti minacce simili. 

Impatto: Lo sfruttamento di questa vulnerabilità potrebbe portare a gravi violazioni della sicurezza, rendendo fondamentale per le organizzazioni rimanere vigili e applicare gli aggiornamenti o le patch necessari. 

Dettagli sulle azioni di difesa:

Per tutte le istanze di Ivanti Connect Secure che non sono state aggiornate entro il 28 febbraio 2025 all'ultima patch di Ivanti (22.7R2.6) e per tutte le istanze di Pulse Connect Secure (EoS), Policy Secure e ZTA Gateway, CISA esorta utenti e amministratori a implementare le seguenti azioni: Condurre azioni di caccia alle minacce: Esegui uno strumento di controllo dell'integrità esterno (ICT). Per ulteriori indicazioni, consulta le istruzioni di Ivanti.

Eseguire azioni di ricerca delle minacce su tutti i sistemi connessi al dispositivo Ivanti interessato o che si sono connessi di recente.

Se le azioni di caccia alle minacce non determinano alcun compromesso: Per il massimo livello di sicurezza, esegui un ripristino delle impostazioni di fabbrica. Per i sistemi cloud e virtuali, eseguire un ripristino delle impostazioni di fabbrica utilizzando un'immagine esterna pulita del dispositivo.

Applicare la patch descritta in Security Advisory Ivanti Connect Secure, Policy Secure e ZTA Gateways (CVE-2025-22457). Si noti che le patch per Ivanti ZTA Gateways e Ivanti Policy Secure saranno disponibili rispettivamente il 19 e il 21 aprile. Si consiglia di disconnettere i dispositivi vulnerabili finché non saranno disponibili le patch.

Monitorare i servizi di autenticazione o di gestione dell'identità che potrebbero essere esposti.

Continuare a controllare gli account con accesso a livello di privilegio.

Se le azioni di ricerca delle minacce determinano un compromesso: Per i dispositivi che sono stati confermati compromessi, isolare tutte le istanze interessate dalla rete. Mantenere isolati i dispositivi interessati fino al completamento delle seguenti istruzioni e all'applicazione delle patch.

Acquisisci un'immagine forense (inclusa l'acquisizione della memoria) o contatta Ivanti per ottenere una copia dell'immagine.

Disconnettere tutte le istanze compromesse.

Per il massimo livello di sicurezza, esegui un ripristino delle impostazioni di fabbrica.Per i sistemi cloud e virtuali, eseguire un ripristino delle impostazioni di fabbrica utilizzando un'immagine esterna pulita del dispositivo.

Revoca e riemette tutti i certificati, le chiavi e le password connessi o esposti, includendo quanto segue: Reimposta la password di abilitazione amministratore.

Reimposta le chiavi API (Application Programming Interface) memorizzate.

Reimposta la password di tutti gli utenti locali definiti sul gateway, inclusi gli account di servizio utilizzati per la configurazione del server di autenticazione.

Se gli account di dominio associati ai prodotti interessati sono stati compromessi: Reimpostare due volte le password per gli account on-premise, revocare i ticket Kerberos e quindi revocare i token per gli account cloud nelle distribuzioni ibride.

Per i dispositivi registrati/collegati al cloud, disabilitare i dispositivi nel cloud per revocare i token del dispositivo.

Applicare la patch descritta nell'avviso di sicurezza Ivanti Connect Secure, Policy Secure e ZTA Gateway (CVE-2025-22457). Si noti che le patch per Ivanti ZTA Gateway e Ivanti Policy Secure saranno disponibili rispettivamente il 19 e il 21 aprile.

Segnalarlo immediatamente a CISA e Ivanti.

Le organizzazioni devono segnalare incidenti e attività anomale al Centro operativo 24 ore su 24, 7 giorni su 7 del CISA all'indirizzo Report@cisa.gov o al numero (888) 282-0870.

https://www.cisa.gov/news-events/alerts/2025/04/04/ivanti-re

Gli aiuti informatici occidentali all'Ucraina sono messi a dura prova dal protrarsi della guerra contro la Russia

L'assistenza informatica internazionale ha svolto un ruolo fondamentale nel sostenere la difesa dell'Ucraina contro gli attacchi informatici russi. Tuttavia, con il proseguire della guerra, il sostegno dell'Occidente sta diminuendo, sollevando crescenti preoccupazioni sull'efficacia a lungo termine di questi sforzi, secondo un recente rapporto.

Dall'inizio della guerra, il governo degli Stati Uniti, gli alleati europei e le aziende del settore privato hanno fornito all'Ucraina un'assistenza informatica fondamentale che ha permesso a Kyiv di contrastare gli attacchi DDoS (Distributed Denial-of-Service), di proteggere l'infrastruttura cloud e di rimuovere le intrusioni russe dalle sue reti, hanno dichiarato i ricercatori dell'Aspen Institute, un'organizzazione no-profit, in un rapporto pubblicato martedì.

Negli ultimi due anni, il governo statunitense ha fornito all'Ucraina oltre 82 milioni di dollari in assistenza informatica. Il Meccanismo di Tallinn, un'iniziativa multinazionale, ha raccolto oltre 200 milioni di euro (216 milioni di dollari) per rafforzare la capacità di difesa informatica non militare dell'Ucraina, mentre IT Coalition, un gruppo di dieci nazioni europee, ha promesso lo scorso febbraio di aiutare l'Ucraina a sostenere la sua infrastruttura informatica critica per i prossimi sei anni.

Tuttavia, le crescenti divisioni politiche a Washington e il cambiamento delle priorità globali hanno sollevato preoccupazioni circa un sostegno duraturo all'Ucraina. Anche i contributi del settore privato, pur continuando, sono diminuiti a causa del protrarsi della guerra più a lungo del previsto.

Le principali organizzazioni coinvolte nella fornitura di aiuti informatici all'Ucraina, tra cui il Cyber Defense Assistance Collaborative (CDAC), un gruppo di volontari composto da aziende e organizzazioni occidentali di sicurezza informatica, devono affrontare sfide significative nel tentativo di aiutare l'Ucraina.

Ad esempio, le organizzazioni ucraine spesso presentano richieste di aiuto sovrapposte o contrastanti a diversi donatori, complicando il coordinamento. I frequenti cambi di leadership all'interno delle istituzioni ucraine hanno ulteriormente rallentato gli sforzi di assistenza e reso i donatori esitanti a impegnare risorse a lungo termine, hanno detto i ricercatori.

Inoltre, le licenze e i programmi di formazione inizialmente concepiti come misure a breve termine richiedono ora rinnovi e un sostegno continuo. Le discussioni su un sostegno strutturato e a lungo termine rimangono lente, nonostante la continua minaccia delle operazioni informatiche russe.

Un'altra questione fondamentale è la difficoltà di valutare l'efficacia degli aiuti informatici. Molte aziende del settore privato, comprese quelle del CDAC, sono riluttanti a rivelare informazioni specifiche a causa di problemi di sicurezza, obblighi contrattuali e timori di esposizione pubblica. Nel frattempo, i beneficiari ucraini spesso non hanno le risorse per fornire un feedback sull'impatto dell'assistenza ricevuta, complicando ulteriormente gli sforzi per misurarne il successo.

Contributi del settore privato

Le aziende private del settore informatico e tecnologico, come Microsoft, Cloudflare e Mandiant, hanno sostenuto attivamente gli sforzi di difesa informatica dell'Ucraina fornendo supporto di intelligence, licenze software e programmi di formazione.

Tuttavia, il livello di nuove iniziative private è diminuito di recente. Secondo i ricercatori, diversi fattori contribuiscono a questo declino, tra cui il successo della resilienza digitale dell'Ucraina, la percezione dell'inefficacia della Russia nel dominio cibernetico, la stanchezza di alcuni fornitori di assistenza e la mancanza di finanziamenti dedicati per sostenere iniziative sistemiche su larga scala.

Secondo l'Aspen Institute, ci sono pareri discordanti sul fatto che il sostegno digitale e informatico all'Ucraina debba concentrarsi sulla risoluzione dei problemi immediati di difesa informatica o sulla costruzione di una forza digitale a lungo termine. Secondo i ricercatori, è ancora una sfida concordare le giuste priorità e lavorare insieme in modo efficace.

Prima della guerra tra Russia e Ucraina, negli Stati Uniti non esistevano sistemi formali per gestire l'assistenza alla difesa informatica che coinvolgesse il settore privato. Questi sistemi sono stati istituiti solo alla fine del 2023, quasi due anni dopo la guerra. La mancanza di fondi e la percezione che il peggio della crisi sia passato hanno portato a un minore aiuto volontario da parte del settore privato. Inoltre, gli aiuti informatici all'Ucraina sono ora influenzati dalla politica interna e sono considerati meno prioritari rispetto a potenziali nuovi conflitti.

Nonostante queste sfide, si è sviluppata una forte fiducia tra l'Ucraina e i suoi fornitori di assistenza informatica. “Tale fiducia è stata costruita in gran parte soddisfacendo le richieste ucraine e imparando a lavorare con loro per fornire informazioni e tecnologia in modo continuo e maturo”, hanno dichiarato i ricercatori.

Le lezioni apprese dalla guerra cibernetica ucraina dovrebbero influenzare la futura cooperazione internazionale in materia di sicurezza informatica. “Poiché le tensioni geopolitiche intorno alla Russia e in Asia orientale continuano a mostrare una crescente componente informatica, queste lezioni sono fondamentali per aiutare gli Stati Uniti a gestire le crisi e, se necessario, a difendere con successo i propri alleati e amici”, hanno affermato i ricercatori.

https://therecord.media/western-cyber-aid-to-ukraine-faces-strain-war-drags

La CISA avverte della vulnerabilità di Apache Tomcat sfruttata in natura

La Cybersecurity and Infrastructure Security Agency (CISA) ha aggiunto una vulnerabilità critica di Apache Tomcat al suo catalogo delle vulnerabilità note sfruttate (KEV) in seguito alle prove di sfruttamento attivo in circolazione.

La vulnerabilità, identificata come CVE-2025-24813, consente ad aggressori remoti di eseguire codice arbitrario, accedere a informazioni sensibili o iniettare contenuti dannosi tramite un difetto di equivalenza del percorso nel famoso software per server web.

Vulnerabilità di equivalenza del percorso Apache Tomcat

CVE-2025-24813 è una vulnerabilità di equivalenza del percorso con un punteggio CVSS di 9,8, che rappresenta un grave rischio per le organizzazioni che eseguono installazioni Tomcat non corrette.

La falla è causata dalla gestione impropria delle richieste PUT parziali, che consente ad aggressori non autenticati di eseguire codice in remoto tramite una sofisticata catena di attacchi.

"Questa vulnerabilità non è universalmente sfruttabile. Richiede una confluenza di configurazioni specifiche", hanno osservato i ricercatori della sicurezza che stanno indagando sulla falla.

Tuttavia, quando queste condizioni si allineano, l’attacco diventa “semplicissimo da eseguire”, secondo i ricercatori di Wallarm citati in recenti rapporti.

La vulnerabilità interessa più versioni di Apache Tomcat, tra cui 11.0.0-M1 a 11.0.2, 10.1.0-M1 a 10.1.34 e 9.0.0.M1 a 9.0.98.

I ricercatori di sicurezza hanno confermato che anche le versioni 8.5.x (in particolare dalla 8.5.0 alla 8.5.98 e 8.5.100, esclusa la 8.5.99) sono vulnerabili, sebbene inizialmente non fossero state incluse nell'avviso di Apache.

Di seguito è riportato il riepilogo della vulnerabilità:

Gli esperti di sicurezza hanno identificato il processo di sfruttamento come segue:

Gli aggressori inviano al server vulnerabile una richiesta PUT contenente un payload Java serializzato codificato in Base64.

Seguono una richiesta GET contenente un cookie "JSESSIONID" appositamente creato che fa riferimento alla sessione dannosa. Ciò fa sì che il server deserializzi il payload, innescando l'esecuzione del codice.

Per uno sfruttamento di successo, devono essere soddisfatte diverse condizioni:Il servlet predefinito deve avere i permessi di scrittura abilitati (disabilitati per impostazione predefinita).

Deve essere abilitato il supporto PUT parziale (abilitato per impostazione predefinita).

L'applicazione deve utilizzare la persistenza della sessione basata sui file di Tomcat.

L'applicazione deve includere una libreria vulnerabile alla deserializzazione.

Bonifica

La CISA ha aggiunto CVE-2025-24813 al suo catalogo KEV, segnalandolo come un “frequente vettore di attacco per i malintenzionati” che pone “rischi significativi per l’impresa federale”.

Le agenzie del ramo esecutivo civile federale (FCEB) sono tenute a porre rimedio a questa vulnerabilità entro il 22 aprile 2025, in base alla direttiva operativa vincolante (BOD) 22-01.

Sebbene la direttiva si applichi solo alle agenzie federali, la CISA “esorta fermamente tutte le organizzazioni a ridurre la loro esposizione agli attacchi informatici dando priorità a una tempestiva correzione”.

Apache ha rilasciato versioni patchate per risolvere questa vulnerabilità. Le organizzazioni dovrebbero effettuare immediatamente l'aggiornamento ad Apache Tomcat versioni 9.0.99, 10.1.35 o 11.0.3, a seconda del loro ambiente.

Gli esperti di sicurezza raccomandano inoltre queste ulteriori strategie di mitigazione:Disattivare i metodi HTTP non necessari.

Applicare rigidi controlli di accesso.

Distribuire firewall per applicazioni Web (WAF).

Implementare un monitoraggio continuo degli indicatori di minaccia.

Per le organizzazioni che non sono in grado di applicare immediatamente la patch, la revisione delle configurazioni del server per assicurarsi che il servlet predefinito non abbia autorizzazioni di scrittura abilitate può fornire una mitigazione temporanea, poiché questa condizione è necessaria per uno sfruttamento riuscito.

https://cybersecuritynews.com/cisa-warns-of-apache-tomcat-vulnerability-exploited/

Creare una rete DPO per la sanità pubblica: perché è essenziale

Il Garante Privacy invita i DPO della sanità pubblica a creare una rete per affrontare le sfide della protezione dei dati, migliorare la compliance e rafforzare la sicurezza informatica. Un’alleanza strategica per un sistema sanitario più sicuro ed efficace

Nel complesso panorama della sanità pubblica italiana, la gestione della privacy e dei dati personali rappresenta una sfida cruciale.

Il Garante Privacy ha lanciato un chiaro invito: costituire una rete DPO nella sanità pubblica per rafforzare la protezione dei dati e migliorare la compliance normativa. Un’iniziativa strategica che potrebbe offrire numerosi vantaggi ai professionisti del settore e garantire una maggiore sicurezza per i cittadini.

Modelli organizzativi e gestione gerarchica dei dati sanitari

I titolari del trattamento che operano in tale contesto ben sanno, inoltre, che le innovazioni tecnologiche hanno profondamente mutato il processo di trattamento dei dati di salute, passato in pochi decenni da modalità analogiche e gestite in regime quasi del tutto autarchico a modalità automatizzate e digitali, condivise tra più attori, le cui attività devono svolgersi nel rispetto dei principi di privacy by design e privacy by default di cui all’articolo 25 del Regolamento Ue 2016/679.

Riprova di tale nuovo approccio alla gestione dell’informazione di salute sono, in particolare, i modelli organizzativi condivisi gerarchicamente tra i diversi livelli di cui si compone il sistema sanitario, come ad esempio quello dell’anagrafe nazionale vaccini o dell‘importante strumento costituito dal Fascicolo Sanitario Elettronico dove le responsabilità del trattamento dei dati sono suddivise tra livello del produttore, la struttura sanitaria, del coordinatore a livello locale, la regione o la provincia autonoma, e il livello centrale, spesso individuato nel Ministero della Salute.

Il ruolo cruciale del DPO nella sanità pubblica

In questo contesto, il ruolo del Data Protection Officer è divenuto sempre più cruciale, ma anche sempre più impegnativo da svolgere.

E purtroppo sinora, per contro, pochi amministratori se ne sono resi pienamente conto, rischiando così di avviare trattamenti di dati di non completa liceità e compliance al dettato normativo, corpus di regole che spesso non tiene il passo con le occasioni messe a disposizione dall’innovazione tecnologica o non riesce a individuarne pienamente i possibili punti critici.

L‘invito del Garante alla creazione di una rete DPO

Per supportare nel miglior modo tale processo e consentire al sistema sanitario di affrontare con efficacia le sfide attuali e future, è quindi oltremodo opportuno pensare ad avviare una maggiore collaborazione tra i DPO delle diverse strutture sanitarie, professionisti che nel dare seguito ai compiti previsti dall’articolo 39 del Regolamento UE 2016/679 possono trovare estrema utilità nel confronto e collaborazione tra pari.

Ed è proprio l’Autorità Garante che, anche alla luce di esperienze già attive da tempo relativamente al Progetto, messo in campo da Garante e ABI, di costituzione di una “Rete dei Responsabili della protezione dati nel settore bancario”, un gruppo di lavoro permanente, finalizzato al confronto e interscambio informativo tra l’Autorità e i RPD coinvolti nella gestione di trattamenti così complessi” ha nel corso di una importante giornata di studio tenutasi a Trieste a fine novembre 2024 ed organizzata da APIHM e dall’Università di Trieste che ha invitato i DPO del sistema sanitario ad organizzarsi con una propria rete.

Perché creare una rete DPO per la sanità pubblica?

A tal proposito la costituzione di una Rete nazionale dei DPO della sanità pubblica può rappresentare oggi una soluzione strategica per migliorare l’efficacia della funzione di tali professionisti, tale da garantire una gestione più coordinata e una protezione più uniforme dell’enorme e preziosissimo patrimonio di dati dei cittadini che i singoli Enti sanitari hanno in custodia e che sono molto ambiti da svariati soggetti, come i fornitori di servizi e i produttori di farmaci, ma anche dai criminali.

Ma quali sono le principali motivazioni che giustificano questa necessità?

Ridurre la frammentazione e uniformare la compliance

Il sistema sanitario italiano è caratterizzato da una estrema frammentazione, con una serie diversificata di strutture (ospedali, ASL, aziende sanitarie, IRCCS, Aziende sanitarie universitarie, Cliniche Universitarie, Case di cura, Centri diagnostici) con caratteristiche e dimensioni diverse che operano in modo autonomo e sono soggette a regolamentazioni non del tutto omogenee.

Questa frammentazione si riflette anche nella gestione della riservatezza degli utenti dei servizi e della protezione dei loro dati, tematiche che vengono affrontate con approcci disomogenei e, purtroppo, molto spesso di non completa efficacia come vediamo dalla cronaca, con i molti blocchi e danni ai sistemi informativi per attacchi di ransomware o altri tipi di incidenti di sicurezza.

La costituzione di una specifica rete di DPO potrebbe innanzitutto ridurre il rischio di interpretazioni divergenti della vigente normativa nazionale e comunitaria, favorendo senz’altro una maggiore uniformità nell’applicazione delle norme.

Tale uniformità applicativa risulta particolarmente importante in un contesto nel quale i dati sanitari vengono spesso condivisi tra diverse strutture, in particolare per garantire la continuità assistenziale o per la conduzione di attività di ricerca.

La possibilità di condividere conoscenze, esperienze e best practice, tipico effetto di una rete tra professionisti, sarebbe quindi di grande beneficio per il settore sanitario, che è caratterizzato da estremo dinamismo e governato da normative in continua evoluzione ed esposto ai rischi emergenti, come quelli legati alla cybersecurity e all’uso delle nuove tecnologie, come l’intelligenza artificiale e la telemedicina.

Una rete permetterebbe ai DPO di confrontarsi sulle tematiche di carattere comune, sulle soluzioni adottate e sulle criticità riscontrate, e l’esito del dibattito interno alla rete andrebbe così a costituire un patrimonio di conoscenza comune, a beneficio di tutti i suoi componenti.

Inoltre, la possibile analisi e condivisione tra gli attori della rete di taluni modelli operativi e di strumenti standardizzati, come linee guida, checklist, e di metodiche per la valutazione d’impatto dei trattamenti, ecc. potrebbe contribuire a ridurre significativamente i tempi ed i costi legati al raggiungimento della compliance dei titolari del trattamento del contesto sanitario, migliorando al contempo la qualità del lavoro svolto all’interno delle relative strutture.

Rfforzare la sicurezza e la risposta alle emergenze

Nel settore sanitario le violazioni dei dati e gli incidenti di cybersecurity sono in costante aumento, e le statistiche ufficiali su tale problematica evidenziano che tale settore operativo rappresenta uno dei principali bersagli degli attacchi da parte dei criminali informatici, visto anche l’elevato valore economico delle informazioni oggetto di corrente e massivo trattamento.

Ma il tema della sicurezza dei dati è purtroppo di scarso interesse per il management e nel caso purtroppo sempre più frequente di emergenze di sicurezza, i DPO si trovano spesso a dover gestire situazioni complesse, con tempi stretti e pressioni elevate.

Una rete di DPO potrebbe quindi costituire un sistema di allerta che permette di condividere informazioni su potenziali minacce e di coordinare risposte tempestive ed efficaci.

Inoltre, la rete potrebbe facilitare la creazione di protocolli comuni per la gestione delle violazioni dei dati, garantendo una risposta uniforme e conforme alle normative agli enti dove questi operano.

Diffondere la cultura della privacy nella sanità

Uno dei compiti fondamentali del DPO è promuovere una cultura della riservatezza e della protezione dei dati personali all’interno dell’organizzazione dei titolari e dei responsabili del trattamento.

Tuttavia, in un contesto frammentato come quello del sistema sanitario italiano questo obiettivo, che costituisce a ben vedere una vera e propria misura organizzativa di sicurezza, non sempre viene perseguito con metodo e risorse adeguate, rischiando di ottenere risultati disomogenei e di efficacia molto limitata.

Una rete strutturata e coordinata di DPO potrebbe quindi svolgere un ruolo chiave nel promuovere una cultura della privacy condivisa a livello di sistema e una maturazione della percezione della rilevanza della materia della protezione dei dati come asset fondamentale del sistema sanitario.

Attività come campagne di sensibilizzazione, workshop per il top management, corsi di formazione comuni o la creazione di materiali informativi standardizzati, potrebbero aumentare in effetti la consapevolezza di tutti gli operatori sanitari, migliorando l’attenzione alla protezione dei dati e riducendo enormemente i rischi legati agli errori umani, che sappiamo esserne la maggior fonte.

La rete DPO come strumento di rappresentanza e ottimizzazione

I DPO del sistema sanitario si trovano a dover affrontare sfide comuni, legate all’interpretazione delle normative, alla mancanza di risorse e all’estrema complessità tecnica del settore nel quale si trovano ad operare.

Senza un coordinamento a livello nazionale, la loro voce rischia di rimanere frammentata, per nulla incisiva e spesso inascoltata.

Una rete coordinata di DPO potrebbe a tal proposito svolgere un ruolo di rappresentanza di questo importantissimo settore, portando le istanze direttamente all’attenzione delle istituzioni, dell’Autorità Garante per la protezione dei dati personali e degli altri stakeholder, fra i quali anche i rappresentanti della particolare categoria di interessati, i cittadini assistiti dal sistema sanitario.

Questo permetterebbe ai DPO di far sentire la propria voce, di influenzare positivamente le politiche pubbliche, di ottenere chiarimenti normativi e di garantire che le specificità del settore sanitario siano adeguatamente considerate.

Molte strutture sanitarie, soprattutto quelle più piccole, faticano a dotarsi di DPO con competenze adeguate, spesso a causa del limitato impegno di risorse e della scarsa comprensione dell’importanza strategica di questa figura.

Una rete coordinata di DPO potrebbe favorire la condivisione di risorse e competenze, ad esempio attraverso la creazione di pool di esperti disponibili a supportare più strutture o la definizione di modelli di collaborazione tra grandi e piccole aziende sanitarie.

La rete potrebbe anche facilitare l’accesso a finanziamenti o progetti comuni, sfruttando sinergie e riducendo i costi per le singole strutture di titolari e responsabili del trattamento.

Guidare l’innovazione digitale in sanità

La digitalizzazione del settore sanitario rappresenta un’opportunità straordinaria per migliorare l’efficienza e la qualità dei servizi che gli enti devono assolutamente cogliere, ma essa può comportare anche nuovi rischi per la protezione dei dati, ancora non ben compresi e quindi non pienamente valutati.

L’adozione di tecnologie come l’intelligenza artificiale, la blockchain o i big data in ambito sanitario richiede un approccio molto attento e consapevole, che tenga debitamente conto delle conseguenti implicazioni per la protezione dei dati degli interessati.

Una rete coordinata di DPO potrebbe svolgere un ruolo chiave nel guidare l’innovazione, garantendo che le nuove tecnologie siano implementate nel rispetto delle normative e dei diritti dei cittadini.

Inoltre, la rete potrebbe favorire lo sviluppo di soluzioni comuni, come piattaforme sicure per la condivisione dei dati o strumenti per una migliore pseudonimizzazione dei dati, anche a scopo di ricerca.

Perché la rete DPO è una necessità strategica

In conclusione, la costituzione di una rete dei DPO del sistema sanitario nazionale non è più un’opzione, ma è diventata una necessità vera e propria.

In un contesto caratterizzato da complessità normative, rischi crescenti e risorse limitate, la collaborazione tra i DPO rappresenta l’unico modo per garantire una protezione efficace dei dati e, al contempo, migliorare l’efficienza del sistema sanitario.

Una rete di DPO permetterebbe di condividere conoscenze, uniformare gli approcci, rafforzare la capacità di risposta alle emergenze e promuovere una cultura della privacy condivisa.

Inoltre, potrebbe svolgere un ruolo di rappresentanza e favorire l’innovazione, contribuendo a creare un sistema sanitario più sicuro, trasparente e all’avanguardia.

Investire nella creazione di questa rete non significa solo rispondere alle esigenze del presente, ma anche prepararsi alle sfide del futuro, garantendo che la protezione dei dati rimanga al centro della trasformazione digitale del settore sanitario, nel pieno rispetto ed a tutela dei principi fondamentali del Regolamento UE 2016/679.

https://www.agendadigitale.eu/sanita/creare-una-rete-dpo-per-la-sanita-pubblica-perche-e-essenziale/

La guida per tutti a Log4Shell (CVE-2021-44228)

Se lavori nella sicurezza, è probabile che tu abbia trascorso gli ultimi giorni a rispondere urgentemente alla vulnerabilità Log4Shell (CVE-2021-44228), indagando dove hai istanze di Log4j nel tuo ambiente e interrogando i tuoi fornitori sulla loro risposta. Probabilmente hai già letto le implicazioni e i passaggi da seguire. Questo blog è per tutti coloro che vogliono capire cosa sta succedendo e perché Internet sembra essere di nuovo in fiamme. E per voi professionisti della sicurezza, abbiamo anche incluso alcune domande sulle implicazioni più ampie e sulla visione a lungo termine. Sai, per tutto quel tempo libero che hai in questo momento.

Che cos'è Log4Shell?

Log4Shell, noto anche come CVE-2021-44228, è una vulnerabilità critica che consente l'esecuzione di codice remoto nei sistemi che utilizzano Log4j della Apache Foundation, una libreria Java open source ampiamente utilizzata in prodotti e utilità software commerciali e open source. Per una valutazione tecnica più approfondita di Log4Shell, consulta l'analisi AttackerKB di Rapid7.

Che cos'è Log4j?

Log4j è uno degli strumenti più comuni per inviare testo da archiviare in file di registro e/o database. È utilizzato in milioni di applicazioni e siti Web in ogni organizzazione in tutta Internet. Ad esempio, le informazioni vengono inviate per tenere traccia dei visitatori del sito Web, annotare quando si verificano avvisi o errori durante l'elaborazione e aiutare a supportare i problemi di triage dei team.

Allora qual è il problema?

Si scopre che Log4j non registra solo stringhe semplici. Le stringhe di testo formattate in un certo modo saranno eseguite proprio come una riga di un programma per computer. Il problema è che questo consente agli attori malintenzionati di manipolare i computer in tutto Internet per fargli compiere azioni senza la volontà o il permesso dei proprietari del computer. Gli attacchi informatici possono usare questo per rubare informazioni, forzare azioni o estorcere denaro ai proprietari o agli operatori del computer.

Questa vulnerabilità è ciò a cui ci riferiamo come Log4Shell, o CVE-2021-44228. Log4j è la tecnologia vulnerabile. Poiché questa è una situazione in continua evoluzione, puoi sempre andare al nostro blog principale in diretta su Log4Shell.

È davvero una cosa così importante?

In una parola, sì.

Caitlin Kiska, un ingegnere della sicurezza informatica presso Cardinal Health, l'ha messa così : "Immaginate che ci sia uno specifico tipo di bullone utilizzato nella maggior parte delle auto e dei componenti di auto nel mondo, e che abbiano appena detto che quel bullone deve essere sostituito." Glenn Thorpe, Emergent Threat Response Manager di Rapid7 ha aggiunto, "... e la presenza di quel bullone consente a chiunque di impossessarsi dell'auto."

Il primo problema è l'uso diffuso di Log4j. Questo piccolo strumento è utilizzato in innumerevoli sistemi su Internet, il che rende la correzione o la mitigazione di questo un compito enorme, e rende più probabile che qualcosa possa essere trascurato.

Il secondo problema è che gli aggressori possono usarlo in vari modi, quindi per loro il limite è il cielo.

Forse la preoccupazione più grande di tutte è che in realtà è piuttosto facile usare la vulnerabilità per scopi malevoli. Le vulnerabilità di esecuzione di codice remoto sono sempre preoccupanti, ma si spera che siano complicate da sfruttare e richiedano competenze tecniche specialistiche, limitando chi può trarne vantaggio e rallentando il ritmo degli attacchi in modo che i difensori possano idealmente intraprendere prima azioni correttive. Non è questo il caso di Log4Shell. Lo strumento Log4j è progettato per inviare qualsiasi dato immesso nel formato corretto, quindi finché gli aggressori sanno come formare i loro comandi in quel formato (il che non è un segreto), possono trarre vantaggio da questo bug, e attualmente lo stanno facendo.

Sembra piuttosto brutto. La situazione è senza speranza?

Assolutamente no. La buona notizia è che la Apache Foundation ha aggiornato Log4j per risolvere la vulnerabilità. Tutte le organizzazioni devono urgentemente verificare la presenza di questa vulnerabilità nel loro ambiente e aggiornare i sistemi interessati all'ultima versione patchata.

Il primo aggiornamento, la versione 2.15.0, è stato rilasciato il 6 dicembre 2021. Con l'aumento dello sfruttamento in natura, è diventato chiaro che l'aggiornamento non risolveva completamente il problema in tutti i casi d'uso, una vulnerabilità che il National Vulnerability Database (NVD) ha codificato come CVE-2021-45046 .

Di conseguenza, il 13 dicembre, la Apache Foundation ha rilasciato la versione 2.16.0, che rimuove completamente il supporto per i modelli di ricerca dei messaggi, chiudendo così definitivamente la porta alla funzionalità JNDI e probabilmente aggiungendosi agli arretrati del team di sviluppo per aggiornare le sezioni del materiale sulla loro base di codice che gestiscono la registrazione.

Sembra semplice, vero?

Sfortunatamente, sarà probabilmente un'impresa piuttosto imponente e richiederà diverse fasi di individuazione e di bonifica/mitigazione.

Bonifica

Il primo corso d'azione è identificare tutte le applicazioni vulnerabili, che possono essere un mix di soluzioni fornite dal fornitore e applicazioni sviluppate internamente. NCSC NL sta mantenendo un elenco di software interessati, ma le organizzazioni sono incoraggiate a monitorare direttamente gli avvisi e le release del fornitore per le informazioni più aggiornate.

Per le applicazioni sviluppate internamente, le organizzazioni, come minimo, devono aggiornare le proprie librerie Log4j all'ultima versione (che, al 14-12-2021, è la 2.16) e applicare le mitigazioni descritte nel post iniziale del blog di Rapid7 su CVE-2021-44228, che include l'aggiunta di un parametro a tutti gli script di avvio Java e incoraggia vivamente l'aggiornamento delle installazioni di macchine virtuali Java alle versioni più recenti e sicure. Un'ulteriore risorsa, pubblicata dall'Apache Security Team, fornisce un elenco curato di tutti i progetti Apache interessati , che può essere utile per accelerare l'identificazione e la scoperta.

Se i team eseguono controlli "remoti" (vale a dire sfruttando la vulnerabilità da remoto come farebbe un aggressore) anziché controlli "autenticati" sui file system locali, i controlli remoti dovrebbero essere effettuati sia tramite indirizzo IP sia tramite nome di dominio completamente qualificato/nome host virtuale, poiché potrebbero essere in gioco diverse regole di routing che la scansione tramite solo indirizzo IP non riuscirebbe a rilevare.

Queste mitigazioni devono essere eseguite ovunque ci sia un'istanza vulnerabile di Log4j. Non dare per scontato che il problema si applichi solo ai sistemi rivolti a Internet o ai sistemi in esecuzione live. Potrebbero esserci lavori batch che vengono eseguiti ogni ora, ogni giorno, ogni settimana, ogni mese, ecc., su dati archiviati che potrebbero contenere stringhe di exploit che potrebbero innescare l'esecuzione.

Scienze forensi

Gli attacchi sono attivi almeno dal 1° dicembre 2021 e ci sono prove che questa debolezza sia nota almeno da marzo 2021. Pertanto, è abbastanza prudente adottare una mentalità "presunta violazione". NCSC NL ha un'ottima pagina di risorse sui modi in cui è possibile rilevare i tentativi di sfruttamento dai file di registro delle applicazioni. Si prega di notare che questo non è solo un attacco basato sul Web. Le vetrine iniziali di exploit, piuttosto pubbliche, includevano la modifica del nome dei dispositivi iOS e delle auto Tesla. Entrambe queste aziende estraggono regolarmente metadati dai rispettivi dispositivi e sembra che quelle stringhe siano state passate ai gestori di Log4j da qualche parte nella catena di elaborazione. Dovresti esaminare i registri di tutti i sistemi rivolti a Internet, nonché ovunque si verifichi l'elaborazione di Log4j.

I tentativi di sfruttamento si baseranno generalmente sull'estrazione di risorse esterne (come nel caso di qualsiasi attacco dopo aver ottenuto l'accesso iniziale), quindi i rilevamenti comportamentali potrebbero aver già individuato o fermato alcuni attacchi. La debolezza di Log4j consente percorsi di esfiltrazione dei dati piuttosto intelligenti, in particolare DNS. Gli aggressori estraggono valori da variabili di ambiente e file con percorsi di file system noti e creano nomi di dominio dinamici da essi. Ciò significa che le organizzazioni dovrebbero esaminare i log delle query DNS risalendo il più indietro possibile. Nota: ciò potrebbe richiedere un bel po' di tempo e impegno, ma deve essere fatto per assicurarsi di non essere già una vittima.

Risposta proattiva

Per eccesso di cautela, le organizzazioni dovrebbero anche prendere in considerazione la rinumerazione dei segmenti IP critici (in cui risiedeva Log4j), la modifica dei nomi host sui sistemi critici (in cui risiedeva Log4j) e la reimpostazione delle credenziali, in particolare quelle associate ad Amazon AWS e ad altri provider cloud, nel caso in cui siano già state esfiltrate.

Chi dovrebbe prestare attenzione a questo?

Praticamente ogni organizzazione, indipendentemente dalle dimensioni, dal settore o dalla geografia. Se hai qualsiasi tipo di presenza web o connettività internet, devi prestare attenzione e controllare il tuo stato. Se esternalizzi tutti gli aspetti tecnici della tua attività, chiedi ai tuoi fornitori cosa stanno facendo a riguardo.

Chi lo sfrutta e come?

Un po'... tutti .

I ricercatori “benigni” (alcuni indipendenti, altri parte di aziende di sicurezza informatica) stanno utilizzando l’exploit per ottenere una comprensione iniziale della superficie di attacco di base rivolta a Internet.

Anche i cyberattaccanti sono molto attivi e stanno correndo per sfruttare questa vulnerabilità prima che le organizzazioni possano mettere in atto le loro patch. Le botnet, come Mirai, sono state adattate per usare il codice exploit sia per esfiltrare dati sensibili sia per ottenere l'accesso iniziale ai sistemi (alcuni in profondità all'interno delle organizzazioni).

I gruppi ransomware sono già entrati in azione e hanno sfruttato la debolezza di Log4j per compromettere le organizzazioni. Il progetto Heisenberg di Rapid7 sta raccogliendo e pubblicando campioni di tutti i tentativi unici visti dall'11 dicembre 2021.

Come è probabile che si sviluppino le cose?

Queste campagne iniziali sono solo l'inizio. Attacchi sofisticati da parte di gruppi più seri e capaci appariranno nei prossimi giorni, settimane e mesi e probabilmente si concentreranno su software di livello aziendale che è noto per essere vulnerabile.

La maggior parte dei tentativi di attacco iniziali avviene tramite punti di iniezione focalizzati sul sito Web (campi di input, caselle di ricerca, intestazioni, ecc.). Ci saranno campagne più avanzate che colpiranno gli endpoint API (anche API "nascoste" che fanno parte delle app mobili aziendali) e cercheranno di trovare modi furtivi per far passare le stringhe di exploit oltre le guardie di gate (come l'esempio di ridenominazione del dispositivo iOS).

Anche le organizzazioni che hanno rimediato alle applicazioni distribuite potrebbero non notare alcune immagini di macchine virtuali o container che vengono avviate regolarmente o meno. Gli attacchi Log4Shell sono facilmente automatizzabili e li vedremo regolarmente come vediamo WannaCry e Conficker (sì, vediamo ancora parecchi exploit regolarmente per quelle vulnerabilità).

Dobbiamo preoccuparci di vulnerabilità simili in altri sistemi?

Nell'immediato, i team di sicurezza dovrebbero concentrare la loro attenzione sull'identificazione dei sistemi con i pacchetti Log4j interessati.

Nel lungo termine, sebbene sia impossibile prevedere l'identificazione di vulnerabilità simili, sappiamo che la facilità e la prevalenza di CVE-2021-44228 richiedono la continua attenzione (è stato un lungo weekend per molti) dei team di sicurezza, infrastruttura e applicazioni.

Insieme a Log4Shell, abbiamo anche CVE-2021-4104 , segnalato il 9 dicembre 2021, un difetto nella libreria di registrazione Java Apache Log4j nella versione 1.x. JMSAppender che è vulnerabile alla deserializzazione di dati non attendibili. Ciò consente a un aggressore remoto di eseguire codice sul server se l'applicazione distribuita è configurata per utilizzare JMSAppender e il JMS Broker dell'aggressore. Nota che questo difetto riguarda solo le applicazioni che sono specificamente configurate per utilizzare JMSAppender, che non è l'impostazione predefinita, o quando l'aggressore ha accesso in scrittura alla configurazione Log4j per aggiungere JMSAppender al JMS Broker dell'aggressore.

I vettori di exploit di Log4Shell e le mitigazioni segnalate venerdì continuano a evolversi come segnalato dai nostri partner di Snyk.io e dal Java Champion, Brian Vermeer (vedere "Nota dell'editore (13 dicembre 2021)"), pertanto, la vigilanza continua su questa minaccia imminente e presente è tempo ben speso. Gli esercizi postmortem (e ce ne saranno molti) dovrebbero assolutamente includere sforzi per far evolvere inventari di dipendenze software, open source e pacchetti e, dati gli impatti attuali, modellare meglio le minacce dai pacchetti con un comportamento di ricerca non ispezionato simile.

Questo problema indica che dovremmo smettere di compilare sistemi e tornare a costruirli da zero?

Si è sicuramente parlato molto della dipendenza da così tante dipendenze di terze parti in tutte le aree dello sviluppo software. Abbiamo assistito a molti tentativi di avvelenare numerosi ecosistemi quest'anno, da Python a JavaScript, e ora abbiamo una vulnerabilità critica in un componente quasi onnipresente.

Da un lato, c'è un merito nell'affidarsi esclusivamente al codice che sviluppi internamente, basato sulle funzionalità principali del tuo linguaggio di programmazione preferito. Puoi sostenere che questo renderebbe la vita degli aggressori più difficile e ridurrebbe il botto che ottengono per il loro denaro.

Tuttavia, sembra un po' folle rinunciare completamente ai volumi di componenti pre-costruiti, ricchi di funzionalità e altamente utili. E non dimentichiamo che non tutti i software sono creati uguali. L'ideale è che il software creato e condiviso dalla comunità tragga vantaggio da molte più mani alla pompa, occhi più critici e un periodo più lungo per maturare.

La lezione dalla debolezza di Log4Shell sembra abbastanza chiara: usa, ma verifica e supporta! Librerie come Log4j traggono vantaggio dall'ampia adozione della comunità, poiché acquisiscono grandi funzionalità che possono essere sfruttate rapidamente ed efficacemente. Tuttavia, non puoi semplicemente dare per scontato che tutto vada e andrà bene in un dato ecosistema, e devi assolutamente far parte della comunità che esamina le richieste di modifica e funzionalità. Se più occhi fossero puntati sulla richiesta iniziale di aggiungere questa funzionalità piuttosto folle (esecuzione dinamica dei messaggi) e più persone esperte di sicurezza fossero nel flusso di approvazione, molto probabilmente non staresti leggendo questo post in questo momento (e sarebbe uno degli episodi Marvel "What If…?" più noiosi di sempre).

Le organizzazioni dovrebbero sedersi al tavolo delle trattative, offrire supporto nella creazione e revisione del codice e prendere in considerazione il finanziamento di progetti che diventino componenti fondamentali o onnipresenti nel vostro ambiente di sviluppo delle applicazioni.

In che modo una distinta base del software (SBOM) avrebbe influito su questo problema?

Per definizione, una distinta base è un inventario e concettualmente dovrebbe contribuire ad accelerare i tempi di scoperta durante le esercitazioni di risposta alle vulnerabilità emergenti, come l'incidente Log4j in cui siamo coinvolti collettivamente in questo momento.

Uno SBOM è concepito come un record formale che contiene i dettagli e le relazioni della supply chain di vari componenti utilizzati nel software, un po' come un elenco di ingredienti per la tecnologia. In questo caso, tali componenti includerebbero librerie java utilizzate per la registrazione (ad esempio Log4j2).

I requisiti SBOM sono stati inclusi nell'ordine esecutivo statunitense emesso a maggio 2021. Sebbene possano esserci variazioni internazionali, il concetto e gli oggetti previsti sono uniformi. Per questo motivo, farò riferimento ai progressi statunitensi per semplicità.

Da: Elementi minimi per una distinta base del software (SBOM), emesso dal Dipartimento del Commercio, in coordinamento con la National Telecommunications and Information Administration (NTIA), 12 luglio 2021

La domanda con cui molti rispondenti di Log4Shell, tra cui CISO, sviluppatori, ingegneri, amministratori di sistema, clienti e consumatori, si stanno ancora confrontando è semplicemente dove le versioni interessate di Log4j sono in uso all'interno dei loro ecosistemi tecnici. Mantenere inventari accurati delle risorse è diventato sempre più difficile man mano che i nostri ambienti tecnici sono diventati più complicati, interconnessi e di vasta portata. La nostra dipendenza sempre crescente dalle tecnologie connesse a Internet e l'ascesa dell'IT ombra non fanno che peggiorare questo problema.

Le vulnerabilità in strumenti come Log4j, ampiamente utilizzati in una vasta gamma di tecnologie e sistemi, evidenziano la necessità di maggiore trasparenza e automazione per la gestione di asset e inventari. Forse l'impatto sostanziale a lungo termine di Log4Shell sarà quello di riorientare gli investimenti e l'apprezzamento per la crucialità di un inventario accurato di software e componenti associati tramite uno SBOM che può essere facilmente interrogato e collegato alle dipendenze.

In conclusione, se avessimo vissuto in un periodo in cui gli SBOM erano obbligatori e in atto per tutti i progetti software, l'identificazione dei prodotti, dei dispositivi e degli ecosistemi interessati sarebbe stata molto più semplice di quanto non lo sia stata per Log4Shell e la correzione sarebbe stata probabilmente più rapida ed efficace.

In che modo Log4Shell influisce sul mio stato normativo? Devo adottare misure speciali per garantire la conformità?

Secondo Harley Geiger, esperto di policy e conformità di Rapid7, "Gli enti regolatori potrebbero non aver previsto Log4Shell, ma ora che la vulnerabilità è stata scoperta, ci si aspetta che le aziende regolamentate la affrontino. Mentre i programmi di sicurezza delle organizzazioni affrontano questa vulnerabilità diffusa e grave, tali azioni dovrebbero essere allineate con i requisiti di conformità e la segnalazione. Per molte aziende regolamentate, la scoperta di Log4Shell innesca la necessità di rivalutare i rischi aziendali, l'efficacia delle loro misure di sicurezza per proteggere sistemi e informazioni sensibili (inclusa la patch alla versione più recente) e la prontezza dei loro processi di risposta agli incidenti per affrontare il potenziale sfruttamento di Log4j. Molte normative richiedono inoltre che questi obblighi vengano trasferiti ai fornitori di servizi. Se uno sfruttamento di Log4j comporta un'interruzione significativa dell'attività o una violazione delle informazioni personali, le normative potrebbero richiedere all'azienda di emettere un rapporto sugli incidenti o una notifica di violazione".

Abbiamo anche chiesto ad Harley se è probabile che assisteremo a una risposta di politica pubblica. Ecco cosa ha detto...

"A livello di politica federale, le organizzazioni dovrebbero aspettarsi una spinta rinnovata per l'adozione di SBOM per aiutare a identificare la presenza di Log4j (e altre vulnerabilità) nei prodotti e negli ambienti in futuro. La CISA ha anche richiesto alle agenzie federali di accelerare la mitigazione di Log4j e ha intensificato la condivisione delle informazioni relative alla vulnerabilità. Ciò potrebbe dare impulso alla legislazione sulla segnalazione degli incidenti informatici che sta circolando al Congresso al momento".

Come sappiamo tutto questo?

Bene, un gruppo di ragazzi ha iniziato a creare scompiglio nei server di Minecraft e da lì le cose sono andate semplicemente in discesa. Sebbene ci sia del vero in questo, la realtà è che è stato presentato un problema al progetto Log4j a fine novembre 2021. Il codice proof-of-concept è stato rilasciato a inizio dicembre e gli attacchi attivi sono iniziati poco dopo. Alcuni fornitori di sicurezza informatica hanno prove di attacchi preliminari a partire dal 1° dicembre 2021.

Chiunque monitorasse le discussioni sul problema (cosa che sia gli sviluppatori, sia i difensori che gli aggressori fanno regolarmente) avrebbe notato il buco enorme creato da questa "funzionalità".

Da quanto tempo esiste?

Ci sono prove di una richiesta di aggiunta di questa funzionalità risalente al 2013. Un intervento al Black Hat USA 2016 ha menzionato in generale diversi vettori di esecuzione di codice remoto con iniezione JNDI, ma non ha indicato direttamente Log4j.

Nel marzo 2021 è stato scoperto anche un codice proof-of-concept che prendeva di mira la debolezza della ricerca JNDI in Log4j 2.x.

Fear, Uncertainty, and Doubt (FUD) sono in abbondanza oggi e probabilmente persisteranno nelle prossime settimane e mesi. Sebbene adottare una mentalità di "violazione presunta" non sia rilevante per ogni vulnerabilità delle celebrità, la prevalenza e la dipendenza transitiva della libreria Log4j insieme alle sofisticate tecniche di exploit di offuscamento a cui stiamo assistendo in tempo reale sottolineano che la domanda che dovremmo porci non è "Da quanto tempo esiste?" Piuttosto, è "Da quanto tempo dovremmo prepararci mentalmente (e stabilire aspettative) per ripulirla?"

Stiamo aggiungendo altre domande man mano che ci arrivano. Se hai domande a cui vorresti una risposta, faccelo sapere.

Ho sentito che l'aggiornamento non funziona e che potresti comunque essere sfruttato anche se hai aggiornato. Dovrei farmi prendere dal panico?

Se hai aggiornato alla v2.15 (la correzione originale) o alla v2.16 (la correzione più recente), non devi farti prendere dal panico. È vero che l'aggiornamento alla v2.15 "era incompleto in alcune configurazioni non predefinite" e che è stato designato come vulnerabilità separata: CVE-2021-45046. Ma le parole chiave qui sono "in alcune configurazioni non predefinite".

In sostanza, quando una configurazione di registrazione utilizza un Pattern Layout non predefinito con Context Lookup, gli aggressori con controllo sui dati di input della Thread Context Map (MDC) possono creare dati di input dannosi utilizzando un pattern JNDI Lookup. Ciò può causare attacchi DoS e ora abbiamo scoperto che può anche causare perdite di informazioni e, in alcuni casi specifici, RCE. Ciò ha portato all'aggiornamento della vulnerabilità da un punteggio CVSS di 3,7 a 9,0 sul sito Web di Apache Foundation , ma l'RCE è attualmente segnalato solo per macOS e non è stato segnalato pubblicamente alcuno sfruttamento in-the-wild, quindi non è ancora il momento di farsi prendere dal panico. La conclusione è che è necessario aggiornare alla v2.17 il prima possibile, ma a meno che non si disponga di quelle configurazioni non predefinite, la v2.15 probabilmente è quella giusta.

Ho sentito che ora ci sono prove di attacchi ransomware contro questa vulnerabilità. Dovrei farmi prendere dal panico?

È vero che hanno iniziato ad apparire segnalazioni del gruppo ransomware Conti, che sfrutta CVE-2021-44228 (Log4Shell) per montare attacchi. Secondo un rapporto di AdvIntel, Conti sta testando lo sfruttamento prendendo di mira le istanze vulnerabili di Log4j2 in VMware vCenter "per il movimento laterale direttamente dalla rete compromessa, con conseguente accesso a vCenter che colpisce le reti delle vittime statunitensi ed europee dalle sessioni Cobalt Strike preesistenti". Sebbene non sia il momento di farsi prendere dal panico, ci aspettiamo di vedere uno sfruttamento basato su riscatto molto più diffuso nelle prossime settimane, e questo è un altro motivo per assicurarti di avere la versione più recente (v2.17) il prima possibile.

È corretto eseguire la scansione per individuare applicazioni o sistemi vulnerabili?

Se possiedi o noleggi sistemi e disponi delle autorizzazioni appropriate, è assolutamente corretto eseguire una scansione per identificare applicazioni o sistemi vulnerabili. Infatti, ti consigliamo vivamente di farlo nei tuoi ambienti in modo da poter applicare le patch.

Oltre a ciò, sebbene le leggi varino da Paese a Paese, la maggior parte delle leggi anti-hacking si basa sul divieto di superare l'accesso autorizzato o di accedere ai sistemi senza autorizzazione, quindi la scansione dei beni altrui senza permesso potrebbe violare la legge.

Ad esempio, come spiega in questo tweet il nostro esperto di politica pubblica statunitense Harley Geiger, in base alla legge statunitense anti-hacking, il Computer Fraud and Abuse Act (CFAA), "Se il test comporta l'esfiltrazione non autorizzata di dati non pubblici da un sistema di destinazione o fa sì che un sistema di destinazione scarichi il tuo codice eseguibile senza autorizzazione, anche se fatto in buona fede, fermati e fatti amico un avvocato".

https://www.rapid7.com/blog/post/2021/12/15/the-everypersons-guide-to-log4shell-cve-2021-44228/