eToken VS ruToken - Форум по вопросам информационной безопасности

malotavr, опишите, пожалуйста, подробнее атаку с командой от имени пользователя. На примере любой какой-нибудь операции, только от начала до конца, если можно - с задачи злоумышленника до ее успешной реализации. Мне кажется, несколько теоретическое построение.

ПС: Обратите внимание, пожалуйста, что аппаратно шифровать рутокеном можно только ОЧЕНЬ неторопливо. Когда речь идет о приличной скорости - это программная реализация (известны же возможности того процессора, на котором он построен). Поэтому плюсы от этой аппаратности не стоит преувеличивать (это на всякий случай так, что я не то чтобы рутокен отстаиваю своим вопросом )) ).

К вопросу ALEXey - если устройства Вы приобретаете для ХРАНЕНИЯ ключей, то речь наверняка идет о ключах подписи, значит, аппаратный ГОСТ 28147-89 для Вас погоды не делает. С точки зрения хранения ключей подписи разницы нет, но рутокен - дешевле.

Если же речь идет о генерации ключей и непосредственных криптографических вычислениях, то имеет смысл рассматривать другие альтернативы. В частности, ПСКЗИ ШИПКА. В ней и российские, и импортные алгоритмы аппаратно реализованы.

> На примере любой какой-нибудь операции, только от начала до конца, если можно - с задачи злоумышленника до ее успешной реализации.

Издеваетесь? :) Это стандартная техника, который используется при фишинге.

Злоумышленнику требуется решить три задачи:
1. Получить доступ к рабочему месту пользователя
2. Поднять себе привилегии до локального администратора, LOCAL_SYSTEM или до получения системной привилегии SE_DEBUG
3. Перехватить PIN
4. Выполнить криптографическую операцию (единственое новгшество, которое требуется нарушителю)

Решение

1. Стандартная атака на рабочее место. Методов - десятки, от спамовой рассылки до адресной атаки с элементами социальной инженерии. Результат атаки - пользователь идет браузером по указанной нарушителем ссылке, открывает Flash-ролик, вордовый или PDF документ, RARовски архив - и в его сессии отрабатывает эксплойт. Уязвимость - непропатченный клиентский софт, который не патчится в 100% организаций. Результат - на рабочем месте пользователя работает троян с reverse shell до сервера нарушителя.

2. Методов повышения привилегий тоже десятки, от эксплуатации уязвимостей ОС до выдергивания и брутфорса парольных хэшей. Используемые уязвимости - непропатченная операционка (80% организаций) или наплевательское отношение к рекомендациям Microsoft по настройке перационой системы (100% орагнизаций). Результат очевиден, нам существенно только наличие привидегии SE_DEBUG, которая позволяет трояну нарушителя работать с памятью других процессов.

3. Перехват PIN - на примере eToken (с другими носителями работает аналогично). Выполняется стандартная атака DLL injection. Используя стандартную функцию Win32 API CreateRemoteThread троян создает в одном из процессов eToken RTE новый поток. В качестве функции потока используется стандартная функция Win32 API LoadLibrary, в качестве ее аргумента - имя одной из DLL трояна. В результате в память процесса RTE загружается эта DLL, управление передается ее функции инициализации.

Функции инициализации доступна вся виртуальная память процесса, поэтому она перестраивает блок импорта/экспорта так, чтобы вместо функции создания окна ввода PIN вызывалась бы одна из функций инъектированной DLL. Эта функция, в свою очередь, показывает модальное диалоговое окно ввода PIN, и после его закрытия получает доступ ко всем введенным в это окно даным (в том числе - к элементу управлдения EditBox , в котором в открытом виде лежит PIN.

4. Троян готовит сообщение, которое нужно подписать, инициализирует контекст для работы с криптоядром токена, вызывает в этом контексте функцию MS CryptoAPI CryptSignMessage, передавая в качестве аргумента созданное рояном подписываемое сообщение, аналогично п. 3 подавляет создание модального диалогового окна ввода PIN, и сразу возращает стыренное на шаге 3 значение PIN. Криптоядро послушно выполняет запрошенную операцию.

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

А что за объект "сообщение", которое троян будет подписывать от лица пользователя?

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

Вашу квалификацию очень уважаю, потому и спрашиваю ))

Я объясню, почему я таким странным образом ставлю вопрос.
Мне понятно, как можно использовать украденный закрытый ключ. Украв его, я могу не привязываться к сеансу работы легального владельца (когда его - етокен, как мы с Вами решили? ;) ) подключен к компьютеру и возможно обращение к его криптодвижку.
Я спокойно, не обязательно даже на этом же компьютере, не прибегая к написанию программ, а вполне прямо - составляю, например, извещение, или что мне там еще нужно, и подписываю.
А каковы мои действия, если я знаю всего лишь пин? Ну, то есть напрашивается - кража токена (неприятно, конечно, да). А система с подготовкой того, что мне нужно подписать на чужом ключе, с помощью трояна... ну, то есть, наверное, все возможно, но как-то очень уж трудоемко. Сильно увеличивается цена вопроса. Обычно в тех системах, где обрабатываются документы, такая атака на которые - реальна, все же есть защита от НСД достаточного уровня, чтобы троян не заработал ))
Хочется в это верить, по крайней мере.

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

> Я хочу понять, что конкретно, подписанное от моего лица может возникнуть, и как это подписанное от моего лица станет использовать злоумышленник.

Самый распространенный случай - платежи в системах Клиент-Банк. А хакера стоит точно такая же клиентская софтина, которой он легально пользуется. Собственно, все, что ему нужно - разобраться в протоколе обмена информацией между банком и клиентом. Как правило, программисты - существа ленивые, и для обмена используется один из стандартных форматов - S/MIME или XML. Используя свой комплект ключей, реверсер сравнительно легко этот формат расковыривает. Расковыряв протокол, ему уже несложно понять формат сообщения и подготовить абсолютно корректное платежное поручение. Ему нужны только ваши платежные реквизиты, ваш ключ и ваш PIN к ключевому носителю.
-
Когда такие системы только появлялись, атака на такую систему выглядела совсем просто: отслеживалось наличие в дисководе ключевой дискеты, ее содержимое копировалось, после чего нарушитель, использую точкно такую же клиентскую программу, что и клиент банка, выполнял платеж от его имени. Это было совсем просто, и это до сих пор актуально для многих банков.

Чтобы защититься от этого, пошли по двум путям: во-первых, стали выдавать клиентам токены, во-вторых, стали фиксировать за клиентом IP-адрес, с которого платежи могут приниматься. Оба этих решения быстро были обойдены. Ключ их eToken'а выковыривается примерно так же, как я и описал, только шаг 4 выглядит по-другому и достаточно сложно. А из-за фиксации IP-адреса, в платежных системах многих банков красть ключ бесполезно - нужно не только подписать платежное поручение вашим ключом, но и отправить его с вашей машины.

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

Да, это сложно. Но ненамного сложнее, чем написать трояна к банкомату :)

> Обычно в тех системах, где обрабатываются документы, такая атака на которые - реальна, все же есть защита от НСД достаточного уровня, чтобы троян не заработал ))

Блажен, кто верует :)
Я уже не раз приводил оценки: получение полного контроля над доменом AD организаций, которые достаточно серьезно относится к своей безопасности, занимает 3-5 рабочих дней. Проблема в низком "среднебольничном" уровне квалификации российских безопасников, поэтому тот набор мер и средств, что многие считают "защитой от НСД достаточного уровня", для реального нарушителя препятствием не является вовсе.

malotavr,
> Я уже не раз приводил оценки: получение полного контроля над доменом AD организаций, которые достаточно серьезно относится к своей безопасности, занимает 3-5 рабочих дней. Проблема в низком "среднебольничном" уровне квалификации российских безопасников, поэтому тот набор мер и средств, что многие считают "защитой от НСД достаточного уровня", для реального нарушителя препятствием не является вовсе.

Не соглашусь с Вашим утверждением насчёт 3-5 дней. Либо много меньше, либо наоборот.
Аудит событий в течение одних лишь попыток получить доступ к AD, не прибегая к социальной инженерии, - тоже не проблема?
Не подумайте, не пытаюсь усомниться в Вашей квалификации, интересны идеи.

Коллеги, ваша высокоинтеллектуальная дискуссия крайне интересна, но несколько уклоняется от сути вопроса.
Полагаю, что с вопросами цены следует обратиться к разработчикам-производителям этих самых токенов.
Рутокен -все бы ничего, но сертификация этого устройства в ФСБ на соответствие гост 28147-89 имеет ограниченный характер, поскольку идет ссылка на формуляр, а там на другой документ из комплекта эксплуатационной документации и из него мы узнаем что:
Поскольку Rutoken не имеет аппаратной генерации ключей, в состав сертифициро-ванного изделия входит АРМ для генерации первичной ключевой информации (глав-ного ключа шифрования Rutoken ) - "КРИПТОН-ЗАМОК/К"– один на организацию (подразделение), не подключенный к сети.
Состав сертифицированного СКЗИ «ruToken» входит:
- автоматизированное рабочее место (АРМ ГК), предназначенное для генерации первичной ключевой информации (ключ датчика случайных чисел) и записи ее в аппаратные модули «ruToken» (одно на сеть связи, не подключенное к сети компьютерной связи) (КБДЖ.466452.006). В комплектации:
устройство «КРИПТОН-ЗАМОК/К», включающий аппаратный ДСЧ (КБДЖ.468243.035);
драйвер устройства «КРИПТОН-ЗАМОК/К» (КБДЖ.00174-0100);
библиотека специальных функций устройства «КРИПТОН-ЗАМОК/К» для ОС Windows 2000/XP/2003 (КБДЖ.00600-0100);
программа rtARM_GK.exe для записи ключа для ДСЧ в память аппаратного модуля «ruToken» (КБДЖ.00142-0100)
Кроме того, данный сертификат требует соблюдение следующих условий:
Срок действия пароля (PIN-кода) пользователя – не более 30 дней.
Срок действия главного ключа – не более 1 года. Уничтожение или замена главного ключа должна производиться с полным переформатированием Rutoken (с полной потерей всех пользовательских данных).
При использовании Rutoken в системах, подлежащих обязательной защите, в обяза-тельном порядке требуется проведение работ по оценке корректности встраивания.
Поскольку Rutoken является СКЗИ (в соответствии с сертификатом) то
Организация-поставщик и ее партнеры-дилеры должны иметь соответствующие ли-цензии ФСБ на распространение шифросредств.
Требуется вести поэкземплярный учет (в т.ч. при генерации ключа в журнале учета пользователей должна делаться соответствующая запись с указанием Ф.И.О. пользователя и даты генерации ключа).
Действуют запрет на вывоз Rutoken за пределы РФ, без оформления соответ-свующего разрешения в ФСБ.
Должны быть проведены работы по оценке корректности встраивания СКЗИ Rutoken в информационную систему.
Сертификат №1461 ФСТЭК России от 18 сентября 2007 г. и Сертификат №1395 ФСТЭК Рос-сии от 30 мая 2007 г. получены не на ключевой носитель Rutoken а на системное и прикладное программное обеспечение (драйвера). Сертификат соответствия ФСТЭК РФ №1461, по 3-му уровню контроля отсутствия НДВ подтверждает отсутствие функций и свойств не заявленных в документации на изделие
Поддерживаемые операционные системы
Windows 98, МЕ, 2000, ХР, 2003
При использовании Vista и 7 –условия этих сертификатов не соблюдаются.
Сертификат ФСБ требует соблюдения следующих условий:
Срок действия пароля (PIN-кода) пользователя – не более 30 дней.
Срок действия главного ключа – не более 1 года. Уничтожение или замена главного ключа должна производиться с полным переформатированием Rutoken (с полной потерей всех пользовательских данных).

А не подскажете, что быстрей подписывает, рутокен или Етокен?
Иногда важно подписать очень быстро ..