Цифровая подпись исполняемого файла

Цифровые подписи для исполняемых файлов

Цифровая подпись — это блок из зашифрованной информации, добавленной в определенные файлы для идентификации создателя и индикации изменений в файле с момента применения цифровой подписи.

Исполняемые файлы с цифровой подписью обладают следующими преимуществами.

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

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

Исполняемые файлы, связанные с продуктами на базе AutoCAD

Исполняемый код может содержаться в файлах следующих типов: ARX, CRX, CUI, CUIx, DBX, DLL, DVB, EXE, FAS, HDI, JS, LSP, MNL, PGP, RX, SCR и VLX. Компания Autodesk обеспечивает защиту данных за счет добавления цифровой подписи в исполняемые файлы в программных продуктах. При этом файлы с расширением CUI, CUIx, DVB, JS, PGP и SCR могут содержать исполняемый код, но добавить цифровую подпись в них нельзя. Рекомендуется размещать файлы такого типа в папках со свойством «только для чтения», доступ к которым имеет менеджер САПР или администратор сети.

Неверные цифровые подписи

Цифровая подпись станет неверной по следующим причинам:

• После добавления цифровой подписи файл был изменен.
• Файл был поврежден при передаче или во время добавления цифровой подписи.
• Цифровой сертификат отозван выдавшим его центром сертификации.

Прим.: Переименование файла не аннулирует цифровую подпись.

Цифровые подписи и файлы AutoLISP

Для добавления цифровой подписи к файлу AutoLISP необходимо иметь цифровой сертификат, выданный независимым центром сертификации. Можно также создать самозаверяющий сертификат с помощью одной из утилит.

Чтобы обеспечить целостность общих исполняемых файлов AutoLISP, следует использовать утилиту AcSignAply для применения цифровой подписи к файлам. Если в дальнейшем потребуется изменить файл AutoLISP с цифровой подписью, следует вручную удалить блок цифровой подписи в конце файла и назначить новую цифровую подпись.

Понятия, связанные с данным

• Цифровые подписи для файлов пользовательских программ
• Взломанные копии программных продуктов
• Сведения о цифровых подписях для чертежей

Задачи, связанные с данной

Code Signing сертификаты подписи кода

Подписание кода — это процесс цифровой подписи исполняемых файлов и скриптов для подтверждения личности автора программного обеспечения и гарантии того, что код не был изменен или поврежден с момента его подписания. Публично доверенные сертификационные центры (ЦС) подтверждают удостоверения подписчиков и связывают их открытый ключ с сертификатом подписи кода.

Зачем нужен сертификат кода подписи?

Большинство продаваемых сегодня вычислительных устройств массового рынка поставляются с предварительно загруженным программным обеспечением, но программное обеспечение, поставляемое с устройством «из коробки», стареет и часто требует обновления. Для персонального компьютера или мобильного устройства пользователи часто сталкиваются с ситуациями, когда им необходимо загрузить обновленное программное обеспечение или приложение, ногда обновление происходит в автоматическом режиме. Пользователям рекомендуется использовать приложение на своем устройстве или посещаемом им сайте, чтобы, чтобы испытать или использовать предлагаемое им, им необходимо обновить, исправить или расширить свое текущее программное обеспечение. Их просят принять правильное решение: «Запустить» или «Не запускать».>

В этой ситуации операционная система спрашивает Разрешить или Неразрешить «run / do not run» у пользователя, следует ли запускать загруженный код. Как решит пользователь? Как пользователь или пользовательский агент например «браузер» знает, доверять ли вам программному обеспечению или нет? Ответ — это наличие подписи кода. Чтобы помочь пользователю принять решение, издатель программного обеспечения может в цифровой форме подписать свой код. Цифровая подпись отвечает на вопросы аутентификации и целостности кода, то есть:

• Кто подписал код?
• Был ли изменен код с момента его подписания?

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

Code Signing процедура подписи кода

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

Чтобы подписать код, издателю необходимо иметь пару: открытый и закрыты ключь. В Центр сертификации отправляется запрос на выдачу сертификата подписи кода. CA проверяет подлинность издателя и подтверждает подлинность сертификата, подписанного цифровым подписчиком. Если этот процесс проверки и проверки ключа успешный, ЦС связывает личность издателя с открытым ключом и подписывает пакет, создавая сертификат подписи кода.

Вооруженный сертификатом подписи кода, издатель готов подписать код. Когда код подписан, к исходному файлу, содержащему исполняемый код, добавляется несколько фрагментов информации. Эта связанная информация используется пользовательским агентом получателя для аутентификации издателя и проверки на фальсификацию кода. Вся последовательность для объединения кода с цифровой подписью выполняется следующим образом:

• Вычисляется хеш кода
  • Алгоритмы с открытым ключом неэффективны для подписи больших объектов, поэтому код передается через алгоритм хеширования, создавая дайджест фиксированной длины файла
  • Хэш представляет собой криптографически уникальное представление файла
  • Хэш воспроизводится только с использованием неизмененного файла и алгоритма хэширования, который использовался для создания хэша
• Хэш подписывается с использованием закрытого ключа издателя
  • Хэш передается посредством алгоритма подписи с использованием закрытого ключа издателя в качестве входного
  • Информация об издателе и ЦС берется из сертификата подписи кода и включается в подпись
• Оригинальный код, подпись и сертификат подписываются вместе
  • Ссертификат для подписи кода добавляется в пакет, поскольку открытый ключ требуется для аутентификации кода при его проверке

Проверка подлинности кода

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

Подпись проверяется следующим образом:

1. Исходный код передается через алгоритм хеширования для создания хэша
2. Открытый ключ издателя извлекается из пакета и применяется к сигнатурной информации; применение открытого ключа показывает хэш, который был рассчитан при подписании файла
3. Сравнение двух хэшей; если он равен, то код не изменился и подпись считается действительной
4. Сертификат подписи кода проверяется, чтобы убедиться, что он был подписан доверенным центром сертификации
5. Дата истечения срока действия сертификата подписи кода проверяется
6. Сертификат подписи кода проверяется в списках аннулирования, чтобы убедиться, что он действителен
7. Если файл считается действительным, он принимается агентом пользователя; если файл не считается действительным, пользовательский агент отображает диалог доверия, аналогичный приведенному выше

Как подписать код сертификатом

• Adobe AIR – Digitally signing an AIR file
• Firefox XPI – Signing an XPI
• Java – How to Sign Applets Using RSA-Signed Certificates и Signing Code and Granting it Permissions
• Microsoft Authenticode – Signing and Checking Code with Authenticode
• Microsoft Windows Macro and Visual Basic Signing – Signing a VBA Project

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

Вот типичное предупреждение безопасности проверки кода. Код был подписан, пользователь начал установку и проверку. Как пользователю определиться, принимать или не принимать код?

Пользователь должен принять свое доверительное решение на основании вышеизложенного. В заявлении содержится следующее:
Название файла: AdbeRdr1010_en_US.exe
Издатель, автор файла: Adobe Systems, Incorporated
Code Signing сертификат: нажмите на ссылку с именем издателя

• Планируете ли вы установить программное обеспечение? Если да, переходите к следующему шагу.
• Проверьте имя файла и посмотрите, указывает ли оно на программное обеспечение, которое вы планировали установить. В этом случае это Adobe Reader 10, на которое указывает это имя.
• Проверьте имя издателя и посмотрите, соответствует ли это тому, кто, по вашему мнению, написал программное обеспечение. Это может быть сложно, поскольку сайт загрузки программного обеспечения может отличаться от сайта издателя.
• Проверьте сертификат подписи кода и посмотрите, указано ли имя издателя в сертификате. Кроме того, пользователь может доверять сертификату на основе выдающего ЦС.

Так выгляди диалог с пользователем когда он запускает неподписанный цифровой подписью код

Название файла: App.exe
Издатель, автор файла: Unknown Publisher

«Неизвестный издатель», означает, что публичный ЦС не проверял сертификат подписи кода. Код может быть вредным, но, скорее всего, он подписан с самовыраженным сертификатом подписи кода или не подписан. Это означает, что вы не можете доверять, кто подписал код. Таким образом, вы не должны доверять коду.

Что такое Метка времени Time-Stamping?

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

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

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

• Подпись отправляется в орган фиксации времени time-stamping authority — TSA.
• TSA добавляет отметку времени к связанной информации и вычисляет новый хеш.
• TSA подписывает новый хэш с его закрытым ключом, создавая новый набор информации.
• Пакет с меткой времени, исходный пакет (который был отправлен в TSA) и метка времени повторно связаны с исходным кодом.

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

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

Самоподписанные и выпущенные центрами сертификации сертификаты для подписи кода

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

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

Самоподписаный сертификат	Сертификат выпущенный центром сертификации
Эмитент предоставляет свою личность, которая не публикуется в доверительном диалоге	CA выполняет проверку подлинности, которая отображается в диалоге доверия
Эмитент предоставляет свою собственную политику и качество	CA выдает сертификаты в соответствии с отраслевой политикой и качеством
Подписи будут предоставлять предупреждение о доверии, указывающее, что был неизвестный издатель, и отобразит «Неизвестный издатель»	Подписи обеспечат положительный диалог доверия
Скомпрометированные сертификаты не могут быть отменены и могут нанести вред пользователям вашего программного обеспечения	Скомпрометированные сертификаты могут быть отменены, и если используется штамп времени, код, подписанный до отзыва, останется надежным

Для доверия пользователей и долговечности вашего кода рекомендуется использовать сертификат, выпущенный из центра сертификации, которому доверяют.

 DV OV EV WC SAN PRO CodeSign Email PDF Wi-Fi IoT ALL Купить сертификат

Copyright © 1997-2024 adgrafics

Heaventools

главная программы pe explorer обзорный тур

Просмотр цифровой подписи

Идентификация производителя файла

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

Технология подписи программного кода Authenticode® от Microsoft основана на использовании цифровой подписи, которая, в свою очередь, основана на использовании цифрового сертификата, выданного производителю программного обеспечения доверенной третьей стороной (удостоверяющим центром) после тщательной проверки сведений, сообщённых производителем ПО о себе.

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

Цифровая подпись исполняемого файла представляет собой блок данных, вставленных в конец файла. Во время подписи файла вычисляется хэш-сумма файла, так называемый дайджест сообщения (message digest) – уникальная последовательность байт определенной длины. Этот хэш шифруется с использованием алгоритма RSA с применением закрытого ключа владельца сертификата. Полученная последовательность байт вместе с сертификатом, в котором находится открытый ключ для обратной расшифровки и верификации дайджеста, и образует блок данных цифровой подписи.

Проверка валидности цифровой подписи

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

Далее PE Explorer извлекает из блока цифровой подписи зашифрованный хэш файла и дешифрует его с помощью извлечённого из сертификата публичного ключа. Полученное значение отображается как Signed File Hash.

Затем PE Explorer вычисляет хэш-сумму файла самостоятельно и сравнивает полученное значение (Real File Hash) с оригинальным (Signed File Hash). Дополнительно производится вычисление и сравнение значений фактической контрольной суммы файла с той, что указана в заголовке файла.

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

Если хэш-суммы (Signed File Hash и Real File Hash) не совпадают, значит, файл уже после подписания кто-то пытался изменить (например, вирус или хакер):

Просмотр деталей сертификата

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

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

Обзорный тур
назад | след.

Copyright © 2024 Heaventools Software. Все права сохранены.

Цифровые подписи в исполняемых файлах и обход этой защиты во вредоносных программах

Хабрапривет!

Ну вроде как удалось решить вопросы с кармой, но они ником образом не касаются сегодняшней темы, а лишь объясняют некоторое опоздание её выхода на свет (исходные планы были на ноябрь прошлого года).

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

ТЕОРИЯ

Идея и технология электронной подписи для исполняемых файлов возникла ещё в эпоху Windows NT. C момента появления Windows Vista компания Microsoft начала активную компанию по продвижению этой технологии. По задумке производителя, подписанный код может идти только от доверенного автора этого кода, а следовательно гарантированно не наносит вреда системе и защищён от ошибок (три ха-ха).

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

Становится ясно, что подписав свои творения валидной подписью, вирусмейкер получает довольно богатую аудиторию клиентов, у которых даже с активным и регулярно обновляемым антивирусом произойдёт заражение. Очевидно, что это — весьма лакомый кусочек, что легко заметно на примере уже ставшего знаменитым вируса Stuxnet, где код был подписан валидными сертификатами Realtek (позже сообщалось и о подписях от JMicron).

Но у этого подхода есть и оборотная сторона: после выявления скомпрометированной подписи она немедленно отзывается, а по самому факту подписи АВ-вендоры ставят сигнатурный детект, понятно, что с 100%-ным срабатыванием. Учитывая то, что приобрести украденный сертификат, необходимый для подписывания крайне дорого, ясно, что вирусмейкеры заинтересованы в тотальном обходе механизма проверки подписи, без валидных private-ключей или с помощью самостоятельной генерации таких ключей. Это позволит обходить защиту не только антивирусных продуктов, но и устанавливать драйвера и ActiveX-компоненты без предупреждений, да и вообще как-то пробиться в мир х64, где без подписей ничего не установить вообще.

Но об этом — подробнее на практике.

Кто-то из великих сказал, что чтобы опередить врага, надо начать мыслить как он. Итак, если мы вирусмейкеры, то что мы можем сделать?

1. Скопировать информацию о сертификате с какого-нибудь чистого файла.

Это наиболее популярный способ на данный момент. Копируется информация подписи до мельчайших подробностей, вплоть до цепочки доверенных издателей. Понятно, что такая копия валидна только на взгляд пользователя. Однако то, что отображает ОС вполне может сбить с толку неискушённого и быть воспринято как очередной глюк — ещё бы, если все издатели правильные, то почему это подпись невалидна? Увы и ах — таких большинство.

2. Использовать самоподписанные сертификаты с фэйковым именем.

Аналогично выше описанному варианту за исключением того, что даже не копируется цепочка в пути сертификации.

3. Подделать MD5.

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

Одна из наиболее распространённых методик авторов так называемых riskware, adware и фэйковых антивирусов. Примером может послужить фэйковый Perfect Defender (стандартный развод: «просканируйтесь бесплатно — у вас вирус — заплатите нам и мы его удалим») существует с подписями нескольких контор:
• Jeansovi llc
• Perfect Software llc
• Sovinsky llc
• Trambambon llc

Как это делается хорошо могут рассказать наши отечественные разработчики винлокеров, мелкими буквами пишущие про «программу-шутку» и т.д., таким образом оберегаясь от статьи о мошенничестве. Так и живём…

Интересно, что реально существуют абсолютно нормальные программы с такими именами владельцев:
• Verified Software
• Genuine Software Update Limited
• Browser plugin

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

Следует также отметить, что отнюдь несложно получить подпись от сертификационных центров. Например RapidSSL для проверки использует просто e-mail. Если переписка ведётся из адресов типа admin, administrator, hostmaster, info, is, it, mis, postmaster, root, ssladmin,
ssladministrator, sslwebmaster, sysadmin или webmaster@somedomain.com — очевидно, что пишет владелец домена, верно? (ещё три ха-ха). А вот славная компания Digital River (DR), промышляющая аутсорсингом и электронной коммерцией, вообще предоставляет сертификаты всем своим клиентам. Немудрено, что MSNSpyMonitor, WinFixer, QuickKeyLogger, ErrorSafe, ESurveiller, SpyBuddy, TotalSpy, Spynomore, Spypal и вообще около 0,6% из всех подписанных DR файлов являются малварью, а потенциально нежелательными являются и того больше — более 5% всех подписанных DR файлов.

Справедливости ради отмечу, что подписать х64-драйвер далеко не так просто, в этом случае пока нарушений не замечено.

5. Найти какого-нибудь работника доверенной компании и попросить его подписать Ваш код.

Без комментариев. Все любят деньги. Вопрос только в сумме 🙂

6. Украсть сертификат.

На данный момент известно три больших семейства троянцев, «заточенных», в частности, под похищение сертификатов. Это:
• Adrenalin
• Ursnif
• Zeus
• SpyEye (возможно)

Тем не менее пока не замечено массовых случаев использования украденных сертификатов в новых версиях этих троянцев. Возможно, это козырь в рукаве? Время покажет…

7. Заразить систему разработки доверенного разработчика и внедрять злонамеренный код в релизы до подписания.

Яркий пример такого заражения — вирус-концепт Induc.a. Вирус внедряет код на этапе компиляции, заражая систему разработки. В итоге разработчик даже не знает, что в его программе появился невидимый «довесок». Релиз проходит подпись и выходит в свет с полноценным сертификатом. Видишь суслика? А он есть! 😉

К счастью, Induc.a является только PoC, выполняя только заражение систем разработки без реализации какого бы то ни было дополнительного вредоносного функционала.

Ну а теперь — обещанные вкусняшки.

УЯЗВИМОСТЬ ИЛИ КАК Я ПРОВЁЛ ЭТИМ ЛЕТОМ

Как видим, вариантов обхода подписи достаточно много. В нашем примере будет рассмотрен модифицированный вариант 1 и 2, описанные выше.

Итак, что нам потребуется?
— MakeCert.exe
— cert2spc.exe
— sign.exe
— ruki.sys
— mozg.dll

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

Итак, создадим какой-либо сертификат доверенного издателя. Попробуем максимально скопировать информацию о том же VeriSign:
MakeCert.exe -# 7300940696719857889 -$ commercial -n CN=»VeriSign Class 3 Code Signing 2009-2 CA» -a sha1 -sky signature -l «https://www.verisign.com/rpa» -cy authority -m 12 -h 2 -len 1024 -eku 1.3.6.1.5.5.7.3.2,1.3.6.1.5.5.7.3.3 -r -sv veri.pvk veri.cer

В результате выполнения мы получим veri.pvk и veri.cer, пригодные для подписывания.

Теперь создадим дочерний сертификат с использованием полученных только что:

MakeCert.exe -# 8928659211875058207 -$ commercial -n CN=»Home Sweet Home» -a sha1 -sky signature -l «http://habrahabr.ru/» -ic veri.cer -iv veri.pvk -cy end -m 12 -h 2 -len 1024 -eku 1.3.6.1.5.5.7.3.3 -sv kl.pvk kl.cer

В итоге получим kl.pvk и kl.cer, которые будут доверенными сертификатами от недоверенного издателя. Цепочку можно продолжать долго, задуривая наивного пользователя. Но итог будет один: сертификат не будет валидным, потому как в цепочке есть один недоверенный элемент. НО!

В Windows имеется возможность установки любого сертификата, в том числе и самоподписанного, в качестве доверенного. Это удобно: в ряде случаев разработчик может сделать себе самоподписанный сертификат, ввести его в доверенные и спокойно работать со своими приложениям. В нашем случае это удобно вдвойне, потому как такой внос — очевидно, простое внесение информации в реестр. при чём информации отнюдь не специфичной для конкретной системы.

Установим на нашу тестовую виртуалку любой монитор реестра, после чего внесём наш искомый сертификат от якобы VeriSign в доверенные. Отследим, где произошло изменение — и voila! Мы можем сделать дамп соответствующей ветки реестра, после чего засунуть её в инсталлер. В итого, наш инсталлер вносит в реестр инфу, автоматически превращая сертификат первичного издателя в доверенный и валидируя всю цепочку.

Чтобы окончательно не открывать все карты, скажу только, что в моём случае дамп реестра имел вид
Windows Registry Editor Version 5.00

ну или если только для текущего пользователя, то
Windows Registry Editor Version 5.00

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

cert2spc.exe kl.cer kl.spc
sign.exe -spc kl.spc -v kl.pvk -n «My Installer» -i «http://habrahabr.ru» -ky signature -$ commercial -a sha1 -t «http://timestamp.verisign.com/scripts/timstamp.dll» myprogram.exe
del kl.spc

Обратите внимание на использование таймстампа timestamp.verisign.com/scripts/timstamp.dll — теоретически вполне возможно использование собственного сервера на собственном домене, что позволит каждый раз видеть, что кто-то проверил подпись нашей программы на своём компьютере, а значит получать IP и время проверки. Правда удобно? 😉

Самое забавное, что на момент написания материала в далёком октябре-ноябре 2010-го Kaspersky Internet Security 2011 не отслеживала указанные ветки реестра, а проверку валидности цепочки оставляла на усмотрение ОС, которую мы довольно просто надули. Не знаю, что сейчас, но вроде как некоторые ветки заблокировали… Проверяйте, отписывайтесь!

Нужно отметить, что для простановки подписей возможно использование и специфичного, недоступного в паблике софта. Понятно, что подписи он не ломает, но даёт куда более гибкие возможности для заполнения полей X500, что ещё лучше создаёт видимость валидности. Вот тут возможно скачать любопытный пример. В архиве — файл популярной замены Блокноту bred3_2k (офсайт) с и без подписи Microsoft 🙂 Чтобы подпись полностью стала валидной, достаточно внести в реестр изменения, содержащиеся в файле key +.reg. Аналогично, файл key -.reg эти изменения отменяет. Отследите путь сертификации — он любопытен 🙂

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

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

В статье использован материал презентации Jarno Niemela (F-Secure).

• цифровая подпись
• malware
• доверенное приложение