Skip to content

Piero Bosio Social Web Site Personale Logo Fediverso

Social Forum federato con il resto del mondo. Non contano le istanze, contano le persone

Da qualche ora sto facendo delle scoregge orrende.

Uncategorized
21 10 0

Gli ultimi otto messaggi ricevuti dalla Federazione
  • @marco_fenice dobbiamo convincere gli astenuti di sinistra a tornare a votare che non si vota un partito ma per mantenere la democrazia

    read more

  • @ben nice! Enjoy.

    read more

  • "La del futuro è : tecnologia, consapevolezza e bene comune"
    BRICKS_7_2025_21_Lovato

    https://www.rivistabricks.it/wp-content/uploads/2025/12/BRICKS_7_2025_21_Lovato.pdf

    read more

  • @aeva boosting this so it can harm more people

    read more

  • read more

  • Some of them don't even do any programming in assembly language.

    read more

  • Il lato oscuro del sandboxing Windows: vulnerabilità nel Brokering File System

    Microsoft ha introdotto circa due anni fa Win32 App Isolation, un meccanismo pensato per rafforzare l’isolamento delle applicazioni sui sistemi Windows client. In parallelo è stato rilasciato il Brokering File System (BFS), un driver incaricato di mediare l’accesso a file system, pipe e registro da parte delle applicazioni eseguite in ambienti isolati, rendendolo una componente potenzialmente interessante dal punto di vista della sicurezza.

    In questo contesto si colloca il CVE-2025-29970, una vulnerabilità di tipo use-after-free individuata nel driver bfs.sys, inizialmente scoperta da HT3Labs. L’analisi tecnica è stata condotta sulla versione 26100.4061 del driver e riguarda un errore nella gestione della memoria associata alle strutture interne di BFS.

    BFS nasce insieme ad AppContainer e successivamente ad AppSilo, con l’obiettivo di controllare le operazioni di I/O provenienti da contesti isolati. Per farlo utilizza una serie di strutture dati che consentono di applicare policy di accesso basate su utente, applicazione e percorso, garantendo al contempo buone prestazioni.

    Al centro di questo meccanismo c’è la PolicyTable, che memorizza le singole PolicyEntry in una tabella hash. Ogni PolicyEntry rappresenta una regola di accesso e include informazioni come il SID dell’utente, il SID dell’AppContainer e un riferimento a uno StorageObject, oltre a un contatore di riferimenti utilizzato per la gestione del ciclo di vita.

    Lo StorageObject contiene i dettagli sui percorsi regolati dalla policy e utilizza più strutture interne, tra cui una DirectoryBlockList, una lista concatenata che rappresenta file e sottodirectory associati alla policy. Questa lista viene allocata quando viene aperta una directory radice e popolata con una o più voci nel corso del tempo.

    La vulnerabilità CVE-2025-29970 emerge durante la fase di rimozione di una policy, in particolare nella funzione BfsCloseStorage. Durante la deallocazione della DirectoryBlockList, l’inizio della lista viene liberata all’interno del ciclo che scorre gli elementi, causando una dereferenziazione di memoria già liberata nel caso in cui la lista contenga più di una voce.

    Microsoft ha corretto il problema separando la logica di deallocazione. Con l’introduzione della funzione BfsCloseRootDirectory, tutti gli elementi della lista concatenata vengono liberati prima della deallocazione della sua testa, eliminando così la condizione di use-after-free alla radice.

    Dal punto di vista dello sfruttamento, la vulnerabilità offre margini limitati: il puntatore coinvolto non consente letture o scritture arbitrarie e la finestra temporale tra la liberazione della memoria e il suo riutilizzo è estremamente ridotta. Nonostante ciò, il caso conferma come driver legati al sandboxing restino una superficie d’attacco rilevante, soprattutto con l’aumento delle funzionalità di isolamento su Windows.

    L'articolo Il lato oscuro del sandboxing Windows: vulnerabilità nel Brokering File System proviene da Red Hot Cyber.

    read more

  • Il Professionista della Sicurezza Informatica sotto la Lente del Codice Penale

    L’inarrestabile metamorfosi delle tecnologie dell’informazione ha trasformato radicalmente i paradigmi di protezione dei beni giuridici. In un’epoca dove la robustezza delle infrastrutture critiche è diventata sinonimo di sicurezza nazionale, chi opera nella cybersecurity non è più un semplice tecnico ma un attore centrale investito di responsabilità che travalicano il perimetro dei bit per approdare nelle aule di giustizia. Come avvocato che da anni seziona i reati informatici in tribunale e come docente che cerca di trasmettere la dogmatica di questa materia, avverto l’urgenza di fare chiarezza su un punto fondamentale: oggi l’operatore IT non è solo il difensore del sistema ma può diventarne, per azione o per una fatale omissione, il responsabile legale davanti allo Stato.

    La mappatura dei ruoli e l’identificazione della posizione di garanzia


    L’Agenzia per la Cybersicurezza Nazionale ha adottato lo European Cybersecurity Skills Framework per classificare le figure professionali e questa non è una mera operazione burocratica. In sede giudiziaria, questa catalogazione funge da parametro per identificare quella che noi giuristi chiamiamo posizione di garanzia. Ogni ruolo porta con sé una specifica esposizione al rischio penale. Se pensiamo al CISO, ci troviamo di fronte al vertice della gestione della sicurezza. Ai sensi dell’articolo 40 del Codice Penale, non impedire un evento che si ha l’obbligo giuridico di evitare equivale a cagionarlo. Se un responsabile omette di segnalare vulnerabilità critiche o non richiede gli investimenti necessari pur consapevole del rischio imminente, potrebbe essere chiamato a rispondere degli effetti dannosi di un attacco come se lo avesse agevolato.

    Operatività tecnica e il rischio di condotte attive illecite


    Per le figure più operative come i Cybersecurity Architect o i Responder, il rischio è spesso legato alla condotta attiva. L’installazione di programmi di monitoraggio che possono essere interpretati come strumenti di intercettazione abusiva o la configurazione di backdoor non autorizzate integra fattispecie di reato se non supportata da una delega formale. Durante la gestione di un incidente, manovre di emergenza eccessivamente intrusive potrebbero causare il danneggiamento di dati o la violazione della segretezza delle comunicazioni. Ancora più delicata è la posizione del Digital Forensics Investigator. Un errore nella catena di custodia o l’alterazione di un supporto informatico può non solo invalidare un processo ma esporre il professionista ad accuse di falso o inquinamento probatorio.

    Il sottile confine del penetration testing e il valore del consenso


    L’articolo 615-ter c.p. rimane il pilastro della tutela del domicilio informatico e la sua interpretazione è più insidiosa di quanto sembri. La giurisprudenza della Cassazione ha chiarito che l’accesso è abusivo ogni volta che un soggetto pur dotato di credenziali legittime si trattiene nel sistema violando le disposizioni del titolare o agendo per scopi ontologicamente estranei alle finalità per cui il potere gli è stato conferito. Un amministratore di sistema che accede ai log di un collega per curiosità personale commette un reato anche se possiede tecnicamente le chiavi per farlo. In questi casi l’abuso della qualità di operatore costituisce un’aggravante che trasforma la procedibilità da querela a d’ufficio, rendendo l’azione penale inevitabile.

    Il penetration tester si trova in una posizione paradossale: la sua attività materiale è formalmente identica a un attacco criminale. L’unica scriminante che separa la sua condotta dal reato è il consenso dell’avente diritto previsto dall’articolo 50 del Codice Penale. Tuttavia questo consenso deve essere preventivo, informato e soprattutto specifico. Un tester che durante un’attività autorizzata decide autonomamente di estendere il raggio d’azione a una rete interna non inclusa nel contratto commette il reato di accesso abusivo.

    Affinché un professionista sia ritenuto penalmente responsabile per un data breach o un attacco ransomware, invece, la pubblica accusa deve dimostrare la sussistenza di un nesso di causalità ipotetica. Si deve cioè provare che se la misura di sicurezza omessa (come l’applicazione di una patch critica già disponibile) fosse stata adottata, l’evento con elevata probabilità non si sarebbe verificato. La colpa professionale si manifesta nell’ignorare i risultati di test di vulnerabilità o nella scelta di fornitori palesemente inadeguati per ragioni di risparmio. La Direttiva NIS 2 ha accentuato questo profilo eliminando lo scudo della sola responsabilità societaria e introducendo la responsabilità personale degli organi di gestione per l’inottemperanza agli obblighi di sicurezza.

    La rivoluzione della Legge 90 del 2024 e le nuove sfide dell’IA


    Il recente intervento legislativo ha inasprito le pene per l’accesso abusivo fino a dieci anni di reclusione se l’azione causa il danneggiamento del sistema o se colpisce infrastrutture di interesse pubblico. È stata inoltre introdotta un’aggravante specifica per l’estorsione commessa mediante reati informatici, un punto che tocca da vicino i CISO coinvolti nella gestione di trattative ransomware. A questo si aggiungono le nuove frontiere dell’intelligenza artificiale con il reato di diffusione illecita di contenuti generati tramite IA per trarre in inganno o causare danno. Per chi si occupa di sicurezza, l’uso di tecniche generative AI per simulazioni di social engineering deve essere ora più che mai autorizzato nei minimi dettagli per non incorrere nelle nuove sanzioni.

    La complessità di questo quadro impone al professionista moderno l’adozione di rigorose strategie di compliance. È fondamentale verbalizzare ogni richiesta di budget o di intervento tecnico negata dalla direzione per poter dimostrare in sede penale la propria mancanza di colpa. Per i consulenti, la chiave della sicurezza legale risiede nelle Rules of Engagement. Il contratto deve definire in modo puntuale indirizzi IP target, finestre temporali e tecniche escluse. La sicurezza informatica non è più una disciplina esclusivamente tecnica e la tolleranza verso la zona grigia della gestione IT si è azzerata. Solo agendo nel perimetro della legge l’esperto di cybersecurity può dirsi realmente al sicuro dai rischi intrinseci alla sua professione.

    L'articolo Il Professionista della Sicurezza Informatica sotto la Lente del Codice Penale proviene da Red Hot Cyber.

    read more
Post suggeriti
  • 0 Votes
    1 Posts
    0 Views
    "La #scuola del futuro è #Libera: tecnologia, consapevolezza e bene comune"BRICKS_7_2025_21_Lovatohttps://www.rivistabricks.it/wp-content/uploads/2025/12/BRICKS_7_2025_21_Lovato.pdf
  • 0 Votes
    1 Posts
    0 Views
    Il lato oscuro del sandboxing Windows: vulnerabilità nel Brokering File SystemMicrosoft ha introdotto circa due anni fa Win32 App Isolation, un meccanismo pensato per rafforzare l’isolamento delle applicazioni sui sistemi Windows client. In parallelo è stato rilasciato il Brokering File System (BFS), un driver incaricato di mediare l’accesso a file system, pipe e registro da parte delle applicazioni eseguite in ambienti isolati, rendendolo una componente potenzialmente interessante dal punto di vista della sicurezza.In questo contesto si colloca il CVE-2025-29970, una vulnerabilità di tipo use-after-free individuata nel driver bfs.sys, inizialmente scoperta da HT3Labs. L’analisi tecnica è stata condotta sulla versione 26100.4061 del driver e riguarda un errore nella gestione della memoria associata alle strutture interne di BFS.BFS nasce insieme ad AppContainer e successivamente ad AppSilo, con l’obiettivo di controllare le operazioni di I/O provenienti da contesti isolati. Per farlo utilizza una serie di strutture dati che consentono di applicare policy di accesso basate su utente, applicazione e percorso, garantendo al contempo buone prestazioni.Al centro di questo meccanismo c’è la PolicyTable, che memorizza le singole PolicyEntry in una tabella hash. Ogni PolicyEntry rappresenta una regola di accesso e include informazioni come il SID dell’utente, il SID dell’AppContainer e un riferimento a uno StorageObject, oltre a un contatore di riferimenti utilizzato per la gestione del ciclo di vita.Lo StorageObject contiene i dettagli sui percorsi regolati dalla policy e utilizza più strutture interne, tra cui una DirectoryBlockList, una lista concatenata che rappresenta file e sottodirectory associati alla policy. Questa lista viene allocata quando viene aperta una directory radice e popolata con una o più voci nel corso del tempo.La vulnerabilità CVE-2025-29970 emerge durante la fase di rimozione di una policy, in particolare nella funzione BfsCloseStorage. Durante la deallocazione della DirectoryBlockList, l’inizio della lista viene liberata all’interno del ciclo che scorre gli elementi, causando una dereferenziazione di memoria già liberata nel caso in cui la lista contenga più di una voce.Microsoft ha corretto il problema separando la logica di deallocazione. Con l’introduzione della funzione BfsCloseRootDirectory, tutti gli elementi della lista concatenata vengono liberati prima della deallocazione della sua testa, eliminando così la condizione di use-after-free alla radice.Dal punto di vista dello sfruttamento, la vulnerabilità offre margini limitati: il puntatore coinvolto non consente letture o scritture arbitrarie e la finestra temporale tra la liberazione della memoria e il suo riutilizzo è estremamente ridotta. Nonostante ciò, il caso conferma come driver legati al sandboxing restino una superficie d’attacco rilevante, soprattutto con l’aumento delle funzionalità di isolamento su Windows.L'articolo Il lato oscuro del sandboxing Windows: vulnerabilità nel Brokering File System proviene da Red Hot Cyber.
  • 0 Votes
    2 Posts
    0 Views
    Some of them don't even do any programming in assembly language.
  • 0 Votes
    2 Posts
    0 Views
    @dubito_ergo_sum caro vita melonihttps://www.milanotoday.it/attualita/in-coda-per-cibo-natale-pane-quotidiano-25-dicembre-2025.html