CRACKDOWN, violato autistici.org

Come ci hanno fregato

Gli strumenti utilizzati sono tutti liberamente scaricabili e le operazioni sono nella loro immediata applicazione piuttosto banali.

I principi teorici sono un poco piu' complessi, ma non troppo.

Negli atti si legge che il software in grado di effettuare l'analisi del protocollo e' stato scritto apposta. Sara' una coincidenza ma esiste un tool disponibile con tutte le distribuzioni di linux che fa esattamente le stesse cose, nella stessa maniera: ssldump, ed esiste gia' da diverso tempo.

Una sezione del documento e' dedicata ad un esempio pratico di utilizzo e alla ricostruzione di un semplice scenario di attacco.

Sommario

[ La teoria ]
[ La pratica ]
[ Considerazioni ]

La teoria

Esistono molti documenti in rete che spiegano del dettaglio il funzionamento del protocollo TLS/SSL. Per questo non illustremo tutto nei particolari, ma soltanto quelle parti che servono a comprendere lo scenario e il sistema dell'attacco.

Il tls opera a livello applicativo. Il suo scopo e' quello di garantire l'autenticazione, l'integrita e la riservatezza di una comunicazione.

Si compone di due protocolli distinti

il TLS Record Protocol
il TLS Handshake Protocol

Per la nostra trattazione e' importante la comprensione del secondo, del primo basti sapere che il suo compito e' quello di dividere il traffico a pezzettini (blocchi), calcolare un Message Digest sul pacchetto, eventualmente comprimerlo e cifrarlo. Per cifrarlo e' necessario utilizzare un algoritmo simmetrico di qualche tipo e contrattare di conseguenza una chiave. In realta' i parametri coinvolti sono di piu', ma a noi basta focalizzarci su questi, tralasciando il contorno. Questi parametri sono contrattati all'inizio della sessione dal client e dal server.

Questo e' compito del TLS Handshake Protocol, che analizzeremo piu' nel dettaglio. Quest'ultimo si compone a propria volta di 3 protocolli: change cipher spec, aler ed handshake. A noi interessa solo l'ultimo.

La sicurezza del protocollo e' in gran parte garantita dalla correttezza del handshake e dalla protezione degli elementi coinvolti in questa fase. In particolare dall'inacessibilita' della chiave privata riferita al certificato del server. Entrati in possesso di quest'ultima e' di fatto possibile decifrare il traffico ssl.

Qui di seguito viene illustrato nel dettaglio la fase di handshake al fine di comprendere il ruolo centrale svolto dalla chiave privata.

L'handshake si svolge attraverso una serie di scambi di messaggi tra client e server, che determinato le varie fasi della negoziazione ed hanno dei nomi convenzionali. Un tipico handshake:



Client 			Server

ClientHello		
			ServerHello
			Certificate
			ServerHelloDone

ClientKeyExchange
ChangeCipherSpec
Finished
			ChangeCipherSpec
			Finished

ClientHello:
il client fornisce al server l'elenco degli algortimi che supporta e quale predilige

ServerHello:
il server indica quali ha scelto e genera un numero per la sessione e un altro valore causale, che utilizzera' in seguito

Certificate:
il server fornisce un certificato x509 con all'interno una chiave pubblica
Il formato del certificato potrebbe essere il seguente

version
serial number
signature algorithm ID
issuer name
validity period
subject name
subject public key information
issuer unique identifier
subject unique identifier
extensions
signature dei campi precedenti

ServerHelloDone:
passa la palla al client

ClientKeyExchange:
Il client invia un premaster secret, una sequenza di byte necessaria alla creazione del master secret in aggiunta agli altri valori casuali, un valore di 48 byte sul quale si regge la riservatezza del protocollo. Tutte le chiavi simmetriche accennate nella parte introduttiva della trattazione derivano da questo valore: sia le chiavi segrete utilizzate per produrre i MAC dei blocchi, sia la chiave di sessione utilizzate per cifrarli, che i vettori di inizializzazione.
Se si e' in grado, poiche' in possesso della chiave privata del certificato, di decifrare queste fasi, a partire dal premaster secret, allora la sicurezza di tutto il sistema e' compromessa.
Il resto dell'handshake non e' piu' interessante per la nostra trattazione.
La summa di tutto questo discorso e' che in possesso del certificato e della chiave privata del server il traffico e' compromesso, come e' facile immaginare.

La pratica

ssldump e' un tool per l'analisi del protocollo TLS/SSL. Potete scaricarlo da http://www.rtfm.com/ssldump oppure controllare che esista per la vostra distribuzione di Linux o BSD o che utilizzate voi.

Qui di seguito riportiamo un semplice scenario


Web server

A: 192.168.0.77


Client 

B: 192.168.1.77


Gateway tra A e B

C: 192.168.0.254 eth0
   192.168.1.254 eth1


Copio dal webserver il file con il certificato X509
su 192.169.0.254 in /root/apache.pem

quindi semplicemente lancio su C

ssldump -Adn -k /root/apache.pem -i eth1 host 192.168.1.77 > dump

-A indica di stampare tutti i campi del protocollo

-d indica di stampare il livello applicativo

-n non risolve i nomi

-k indica il file con la chiave privata

Se ora effettuo una richiesta dal client al server web
mi ritrovero' sul gw un file dump simile a questo

La prima parte contiene l'handshake del protocollo
illustrato sopra.
Segue quindi la sessione https in chiaro

New TCP connection #2: 192.168.1.77(33220) <-> 192.168.0.77(443)
2 1  0.0072 (0.0072)  C>S SSLv2 compatible client hello
  Version 3.0 
  cipher suites
  SSL_RSA_WITH_RC4_128_MD5  
  SSL2_CK_RC4  
  SSL_RSA_WITH_RC4_128_SHA  
  SSL_RSA_WITH_3DES_EDE_CBC_SHA  
  SSL2_CK_RC2  
  SSL2_CK_3DES  
  Unknown value 0x39  
  Unknown value 0x38  
  Unknown value 0x35  
  SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA  
  SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA  
  Unknown value 0x33  
  Unknown value 0x32  
  Unknown value 0x2f  
  SSL_DHE_DSS_WITH_RC4_128_SHA  
  SSL2_CK_RC464  
  SSL2_CK_DES  
  SSL_DHE_DSS_WITH_RC2_56_CBC_SHA  
  SSL_RSA_EXPORT1024_WITH_RC4_56_SHA  
  SSL_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA  
  SSL_RSA_EXPORT1024_WITH_DES_CBC_SHA  
  SSL_RSA_EXPORT1024_WITH_RC2_CBC_56_MD5  
  SSL_RSA_EXPORT1024_WITH_RC4_56_MD5  
  SSL_DHE_RSA_WITH_DES_CBC_SHA  
  SSL_DHE_DSS_WITH_DES_CBC_SHA  
  SSL_RSA_WITH_DES_CBC_SHA  
2 2  0.0179 (0.0107)  S>CV3.0(74)  Handshake
      ServerHello
        Version 3.0 
        random[32]=
          42 ba d1 02 a6 2a fa f3 9a 92 b4 01 b5 e5 ba 63 
          36 56 37 7b 69 21 4c ab 47 dd 9e fa 3a 88 d9 24 
        session_id[32]=
          57 05 d6 6b c2 0a 8a a9 40 18 2a 4f f9 32 c3 86 
          49 62 ea f6 47 29 77 b3 bf b3 75 08 5e c2 0d 22 
        cipherSuite         SSL_RSA_WITH_RC4_128_MD5
        compressionMethod                   NULL
2 3  0.0179 (0.0000)  S>CV3.0(669)  Handshake
      Certificate
2 4  0.0179 (0.0000)  S>CV3.0(4)  Handshake
      ServerHelloDone
2 5  0.0202 (0.0022)  C>SV3.0(132)  Handshake
      ClientKeyExchange
        EncryptedPreMasterSecret[128]=
          6b 9f 22 1f 85 20 e8 92 50 77 1b 6f 89 a3 54 51 
          4a 7f a7 c8 34 fe d2 c1 94 bf 17 08 ce ae b4 c8 
          bd 48 24 fc 24 60 be 13 77 dd 04 19 7e a6 3b 94 
          7a 69 6a 00 62 d4 39 bd 4a d0 64 de 2a a4 a7 5d 
          b8 62 53 4e 33 bd de 9d 3f 45 df c7 e9 41 46 d4 
          d7 fa 9d ae dd eb 34 ae 7c 0c ca 16 ef 50 66 28 
          d5 d3 d9 89 5e 28 f9 3a f0 57 39 6e b6 e6 95 6d 
          3f b7 ef 06 64 d9 8c 62 76 52 1e c1 78 77 68 07 
2 6  0.0202 (0.0000)  C>SV3.0(1)  ChangeCipherSpec
2 7  0.0202 (0.0000)  C>SV3.0(56)  Handshake
      Finished
        md5_hash[16]=
          98 83 18 44 50 b8 c1 49 5f 92 27 15 cf ad 01 c3 
        sha_hash[20]=
          56 7e a8 cf 79 8c ad 04 f8 2b a7 c9 7b 2d a8 bd 
          40 32 56 43 
2 8  0.0342 (0.0139)  S>CV3.0(1)  ChangeCipherSpec
2 9  0.0342 (0.0000)  S>CV3.0(56)  Handshake
      Finished
        md5_hash[16]=
          55 d8 2d 7d 40 8c 73 7c d8 c3 ef 31 c8 77 cc 25 
        sha_hash[20]=
          b4 d2 b3 71 8d ec a6 82 b5 2d 7a 97 1a 6e 40 bf 
          51 e5 eb 29 


2 10 0.0933 (0.0590)  C>SV3.0(397)  application_data
    ---------------------------------------------------------------
    GET / HTTP/1.1
    Connection: Keep-Alive
    User-Agent: Mozilla/5.0 (compatible; Konqueror/3.3; Linux) KHTML/3.3.2 (like Gecko)
    Pragma: no-cache
    Cache-control: no-cache
    Accept: text/html, image/jpeg, image/png, text/*, image/*, */*
    Accept-Encoding: x-gzip, x-deflate, gzip, deflate
    Accept-Charset: iso-8859-15, utf-8;q=0.5, *;q=0.5
    Accept-Language: it, en
    Host: 192.168.0.77
    
    ---------------------------------------------------------------
2 11 0.0996 (0.0062)  S>CV3.0(4112)  application_data
    ---------------------------------------------------------------
    HTTP/1.1 200 OK
    Date: Thu, 23 Jun 2005 15:10:58 GMT
    Server: Apache/1.3.33 Ben-SSL/1.55 (Debian GNU/Linux) PHP/4.3.10-15
    Last-Modified: Fri, 17 Sep 2004 11:06:46 GMT
    ETag: "5f19e-145d-414ac546"
    Accept-Ranges: bytes
    Content-Length: 5213
    Keep-Alive: timeout=15, max=100
    Connection: Keep-Alive
    Content-Type: text/html; charset=iso-8859-1
    
    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
    <HTML>
    <HEAD>
       <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
       <META NAME="Description" CONTENT="The initial installation of Debian Apache.">
       <TITLE>Placeholder page</TITLE>
    </HEAD>
    <BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#0000EF" VLINK="#55188A" ALINK="#FF0000">
    
    I miei dati personali non sono piu' personali, ma sono a disposizione della
    postale ed anche tutti quelli degli utenti di questo server.
    
    </BODY>
    </HTML>

E' possibile anche leggere i pacchetti da un file, quindi ad esempio utilizzare tcpdump con l'opzione -w per raccogliere il flusso di dati e passarli in seguito ad ssldump, che e' probabilmente quanto fatto dalla postale nei nostri confronti.

Considerazioni

Essendo un problema di accesso, anche fisico, alla macchina, si puo' risolvere solo inibendo il prelievo della chiave privata del certificato. In una qualsiasi web farm e' piuttosto irrealizzabile impedire l'accesso fisico al server da parte del personale della farm stessa. E' possibile pero' cercare di rendere inutile il prelievo di informazioni con un file system cifrato, il che pero' potrebbe essere un po' un problema di carico per il server, e rendere un po' piu' complessa la gestione dell'avvio e del riavvio delle macchine da remoto.

Anche cifrare con una password la chiave privata del certificato puo' essere un ostacolo in piu' per un possibile attaccante, ma complica il riavvio automatico del servizio.

In realta' nessuna di queste soluzioni e' risolutiva, e tutte lasciano aperti dei grossi dubbi. Un file system cifrato deve cmq essere avviato da un qualcosa in chiaro, che puo' essere compromesso.

Si tratta insomma di barattare la possibilita' di un down anche prolungato della macchina e diversi problemi nella gestione da remoto, con qualche sicurezza della privacy in piu'.

Anche i sistemi antintrusione (tipo sensori di rilevamento dell'apertura del case) forse hanno una loro utilita', almeno nell'accorgersi in seguito della violazione, ma la cosa e' piuttosto discutibile.

Rimane comunque il problema dell'accesso non fisico, ma tramite attacchi da remoto alle strutture del server, in questo caso il file system e' gia' in chiaro e quindi accessbile.

Senza dubbio vale la pena di affrontare queste problematiche. Le altre macchine che stavamo sistemando sono concepite secondo queste linee, anche se per un collettivo come il nostro, dove tutto avviene su base volontaria, rubando il tempo al lavoro e agli altri impegni, la possibilita' di errore umano rimane alta.

Personalmente io credo che, indipendetemente da tutto quello che possiamo inventarci, data la presenza di un arbitrio totale nel gestire la questione delle liberta dell'individuo e nello strapotere offerto da un clima di emergenza continua, sapientemente costruito e mantenuto, le contromisure tecniche siano poca cosa. E che cullarsi nell'illusione della sicurezza intrinseca di certi metodi, sia un problema che svia dalla necessita' di una battaglia politica su queste tematiche: sul fatto che il nostro mondo assomiglia sempre piu' ad un "inferno dei viventi". Alimentato dalla paura e dal sospetto, in un perenne tira e molla tra i minuscoli spazi di liberta' concessa, dietro i quali si celano macroscopiche violazioni di ogni bisogno.

La realta' mi appare sempre piu' come uno spettacolo di illusionismo, "mi si e' ristretta e seguita a restringersi".