Серйозна безпека: Microsoft Office 365 атакували через слабке шифрування

Зараз ми не зовсім впевнені, як його назвати, тому в заголовку назвали його гібридною назвою Microsoft Офіс 365.

(Назва «Office» як збірний іменник для програм Microsoft для обробки текстів, електронних таблиць, презентацій і спільної роботи вбито протягом наступного місяця чи двох, щоб стати просто «Microsoft 365».)

Ми впевнені, що люди продовжуватимуть використовувати окремі назви програм (слово, перевершувати, PowerPoint і друзі) і псевдонім набору Office протягом багатьох років, хоча новачки в програмному забезпеченні, ймовірно, зрештою знатимуть його як 365, видаливши всюдисущий префікс Microsoft.

Як ви, можливо, знаєте, автономні програми Office (ті, які ви фактично встановлюєте локально, щоб вам не потрібно було виходити в Інтернет, щоб працювати над своїми матеріалами) включають власну опцію для шифрування збережених документів.

Передбачається, що це додасть додатковий рівень безпеки на випадок, якщо ви пізніше випадково чи навмисно поділитеся будь-яким із цих файлів з кимось, хто не мав їх отримати – те, що напрочуд легко зробити помилково, надсилаючи вкладення електронною поштою.

Доки ви також не дасте одержувачу пароль, потрібний для розблокування файлу, для нього це просто нашаткована капуста.

Звичайно, якщо ви включите пароль у тіло електронної пошти, ви нічого не виграєте, але якщо ви бодай трохи обережні щодо надання пароля через інший канал, ви придбали собі додаткову безпеку та захист від шахраїв , шпигуни та нелюди отримують легкий доступ до конфіденційного вмісту.

OME під прожекторами

Або ви?

За оцінками Дослідники у фінській компанії з кібербезпеки WithSecure ваші дані можуть мати набагато менший захист, ніж ви могли очікувати.

Функцію, яку використовували тестери, вони називають Шифрування повідомлень Office 365або ОМЕ для короткого.

Ми не відтворювали тут їхні експерименти з тієї простої причини, що основні продукти Office, вибачте, 365 не працюють у Linux, який ми використовуємо для роботи. Веб-версії інструментів Office не мають такого самого набору функцій, як повноцінні програми, тому будь-які результати, які ми можемо отримати, навряд чи відповідатимуть тому, як більшість бізнес-користувачів Office, ну, 365 налаштували Word, Excel, Outlook і друзів на своїх ноутбуках Windows.

Як це описують дослідники:

Ця функція рекламується, щоб дозволити організаціям безпечно надсилати й отримувати зашифровані електронні листи між людьми всередині та за межами вашої організації.

Але вони також зазначають, що:

На жаль, повідомлення OME зашифровано в режимі незахищеної електронної кодової книги (ECB).

ЄЦБ пояснив

Пояснити.

Багато алгоритмів шифрування, зокрема Шифрування Advanced Encryption Standard або AES, які використовує OME, відомі як блокові шифри, які зашифровують великі фрагменти даних за раз, а не обробляють окремі біти або байти послідовно.

Взагалі кажучи, це має сприяти як ефективності, так і безпеці, оскільки шифр має більше вхідних даних для змішування-подрібнення-подрібнення та ліквідації під час кожного повороту криптографічної рукоятки, яка керує алгоритмом, і кожен поворот веде вас далі через дані, які потрібно зашифрувати.

Основний алгоритм AES, наприклад, споживає 16 вхідних байтів відкритого тексту (128 біт) за раз і шифрує ці дані під ключ шифрування, щоб отримати 16 зашифрованих вихідних байтів зашифрованого тексту.

(Не плутайте розмір блоку з розмір ключа – Ключі шифрування AES можуть мати довжину 128 бітів, 192 біти або 256 бітів, залежно від того, наскільки малоймовірно ви хочете, щоб вони вгадали, але всі три розміри ключів працюють із 128-бітними блоками кожного разу, коли алгоритм «прокручується».)

Це означає, що якщо ви виберете ключ AES (незалежно від довжини), а потім використаєте шифр AES безпосередньо на фрагменті даних…

…тоді кожного разу, коли ви отримуєте той самий вхідний фрагмент, ви отримаєте той самий вихідний фрагмент.

Як справді величезна книга кодів

Тому цей прямий режим роботи називається ECB, скорочено електронна кодова книга, оскільки це схоже на величезну книгу кодів, яку можна використовувати як таблицю пошуку для шифрування та дешифрування.

(Повну «кодову книгу» ніколи не можна створити в реальному житті, тому що вам потрібно буде зберігати базу даних, що складається з 2¹²⁸ 16-байтові записи для кожного можливого ключа.)

На жаль, особливо в комп’ютерно-форматованих даних, повторення певних фрагментів даних часто неминуче завдяки використаному формату файлу.

Наприклад, файли, у яких зазвичай розміщуються розділи даних, щоб вони вишикувались на межі 512 байт (загальний розмір сектора під час запису на диск) або на межі 4096 байт (загальний розмір одиниці розподілу під час резервування пам’яті), часто створюють файли з довгі прогони нульових байтів.

Подібним чином текстові документи, які містять багато шаблонних елементів, наприклад верхніх і нижніх колонтитулів на кожній сторінці, або багаторазове згадування повної назви компанії, будуть містити багато повторів.

Кожного разу, коли повторювана частина відкритого тексту випадково вибудовується на 16-байтовій межі в процесі шифрування AES-ECB, вона з’являється в зашифрованому виведенні як точно такий же зашифрований текст.

Таким чином, навіть якщо ви не можете формально розшифрувати файл зашифрованого тексту, ви можете зробити з нього негайні висновки, що руйнують безпеку, завдяки тому факту, що шаблони у вхідних даних (які ви можете знати або мати можливість зробити висновок, або вгадати) зберігаються у вихідних даних.

Ось приклад, заснований на статті, опублікованій майже дев’ять років тому, коли ми пояснювали, чому сумнозвісне використання компанією Adobe шифрування в режимі ECB для «хешування» паролів своїх користувачів було Не гарна ідея:

Зверніть увагу на те, що пікселі, які є суцільно білими у вхідних даних, надійно створюють повторюваний візерунок у вихідних даних, а сині частини залишаються певною мірою регулярними, так що структура вихідних даних є очевидною.

У цьому прикладі кожен піксель у вихідному файлі займає рівно 4 байти, тому кожен 4-піксельний прогін зліва направо у вхідних даних має довжину 16 байтів, що точно узгоджується з кожним 16-байтовим блоком шифрування AES, таким чином підкреслюючи «ефект ЄЦБ».

---

Зіставлення шаблонів зашифрованого тексту

Ще гірше, якщо у вас є два документи, які, як ви знаєте, зашифровані одним і тим же ключем, і ви випадково маєте відкритий текст одного з них, тоді ви можете переглянути зашифрований текст, який ви не може розшифруйте та спробуйте зіставити його частини з шаблонами в зашифрованому тексті, який ви може розшифрувати.

Пам’ятайте, що вам не потрібен ключ для «дешифрування» першого документа, якщо він у вас уже є в розшифрованому вигляді – це, як не дивно, відомо як атака відомого відкритого тексту.

Навіть якщо є лише кілька збігів очевидно невинного тексту, який сам по собі не є секретними даними, знання, які зловмисник може отримати таким чином, можуть стати золотою жилою для шпигунів інтелектуальної власності, соціальних інженерів, судових слідчих тощо.

Наприклад, навіть якщо ви не знаєте, на що посилаються деталі документа, зіставляючи відомі фрагменти відкритого тексту в кількох файлах, ви можете визначити, що очевидно випадкова колекція документів:

• Усі були надіслані одному одержувачу, якщо у верхній частині кожного є спільне привітання.
• Зверніться до того самого проекту, якщо існує унікальний ідентифікаційний текстовий рядок, який постійно з’являється.
• Мають однакову класифікацію безпеки, якщо ви прагнете зосередитися на речах, які явно мають бути «більш секретними», ніж інші.

Що ж робити?

Не використовуйте режим ECB!

Якщо ви використовуєте блоковий шифр, виберіть a режим роботи блочного шифру що:

• Включає те, що відомо як IV або вектор ініціалізації, вибирається випадково й унікально для кожного повідомлення.
• Навмисно організовує процес шифрування так що повторювані введення кожного разу виходять по-різному.

Якщо ви використовуєте AES, режим, який ви, ймовірно, захочете вибрати сьогодні AES-GCM (Режим лічильника Галуа), який не лише використовує IV для кожного разу створення іншого потоку даних шифрування, навіть якщо ключ залишається незмінним, але також обчислює те, що називається Код аутентифікації повідомлення (MAC), або криптографічну контрольну суму, одночасно зі скремблуванням або дешифруванням даних.

AES-GCM означає не тільки те, що ви уникаєте повторюваних шаблонів зашифрованого тексту, але й що ви завжди отримуєте «контрольну суму», яка покаже вам, чи дані, які ви щойно розшифрували, були підроблені під час цього.

Пам’ятайте, що шахрай, який не знає, що насправді означає зашифрований текст, може, тим не менше, змусити вас довіритися неточному розшифруванню, навіть не знаючи (або не піклуючись про те), який саме неправильний результат ви отримаєте.

MAC, який обчислюється під час процесу дешифрування на основі того самого ключа та IV, допоможе переконатися, що ви знаєте, що отриманий зашифрований текст є дійсним, а отже, ви майже напевно розшифрували те, що спочатку було введено на іншому кінці.

Крім того, скористайтеся спеціальним потоковий шифр який створює псевдовипадковий побайтовий потік ключів, який дозволяє шифрувати дані без необхідності обробляти 16 байт (або будь-якого розміру блоку) за раз.

AES-GCM по суті перетворює AES на потоковий шифр і додає автентифікацію у формі MAC, але якщо ви шукаєте спеціальний потоковий шифр, розроблений спеціально для цієї роботи, ми пропонуємо Деніела Бернштейна ChaCha20-Poly1305 (частина Poly1305 є MAC), як описано в RFC 8439.

Нижче ми показали, що ми отримали за допомогою AES-128-GCM і ChaCha20-Poly1305 (тут ми відкинули MAC-коди), а також «зображення», що складається з 95,040 330 байтів RGBA (72×4 при XNUMX байтах на піксель) із Генератор псевдовипадкових записів ядра Linux.

Пам’ятайте, що те, що дані виглядають неструктурованими, не означає, що вони справді випадкові, але якщо вони не виглядають випадковими, але стверджують, що вони зашифровані, ви також можете припустити, що там залишилася якась структура, і що шифрування є підозрюваний:

Що відбувається далі?

За матеріалами WithSecure, Microsoft не планує виправляти цю «вразливість», мабуть, з причин зворотної сумісності з Office 2010…

Застарілі версії Office (2010) вимагають AES 128 ECB, і документи Office все ще захищені таким чином програмами Office.

… І…

Звіт [дослідників WithSecure] не вважався таким, що відповідає вимогам безпеки, а також порушенням. Код не змінювався, тому для цього звіту не було видано CVE.

Коротше кажучи, якщо ви зараз покладаєтеся на OME, ви можете замінити його стороннім інструментом шифрування для конфіденційних повідомлень, який шифрує ваші дані незалежно від програм, які створили ці повідомлення, і, таким чином, працює незалежно від внутрішнього шифрування. код в асортименті Office.

Таким чином ви можете вибрати сучасний шифр і сучасний режим роботи шифру, не повертаючись до старовинного коду дешифрування, вбудованого в Office 2010.

---

ЯК МИ СТВОРИЛИ ЗОБРАЖЕННЯ У СТАТТІ

Почніть із sop330.png, для якого ви можете створити
самостійно, обрізавши очищений логотип SOPHOS
від самого верхнього зображення, видаливши 2-піксель
синя межа та збереження у форматі PNG.  Розмір зображення має бути 330x72 пікселів.
 Перетворення на RGBA за допомогою ImageMagick:

$ конвертувати sop330.png sop.rgba

Вихід 330x72 пікселів x 4 байти/піксель = 95,040 XNUMX байтів.
 ===

Шифруйте за допомогою Lua та бібліотеки LuaOSSL (Python має дуже
аналогічне прив'язування OpenSSL):

-- завантажити дані
> fdat = misc.filetostr('sop.rgba')
> fdat:len()
95040

-- створювати об'єкти шифру
> aes = openssl.cipher.new('AES-128-ECB')
> gcm = openssl.cipher.new('AES-128-GCM')
> cha = openssl.cipher.new('ChaCha20-Poly1305')

-- ініціалізувати паролі та IV
-- Для AES-128-ECB потрібен 128-бітний пароль, але не IV
-- Для AES-128-GCM потрібен 128-бітний пароль і 12-байтовий IV
-- ChaCha20 потребує 256-бітного пароля та 12-байтового IV
> aes:encrypt('THEPASSWORDIS123')
> gcm:encrypt('THEPASSWORDIS123','andkrokeutiv')
> cha:encrypt('THEPASSWORDIS123THEPASSWORDIS123','qlxmtosh476g')

-- зашифрувати дані файлу за допомогою трьох шифрів
> aesout = aes:final(fdat)
> gcmout = gcm:final(fdat)
> chaout = cha:final(fdat)

-- потоковий шифр створює вихідні дані байт за байтом,
-- тому зашифрований текст має бути такої ж довжини, як і відкритий текст
> gcmout:len()
95040
> chaout:len()
95040

-- ми не будемо використовувати коди MAC від GCM і Poly1305 тут,
-- але кожен шифр створює 128-бітну (16-байтову) "контрольну суму"
-- використовується для автентифікації дешифрування після його завершення,
-- щоб виявити, чи введений зашифрований текст пошкоджено чи зламано
-- (MAC залежить від ключа, тому зловмисник не може його підробити)
> base.hex(gcm:getTag(16))
a70f204605cd5bd18c9e4da36cbc9e74
> base.hex(cha:getTag(16))
a55b97d5e9f3cb9a3be2fa4f040b56ef

-- створити "образ" 95040 прямо з /dev/random
> rndout = misc.filetostr('/dev/random',#fdat)

-- зберегти їх усі - зауважте, що ми явно скорочуємо AES-ECB
-- виведення блокового шифру до точної необхідної довжини зображення, оскільки
-- ECB потребує доповнення, щоб відповідати розміру вхідних даних розміру блоку
> misc.strtofile(aesout:sub(1,#fdat),'aes.rgba')
> misc.strtofile(gcmout,'gcm.rgba')
> misc.strtofile(chaout,'cha.rgba')
> misc.strtofile(rndout,'rnd.rgba')

===

Щоб завантажити файли у звичайний переглядач зображень, ви можете
потрібно конвертувати їх без втрат назад у формат 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

===

Враховуючи, що процес шифрування зашифровує всі чотири
байтів у кожному пікселі RGBA, отримане зображення має
змінна прозорість (A = альфа, скорочення від прозорості).
 Ваш засіб перегляду зображень може вирішити відобразити цей тип
зображення з фоном шахової дошки, що вводить в оману
виглядає як частина зображення, але не є.  Тому ми
використовував Sophos blue з оригінального зображення як a
фон для зашифрованих файлів, щоб зробити їх легшими
бачити.  Тому загальний блакитний відтінок не є частиною
дані зображення.