Keamanan Serius: Microsoft Office 365 diserang karena enkripsi yang lemah

Kami tidak yakin harus menyebutnya apa sekarang, jadi kami menyebutnya di judul dengan nama hibrida Microsoft Office 365.

(Nama “Office” sebagai kata benda kolektif untuk aplikasi pengolah kata, spreadsheet, presentasi, dan kolaborasi Microsoft sedang terbunuh selama satu atau dua bulan ke depan, menjadi "Microsoft 365".)

Kami yakin bahwa orang akan terus menggunakan nama aplikasi individual (Word, Excel, PowerPoint dan teman-teman) dan moniker suite Office selama bertahun-tahun, meskipun pendatang baru di perangkat lunak mungkin akan mengetahuinya sebagai 365, setelah menghapus awalan Microsoft yang ada di mana-mana.

Seperti yang Anda ketahui, aplikasi mandiri Office (yang sebenarnya Anda instal secara lokal sehingga Anda tidak perlu online untuk mengerjakan barang-barang Anda) menyertakan opsi mereka sendiri untuk mengenkripsi dokumen yang disimpan.

Ini seharusnya menambahkan lapisan keamanan ekstra jika nanti Anda membagikan file itu, secara tidak sengaja atau dirancang, dengan seseorang yang tidak seharusnya menerimanya – sesuatu yang sangat mudah dilakukan secara tidak sengaja saat berbagi lampiran melalui email.

Kecuali dan sampai Anda juga memberi penerima kata sandi yang mereka butuhkan untuk membuka kunci file, itu hanya kol yang diparut bagi mereka.

Tentu saja, jika Anda memasukkan kata sandi di badan email, Anda tidak mendapatkan apa-apa, tetapi jika Anda bahkan sedikit berhati-hati dalam membagikan kata sandi melalui saluran yang berbeda, Anda telah membeli sendiri beberapa keamanan dan keamanan ekstra terhadap penyamun. , snoops dan ne'er-do-wells mendapatkan akses mudah ke konten rahasia.

OME di bawah sorotan

Atau memiliki Anda?

Menurut peneliti di perusahaan keamanan siber Finlandia WithSecure, data Anda dapat menikmati perlindungan yang jauh lebih sedikit daripada yang mungkin Anda harapkan.

Fitur yang digunakan penguji adalah apa yang mereka sebut sebagai Enkripsi Pesan Office 365, atau OME Singkatnya.

Kami belum mereproduksi eksperimen mereka di sini, karena alasan sederhana bahwa Office inti, maaf, produk 365 tidak berjalan secara asli di Linux, yang kami gunakan untuk bekerja. Alat Office versi berbasis web tidak memiliki kumpulan fitur yang sama seperti aplikasi lengkap, sehingga hasil apa pun yang mungkin kami peroleh kemungkinan tidak sesuai dengan cara sebagian besar pengguna bisnis Office, ah, 365 telah mengonfigurasi Word, Excel, Outlook dan teman-teman di laptop Windows mereka.

Seperti yang peneliti jelaskan:

Fitur ini diiklankan untuk memungkinkan organisasi mengirim dan menerima pesan email terenkripsi antara orang-orang di dalam dan di luar organisasi Anda dengan cara yang aman.

Tetapi mereka juga menunjukkan bahwa:

Sayangnya pesan OME dienkripsi dalam mode operasi Electronic Codebook (ECB) yang tidak aman.

ECB menjelaskan

Untuk menjelaskan.

Banyak algoritma enkripsi, terutama yang Advanced Encryption Standard atau AES, yang digunakan OME, adalah apa yang dikenal sebagai cipher blok, yang mengacak potongan data berukuran besar sekaligus, daripada memproses bit atau byte individual secara berurutan.

Secara umum, ini seharusnya membantu efisiensi dan keamanan, karena cipher memiliki lebih banyak data input untuk mencampur-aduk-cacah-dan-cairkan di setiap putaran pegangan engkol kriptografi yang menggerakkan algoritme, dan setiap putaran membawa Anda lebih jauh melalui data yang ingin Anda enkripsi.

Algoritme inti AES, misalnya, menggunakan 16 byte input plaintext (128 bit) sekaligus, dan mengacak data tersebut di bawah kunci enkripsi untuk menghasilkan 16 byte output ciphertext terenkripsi.

(Jangan bingung Ukuran blok dengan ukuran kunci – Kunci enkripsi AES dapat memiliki panjang 128 bit, 192 bit, atau 256 bit, tergantung seberapa kecil kemungkinan Anda ingin menebaknya, tetapi ketiga ukuran kunci tersebut bekerja pada blok 128 bit setiap kali algoritme "diputar".)

Artinya adalah jika Anda memilih kunci AES (berapa pun panjangnya) dan kemudian menggunakan cipher AES langsung pada sepotong data…

…kemudian setiap kali Anda mendapatkan potongan input yang sama, Anda akan mendapatkan potongan output yang sama.

Seperti buku kode yang sangat besar

Itu sebabnya mode operasi langsung ini disebut ECB, kependekan dari buku kode elektronik, karena ini seperti memiliki buku kode besar yang dapat digunakan sebagai tabel pencarian untuk enkripsi dan dekripsi.

("Buku kode" lengkap tidak akan pernah dapat dibuat dalam kehidupan nyata, karena Anda harus menyimpan database yang terdiri dari 2¹²⁸ Entri 16-byte untuk setiap kunci yang mungkin.)

Sayangnya, terutama pada data berformat komputer, pengulangan potongan data tertentu sering kali tidak dapat dihindari, berkat format file yang digunakan.

Misalnya, file yang secara rutin mengisi bagian data sehingga berbaris pada batas 512 byte (ukuran sektor umum saat menulis ke disk) atau hingga batas 4096 byte (ukuran unit alokasi umum saat memesan memori) akan sering menghasilkan file dengan jangka panjang nol byte.

Demikian juga, dokumen teks yang berisi banyak boilerplate, seperti header dan footer di setiap halaman, atau penyebutan nama lengkap perusahaan secara berulang, akan berisi banyak pengulangan.

Setiap kali potongan plaintext berulang kebetulan berbaris pada batas 16-byte dalam proses enkripsi AES-ECB, karena itu akan muncul dalam output terenkripsi sebagai ciphertext yang sama persis.

Jadi, bahkan jika Anda tidak dapat mendekripsi file ciphertext secara formal, Anda mungkin dapat langsung membuat kesimpulan yang menghancurkan keamanan darinya, berkat fakta bahwa pola dalam input (yang mungkin Anda ketahui, atau dapat Anda simpulkan, atau menebak) dipertahankan dalam output.

Berikut adalah contoh berdasarkan artikel yang kami terbitkan hampir sembilan tahun yang lalu ketika kami menjelaskan mengapa penggunaan enkripsi mode ECB oleh Adobe untuk "menghash" kata sandi penggunanya adalah Bukan Ide Bagus:

Perhatikan bagaimana piksel-piksel yang berwarna putih pekat dalam input dapat diandalkan menghasilkan pola berulang dalam output, dan bagian biru tetap agak teratur, sehingga struktur data asli terlihat jelas.

Dalam contoh ini, setiap piksel dalam file asli membutuhkan tepat 4 byte, sehingga setiap 4-piksel kiri-ke-kanan yang berjalan dalam data input panjangnya 16 byte, yang sejajar persis dengan setiap blok enkripsi AES 16-byte, sehingga menonjolkan "Efek ECB".

---

Mencocokkan pola ciphertext

Lebih buruk lagi, jika Anda memiliki dua dokumen yang Anda tahu dienkripsi dengan kunci yang sama, dan Anda hanya memiliki plaintext salah satunya, maka Anda dapat melihat melalui ciphertext yang Anda tidak bisa dekripsi, dan coba cocokkan bagian-bagiannya dengan pola dalam teks sandi yang Anda bisa mendekripsi.

Ingatlah bahwa Anda tidak memerlukan kunci untuk "mendekripsi" dokumen pertama jika Anda sudah memilikinya dalam bentuk yang didekripsi - ini dikenal, tidak mengejutkan, sebagai serangan teks biasa yang diketahui.

Bahkan jika hanya ada beberapa kecocokan teks yang tampaknya tidak bersalah yang bukan merupakan data rahasia itu sendiri, pengetahuan yang dapat diekstraksi oleh musuh dengan cara ini dapat menjadi tambang emas bagi mata-mata kekayaan intelektual, insinyur sosial, penyelidik forensik, dan banyak lagi.

Misalnya, bahkan jika Anda tidak tahu apa yang dirujuk oleh detail dokumen, dengan mencocokkan potongan teks biasa yang diketahui di beberapa file, Anda mungkin dapat menentukan bahwa kumpulan dokumen yang tampaknya acak:

• Semua dikirim ke penerima yang sama, jika ada salam umum di bagian atas masing-masing.
• Merujuk pada proyek yang sama, jika ada string teks pengenal unik yang terus bermunculan.
• Memiliki klasifikasi keamanan yang sama, jika Anda ingin berfokus pada hal-hal yang jelas-jelas dimaksudkan untuk menjadi "lebih rahasia" daripada yang lain.

Apa yang harus dilakukan?

Jangan gunakan mode ECB!

Jika Anda menggunakan cipher blok, pilih a mode operasi cipher blok bahwa:

• Termasuk apa yang dikenal sebagai IV, atau vektor inisialisasi, dipilih secara acak dan unik untuk setiap pesan.
• Sengaja mengatur proses enkripsi sehingga input berulang keluar berbeda setiap waktu.

Jika Anda menggunakan AES, mode yang mungkin ingin Anda pilih akhir-akhir ini adalah AES-GCM (Mode Penghitung Galois), yang tidak hanya menggunakan IV untuk membuat aliran data enkripsi yang berbeda setiap saat, meskipun kuncinya tetap sama, tetapi juga menghitung apa yang dikenal sebagai Kode Otentikasi Pesan (MAC), atau checksum kriptografi, pada saat yang sama dengan mengacak atau mengacak data.

AES-GCM tidak hanya berarti bahwa Anda menghindari pola ciphertext berulang, tetapi juga bahwa Anda selalu berakhir dengan "checksum" yang akan memberi tahu Anda jika data yang baru saja Anda dekripsi dirusak di sepanjang jalan.

Ingat bahwa seorang penjahat yang tidak tahu apa arti sebenarnya dari ciphertext mungkin tetap dapat menipu Anda untuk mempercayai dekripsi yang tidak tepat tanpa pernah mengetahui (atau peduli) jenis output yang salah yang Anda dapatkan.

MAC yang dihitung selama proses dekripsi, berdasarkan kunci dan IV yang sama, akan membantu memastikan bahwa Anda mengetahui bahwa ciphertext yang Anda terima valid, dan oleh karena itu Anda hampir pasti telah mendekripsi apa yang awalnya dimasukkan di ujung yang lain.

Atau, gunakan khusus sandi aliran yang menghasilkan keystream byte demi byte pseudo-acak yang memungkinkan Anda mengenkripsi data tanpa harus memproses 16 byte (atau berapa pun ukuran bloknya) sekaligus.

AES-GCM pada dasarnya mengubah AES menjadi stream cipher dan menambahkan otentikasi dalam bentuk MAC, tetapi jika Anda mencari stream cipher khusus yang dirancang khusus untuk bekerja seperti itu, kami sarankan Daniel Bernstein's ChaCha20-Poli1305 (bagian Poly1305 adalah MAC), seperti yang dijelaskan dalam RFC 8439.

Di bawah ini, kami telah menunjukkan apa yang kami dapatkan menggunakan AES-128-GCM dan ChaCha20-Poly1305 (kami membuang kode MAC di sini), bersama dengan "gambar" yang terdiri dari 95,040 RGBA byte (330×72 pada 4 byte per piksel) dari Generator pseudo-acak kernel Linux.

Ingat bahwa hanya karena data terlihat tidak terstruktur tidak berarti bahwa itu benar-benar acak, tetapi jika tidak terlihat acak, namun mengklaim dienkripsi, Anda mungkin juga berasumsi bahwa ada beberapa struktur yang tertinggal, dan enkripsi mengira:

Apa yang akan terjadi selanjutnya?

Menurut WithSecure, Microsoft tidak berencana untuk memperbaiki "kerentanan" ini, tampaknya karena alasan kompatibilitas mundur dengan Office 2010…

Office versi lawas (2010) memerlukan AES 128 ECB, dan dokumen Office masih dilindungi dengan cara ini oleh aplikasi Office.

…dan…

Laporan [Peneliti WithSecure] tidak dianggap memenuhi standar untuk layanan keamanan, juga tidak dianggap sebagai pelanggaran. Tidak ada perubahan kode yang dibuat sehingga tidak ada CVE yang dikeluarkan untuk laporan ini.

Singkatnya, jika saat ini Anda mengandalkan OME, Anda mungkin ingin mempertimbangkan untuk menggantinya dengan alat enkripsi pihak ketiga untuk pesan sensitif yang mengenkripsi data Anda secara independen dari aplikasi yang membuat pesan tersebut, dan dengan demikian bekerja secara independen dari enkripsi internal kode dalam rentang Office.

Dengan begitu, Anda dapat memilih sandi modern dan mode operasi sandi modern, tanpa harus kembali ke kode dekripsi jadul yang ada di Office 2010.

---

BAGAIMANA KAMI MEMBUAT GAMBAR DALAM ARTIKEL Mulailah dengan sop330.png, yang dapat Anda buat sendiri dengan memotong logo SOPHOS yang sudah dibersihkan dari gambar paling atas, menghapus batas biru 2 piksel, dan menyimpannya dalam format PNG.  Gambar harus berukuran 330x72 piksel.
 Konversi ke RGBA menggunakan ImageMagick: $ convert sop330.png sop.rgba Outputnya adalah 330x72 piksel x 4 byte/piksel = 95,040 byte.
 === Enkripsi menggunakan Lua dan pustaka LuaOSSL (Python memiliki pengikatan OpenSSL yang sangat mirip): -- memuat data > fdat = misc.filetostr('sop.rgba') > fdat:len() 95040 -- buat objek sandi > aes = openssl.cipher.new('AES-128-ECB') > gcm = openssl.cipher.new('AES-128-GCM') > cha = openssl.cipher.new('ChaCha20-Poly1305') -- inisialisasi kata sandi dan infus -- AES-128-ECB membutuhkan kata sandi 128-bit, tetapi tidak ada IV -- AES-128-GCM membutuhkan kata sandi 128-bit dan IV 12-byte -- ChaCha20 membutuhkan kata sandi 256-bit dan a 12-byte IV > aes:encrypt('THEPASSWORDIS123') > gcm:encrypt('THEPASSWORDIS123','andkrokeutiv') > cha:encrypt('THEPASSWORDIS123THEPASSWORDIS123','qlxmtosh476g') -- mengenkripsi data file dengan tiga sandi > aesout = aes:final(fdat) > gcmout = gcm:final(fdat) > chaout = cha:final(fdat) -- stream cipher menghasilkan keluaran byte-by-byte, -- jadi ciphertext harus sama panjangnya dengan plaintext > gcmout:len() 95040 > chaout:len() 95040 -- kami tidak akan menggunakan kode MAC dari GCM dan Poly1305 di sini, -- tetapi setiap cipher menghasilkan "checksum" 128-bit (16-byte) -- digunakan untuk mengautentikasi dekripsi setelah selesai, -- untuk mendeteksi jika ciphertext input rusak atau diretas -- (MAC tergantung pada kuncinya, jadi penyerang tidak dapat memalsukannya) > base.hex(gcm:getTag(16)) a70f204605cd5bd18c9e4da36cbc9e74 > base.hex(cha:getTag(16)) a55b97d5e9f3cb9a3be2fa4f040b56ef -- buat langsung dari 95040 "image" = misc.filetostr('/dev/random',#fdat) -- simpan semuanya - perhatikan bahwa kami secara eksplisit memotong AES-ECB -- memblokir keluaran cipher ke panjang gambar yang tepat yang diperlukan, karena -- ECB membutuhkan padding agar sesuai dengan masukan ukuran dengan ukuran blok > misc.strtofile(aesout:sub(1,#fdat),'aes.rgba') > misc.strtofile(gcmout,'gcm.rgba') > misc.strtofile(chaout,'cha. rgba') > misc.strtofile(rndout,'rnd.rgba') === Untuk memuat file dalam penampil gambar biasa, Anda mungkin perlu mengonversinya tanpa kehilangan kembali ke format PNG: $ convert -depth 8 -size 330x72 aes .rgba aes.png $ konversi -kedalaman 8 -ukuran 330x72 gcm.rgba gcm.png $ convert -depth 8 -size 330x72 cha.rgba cha.png $ convert -depth 8 -size 330x72 rnd.rgba rnd.png === Mengingat bahwa proses enkripsi mengacak keempat byte di setiap piksel RGBA , gambar yang dihasilkan memiliki transparansi variabel (A = alpha, kependekan dari tranparency).
 Penampil gambar Anda mungkin memutuskan untuk menampilkan gambar semacam ini dengan latar belakang kotak-kotak, yang secara membingungkan terlihat seperti bagian dari gambar, padahal sebenarnya tidak.  Oleh karena itu, kami menggunakan Sophos blue dari gambar asli sebagai latar belakang untuk file terenkripsi agar lebih mudah dilihat.  Oleh karena itu, rona biru keseluruhan bukan merupakan bagian dari data gambar.