Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 46
«Заразить систему разработки доверенного разработчика и внедрять злонамеренный код в релизы до подписания.»
По поводу того, что это был PoC — я смутно припоминаю, что одна из версий qip была именно так заражена и попала в сеть.
По поводу того, что это был PoC — я смутно припоминаю, что одна из версий qip была именно так заражена и попала в сеть.
А можно прописать сертификат в реестре не имея админских прав?
за статью автору спасибо, лично мне понравилось. Только способ взлома какой-то слишком уж прямой, прямо лежит на поверхности. Не думал, что всё так просто.
В Win95 криптование паролей делалось по статичной фразе через xor. Просто? А ведь было :)
На самом деле рецепт далеко не универсальный и не революционный — ниже об этом говорится.
На самом деле рецепт далеко не универсальный и не революционный — ниже об этом говорится.
Вы не поверите как многие вещи легко обходятся «в лоб».
Например когда-то самый популярный (и кажется на тот момент единственный) фаервол для виндоус @Guard (в 1999 его купила Symantec для создания Norton Internet Security) обходился просто добавлением себя в его правила через тот же реестр, через реестр его же можно было и выключить :)
Или вот в леопарде ввели загрузку библиотек по разным случайным адресам дабы усложнить жизнь взломщикам, звучит угрожающе, но на деле лишь часть библиотек будет грузится по случайным адресам (системные, вроде dyld постоянны), причем все изменения для системы легко можно посмотреть: cat /var/db/dyld/dyld_shared_cache_*.map
Например когда-то самый популярный (и кажется на тот момент единственный) фаервол для виндоус @Guard (в 1999 его купила Symantec для создания Norton Internet Security) обходился просто добавлением себя в его правила через тот же реестр, через реестр его же можно было и выключить :)
Или вот в леопарде ввели загрузку библиотек по разным случайным адресам дабы усложнить жизнь взломщикам, звучит угрожающе, но на деле лишь часть библиотек будет грузится по случайным адресам (системные, вроде dyld постоянны), причем все изменения для системы легко можно посмотреть: cat /var/db/dyld/dyld_shared_cache_*.map
Мы можем сделать дамп соответствующей ветки реестра, после чего засунуть её в инсталлер.
А разве целью не было как-раз заставить систему не ругнуться на инсталлер при его запуске?
Верно. Инсталлятор сделает подпись валидной — но кто валидирует сам инсталлятор? И тут приходит социальный момент «запустите кряк», «установите патч» и прочее. В принципе, можно даже с помощью reg add внести нужную инфу — дескать запустите батник или скопируйте код ниже в командную строку и выполните :)
Я не обещал выложить Рецепт Тотальной Революции, но тем не менее.
Я не обещал выложить Рецепт Тотальной Революции, но тем не менее.
Вот, блин, именно это и меня волнует. Практически никакого значения подпись не имеет, разве что надо запуститься от админа (процесс развертывания & etc) и лишний раз сказать пользователю, мол, я в адеквате, давай дальше, не ссы.
Про х64 речь вообще не шла :)
Уязвимость касалась вот чего:
Настройка по умолчанию добавляет такие программы в доверенные хипса. Если не ошибаюсь, в других продуктах — то же самое.
При попытке установки дрова без подписи на х32 Виста и старше выкидывает алерт. Вы невнимательно читаете:
Теперь рассматриваем вариант: классический пинч с якобы «кряком». Кряк делает подпись валидной, пинч запускается, благодаря подписи обходит хипс и обнюхиватель антивируса, снимает все кешированные пароли и шлёт владельцу. ОС ни слова не скажет — прога-то подписана!
Я не описываю вариант тотального получения рута через неверную реализацию криптомеханизма, но потеря инфы как-то номеров кредитных карт и прочего — неприятно. Вы скажете — нечего кешировать такую информацию и верить настройкам по умолчанию? Верно, Вы правы, но отнюдь не все так же умны и продвинуты.
Уязвимость касалась вот чего:
Самое забавное, что на момент написания материала в далёком октябре-ноябре 2010-го Kaspersky Internet Security 2011 не отслеживала указанные ветки реестра, а проверку валидности цепочки оставляла на усмотрение ОС, которую мы довольно просто надули. Не знаю, что сейчас, но вроде как некоторые ветки заблокировали… Проверяйте, отписывайтесь!
Настройка по умолчанию добавляет такие программы в доверенные хипса. Если не ошибаюсь, в других продуктах — то же самое.
При попытке установки дрова без подписи на х32 Виста и старше выкидывает алерт. Вы невнимательно читаете:
Это позволит обходить защиту не только антивирусных продуктов, но и устанавливать драйвера и ActiveX-компоненты без предупреждений
Теперь рассматриваем вариант: классический пинч с якобы «кряком». Кряк делает подпись валидной, пинч запускается, благодаря подписи обходит хипс и обнюхиватель антивируса, снимает все кешированные пароли и шлёт владельцу. ОС ни слова не скажет — прога-то подписана!
Я не описываю вариант тотального получения рута через неверную реализацию криптомеханизма, но потеря инфы как-то номеров кредитных карт и прочего — неприятно. Вы скажете — нечего кешировать такую информацию и верить настройкам по умолчанию? Верно, Вы правы, но отнюдь не все так же умны и продвинуты.
В варианте с «классическим пинчем» непонятна одна штука: почему «кряк» не может выслать весь protected storage? Тем более, что они чаще всего требуют элевации (ну надо ж пропатчить бинарник в Program Files), а юзеры им на голубом глазу разрешают. На фига возиться с подписями вообще?
Предложите отправку protected storage с помощью рег-файла или с помощью кода в несколько строк в текстовом файле. Исполняемые файлы не считаются.
Я, наверное, запутался, но как «кряк» стал «рег-файлом»? Или перед запуском «кряка» пользователь еще и импортирует что то в реестр?
Наверное запутались. Для рядового обывателя кряк всё, что обеспечивает функциональность проги. Итого, пишем инсталлятор-«взлом интернета», который вначале проверяет наличие искомого ключа в ветке. Если такого нет — валится с ошибкой типа «незарегистрированная версия».
Теперь пишем на всех форумах «бла-бла-бла, я крут, я взломал то-то и то-то». Кладём инсталлятор и говорим, что он требует регистрации, регистрационную информацию ты похитил и она лежит в виде файла для реестра. Запустишь — заработает прога. Реально, файл реестра лишь добавляет корневого издателя в доверенные.
Пользователь понимает, что файл реестра скорее всего ничего плохого не сделает, более того — реально многие проги ломаются именно правкой реестра (пример — Uniblue Registry Booster, да он и не один). Реестр добавляется и случается счастье.
Кряк = файл реестра.
Теперь пишем на всех форумах «бла-бла-бла, я крут, я взломал то-то и то-то». Кладём инсталлятор и говорим, что он требует регистрации, регистрационную информацию ты похитил и она лежит в виде файла для реестра. Запустишь — заработает прога. Реально, файл реестра лишь добавляет корневого издателя в доверенные.
Пользователь понимает, что файл реестра скорее всего ничего плохого не сделает, более того — реально многие проги ломаются именно правкой реестра (пример — Uniblue Registry Booster, да он и не один). Реестр добавляется и случается счастье.
Кряк = файл реестра.
А. Имеет смысл, но опять таки неоправдано сложно. Можно прямо из инсталлятора (раз уж мы его полностью контроллируем) снять что угодно.
Она тем и страдает сейчас при установках по умолчанию. Вопрос в том, что считать валидной подписью, и если поддерживается локальное хранилище доверенных — тогда это то, о чём я пишу.
Самому всех проверять лениво, потому призываю других товарищей проделать такую работу. Благо всё, что нужно, разжёвано и описано.
Самому всех проверять лениво, потому призываю других товарищей проделать такую работу. Благо всё, что нужно, разжёвано и описано.
Кстати, а как обстоят дела в Eset (это как бы ответ на Ваш лол, мы-то немного знакомы ;) ), если…
1. Попытаться добавить в реестр информацию файла key +.reg.
2. Запустить подписанный файл bred3_2k (подписан).exe после такого импорта. Хипс (он есть в эсете — честно, не знаю, давно не пользовал?) занесёт файл в доверенные сразу или всё-таки проверит? При настройках по умолчанию, естественно.
Вот это я подразумевал уязвимостью, а не особенности Windows и тем более платформы х64.
1. Попытаться добавить в реестр информацию файла key +.reg.
2. Запустить подписанный файл bred3_2k (подписан).exe после такого импорта. Хипс (он есть в эсете — честно, не знаю, давно не пользовал?) занесёт файл в доверенные сразу или всё-таки проверит? При настройках по умолчанию, естественно.
Вот это я подразумевал уязвимостью, а не особенности Windows и тем более платформы х64.
Спасибо за статью )
Несколько отойду от темы, но в рамках «малварь & сертификаты». Меня всегда волновала ситуация, есть некое приложение A (подписанное валидным сертификатом), уже установленное / развернутое. Приложение А не требует прав админа для запуска (UAC не показывает окно, отображающее статус подписи и вендора). Существует некоторая malware B, которая осуществила успешное заражение приложения А (допустим, малварь не переподписывала благородный софт и не удаляла подписи). Да, действительно, утилита проверки и свойства системы покажут, что подпись более не валидна. Но при запуске приложения А никто ничего не скажет.
Вопрос. Должен ли этим заниматься автор софта и используя доступное API отчекать свой же сертификат на предмет действительности и предупредить пользователя. Или все-таки валидация сертификата должна занимать чуть более значимое место в системе? Ведь если подпись не валидна (она имеется, я не прошу ввести ЭЦП в качестве обязательного клейма), значит это кому-то было нужно (либо стечение обстоятельств) и стоит просигнализировать об этом пользователю (опять же не говорю про полную блокировку запускаемой софтины)?
Только что, эксперимента ради, пропатчил пару байт (в ресурсах) в 3х подписанных приложениях. Что с ЭЦП, что без. Всем, как говорится, похуй. В свойствах красуется перечеркнутый сертификат, а нам об этом никто не сказал. Я же не полезу валидировать сам каждый раз перед запуском. Понимаю, конечно, что сертификация это на 50% обдираловка.
Несколько отойду от темы, но в рамках «малварь & сертификаты». Меня всегда волновала ситуация, есть некое приложение A (подписанное валидным сертификатом), уже установленное / развернутое. Приложение А не требует прав админа для запуска (UAC не показывает окно, отображающее статус подписи и вендора). Существует некоторая malware B, которая осуществила успешное заражение приложения А (допустим, малварь не переподписывала благородный софт и не удаляла подписи). Да, действительно, утилита проверки и свойства системы покажут, что подпись более не валидна. Но при запуске приложения А никто ничего не скажет.
Вопрос. Должен ли этим заниматься автор софта и используя доступное API отчекать свой же сертификат на предмет действительности и предупредить пользователя. Или все-таки валидация сертификата должна занимать чуть более значимое место в системе? Ведь если подпись не валидна (она имеется, я не прошу ввести ЭЦП в качестве обязательного клейма), значит это кому-то было нужно (либо стечение обстоятельств) и стоит просигнализировать об этом пользователю (опять же не говорю про полную блокировку запускаемой софтины)?
Только что, эксперимента ради, пропатчил пару байт (в ресурсах) в 3х подписанных приложениях. Что с ЭЦП, что без. Всем, как говорится, похуй. В свойствах красуется перечеркнутый сертификат, а нам об этом никто не сказал. Я же не полезу валидировать сам каждый раз перед запуском. Понимаю, конечно, что сертификация это на 50% обдираловка.
При нарушении целостности файла подпись слетает. Если при этом система не распознаёт такого нарушения — грош ему цена.
Что значит «не распознает»? Файл продолжает проходить проверку подписи? Ага, все вокруг такие дураки и не замечали такого мелкого «недостатка» RSA/DSA (ну или SHAx/RCx)
Это ко мне вопрос? Если да, то не я писал:
Мне самому интересно, как это могло быть.
Только что, эксперимента ради, пропатчил пару байт (в ресурсах) в 3х подписанных приложениях. Что с ЭЦП, что без. Всем, как говорится, похуй. В свойствах красуется перечеркнутый сертификат, а нам об этом никто не сказал. Я же не полезу валидировать сам каждый раз перед запуском. Понимаю, конечно, что сертификация это на 50% обдираловка.
Мне самому интересно, как это могло быть.
А кто инициирует проверку подписи? Файл не проходит проверку подписи (само собой), но ее никто и не вызывает (кроме перечисленных ранее «свойств файла», специализированных утилит и UAC — по сути инициация пользователем, либо «исключительный» случай запуска от админа). И в чем тогда протекция?
Не то чтобы «слетает» (она никуда не исчезает, хотя, думаю, мы об одном говорим), просто перестает проходить валидацию (из-за несоответствия контрольной суммы, соответственно) и… Это несоответствие остается незамеченным для пользователя во всех случаях кроме:
1. Проверки с помощью утилиты
2. Проверки через свойства файла
3. Окна UAC, при запуске от админа (и то, там речь не будет идти о том что подпись более невалидна, просто скажут что неизвестный издатель)
Вот это грустно.
1. Проверки с помощью утилиты
2. Проверки через свойства файла
3. Окна UAC, при запуске от админа (и то, там речь не будет идти о том что подпись более невалидна, просто скажут что неизвестный издатель)
Вот это грустно.
Интересно, зачем писать чушь?
> «а следовательно гарантированно не наносит вреда системе и защищён от ошибок (три ха-ха).»
Откуда Вам известна «задумка производителя»? Да и при чем здесь «производитель» ВООБЩЕ?
Ну а «практика» — это вообще красота.
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. Скопировать информацию вместе с цепочкой доверия, ога. Вы неточно выразились или таки действительно совершенно не понимаете как работает 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. Скачайте пример из статьи. Объясните, как сделан сертификат Microsoft Code Signing RSA, выданный Microsoft Root Authority. предложите способ создания любого сертификата с издателем Microsoft Root Authority.
2. Об этом ниже в статье, не торопитесь, прочтите до конца.
3. Вы читали? Я писал, что есть рабочая концепция, но не решение по взломы MD5 во всех и вся.
4. Мне трудно комментировать, что является «шарашкой», здесь я привёл примеры и рабочую статистику F-Secure. Полагаю, у Вас имеются более достоверные сведения? Будьте любезны, поделитесь?
5,6,7. Пример таких «лохов» и вообще источник информации тут. источник на английсокм. Надеюсь, владеете?
Повторяю: уязвимость касалась продукта Kaspersky Internet Security 2011, позволяющего вносить в критичные ветки реестра изменения и не отслеживающего самостоятельно доверенных издателей сертификатов. Уязвимость касалась октября-ноября прошлого года, на тот момент по понятным причинам не публиковалась.
Каким мне нужно это выделить шрифтом, чтобы сюда не приплетали Microsoft?
2. Об этом ниже в статье, не торопитесь, прочтите до конца.
3. Вы читали? Я писал, что есть рабочая концепция, но не решение по взломы MD5 во всех и вся.
4. Мне трудно комментировать, что является «шарашкой», здесь я привёл примеры и рабочую статистику F-Secure. Полагаю, у Вас имеются более достоверные сведения? Будьте любезны, поделитесь?
5,6,7. Пример таких «лохов» и вообще источник информации тут. источник на английсокм. Надеюсь, владеете?
Повторяю: уязвимость касалась продукта Kaspersky Internet Security 2011, позволяющего вносить в критичные ветки реестра изменения и не отслеживающего самостоятельно доверенных издателей сертификатов. Уязвимость касалась октября-ноября прошлого года, на тот момент по понятным причинам не публиковалась.
Каким мне нужно это выделить шрифтом, чтобы сюда не приплетали Microsoft?
1. Фейковый «Microsoft Root Authority» добавляется в HKLM из рег-файла. Не вижу никаких сложностей создать самоподписанный сертификат с любым именем
2. Ну да, ниже в статье и приводится пример с импортом сертификата в HKLM (или Вы о чем то другом?). С таким же успехом пользователя можно просто попросить согласиться с UAC запросом.
3. Я согласился. MD5 уже слишком слаб для современной техники. С другой стороны, им уже и не пользуются. С третье — не стоит недооценивать глупость людей. Так что это таки реальный вектор
4. Шарашка в данном случае — это контора, выдающая сертификаты, цепочка доверия которых не заканчивается на одном из дефолтных trusted root сертификатов. Вполне допускаю, что кто-то может приобрести verisign/thawte сертификат и подписывать все подряд на основе только email, но такой сертификат быстро будет отозван. Подпись важна не сама по себе, важно чтоб подпись можно было проследить до trusted ca.
5, 6, 7. Да в прошлом году утекли два валидных сертификата от крупных производителей. Я не говорю, что это невозможно — я говорю, что это неоправданно сложно для среднего представителя vx сцены.
Насчет уязвимости — прошу прощения, неправильно понял. Но вообще менее, чем 100% срабатывание хипсов и сканеров/мониторов не может считаться уязвимостью, потому что это просто невозможно.
2. Ну да, ниже в статье и приводится пример с импортом сертификата в HKLM (или Вы о чем то другом?). С таким же успехом пользователя можно просто попросить согласиться с UAC запросом.
3. Я согласился. MD5 уже слишком слаб для современной техники. С другой стороны, им уже и не пользуются. С третье — не стоит недооценивать глупость людей. Так что это таки реальный вектор
4. Шарашка в данном случае — это контора, выдающая сертификаты, цепочка доверия которых не заканчивается на одном из дефолтных trusted root сертификатов. Вполне допускаю, что кто-то может приобрести verisign/thawte сертификат и подписывать все подряд на основе только email, но такой сертификат быстро будет отозван. Подпись важна не сама по себе, важно чтоб подпись можно было проследить до trusted ca.
5, 6, 7. Да в прошлом году утекли два валидных сертификата от крупных производителей. Я не говорю, что это невозможно — я говорю, что это неоправданно сложно для среднего представителя vx сцены.
Насчет уязвимости — прошу прощения, неправильно понял. Но вообще менее, чем 100% срабатывание хипсов и сканеров/мониторов не может считаться уязвимостью, потому что это просто невозможно.
1. Я Вас очень прошу: скачайте файл и посмотрите его. Потом будем говорить. В примере Microsoft Root Authority валидный, фейковый выданный им Microsoft Code Signing RSA.
2. Тут всё верно. Кстати, UAC многие отключают сами :)
3. Рад, что мы поняли друг друга.
4. Но тем не менее такие «шарашки» есть и ими пользуются.
5,6,7. Ну почин дан — подождём :)
Согласен, но как способ обхода хипсов — тоже вариант.
2. Тут всё верно. Кстати, UAC многие отключают сами :)
3. Рад, что мы поняли друг друга.
4. Но тем не менее такие «шарашки» есть и ими пользуются.
5,6,7. Ну почин дан — подождём :)
Согласен, но как способ обхода хипсов — тоже вариант.
1. Я похоже как обычно чего то недопонимаю, но импортируется именно фейковый Microsoft Root Authority (поле Subject):
При этом он самоподписан: Issuer == Subject
При этом он самоподписан: Issuer == Subject
Ну тогда и я что-то не понимаю:
Да, и оговорюсь сразу: я — не автор этого примера. история событий такова, один не очень чистоплотный дядя предложил покупать подписи Microsoft на хакерском форуме. В качестве примера выложил это и ещё кое-что. В принципе, техника понятна, но до сих пор для меня загадка, где он нашёл издателя Microsoft Root Authority и почему он распознаётся как валидный (скрин выше).
Это самоподписанный сертификат для «Microsoft Root Authority». Валидный он потому что самоподписан. А распознается потому, что был вручную добавлен в Trusted Root CAs.
Да вот нет — я не добавлял ничего в реестр, а приведённый скрин — с чистой виртуалки. Так что не то. Сам в недоумении.
Кроме того — есть идеи, чем злоумышленник мог добавить поля Х500? Потому как тот же makecert такую подробность сделать не позволяет.
Кроме того — есть идеи, чем злоумышленник мог добавить поля Х500? Потому как тот же makecert такую подробность сделать не позволяет.
Он там есть (даже два, но CurrentUser-ский стор игнорируется при проверке валидности). С таким же именем и серийником (но другим отпечатком пальца). Но подпись нижележащего сертификата не проходит (что естественно — публичные ключи то тоже разные). В certification path он попал, потому что подошел по Issuer-у и Serial Number-у. Попробуйте:
Что же до генерации, как минимум OpenSSL позволяет генерировать запросы на сертификаты (ну и сами самоподписанные сертификаты) с любыми полями. Попробую сейчас поковырять как это можно дотнетом сделать
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 позволяет генерировать запросы на сертификаты (ну и сами самоподписанные сертификаты) с любыми полями. Попробую сейчас поковырять как это можно дотнетом сделать
То есть в принципе он прописал CN и серийный номер, соответствующий Microsoft Root Authority и тогда сертификат включается в цепочку certification path, хотя и признаётся невалидным? Это очень интересно! Спасибо!
Стоп, нет, ничего не выйдет. Если я хочу сделать в качестве Issuer упомянутого Microsoft Root Authority, который к тому же по умолчанию сидит в Доверенных корневых центрах сертификации, то я должен указать что-то типа makecert -in «Microsoft Root Authority» — что никогда не будет выполнено, поскольку у меня нет private key к издательскому Microsoft Root Authority. То есть я никак имя издателя не впишу в самоподписанный сертификат, а тогда вообще не понятно, как тот издатель попалд в путь сертификации.
Вы можете опробовать Вашу теорию в практике? Возможно, я Вас неправильно понимаю.
Вы можете опробовать Вашу теорию в практике? Возможно, я Вас неправильно понимаю.
Это не тот Root Authority и не тот CSPCA. Это легко посмотреть по thumbprint-ам. Оба этих сертификата были сгенерированы НЕ в Microsoft, а злоумышленником (если бы там ДЕЙСТВИТЕЛЬНО была подпись Microsoft Root Authority — не нужно было бы ставить фейк).
Два сертификата (в том числе и CSPCA) встроены в экзешник, а корневой — устанавливается из reg файла. Во всей цепочке нет ни одного «реального» сертификата
На практике нужно сгенерировать самоподписанный MRA, сгенерировать и подписать им CSPCA и потом подписать экзешник. Публичную часть фейкового MRA закинуть в реестр.
Два сертификата (в том числе и CSPCA) встроены в экзешник, а корневой — устанавливается из reg файла. Во всей цепочке нет ни одного «реального» сертификата
На практике нужно сгенерировать самоподписанный MRA, сгенерировать и подписать им CSPCA и потом подписать экзешник. Публичную часть фейкового MRA закинуть в реестр.
В общем, вот здесь все очень подробно расписано.
А при чем тут rapidssl? Они предоставляют сертификаты для веба, которые не могут использоваться для подписи кода.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Цифровые подписи в исполняемых файлах и обход этой защиты во вредоносных программах