, , , , , , , ,

Disaster recovery & business continuity

di Jacopo Sabbadini

 

Solo negli ultimi due mesi vi sono stati diversi attacchi alle aziende italiane. SIAE, Regione Lazio, San Carlo, solo per citarne alcuni.

Recente è lo studio di Trend Micro che dimostra come l’Italia sia, ad oggi, il terzo paese più colpito da malware, al mondo, secondo solo a Stati Uniti e Giappone.

 

Per queste ragioni diventa imperativo adoperarsi, non importa quanto grande sia la propria azienda, per avere delle efficaci politiche di disaster recovery e business continuity.

Partiamo da una rapida definzione:

  • Per disaster recovery si intende la possibilità di riprendersi in maniera efficace da un evento atto a distruggere o compromettere gravemente la propria infrastruttura.
  • Per business continuity si intendono quella serie di procedure atte a mantenere attiva la propria infrastruttura durante un evento atto a compromettere l’infrastruttura.

Pietra angolare di ogni procedura di disaster recovery è una corretta politica di backup; questa deve essere pensata per essere automatica e sicura, in modo tale da evitare da un lato la perdita potenziale di dati, dall’altro il backup della minaccia stessa.
Per questa ragione si consiglia sempre di eseguire backup asincroni, in ridondanza su più unità, e solo dei file effettivamente importanti, mai dell’intero sistema; questo proprio per evitare di portarsi dietro, con il backup, anche un potenziale malware, rendendo quindi inutile la procedura stessa.

In aggiunta, i sistemi su cui vengono eseguiti i backup dovrebbero trovarsi su una rete particolare, non raggiungibile dalle altre, se non nel momento della copia dei dati o, in alternativa, completamente scollegati dalla rete.

Per quanto riguarda le procedure di business continuity  invece, il concetto principale è la ridondanza. Vanno previsti più sistemi, ridondanti tra di loro, in modo tale che se uno di questi sistemi dovesse trovarsi sotto attacco, esso possa essere velocemente scollegato e rimpiazzato da un altro; in questo modo si può garantire la continuità dei servizi, anche durante un incidente.

 

Essenziale è anche testare le sopracitate procedure. Un po’ come per le procedure antincendio, se le procedure di backup, disaster recovery e business continuity non vengono mai testate, non importa quanto queste possano essere sicure ed efficaci sulla carta, non può esserci garanzia di reale efficacia e funzionalità.
Una buona prassi è quella di simulare quindi, periodicamente, questi scenari, in modo tale che tutti i membri dell’azienda, grande o piccola che essa sia, siano a conoscenza dei propri ruoli, e possano agire in maniera efficace quando sarà necessario.

/da
, , , , , , , , ,

GDPR for dummies. Il modello organizzativo minimo per una PMI – Paperless compliance for free… almost.

Nonostante la protezione del dato e la cultura della sicurezza delle informazioni abbiano compiuto dei significativi passi in avanti negli ultimi anni, ancora oggi, molte piccole-medie imprese trovano difficoltà nell’implementare modelli di gestione della privacy anche basilari.

Molti continuano, ingiustamente, ad avere paura delle sanzioni previste dal Regolamento Europeo con l’effetto di produrre inutile carta senza aumentare il livello di consapevolezza, accountability e sicurezza. Da qui si producono inutili consensi controfirmati, lettere di incarico senza formare le risorse e burocratizzazione inutile di processi che potrebbero essere lineari, semplici e paperless.

Non penso sia un caso, dunque, che la protezione del dato continui erroneamente ad essere abbinata a burocrazia inutile quando essa potrebbe essere agevolmente gestita con pochi essenziali adempimenti.

Non me ne voglia chi ci ha prosperato con la paura delle salatissime multe e prodotto carta inutile; ma molte volte, per raggiungere un grado sufficiente di compliance, è sufficiente dotarsi di pochi piccoli accorgimenti ed effettuare pochi piccoli investimenti mirati, principalmente in misure di sicurezza e formazione delle risorse umane.

Sperando di ripetere l’ovvio, ribadisco che la “paperless compliance for free… almost” non può trovare applicazione, ad esempio, per realtà molto particolari che effettuano trattamenti ad alto rischio, anche se poco strutturate così come per realtà che trattano dati su larga scala o presentano rischi maggiori rispetto alla media.

Per affrontare il discorso relativo alla paperless compliance, è necessario tenere presente che il GDPR va letto partendo dall’articolo 1 per poi scorrere verso gli articoli finali abbinando, se possibile, la lettura dei considerando alla norma.

È oramai opinione consolidata fra gli esperti che il GDPR chiede di affrontare con un approccio organico tutti i processi aziendali dove vengono coinvolti dati personali.

Ogni processo deve, dunque, essere originariamente configurato per garantire il rispetto principi generali previsti dall’art. 5: liceità, correttezza e trasparenza, limitazione della finalità, minimizzazione dei dati, esattezza, limitazione della conservazione, integrità e riservatezza e responsabilizzazione (o accountability per gli anglofili).  Non ci dilungheremo in questa sede su questi principi, limitandoci a citarli.

In secondo luogo, bisogna vedere se ricorre una o più delle basi di legittimità previste dal susseguente art. 6, fra cui è presente anche il consenso dell’interessato che però, è bene richiedere solo ove strettamente necessario (v. https://avvgiacomoconti.com/un-consenso-per-uno-e-uno-per-tutti-una-corretta-applicazione-del-principio-di-irresponsabilizzazione/ ).

Se l’organizzazione sa perché tratta il dato e partendo da quali basi, ad esempio un contratto o una norma di legge o un legittimo interesse, potrà approfondire la conformità del processo al GDPR, ma potrà con una certa ragionevolezza essere sicura che il processo è, in linea di massima, lecito.

Sorvolando sugli articoli seguenti ci troviamo all’art. 24 che menziona espressamente i rischi per i diritti e per le libertà degli interessati che sono indicati per sommi capi nel testo dell’articolo. La norma, senza richiedere nulla di trascendentale chiede semplicemente di tenere conto dei trattamenti che vengono operati all’interno dell’organizzazione e di adottare misure organizzative e di sicurezza adeguate e parametrate al rischio.

Senza pretesa di esaustività, basti pensare al fatto che il trattamento di dati personali apre una finestra sulla vita dell’interessato e a seconda del “peso specifico” del dato personale sarò in grado di conoscere certi aspetti della vita di una persona che sarà, conseguentemente, vulnerabile. Per questa ragione il GDPR distingue i dati in comuni (che permettono di identificare o prendere contatto con l’interessato) e particolari (che invece rilevano aspetti particolarmente delicati della vita privata altrui).  È bene abbinare la lettura dell’art. 24 agli artt. 9 e 10 del GDPR per meglio comprendere il concetto di “rischi per i diritti e per le libertà”.

Semplificando al massimo questo processo che è piuttosto complesso, è essenziale che ogni organizzazione sappia almeno in linea di massima quali dati tratta, per quale motivo e che effetto una violazione alla loro riservatezza, integrità e disponibilità può avere sulla vita personale del lavoratore, del cliente del fornitore e degli altri soggetti coinvolti nel trattamento.

Veniamo ora all’art. 29 che richiede di adottare misure organizzative adeguate. In questa sede ci limiteremo ad indicare le misure che ogni impresa dovrebbe adottare fra le quali, l’individuazione del designato/privacy officer che è un soggetto interno incaricato della gestione delle procedure di trattamento dei dati e per rispettare il GDPR, come garantire le richieste degli interessati o comunicare con l’autorità garante.

Questa figura dovrebbe essere interessata alla materia, adeguatamente formata e responsabilizzata per assicurare un adeguato livello di compliance interno all’organizzazione. L’attività di designazione del referente privacy è un processo a costo zero. Altrettanto gratuita potrebbe essere la creazione dell’organigramma aziendale dove vengono mappati funzioni e compiti dei soggetti designati dall’organizzazione.

Se si vuole che la designazione sia efficiente, tuttavia, sarebbe bene stanziare una somma – anche modesta – per la formazione dei referenti affinché questi siano in grado di mappare e gestire le procedure di cui sono incaricati e responsabilizzare anche gli altri soggetti autorizzati al trattamento.

Veniamo a questo punto ai registri disciplinati dall’art.30: questi altro non sono che un processo di mappatura dei trattamenti che l’azienda opera. Pertanto, i registri dovrebbero configurarsi più che come un documento, come una procedura da monitorare e tenere aggiornata con l’evolversi dei processi aziendali. Pertanto, essi possono essere tenuti senza particolari formalità e aggiornati, anche mediante stampa del file anche in PDF, all’occorrenza.

Più che la forma, è importante che questi strumenti siano tenuti da un soggetto competente che, verosimilmente, sarà il designato aziendale che conoscerà i processi aziendali ed avrà anche una discreta conoscenza normativa ove adeguatamente formato.

Oltre al registro delle attività di trattamento (art. 30), è opportuno che l’organizzazione si munisca anche di un registro della formazione per documentare l’attività svolta e un registro delle violazioni (art. 33) per documentare eventuali data breach e che è uno strumento di ausilio e responsabilizzazione fondamentale per valutare se e quali conseguenze la violazione potrà avere per gli interessati coinvolti.

Seppure i registri non siano richiesti a tutte le organizzazioni, l’adozione di questi è stata fortemente incoraggiata sia dalla nostra Autorità Garante che dal Comitato Europeo per la protezione dei dati personali, ma anche da autorità straniere.

Veniamo ora ai processi relativi alla sicurezza dei dati che possono avere natura fisica o logica.

La sicurezza fisica si articola in misure piuttosto banali come, ad esempio, l’apposizione di porte blindate agli ingressi, inferriate alle finestre, la presenza di estintori.

Apparentemente più complesso è il profilo della sicurezza informatica, ma anche qui, vedremo soluzioni a basso costo o gratuite che possono aiutare enormemente l’organizzazione ad aumentare il proprio livello di sicurezza.

Il primo problema comune a tutte le organizzazioni è la gestione delle Password. Avere password in giro non protette è come lasciare le chiavi della porta vicino allo zerbino di casa.

Rinviando all’apprezzabile vademecum elaborato dal Garante (v. https://www.garanteprivacy.it/temi/cybersecurity/password) è consigliabile adottare gestionali gratuiti come KeePass ( v. https://keepass.info/ ) che salvano i dati in locale criptati eliminando il rischio del cloud e attraverso la master password e i plugin consentono un’agile gestione delle password eliminando fogliettini, il rischio di perderle e altri rischi. Il dipendente dovrà ricordarsi solo la Master Password di accesso al servizio KeePass per accedere in sicurezza a tutte le proprie credenziali.

Altro problema che ogni organizzazione affronta è il backup e, per le organizzazioni più semplici, può bastare anche un piccolo investimento in un NAS o in un economico servizio di backup online scegliendo quello più adatto alle proprie esigenze. Senza dilungarci sulla gestione della backup policy in questa sede, si segnala Duplicati (v. https://www.duplicati.com/ ): una soluzione che rende più efficiente il processo di backup e aiuta a gestire il rischio di perdita dei dati trattati. Questo sistema, di default cripta i dati in formato criptato e permette di gestire la recovery dei dati in maniera intuitiva e semplice. Il gestionale è anche flessibile e permette all’utente di configurare i tempi, modi e livelli di sicurezza del backup.

Potrebbe essere auspicabile anche prevedere un programma formativo con oggetto la cybersecuirty awareness per sensibilizzare i dipendenti alle minacce informatiche. Per iniziare il percorso di sensibilizzazione si può iniziare con il fruire di risorse gratuite e accessibili online.

I problemi della sicurezza informatica, ça va sans dire, non si esauriscono a quelli indicati ed è auspicabile che buona parte delle organizzazioni si accerti, fra le altre cose, di:

  1. Installare solamente programmi originali da autori verificati e sempre aggiornati all’ultima versione
  2. Investire in un solido antivirus che implementi almeno un firewall logico e sistemi di rimozione di malware
  3. Differenziare la rete ad uso interna da quella data ad uso degli ospiti adottando processi di segmentazione

I più scrupolosi vorranno, altresì, adottare un firewall perimetrale integrato con un servizio di analisi dei file di log.

Pare, dunque, opportuno stanziare somme, anche modeste, per aumentare il proprio livello di sicurezza informatica in azienda investendo sulle risorse umane e sulle misure di protezione tecniche.

Un’azienda con un elevato grado di compliance al GDPR, dunque, saprà valutare in autonomia gli investimenti, a livello tecnico e sulle risorse umane, che dovrà operare e saprà gestirsi autonomamente evitando di spendere soldi in consulenze inutili e carte e agire in autonomia per rispettare la norma, nelle migliori ipotesi, con un costo tendente allo zero o con un investimento più che contenuto.

Il GDPR non richiede, dunque, di produrre carte, ma di implementare dei processi efficienti per una corretta gestione del dato e, per essere applicato efficacemente, richiede cultura, formazione e sensibilizzazione.

/da
, , , , , ,

Attacchi informatici ai fornitori e crisi della supply chain. Da una difesa attiva a una logica di difesa zero-trust.

Di Jacopo Sabbadini

Negli ultimi anni abbiamo visto una crescita esponenziale delle minacce alla sicurezza informatica. Questo fenomeno si è acuito nell’ultimo periodo a causa della situazione dovuta alla pandemia mondiale, che ha portata ad un incremento del lavoro da remoto, accelerando di molto un fenomeno già in essere.

A seguito di questo trend molte realtà aziendali hanno cominciato ad implementare svariate soluzioni di sicurezza basate sull’analisi del traffico e dei pacchetti , sulle firme dei programmi , sul comportamento delle utenze.

 

 

Questa “presa di consapevolezza” da parte delle aziende non sembra però aver sortito effetto, praticamente ogni giorno si legge di un nuovo attacco a grandi infrastrutture, spesso strategiche (Colonial Pipeline, AXA, Glovo, solo per citarne alcune) dunque sorge spontanea una domanda: come è possibile che con l’aumento delle misure di protezione, vi sia un conseguente aumento degli attacchi riusciti contro le stesse infrastrutture che implementano questi sistemi?

Per rispondere a questa domanda, bisogna partire da un concetto che pare banale, ma è cardinale in questa analisi: nessun’azienda, nessuna realtà è un’isola. Maggiore è l’azienda, maggiore è il suo giro di affari, maggiore è la galassia di fornitori di beni e servizi che orbitano intorno all’azienda stessa.

Se l’azienda di riferimento è in grado di utilizzare un determinato budget per l’implementazione e il controllo delle misure di sicurezza informatica, è quasi matematico che almeno una parte dei suoi fornitori non abbiano accesso a simili risorse; e quindi, i fornitori stessi diventano il principale obiettivo di un attacco, non tanto per i dati che possono possedere, ma per gli accessi che si possono recuperare.

Un esempio emblematico su tutti è quanto successo con VMWare; la società si occupa di virtualizzazione, ed è leader di mercato per quanto riguarda il deploy di macchine virtuali su server di produzione, ricerca e sviluppo. Quanto accaduto è stato che, ad un certo punto, durante un controllo, il team di sicurezza di VMWare si è reso conto che vi era una API con all’interno del codice mai scritto da loro, che permetteva un accesso non autenticato ma con alti privilegi dall’esterno, e l’esecuzione di codice da remoto; in buona sostanza, era un rootkit inserito non si sa da chi o quando, con molta probabilità aggiunto a seguito di una violazione dei sistemi di un proprio fornitore, che non ne era neanche a conoscenza. Quello che però si sa di per certo sono state le conseguenze: l’attacco a SolarWinds che ha messo in ginocchio moltissime aziende che utilizzano i loro software; tutto è partito da un attacco ai fornitori di VMWare, ed si è arrivati alla crisi della gestione di Orion ed Exchange.

Come fare quindi in una realtà in cui chiunque può essere un bersaglio, e magari anche un veicolo inconsapevole di attacchi mirati?
È da ripensare completamente l’idea di cybersecurity e sicurezza in generale.

Ad oggi si utilizzano dei sistemi con una vulnerabilità lampante: un antivirus, per quanto complesso e “intelligente” si basa su delle firme, su qualcosa di già noto, oltre che su un costante aggiornamento delle proprie componenti di rilevazione.

Una simile soluzione è inadeguata a proteggere contro le odierne minacce, che spesso si declinano in zero days e potenziali attacchi che arrivano da utenti “fidati” all’interno del sistema.

Bisogna passare da una logica di controllo attivo, come quella degli antivirus, firewall e via discorrendo, ad una logica di zero-trust per la quale indifferentemente dal fatto che l’utente sia autenticato, che il processo sia considerato sicuro o in ogni caso non facente riferimento ad alcun database di malware, qualsiasi azione considerata potenzialmente pericoloso viene immediatamente interrotta e segnalata.

Vista l’evoluzione delle tecniche di attacco, la ampia superficie d’attacco disponibile, le classiche soluzioni hanno fatto il loro tempo.

 

 

[1] Application Program Interface, è un sistema di interrogazione di un’applicazione utilizzato per automatizzare dei processi in programmazione.

[1] Malware che permette l’accesso a un sistema, l’esecuzione di comandi e/o programmi, spesso con alti livelli di privilegio.

[1] Malware sconosciuti, di cui non esistono firme digitali in nessun database

/da
, , , , ,

MySQLInjection: gestione dei rischi e corretta configurazione dei form nelle pagine html

di Jacopo Sabbadini

Uno degli attacchi più semplici che si possono portare contro un database è sicuramente il cosiddetto SQLInjection, che consiste nel utilizzare il linguaggio SQL per accedere ai dati di un database.
Facciamo un attimo di chiarezza su cosa sia un form e come funzioni a livello di backend del database; in poche parole, il form è l’interfaccia che vede l’utente, in cui inserisce i propri dati (ad esempio nome, cognome, data di nascita, password e via discorrendo) al momento della registrazione su un sito, o al momento del login sul sito stesso. Questi dati inseriti dall’utente vengono trattati dal database ed inseriti all’interno dello stesso, utilizzando la sintassi propria del database in esame (nel nostro caso SQL per un database scritto in MySQL).
Appare immediatamente evidente un problema: come fa la macchina a distinguere nel momento in cui viene digitata una stringa nel campo del form, tra una stringa che deve inserire all’interno del database (ad esempio il nome) e un comando nel proprio linguaggio?
Qui è necessaria la corretta configurazione del form, vi sono vari tools che permettono di filtrare quanto viene scritto dall’utente, in modo tale che qualsiasi cosa scriva non verrà mai interpretata come un comando.
Se questa precauzione però non viene presa, si rende l’intero database vulnerabile ad un injection, cioè l’inserimento dall’esterno di un comando.
A titolo dimostrativo useremo una macchina virtuale appositamente costruita con questa vulnerabilità.
Iniziamo con registrare un nuovo utente, lo chiameremo Pippo, password Topolino, signature Paperino

 

Una volta creato il nostro nuovo utente, vediamo come normalmente risponde il database ad una query normale, cioè inserendo i corretti parametri per username e password

 

Come si può vedere, nulla di strano, mi viene restituito a video un riepilogo delle informazioni inserite.
Vediamo però cosa succede se cambiamo leggermente il nostro username, e aggiungiamo un ‘, cioè un apice, alla fine del nome. Se il form fosse correttamente settato, dovrebbe semplicemente restituirci un errore in quanto non esiste nessun utente con lo username Pippo’.

 

 

In realtà ci viene restituita una videata in cui ci dice che il codice che abbiamo inserito contiene un errore, nello specifico: Query: SELECT * FROM accounts WHERE username=’Pippo ” AND password=” (0) [Exception]
Questo ci fa capire che in realtà il form non era correttamente configurato, e il database va in errore in quanto il comando che gli è stato dato non era sintatticamente corretto.
A questo punto, possiamo provare a passare un comando che riconosca come sintatticamente corretto, ad esempio dicendogli di cercare tutti i campi in cui il nome utente sia Pippo, oppure di mostrare a video tutti i campi in cui una condizione che sappiamo essere sempre vera (nell’es 1=1) appaia; questa condizione sarà ovviamente vera per ogni riga del database, e questo è il risultato:

 

Andando in errore il database, stampa a video TUTTE le linee al suo interno, comprensive di username e password. Questa tecnica può essere utilizzata per carpire non solo informazioni dalle tabelle di un database, ma anche per portare ulteriori attacchi al server stesso; la prima linea che ci viene stampata è infatti un utente con username admin e password admin; si potrebbe provare a connettersi direttamente al server usando queste credenziali, per prenderne il controllo, e per iniziare un’escalation di permessi.

Per concludere quindi, sempre controllare che le interfacce utente siano correttamente settate, altrimenti il backend più sicuro al mondo può essere bypassato con estrema semplicità.

/da
, , , , ,

L’INDIRIZZO IP E’ UN DATO PERSONALE?

di Alessandro Bottonelli

 

Secondo la Commissione Europea, parrebbe di si (V. risposta ufficiale). Eppure chi avesse interpretato che da solo un Indirizzo IP è “dato personale” ha forse preso una abbaglio? Notare che si considerano dati personali tutte le informazioni relative a una persona vivente identificata o identificabile. Anche le varie informazioni che, raccolte insieme, possono portare all’identificazione di una determinata persona costituiscono i dati personali”. Notare il raccolte insieme. Dopo la premessa, segue una lista esemplificativa di possibili dati personali, fra cui spicca: “un indirizzo IP”. Le informazioni della lista d’esempio sono individualmente “dati personali”? O sono tali quando sono informazioni che assemblate fra loro identificano una persona fisica? (v. ancora il raccolte insieme).

La tesi dell’autore è che da solo un indirizzo IP non identifica una persona fisica. Nella migliore delle ipotesi, e non sempre, identifica una macchina o meglio un sistema (PC, Server, Stampante, Disco di Rete, Router, qualunque cosa). Di per sè l’indirizzo IP non ci dice nulla della “persona” (fisica!) dietro al o ai sistemi¦ quando una persona c’è! (v. IoT, domotica ed altro).

Legare un IP pubblico ad un interessato (persona fisica: individuo appartenente alla specie homo-sapiens) richiede molti altri dati da correlare fra loro temporalmente e logicamente. E quasi mai oltre ogni ragionevole dubbio. Molti di questi altri dati sono accessibili solo alle c.d. “LEA” (Law Enforcemente Agencies) a fronte di specifiche circostanze e mandati. Da notare che le “LEA” sono escluse dal campo di applicazione (o “scope“) del GDPR. Anche per un’azienda di qualunque dimensione è difficile legare con assoluta certezza un IP privato delle proprie reti interne ad una persona fisica. Anche quando (quando?) si raccolgano a norma i log.

In sintesi: un indirizzo IP da solo non è, di per sé, dato personale: difficile da esso identificare univocamente una persona fisica. Servono altri dati.

A supporto di questa tesi occorre una spiegazione tecnica: che si spera d’aver reso il più possibile accessibile a tutti. Un indirizzo IP è ¨ la proprietà   di uno o più sistemi. Non è una proprietà dell’interessato che forse sta usando il sistema: se c’è¨ almeno un umano dietro al sistema. Non è neanche una proprietà della o delle macchine che compongono il sistema. E spesso è una proprietà volatile, non fissa nel tempo (i c.d. “ip dinamici”). Per parafrasare: sarebbe come sostenere che la “targa”, e non necessariamente permanente, di una automobile identifichi il suo guidatore. O, peggio, sostenere che la targa, mutevole, di un autobus identifichi tutti i suoi passeggeri (quando più¹ sistemi condivisi da più¹ persone condividono lo stesso IP).Per esemplificare e semplificare, prendete il vostro PC (ma vale per qualunque sistema/macchina: un server, una WebCam, un Televisore, ecc.).

Fig. 1 – la “pila” o “catena” apri in nuova scheda

Fate riferimento alla figura 1. Pensate al PC o qualunque altro oggetto di rete. Da spenta la macchina è un semplice “pezzo di ferro”, senza alcuna proprietà e men che meno un indirizzo IP. Da acceso il pezzo di ferro diventa sistema grazie al Sistema Operativo “OS” installato sulla macchina, non importa quale OS, anzi, una singola macchina potrebbe diventare più sistemi (questione qui non approfondita) che condividono lo stesso indirizzo IP. Fra le tante cose che fa, l’OS inizializza la c.d. Scheda di Rete (NIC o “Network Interface Card“), di qualunque natura essa sia: wifi, cablata o altro. Per i puristi: la NIC ha, anzi avrebbe, una proprietà unica di fabbrica chiamata MAC-Address, peccato che esso sia riprogrammabile dall’OS e serva solo alla rete locale, quindi è un’informazione che va perduta oltre il primo router: quindi la NIC non identifica neanche il pezzo di ferro. Finita di inizializzare la NIC, il Sistema Operativo (forse!) associa alla NIC un “indirizzo IP” della rete locale, ma anche due, tre o dieci indirizzi IP: nulla lo impedisce. Concluso tutto questo processo, il sistema (non la macchina, non i suoi utenti!) ha uno o più indirizzi IP. Che sia stato o meno riprogrammato, il MAC-Address è “informazione perduta”: non arriva ad InterNet. È probabile che il sistema o sistemi della rete locale subiscano il c.d. “NATting”: tutto e tutti si presentano ad internet con un solo indirizzo IP pubblico. Le informazioni MAC-Address e IP address della rete locale sono andate perdute.

In conclusione. Organizzazioni con uno o migliaia di sistemi “dentro” la propria rete locale si presentano ad Internet con un unico indirizzo IP: come si lega quell’indirizzo al o agli umani, se ce ne sono, che stanno usando quell’indirizzo? Come anticipato, si può fare: ma è¨ un esercizio difficile proprio come provare a legare la targa (mutevole!) di un autobus a tutti i suoi passeggeri! O, peggio, tentare di legare il codice radio di una nave traghetto che trasporta più autobus prima agli autobus e poi ai passeggeri di ogni autobus.

In realtà , la parafrasi è imperfetta. È più facile per una “LEA” (Law Enforcement Agency”) legare il codice radio della nave traghetto agli autobus attraverso il manifesto di carico della nave e con qualche altro passaggio arrivare ai passeggeri degli autobus. Il codice radio del traghetto e le targhe degli autobus sono statici. Invece gli indirizzi IP (le targhe e codici radio della parafrasi) sono spesso volatili: rendendo l’esercizio ben più complicato.

/da
, , , ,

Aggiornamenti e vulnerabilità del sistema Linux. Bug, Access Point e Wi-Fi.

di Paolo Montali

 

L’overflow del buffer può essere attivato nei chip Wi-Fi Realtek

Qualsiasi Software, allo stato attuale delle cose, presenta delle vulnerabilità. Per vulnerabilità, si intendono delle debolezze che vengono (spesso) inconsapevolmente create dagli sviluppatori e che possono essere utilizzate da parte di malintenzionati per entrare all’interno di un sistema.

Questo è noto agli sviluppatori, per cui le case di software si preoccupano, nei loro reparti di ricerca e sviluppo, di miigliorare gli aspetti di sicurezza e in generale di andare ad eliminare mano a mano le vulnerabilità e in generale qualsiasi tipo di “bug” che si sia manifestato o sia stato rilevato, in fase di testing, così come a seguito delle segnalazioni da parte dei Clienti/utilizzatori.

I “bug” sono ancora più pericolosi nei sistemi di connettività o di networking, in quanto, vista la loro funzione di apparati per l’interconnessione di computer, possono consentire di aprire delle porte che dovrebbero restare chiuse.

Questo è il motivo per cui è fondamentale tenere aggiornati tutti i sistemi ad ogni livello, dai BIOS o firmware dei Computer e dei vari dispositivi di networking, ai Sistemi Operativi, a tutti gli applicativi utilizzati sui computer, fino agli ERP o sistemi gestionali.

Oggi ci occupiamo del problema del mancato aggiornamento degli apparati Wi-FI con CHIP Realtek.

Le reti Wi-Fi sono una grande comodità, ma spesso ci dimentichiamo che anche questi apparati sono dotati di software per funzionare. A bordo hanno un sistema operativo (Linux) sul quale vengono implementati dei software per l’implementazione degli standard di comunicazione e per la gestione delle regole di connettività.

E’ stato verificato che gli Access Point con CHIP Realtek non patchati possono essere attaccati sfruttando le onde Wi-Fi, causando l’overflow nel buffer del nucleo (kernel) del Sistema Operativo Linux e creando il blocco o il controllo totale da parte dell’attaccante, dei computer connessi.

Il bug rilevato, si trova nel driver RTLWIFI, che viene utilizzato per gestire i chip Wi-Fi Realtek. La vulnerabilità causa un overflow del buffer nel kernel Linux quando una macchina con un chip Wi-Fi Realtek si trova nel raggio di azione di un dispositivo “malevolo”.

E’ stato verificato che come minimo, gli exploit possono causare un arresto anomalo del sistema operativo e possono consentire a un hacker di ottenere il controllo completo del computer connessi. Il difetto risale alla versione 3.10.1 del kernel Linux rilasciato nel 2013.

Purtroppo sappiamo bene che ci sono molti dispositivi che non vengono aggiornati, per cui potremmo avere nei nostri uffici o nelle nostre case dispositivi con questo bug.

‘Il problema è serio’, ha detto ad Ars Nico Waisman, un ingegnere capo della sicurezza presso Github. ‘È una vulnerabilità che, nei sistemi che utilizzano il driver Realtek (RTLWIFI), attiva un overflow in remoto tramite Wi-Fi sul kernel Linux.

La vulnerabilità è stata denominata CVE-2019-17666. Gli sviluppatori hanno proposto una correzione intorno alla metà del mese di Ottobre 2019, che probabilmente verrà incorporata nel kernel del sistema operativo nei prossimi giorni o settimane. Solo dopo ciò la correzione si farà strada in varie distribuzioni Linux.

/da