positive hack days. Терешкин. "Злая горничная" атакует pgp

«Злая горничная» атакует PGP

Александр Терешкиннезависимый исследователь

alex.tereshkin@gmail.com

Positive Hack Days 2011, 19 мая, Москва

Отказ от ответственност

иПрезентация содержит результаты

исследования безопасности программного продукта, и

представлена исключительно в обучающих целях на форуме Positive

Hack Days.

Исследования проводились на PGP WDE версии 9.12

Сценарий и реализация атаки «Злая Сценарий и реализация атаки «Злая горничная»горничная»

Возможные методы противодействияВозможные методы противодействия

Системы безопасностиСистемы безопасности PGP WDE PGP WDE

... ... и другие проблемыи другие проблемы PGP WDE PGP WDE

11

22

33

44

Сценарий и Сценарий и реализация атаки реализация атаки «Злая горничная»«Злая горничная»

Полнодисковое шифрование используется для предотвращения несанкционированного доступа к

хранилищам данных.

Так что, если вы теряете полностью шифрованный ноутбук, или кто-то его

крадет, вы думаете: «Ничего страшного, злодеи не получат

данные – а у меня есть бэкапы»

Полагаясь на шифрование, вы начинаете меньше обращать внимание

на физическую безопасность – например, оставляете ноутбук в

номере отеля, когда идете в бассейн.

Но давайте дополним вашу модель атаки (кражу ноутбука) еще одним

пунктом:злоумышленник может покопаться в

вашем ноутбуке, и вы это не заметите.

Двухэтапная атака• Ноутбук оставлен в номере без присмотра

• Атакующая (злая горничная) входит в номер и заражает загрузочный код жесткого диска ноутбука сниффером ключей шифрования путем загрузки со специально подготовленной USB-флэшки или путем подсоединения жесткого диска к ее собственному ноутбуку

• Владелец возвращается в номер, включает ноутбук и вводит ключ

• Ключ шифрования перехватывается сниффером, установленным в загрузочном коде, и сохраняется где-нибудь на диске или передается по сети; на диске восстанавливается исходный немодифицированный загрузчик для скрытия факта атаки

• Теперь атакующая может красть ноутбук – ей известен ключ для дешифровки жесткого диска

Различные методы двухфакторной аутентификации типа смарт-карт и

токенов не добавляют здесь защищенности:

мы не записываем клавиши во время ввода пароля,

мы перехватываем ключ шифрования после того, как он был предоставлен

пользователем

Для этого мы изменяем код FDE в том месте, где он уже готов

расшифровывать диск и может передавать управление загрузчику

ОС.

Там мы получаем ключи шифрования и делаем с ними, что

захотим.

PGP WDE: расположение кода• Во время установки PGP WDE занимает

на диске 1Mb свободных секторов подряд в заданном разделе и сохраняет там свой код и данные.

• Номер первого сектора этого региона сохраняется в MBR. Этот номер будет использован загрузчиком при чтении основного кода.

• WDE не испытывает жесткой нехватки места на диске, поэтому сжатие кода или данных не применяется.

PGP WDE: заражение

• Основная логика загрузочной части WDE находится в модуле, именованном “stage2” в их мини - файловой системе.

• Так как WDE поддерживает несколько типов аутентификации (пароли, смарт-карты, токены), ключ может быть получен в разных участках кода, поэтому надо перехватить их все.

• Фактически, имеется две основных ветки кода, которые надо перехватить:

- Аутентификация по паролю

- Все остальные типы аутентификации (authentication on offload target)

• Оба места в коде могут быть легко найдены по шаблону.

PGP WDE: полезная нагрузка• Нет необходимости иметь сложный код для передачи

ключей по сети сразу после их перехвата, так как ноутбук все равно будет украден в будущем

• Достаточно записать их на диск (возможно, не открытым текстом), откуда атакующий их впоследствии прочтет

• Также, неплохо вычистить все остальные следы заражения путем восстановления исходного загрузочного кода до загрузки ОС, с целью избежать обнаружения антивирусами

• В коде WDE есть удобная функция для чтения и записи секторов – нет необходимости вызывать сервисы BIOS из 32-битного кода самим (код загрузочной части WDE – 32-битный). Эта функция также может быть найдена по шаблону

• BOCHS оказывает неоценимую помощь при отладке и исследовании загрузочного кода

В демонстрационных целях заражение «Злой горничной» можно

сделать более наглядным.

Например, можно зашить перехваченный ключ в код PGP WDE,

так что независимо от того, какой пароль вводится, ключ все равно

остается корректным.

Возможные Возможные методы методы

противодействияпротиводействия

Доверенная загрузка

• Важнейшей задачей является установка цепочки доверия во время исполнения кода. Недоверенный код (код атакующего) не должен быть разрешен к исполнению без санкции пользователя.

• Этого можно добиться с помощью контроля корней доверия (Root of Trust Measurement), статического (Static, SRTM) или динамического (Dynamic, DRTM – Trusted Execution Technology от Intel)

Статический RTM• Начиная с некоего доверенного кода – например,

прошивки, – каждый компонент предварительно измеряется до передачи на него управления путем хэширования SHA-1

• Измерение сохраняется в регистре чипа TPM (PCRn) путем его расширения: результат измерения присоединяется к имеющемуся значению PCR и хэшируется; результат сохраняется в PCR

• Невозможно записать требуемое значение в PCR, можно только расширить существующее

• Таким образом, набор значений PCR, основанный на хэшах доверенных участков кода, представляет собой доверенное состояние системы

• Приложение может запечатать секретный ключ в TPM для указанного набора значений PCR; этот же набор значений PCR будет необходим для распечатывания ключа из TPM

Статический RTM• Сразу после установки системы полнодискового

шифрования пользователь удостоверяется, что система находится в доверенном состоянии, и запечатывает ключ шифрования (или его часть) в TPM для доверенного набора значений PCR

• Позже, если любой элемент цепочки исполнения будет модифицирован атакующим, хэш измененного модуля не совпадет с хэшем доверенного модуля, что приведет к записи в PCR значений, отличающихся от представляющих доверенное состояние

• Таким образом, система полнодискового шифрования не сможет получить ключ шифрования путем распечатывания его из TPM

• Пользователь увидит, что система не может быть загружена, поскольку ее состояние не является доверенным

Динамический RTM

• SRTM строит цепочку доверия начиная с прошивки, BIOS, и заканчивая ядром ОС, что делает общую доверенную кодовую базу (TCB) очень большой

• DRTM позволяет запустить доверенный код в изолированной среде, ограничивая TCB только этой средой, которая может быть небольшой (к примеру, гипервизором)

• Мы не знакомы ни с одной системой полнодискового шифрования, использующей DRTM

• tboot и LUKS могут быть отправной точкой в таком проекте

Системы Системы безопасностибезопасности PGP PGP

WDEWDE

https://pgp.custhelp.com/app/answers/detail/a_id/1448/~/using-trusted-platform-module-%28tpm%29-authentication-with-pgp-wde---pgp-desktop

PGP WDE поддерживает TPM,

так ведь?

Документация не говорит о том, что WDE поддерживает доверенную

загрузку через SRTM или DRTM – он рассчитан только на защиту от

кражи жесткого диска.

Как это реализовано?

Поддержка TPM•PGP WDE использует несколько 32-

битных плагинов для выполнения разных задач. Плагины читаются загрузочным кодом с диска. Для этого WDE использует мини – файловую систему

•Плагин, работающий с TPM, называется PGPTPM. Он взаимодействует с TPM через прерывание BIOS под номером 0x1A (переключаясь в реальный режим из защищенного и обратно)

Поддержка TPM• PGPTPM получает на вход несколько адресов

памяти с данными

• Активно хэширует данные (не код) с помощью SHA-1

• Распечатывает секрет из TPM

• Немного хэширует распечатанный секрет

• Сравнивает два хэша с помощью memcmp()

• Булевское значение – это все, что основной код хочет узнать от плагина TPM

• “xor eax, eax / ret” работает

PGP WDE не запечатывает никакие ключи шифрования в TPM, что делает плагин TPM функцией

«безопасности путем сокрытия»

Другие проблемыДругие проблемы PGP WDEPGP WDE

Представим, что PGP WDE поддерживает цепочку доверия для своего кода, так что мы не можем

нигде модифицировать его так, чтобы не помешать загрузке пользовательской ОС.

Возможно ли каким-нибудь образом получить ключи шифрования, не меняя ни одного байта кода или данных PGP

WDE?

Анализ показывает, что режим работы AES, используемый в PGP

WDE,это CFB с небольшими

изменениями

Измененная схема AES-CFB

• Каждый 0x200-байтный сектор делится на две 0x100-байтных части, обрабатываемых по отдельности

• Для каждой пары векторы инициализации AES в режиме CFB берутся из определенных 16 байт шифротекста другой пары; ведутся две CFB сессии, у каждой из которых – свой IV. Блоки дешифруются по очереди: первый – с первым IV, второй – со вторым, затем опять с первым и так далее

• Байты шифротекста по смещениям [0xe0..0xf0) используются как IV для второй части сектора [0x100..0x1FF], которая дешифруется первой по счету

• Затем расшифрованный по AES-CFB (но еще не являющийся открытым текстом) 16-байтный вектор по смещению 0x1f0 используется как первый IV, и его инверсия используется как второй IV для дешифровки первой части сектора

• 16-байтный вектор по смещению 0x1f0 окончательно расшифровывается путем исключения контрольной суммы

CFB подвержен

ковкости шифротекста

(ciphertext malleability)

Алгоритм шифрования является ковким, если атакующий может трансформировать шифротекст в другой

шифротекст, который расшифровывается в зависимый от исходного открытый текст.

То есть, имея шифротекст открытого текста m, есть возможность сгенерировать другой шифротекст,

расшифровывающийся в f(m), для известной функции f, не обязательно зная или получая m.

В случае CFB атакующий должен знать исходный открытый текст, чтобы создавать шифротекст,

расшифровывающийся в требуемый открытый текст без знания ключа.

Ковкость шифротекста

Расшифровка в режиме CFB

courtesy of Wikipedia

Это может быть не так важно для обмена сообщениями, где открытый текст сложно

предсказуем. Однако, предсказуемостьзагрузчика ОС и прилежащих секторов

очень велика.

Разработчики явно упустили это при составлении модели атак на WDE!

Существует не так много различающихся загрузчиков Windows. Обычно атакующий

знает точную версию ОС, что еще больше уменьшает количество

вариантов.

Также, данные около загрузочного кода тоже очень постоянны.

Что находится под контролем

атакующего?• Для каждой из двух половин сектора ведется две CFB сессии, что

дает 16+16 байт ковкого шифротекста на два раунда двух сессий – мы можем контролировать раунд CFB в каждой сессии за счет повреждения открытого текста в следующем раунде текущей сессии; также, контрольная сумма нарушается, и из-за этого ее исключение разрушает открытый текст последнего 16-байтного региона сектора (на него накладывается XOR контрольной суммы).

• На сектор приходится 4 сессии CFB, по 8 раундов в каждой, итого 32 раунда – значит, мы можем, теоретически, контролировать 16 из них, но :

• Дли расшифровки первых 32-х байт первой половины сектора AES-CFB получает IV из (почти) открытого текста второй половины по смещению 0x1F0, значит, шифротекст по смещению 0x1D0 не должен быть изменен (иначе открытый текст 0x1F0 будет поврежден), если мы хотим модифицировать открытый текст по смещению [0x0..0x1F].

• Это дает нам 7*32 + 16 = 240 байт, которые мы можем выставить по желанию, если нам известен открытый текст сектора.

Изначально зашифрованный сектор, содержащий только нули, с наложенным XOR 0x01 в помеченных участках, после

расшифровки

Чтобы успешно перехватить ключи путем изменения только шифротекста мы должны найти два региона, открытый текст которых известен:

•Зашифрованная точка входа, которую легко изменить без потери работоспособности

•Достаточно большой зашифрованный регион для хранения кода сниффера ключей

Ищем точку заражения

• MBR и загрузочные сектора имеют точку входа в их начале, которое мы можем изменять. Это делает возможным вместить загрузчик основного кода сниффера и трамплин к нему в 240 байт.

• Маркер MBR (0xAA55 по смещению 0x1FE) должен присутствовать в модифицированном секторе после расшифровки – это надо учитывать, так как WDE делает исключение (нарушенной) контрольной суммы из последнего 16-байтного региона сектора.

• Основной код должен восстановить поврежденные модификацией сектора, так что необходимо где-то хранить их копию.

Ищем свободное место

• Первый раздел Windows обычно начинается по смещению 0x7e00

• После загрузочного сектора и загрузчика NTLDR расположено очень много секторов, содержащих одни нули

• Можно быть уверенным, что полное количество последовательно расположенных нулевых секторов не меньше 400

• Мы можем контролировать до 240 байт в каждом секторе, что дает 93Kb общего объема

• Это более чем достаточно для сохранения там тела сниффера вместе с загрузчиком-сборщиком

Решения?

•Очевидно, нужен некий метод аутентификации данных, чтобы атакующий не мог вносить осмысленные и целенаправленные изменения в систему

•MAC нельзя использовать по ряду причин:

- Шифрование происходит на секторном уровне, каждый сектор может быть шифрован и расшифрован отдельно

- Шифротекст не может быть больше открытого текста

Решения?• Microsoft реализовала распылитель открытого

текста, работающий с ключом, (keyed plaintext diffuser) для BitLocker, так как они были вынуждены признать, что единственный жизнеспособный метод аутентификации дисковых данных это «шифрование и вера в то, что изменения в шифротексте не приводят к семантически целесообразным изменениям в открытом тексте»

• Для детальных объяснений, почему MAC неприменимы к дисковому шифрованию, и общим рассуждениям на тему использования распылителей обращайтесь к статье Niels Ferguson “AES-CBC + Elephant diffuser”: http://download.microsoft.com/download/0/2/3/0238acaf-d3bf-4a6d-b3d6-0a0be4bbb36e/BitLockerCipher200608.pdf

Решения?

•Переход на AES-XTS

•Этот режим не был стандартизован, когда Microsoft искал подходящий шифр (стал стандартом NIST 27-го января 2010)

В любом случае, смена шифра будет означать перешифрование всех

клиентских дисков, что занимает гораздо большее время, чем

развертывание обычного обновления ПО

Спасибо за внимание!

Вопросы?

alex.tereshkin@gmail.com