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

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

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

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

    ТЕОРИЯ

    Идея и технология электронной подписи для исполняемых файлов возникла ещё в эпоху 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

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\Certificates\A61F9F1A51BBCA24218F9D14611AFBA61B86C14C]
    "Blob"=hex:04,00,00,.....


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

    [HKEY_CURRENT_USER\Software\Microsoft\SystemCertificates\Root\Certificates\A61F9F1A51BBCA24218F9D14611AFBA61B86C14C]
    "Blob"=hex:04,00,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).
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 46

      +3
      «Заразить систему разработки доверенного разработчика и внедрять злонамеренный код в релизы до подписания.»
      По поводу того, что это был PoC — я смутно припоминаю, что одна из версий qip была именно так заражена и попала в сеть.
        +2
        PoC — имелось в виду, что «Индюк» по сути занимается только самораспространением. Никакого вреда, кроме этого самого самораспространения, он не причиняет. Хотя мог бы :)

        В реале вирус Induc.a существует и заразил он отнюдь не только QIP.
        +2
        А можно прописать сертификат в реестре не имея админских прав?
          0
          Хехе, я тоже думал, что так можно и админа обойти :)
          Нет, нельзя такое прописать. Только в HKCU — но тогда ни для LocalSystem, ни для других пользователей это работать не будет.
          0
          за статью автору спасибо, лично мне понравилось. Только способ взлома какой-то слишком уж прямой, прямо лежит на поверхности. Не думал, что всё так просто.
            0
            В Win95 криптование паролей делалось по статичной фразе через xor. Просто? А ведь было :)

            На самом деле рецепт далеко не универсальный и не революционный — ниже об этом говорится.
              –1
              Вы не поверите как многие вещи легко обходятся «в лоб».

              Например когда-то самый популярный (и кажется на тот момент единственный) фаервол для виндоус @Guard (в 1999 его купила Symantec для создания Norton Internet Security) обходился просто добавлением себя в его правила через тот же реестр, через реестр его же можно было и выключить :)

              Или вот в леопарде ввели загрузку библиотек по разным случайным адресам дабы усложнить жизнь взломщикам, звучит угрожающе, но на деле лишь часть библиотек будет грузится по случайным адресам (системные, вроде dyld постоянны), причем все изменения для системы легко можно посмотреть: cat /var/db/dyld/dyld_shared_cache_*.map
              +2
              Мы можем сделать дамп соответствующей ветки реестра, после чего засунуть её в инсталлер.

              А разве целью не было как-раз заставить систему не ругнуться на инсталлер при его запуске?
                +2
                Верно. Инсталлятор сделает подпись валидной — но кто валидирует сам инсталлятор? И тут приходит социальный момент «запустите кряк», «установите патч» и прочее. В принципе, можно даже с помощью reg add внести нужную инфу — дескать запустите батник или скопируйте код ниже в командную строку и выполните :)

                Я не обещал выложить Рецепт Тотальной Революции, но тем не менее.
              • UFO just landed and posted this here
                  0
                  Вот, блин, именно это и меня волнует. Практически никакого значения подпись не имеет, разве что надо запуститься от админа (процесс развертывания & etc) и лишний раз сказать пользователю, мол, я в адеквате, давай дальше, не ссы.
                    +3
                    Про х64 речь вообще не шла :)
                    Уязвимость касалась вот чего:
                    Самое забавное, что на момент написания материала в далёком октябре-ноябре 2010-го Kaspersky Internet Security 2011 не отслеживала указанные ветки реестра, а проверку валидности цепочки оставляла на усмотрение ОС, которую мы довольно просто надули. Не знаю, что сейчас, но вроде как некоторые ветки заблокировали… Проверяйте, отписывайтесь!


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

                    При попытке установки дрова без подписи на х32 Виста и старше выкидывает алерт. Вы невнимательно читаете:
                    Это позволит обходить защиту не только антивирусных продуктов, но и устанавливать драйвера и ActiveX-компоненты без предупреждений


                    Теперь рассматриваем вариант: классический пинч с якобы «кряком». Кряк делает подпись валидной, пинч запускается, благодаря подписи обходит хипс и обнюхиватель антивируса, снимает все кешированные пароли и шлёт владельцу. ОС ни слова не скажет — прога-то подписана!

                    Я не описываю вариант тотального получения рута через неверную реализацию криптомеханизма, но потеря инфы как-то номеров кредитных карт и прочего — неприятно. Вы скажете — нечего кешировать такую информацию и верить настройкам по умолчанию? Верно, Вы правы, но отнюдь не все так же умны и продвинуты.
                      –1
                      В варианте с «классическим пинчем» непонятна одна штука: почему «кряк» не может выслать весь protected storage? Тем более, что они чаще всего требуют элевации (ну надо ж пропатчить бинарник в Program Files), а юзеры им на голубом глазу разрешают. На фига возиться с подписями вообще?
                        0
                        Предложите отправку protected storage с помощью рег-файла или с помощью кода в несколько строк в текстовом файле. Исполняемые файлы не считаются.
                          –1
                          Я, наверное, запутался, но как «кряк» стал «рег-файлом»? Или перед запуском «кряка» пользователь еще и импортирует что то в реестр?
                            0
                            Наверное запутались. Для рядового обывателя кряк всё, что обеспечивает функциональность проги. Итого, пишем инсталлятор-«взлом интернета», который вначале проверяет наличие искомого ключа в ветке. Если такого нет — валится с ошибкой типа «незарегистрированная версия».

                            Теперь пишем на всех форумах «бла-бла-бла, я крут, я взломал то-то и то-то». Кладём инсталлятор и говорим, что он требует регистрации, регистрационную информацию ты похитил и она лежит в виде файла для реестра. Запустишь — заработает прога. Реально, файл реестра лишь добавляет корневого издателя в доверенные.

                            Пользователь понимает, что файл реестра скорее всего ничего плохого не сделает, более того — реально многие проги ломаются именно правкой реестра (пример — Uniblue Registry Booster, да он и не один). Реестр добавляется и случается счастье.

                            Кряк = файл реестра.
                              –1
                              А. Имеет смысл, но опять таки неоправдано сложно. Можно прямо из инсталлятора (раз уж мы его полностью контроллируем) снять что угодно.
                                +1
                                Инсталлятор нарвётся на обнюхивания хипса, если в системе есть таковой. Он-то не подписан валидной подписью! Зато после обработки реестра «кряком» подпись становится валидной и хипс в стороне.
                                  –1
                                  Да, хипс можно обойти. Как и сканер. Но на мой взгяд их назначение не в предотвращении вторжений.
                                    0
                                    Ну, формально HIPS расшифровывается как «host intrusion prevention system», т.е. именно как «система предотвращения вторжений»…
                      • UFO just landed and posted this here
                          0
                          Она тем и страдает сейчас при установках по умолчанию. Вопрос в том, что считать валидной подписью, и если поддерживается локальное хранилище доверенных — тогда это то, о чём я пишу.

                          Самому всех проверять лениво, потому призываю других товарищей проделать такую работу. Благо всё, что нужно, разжёвано и описано.
                        0
                        Кстати, а как обстоят дела в Eset (это как бы ответ на Ваш лол, мы-то немного знакомы ;) ), если…

                        1. Попытаться добавить в реестр информацию файла key +.reg.
                        2. Запустить подписанный файл bred3_2k (подписан).exe после такого импорта. Хипс (он есть в эсете — честно, не знаю, давно не пользовал?) занесёт файл в доверенные сразу или всё-таки проверит? При настройках по умолчанию, естественно.

                        Вот это я подразумевал уязвимостью, а не особенности Windows и тем более платформы х64.
                        • UFO just landed and posted this here
                        0
                        Спасибо за статью )

                        Несколько отойду от темы, но в рамках «малварь & сертификаты». Меня всегда волновала ситуация, есть некое приложение A (подписанное валидным сертификатом), уже установленное / развернутое. Приложение А не требует прав админа для запуска (UAC не показывает окно, отображающее статус подписи и вендора). Существует некоторая malware B, которая осуществила успешное заражение приложения А (допустим, малварь не переподписывала благородный софт и не удаляла подписи). Да, действительно, утилита проверки и свойства системы покажут, что подпись более не валидна. Но при запуске приложения А никто ничего не скажет.

                        Вопрос. Должен ли этим заниматься автор софта и используя доступное API отчекать свой же сертификат на предмет действительности и предупредить пользователя. Или все-таки валидация сертификата должна занимать чуть более значимое место в системе? Ведь если подпись не валидна (она имеется, я не прошу ввести ЭЦП в качестве обязательного клейма), значит это кому-то было нужно (либо стечение обстоятельств) и стоит просигнализировать об этом пользователю (опять же не говорю про полную блокировку запускаемой софтины)?

                        Только что, эксперимента ради, пропатчил пару байт (в ресурсах) в 3х подписанных приложениях. Что с ЭЦП, что без. Всем, как говорится, похуй. В свойствах красуется перечеркнутый сертификат, а нам об этом никто не сказал. Я же не полезу валидировать сам каждый раз перед запуском. Понимаю, конечно, что сертификация это на 50% обдираловка.
                          +1
                          При нарушении целостности файла подпись слетает. Если при этом система не распознаёт такого нарушения — грош ему цена.
                            0
                            Что значит «не распознает»? Файл продолжает проходить проверку подписи? Ага, все вокруг такие дураки и не замечали такого мелкого «недостатка» RSA/DSA (ну или SHAx/RCx)
                              +1
                              Это ко мне вопрос? Если да, то не я писал:
                              Только что, эксперимента ради, пропатчил пару байт (в ресурсах) в 3х подписанных приложениях. Что с ЭЦП, что без. Всем, как говорится, похуй. В свойствах красуется перечеркнутый сертификат, а нам об этом никто не сказал. Я же не полезу валидировать сам каждый раз перед запуском. Понимаю, конечно, что сертификация это на 50% обдираловка.


                              Мне самому интересно, как это могло быть.
                                +1
                                А кто инициирует проверку подписи? Файл не проходит проверку подписи (само собой), но ее никто и не вызывает (кроме перечисленных ранее «свойств файла», специализированных утилит и UAC — по сути инициация пользователем, либо «исключительный» случай запуска от админа). И в чем тогда протекция?
                                +2
                                Не то чтобы «слетает» (она никуда не исчезает, хотя, думаю, мы об одном говорим), просто перестает проходить валидацию (из-за несоответствия контрольной суммы, соответственно) и… Это несоответствие остается незамеченным для пользователя во всех случаях кроме:
                                1. Проверки с помощью утилиты
                                2. Проверки через свойства файла
                                3. Окна UAC, при запуске от админа (и то, там речь не будет идти о том что подпись более невалидна, просто скажут что неизвестный издатель)

                                Вот это грустно.
                              –2
                              Интересно, зачем писать чушь?
                              > «а следовательно гарантированно не наносит вреда системе и защищён от ошибок (три ха-ха).»
                              Откуда Вам известна «задумка производителя»? Да и при чем здесь «производитель» ВООБЩЕ?

                              Ну а «практика» — это вообще красота.
                              1. Скопировать информацию вместе с цепочкой доверия, ога. Вы неточно выразились или таки действительно совершенно не понимаете как работает PKI?
                              2. Самоподписанный сертификат должен оказаться в trusted root. И как же, интересно, он там окажется?
                              3. Здесь все тоже очень забавно. Единственная известная мне атака на md5 находит коллизии парами (то есть позволяет не сгенерировать данные с произвольным хешем, а сгенерировать два разных «документа» с одинаковым, но неизвестным наперед хешем). Ну с современными мощностями можно еще и брутфорсить, хотя это и не всем доступно. Но действительно интересная часть в том, чтобы найти доверенный корневой сертификат с md5 и найти какую нибудь программу, использующую его для подписи.
                              4. Да-да, или получить сертификат от шарашки (зачем, если с тем же успехом можно сгенерировать самоподписанный сертификат) или проходить verified by visa с предоставлением паспортных данных и телефона. Нет, можно конечно подделать паспортные данные. До первого же апдейта CRL, ага.
                              5, 6, 7. Примерно из той же серии, что и ответ на вопрос «Как разбогатеть» — «Найти лоха с кучей кеша». Иногда случается, но КРАЙНЕ редко и требует вложения весьма серьезных средств, которые нелегко отбить смсками. Вот ежели надо вставить палку в колеса иранской ядерной программе — тогда да.

                              По поводу третьей части у меня только один вопрос: почему всем так не терпится называть всякую херню «уязвомостью»?
                              Предлагаю следующую часть назвать «ОЛОЛОЛО, Microsoft публикует эксплоиты на MSDN». Если внимательно присмотреться, можно увидеть, что открывается CAPICOM_CURRENT_USER_STORE с доступом CAPICOM_STORE_OPEN_READ_WRITE (и туда добавляется сертификат из AD, что в общем не важно — его можно импортировать и из файла).
                                +1
                                1. Скачайте пример из статьи. Объясните, как сделан сертификат Microsoft Code Signing RSA, выданный Microsoft Root Authority. предложите способ создания любого сертификата с издателем Microsoft Root Authority.
                                2. Об этом ниже в статье, не торопитесь, прочтите до конца.
                                3. Вы читали? Я писал, что есть рабочая концепция, но не решение по взломы MD5 во всех и вся.
                                4. Мне трудно комментировать, что является «шарашкой», здесь я привёл примеры и рабочую статистику F-Secure. Полагаю, у Вас имеются более достоверные сведения? Будьте любезны, поделитесь?
                                5,6,7. Пример таких «лохов» и вообще источник информации тут. источник на английсокм. Надеюсь, владеете?

                                Повторяю: уязвимость касалась продукта Kaspersky Internet Security 2011, позволяющего вносить в критичные ветки реестра изменения и не отслеживающего самостоятельно доверенных издателей сертификатов. Уязвимость касалась октября-ноября прошлого года, на тот момент по понятным причинам не публиковалась.

                                Каким мне нужно это выделить шрифтом, чтобы сюда не приплетали Microsoft?
                                  0
                                  1. Фейковый «Microsoft Root Authority» добавляется в HKLM из рег-файла. Не вижу никаких сложностей создать самоподписанный сертификат с любым именем
                                  2. Ну да, ниже в статье и приводится пример с импортом сертификата в HKLM (или Вы о чем то другом?). С таким же успехом пользователя можно просто попросить согласиться с UAC запросом.
                                  3. Я согласился. MD5 уже слишком слаб для современной техники. С другой стороны, им уже и не пользуются. С третье — не стоит недооценивать глупость людей. Так что это таки реальный вектор
                                  4. Шарашка в данном случае — это контора, выдающая сертификаты, цепочка доверия которых не заканчивается на одном из дефолтных trusted root сертификатов. Вполне допускаю, что кто-то может приобрести verisign/thawte сертификат и подписывать все подряд на основе только email, но такой сертификат быстро будет отозван. Подпись важна не сама по себе, важно чтоб подпись можно было проследить до trusted ca.
                                  5, 6, 7. Да в прошлом году утекли два валидных сертификата от крупных производителей. Я не говорю, что это невозможно — я говорю, что это неоправданно сложно для среднего представителя vx сцены.

                                  Насчет уязвимости — прошу прощения, неправильно понял. Но вообще менее, чем 100% срабатывание хипсов и сканеров/мониторов не может считаться уязвимостью, потому что это просто невозможно.
                                    +1
                                    1. Я Вас очень прошу: скачайте файл и посмотрите его. Потом будем говорить. В примере Microsoft Root Authority валидный, фейковый выданный им Microsoft Code Signing RSA.
                                    2. Тут всё верно. Кстати, UAC многие отключают сами :)
                                    3. Рад, что мы поняли друг друга.
                                    4. Но тем не менее такие «шарашки» есть и ими пользуются.
                                    5,6,7. Ну почин дан — подождём :)

                                    Согласен, но как способ обхода хипсов — тоже вариант.
                                      0
                                      1. Я похоже как обычно чего то недопонимаю, но импортируется именно фейковый Microsoft Root Authority (поле Subject):

                                      При этом он самоподписан: Issuer == Subject
                                        0
                                        Ну тогда и я что-то не понимаю:

                                        image
                                          +1
                                          Ну да, сам сертификат валиден, а «выданная им» подпись — нет.

                                          Это разные сертификаты. Причем ищутся они (Authority Key Identifier второго сертификата в цепочке) по Issuer + SerialNumber (которые в фейковом сертификате совпадают с настоящим):
                                          0
                                          Да, и оговорюсь сразу: я — не автор этого примера. история событий такова, один не очень чистоплотный дядя предложил покупать подписи Microsoft на хакерском форуме. В качестве примера выложил это и ещё кое-что. В принципе, техника понятна, но до сих пор для меня загадка, где он нашёл издателя Microsoft Root Authority и почему он распознаётся как валидный (скрин выше).
                                            0
                                            Это самоподписанный сертификат для «Microsoft Root Authority». Валидный он потому что самоподписан. А распознается потому, что был вручную добавлен в Trusted Root CAs.
                                              0
                                              Да вот нет — я не добавлял ничего в реестр, а приведённый скрин — с чистой виртуалки. Так что не то. Сам в недоумении.

                                              Кроме того — есть идеи, чем злоумышленник мог добавить поля Х500? Потому как тот же makecert такую подробность сделать не позволяет.
                                                +1
                                                Он там есть (даже два, но CurrentUser-ский стор игнорируется при проверке валидности). С таким же именем и серийником (но другим отпечатком пальца). Но подпись нижележащего сертификата не проходит (что естественно — публичные ключи то тоже разные). В certification path он попал, потому что подошел по Issuer-у и Serial Number-у. Попробуйте:
                                                PS C:\> dir -r cert: |? {$_.Subject -match "CN=Microsoft Root Authority"}
                                                
                                                
                                                
                                                    Directory: Microsoft.PowerShell.Security\Certificate::CurrentUser\Root
                                                
                                                
                                                Thumbprint                                Subject                                                       
                                                ----------                                -------                                                       
                                                A43489159A520F0D93D032CCAF37E7FE20A8B419  CN=Microsoft Root Authority, OU=Microsoft Corporation, OU=C...
                                                
                                                
                                                    Directory: Microsoft.PowerShell.Security\Certificate::LocalMachine\Root
                                                
                                                
                                                Thumbprint                                Subject                                                       
                                                ----------                                -------                                                       
                                                A43489159A520F0D93D032CCAF37E7FE20A8B419  CN=Microsoft Root Authority, OU=Microsoft Corporation, OU=C...


                                                Что же до генерации, как минимум OpenSSL позволяет генерировать запросы на сертификаты (ну и сами самоподписанные сертификаты) с любыми полями. Попробую сейчас поковырять как это можно дотнетом сделать
                                                  0
                                                  То есть в принципе он прописал CN и серийный номер, соответствующий Microsoft Root Authority и тогда сертификат включается в цепочку certification path, хотя и признаётся невалидным? Это очень интересно! Спасибо!
                                                    0
                                                    Стоп, нет, ничего не выйдет. Если я хочу сделать в качестве Issuer упомянутого Microsoft Root Authority, который к тому же по умолчанию сидит в Доверенных корневых центрах сертификации, то я должен указать что-то типа makecert -in «Microsoft Root Authority» — что никогда не будет выполнено, поскольку у меня нет private key к издательскому Microsoft Root Authority. То есть я никак имя издателя не впишу в самоподписанный сертификат, а тогда вообще не понятно, как тот издатель попалд в путь сертификации.

                                                    Вы можете опробовать Вашу теорию в практике? Возможно, я Вас неправильно понимаю.
                                                      +1
                                                      Это не тот Root Authority и не тот CSPCA. Это легко посмотреть по thumbprint-ам. Оба этих сертификата были сгенерированы НЕ в Microsoft, а злоумышленником (если бы там ДЕЙСТВИТЕЛЬНО была подпись Microsoft Root Authority — не нужно было бы ставить фейк).

                                                      Два сертификата (в том числе и CSPCA) встроены в экзешник, а корневой — устанавливается из reg файла. Во всей цепочке нет ни одного «реального» сертификата

                                                      На практике нужно сгенерировать самоподписанный MRA, сгенерировать и подписать им CSPCA и потом подписать экзешник. Публичную часть фейкового MRA закинуть в реестр.
                                                    +1
                                                    В общем, вот здесь все очень подробно расписано.
                                      0
                                      А при чем тут rapidssl? Они предоставляют сертификаты для веба, которые не могут использоваться для подписи кода.

                                      Only users with full accounts can post comments. Log in, please.