Cyber Security Archivi - 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.

I difetti di CocoaPods evidenziano i crescenti rischi della catena di approvvigionamento

admin — Wed, 03 Jul 2024 12:03:53 +0000

I ricercatori di sicurezza di E.V.A Information Security hanno scoperto diverse vulnerabilità critiche in CocoaPods, un popolare gestore di dipendenze per progetti Swift e Objective-C. Queste vulnerabilità espongono potenzialmente milioni di dispositivi Apple ad attacchi alla catena di distribuzione, evidenziando i crescenti rischi associati alle dipendenze del software open-source.

CocoaPods, utilizzato in oltre tre milioni di app mobili, svolge un ruolo cruciale nell’ecosistema di sviluppo di iOS e macOS. Le falle scoperte potrebbero consentire agli aggressori di rivendicare la proprietà di pacchetti orfani, di eseguire codice arbitrario sul server “Trunk” di CocoaPods e di effettuare acquisizioni di account senza clic.

Dettagli della vulnerabilità:

Proprietà non autorizzata di pod orfani (CVE-2024-38368): Gli aggressori potrebbero rivendicare la proprietà di uno qualsiasi dei 1.866 pod orfani, iniettando potenzialmente codice dannoso in pacchetti ampiamente utilizzati.
Esecuzione di codice remoto sul server “Trunk” (CVE-2024-38366): Un difetto nel processo di verifica delle e-mail potrebbe consentire agli aggressori di eseguire codice arbitrario sul server che gestisce la distribuzione dei pacchetti.
Acquisizione dell’account senza clic (CVE-2024-38367): Sfruttando l’intestazione X-Forwarded-Host e gli strumenti di sicurezza delle e-mail, gli aggressori potrebbero ottenere un accesso non autorizzato agli account degli sviluppatori.

Le vulnerabilità interessano una parte significativa dell’ecosistema delle applicazioni Swift e Objective-C, con un potenziale impatto su migliaia o milioni di app su iOS, macOS e altre piattaforme Apple. Aziende importanti come Google, GitHub, Amazon e Dropbox gestiscono progetti che potrebbero essere a rischio a causa di queste falle.

“Molti di questi Pod non reclamati sono ancora ampiamente utilizzati. Abbiamo trovato menzioni di Pod orfani nella documentazione o nei termini di servizio delle applicazioni fornite da Meta (Facebook, WhatsApp), Apple (Safari, AppleTV, Xcode) e Microsoft (Teams); così come in TikTok, Snapchat, Amazon, LinkedIn, Netflix, Okta, Yahoo, Zynga e molti altri”, spiegano i ricercatori di E.V.A Information Security.

Le potenziali conseguenze di queste vulnerabilità sono gravi. I malintenzionati potrebbero potenzialmente accedere alle informazioni sensibili degli utenti, compresi i dati delle carte di credito e le cartelle cliniche, causando attacchi ransomware, frodi o spionaggio aziendale.

Si consiglia agli sviluppatori e alle organizzazioni che utilizzano CocoaPods, soprattutto prima di ottobre 2023, di prendere provvedimenti immediati:

Esaminare gli elenchi delle dipendenze e convalidare le checksum delle librerie di terze parti.
Eseguire scansioni di sicurezza per rilevare codice dannoso o modifiche sospette.
Mantenere il software aggiornato e limitare l’uso di pacchetti orfani o non mantenuti.
Implementare revisioni di sicurezza approfondite del codice di terze parti.
Verificare che non siano in uso Pod orfani.
Assicurarsi che le dipendenze di terze parti siano mantenute attivamente con una chiara proprietà.

Il team di CocoaPods è stato informato di queste vulnerabilità e ha provveduto a correggerle. Tuttavia, l’incidente serve a ricordare i rischi associati all’affidarsi pesantemente alle dipendenze open-source e l’importanza di mantenere la vigilanza sulla sicurezza della catena di approvvigionamento del software.

Questa scoperta sottolinea la necessità per gli sviluppatori di rimanere consapevoli delle potenziali conseguenze dell’integrazione di codice di terze parti nelle loro applicazioni. Poiché le catene di fornitura del software diventano sempre più complesse, la comprensione della composizione del codice delle applicazioni e la garanzia della validità delle dipendenze open-source sono fondamentali.

Sebbene non vi siano prove dirette di sfruttamento di queste vulnerabilità, il potenziale impatto su milioni di dispositivi Apple in tutto il mondo richiede un approccio proattivo alla sicurezza. Gli sviluppatori sono invitati a implementare le strategie di mitigazione consigliate e a tenersi informati sullo stato di sicurezza dei loro strumenti di gestione delle dipendenze.

L'articolo I difetti di CocoaPods evidenziano i crescenti rischi della catena di approvvigionamento 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.

Rafforzare la sicurezza delle app con l’aiuto di Terraform

admin — Wed, 24 Apr 2024 08:11:57 +0000

Punto fermo degli stack tecnologici DevOps, Terraform è uno strumento di provisioning e gestione dell’Infrastructure-as-Code (IaC) sviluppato da HashiCorp. Sebbene Terraform sia raramente associato alla sicurezza delle applicazioni e non sia direttamente correlato alla sicurezza e alla protezione informatica delle applicazioni, il suo corretto utilizzo è fondamentale per l’implementazione delle best practice di sicurezza.

Poiché DevOps continua a trasformarsi in DevSecOps e gli attacchi alla supply chain continuano a violare i sistemi aziendali, l’uso di Terraform in un’ottica di sicurezza è fondamentale per proteggere gli ambienti cloud.

Un modo particolarmente utile per massimizzare la sicurezza delle app quando si usa Terraform è l’integrazione di Open Policy Agent (OPA) quando si creano criteri di sicurezza come codice. OPA funge da esecutore delle policy scritte come codice. Aggiunge a Terraform la capacità di valutare le configurazioni dell’infrastruttura rilevanti per la sicurezza.

OPA facilita la valutazione dei piani di Terraform per rilevare le configurazioni errate della sicurezza durante il ciclo di sviluppo, soprattutto nella parte iniziale e vicino alla fase di distribuzione. In questo modo si garantisce che l’infrastruttura non ancora ritenuta sicura non venga fornita, impedendo l’esposizione delle applicazioni alle vulnerabilità. Inoltre, OPA mette in atto dei guardrail per l’infrastruttura basati su policy, come la segnalazione di regole di ingresso “troppo permissive” o poco rigorose.

Inoltre, OPA supporta l’integrazione con le pipeline CI/CD, consentendo alle organizzazioni di applicare in modo coerente e automatico i criteri di sicurezza. Blocca i piani Terraform che sono considerati in violazione delle politiche di sicurezza esistenti.

OPA aiuta le organizzazioni a spostare a sinistra il loro approccio alla sicurezza, in quanto fornisce un modo proattivo di condurre test di sicurezza, a vantaggio della sicurezza delle app.

In Terraform, il looping è la capacità di generare automaticamente diverse risorse o moduli. Viene utilizzato quando si creano diversi record DNS, si distribuiscono più istanze in diverse zone di disponibilità e si gestiscono più account utente.

Il looping è utile perché riduce la necessità di scrivere ripetutamente lo stesso blocco di risorse, che è l’obiettivo dell’efficienza IaC. Questo approccio consente agli ingegneri di creare istanze su base dinamica, in quanto disaccoppia la logica di creazione di più risorse dalle configurazioni specifiche.

Essendo un meccanismo di automazione dell’infrastruttura, il looping di Terraform non ha necessariamente un impatto diretto sulla sicurezza delle applicazioni. Tuttavia, il modo in cui viene eseguito il looping può influire sulla sicurezza delle applicazioni. Per questo è importante che il looping sia gestito con cautela. Nel caso del ciclo “for_each” di Terraform, ad esempio, è importante sottolineare la gestione sicura dei dati, evitando di memorizzare dati sensibili come password e chiavi API all’interno del ciclo for_each.

Inoltre, è fondamentale rivedere la logica dei cicli per assicurarsi che l’iterazione sulla struttura di dati prevista proceda come previsto e che gli errori siano risolti. Inoltre, è consigliabile osservare il principio del minimo privilegio, le regole di ingresso e di uscita appropriate e un adeguato controllo e revisione delle versioni.

L’hardening della configurazione, come suggerisce l’espressione, consiste nell’ottenere impostazioni dell’infrastruttura ottimizzate (e possibilmente regolate e riadattate) per ottenere la configurazione più adatta a ridurre al minimo i problemi di sicurezza. Comporta la conformità alle best practice o alle linee guida di sicurezza che possono essere applicate tramite Terraform. Ad esempio, alcuni fornitori di cloud possono consigliare di disabilitare i servizi inutilizzati su una specifica immagine di macchina virtuale. Terraform può essere impostato in modo da configurare automaticamente l’immagine, al momento del provisioning, per disabilitare i servizi inutilizzati fin dall’inizio.

D’altra parte, i moduli di Terraform possono supportare la sicurezza delle applicazioni grazie al loro ruolo nella costruzione di un ambiente applicativo sicuro. Questi moduli consentono il concetto di security-by-design e promuovono l’applicazione coerente delle pratiche di sicurezza grazie alle configurazioni di sicurezza in essi incorporate.

I moduli Terraform facilitano anche l’integrazione di strumenti di sicurezza, come gli scanner di sicurezza, che vengono distribuiti automaticamente con le risorse dell’infrastruttura. Inoltre, i moduli aiutano a controllare la possibilità di fuga di vulnerabilità che possono emergere a causa di configurazioni errate.

Terraform è dotato di una funzione di gestione dei dati sensibili che può rafforzare in modo significativo la sicurezza delle applicazioni, anche se indirettamente. Questo strumento IaC consente di ridurre al minimo i rischi di esposizione delle credenziali e di migliorare la verificabilità e la conformità.

Terraform supporta la gestione sicura dei segreti, consentendo di evitare di incorporare credenziali e segreti come le chiavi API nel codice stesso di Terraform. I dati sensibili possono essere contenuti in sistemi di controllo delle versioni, nel Vault di HashiCorp o in strumenti di gestione dei segreti di terze parti, per garantire che l’accesso al codice IaC non significhi automaticamente accesso ai dati sensibili.

A volte le organizzazioni memorizzano le credenziali delle app nel loro codice IaC, soprattutto quelle che sono nuove al provisioning e alla gestione IaC. Terraform offre modi per evitare di farlo. Inoltre, le funzioni di gestione dei dati di Terraform, insieme all’uso delle variabili d’ambiente, supportano i requisiti di conformità della sicurezza dei dati e migliorano la verificabilità.

La sicurezza dell’infrastruttura contribuisce in modo significativo alla creazione di posture di sicurezza delle app affidabili. Una gestione meticolosa dell’IaC riduce al minimo le configurazioni errate e i problemi di sicurezza che, a loro volta, contribuiscono a ridurre le superfici di attacco e le vulnerabilità. Gli attori delle minacce avranno difficoltà a compromettere le app o a sfruttare le vulnerabilità a livello di applicazione se l’infrastruttura è costruita con pratiche di sicurezza solide.

Anche in questo caso, Terraform non è progettato per garantire la sicurezza delle applicazioni e non ha strumenti o funzioni specifiche che proteggano direttamente le applicazioni stesse. Tuttavia, può aiutare a stabilire le basi per la sicurezza delle applicazioni, in particolare il rilevamento e la risoluzione di configurazioni errate, l’integrazione di un agente di sicurezza, le migliori pratiche di sicurezza del cloud e la gestione dei dati sensibili.

Terraform non è destinato esclusivamente al cloud, ma la maggior parte dei suoi utenti tende ad avere a che fare con ambienti ibridi e multi-cloud. È perfettamente sensato allineare la sicurezza di Terraform con le raccomandazioni di sicurezza stabilite dai fornitori di servizi cloud e dagli esperti di sicurezza, principalmente i benchmark CIS, l’hardening della configurazione e la sicurezza dei moduli.

I benchmark CIS si riferiscono all’insieme di best practice pubblicate dal Center for Internet Security (CIS). Queste best practice si applicano ai prodotti di oltre 25 fornitori e, sebbene questi benchmark siano destinati principalmente alla sicurezza dell’infrastruttura cloud sottostante, la loro osservanza offre vantaggi anche per la sicurezza delle applicazioni. Questi vantaggi includono la riduzione delle superfici di attacco informatico che coinvolgono le app, la mitigazione delle vulnerabilità di configurazione errata e la creazione di una base sicura per lo sviluppo delle app.

L'articolo Rafforzare la sicurezza delle app con l’aiuto di Terraform proviene da Webbare.

GitHub, oltre 100.000 repository infetti

admin — Wed, 06 Mar 2024 13:11:34 +0000

Gli sviluppatori si trovano di fronte a una grave minaccia per la sicurezza: oltre 100.000 repository su GitHub sono stati infettati con codice malevolo.

La recrudescenza di una campagna di confusione di repo maligni – rilevata dai ricercatori di sicurezza di Apiiro – ha colpito innumerevoli sviluppatori che utilizzano inconsapevolmente repository che ritengono affidabili ma che in realtà sono compromessi.

Simili agli attacchi di confusione delle dipendenze – che sfruttano i gestori di pacchetti – gli attacchi di confusione dei repository si basano sull’errore umano, inducendo gli sviluppatori a scaricare versioni dannose invece di quelle legittime.

I malintenzionati clonano i repository esistenti, li infettano con il malware, li caricano con nomi identici su GitHub e poi li biforcano automaticamente migliaia di volte, diffondendoli sul web attraverso forum e altri canali.

Una volta che gli sviluppatori utilizzano questi repository infetti, il payload nascosto scompone gli strati di offuscamento, eseguendo codice Python ed eseguibili binari dannosi. Questo codice modificato – spesso una versione di BlackCap-Grabber – raccoglie dati sensibili come le credenziali di accesso e le informazioni del browser, inviandoli al server di comando e controllo degli aggressori.

Mentre GitHub rimuove rapidamente la maggior parte dei repository biforcati, il rilevamento automatico non ne individua molti, permettendo a migliaia di persone di persistere.

Il processo di rimozione, che ha come obiettivo le bombe a forcella, avviene entro poche ore dal caricamento, rendendo difficile documentare la portata dell’attacco. L’enorme volume di repository coinvolti in questa campagna, unito alla loro automazione, rappresenta una sfida significativa per gli sforzi di rilevamento e mitigazione.

Questa campagna dannosa è iniziata nel maggio 2023 con la diffusione di pacchetti dannosi su PyPI e mette in evidenza una tendenza più ampia del malware che prende di mira le catene di fornitura del software. Con l’aumento dell’attenzione sui gestori di pacchetti, gli aggressori stanno spostando la loro attenzione sui gestori del controllo sorgente come GitHub.

L'articolo GitHub, oltre 100.000 repository infetti proviene da Webbare.

Scoperti alcuni Pacchetti Python che utilizzavano il sideloading DLL per aggirare la sicurezza

admin — Wed, 21 Feb 2024 14:12:49 +0000

I ricercatori di ReversingLabs hanno scoperto dei pacchetti Python che utilizzano il sideloading di DLL per aggirare gli strumenti di sicurezza.

Il 10 gennaio 2024, Karlo Zanki, un reverse engineer di ReversingLabs, si è imbattuto in due pacchetti sospetti sul Python Package Index (PyPI). Questi pacchetti, denominati NP6HelperHttptest e NP6HelperHttper, sono risultati utilizzare il sideloading di DLL, una tecnica nota utilizzata da attori malintenzionati per eseguire codice in modo discreto ed eludere il rilevamento da parte degli strumenti di sicurezza.

Questa scoperta sottolinea l’espansione del panorama delle minacce all’interno delle catene di fornitura del software, con attori malintenzionati che sfruttano le vulnerabilità negli ecosistemi open-source. L’incidente evidenzia le sfide che gli sviluppatori devono affrontare per verificare la qualità e l’autenticità dei moduli open-source, in un panorama vasto e in continua evoluzione di codice disponibile.

I pacchetti dannosi, camuffati con nomi molto simili a quelli legittimi, miravano a ingannare gli sviluppatori e a farli incorporare inconsapevolmente nei loro progetti. Questa tattica, nota come typosquatting, è solo uno dei tanti metodi utilizzati dagli aggressori per infiltrarsi nelle catene di fornitura del software legittimo.

Ulteriori indagini hanno rivelato che i pacchetti dannosi hanno preso di mira i pacchetti PyPI esistenti, NP6HelperHttp e NP6HelperConfig, originariamente pubblicati da un utente chiamato NP6. Mentre NP6 è associato a Chapvision, un’azienda di automazione del marketing, l’account PyPI in questione era collegato a un account personale di uno sviluppatore di Chapvision. La scoperta ha spinto Chapvision a confermare la legittimità degli strumenti di aiuto e a rimuovere successivamente i pacchetti dannosi da PyPI.

L’analisi dei pacchetti dannosi ha rivelato un approccio sofisticato, in cui uno script setup.py è stato utilizzato per scaricare sia i file legittimi che quelli dannosi. In particolare, la DLL dannosa – dgdeskband64.dll – è stata creata per sfruttare il sideloading delle DLL, una tecnica comunemente utilizzata dai criminali informatici per caricare codice dannoso eludendo il rilevamento.

Un ulteriore esame ha rivelato una campagna più ampia, con altri campioni che presentano caratteristiche simili. La piattaforma Titanium di ReversingLabs, utilizzando YARA Retro Hunt, ha identificato campioni correlati che indicano uno sforzo coordinato da parte degli attori delle minacce.

Il codice dannoso, incorporato nella DLL, utilizzava un gestore di eccezioni per eseguire shellcode, stabilendo una connessione con un server esterno per scaricare ed eseguire payload. L’indagine ha inoltre portato alla luce tracce di Cobalt Strike Beacon, uno strumento di sicurezza del Red Team riutilizzato dagli attori delle minacce per attività dannose.

Questa scoperta sottolinea la crescente sofisticazione degli attori maligni che sfruttano le infrastrutture open-source per le loro campagne. Evidenzia l’urgente necessità per gli sviluppatori e le organizzazioni di fortificare le loro catene di fornitura del software contro tali attacchi, sottolineando le misure proattive per garantire l’integrità e la sicurezza dei loro repository di codice.

L'articolo Scoperti alcuni Pacchetti Python che utilizzavano il sideloading DLL per aggirare la sicurezza proviene da Webbare.