Как сделать файл доверенным

Добавил пользователь Владимир З.
Обновлено: 04.10.2024

Следующая команда описывает создание cer файла Windows (т.е. Сертификата от надежного поставщика).

Проблема заключается в том, что при создании приложения в Visual Studio 2017 оно позволяет только через файл package.windows10.appxmanifest файл pfx. при обновлении ссылки на эту командную строку он не создает pvk файл, поэтому нужно добавить

дополнительные параметры командной строки, такие как /sv SubjectKeyFile, которые будут создавать результирующий файл pvk.

Однако даже используя эту ссылку командной строки:

В результате имплантации файла сертификата в Visual Studio возникает эта ошибка:

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

Есть ли лучший способ создать скрипт с makecert? Как мне узнать, правильно ли в конечном итоге создается сертификат или нет? Дополнительная документация будет полезна, но я не нашел ничего другого.

ОТВЕТЫ

Ответ 1

Ответ, предоставленный @nico, имеет правильные утверждения, но заставил меня осознать, что в этом было нечто большее, чем я первоначально описывал. Поэтому я очистил заголовок вопроса и вопрос, чтобы обеспечить лучший вопрос и последующий ответ.

Во-первых, нужно спросить себя, для чего они используют приложение? Будет ли приложение загружено в Microsoft Store или предназначено только для внутреннего использования.

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

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

Этот сертификат может существовать в нескольких различных сценариях.

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

Я пойду по обоим сценариям. В любом случае протокол makecert устарел Заметки об устаревании makecert

Сценарий 1. Если вам нужен самозаверяющий сертификат, выполните следующие действия.

Перейдите на powershell и используйте командлет New-SelfSignedCertificate pkiclient. что позволит вам создать комбинацию .cer и соответствующий закрытый ключ + открытый сертификат =.pfx, если вы создадите для сертификата + закрытый ключ. И вам нужно иметь закрытый ключ, т.е..pfx, чтобы связать и упаковать ваше приложение с Visual Studio и установить его в локальное хранилище приложений Windows (не путать с магазином Microsoft.)

Вот ссылки, по которым нужно следовать *** Прежде чем создавать сертификат, обязательно прочитайте 1А:

1А. *** Когда вы создаете New-SelfSignedCertificate, вы должны понимать, что сертификат должен быть создан очень специфическим способом. Это для самоподписанного или выданного СА сертификата.

В частности, сертификат должен обладать 2 свойствами

а). Должно быть расширение Basic Constraints, установленное в Subject Type = End Entity. Простыми словами это говорит о том, что. Когда этот сертификат выдается вам, вы не можете сделать так, чтобы сертификат был последующим центром сертификации с возможностью выдавать больше сертификатов. Другими словами. Это конец строки сертификата.

б). Значение расширения Enhanced Key Usage (EKU) установлено на подпись кода. Это предотвращает использование сертификата для каких-либо целей, кроме его предназначения. Что означает, что программное обеспечение было получено от издателя программного обеспечения && Защищает программное обеспечение от изменения после публикации.
В деталях сертификата информация будет выглядеть следующим образом:

Подпись кода (1.3.6..1.5.5.7.3.3) & lt; & lt; & lt; & lt; Это OID расширенного использования ключа для подписи кода 1.3.6. число

Эта информация была найдена очень случайно и не в каком-либо конкретном порядке текущей документации:

1В. Таким образом, в конечном итоге для использования командлета New-SelfSignedCertifcate через powershell нужно было выполнить команду следующим образом:

Приведенная выше команда соответствует обоим критериям сертификата для подписи кода (хотя вместо использования свойства -type можно было бы выбрать oid расширения использования ключа с соответствующим типом подписи кода, т.е. oid подписи кода = 1.3.6.1. 5.5.7.3.3)

Если вы запустите указанную выше команду в powershell, вы создадите 2 вещи, которые теперь можно экспортировать.

А) публичный сертификат B.) закрытый ключ + открытый сертификат, содержащийся в формате файла .pfx.

Теперь, когда у нас есть возможность экспортировать .pfx, вы можете создать пароль и экспортировать файл с закрытым ключом + сертификат .pfx.

Используя команду, вы запустите командлет в powershell Export-PfxCertificate:

Вот документация Экспорт pfx:

На этом этапе у вас есть ключ, который работает с Visual Studio, и теперь вы можете упаковать свое приложение и создать файл .appx или файл appxbundle, который можно будет развернуть в хранилище Windows на локальных машинах.

Подробные инструкции можно найти здесь:

Сценарий 2. Если вам нужен доверенный сертификат от центра сертификации вашей организации

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

Ну, вот один из способов понять это. Корневым сертификатом при его создании был сертификат SelfSigned. Тем не менее, он имеет возможность выдавать сертификаты другим для различных вещей. то есть авторизация на сервере или подпись кода. Подумайте, основные ограничения НЕОГРАНИЧЕННЫЕ. И он также может выдавать другие центры сертификации, которые могут выдавать сертификаты другим по ряду причин.

Это называется цепочкой сертификатов. Помните, что сертификат, который мы хотим для наших целей, является концом этой цепочки. Basic Constraints = LIMITED до 0 или false, что означает, что он должен быть подписан как End-endtity или Certificate Authroity = false. в другом слова, которые вы не можете выдать дальнейшие сертификаты по любой причине из этого сертификата, который был выпущен.

Так как это для приложения, которое просто необходимо установить и использовать. Это имеет смысл.

Итак, для следующего сегмента я собираюсь объяснить шаги для запроса сертификата у вашего центра сертификации через запрос сертификата. В мире Linux через openssl это называется .csr. В мире powershell это называется .req

Если вы правильно установите параметры. конечный результат - это файл, который может быть прочитан веб-сайтом проверки openssl или сертификатом со сменным расширением .req или .csr

Powershell может создавать это с помощью командлета CertReq

.Вы просто используете эту команду вместе с передачей файла .inf, который создаст ваш запрос сертификата .req

certreq -new TestReqConfig.inf MyRequest.req

Файл .inf будет содержать параметры для ключа и информацию о сертификате, как при создании сертификата new-selfsigned на основе приведенной выше информации.

INF файл будет выглядеть так:

Requesttype = PKCS10 позволяет работать с декодером openssl csr. и все остальное объясняется через эти сайты:

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

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

Ответ 2

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

Шаг 1: Определите имя издателя пакета

Шаг 2. Создайте закрытый ключ, используя MakeCert.exe.

Шаг 3. Создание файла обмена личной информацией (.pfx) с помощью Pvk2Pfx.exe.

И вы также можете использовать приведенную ниже команду для создания сертификата напрямую. Вам нужно только заменить параметр CN параметром.

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

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

Откройте Word.
Щелкните Файл> Параметры.
Откройте ” Доверенный центр”> “Настройки доверенного центра”.
Выберите Защищенный просмотр.

Защищенный просмотр для приложений Microsoft Office предлагает три основных параметра, перечисленных ниже:

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

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

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

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

Повторное включение защищенного просмотра для доверенных файлов

Запустите сканирование системы, чтобы обнаружить потенциальные ошибки

Запустите сканирование ПК с помощью Restoro Repair Tool, чтобы найти ошибки, вызывающие проблемы с безопасностью и замедление. После завершения сканирования в процессе восстановления поврежденные файлы заменяются новыми файлами и компонентами Windows.

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

Добавить надежные расположения для надежных файлов

Файлы и папки из надежного расположения будут открываться без перехода в режим защищенного просмотра.

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

Приложения Microsoft Office, такие как Word, упрощают обмен документами. Это означает, что вы можете добавлять файлы, например изображения из Интернета, и отправлять их своим клиентам по электронной почте или другим носителям.

Потенциальные злоумышленники могут использовать веб-трекеры и другие вредоносные коды различными способами, чтобы получить доступ к вашему компьютеру или украсть учетные данные.

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

Веб-трекер

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

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

Ваш IP-адрес
ОС и версия Microsoft Officer
Название и версия браузера

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

Атака внедрения SMB

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

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

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

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

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

Защищенный просмотр в Microsoft Word – это функция безопасности, которая защищает вас от случайного открытия потенциально вредоносных файлов, встроенных в вредоносные программы или даже средства отслеживания.

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

Как добавить корневой сертификат в доверенные в Windows на уровне системы

1. Мастер импорта сертификатов

Если сертификат имеет расширение .crt, то его достаточно запустить двойным кликом:

Выберите один из вариантов:

Теперь сертификат будет доступен в Менеджере Сертификатов:

2. Добавление root CA сертификата в Менеджере Сертификатов

Чтобы открыть Менеджер Сертификатов нажмите Win+r, введите в открывшееся поле и нажмите Enter:

Укажите папку и имя файла:

Теперь действительно всё готово:

Только что импортированный сертификат в Менеджере Сертификатов:

Как добавить корневой сертификат в доверенные в Windows в веб браузеры

Chrome, Chromium, Opera и сделанные на их основе веб браузеры используют общесистемные корневые CA сертификаты. То есть для добавления новых доверенных CA достаточно добавить их в систему, как это показано выше.

Firefox использует исключительно своё хранилище. Для добавления корневых сертификатов CA в Firefox нужно сделать так:

В настройках Firefox: Приватность и Защита → Сертификаты → Просмотр сертификатов → Центры сертификации:

Выберите файл с сертификатом.

Укажите, какие полномочия вы даёте этому сертификату:

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

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

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

ТЕОРИЯ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В результате выполнения мы получим veri.pvk и veri.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

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

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

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

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

Читайте также: