Sicurezza seria: Microsoft Office 365 attaccato con una crittografia debole

Non siamo sicuri di come chiamarlo in questo momento, quindi lo abbiamo indicato nel titolo con il nome ibrido Microsoft Office 365.

(Il nome "Office" come nome collettivo per le app di elaborazione testi, fogli di calcolo, presentazioni e collaborazione di Microsoft è essere fatto fuori nel prossimo mese o due, per diventare semplicemente "Microsoft 365".)

Siamo sicuri che le persone continueranno a utilizzare i nomi delle singole app (Word, Excel, PowerPoint e amici) e il moniker della suite Office per molti anni, anche se i nuovi arrivati ​​​​al software probabilmente finiranno per conoscerlo come 365, dopo aver eliminato l'onnipresente prefisso Microsoft.

Come forse saprai, le app autonome di Office (quelle che installi effettivamente localmente in modo da non dover andare online per lavorare sulle tue cose) includono la loro opzione per crittografare i documenti salvati.

Questo dovrebbe aggiungere un ulteriore livello di sicurezza nel caso in cui in seguito condividi qualcuno di quei file, per caso o per progettazione, con qualcuno che non avrebbe dovuto riceverli, cosa che è sorprendentemente facile da fare per errore quando si condividono allegati via e-mail.

A meno che e fino a quando non fornirai anche al destinatario la password di cui ha bisogno per sbloccare il file, per loro è solo cavolo tritato.

Naturalmente, se includi la password nel corpo dell'e-mail, non hai guadagnato nulla, ma se sei anche un po' cauto nel condividere la password tramite un canale diverso, ti sei guadagnato un po' di sicurezza in più contro i malintenzionati. , ficcanaso e fannulloni ottengono un facile accesso a contenuti riservati.

OME sotto i riflettori

O tu?

Secondo ricercatori presso la società finlandese di sicurezza informatica WithSecure, i tuoi dati potrebbero godere di una protezione molto inferiore a quella che potresti ragionevolmente aspettarti.

La funzione utilizzata dai tester è quella a cui si riferiscono Crittografia dei messaggi di Office 365, o OME in breve.

Non abbiamo riprodotto i loro esperimenti qui, per il semplice motivo che i prodotti principali di Office, mi dispiace, 365 non funzionano in modo nativo su Linux, che usiamo per lavoro. Le versioni basate sul Web degli strumenti di Office non hanno lo stesso set di funzionalità delle app complete, quindi è improbabile che i risultati che potremmo ottenere siano in linea con il modo in cui la maggior parte degli utenti aziendali di Office, ah, 365 ha configurato Word, Excel, Outlook e amici sui loro laptop Windows.

Come lo descrivono i ricercatori:

Questa funzione è pubblicizzata per consentire alle organizzazioni di inviare e ricevere messaggi di posta elettronica crittografati tra persone all'interno e all'esterno dell'organizzazione in modo sicuro.

Ma fanno anche notare che:

Sfortunatamente i messaggi OME sono crittografati in modalità operativa non sicura Electronic Codebook (ECB).

ha spiegato la BCE

Spiegare.

Molti algoritmi di crittografia, in particolare il Advanced Encryption Standard o AES, che utilizza OME, sono i cosiddetti cifrari a blocchi, che codificano grandi quantità di dati alla volta, invece di elaborare singoli bit o byte in sequenza.

In generale, questo dovrebbe aiutare sia l'efficienza che la sicurezza, perché la cifra ha più dati di input da mescolare, tritare, triturare e liquidare ad ogni giro della manovella crittografica che guida l'algoritmo, e ogni giro ti porta oltre attraverso i dati che vuoi crittografare.

L'algoritmo AES di base, ad esempio, consuma 16 byte di testo in chiaro di input (128 bit) alla volta e codifica i dati in una chiave di crittografia per produrre 16 byte di output di testo crittografato.

(Non confondere misura del blocco con dimensione chiave – Le chiavi di crittografia AES possono essere lunghe 128 bit, 192 bit o 256 bit, a seconda di quanto improbabile si desidera che vengano indovinate, ma tutte e tre le dimensioni delle chiavi funzionano su blocchi da 128 bit ogni volta che l'algoritmo viene “avviato”.)

Ciò significa che se si sceglie una chiave AES (indipendentemente dalla lunghezza) e quindi si utilizza il codice AES direttamente su un blocco di dati...

…poi ogni volta che ottieni lo stesso blocco di input, otterrai lo stesso blocco di output.

Come un libro di codici davvero enorme

Ecco perché viene chiamata questa modalità operativa diretta BCE, abbreviazione di libro di codici elettronico, perché è un po' come avere un enorme libro di codici che potrebbe essere usato come tabella di ricerca per crittografare e decrittografare.

(Un “codice” completo non potrebbe mai essere costruito nella vita reale, perché sarebbe necessario memorizzare un database composto da 2¹²⁸ Voci a 16 byte per ogni chiave possibile.)

Sfortunatamente, soprattutto nei dati formattati per computer, la ripetizione di determinati blocchi di dati è spesso inevitabile, grazie al formato di file utilizzato.

Ad esempio, i file che riempiono regolarmente sezioni di dati in modo che si allineino su limiti di 512 byte (una dimensione di settore comune durante la scrittura su disco) o su limiti di 4096 byte (una dimensione comune dell'unità di allocazione quando si riserva la memoria) produrranno spesso file con long run di zero byte.

Allo stesso modo, i documenti di testo che contengono molti elementi standard, come intestazioni e piè di pagina su ogni pagina, o la menzione ripetuta del nome completo dell'azienda, conterranno numerose ripetizioni.

Ogni volta che un blocco di testo in chiaro ripetuto si allinea su un limite di 16 byte nel processo di crittografia AES-ECB, emergerà quindi nell'output crittografato esattamente come lo stesso testo cifrato.

Quindi, anche se non riesci a decifrare formalmente il file di testo cifrato, potresti essere in grado di trarne deduzioni immediate e dannose per la sicurezza, grazie al fatto che i modelli nell'input (che potresti conoscere, o essere in grado di dedurre, o indovinare) vengono conservati nell'output.

Ecco un esempio basato su un articolo che abbiamo pubblicato quasi nove anni fa quando abbiamo spiegato perché l'uso ormai noto di Adobe della crittografia in modalità ECB per "hash" le password dei suoi utenti era Non è una buona idea:

Nota come i pixel che sono di colore bianco fisso nell'input producono in modo affidabile uno schema ripetitivo nell'output e le parti blu rimangono alquanto regolari, in modo che la struttura dei dati originali sia ovvia.

In questo esempio, ogni pixel nel file originale occupa esattamente 4 byte, quindi ogni 4 pixel da sinistra a destra eseguito nei dati di input è lungo 16 byte, che si allinea esattamente con ogni blocco di crittografia AES da 16 byte, accentuando così l'“effetto BCE”.

---

Modelli di testo cifrato corrispondenti

Ancora peggio, se hai due documenti che sai essere crittografati con la stessa chiave e ti capita di avere il testo in chiaro di uno di essi, puoi guardare attraverso il testo cifrato che non può decifrare e provare a far corrispondere sezioni di esso con i modelli nel testo cifrato che tu può decifrare.

Ricorda che non hai bisogno della chiave per “decifrare” il primo documento se lo hai già in forma decifrata – questo è noto, non a caso, come attacco con testo in chiaro noto.

Anche se ci sono solo poche corrispondenze di testo apparentemente innocente che non è di per sé un dato segreto, la conoscenza che un avversario può estrarre in questo modo può essere una miniera d'oro per spie della proprietà intellettuale, ingegneri sociali, investigatori forensi e altro ancora.

Ad esempio, anche se non hai idea a cosa si riferiscano i dettagli di un documento, confrontando blocchi di testo in chiaro noti su più file, potresti essere in grado di determinare che una raccolta apparentemente casuale di documenti:

• Sono stati tutti inviati allo stesso destinatario, se c'è un saluto comune in cima a ciascuno.
• Fare riferimento allo stesso progetto, se è presente una stringa di testo identificativa univoca che continua a comparire.
• Avere la stessa classificazione di sicurezza, se desideri concentrarti su cose che sono chiaramente destinate ad essere "più segrete" rispetto alle altre.

Cosa fare?

Non utilizzare la modalità BCE!

Se stai usando un cifrario a blocchi, scegli a modalità operativa cifratura a blocchi che:

• Include ciò che è noto come IV, o vettore di inizializzazione, scelti in modo casuale e univoco per ogni messaggio.
• Organizza deliberatamente il processo di crittografia in modo che gli input ripetuti escano ogni volta in modo diverso.

Se stai usando AES, la modalità che probabilmente vorresti scegliere in questi giorni è AES-GCM (Galois Counter Mode), che non solo utilizza un IV per creare ogni volta un flusso di dati di crittografia diverso, anche se la chiave rimane la stessa, ma calcola anche ciò che è noto come Codice di autenticazione del messaggio (MAC), o checksum crittografico, contemporaneamente alla codifica o alla ricomposizione dei dati.

AES-GCM significa non solo che eviti schemi di testo cifrato ripetuti, ma anche che finisci sempre con un "checksum" che ti dirà se i dati che hai appena decifrato sono stati manomessi lungo il percorso.

Ricorda che un truffatore che non sa cosa significhi effettivamente il testo cifrato potrebbe comunque essere in grado di indurti a fidarti di una decrittazione inesatta senza mai sapere (o preoccuparsi) che tipo di output errato ti ritroverai.

Un MAC calcolato durante il processo di decrittografia, basato sulla stessa chiave e IV, ti aiuterà a garantire che tu sappia che il testo cifrato che hai ricevuto è valido e quindi che hai quasi certamente decrittografato ciò che è stato originariamente inserito dall'altra parte.

In alternativa, utilizzare un apposito codice di flusso che produce un flusso di chiavi pseudo-casuale byte per byte che consente di crittografare i dati senza dover elaborare 16 byte (o qualunque sia la dimensione del blocco) alla volta.

AES-GCM converte essenzialmente AES in un codice a flusso e aggiunge l'autenticazione sotto forma di MAC, ma se stai cercando un codice a flusso dedicato progettato specificamente per funzionare in questo modo, ti suggeriamo il metodo di Daniel Bernstein ChaCha20-Poly1305 (la parte Poly1305 è il MAC), come dettagliato in RFC 8439.

Di seguito, abbiamo mostrato cosa abbiamo ottenuto utilizzando AES-128-GCM e ChaCha20-Poly1305 (qui abbiamo scartato i codici MAC), insieme a un'"immagine" composta da 95,040 byte RGBA (330×72 a 4 byte per pixel) dal Generatore pseudo-casuale del kernel Linux.

Ricorda che solo perché i dati sembrano non strutturati non significa che siano veramente casuali, ma se non sembrano casuali, ma affermano di essere crittografati, potresti anche presumere che sia rimasta qualche struttura e che la crittografia sia sospettare:

Cosa succede dopo?

Secondo WithSecure, Microsoft non prevede di correggere questa "vulnerabilità", apparentemente per motivi di compatibilità con le versioni precedenti di Office 2010...

Le versioni precedenti di Office (2010) richiedono AES 128 ECB e i documenti di Office sono ancora protetti in questo modo dalle app di Office.

…e…

Il rapporto [dei ricercatori WithSecure] non è stato considerato all'altezza del limite per i servizi di sicurezza, né è considerato una violazione. Non è stata apportata alcuna modifica al codice e quindi non è stato emesso alcun CVE per questo rapporto.

In breve, se attualmente ti affidi a OME, potresti prendere in considerazione la possibilità di sostituirlo con uno strumento di crittografia di terze parti per i messaggi sensibili che crittografa i tuoi dati indipendentemente dalle app che hanno creato quei messaggi e quindi funziona indipendentemente dalla crittografia interna codice nella gamma Office.

In questo modo, puoi scegliere una crittografia moderna e una modalità moderna di operazione di crittografia, senza dover tornare al codice di decrittografia della vecchia scuola integrato in Office 2010.

---

COME ABBIAMO REALIZZATO LE IMMAGINI NELL'ARTICOLO Inizia con sop330.png, che puoi creare tu stesso ritagliando il logo SOPHOS ripulito dall'immagine più in alto, rimuovendo il bordo blu di 2 pixel e salvando in formato PNG.  L'immagine dovrebbe avere una dimensione di 330x72 pixel.
 Converti in RGBA utilizzando ImageMagick: $ convert sop330.png sop.rgba L'output è 330x72 pixel x 4 byte/pixel = 95,040 byte.
 === Cifra utilizzando Lua e la libreria LuaOSSL (Python ha un collegamento OpenSSL molto simile): -- carica dati > fdat = misc.filetostr('sop.rgba') > fdat:len() 95040 -- crea oggetti cifrati > aes = openssl.cipher.new('AES-128-ECB') > gcm = openssl.cipher.new('AES-128-GCM') > cha = openssl.cipher.new('ChaCha20-Poly1305') -- inizializza password e IV -- AES-128-ECB necessita di una password a 128 bit, ma nessuna IV -- AES-128-GCM necessita di una password a 128 bit e di una IV a 12 byte -- ChaCha20 necessita di una password a 256 bit e a IV a 12 byte > aes:encrypt('THEPASSWORDIS123') > gcm:encrypt('THEPASSWORDIS123','andkrokeutiv') > cha:encrypt('THEPASSWORDIS123THEPASSWORDIS123','qlxmtosh476g') -- crittografa i dati del file con le tre cifre > aesout = aes:final(fdat) > gcmout = gcm:final(fdat) > chaout = cha:final(fdat) -- un cifrario a flusso produce output byte per byte, -- quindi il testo cifrato dovrebbe avere la stessa lunghezza del testo in chiaro > gcmout:len() 95040 > chaout:len() 95040 -- non utilizzeremo i codici MAC di GCM e Poly1305 qui, -- ma ogni cifra produce un "checksum" a 128 bit (16 byte) - - utilizzato per autenticare la decrittazione al termine, -- per rilevare se il testo cifrato in input viene danneggiato o violato -- (il MAC dipende dalla chiave, quindi un utente malintenzionato non può falsificarlo) > base.hex(gcm:getTag( 16)) a70f204605cd5bd18c9e4da36cbc9e74 > base.hex(cha:getTag(16)) a55b97d5e9f3cb9a3be2fa4f040b56ef -- crea un'"immagine" 95040 direttamente da /dev/random > rndout = misc.filetostr('/dev/random',#f dat) -- salvali tutti - nota che tronchiamo esplicitamente l'output del codice a blocchi -- AES-ECB alla lunghezza esatta dell'immagine richiesta, perché -- ECB necessita di riempimento per far corrispondere la dimensione dell'input con la dimensione del blocco > misc.strtofile(aesout:sub(1 ,#fdat),'aes.rgba') > misc.strtofile(gcmout,'gcm.rgba') > misc.strtofile(chaout,'cha.rgba') > misc.strtofile(rndout,'rnd.rgba') === Per caricare i file in un normale visualizzatore di immagini, potrebbe essere necessario riconvertirli senza perdita di dati in formato PNG: $ convert - Depth 8 -size 330x72 aes.rgba aes.png $ convert - Depth 8 -size 330x72 gcm.rgba gcm.png $ convert - Depth 8 -size 330x72 cha.rgba cha.png $ convert - Depth 8 -size 330x72 rnd.rgba rnd.png === Dato che il processo di crittografia codifica tutti e quattro i byte in ciascun pixel RGBA, il risultato l'immagine ha una trasparenza variabile (A = alfa, abbreviazione di trasparenza).
 Il tuo visualizzatore di immagini potrebbe decidere di visualizzare questo tipo di immagine con uno sfondo a scacchiera, che in modo confuso sembra parte dell'immagine, ma non lo è.  Abbiamo quindi utilizzato il blu Sophos dell'immagine originale come sfondo per i file crittografati per renderli più facili da visualizzare.  La tonalità blu complessiva non fa quindi parte dei dati dell'immagine.