Attacchi alle unità di memoria (2)

Aggiornamento, più che altro una provocazione, al precedente post sul tema.
Che bisogno c'è di cifrare i dati del sistema quando, come si legge dalla documentazione di TrueCrypt:

Paging File
(...)
Also called 'swap file'; Windows uses this file (usually stored on a hard disk) to hold parts of programs and data files that do not fit in memory. This means that sensitive data, which you believe are only stored in RAM, can actually be written unencrypted to a hard disk by Windows without you knowing.

TrueCrypt always attempts to lock the memory areas in which cached passwords, encryption keys, and other sensitive data are stored, in order to prevent such data from being leaked to paging files. However, note that Windows may reject or fail to lock memory for various (documented and undocumented) reasons.

Non ho prove a credito nè a discredito di tale affermazione, che ho sentito più volte, sulla quale non faccio commenti.
In primis, non è detto che il problema sia limitato al solo OS di casa Redmond. Il fatto stesso che esista un meccanismo di lock dimostra quanto meno attenzione al problema. Se poi l'implementazione va in deroga allo stesso....
In secondo luogo, direi che un approccio sensato sia comunque valutare il rischio che dati sensibili che "dovrebbero" trovarsi in memoria, prima o poi finiscano sul disco, da qualche parte, non necessariamente dove vorremmo. Questo vale allo stesso modo per i contenuti dei documenti che stiamo scrivendo, e nessun0 se ne fa meraviglia.

In generale, aggiungerei al mio precedente post sul tema che i meccanismi di cifuratura del disco, se comprendono le aree destinate ai file temporanei, possono quanto meno garantire che tali dati, residenti anche dopo la chiusura delle applicazioni o del sistema, sono quanto meno non leggibili se non si è a conoscenza della password di decifratura del disco.
Tuttavia, quale consolazione alla luce di quanto detto all'inizio...

Il riferimento al software TrueCrypt testé citato deriva dal fatto che da tempo mi ero ripromesso di provare questa soluzione, e che dopo aver scritto di problemi di cifratura mi sono finalmente deciso a farlo.
Della versione in ambiente Apple, per adesso, mi ha colpito favorevolmente il fatto che dopo un certo tempo il servizio faccia automaticamente l'unmount del volume cifrato.
Tornerò a parlarne dopo averlo provato per più tempo.

Ancora su Time Machine e backup su MacOS (Leopard)

Ringraziando l'autore, rispondo a questo commento con un aggiornamento alla questione del backup con Time Machine che avevo intenzione di scrivere.

Time Machine non adotta alcun sistema di protezione oltre ai meccanismi di controllo accesso ai dati previsti dal file system. Questo significa, sostanzialmente, che il livello di protezione dei dati della partizione o del disco ove sono salvati i dati da T.M. è equivalente a quello offerto per gli stessi dati sul disco originale. Per altro, con il rischio in più del furto del disco esterno, il cui valore economico, marginale rispetto a quello di un PC, è tipicamente causa di una minore attenzione da parte del proprietario rispetto al (faccio il mio esempio) portatile, ed in più è certamente più facile da rubare.

Per quanto mi riguarda, utilizzo FileVault per cifrare interamente la home directory, proprio per ovviare a questo problema. Le informazioni più critiche, poi, le conservo in file immagine cifrati (AES 128-256bit) creati con Disk Utility, ed ovviamente con una password diversa da quella utilizzata per l'accesso al sistema. Questo perchè FileVault non offre, di per se, protezione dal momento che l'utente accede al sistema, quando il meccanismo di cifratura è trasparente alle applicazioni, "buone o cattive" che siano.

Personalmente, riscontrata l'assenza di meccanismi di cifratura da parte di Time Machine, ho ripristinato il sistema di backup che utilizzavo con Mac OS X 10.4 (Tiger):

1. ho creato un volume virtuale cifrato con Disk Utility, di dimensioni adeguate per ospitare i miei backup
2. ho scelto, tra vari software disponibili per il backup, iBackup, configurandolo per utilizzare, come destinazione dei dati di backup, il volume virtuale cifrato
3. ho installato iBackup sul volume virtuale cifrato, e ho creato uno shortcut sul Dock.

A questo punto, quando devo eseguire il backup, basta fare click sull'icona di iBackup perchè il sistema mi richieda la password di decifratura del volume virtuale per accedere all'applicazione. Il sistema, monta quindi il volume, avvia iBackup ed effettua il backup. Il meccanismo funziona anche creando degli script per pianificare l'operazione in modo automatico ma, visto che devo inserire la password e che sono un ragazzo diligente :-) , faccio tutto giornalmente a mano.

iBackup è una delle possibilità. A me piace perchè unisce semplicità di utilizzo a meccanismi standard di compressione e salvataggio dei dati (crea archivi cpio, cpgz o si appoggia a rsync). La semplicità di utilizzo risiede nella possibilità di selezionare, oltre alle directory delle quali l'utente vuole fare delle copie di sicurezza, anche le impostazioni personali e di sistema, le applicazioni etc... Per esempio, la posta elettronica, che come sapranno gli utenti della mela è conservata in "Library".
Il restore funziona bene, e comunque trattandosi di archivi standard, non è necessario avere a disposizione iBackup per ripristinare il tutto, la qual cosa è per me un elemento indispensabile di scelta di un meccanismo di backup (inizialmente utilizzavo Windows, poi Linux ed adesso MacOS, e sono sempre stato in grado di accedere ai backup fatti con i S.O. precedenti, guarda un pò!).

Web service over SSL, in Java

Le soluzioni di sicurezza in ambito web service abbondano.
Fortunatamente? Certamente è un bene disporre di un'ampia scelta di soluzioni, per altro quasi tutte a carattere innovativo, che consentono di autenticare le parti, cifrare i messaggi, firmarli digitalmente etc...

D'altro canto, non sempre la sicurezza legata al payload è quello che serve, senza considerare poi che molte delle tecnologie di protezione delle buste XML non sono poi così consolidate da garantire una completa protezione dell'informazione.
Tutto questo per dire che, dovendo scegliere come rendere sicura la comunicazione tra un servizio che opera come client ed un web service, ho preferito ricorrere a ciò che già abbiamo a disposizione da tempo, dato che, in definitiva, ho "solo" bisogno di autenticare tra loro i servizi e rendere sicuro il canale di comunicazione.
Non fraintendete: non sono per "accontentarmi" del canale, nè credo che la sicurezza del canale risolva immediatamente tutti i problemi legati alla protezione della comunicazione e dei dati, tuttavia, credetemi sulla parola, il contesto è tale da non rendere necessario alcuna altra forma di protezione diversa (di tipo applicativo, si intende!), e certamente la cifratura dei singoli messaggi non avrebbe apportato miglioramenti di alcun genere. Anzi...
Così, posto il problema, ecco la soluzione.
JSSE, la libreria SUN di Java che opera come security provider per l'implementazione del protocollo SSL/TLS , fa da sola gran parte del lavoro necessario.
Lato server, la configurazione necessaria è di tipo prevalentemente sistemistico: si tratta di attivare l'HTTPS e l'autenticazione dei client. Potete vedere un esempio qui. Potete aggiungere, estraendo come "properties" della connessione SSL i dati del certificato, dei controlli applicativi sul contenuto (per esempio, se configurate il server per accettare tutti i certificati emessi da una particolare CA, potete poi verificare che il CN dell'utente corrisponda ad uno precedentemente autorizzato...), fidandovi del fatto che il web server abbia svolto tutti i controlli crittografici a monte per instaurare la sessione autenticata e cifrata.
Lato client il problema è più complesso: il web service client è normalmente costruito a partire da framework semi-automatici che limitano lo spazio di azione, risolvendo gran parte del lavoro, tuttavia con il limite di dover letteralmente "impazzire" per ogni minima personalizzazione. D'altro canto, è quanto questa tecnologia promette, tra le altre cose, agli sviluppatori!
Tra le vittime di questo livello di astrazione, vi è il canale di comunicazione, così come tutto quanto c'è al di sotto della logica applicativa...
Torniamo all'oggetto: consentire ad un web service client di comunicare con un web service mediante canale SSL con mutua autenticazione.
Se vi affidate a Java, i vari framework che sono coinvolti in maniera pressochè invisibile allo sviluppatore includono anche JSSE, e quindi la possibilità di utilizzare e configurare dinamicamente il "substrato" SSL.
Per questo, è necessario indicare all'applicazione dove potrà trovare la propria chiave privata, il proprio certificato, e come verificare l'identità del server.
A tale scopo sono necessari un keystore, contenente il certificato e la chiave privata del client, ed un truststore, contenente, in alternativa:

• il certificato del server con il quale comunicare, che consentirà quindi un riconoscimento univoco e mirato al quel particolare servizio/sistema
• il certificato dell'Autorità di Certificazione che ha emesso il certificato del server, che permetterà quindi di ritenere affidabile sia il suddetto server, sia qualunque altro servizio che si è rivolto alla medesima autorità.

Per creare il keystore, è possibile rivolgersi a molteplici servizi di certificazione. Tipicamente, dall'esito della procedura di certificazione si otterranno due file in formato PEM (di cui quello della chiave cifrato) o un file in formato PKCS#12. In ogni caso, tramite openssl, è possibile ricondurci nella condizione di disporre di un file PKCS#12 cifrato con password (di seguito indicato come pkcs12.p12, con password "password").
Relativamente al truststore, il modo più semplice di crearlo è affidarsi all'utilità keytool, avendo a disposizione il certificato dell'Autorità di Certificazione (il file cacert.cer):

keytool -import -v -keystore truststore.jks -storepass 12345678 -file cacert.cer

Naturalmente, è opportuno inserire una password diversa da "12345678" e non dimenticare di confermare, quando richiesto, che si ritiene tale certificato appartenente ad una CA "trusted".
Adesso, mani al codice!
Nella procedura dalla quale si richiamano le classi di creazione del web service client, prima di creare un'istanza dello stesso, inserire le seguenti chiamate:
//indicare il nome del file del keystore
System.setProperty("javax.net.ssl.keyStore","/home/client/pkcs12.p12");

//indicare la password di accesso al keystore
System.setProperty("javax.net.ssl.keyStorePassword","password");

//specificare che il keystore è un file PKCS#12
System.setProperty("javax.net.ssl.keyStoreType","PKCS12");

//indicare il file del truststore
System.setProperty("javax.net.ssl.trustStore","/home/bechelli/truststore.jks");

//specificare la password di accesso al truststore
System.setProperty("javax.net.ssl.trustStorePassword","12345678");

//specificare che il truststore è nel formato Java KeyStore
System.setProperty("javax.net.ssl.trustStoreType","JKS");

Il gioco è fatto: il web service client, riscontrato che il protocollo di accesso è HTTPS, verificherà l'autenticità del server mediante il proprio truststore, mentre all'atto della richiesta di autenticazione del server risponderà con il proprio certificato.
Per ulteriori controlli o personalizzazioni, fare riferimento alla documentazione di JSSE.

Hacking e formazione

Non sono un ethical hacker.
Partendo da questa considerazione, seppure tra le varie attività non mancano occasioni di fare Penetration Test, una delle situazioni nelle quali mi trovo spesso ad usare strumenti di hacking è quella della formazione.
Poichè, come ho detto, non mi ritengo qualificato come ethical hacker, anche nel caso della formazione non svolgo corsi finalizzati su queste tematiche specifiche. Più spesso, il mio obiettivo è fornire una panoramica di strumenti sufficientemente completi ed user-friendly perchè siano effettivamente usati dai partecipanti ai corsi, in relazione sopratutto a quello che fanno di mestiere nel loro lavoro quotidiano.
In questi corsi, tuttavia, non manca quasi mai un momento nel quale mostrare loro una vera e propria esecuzione di un attacco (quasi mai attacchi basati su vulnerabilità delle quali non è disponibile una patch, non si sa mai :-) ), sopratutto perchè spesso ho riscontrato come per qualcuno l'hacking è appannaggio esclusivo di supertecnici e, cosa peggiore, qualcosa che accade ad altri e di cui non si ha una reale immagine della portata.
Quindi, il mio scopo è, in questi casi, mostrare come gli strumenti esistano, siano facilmente reperibili ed utilizzabili, e come non sia necessario conoscere troppi tecnicismi per fare danni (qualcuno potrà dire, un approccio in stile script kiddie...).
Per ogni corso, quindi, corro affannatamente a trovare una vulnerabilità recente ma della quale esiste una patch, che sia sufficientemente "pirotecnica" per essere mostrata ai discenti, e possibilmente utilizzabile da loro nel caso in cui il corso sia di laboratorio (quindi compilabile sull'OS dei loro sistemi etc...).
Recentemente, uno degli studenti del master di primo livello di Ingegneria dell'Università di Pisa ha portato un progetto di hacking utilizzando un framework disponibile in rete: Metasploit.
Questo framework è particolarmente interessante per chi ha esigenze analoghe alle mie: tramite diverse interfacce, tra le quali una addirittura web-based, è possibile selezionare una vulnerabilità (ricercandola per OS, vendor o applicazione) e quindi l'exploit da utilizzare, il payload ed i parametri dell'attacco.
Il funzionamento del framework è simile ad altri strumenti di penetration test, poichè incorpora un interprete di comandi che consente la selezione e l'esecuzione dell'attacco, tuttavia la novità più evidente è appunto quella di poter rapidamente passare da un payload ad un altro avendo quindi facoltà di veicolare l'attacco preferito indipendentemente (più o meno...) dal tipo di vulnerabilità che si va a sfruttare, con poco sforzo.
L'obiettivo del progetto Metasploit è comunque più alto, pertanto consiglio una visita al sito.
Devo dire, dai riscontri dell'ultimo corso che ho svolto, che la violazione di un server utilizzando in modo semplice una interfaccia web per ottenere una console, ha avuto il suo effetto sulla consapevolezza delle persone. Provare, per credere...

Mutua autenticazione su Jboss 4.0.x

Faccio riferimento al post precedente, nel quale si illustra uno dei fin troppo numerosi modi di configurare JBoss per l'accesso HTTPS.
Questa volta proviamo a configurare la mutua autenticazione SSL.
Per fare questo, rispetto alla procedura precedentemente descritta, è sufficiente aprire con un editor di testi il file /server/default/deploy/jbossweb-tomcatxx.sar/server.xml ed impostare a "true" l'opzione clientAuth :

<Connector port="8443" address="${jboss.bind.address}"
maxThreads="100" strategy="ms" maxHttpHeaderSize="8192"
emptySessionPath="true"
scheme="https" secure="true" clientAuth="true"
keystoreFile="${jboss.server.home.dir}/conf/servercert.p12"
keystorePass="apassword" sslProtocol = "TLS"
keystoreType="PKCS12" />

Non riavviare il servizio! Così configurato, Jboss non farà accedere alcun utente.
E' infatti necessario configurare il trustStore, ovvero l'archivio dei certificati client e delle Autorità di Certificazione affidabili, in una delle due modalità previste:

• aggiungendo certificati root di Autorità di Certificazione: in questa modalità, tutti gli utenti in possesso di certificati validi ed emessi dalle Autorità di Certificazione i cui certificati sono inclusi nel trustStore sono automaticamente autorizzati ad accedere;
• aggiungendo i singoli certificati degli utenti che hanno facoltà di accedere ai servizi: in questo modo, solo gli utennti i cui certificati sono inclusi nel trustStore possono accedere al server.

Il trustStore non è presente all'atto dell'installazione di JBoss. Per crearlo, aggiungendovi un certificato, digitare:

    keytool -import -v -keystore truststore.jks  -storepass apassword -file cert.cer

dove trustore.jks indica il file del vero e proprio trustStore che si vuole creare, apassword indica la parola chiave di cifratura del file e cert.cer è il nome del file del certificato dell'Autorità di Certificazione o dell'utente che si vuole aggiungere.
Naturalmente, se è stabilito di inserire un certificato per ogni utente abilitato all'accesso, il comando di cui sopra va ripetuto per ogni certificato da autorizzare.

Rimane quindi un ultimo passaggio: indicare a JBoss quale trustStore utilizzare.
Per fare questo, modificare il file di configurazione /server/default/deploy/jbossweb-tomcatxx.sar/server.xml nel seguente modo:

<Connector port="8443" address="${jboss.bind.address}"
maxThreads="100" strategy="ms" maxHttpHeaderSize="8192"
emptySessionPath="true"
scheme="https" secure="true" clientAuth="true"
keystoreFile="${jboss.server.home.dir}/conf/servercert.p12"
keystorePass="apassword" sslProtocol = "TLS"
keystoreType="PKCS12"
truststoreFile="${jboss.server.home.dir}/conf/truststore.jks"
truststorePass="apassword" />

Ricordarsi inoltre di fare attenzione ai path dei vari *store!

HTTPS su JBoss 4.0.x

Ispirazione: vedere qui
Scenario: application server Jboss 4.0.x che deve abilitare l'autenticazione dei client mediante SSL, e quindi con certificati digitali.
Il certificato del server con la relativa chiave privata sono protetti su file cifrato PKCS#12 (supponiamo il file /home/user/servercert.p12).
La modifica della configurazione avviene sul motore di Jboss 4.0.x, un buon vecchio Tomcat!
Copiare /home/user/servercert.p12 in /server/default/conf/.
Aprire quindi con un editor di testi il file /server/default/deploy/jbossweb-tomcatxx.sar/server.xml

de-commentare le linee:


<Connector port="8443" address="${jboss.bind.address}"
maxThreads="100" strategy="ms" maxHttpHeaderSize="8192"
emptySessionPath="true"
scheme="https" secure="true" clientAuth="false"
keystoreFile="${jboss.server.home.dir}/conf/chap8.keystore"
keystorePass="rmi+ssl" sslProtocol = "TLS" />



e quindi modificare i parametri evidenziati sopra in neretto:

• Connector Port, specificando il numero di porta preferito per le connessioni https,
  
• keystoreFile, sostituendo a chap8.keystore il nome del file pkcs#12 servercert.p12,
  
• keystorePass, indicando la password di decifratura del file PKCS#12.

Dato che l'ambiente Java non supporta nativamente il formato PKCS#12 per i Keystore, ma il "proprietario" JKS (Java KeyStore), aggiungere per precauzione un'ulteriore opzione:

• keystoreType="PKCS12"

E' quindi possibile lanciare Jboss e provare la connessione sulla porta 8443, o quella indicata in Connector Port, in https.

Backup e Restore di server LDAP

...ovvero come farlo nella condizione più difficile: online e senza utilità di specifici prodotti.
Utilizzando le utilità OpenLDAP Client Utilities come ldapadd, ldapsearch etc..., è possibile eseguire rapidamente e semplicemente l'operazione di copia completa delle entry di un server LDAP remoto, nonché di scrittura di tale copia su un LDAP server "vuoto".
Come vi sarete abituati a leggere, in queste pagine le note tecniche sono relativamente semplici e utili al più come promemoria, ma spero possano essere comunque di vostra utilità, sopratutto, per esempio, per la stesura di script automatici.

Per il backup, utilizzando ldapsearch:
>ldapsearch -x -b "dc=example,dc=com" -h 192.168.0.1 -D "cn=manager,dc=example,dc=com" -w secret "(objectclass=*)" > nomefile.ldif

dove:

• -x specifica l'utilizzo della "sample authentication" (anzichè SASL)
• -b "dc=example,dc=com" indica il BaseDN del server, ovvero la posizione dalla quale effettuare la copia di tutti i nodi e le entry contenute
  
• -h 192.168.0.1 indica l'indirizzo del server LDAP remoto
  
• -D "cn=manager,dc=example,dc=com" specifica l'identificativo dell'utenza ai fini dell'autenticazione al server remoto
• -w secret permette di specificare la password di accesso per l'utenza precedentemente indicata
• "(objectclass=*)" da istruzione al ldapsearch di restituire tutte le entry
• nomefile.ldif è il file, in formato LDIF, ove salvare il risultato della ricerca.

Il file LDIF prodotto può quindi essere utilizzato per ripristinare, ad esempio, un server il cui contenuto è andato perso. Pertanto, il seguente comando può essere utilizzato (attenzione!) per ripristinare un LDAP server privo di entry:
> ldapadd -D "cn=manager,dc=example,dc=com" -x -w secret -h LDAPServer -f nomefile.ldif

Per il significato dei parametri, fare riferimento alla precedente descrizione. Per la stesura di script, suggerisco l'opzione -W anzichè -w secret poichè attiva un prompt per la richiesta della password di autenticazione, evitando così la pessima abitudine di salvare le password di accesso all'interno dei batch...

A presto!

Estrarre chiavi e certificati in formato "pem" da un file PKCS#12

Ancora una cosa facile facile ma che ogni volta mi costringe a navigare sul sito di openssl (che consiglio comunque di visitare!) .
Ipotizziamo di avere un file PKCS#12 protetto con password, e di voler esportare la chiave privata ed il certificato utente in file in formato "pem" (il formato, per intenderci, utilizzato da Apache).

Con openssl:
> openssl pkcs12 -in pkcs12.p12 -nocerts -out key.pem

dove pkcs12.p12 è il nome del file PKCS#12 di origine, ed il file key.pem è quello destinato a contenere la chiave privata. Verrà richiesta una password per decifrare il PKCS#12 ed una nuova per cifrare il file key.pem.

Esportiamo adesso il certificato utente:
>openssl pkcs12 -in pkcs12.p12 -clcerts -nokeys -out cert.pem

dove pkcs12.p12 è il nome del file PKCS#12 di origine, ed il file cert.pem è quello destinato a contenere il solo certificato utente. Verrà richiesta una password per decifrare il PKCS#12.

Talvolta, i file PKCS#12 contengono, oltre ai certificati utente, anche quelli della CA che li ha emessi. Esportiamo quindi anche questo certificato:
>openssl pkcs12 -in pkcs12.p12 -cacerts -nokeys -out cacert.pem

dove pkcs12.p12 è il nome del file PKCS#12 di origine, ed il file cacert.pem è quello destinato a contenere il certificato della CA. Verrà richiesta una password per decifrare il PKCS#12.

Alla prossima!

Esportare le chiavi da un file PKCS#12 per l'utilizzo con SSH

Supponiamo di avere, per l'utente sshuser, un file cifrato contenente certificati e chiavi in formato PKCS#12, e supponiamo di dover utilizzare la chiave privata per connessioni SSH con mutua autenticazione.

Il primo passo è quello di esportare la chiave privata. Considerato che, per openssh, la chiave privata è conservata nella directory .ssh/ nel file id_rsa, e supponendo di avere il file PKCS#12 sshuser.p12, avremo:
openssl pkcs12 -in sshuser.p12 -clcerts -nocerts -des3 -out .ssh/id_rsa

Seguirà la richiesta della password di accesso al file PKCS#12, nonchè quella di cifratura del nuovo file in formato PEM.

Adesso sarà necessario generare, nel formato opportuno, i dati indicativi per la ricostruzione della chiave pubblica da parte di openssh.
Per questo motivo, è innanzitutto opportuno modificare i diritti del file della chiave privata:
chmod 400 .ssh/id_rsa

quindi eseguire:
ssh-keygen -y -f .ssh/id_rsa > .ssh/id_rsa.pub

Enjoy!

Firmare codice java

Cominciamo con una cosa banale ma, come sempre, visto che non è la classica attività di tutti i giorni, tipicamente destinata al dimenticatoio.
Ogni volta devo ricominciare da capo!

Iniziamo da un PKCS#¹2. Per poterlo utilizzare, con l'utilità jarsigner, scrivere:
jarsigner -storetype pkcs12 -keystore FilePKCS12.p12 JarDaFirmare.jar Nome_Alias

La verifica dell'esito dell'operazione è possibile nel seguente modo:
jarsigner -verify -certs JarDaFirmare.jar

Banale? Sì, tranne nel fatto che continuerò a dimenticarmelo :-)