hacking Archivi - Webbare

Scoperta una falla di sicurezza nel framework Next.js

admin — Wed, 26 Mar 2025 14:42:40 +0000

È stata scoperta una falla critica nella sicurezza nel popolare framework Next.js, che potrebbe avere un impatto su milioni di siti web e applicazioni.

I ricercatori di sicurezza Rachid Allam, noto online come zhero, e Yasser Allam (inzo_) hanno collaborato per scoprire la falla nella funzionalità middleware del framework.

Next.js, che vanta oltre 130.000 stelle su GitHub e quasi 10 milioni di download settimanali, è un framework costruito su React. Il suo ampio set di funzionalità lo rende una scelta popolare per gli sviluppatori, ma presenta anche un’ampia superficie di attacco per i ricercatori di sicurezza.

La vulnerabilità risiede nel modo in cui Next.js gestisce il middleware, una funzione che consente agli sviluppatori di eseguire codice prima che una richiesta sia completata.

Il middleware è un componente cruciale per diverse funzionalità, tra cui la riscrittura dei percorsi, i reindirizzamenti lato server, l’aggiunta di intestazioni di sicurezza come CSP e, soprattutto, l’autenticazione e l’autorizzazione.

Un esempio tipico fornito nel blog post illustra questo aspetto: “Quando un utente tenta di accedere a /dashboard/admin, la sua richiesta passa prima attraverso il middleware, che controlla se i suoi cookie di sessione sono validi e gli concede le autorizzazioni necessarie. In caso affermativo, il middleware inoltrerà la richiesta; altrimenti, il middleware reindirizzerà l’utente a una pagina di login”.

La scoperta dei ricercatori è avvenuta esaminando le versioni precedenti del framework. Analizzando la versione 12.0.7, hanno identificato un pezzo di codice specifico all’interno della funzione runMiddleware.

Questa funzione, responsabile dell’esecuzione del middleware, recupera il valore dell’intestazione x-middleware-subrequest. Questa intestazione serve a determinare se il middleware deve essere applicato a una determinata richiesta. Il valore di questa intestazione viene suddiviso in un elenco utilizzando i due punti (:) come separatore e il framework controlla se questo elenco contiene il valore middlewareInfo.name.

I ricercatori si sono resi conto che aggiungendo l’intestazione x-middleware-subrequest con un valore specifico a una richiesta, potevano effettivamente bypassare completamente il middleware.

“Ciò significa che se aggiungiamo l’intestazione x-middleware-subrequest con il valore corretto alla nostra richiesta, il middleware – qualunque sia il suo scopo – sarà completamente ignorato e la richiesta sarà inoltrata tramite NextResponse.next() e completerà il suo viaggio verso la destinazione originale senza che il middleware abbia alcun impatto/influenza su di essa”. L’intestazione e il suo valore agiscono come una chiave universale che consente di ignorare le regole”.

L’elemento cruciale era determinare il valore corretto per questa “chiave universale”, che dipende da middlewareInfo.name. Questo valore, si scopre, è il percorso del file middleware.

Nelle versioni precedenti di Next.js (prima della 12.2), i file middleware dovevano essere denominati _middleware.ts e risiedevano all’interno della directory pages a causa dell’uso esclusivo del router pages. Questo ha permesso ai ricercatori di dedurre il percorso esatto e quindi il valore dell’intestazione x-middleware-subrequest: pages/_middleware.

I test hanno confermato i loro sospetti. Quando si cercava di accedere a un percorso protetto come /dashboard/team/admin che era configurato per reindirizzare a /dashboard, l’aggiunta dell’intestazione x-middleware-subrequest: pages/_middleware consentiva di aggirare il reindirizzamento e di accedere direttamente alla pagina protetta.

Inoltre, le versioni precedenti alla 12.2 consentivano file middleware annidati, ognuno con il proprio ordine di esecuzione. Ciò significa che per un percorso come /dashboard/panel/admin, esistevano più valori potenziali per l’intestazione x-middleware-subrequest: pages/_middleware, pages/dashboard/_middleware o pages/dashboard/panel/_middleware.

Inizialmente, i ricercatori ritenevano che la vulnerabilità fosse limitata alle versioni precedenti alla 13, a causa di modifiche nella gestione del middleware. Tuttavia, il proseguimento delle indagini ha rivelato una realtà molto più preoccupante.

“Con grande sorpresa, due giorni dopo la scoperta iniziale, abbiamo scoperto che tutte le versioni di next.js, a partire dalla versione 11.1.4, erano vulnerabili”, ha dichiarato Allam.

Sebbene la posizione del codice e la logica di exploit siano leggermente cambiate nelle nuove versioni, la falla fondamentale è rimasta. A partire dalla versione 12.2, i file middleware sono denominati semplicemente middleware.ts e si trovano nella directory principale o nella directory /src, se utilizzata. Questo semplifica i valori potenziali per l’intestazione x-middleware-subrequest a middleware o src/middleware.

Nelle ultime versioni di Next.js, la logica si è evoluta nuovamente per evitare loop infiniti. Il framework ora controlla la profondità del valore dell’intestazione x-middleware-subrequest rispetto a un MAX_RECURSION_DEPTH (impostato a 5). Per aggirare il middleware in queste versioni, l’intestazione deve includere il percorso corretto ripetuto più volte.

I ricercatori hanno fornito esempi concreti di come questa vulnerabilità possa essere sfruttata in scenari reali:

Bypass dell’autorizzazione/riscrittura: Aggiungendo l’header dannoso, sono stati in grado di accedere a un endpoint /admin/login altrimenti protetto da un rewrite basato su middleware.
Bypass del CSP: Hanno dimostrato come la vulnerabilità potesse essere utilizzata per aggirare la Content Security Policy (CSP) e le impostazioni dei cookie applicate dal middleware.
Denial-of-Service (DoS) tramite cache-poisoning: In determinate configurazioni, la vulnerabilità potrebbe essere sfruttata per causare un attacco DoS con avvelenamento della cache. Ciò potrebbe verificarsi se un sito riscrive i percorsi degli utenti in base alla posizione e non ha una risorsa nel percorso principale. L’aggiramento del middleware porterebbe a un errore 404 sulla radice, che potrebbe essere memorizzato nella cache da un CDN per rendere potenzialmente inutilizzabile il sito.

Impatto e rimedio

“Per essere chiari, l’elemento vulnerabile è il middleware. Se non viene utilizzato (o almeno non viene utilizzato per scopi sensibili), non c’è nulla di cui preoccuparsi… poiché bypassando il middleware non si bypassa alcun meccanismo di sicurezza. In caso contrario, le conseguenze possono essere catastrofiche”, avvertono i ricercatori.

È stato emesso un avviso di sicurezza, CVE-2025-29927, per risolvere questa falla critica, alla quale è stato assegnato un punteggio CVSS di 9,1 su 10. I ricercatori hanno osservato che le piattaforme come Vercel non sono in grado di risolvere il problema.

I ricercatori hanno notato che piattaforme come Vercel e Netlify hanno implementato delle mitigazioni, anche se Cloudflare ha inizialmente introdotto una regola che è stata poi resa opt-in a causa dei falsi positivi.

“Questa vulnerabilità è presente da diversi anni nel codice sorgente di next.js, evolvendosi con il middleware e le sue modifiche nel corso delle versioni”, ha dichiarato Allam.

“Una vulnerabilità critica può verificarsi in qualsiasi software, ma quando colpisce uno dei framework più popolari, diventa particolarmente pericolosa e può avere gravi conseguenze per l’ecosistema in generale”.

Il team di Vercel, gli sviluppatori di Next.js, ha reagito prontamente una volta a conoscenza del problema. Una correzione è stata implementata e rilasciata nel giro di poche ore, includendo backport alle vecchie versioni supportate.

Agli sviluppatori che utilizzano Next.js si consiglia vivamente di aggiornare alle versioni corrette o di implementare immediatamente la soluzione consigliata.

L'articolo Scoperta una falla di sicurezza nel framework Next.js proviene da Webbare.

Ricercatori del MIT sviluppano “Oreo” per proteggersi dagli attacchi hardware

admin — Wed, 12 Feb 2025 13:28:16 +0000

I ricercatori del MIT Computer Science and Artificial Intelligence Laboratory (CSAIL) hanno sviluppato un nuovo metodo innovativo per proteggere i computer dagli attacchi hardware.

Nella memoria fisica di un computer, le istruzioni del programma sono memorizzate a indirizzi specifici. Nonostante gli sforzi per oscurare questi indirizzi con tecniche come l’Address Space Layout Randomisation (ASLR), gli hacker più astuti hanno trovato il modo di sfruttare le falle dell’hardware per scovarli.

Soprannominata “Oreo”, dal nome del famoso biscotto a tre strati, la soluzione dei ricercatori promette di rafforzare l’efficacia dell’ASLR e di proteggere dalla crescente minaccia di attacchi collaterali alla microarchitettura, facendo sparire tali tracce.

L’ASLR è una misura di sicurezza standard presente nei moderni sistemi operativi, tra cui Linux e Windows. Il suo ruolo è quello di confondere le istruzioni del programma, rendendo più difficile per gli aggressori prevedere la loro esatta posizione. Tuttavia, gli hacker hanno sviluppato tecniche astute per aggirare l’ASLR.

Invece di sfruttare direttamente le vulnerabilità del software, si affidano ad attacchi collaterali alla microarchitettura. Questi attacchi prendono di mira l’hardware per monitorare le aree di memoria a cui si accede più frequentemente, utilizzando queste informazioni per mettere insieme le posizioni di dati sensibili o frammenti di codice eseguibile, noti come “gadget di codice”.

Una volta identificati questi “gadget”, gli hacker possono sferrare i cosiddetti attacchi di riutilizzo del codice, consentendo il furto di password o l’esecuzione di modifiche amministrative non autorizzate. L’efficacia dell’ASLR, uno scudo un tempo affidabile, ha vacillato di fronte a queste incursioni sofisticate.

“L’ASLR è stato utilizzato in sistemi operativi come Windows e Linux, ma negli ultimi dieci anni i suoi difetti di sicurezza lo hanno reso quasi inutilizzabile”, spiega Mengjia Yan, professore associato al MIT e ricercatore principale del CSAIL.

“Il nostro obiettivo è far rivivere questo meccanismo nei sistemi moderni per difendere gli attacchi alle microarchitetture”.

Per migliorare l’ASLR, il team del CSAIL ha progettato il sistema Oreo. Come dice il nome, questo metodo introduce un processo a tre livelli per nascondere le informazioni vitali agli hacker.

Il cuore di Oreo è uno “spazio degli indirizzi mascherato” che aggiunge un livello intermedio tra lo spazio degli indirizzi virtuali (usato per fare riferimento alle istruzioni del programma) e lo spazio degli indirizzi fisici (dove le istruzioni sono effettivamente memorizzate). Questo strato intermedio essenzialmente “cancella” qualsiasi traccia delle posizioni randomizzate dei programmi prima che le istruzioni vengano eseguite dall’hardware.

Shixin Song, autore principale dell’articolo su Oreo e dottorando in ingegneria elettrica e informatica presso il CSAIL, paragona il processo al biscotto stesso.

“L’idea di strutturarlo in tre strati ci è venuta dai biscotti Oreo”, racconta. “Pensate al ripieno bianco al centro di quel dolcetto: la nostra versione è uno strato che essenzialmente cancella le tracce delle posizioni dei gadget prima che finiscano nelle mani sbagliate”.

Questa strategia aggiunge un ulteriore passaggio che rimappa le istruzioni del programma da indirizzi virtuali randomizzati a posizioni fisse, offuscando il layout originale della memoria. Anche se un hacker utilizza tecniche lato hardware per scoprire gli indirizzi fisici, Oreo garantisce che gli indirizzi virtuali criptati rimangano invisibili.

Il team del CSAIL ha testato Oreo simulando attacchi hardware su Linux utilizzando gem5, una piattaforma spesso impiegata per studiare l’architettura dei computer. I risultati hanno dimostrato che Oreo è in grado di schermare con successo gli attacchi laterali alla microarchitettura senza impattare sulle prestazioni del software che protegge.

“Il nostro metodo introduce modifiche marginali all’hardware, richiedendo solo alcune unità di memoria aggiuntive per memorizzare alcuni metadati”, osserva Song. “Fortunatamente, ha anche un impatto minimo sulle prestazioni del software”.

Questo piccolo ingombro rende Oreo un aggiornamento leggero ma robusto per i sistemi di memoria basati su tabelle di pagine, spesso presenti nelle piattaforme dotate di processori Intel, AMD e Arm.

Il team CSAIL ritiene che Oreo abbia un potenziale significativo al di là di Linux.

“Pensiamo che Oreo possa essere un’utile piattaforma di co-progettazione software-hardware per un tipo più ampio di applicazioni”, afferma Yan. “Oltre a puntare sull’ASLR, stiamo lavorando a nuovi metodi che possano aiutare a salvaguardare le librerie crittografiche critiche ampiamente utilizzate per proteggere le informazioni nelle comunicazioni di rete e nello storage cloud”.

Sebbene Oreo offra una spinta significativa all’ASLR, non si tratta di una pallottola d’argento. Il team riconosce che deve lavorare insieme ad altre difese, in particolare contro gli attacchi di esecuzione speculativa.

Gli attacchi di esecuzione speculativa sono stati resi celebri dalle vulnerabilità Meltdown e Spectre scoperte nel 2018. Tali attacchi sfruttano una funzione del processore progettata per prevedere le attività successive a vantaggio dell’efficienza, ma così facendo lasciano inavvertitamente esposti dati sensibili.

Per difendersi dagli attacchi di esecuzione speculativa, Oreo deve essere abbinato ad altri meccanismi di sicurezza (come le mitigazioni Spectre).

Questa limitazione si estende anche a sistemi più grandi e complessi. Tuttavia, per applicazioni mirate come la salvaguardia di strumenti di crittografia sensibili, il potenziale di Oreo potrebbe essere trasformativo.

Il team CSAIL presenterà i suoi risultati alla fine del mese al Network and Distributed System Security Symposium. Il loro lavoro è stato finanziato da Amazon, dall’US Air Force Office of Scientific Research e da ACE, un centro della Semiconductor Research Corporation sponsorizzato dalla DARPA.

In prospettiva, il team spera che il framework Oreo ispiri un ulteriore sviluppo di meccanismi di co-progettazione software-hardware per combattere le minacce informatiche emergenti. Per ora, questa innovazione a tre livelli è una dolce aggiunta al kit di strumenti per la sicurezza informatica.

L'articolo Ricercatori del MIT sviluppano “Oreo” per proteggersi dagli attacchi hardware proviene da Webbare.

Un ingegnere della sicurezza scopre molteplici vulnerabilità di Git

admin — Wed, 29 Jan 2025 09:52:41 +0000

Un ingegnere della sicurezza ha rivelato una serie di vulnerabilità critiche negli strumenti Git che hanno esposto milioni di sviluppatori al furto di credenziali.

RyotaK, un ingegnere della sicurezza di GMO Flatt Security Inc., stava effettuando una ricerca di bug per il programma GitHub Bug Bounty nell’ottobre 2024 quando ha scoperto delle debolezze in GitHub Desktop, Git Credential Manager, Git LFS, GitHub CLI e GitHub Codespaces, tutte derivanti da una non corretta convalida dell’input e dalla gestione di protocolli basati sul testo.

Il protocollo delle credenziali Git e le sue vulnerabilità

Queste vulnerabilità ruotano attorno al Git Credential Protocol, che scambia le credenziali degli utenti utilizzando un formato chiave-valore con delimitatori di newline (\n).

Mentre Git generalmente vieta le newline e i byte NULL per evitare attacchi di tipo injection, la gestione impropria di altri caratteri di fine riga come i ritorni a capo (\r) ha introdotto delle falle nella sicurezza.

Le vulnerabilità:

GitHub Desktop (CVE-2025-23040) Un URL di sottomodulo maligno abilmente realizzato e contenente %0d (un ritorno a capo esadecimale) poteva aggirare la logica di parsing di GitHub Desktop, inducendolo a esporre le credenziali dell’utente per github.com a domini controllati dagli aggressori.
Git Credential Manager (CVE-2024-50338) Simili falle di parsing nello StreamReader di .NET consentivano ai caratteri di ritorno a capo di far passare i dati attraverso le righe, esponendo gli utenti a un potenziale furto di credenziali.
Git LFS (CVE-2024-53263) Le vulnerabilità di Newline Injection consentivano a repository malintenzionati di modificare i file di configurazione e di aggirare le protezioni di Git, facendo trapelare credenziali sensibili agli aggressori.
GitHub CLI (CVE-2024-53858) Le falle logiche causavano la perdita di token di accesso da parte di GitHub CLI a domini controllati da aggressori quando si sfruttavano alcune variabili d’ambiente come CODESPACES=true o GITHUB_ENTERPRISE_TOKEN.
GitHub Codespaces: Lo script di aiuto alle credenziali di Codespaces (gitcredential_github.sh) restituiva indiscriminatamente token sensibili per tutte le operazioni Git, indipendentemente dall’host richiesto.

In risposta, Git ha implementato un meccanismo di difesa completo (CVE-2024-52006), introducendo la configurazione credential.protectProtocol per bloccare gli URL contenenti caratteri di ritorno a capo (\r).

Questa opzione, abilitata per impostazione predefinita, chiude le vulnerabilità in Git e Git LFS. GitHub ha anche aggiornato Codespaces per convalidare le richieste di host e limitare la condivisione delle credenziali a github.com.

Le scoperte di RyotaK evidenziano i pericoli persistenti dei protocolli basati sul testo e della convalida inadeguata. Come ha osservato l’ingegnere, “un piccolo difetto di architettura può portare a un grande problema di sicurezza”.

Gli sviluppatori e i manutentori di piattaforme sono invitati ad adottare strategie di difesa in profondità e a testare rigorosamente le vulnerabilità di parsing degli input.

L'articolo Un ingegnere della sicurezza scopre molteplici vulnerabilità di Git proviene da Webbare.

Tendenze e previsioni dello sviluppo software per il 2025

admin — Wed, 08 Jan 2025 13:20:11 +0000

Mentre il mondo inizia il 2025, esaminiamo cosa ci aspetta per lo sviluppo del software nel nuovo anno.

Tra le tendenze più urgenti per il 2025 vi sono la semplificazione dello sviluppo dell’intelligenza artificiale, l’integrazione di team di progettazione interfunzionali e l’evoluzione delle pratiche DevSecOps. Questi cambiamenti promettono di ridefinire il modo in cui le aziende affrontano l’innovazione, la sicurezza e l’efficienza delle loro pipeline di sviluppo.

Semplificazione dello sviluppo con l’AI

Avthar Sewrathan, AI Product Lead di Timescale, prevede una trasformazione significativa del panorama dello stack tecnologico entro il 2025.

“Lo stack tecnologico tradizionale continuerà a crollare”, osserva Sewrathan, sottolineando i progressi guidati da API e strumenti che riducono la complessità e consentono uno sviluppo più rapido. Si prevede che questo cambiamento consentirà agli ingegneri di tutti i livelli di competenza di creare facilmente applicazioni di intelligenza artificiale di grande impatto.

“Entro il 2025, lo stack tecnologico tradizionale continuerà a crollare, alimentato da API e strumenti che riducono la complessità e consentono uno sviluppo più rapido”, spiega Sewrathan. “Le aziende che offrono soluzioni accessibili e senza attrito, con basse barriere all’ingresso, permetteranno agli ingegneri di creare applicazioni di IA di grande impatto, indipendentemente dal loro livello di competenza”.

Questa democratizzazione della creazione di applicazioni di IA dovrebbe aumentare la concorrenza all’interno del settore, poiché un maggior numero di sviluppatori avrà accesso a funzionalità avanzate. Anche la coerenza e l’affidabilità delle applicazioni di IA sono destinate a diventare fondamentali.

“Poiché nel 2025 le applicazioni di IA diventeranno centrali nelle interazioni quotidiane, la coerenza e l’affidabilità avranno la precedenza”, osserva Sewrathan.

Evoluzione del ruolo dello sviluppatore

Indu Keri, General Manager e Head of Engineering for Hybrid Cloud di Nutanix, prevede una nuova era dello sviluppo software a partire dal 2025.

“Lo sviluppo e la progettazione del software sono già in fase di democratizzazione grazie a strumenti come Copilot”, afferma Keri.

Combinando GenAI con soluzioni low-code, il codice sarà astratto fino a diventare irrilevante. L’intelligenza artificiale genererà applicazioni piuttosto che codice, consentendo agli sviluppatori di assumere ruoli strategici.

“La quotidianità degli sviluppatori cambierà drasticamente”, osserva Keri. “Non più ostacolati dal lavoro di routine, gli sviluppatori assumeranno un ruolo strategico di livello superiore, comunicando con i responsabili delle decisioni su come la tecnologia può risolvere i problemi aziendali”.

Questa evoluzione, sostiene Keri, integra le migliori qualità degli sviluppatori – creatività e innovazione – e li sfida a crescere in ruoli di leadership all’interno delle loro organizzazioni.

“Entro il 2025, gli ingegneri di qualsiasi livello saranno in grado di creare un’applicazione di intelligenza artificiale grazie alla disponibilità diffusa di API e modelli”, aggiunge Sewrathan. “Ma i fattori di differenziazione saranno la coerenza, l’usabilità e l’impatto sui clienti”.

IA agenziale e automazione DevOps

Il clamore attorno all’AI agenziale raggiungerà il punto di ebollizione nel 2025, quando le organizzazioni raggrupperanno agenti specializzati per le diverse fasi di consegna del software, tra cui la generazione del codice, i test e il controllo qualità. Questo approccio guidato dagli orchestratori porterà a un approccio più intelligente all’automazione DevOps.

Martin Reynolds, Field CTO di Harness, afferma: “Invece di avere un unico assistente GenAI di base, le organizzazioni raggrupperanno agenti specializzati per le diverse fasi della consegna del software, come la generazione del codice, i test e il controllo qualità”.

“Un agente fungerà da orchestratore, dirigendo gli altri e producendo approfondimenti più accurati sul processo end-to-end”.

Rodrigo Coutinho di OutSystems sottolinea che l’intelligenza artificiale agenziale risponderà a molti, ma non a tutti, i problemi aziendali: “Negli ultimi anni, le aziende hanno tentato di affrontare tutti i loro problemi con la GenAI. Il risultato: GenAI è una soluzione notevole per molti casi d’uso, ma non per tutti”.

“Uno strumento di IA è buono solo quanto i dati su cui viene addestrato. Il fatto che i giganti della tecnologia stiano spingendo l’IA agenziale in questo momento non significa che si debbano scartare le soluzioni più semplici. Allineate la vostra strategia di IA alle esigenze della vostra organizzazione, piuttosto che all’ultimo oggetto luccicante”.

Integrazione di team di progettazione interfunzionali

Al di là dello sviluppo dell’IA, la previsione di team di ingegneria interfunzionali è un’altra area di cambiamento significativo. Reynolds delinea un futuro in cui i team DevOps autonomi saranno gradualmente eliminati a favore di gruppi più olistici che includono la rappresentanza di tutte le discipline ingegneristiche.

“Nel 2025, le organizzazioni abbandoneranno i team DevOps autonomi a favore di gruppi più olistici che includano la rappresentanza di tutte le discipline ingegneristiche”, spiega Reynolds.

Questo passaggio a team interfunzionali unificati dovrebbe eliminare i silos ancora esistenti tra i team di consegna del software e accelerare l’innovazione a un livello completamente nuovo. Per supportare questi team integrati, le organizzazioni adotteranno sempre più piattaforme unificate che forniranno funzionalità per l’intero ciclo di vita della consegna del software, dal CI/CD all’ingegneria del caos e alla gestione dei costi del cloud.

In linea con questi cambiamenti di piattaforma, Reynolds sottolinea l’importanza dei portali interni per sviluppatori (IDP) che consentono agli ingegneri di accedere autonomamente alle soluzioni e ai dati di cui hanno bisogno.

“Per massimizzare il valore di queste piattaforme”, consiglia Reynolds, ‘le organizzazioni esporranno queste funzionalità attraverso gli IDP’.

Evoluzione delle pratiche DevSecOps

Anche il panorama dello sviluppo software sta assistendo a una significativa evoluzione delle pratiche DevSecOps.

Dylan Thomas, Senior Director of Product Engineering di OpenText Cybersecurity, prevede che, entro il 2025, DevSecOps si evolverà oltre il paradigma “shift-left” per abbracciare un approccio più maturo “shift everywhere”.

Questo cambiamento richiederà alle organizzazioni di applicare gli strumenti giusti nelle fasi giuste del ciclo DevSecOps, migliorando l’efficienza e l’efficacia delle pratiche di sicurezza.

“L’analisi leggera negli IDE aiuterà gli sviluppatori a individuare tempestivamente i problemi”, spiega Thomas. “L’automazione integrata nelle richieste di pull e nelle pipeline CI/CD garantirà un approccio coesivo di ‘integrazione una volta sola’ per le funzioni principali come SAST, SCA e sempre più DAST, in particolare per i test di sicurezza delle API”.

Questa integrazione dovrebbe snellire il processo di sviluppo, migliorando al contempo la sicurezza generale.

L’emergere di xOps

La convergenza di DevOps, DataOps e ModelOps in un nuovo paradigma “xOps” è prevista man mano che un numero maggiore di applicazioni tradizionali adotterà le capacità dell’intelligenza artificiale.

“Questa nuova serie di dipendenze accelererà drasticamente la Release Orchestration ‘AI-aware’ e allo stesso tempo metterà alla prova i team operativi, i team di supporto, i team QA e altri ancora, poiché la linea di demarcazione tra le applicazioni dichiarative più tradizionali si confonderà con le nuove dipendenze dai LLM e dalle funzionalità GenAI”, spiega Derek Holt, CEO di Digital.ai.

Crescenti sfide per la sicurezza

Se da un lato il codice generato dall’intelligenza artificiale può aumentare significativamente l’efficienza degli sviluppatori, dall’altro introduce rischi per la sicurezza a causa dell’aumento del volume di codice che deve essere testato per individuare vulnerabilità ed errori.

“Sebbene la ricerca abbia dimostrato che l’IA generativa può dimezzare il tempo necessario agli sviluppatori per completare le attività di codifica, l’aumento del volume di codice prodotto deve comunque essere testato per individuare vulnerabilità ed errori”, avverte Holt.

“Questo aumenterà i rischi per la sicurezza e comporterà ulteriore fatica nelle fasi successive della consegna, vanificando qualsiasi guadagno di efficienza derivante dal codice generato dall’intelligenza artificiale”.

Negli ultimi anni si è registrato un notevole aumento degli attacchi alla catena di fornitura. È probabile che questo fenomeno continui nel 2025 e oltre.

Aaron Costello, responsabile della ricerca sulla sicurezza SaaS di AppOmni, osserva: “Negli ultimi anni abbiamo assistito a un aumento costante degli attacchi alla supply-chain SaaS attraverso applicazioni di terze parti compromesse. Di conseguenza, le organizzazioni stanno sottoponendo queste integrazioni e i livelli di accesso richiesti a un esame molto più accurato”.

“La mia ricerca sulle esposizioni dei dati ha dimostrato che spesso non è necessario un punto d’appoggio iniziale perché gli attori delle minacce possano accedere ai dati sensibili che desiderano. La combinazione di endpoint API legacy non documentati, accesso pubblico con privilegi eccessivi e lacune nelle capacità di registrazione dei fornitori continuerà a fornire agli attori delle minacce un’opzione pericolosamente efficace per eseguire attacchi di tipo “hit-and-run””.

L'articolo Tendenze e previsioni dello sviluppo software per il 2025 proviene da Webbare.

Immagini malevoli nell’ultimo attacco alla supply chain

admin — Wed, 17 Jul 2024 07:29:48 +0000

Una serie di pacchetti dannosi, camuffati da software legittimi, sono stati scoperti nel registro npm dalla società di cybersicurezza Phylum.

I pacchetti – identificati il 13 luglio 2024 – contenevano funzionalità nascoste di comando e controllo incorporate in file immagine, eseguite durante il processo di installazione.

I ricercatori di Phylum hanno scoperto due pacchetti in questa campagna, uno dei quali denominato “img-aws-s3-object-multipart-copy” imitava una libreria GitHub legittima. La versione dannosa includeva modifiche per eseguire un nuovo script chiamato “loadformat.js” al momento dell’installazione.

Il file loadformat.js, pur sembrando innocuo a prima vista, conteneva un codice sofisticato progettato per estrarre ed eseguire payload nascosti dai file immagine forniti con il pacchetto. L’analisi di Phylum ha rivelato che una di queste immagini, camuffata da logo Microsoft, conteneva codice dannoso in grado di stabilire una connessione con un server di comando e controllo.

“Nascondere i payload nelle immagini non è un concetto nuovo”, afferma Phylum nel suo rapporto. “Tuttavia, quando un aggressore cerca di nascondere i propri payload in modo così profondo, possiamo solo supporre che sia sofisticato e che operi con un chiaro intento malevolo”.

Il payload estratto comprendeva la funzionalità di registrazione delle macchine infette con il server dell’aggressore, il recupero e l’esecuzione periodica di comandi e la trasmissione dei risultati all’aggressore. Il server di comando e controllo è stato identificato come operante dall’indirizzo IP 85.208.108.29.

Particolarmente preoccupante è il periodo di tempo in cui questi pacchetti dannosi sono rimasti disponibili sul registro di npm.

“I pacchetti dannosi sono rimasti disponibili su npm per quasi due giorni”, ha osservato Phylum. “Questo dato è preoccupante perché implica che la maggior parte dei sistemi non è in grado di rilevare e segnalare tempestivamente questi pacchetti, lasciando gli sviluppatori vulnerabili agli attacchi per periodi di tempo più lunghi”.

Questo incidente mette in evidenza la crescente sofisticazione degli attacchi alla catena di approvvigionamento che prendono di mira gli ecosistemi open-source. Phylum sottolinea la necessità critica per gli sviluppatori e le organizzazioni di sicurezza di esercitare estrema cautela quando incorporano librerie open-source nei loro progetti.

Gli sviluppatori sono invitati ad aumentare la vigilanza e a migliorare l’uso delle capacità di rilevamento per combattere questi attacchi sempre più sofisticati alle catene di fornitura del software.

L'articolo Immagini malevoli nell’ultimo attacco alla supply chain proviene da Webbare.

Una vulnerabilità critica di OpenSSH minaccia milioni di sistemi Linux

admin — Wed, 10 Jul 2024 08:48:40 +0000

La Threat Research Unit (TRU) di Qualys ha scoperto una grave vulnerabilità nel server OpenSSH (sshd), che potenzialmente può interessare oltre 14 milioni di sistemi Linux in tutto il mondo. La falla, denominata CVE-2024-6387, consente l’esecuzione di codice non autenticato da remoto (RCE) con privilegi di root sui sistemi Linux basati su glibc.

Questa vulnerabilità, derivante da una race condition del gestore del segnale, colpisce sshd nella sua configurazione predefinita. I ricercatori di Qualys hanno identificato circa 700.000 istanze esterne vulnerabili rivolte a Internet tra i loro clienti globali, che rappresentano il 31% di tutte le istanze OpenSSH rivolte a Internet.

Ray Kelly, Fellow del Software Integrity Group di Synopsys, ha dichiarato: “Questa vulnerabilità è la più grave che ci sia. La tripletta di esecuzione di codice da remoto, accesso root e una distribuzione diffusa tra i server Linux ne fanno un bersaglio molto ghiotto per gli attori delle minacce”.

La scoperta è particolarmente allarmante perché rappresenta una regressione di una vulnerabilità precedentemente patchata (CVE-2006-5051) del 2006. Questa regressione è stata inavvertitamente introdotta nell’ottobre 2020 con OpenSSH 8.5p1, evidenziando l’importanza fondamentale di un accurato test di regressione nello sviluppo del software.

Le versioni di OpenSSH interessate includono quelle precedenti alla 4.4p1 (a meno che non siano state applicate le patch per CVE-2006-5051 e CVE-2008-4109) e le versioni dalla 8.5p1 fino alla 9.8p1, esclusa. In particolare, i sistemi OpenBSD non sono interessati da questa vulnerabilità grazie a un meccanismo di sicurezza sviluppato nel 2001.

L’impatto potenziale di questa vulnerabilità è grave. Se sfruttata, potrebbe portare alla completa compromissione del sistema, consentendo agli aggressori di eseguire codice arbitrario con privilegi di root. Ciò potrebbe portare all’installazione di malware, alla manipolazione dei dati e alla creazione di backdoor persistenti. Inoltre, i sistemi compromessi potrebbero essere utilizzati come trampolino di lancio per la propagazione della rete, aggirando potenzialmente i meccanismi di sicurezza critici.

Sebbene la vulnerabilità sia difficile da sfruttare a causa della sua natura di condizione di gara remota, i progressi nel deep learning potrebbero aumentare significativamente il tasso di successo degli attacchi in futuro.

Per ridurre i rischi, si consiglia alle aziende di:

Implementare una gestione immediata delle patch
Migliorare il controllo degli accessi per SSH
Utilizzare sistemi di segmentazione della rete e di rilevamento delle intrusioni.

OpenSSH, una suite di utilità di rete sicure basate sul protocollo SSH, è fondamentale per la comunicazione sicura su reti non sicure. È ampiamente utilizzato negli ambienti aziendali per la gestione di server remoti, il trasferimento sicuro di file e varie pratiche DevOps.

Nonostante questa battuta d’arresto, OpenSSH mantiene una solida reputazione in termini di sicurezza. Tuttavia, questo incidente serve a ricordare le continue difficoltà nel mantenere la sicurezza del software, anche per strumenti consolidati e ampiamente utilizzati.

Gli sviluppatori e gli amministratori di sistema sono invitati a rivedere le loro implementazioni di OpenSSH e ad applicare tempestivamente gli aggiornamenti necessari.

“Sebbene sia disponibile una patch per OpenSSH, la sua distribuzione su tutti i sistemi interessati – che potrebbe avere un impatto su 14 milioni di istanze OpenSSH – rappresenta una sfida significativa. Questa vulnerabilità potrebbe persistere a lungo, ricordando la vulnerabilità Heartbleed di OpenSSL del 2014”, spiega Kelly.

Con l’evolversi della situazione, la comunità della sicurezza informatica osserverà con attenzione la rapidità con cui questa vulnerabilità verrà affrontata e le implicazioni a lungo termine che potrebbe avere per OpenSSH e per altri software critici per la sicurezza.

L'articolo Una vulnerabilità critica di OpenSSH minaccia milioni di sistemi Linux proviene da Webbare.

Gli hacker sfruttano sempre più spesso i packer per diffondere il malware

admin — Wed, 12 Jun 2024 13:16:08 +0000

I ricercatori di Cybersecurity di Check Point hanno scoperto una tendenza crescente degli hacker a sfruttare strumenti commerciali di imballaggio come BoxedApp per nascondere e distribuire vari ceppi di malware. Nell’ultimo anno è stato osservato un aumento significativo dell’abuso dei prodotti BoxedApp, in particolare negli attacchi rivolti a istituzioni finanziarie e organizzazioni governative.

BoxedApp offre una serie di packer commerciali, tra cui BoxedApp Packer e BxILMerge, che forniscono funzionalità avanzate come l’archiviazione virtuale (file system virtuale, registro virtuale), i processi virtuali e un sistema di strumentazione universale (aggancio API WIN/NT). Sebbene questi strumenti siano stati progettati per scopi legittimi, gli attori delle minacce li hanno sfruttati per confezionare payload dannosi, eludere il rilevamento e rendere più difficili le attività di analisi.

Secondo le indagini dei ricercatori, i principali prodotti BoxedApp abusati sono BoxedApp Packer e BxILMerge, entrambi costruiti sopra l’SDK di BoxedApp. Questi prodotti garantiscono agli attori delle minacce l’accesso alle funzionalità più avanzate dell’SDK, consentendo loro di creare packer personalizzati e unici che sfruttano funzionalità all’avanguardia pur rimanendo abbastanza diversi da evitare il rilevamento statico.

I vantaggi derivanti dall’utilizzo delle funzionalità avanzate ed esclusive offerte da BoxedApp SDK superano gli svantaggi derivanti dall’utilizzo di un packer commerciale noto. Tra le caratteristiche e le capacità più importanti vi sono il File System Virtuale, il Registro Virtuale, i Processi Virtuali (PE Injection), l’SDK per l’aggancio delle API WIN/NT, il packing generale (distruzione delle importazioni PE originali, compressione, ecc.), la produzione di bundle di singoli file e la garanzia che tutto l’I/O verso lo storage virtuale rimanga in memoria senza scaricare i file su disco.

Sebbene i prodotti BoxedApp siano disponibili da diversi anni, il loro abuso per scopi dannosi è aumentato in modo significativo nell’ultimo anno, senza che finora sia stato riconosciuto pubblicamente il loro legame con BoxedApp. Sebbene l’uso di packer commerciali abbia sia pro che contro per gli aggressori, le capacità avanzate che forniscono sembrano superare i potenziali svantaggi.

I vantaggi dell’utilizzo dei prodotti BoxedApp per la distribuzione di malware includono:

Prodotti affidabili e pronti all’uso con funzionalità avanzate
SDK BoxedApp disponibile per la creazione di packer personalizzati e diversificati
Sistema di archiviazione virtuale proprietario (Virtual File System, Virtual Registry)
Creazione di processi virtuali per l’iniezione di PE
SDK semplice per agganciare le API WIN/NT
Impacchettamento generale (distrugge le importazioni di PE originali, esegue la compressione, ecc.)
Produzione di bundle a file singolo con tutte le dipendenze in Virtual Storage
Tutto l’I/O verso il Virtual Storage rimane in memoria, evitando cadute di file su disco
Difficoltà nel distinguere le applicazioni impacchettate regolari da quelle dannose (alto tasso di falsi positivi).

I contro includono:

Facile rilevamento statico dei prodotti BoxedApp originali utilizzati per il confezionamento
Rilevamento statico generico di alcune funzionalità dell’SDK comunemente utilizzate per scopi dannosi (ad esempio, aggancio di API WIN/NT, iniezione di processi virtuali – PE).
Alto tasso di rilevamento di falsi positivi per le applicazioni non dannose confezionate da BoxedApp

Nonostante l’elevato tasso di falsi positivi, che potrebbe causare discrepanze e innescare rilevamenti anche per applicazioni non dannose, Windows Defender integrato e altre soluzioni antivirus di alto livello non sono in genere interessati.

I ricercatori hanno analizzato circa 1.200 campioni di BoxedApp inviati a VirusTotal negli ultimi tre anni ed elaborati con successo dalle sandbox VT. È allarmante notare che il 25% di questi campioni è stato rilevato come dannoso in base al loro comportamento. La cronologia di invio a VirusTotal di questi campioni dannosi mostra una tendenza crescente all’abuso di BoxedApp per la distribuzione di malware.

Tra le famiglie di malware più comunemente distribuite vi sono RAT (Trojan ad accesso remoto) come QuasarRAT, NanoCore, NjRAT, Neshta, AsyncRAT e LodaRAT, nonché stealers come RevengeRAT, AgentTesla, RedLine e Remcos. Inoltre, sono stati rilevati casi di ransomware come LockBit.

I ricercatori hanno condotto un’analisi approfondita degli interni di BoxedApp, concentrandosi sulle strutture binarie risultanti confezionate da diversi prodotti. Questa analisi ha fornito spunti per disimballare il Virtual Storage e ricostruire i principali binari dannosi. Sono state inoltre fornite le firme Yara per aiutare a rilevare staticamente il packer in uso, distinguendo al contempo il prodotto specifico utilizzato.

L'articolo Gli hacker sfruttano sempre più spesso i packer per diffondere il malware proviene da Webbare.

Sonatype espone il pacchetto PyPI dannoso “pytoileur”

admin — Wed, 29 May 2024 15:35:51 +0000

Sonatype ha scoperto “pytoileur”, un pacchetto PyPI dannoso progettato per scaricare e installare binari Windows troianizzati in grado di sorvegliare, requisire la persistenza e rubare criptovalute. Questa scoperta fa parte di una campagna più ampia, durata mesi, denominata “Cool package”, volta a infiltrarsi nella comunità dei codificatori.

Ieri, un sistema di rilevamento automatico di malware gestito da Sonatype, noto come Sonatype Repository Firewall, ha segnalato un pacchetto PyPI appena pubblicato chiamato “pytoileur”. Il pacchetto dannoso, rintracciato come sonatype-2024-1783, aveva registrato 264 download dal suo rilascio prima che Sonatype avvertisse gli amministratori di PyPI di rimuoverlo.

Il pacchetto si descriveva come “pacchetto cool”, con una descrizione HTML che affermava che si trattava di “uno strumento di gestione delle API scritto in Python”. È interessante notare che includeva un riferimento a “pystob”, un pacchetto ormai defunto, indicando un tentativo di typosquatting per ingannare gli utenti di pacchetti legittimi come “Pyston”.

A prima vista, il file “setup.py” all’interno di “pytoileur” sembrava pulito, ma Jeff Thornhill, ricercatore di sicurezza di Sonatype, ha scoperto del codice maligno abilmente nascosto con spazi bianchi eccessivi.

“Sebbene la codifica base64 sia piuttosto standard nelle applicazioni e non offra molto in termini di mascheramento del codice dannoso, l’autore ha tentato di ‘nascondere’ questa particolare stringa codificata alla revisione umana manuale iniettandola dopo un’istruzione di stampa e includendo un paragrafo di spazi bianchi prima del codice”, ha spiegato Thornhill.

Il payload codificato in base64 è stato progettato per colpire gli utenti di Windows. Utilizzava comandi Python per scaricare un eseguibile dannoso da un server esterno (hxxp://51.77.140[.]144:8086/dl/runtime). Il binario dannoso, “Runtime.exe”, viene eseguito utilizzando comandi Windows PowerShell e VBScript. Questo eseguibile impiega misure anti-rilevamento per evitare i controlli e installa spyware aggiuntivi in grado di persistere, tra cui funzionalità di furto di informazioni e crypto-jacking.

Ax Sharma, ricercatore di Sonatype, ha scoperto che l’attore delle minacce dietro il pacchetto PyPI dannoso “pytoileur” sta pubblicando risposte false su StackOverflow, invitando le persone a installare il pacchetto dannoso.

Questa preoccupazione è amplificata dalla grande presenza di sviluppatori alle prime armi su StackOverflow, che stanno ancora imparando e potrebbero essere vittime di consigli dannosi.

Ulteriori indagini hanno rivelato che “pytoileur” fa parte di una campagna più ampia legata a pacchetti dannosi identificati in precedenza. Questi pacchetti, spesso descritti semplicemente come “Cool package”, hanno utilizzato tecniche di inganno simili dal 2023. Si camuffano da strumenti di gestione delle API o da versioni semplificate di utility ben note, prendendo di mira gli sviluppatori di varie nicchie, tra cui l’intelligenza artificiale e l’apprendimento automatico.

Uno dei pacchetti precedenti, “gpt-requests”, che sembrava rivolto agli sviluppatori di IA, nascondeva anche i payload dannosi utilizzando gli spazi bianchi. Simili a “pytoileur”, questi payload scaricano binari troianizzati destinati allo spionaggio e al furto di dati.

Il pacchetto “lalalaopti” è particolarmente degno di nota perché conteneva moduli di codice Python in chiaro per il dirottamento degli appunti, il keylogging, l’accesso remoto alla webcam e la cattura degli screenshot, evidenziando ulteriormente l’intento malevolo degli attori delle minacce dietro questa campagna.

I ricercatori di Sonatype e Checkmarx hanno identificato diversi pacchetti dannosi collegati a questa campagna, tra cui:

gogogolokl
gpt-richieste
kokokoako
lalalaopti
pybowl
pyclack
pyefflorer
pyhjdddo
pyhulul
piioapso
pyjio
pyjoul
pykokalalz
pykooler
pyktrkatoo
pilone
piminor
piowler
pipiele
pystallerer
pistob
pytarlooko
pytasler
pitoileur
pywolle
pywool

La ricomparsa della campagna “Cool package” attraverso “pytoileur” dimostra la persistenza delle minacce poste da attori malintenzionati negli ambienti di sviluppo software. In presenza di minacce simili, Sonatype dichiara che continuerà a espandere le proprie blocklist e a salvaguardare la comunità degli sviluppatori.

L'articolo Sonatype espone il pacchetto PyPI dannoso “pytoileur” proviene da Webbare.

Phylum scopre un malware mirato camuffato in un pacchetto Python

admin — Wed, 22 May 2024 11:58:05 +0000

Gli esperti di cybersicurezza di Phylum hanno individuato un payload dannoso incorporato in un popolare pacchetto Python sul repository PyPI. Il pacchetto, denominato requests-darwin-lite, è una variante non autorizzata della libreria requests, ampiamente utilizzata.

Il pacchetto requests-darwin-lite è stato abilmente progettato per emulare la sua controparte legittima, ma includeva un binario Go nascosto in un file immagine sovradimensionato che fingeva di essere un semplice logo. Questo file – un PNG etichettato come immagine della barra laterale – pesava insolitamente circa 17 MB, in netto contrasto con le dimensioni normali di circa 300 kB della versione autentica.

Durante l’installazione del pacchetto, se l’ambiente di installazione era macOS, veniva attivata una classe di comando specializzata “PyInstall”. Questa classe esegue un comando codificato in base64 che estrae l’UUID (Universal Unique Identifier) del sistema.

Il codice verificava la presenza di un UUID specifico, indicando un attacco altamente mirato. Se l’UUID non corrispondeva, l’installazione proseguiva senza distribuire il malware. Ciò suggerisce che gli aggressori stavano testando la distribuzione o avevano in mente un obiettivo molto specifico.

Quando le condizioni erano soddisfatte, il file PNG sovradimensionato veniva elaborato per estrarre il binario nascosto, che veniva poi reso eseguibile ed eseguito in background, dando di fatto agli aggressori il controllo del computer. L’analisi dei file ha identificato il binario come un componente di OSX/Silver, un framework C2 (comando e controllo) simile a Cobalt Strike, ma meno conosciuto e quindi con minori probabilità di essere rilevato.

Phylum ha notato che le versioni precedenti di questo pacchetto includevano il gancio di installazione dannoso e il binario impacchettato. Tuttavia, le versioni successive – identificate come 2.28.0 e 2.28.1 – hanno ridotto queste caratteristiche aggressive; la prima non esegue più il binario al momento dell’installazione e la seconda è del tutto priva dei componenti dannosi.

La scoperta ha provocato una segnalazione immediata a PyPI, che ha portato alla rimozione di tutte le versioni del pacchetto dal repository. Questa sequenza di eventi sottolinea la necessità di vigilare nella comunità open-source, dove la confusione delle dipendenze e gli attacchi mirati stanno diventando sempre più sofisticati.

Questo incidente ci ricorda che gli aggressori continuano ad evolvere i loro metodi per sfruttare gli ecosistemi open-source, sfruttando pacchetti apparentemente innocenti per distribuire malware. È necessario aumentare la consapevolezza e le misure preventive in tutta la comunità tecnologica per salvaguardarsi da questi attacchi.

L'articolo Phylum scopre un malware mirato camuffato in un pacchetto Python proviene da Webbare.

PyPI sospende le registrazioni a causa di un attacco di malware

admin — Wed, 03 Apr 2024 08:18:31 +0000

Il Python Package Index (PyPI) ha sospeso la creazione di nuovi progetti e la registrazione degli utenti per mitigare una campagna di upload di malware in corso. Questa mossa arriva dopo che i ricercatori di sicurezza di Checkmarx hanno scoperto una campagna che coinvolge più pacchetti dannosi legati agli stessi attori della minaccia.

Gli aggressori stanno prendendo di mira le vittime attraverso attacchi di typosquatting, inducendo gli utenti a installare pacchetti Python dannosi attraverso la loro interfaccia a riga di comando. Questo attacco in più fasi mira a rubare portafogli di criptovalute, dati sensibili del browser come cookie e dati delle estensioni e varie credenziali.

Il payload dannoso impiega anche un meccanismo di persistenza per sopravvivere ai riavvii del sistema, garantendo l’accesso continuo alle macchine compromesse.

Pacchetti maligni di typosquatting

Tra il 27 e il 28 marzo 2024, diversi pacchetti Python dannosi sono stati caricati su PyPI, probabilmente utilizzando strumenti di automazione. Questi pacchetti contenevano codice maligno all’interno dei loro file setup.py, consentendo l’esecuzione automatica al momento dell’installazione.

I file setup.py contenevano codice offuscato e crittografato utilizzando il modulo di crittografia Fernet. Al momento dell’installazione, questo codice veniva eseguito, innescando il recupero di un payload aggiuntivo da un server remoto. L’URL del payload è stato costruito dinamicamente aggiungendo il nome del pacchetto come parametro di query.

Una volta decriptato, il payload recuperato ha rivelato un ampio info-stealer progettato per raccogliere informazioni sensibili dal computer della vittima, tra cui portafogli di criptovalute, dati del browser e credenziali.

In risposta alla campagna di malware, PyPI ha temporaneamente sospeso la creazione di nuovi progetti e la registrazione di nuovi utenti. Questa misura mira a mitigare la minaccia in corso mentre l’organizzazione indaga e affronta il problema.

L’elenco completo dei pacchetti scoperti da Checkmarx è disponibile qui.

L'articolo PyPI sospende le registrazioni a causa di un attacco di malware proviene da Webbare.