угроза эксплуатации цифровой подписи программного кода
Цифровые подписи в исполняемых файлах и обход этой защиты во вредоносных программах
Хабрапривет!
Ну вроде как удалось решить вопросы с кармой, но они ником образом не касаются сегодняшней темы, а лишь объясняют некоторое опоздание её выхода на свет (исходные планы были на ноябрь прошлого года).
Сегодня я предлагаю Вашему вниманию небольшой обзор по системе электронных подписей исполняемых файлов и способам обхода и фальсификации этой системы. Также будет рассмотрен в деталях один из весьма действенных способов обхода. Несмотря на то, что описываемой инфе уже несколько месяцев, знают о ней не все. Производители описываемых ниже продуктов были уведомлены об описываемом материале, так что решение этой проблемы, если они вообще считают это проблемой, на их ответственности. Потому как времени было предостаточно.
ТЕОРИЯ
Идея и технология электронной подписи для исполняемых файлов возникла ещё в эпоху Windows NT. C момента появления Windows Vista компания Microsoft начала активную компанию по продвижению этой технологии. По задумке производителя, подписанный код может идти только от доверенного автора этого кода, а следовательно гарантированно не наносит вреда системе и защищён от ошибок (три ха-ха).
Тем не менее, поскольку в механизме подписи чаще всего используется довольно сложный криптоустойчивый механизм, общее доверие к подписанному коду распространилось. Не ушли от этого и антивирусные вендоры. Верно: если код подписан, то он явно не может быть вирусом, а потому ему можно доверять априори, тем самым снизив вероятность ложных срабатываний. Поэтому в большинстве современных антивирусных продуктов по умолчанию стоит обход проверки подписанных файлов, что повышает скорость сканирования и снижает вероятность ложных срабатываний. Более того, зачастую подписанные программы автоматически заносятся в категорию «доверенных» поведенческих анализаторов ака хипсов.
Становится ясно, что подписав свои творения валидной подписью, вирусмейкер получает довольно богатую аудиторию клиентов, у которых даже с активным и регулярно обновляемым антивирусом произойдёт заражение. Очевидно, что это — весьма лакомый кусочек, что легко заметно на примере уже ставшего знаменитым вируса Stuxnet, где код был подписан валидными сертификатами Realtek (позже сообщалось и о подписях от JMicron).
Но у этого подхода есть и оборотная сторона: после выявления скомпрометированной подписи она немедленно отзывается, а по самому факту подписи АВ-вендоры ставят сигнатурный детект, понятно, что с 100%-ным срабатыванием. Учитывая то, что приобрести украденный сертификат, необходимый для подписывания крайне дорого, ясно, что вирусмейкеры заинтересованы в тотальном обходе механизма проверки подписи, без валидных private-ключей или с помощью самостоятельной генерации таких ключей. Это позволит обходить защиту не только антивирусных продуктов, но и устанавливать драйвера и ActiveX-компоненты без предупреждений, да и вообще как-то пробиться в мир х64, где без подписей ничего не установить вообще.
Но об этом — подробнее на практике.
Кто-то из великих сказал, что чтобы опередить врага, надо начать мыслить как он. Итак, если мы вирусмейкеры, то что мы можем сделать?
1. Скопировать информацию о сертификате с какого-нибудь чистого файла.
Это наиболее популярный способ на данный момент. Копируется информация подписи до мельчайших подробностей, вплоть до цепочки доверенных издателей. Понятно, что такая копия валидна только на взгляд пользователя. Однако то, что отображает ОС вполне может сбить с толку неискушённого и быть воспринято как очередной глюк — ещё бы, если все издатели правильные, то почему это подпись невалидна? Увы и ах — таких большинство.
2. Использовать самоподписанные сертификаты с фэйковым именем.
Аналогично выше описанному варианту за исключением того, что даже не копируется цепочка в пути сертификации.
Несмотря на то, что слабость алгоритма 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
Думаю, что для хабрачитателя не составит труда найти эти компоненты, но для самых ленивых выкладываю первые три здесь. Последние два не выкладываю в виду жёсткой привязки к железу, полному отсутствию кроссплатформенности и специфичности кода 🙂
В результате выполнения мы получим 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. Ну а подписать наш код с помощью полученного сертификата вообще просто, достаточно батника:
Обратите внимание на использование таймстампа timestamp.verisign.com/scripts/timstamp.dll — теоретически вполне возможно использование собственного сервера на собственном домене, что позволит каждый раз видеть, что кто-то проверил подпись нашей программы на своём компьютере, а значит получать IP и время проверки. Правда удобно? 😉
Самое забавное, что на момент написания материала в далёком октябре-ноябре 2010-го Kaspersky Internet Security 2011 не отслеживала указанные ветки реестра, а проверку валидности цепочки оставляла на усмотрение ОС, которую мы довольно просто надули. Не знаю, что сейчас, но вроде как некоторые ветки заблокировали… Проверяйте, отписывайтесь!
Сразу обращаю внимание на то, что автор «примера» прописал собственный таймстамп-сервер, так что любые манипуляции приведут к тому, что автор узнает Ваш IP — и дальше, как описывалось. Если хотите, то можете отследить эти обращения и отписаться в комментах 😉
Если потребуется, в следующей статье я расскажу, как настроить хипс для защиты соответсвующих веток реестра во избежание описанного внесения сертификатов в доверенные. Отписывайтесь в комментах — возможно, что эту уязвимость уже пофиксили.
В статье использован материал презентации Jarno Niemela (F-Secure).
Электронная подпись: безопасное использование и предотвращение рисков
Квалифицированная электронная подпись не только полноценно заменяет подпись от руки и обладает такой же юридической силой, но имеет преимущества перед обычной подписью, главные из которых:
Более широкий спектр возможностей ЭП по сравнению с обычной подписью и её преимущества в плане безопасности очевидны, осталось разобраться, как оградить себя от существующих рисков при использовании электронной подписи.
Правила безопасности для владельцев электронной подписи
Несмотря на весомые преимущества в плане безопасности, применение технологии электронной подписи по-прежнему сопряжено с опасениями и заблуждениями. Часть из них — не более чем мифы, некоторые риски реальны, но их можно избежать или минимизировать.
Еще один риск связан с хакерскими атаками — получением доступа к компьютеру или ноутбуку владельца подписи для похищения ключа. Предотвратить внедрение злоумышленника в компьютер и компрометацию данных в этом случае можно, соблюдая всем известные правила безопасного поведения в интернете — не переходить по подозрительным ссылкам, не загружать файлы из неизвестных источников, не использовать потенциально зараженные USB-носители и установить на рабочий компьютер надёжную программу-антивирус.
Безопасность использования электронной подписи во многом зависит и от организации, которая её выпустила. Выбор удостоверяющего центра — очень ответственная задача. Фактически удостоверяющий центр подтверждает личность обратившегося и выдаёт ему средство для электронного подписания документов, с юридической точки зрения абсолютно равнозначное его подписи от руки.
Незаконное оформление электронной подписи: в чём корень проблемы
К сожалению, мошенники идут в ногу со временем и находят возможности использовать продукты развития цифровой экономики в своих преступных целях. В некоторых случаях пострадать могут не клиенты удостоверяющих центров, а граждане, никогда не получавшие электронную подпись.
Весной 2019 года в российской прессе широко освещался случай отъёма квартиры мошенническим путём с использованием электронной подписи. Преступники переоформили квартиру на третье лицо без ведома собственника. О том, что жильё больше ему не принадлежит, хозяин московской квартиры узнал случайно, когда обнаружил имя нового владельца в квитанции на оплату коммунальных услуг.
В Росреестре пострадавшему сообщили, что электронная сделка по передаче имущества была проведена без нарушения законодательства. Оказалось, что он «подарил» свою квартиру жителю Уфы еще в октябре 2018 года. В итоге выяснилось, что преступление крылось в незаконном оформлении электронной подписи, которой заверялся договор дарения: хозяин квартиры не оформлял ЭП и не получал носитель с ключами электронной подписи и сертификат, за него это сделал другой человек по поддельной доверенности. Где злоумышленники получили паспортные данные владельца для фальсификации доверенности — неизвестно.
Выпустившая электронную подпись организация, так же, как и владелец квартиры, стала жертвой мошенников, получив от них поддельную доверенность. Законодательство позволяет удостоверяющим центрам выдавать ЭП по доверенности: согласно Федеральному закону от 06.04.2011 №63-ФЗ «Об электронной подписи», заявитель представляет доверенность или иной документ, подтверждающий право заявителя действовать от имени других лиц, в оригинале или его надлежащим образом заверенной копии. Иных требований закон не содержит. Фактически удостоверяющие центры имеют право выпускать электронную подпись по доверенности, не удостоверенной нотариально.
Что было бы, если бы закон запрещал выпуск сертификатов ЭП без нотариального заверения доверенности? Нотариальную доверенность подделать сложнее, но тоже возможно. К тому же запрет на выпуск сертификатов и ключей ЭП для юридических лиц без нотариально заверенной доверенности существенно осложнил бы документооборот и скорость работы организаций.
Тем не менее попытки ввести обязательное нотариальное удостоверение доверенностей на выпуск сертификатов электронной подписи уже предпринимаются на законодательном уровне.
В феврале 2018 года в Госдуму был внесён проект Федерального закона № 387130-7, который предусматривал, что при обращении в аккредитованный удостоверяющий центр потребуется представить не обычную доверенность, как сейчас, а нотариально удостоверенную. Однако после принятия в первом чтении законопроект находится без движения с июля 2018 года.
Защитить своё имущество от мошенничества с электронной сделкой с использованием ЭП, полученной по поддельной доверенности, всё же возможно. Для этого был принят Федеральный закон от 02.08.2019 № 286-ФЗ «О внесении изменений в Федеральный закон „О государственной регистрации недвижимости“». Закон создан для того, чтобы защитить граждан от мошенничества в сфере недвижимости. Теперь не получится подать в Росреестр электронное заявление о продаже недвижимости без специальной отметки в ЕГРН о возможности подачи документов в электронной форме.
Отметку проставят на основании заявления, поданного лично или отправленного по почте. При отсутствии такой отметки в регистрации сделки по передаче недвижимости будет отказано. Исключение сделано для нотариальных сделок, для документов, подписанных электронной подписью, сертификат которой выдан Федеральной кадастровой палатой Росреестра, а также для сделок, которые поданы на регистрацию через банки, — их зарегистрируют без отметки. Кроме того, законом предусмотрена обязанность Росреестра уведомлять владельца недвижимости о поступлении от его имени каких-либо электронных документов для продажи или ином отчуждении недвижимости.
Законодательные меры для защищённого использования ЭП
Законодательство стремится усовершенствовать установленные правила использования электронной подписи: в ноябре 2019 года Госдумой РФ в первом чтении принят законопроект, ужесточающий требования к удостоверяющим центрам. Речь идет о проекте федерального закона № 747528-7 «О внесении изменений в некоторые законодательные акты Российской Федерации в связи с совершенствованием регулирования в сфере электронной подписи».
В настоящее время проходят подготовку ко второму чтению в Госдуме принятые в первом чтении поправки в Федеральный закон от 06.04.2011 №63-ФЗ «Об электронной подписи». Историю подготовки законопроекта с поправками и основные этапы его изменений вы найдете в статье Елены Никоновой.
Как оценить надёжность удостоверяющего центра
Несмотря на то, что мошеннические схемы нацелены на все возможные уязвимые места в законодательстве, которые не ограничиваются сферой электронной подписи, выбор удостоверяющего центра остается одним из важнейших слагаемых безопасного использования ЭП. Поэтому вернёмся к удостоверяющим центрам и рассмотрим подробнее критерии их надёжности.
Законодательство, в рамках которого работают аккредитованные удостоверяющие центры, применяет к ним жёсткие требования, соответствие которым необходимо подтверждать раз в пять лет. Правила аккредитации удостоверяющего центра определяются статьей 16 Федерального закона №63 «Об электронной подписи». Среди главных условий для получения удостоверяющим центром аккредитации Минкомсвязи:
Кроме этого, есть не прописанные в законодательстве критерии, по которым можно определить надёжность удостоверяющего центра:
Фактором, снижающим доверие к удостоверяющему центру, является возможность проведения удалённого установления личности клиентов. Удалённое установление личности может подразумевать передачу отсканированных документов, необходимых для удостоверения личности клиента, через интернет и выпуск сертификата только на основании переданных документов. В таком случае вероятность предъявления поддельных документов значительно возрастает, потому что подделать фотографию или скан документа значительно проще, чем бумажный экземпляр. Кроме того, в такой ситуации невозможна непосредственная проверка соответствия личности заявителя личности владельца предъявляемых документов.
Удостоверяющий центр, проводящий удалённое установление личности, серьёзно нарушает закон, такая процедура не предусмотрена действующим законодательством.
В настоящий момент (до принятия поправок к 63-ФЗ) единственным легальным механизмом удалённой верификации личности при выдаче квалифицированного сертификата ЭП является механизм, связанный с использованием биометрического загранпаспорта. Этот вид дистанционного установления личности используется в рамках эксперимента, проводимого в соответствии с постановлением Правительства РФ от 29.10.2016 №1104.
Облачная и дистанционная электронная подпись
Технологии дистанционной и облачной электронной подписи существуют наряду с «классическими» технологиями электронной подписи, при которых для формирования ЭП используются ключи, хранящиеся на USB-токене или жёстком диске владельца сертификата, а также локальные средства электронной подписи, работающие на его компьютере.
Обе технологии предполагают в процессе формирования электронной подписи взаимодействие пользователя со специальной информационной системой. Разница между этими двумя технологиями в том, что в случае дистанционной подписи система контролирует действия пользователя и защищает его ключи ЭП, хранящиеся в мобильном устройстве. В варианте облачной подписи ключи ЭП пользователя хранятся в специальной информационной системе, а на мобильном устройстве пользователя хранятся специальные ключи для управления.
Действующая редакция Федерального закона «Об электронной подписи» не содержит прямого запрета на использование участниками электронного взаимодействия квалифицированных электронных подписей, созданных с использованием ключей электронных подписей, хранящихся в централизованном хранилище, и облачных средств электронной подписи. Однако все сертифицированные средства криптографической защиты информации, включая средства электронной подписи, должны применяться в строгом соответствии с требованиями эксплуатационной документации и в соответствии с правилами их использования, которые в обязательном порядке учитывают нормативные требования, в частности:
Планируемые изменения в Федеральный закон «Об электронной подписи» содержат дополнительные требования к использованию участниками электронного взаимодействия квалифицированных электронных подписей, созданных с использованием ключей электронных подписей, хранящихся в централизованном хранилище, и облачных средств электронной подписи.
Технология дистанционной подписи не предполагает делегирование хранения ключей третьим лицам, поэтому все связанные с этой процедурой сложности и планируемые к вводу дополнительные ограничения на использование облачных средств электронной подписи не могут применяться к ней. Подробнее с технологией дистанционной подписи IDPoint можно ознакомиться на официальном сайте приложения.
ТЭЦ как объект КИИ: возможно ли обеспечить реальную информационную безопасность?
Сложные технологические процессы, применяемые для получения электроэнергии, должны быть непрерывны; это достигается путём использования автоматизированных систем управления технологическими процессами (АСУ ТП), а также за счёт слаженной работы различных служб предприятия и немалого количества персонала. Автоматизация приводит к тому, что генерирующие объекты энергосистемы могут быть уязвимыми с точки зрения информационной безопасности и оказываться целями кибератак. Постараемся провести объективный анализ мероприятий по обеспечению защиты АСУ ТП, которые реализуются на большинстве генерирующих объектов энергетики, таких как городская теплоэлектроцентраль (ТЭЦ).
Введение
Для того чтобы понять причины, по которым возникла проблематика обеспечения ИБ на теплоэлектроцентралях, следует обратиться к истории появления и эксплуатации таких объектов. Большинство ныне работающих ТЭЦ строились в советскую эпоху, и АСУ ТП реализовывались на отечественной программно-аппаратной базе. Подсистем их защиты никто не создавал, поскольку тогда безопасность обеспечивали на уровне организационно-распорядительных документов и физической изоляции АСУ ТП.
В 2000-е годы началось масштабное обновление устаревших объектов генерации. В первую очередь модернизировалось газовое оборудование, менялись устаревшие системы АСУ ТП. Однако эти процессы опять же в основном не затрагивали защиту от информационных угроз.
Появление Федерального закона №187-ФЗ от 26 июля 2017 г., предписывающего обеспечивать безопасность критической информационной инфраструктуры (КИИ), заставило субъектов энергетики пересмотреть подходы и принципы к защите подведомственных им комплексов оборудования. Нарушения работы ТЭЦ могут привести к тому, что потребители лишатся энергоресурсов, и зачастую носят межмуниципальный характер; согласно упомянутому выше закону, АСУ ТП теплоэлектроцентралей относятся к КИИ и требуют обязательной защиты.
Постановление Правительства РФ №127 и приказы ФСТЭК России №235, №239 дополняют Федеральный закон №187-ФЗ и регламентируют обеспечение информационной безопасности объектов КИИ. К сожалению, эти документы только предъявляют требования и не содержат методических указаний относительно того, как модернизировать существующие АСУ ТП в части реализации механизмов или внедрения средств защиты информации.
Процесс обеспечения защиты АСУ ТП
Перечислим работы, необходимые для обеспечения защиты АСУ ТП как объекта критической информационной инфраструктуры.
Приведём наиболее распространённые меры, применяемые для защиты информации в АСУ ТП на теплоэлектроцентралях:
Уровень защищённости АСУ ТП теплоэлектроцентралей
Для понимания того, насколько АСУ ТП теплоэлектроцентралей защищены от информационных рисков, предлагаем рассмотреть реальные угрозы и вызовы, с которыми могут столкнуться специалисты по ИБ на таких объектах с учётом нового технологического уклада. Для этого будем использовать банк данных ФСТЭК России.
Таблица 1. Описание угроз безопасности информации, актуальных для АСУ ТП