Attacco alla Cifratura e sicurezza dei dati APPLE: Recovery Italia decodifica il FILEVAULT di OSX

Il sistema di cifratura dei dati implementato da APPLE in OS è denominato FILEVAULT, una implementazione di AES 128 CBC, una rivisitazione del block cypher per proteggerlo dai PADDING ATTACK applicati al CBC denominato XTS.
Una caratteristica funzionale del sistema di cifratura APPLE è l'implementazione della wrapped key cifrata nello stesso volume , per consentire una trasportabilità della chiave e l'integrazione con diversi dispositivi APPLE oltre che l'integrazione con le keybags salvate sul sistema ( portachiave )

Come siamo arrivati a questa scoperta

Un nostro cliente dopo aver creato un volume filevault su una sdcard da 512 mb utilizzando una password con 12 caratteri , ha copiato all'interno della card un file di testo con molte altre password di accesso. 
Dopo aver inserito la password di sblocco, ha selezionato la funzione salva sul portachiave del su MAC.
Ogni volta che l'utente inseriva la sd card nel computer, automaticamente il MAC riconosceva il volume e lo legava alla password contenuta nel portachiavi di sistema, quindi tutto funzionava perfettamente.
Dopo aver avuto un problema al MAC, si è resa indispensabile una formattazione del sistema operativo e le password contenute nel portachiavi di sistema, sono andate perdute irrimediabilmente, compresa la password di accesso alla sdcard codificata.

Dati persi per sempre ?

Forse no. Una valutazione approfondita della sicurezza del filevault per un caso così importante e particolare è quantomeno doverosa ed è certo che ogni sistema di sicurezza ha le proprie vulnerabilità.
Bisogna solo trovarle.

Come abbiamo analizzato il problema

Per poter analizzare con chiarezza un problema e trovare una strategia valida, abbiamo riprodotto lo stesso scenario di cifratura, nello stesso contesto operativo, creando un volume FILEVAULT su un pen drive usb con una password di 4 caratteri.

Esistono già alcuni studi sul filevault come libfvde e questo poteva essere una base di analisi per il nostro progetto di attacco password.

Analisi tecnica di APPLE FileVault

Ogni volume FileVault ha un header così strutturato

struct filevault_vh
{
    unsigned char cs[4];
    unsigned char empty[4];
    short int     version;
    short int     blocktype;
    unsigned char blocksn[4];
    unsigned char unknown[32];
    unsigned int  BytesPerSector;
    unsigned char empty_1[12];
    __int64       VolumeSize;
    unsigned char unknown_1[16];
    unsigned char cssig[2];
    unsigned char Checkssum[4];
    short int     DataBlocks;
    unsigned int  BlockSize;
    unsigned int  MetadataSize;
     __int64      FirstMetadataBlockNumber;
     __int64      SecondMetadataBlockNumber;
     __int64      ThirdMetadataBlockNumber;
     __int64      FourthMetadataBlockNumber;
    unsigned char  MetadataValues [32];
    unsigned int   KeyDataSize;
    unsigned int   EncryptionMethod;
    unsigned char  Key [16];
    unsigned char  Key_pad [112];
    //Physical volume identifier    Contains an UUID in big-endian   Used as the AES-XTS tweak key
    unsigned char  PhysicalVolumeID [16];
    //Logical volume group identifier   (com.apple.corestorage.lv.groupUUID)    Contains an UUID in big-endian
    unsigned char  LogicalVolumeUUID [16];
};

I valori che sono essenziali per la nostra analisi sono

1. Key
2. PhysicalVolumeID
3. FirstMetadataBlockNumber

E' importante notare che i metadati del filefault sono cifrati con lo stesso sistem XTS.
E' quindi essenziale procedere alla decodifica dei metadati che possono essere analizzati utilizzando  Key e PhysicalVolumeID

Lettura e decodifica dei Metadati

Abbiamo scritto una piccola libreria per semplificare la decodifica XTS.
libxts * XTS = new libxts;
memcpy( XTS ->tweak_key , header.PhysicalVolumeID,16);
memcpy( XTS ->key , header.Key,16);

Importante notare la variabile tweak_value.

    byte_stream_copy_from_uint64_little_endian( tweak_value, calculated_block_number );
    read( fd , block , 8192  );
    XTS->decrypt_xts( 0 , tweak_value , 16, block , 8192 , decblock , 8192 );

Funzionamento del sistema di cifratura XTS

Per la decodifica dei dati usiamo open ssl 

    EVP_CIPHER_CTX ctx;
    EVP_CIPHER_CTX_init(&ctx);
    EVP_EncryptInit_ex(&ctx, EVP_aes_128_ecb(), NULL, ( unsigned char * )tweak_key, NULL);
    EVP_EncryptUpdate(&ctx, ( unsigned char * )encrypted_tweak_value, &datasize,  ( unsigned char * )tweak_value, 16);

Per ogni linea di cifratura CBC 128 viene applicato un piccolo trucco per creare scrambling ed evitare attacchi CBC
basati sul padding .

                carry_bit = 0;
                for( block_index = 0;block_index < 16;block_index++ )
                {
                    byte_value = ( encrypted_tweak_value[ block_index ] << 1 ) | carry_bit;
                    carry_bit  = encrypted_tweak_value[ block_index ] >> 7;
                    encrypted_tweak_value[ block_index ] = byte_value;
                }
                if( carry_bit > 0 )
                {
                    encrypted_tweak_value[ 0 ] ^= 0x87;
                }

Metadata Header

Ogni Blocco di metadati ha un header e funzioni diverse, ma per il nostro obiettivo è essenziale localizzare il metadato di tipo 0x0019, quello che contiene informazioni sul volume cifrato

struct fv_metadata_block_header
{
    unsigned char cs[4];
    unsigned char empty[4];
    short int     version;
    short int     blocktype;
    uint8_t       BlockSerialNo[4];
    unsigned char empty_2[16];
    uint64_t      BlockNumber;
};

Una volta che abbiamo decriptato e localizzato il blocco di tipo 0x0019 una incredibile scoperta:

Il blocco metadato decifrato è a sua volta cifrato !

Il metadato di tipo 0x0019 Cifrato contiene a sua volta dati cifrati ?

Abbiamo notato che se l'utente genera un volume FIleVault lowercase o case sensitive, il sistema di cifratura è differente, e per pura fortuna, i metadati contenuti nel filevault del nostro cliente lo sono ( vedi legge di murphy ).

Dopo molte elucubrazioni, una intuizione incredibile ... i metadati cifrati non possono contenere altri dati cifrati, o comunque è possibile una sola alterazione delle chiavi in nostro possesso, in quanto non ce ne sono altre.

La grande scoperta ... Compressione dei dati

Dopo circa tre mesi di tentativi e di test un fulmine a ciel sereno... e se i dati fossero semplicemente compressi. ?

Un semplice test di decompressione con l'algoritmo di HUFFMAN sul buffer ci ha restituito un risultato con degli errori ma sufficiente per l'estrazione di una parte della plist xml.

Notiamo che Joachin Metz ha implementato proprio in questi giorni la decompressione della plist xml convalidando la nostra scoperta.

Key encrypted key wrapped volume key

La cosa più importante dell'analisi è proprio il contenuto del campo PassphraseWrappedKEKStruct, una semplice codifica in base 64 di una struttura binaria.

al byte 8 ci sono 16 bytes con la wrapped key, l'obiettivo di questa lunga analisi.

La WrappedKey

La chiave alterata, è il metodo con il quale il sistema controlla se la password inserita dall'utente è corretta, per poi sbloccare il volume cifrato.

Come viene alterata la password digitata dall'utente

per poter limitare attacchi basati su hashing lineare, la password dell'utente viene reiterata su una base di HMAC 256 con un numero notevole di cicli. questa tecnica si chiama pbkdf2.

        hmac_sha256_ctx  ctx;
        hmac_sha256_init( &ctx,password,password_size );
        hmac_sha256_update( &ctx,data_buffer,data_buffer_size );
        hmac_sha256_final( &ctx ,hash_buffer,hash_size);
        memcpy(  output_ptr , hash_buffer , hash_size  );

        for( password_iterator = 0;password_iterator < number_of_iterations - 1;password_iterator++ )
        {

            hmac_sha256_ctx  ctx;
            hmac_sha256_init( &ctx,password,password_size );
            hmac_sha256_update( &ctx,data_buffer,data_buffer_size );
            hmac_sha256_final( &ctx ,hash_buffer,hash_size);
            memcpy(  output_ptr , hash_buffer , hash_size  );
            for( byte_index = 0;byte_index < hash_size;byte_index++ )
            {
                output_ptr[ byte_index ] ^= hash_buffer[ byte_index ];
            }
        }

La cifratura dati XTS e la sua applicazione sui volumi FileVault sono quindi sicuri ?

Assolutamente no.
Lo abbiamo dimostrato con i nostri sistemi CUDA MPI, cluster con Multiple GPU CUDA.
Se è vero che il sistema di cifratura di APPLE sembra robustissimo, in realtà 
è composto solo da un sistema di scatole cinesi, mentre l'unica vera protezione è il numero di reiterazioni per l'alterazione della password basato su HMAC256.