Подмена SSL-сертификатов как средство перехвата зашифрованного трафика – тема научной статьи по компьютерным и информационным наукам читайте бесплатно текст научно-исследовательской работы в электронной библиотеке КиберЛенинка

Атака типа «заворачивание подписи» (signature wrapping attack, swa)

Добавление цифровой подписи. Источник: https://media.ccc.de/v/36c3-10832-how_to_break_pdfs

Исследователи попробовали добавить еще одно поле /ByteRange сразу после подписи. Первые два значения в нем остаются неизменными, меняется только адрес конца кода подписи. В результате в файле появляется дополнительное пространство, в которое можно добавить какие-нибудь вредоносные объекты и описывающий их раздел XRef.

Атака типа «инкрементальное сохранение» (incremental saving attack, isa)

Добавление инкрементального сохранения. Источник: https://media.ccc.de/v/36c3-10832-how_to_break_pdfs

Следующим экспериментом стало удаление двух последних разделов (то есть обновление в основной раздел добавляется, а новые Xref и Trailer — нет). Некоторые приложения отказались работать с таким файлом. Две программы для просмотра PDF увидели, что разделов нет, и автоматически достроили их, не оповещая об изменении контента. Еще три без каких-либо возражений проглотили такой формат.

Далее исследователи задумались, а что будет, если цифровую подпись взять и просто-напросто скопировать в свое «ручное» обновление. На этом прокололись еще две программы — Foxit и MasterPDF.

Итого — 11 из 22 приложений для работы с PDF так или иначе оказались уязвимы к несложным манипуляциям с разделом. Причем в случае шести из них у пользователя, открывшего с их помощью документ, не было никаких шансов определить, что он был изменен. В остальных пяти случаях, чтобы увидеть факт манипуляции, пользователь должен был войти в меню и попробовать проверить валидность цифровой подписи, но при открытии файла никаких признаков изменения документа заметить также невозможно.

Ближе к теме

Но что, если мы (авторы этих приложений) хотим передавать в них какую-либо дополнительную информацию, которая будет известна только в момент скачивания? Ведь любое изменение файла автоматически делает цифровую подпись недействительной. Какие у нас есть варианты?

  1. Дописывать в название отдаваемого файла требуемые для передачи данные, а веб-сервером через регулярные выражения перенаправлять подобные запросы на один физический файл.
    легко реализуемо;
    внутренности файла остаются нетронутыми и подпись всегда верна;
    передать можно лишь небольшой набор данных (например, несколько идентификаторов);
    при переименовании файла информация пропадает.
  2. Изменять данные внутри файла и переподписывать его при отдаче.
    передать можно любой объем данных;
    при переименовании ничего не теряется;
    переподписывание – очень долгий процесс, если речь идёт про отдачу сотен больших (100 MB ) дистрибутивов игр в секунду, как в нашем случае.
  3. Изменять данные внутри файла и НЕ переподписывать его, сохраняя при этом корректную цифровую подпись.
    передать можно любой объем данных;
    при переименовании ничего не теряется;
    не нужно переподписывать файл;
    это невозможно (или возможно?).

Киберконтрабанда и подделка цифровых подписей — новые типы киберпреступлений

Немецкие криптографы обнаружили
способ подделывать цифровые подписи, а
точнее, переносить их с оригинальных
документов на фальшивые. Ранее считалось,
что это невозможно: цифровая подпись к
каждому документу уникальна, поскольку
сама сформирована из содержимого
подписываемого файла. Соответственно, если
пытаться вырезать цифровую подпись из
одного документа и прикрепить к другому, то
подпись окажется недействительной по
причине несовпадения с содержимым
оригинала. Однако Штефан Люкс из
Маннгеймского университета и Магнус Даум
из Рурского университета обнаружили способ
создавать два разных документа с одной и
той же цифровой подписью. Для этого
эксплуатируется уязвимость, недавно
обнаруженная в распространённом
криптографическом алгоритме, известном под
названием хэш-функции. Алгоритмы такого
рода преобразуют цифровой файл в хэш —
цепочку битов фиксированной длины. Этот хэш
используется вместе с электронным ключом
для генерации подписи. Подпись проверяется
доверенной третьей стороной, которая
удаляет ключ и сравнивает оставшееся число
с оригинальным хэшем документа. Уязвимость
хэш-функций была продемонстрирована ещё в
августе 2004, а затем еще в феврале 2005 года,
когда исследователи-криптоаналитики из
Китая нашли слабину в американском
криптоалгоритме SHA-1. Этот криптоалгоритм
был разработан в Агентстве национальной
безопасности США и принят Национальным
институтом стандартов США в качестве
инструмента для создания электронной
подписи. Оказалось, что его надёжность под
вопросом. С другой стороны, описанные
китайцами атаки рассматривались, скорее,
как демонстрация технических возможностей
— как академический эксперимент, едва ли
применимый на практике. Люкс и Даум
показали, что это не совсем так. Легкий трюк
позволил слить в postscript-формате два
документа так, чтобы по очереди один
показывался, а другой скрывался, при этом
общий хэш файла оставался неизменным. Таким
образом, появляется возможность реальной
подмены документов, заверенных цифровой
подписью. Со всеми вытекающими
последствиями.

Подмена — суть и второго типа атак,
обнаруженного на сей раз уже американскими
специалистами. Метод «контрабандного HTTP-запроса»
предусматривает внедрение вредоносных
пакетов в поток внешне нормальных запросов
к серверу. Американская фирма Watchfire,
специализирующаяся на вопросах сетевой
безопасности, объявила
об обнаружении нового типа сетевых атак,
названного HTTP Request Smuggling («контрабандный
HTTP-запрос»). Этот тип атаки эксплуатирует
различия в том, как определённые комбинации
программного обеспечения обрабатывают HTTP-запросы.
Умело сформированный HTTP-пакет, внедрённый в
поток кажущихся вполне легитимными
запросов, позволяет хакеру произвести
целый ряд злонамеренных действий, включая
дефейсы или внедрение вредоносного кода в
обход средств защиты, настроенных на
фильтрацию небезопасных пакетов данных.
Главная проблема — именно в различных
комбинациях программ, обрабатывающих HTTP-запросы.
Самый простой способ такой «контрабанды»
сводится к отправке пакетов данных с
несколькими заголовками (определяющими
размер пакета), вместо одного. Как выяснили
исследователи, разные программы по-разному
реагируют на наличие нескольких заголовков.
Одни набрасываются на первый, игнорируя
второй, другие — как раз наоборот. Если
хакеру известна комбинация ПО,
установленного на сервере, злоумышленник
может «протащить» вредоносный код на
машину и, например, подгрузить в кэш веб-сайта
фальшивые страницы в обход авторизации.
Другие варианты «контрабандного запроса»
подразумевают использование различий в
объёме данных, которые разные программы
способны обрабатывать, а также в том, как
разные программы реагируют на
форматирование пакетов.

Читайте также:  Как установить сертификат ЭЦП на компьютер?

Невозможное возможно


Фокус заключается вот в чём:

размер секции, описанный в IMAGE_DATA_DIRECTORY может отличаться от фактического размера структуры WIN_CERTIFICATE

, а при проверке цифровой подписи исключается

вся

секция, размер которой описан в IMAGE_DATA_DIRECTORY. При этом добавленное вручную содержимое в эту секцию уже не является частью цифровой подписи и по сути может содержать любой набор данных. Таким образом можно с легкостью добавлять любые данные в содержимое блока «Атрибуты таблицы сертификатов», предварительно изменив размер секции в структуре IMAGE_DATA_DIRECTORY, не повредив при этом цифровую подпись файла. Не забывайте про паддинг файла до размера, кратного 8 байтам.

Вы должны понимать возможные последствия при использовании этого метода, иметь в виду тип передаваемых данных, объем, возможную их обработку и потенциальные дыры, связанные с этим. В ваших же интересах передавать там только такую информацию, которую можно безболезненно удалить/заменить/испортить (в случае, если кто-то захочет это сделать намеренно), но при этом не потерять основную функциональность.

«Конечно, а как же контрольная сумма PE файла?» — спросите вы. Спешу вас успокоить — она не играет никакой роли при запуске и работе обычных EXE файлов. Контрольная сумма проверяется только на критически важных системных файлах, например на неё ориентируется сервис System File Checker (для диагностики пропавших или повреждённых системных файлов).

Немного теории

Ниже представлена структура Windows

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


Также показан формат блока цифровой подписи (структура

#7), используемый Microsoft.

Ключевой момент в этой схеме — наличие блоков, исключаемых при генерации и проверке цифровой подписи. Эти блоки описываются простейшими C структурами:

«Таблица сертификатов» в секции «Директории данных» – это структура IMAGE_DATA_DIRECTORY:

typedef struct _IMAGE_DATA_DIRECTORY {
    DWORD   VirtualAddress;
    DWORD   Size;
} IMAGE_DATA_DIRECTORY, *PIMAGE_DATA_DIRECTORY;

где:

  • VirtualAddress — прямой указатель на атрибуты таблицы сертификатов в PE файле;
  • Size — размер этого блока в PE файле.

«Атрибуты таблицы сертификатов» – это структура WIN_CERTIFICATE:

typedef struct _WIN_CERTIFICATE
{
    DWORD       dwLength;
    WORD        wRevision;
    WORD        wCertificateType;   
    BYTE        bCertificate[ANYSIZE_ARRAY];
} WIN_CERTIFICATE, *LPWIN_CERTIFICATE;

элементы которой содержат следующие значения:

  • dwLength — размер секции Бинарных данных сертификата;
  • wRevision — используемая версия структуры WIN_CERTIFICATE;
  • wCertificateType — устанавливается в значение 0x0002 для цифровых подписей PE файлов. Значение определено в Wintrust.h как WIN_CERT_TYPE_PKCS_SIGNED_DATA;
  • bCertificate — набор данных, содержащий цифровую подпись в формате PKCS#7.


При подписывании PE файла секция атрибутов таблицы сертификатов всегда помещается в конец файла (блок «Оставшееся содержимое» отсутствует). Зная об этой особенности, можно провернуть небольшой трюк с очень заманчивыми результатами.

Структура pdf-файла

Для начала нужно сказать несколько слов о том, как устроен формат PDF. Файл состоит из четырех основных частей: заголовка (Header), где хранится версия PDF; основной части, где размещается контент, который видит пользователь (body); раздела Xref, представляющего собой каталог, в котором перечислены объекты внутри основного раздела и их местонахождение (он служит для корректного отображения контента); и трейлера (trailer) — раздела, с которого программы для чтения PDF начинают обработку документа.

Универсальная подделка подписи (universal signature forgery, usf)

Исследователи решили на всякий случай проверить приложения и при помощи стандартных пентестерских приемов — попробовать заменить значения разных полей на некорректные или просто удалить их. При экспериментах с разделом /contents выяснилось, что если вместо реальной подписи в нем будет значение 0x00, то две программы для просмотра все равно будут успешно валидировать ее.

А что будет, если оставить подпись на месте, но удалить информацию о том, что именно подписано (то есть раздел /ByteRange)? Или поставить в нем вместо реальных значений null? В обоих случаях нашлись приложения, которые валидировали такую подпись.

Итого, четыре программы из 22 имели ошибки в имплементации, которые можно эксплуатировать.

Если посмотреть на сводную таблицу по итогам исследования, то видно, что так или иначе удается обмануть 21 из 22 программ для просмотра PDF. То есть при необходимости почти под каждую из них можно сделать PDF-файл с вредоносным контентом или ложной информацией, но в глазах пользователя он останется подписанным автором.

Забавно, что единственное приложение, не поддавшееся ни на одну из уловок исследователей, это Adobe Reader 9. Проблема в том, что он подвержен RCE-уязвимости, а потому он стоит только у пользователей Linux — просто потому, что это последняя доступная для них версия.

Электронная цифровая подпись для чайников: с чем ее есть и как не подавиться. часть 3

Часть 1
Часть 2

Читайте также:  Полис ОСАГО без техосмотра в 2021 году

В этой части сделаем небольшое отступление от цифровых подписей в сторону того, без чего непосредственно цифровых подписей, да и защиты информации в привычном понимании, не было бы: шифрования. Ведь первое, что приходит на ум, когда идет речь о защите наших данных — это не дать эти данные нехорошему человеку прочитать. Поэтому, перед тем, как продолжить рассмотрение стандартов PGP и S/MIME, стоит закрасить некоторые остающиеся в знаниях белые пятна, и рассмотреть процесс шифрования немного поподробнее.

Шифры и коды существуют, наверное, с того момента, как человечество научилось записывать свои впечатления об окружающем мире на носителях. Если немного вдуматься, даже обыкновенный алфавит — уже шифр. Ведь когда мы читаем какой-либо текст, в нашей голове каждому нарисованному символу сопоставляется некий звук, сочетание звуков, или даже целое понятие, а в голове соседа, который читать не умеет, этого уже не происходит.

Не зная, какому символу и что сопоставлено, мы никогда не сможем понять, что же именно писавший имел ввиду. К примеру, попробуйте взять и прочитать что-то, написанное на иврите, или на китайском языке. Сами алфавиты этих языков будут являться для вас непреодолимым препятствием, даже если с помощью этих символов написаны понятия вашего родного языка.

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

Значит, надо придумать алфавит, который знает только ограниченный круг лиц, и с его помощью записать информацию. Наверняка все читали (или, по крайней мере, слышали) цикл историй про Шерлока Холмса. В этом цикле фигурировал алфавит, составленный из пляшущих человечков (а многие, я думаю, в детстве на его основе составляли свой). Однако, как показывает данная история, наблюдательный человек может разгадать, какой символ и к чему относится. А значит наша информация опять попадет не в те руки.

Что же делать? Придумывать все более и более сложные алфавиты? Но чем более сложный и громоздкий алфавит, тем более неудобно с ним работать, хранить его в тайне. К тому же, насчет тайны есть замечательная поговорка: знают двое – знают все. Ведь самое слабое звено в любом шифре – это человек, который знает, как этот шифр расшифровать.

А почему бы не сделать так, чтобы способ шифрования был сразу известен всем, но расшифровать наши данные было бы нельзя без какого-то ключа? Ведь ключ (в отличие от всего алфавита) маленький, его достаточно легко сделать новый, если что (опять же, в отличие от переработки всего алфавита), легко спрятать. Наиболее наглядно плюсы ключевых систем показывает следующий пример: получателю надо прочитать сосланное вами сообщение. Обычное, на бумаге. Допустим, вы используете секретный алфавит. Тогда, чтобы прочитать сообщение, получатель должен знать алфавит, иметь большой пыльный талмуд, в котором описаны способы расшифровки (ведь алфавит должен быть сложным, чтобы быть надежным) и понимать, как же с этим талмудом работать. С ключами же все проще: вы кладете сообщение в коробку с замком, а получателю достаточно просто вставить подходящий ключик, а знать, как же устроен замок ему совершенно но нужно.
Итак, общеизвестные «алфавиты» и ключи — механизм, существенно более удобный, чем просто алфавиты. Но как же так зашифровать, чтобы все расшифровывалось простым ключом? И вот тут нам на помощь приходит математика, а конкретнее – математические функции, которые можно использовать для замены наших исходных символов на новые.

Вспомним же, что такое функция. Это некоторое соотношение, по которому из одного числа можно получить другое. Зная x и подставляя его в известное нам соотношение y=A*x, мы всегда получим значение y. Но ведь, как правило, верно и обратное: зная y, мы можем получить и x.
Как правило, но далеко не всегда. Для многих зависимостей получить y легко, тогда как x – уже очень трудно, и его получение займет продолжительное время. Вот именно на таких зависимостях и базируется используемое сейчас шифрование.

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

Симметричное шифрование, по большому счету, достаточно слабо отличается от старого доброго секретного алфавита. Собственно говоря, отличается оно как раз наличием ключа – некоторой сравнительно маленькой последовательности чисел, которая используется для шифрования и расшифровывания. При этом, каждая из обменивающихся информацией сторон должна этот ключ знать и хранить в секрете. Огромным плюсом такого подхода является скорость шифрования: ключ, по сути, является достаточно простой и короткой инструкцией, какой символ, когда, и на какой надо заменять. И работает данный ключ в обе стороны (то есть с его помощью можно как заменить все символы на новые, так и вернуть все как было), за что такой способ шифрования и получил название симметричного. Столь же огромным минусом является именно то, что обе стороны, между которыми информация пересылается, должны ключ знать. При этом, стоит нехорошему человеку заполучить ключ, как он тут же прочитает наши столь бережно защищаемые данные, а значит проблема передачи ключа принимающей стороне становится в полный рост.

Читайте также:  Эцп сертификат используют в

Асимметричное шифрование поступает несколько хитрее. Здесь и у нас, и у нашего получателя есть уже два ключа, которые называют открытый и закрытый. Закрытый ключ мы и получатель храним у себя (заметьте, каждый хранит только свой ключ, а значит, мы уже выходим за пределы той самой поговорки про двоих знающих), а открытый мы и получатель можем спокойно передавать кому угодно – наш закрытый, секретный, по нему восстановить нельзя. Итого, мы используем открытый ключ получателя для шифрования, а получатель, в свою очередь, использует свой закрытый ключ для расшифровывания. Плюс данного подхода очевиден: мы легко можем начать обмениваться секретной информацией с разными получателями, практически ничем (принимая условие, что наш получатель свой закрытый ключ не потерял/отдал и т.п., то есть не передал его в руки нехорошего человека) не рискуем при передаче информации. Но, без огромного минуса не обойтись. И здесь он в следующем: шифрование и расшифровывание в данном случае идут очень, очень, очень медленно, на два-три порядка медленнее, чем аналогичные операции при симметричном шифровании. Кроме того, ресурсов на это шифрование тратится также значительно больше. Да и сами ключи для данных операций существенно длиннее аналогичных для операций симметричного шифрования, так как требуется максимально обезопасить закрытый ключ от подбора по открытому. А значит, большие объемы информации данным способом шифровать просто невыгодно.
Подмена SSL-сертификатов как средство перехвата зашифрованного трафика – тема научной статьи по компьютерным и информационным наукам читайте бесплатно текст научно-исследовательской работы в электронной библиотеке КиберЛенинка
Пример использования асимметричного шифрования [Wikipedia]
e — открытый ключ получателя B
d — закрытый ключ получателя B
m — исходная информация отправителя A
c — зашифрованная исходная информация

И снова возникает вопрос: что же делать? А делать нужно следующее: взять, и скомбинировать оба способа. Собственно, так мы и получаем комбинированное шифрование. Наш большой объем данных мы зашифруем по первому способу, а чтобы донести ключ, с помощью которого мы их зашифровали, до получателя, мы сам ключ зашифруем по второму способу. Тогда и получим, что хоть асимметричное шифрование и медленное, но объем зашифрованных данных (то есть ключа, на котором зашифрованы большие данные) будет маленьким, а значит расшифровывание пройдет достаточно быстро, и дальше уже в дело вступит более быстрое симметричное шифрование.

Подмена SSL-сертификатов как средство перехвата зашифрованного трафика – тема научной статьи по компьютерным и информационным наукам читайте бесплатно текст научно-исследовательской работы в электронной библиотеке КиберЛенинка
Пример применения комбинированной системы [Wikipedia]

Все эти механизмы нашли свое применение на практике, и оба наших больших лагеря PGP и S/MIME их используют. Как говорилось в первой статье, асимметричное шифрование используется для цифровой подписи (а именно, для шифрования нашего хэша). Отличие данного применения от обычного асимметричного шифрования в том, что для шифрования используется наш закрытый ключ, а для расшифровывания достаточно наличие связанного с ним (то есть, тоже нашего) открытого ключа. Поскольку открытый ключ мы не прячем, наш хэш можем прочитать кто угодно, а не только отдельный получатель, что и требуется для цифровой подписи.
Комбинированное же шифрование применяется в обоих стандартах непосредственно для шифрования отправляемых данных.

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

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

В качестве заключения: кто и как этим пользуется?

Эту возможность использует Google при распространении своих продуктов через автоматический апдейтер Google Omaha. Возможно, вы замечали, что при загрузке Google Chrome или Google Earth, вам предлагают сделать некоторые настройки ещё перед скачиванием, например, установить вместе с Earth браузер Chrome.

Также эту возможность удобно использовать в различных партнёрских сетях – отдача дистрибутивов с трекингом партнёра — необходимость в различных компаниях.

Механизм по отдаче файлов с веб-сервера с использованием этой фичи может быть реализован с помощью самописного плагина для nginx, виртуальной файловой системы на основе FUSE, или ещё каким-нибудь более экзотическим способом (расскажите в комментах, если придумали свой вариант).

Информацию о цифровых подписях PE файлов можно почерпнуть из этого документа: Windows Authenticode Portable Executable Signature Format.

Практические выводы

Какой практический вывод можно сделать из этого? Во-первых, что не стоит слепо доверять цифровой подписи PDF-файла. Если где-то рисуют зеленую галочку, это не значит, что подпись действительно валидна.

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Adblock
detector