2. АНАЛИЗ ЗАЩИЩЕННОСТИ ПРОТОКОЛА SSL/TLS

2.1 Модель угроз протокола SSL

2.1.1 Атака открытого текста

SSL имеет уязвимость, при использовании атаки с выбранным открытым текстом, при этом злоумышленник может генерировать сообщения, шифровать их и анализировать криптограммы. На практике данная атака заключается в легком восстановлении информации с низкой энтропией, такой как пароли и PINs, которые прежде кодируются. Данное использование SSL для передачи именно этих данных, представляет серьезную угрозу для будущих версий SSL. При использовании блочного шифра для шифрования, протокол SSL использует блоки шифрования (CBC), которые для кодирования требуют вектор инициализации (IV).

Вектор инициализации (IV) в SSL - это случайная строка, которая генерируется в начальном приветствии (handshake phase), но на выходе IV является криптографическим блоком. На практике IV является уязвимостью SSL, при использовании низкой энтропии строк, таких как пароли и PINs, которые кодируются. Кроме того, открытая среда Web-браузера обеспечивает «точку входа» для данной атаки через разрешенные порты. Выполнение данной атаки будет значительно легче, чем установка «Трояна».

Данная атака основана на том, что к настоящему времени SSL использует слабые варианты шифрования с помощью блочных шифров (CBC). Метод СВС требует блок вектора инициализации (IV) для каждого сообщения, которое закодировано. В стандарте криптографического использования СВС для каждого сообщения выбирается новый произвольный IV. Тем не менее, в SSL только инициализация IV выполняется случайным образом; IV для последующих сообщений является последним блоком зашифрованного текста. В конкретном случаи, злоумышленник может заранее определить IV для дальнейшего использования его при кодировании следующих сообщений. Это приспосабливает атакующего, выполняющего атаку методом «выбранного открытого текста», устанавливать величину конкретного блока открытого текста. Кроме того что это нарушает принцип безопасного шифрования, это также позволяет злоумышленнику полностью определить величину пароля или PIN (эти данные очень ценные), многократно подбирая возможные величины для этой строки, пока не получит правильного значения. Поэтому при использовании SSL пользователь не может быть полностью уверен в безопасности передаваемой информации.

Как уже было сказано, протокол SSL расположен на «транспортном» уровне, следовательно, «сеансовый» уровень и уровень «приложений» находятся над ним. Как таковой, SSL получает с верхних уровней исходные данные, этот открытый текст фрагментирован в блоки данных, длина которых не менее 2¹⁴ байт. Здесь данные обрабатываются (сжатие) и посылаются в следующем виде:

- тип сообщения(1 байт);

- номер версии (2 байта);

- длина счетчика (2 байта);

- фрагмент открытого текста ();

- код аутентификации сообщения (обычно 20 байт);

- заполнение (0-7 байт);

- длина заполнения (1 байт).

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

Несмотря на длину сообщения открытого текста, есть время когда только небольшая последовательность байтов является критическим значением. Для примера приведем пароль. Ранее было рассмотрено, что злоумышленник должен как-нибудь узнать, какой блок открытого текста будет содержать искомую величину. Заметим, тем не менее, что это легко сделать посредством чтения исходных файлов для страниц, которые использованы в отправлении искомой величины. Для этого просто требуется знание HTTP, HTML, и протоколов CGI, а также возможно Javascript. Обычно доступный browsers имеет исходную команду ”showpage”, которая отображает страничный исходный код HTML. Оба «элемента формы», которые компилируют данные пользователя, также могут быть пригодным для нападающего, как и дополнительный код Javascript, проверяющий свой формат. Злоумышленнику остается только прочитать это.

Атака открытого текста производится, когда атакующий имеет соображения о том, какого типа сообщения посылаются в зашифрованном виде. Злоумышленник может формировать базу данных, где ключами являются зашифрованные строки известного текста (или открытого текста). Если база данных создана, с помощью простых просмотровых функций можно идентифицировать ключ сессии, который соответствует определенному зашифрованному блоку данных. Если ключ сессии удалось раскрыть, можно дешифровать весь поток данных. Общедоступные аппаратные средства могут сделать эту работу быстрее и эффективнее. Алгоритм данной атаки приведен на рисунке 2.1.

Из-за самой природы SSL атаки открытого текста возможны. Например, наиболее часто встречающейся строкой, пересылаемой HTTP-клиентом серверу, является "GET". SSL пытается противостоять этим атакам, используя большие ключи сессии. Сначала клиент генерирует ключ, который длиннее чем допускается экспортными ограничениями, и посылает часть его открытым текстом серверу (это разрешено экспортными правилами). Открытая часть ключа объединяется с секретной частью, чтобы получить достаточно длинный ключ, например 128 бит, как этого требует RC4.



Рисунок 2.1 - Алгоритм атаки открытого текста.

2.1.1.1 Методы предотвращения атаки на открытый текст

Способ блокирования атак открытого текста заключается в том, чтобы сделать объем необходимого общедоступного оборудования неприемлемо большим. Каждый бит, добавляемый к длине ключа сессии, увеличивает размер словаря в два раза. Использование ключа сессии длиной 128 бит делает размер словаря далеко за пределами современных технических возможностей. Даже если может использоваться меньший словарь, он должен быть сначала сформирован с использованием открытых битов ключа. Это достаточно долговременный процесс.

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

Заметим, что следствием всех этих мер защиты SSL является то, что самым простым и дешевым способом атаки становится лобовая атака ключа. Такого рода атаки требуют большой памяти и много времени и их стоимость достаточно легко оценить. Для 128-битового ключа стоимость его раскрытия можно считать бесконечной. В случае 40-битного секретного ключа цена много меньше, но все равно за пределами возможностей “дикого хакера”.

2.1.2 Использование «закладок» для раскрытия выбранного открытого текста

Данная уязвимость позволяет выполнить атаку открытого текста при взаимодействии слоя SSL и web browser's. Это можно выполнить при помощи «закладок» (plug -ins) злоумышленника. Интерфейс на Netscape и Internet Explorer через «закладки» (plug -ins) нормализован и легко доступен. При этом «закладка» содержит «Троян», который не вызывает никаких подозрений у пользователя при его работе за компьютером. На примере известного «Трояна» SpyWare, мы приходим к выводу, что это вполне осуществимо. Данный «Троян» устанавливается как скрытый plug-in и собирает пользовательскую информацию без срочного подтверждения злоумышленника. Данная атака легче, чем атака, в которой Троян установлен исключительно для слежки за паролем, вводимым на клавиатуре.

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

2.1.2.1 Методы борьбы с «закладками»

Для избегания данной атаки используются следующие методы:

- Используется сжатие. При этом на обоих концах связи должно использоваться сжатие, которое иногда помогает защитить SSL.

- Использование случайных IV. Для обеспечения безопасной передачи данных с использованием SSL, при каждом кодировании сообщения нужно менять значение IV. Главной задачей при этом является генерация истинно случайного IV. Например, вместо простого использования (т.е последний блок предыдущего зашифрованного текста) как IV , протокол мог бы использовать , где sk - общий секретный ключ, используемый для шифрования, H - хэш функция.

- Изменение способа шифрования. Другим способом обеспечения безопасности является использование различных способов шифрования (а не только СВС). При этом можно использовать способ «совпадений», который заключается в использовании специального счетчика, значение которого можно вносить в шифротекст. Если значение этого счетчика установить в «0», то IV не устанавливается и не распространяется в течении фазы согласования.

Если придерживаться данных методов, то атаки plug-in не легки в реализации, и осуществить их может хороший «хакер». Специалистами проводится огромная работа по устранению известных уязвимостей. Поэтому реализация атак на SSL с каждым днем усложняется.

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

Одним из атрибутов любого файла является отметка о времени его последней модификации. Однако она не может служить надежным индикатором наличия в системе «Трояна». Дело в том, что ей очень легко манипулировать. Аналогично дело обстоит и с размером файла. Злоумышленник, который пытается внедрить троянскую программу, попытается достать исходный текст соответствующей программы, в которую планируется подставить троянца, и внимательно проанализирует его на предмет присутствия в нем избыточных элементов, которые могут быть удалены безо всякого ощутимого ущерба. Тогда вместо найденных избыточных элементов он вставит в программу своего троянца и перекомпилирует ее заново. Если размер полученного файла окажется меньше или больше размера исходного, процедура повторяется. Итак до тех пор, пока не будет получен файл, размер которого в наибольшей степени близок к оригиналу.

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

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

Одной из наиболее удобных в эксплуатации и эффективных является утилита TripWire [9]. Она позволяет производить однонаправленное хэширование файлов при помощи нескольких алгоритмов, в том числе - MD4, MD5, SHA. В алгоритме хэширования MD4 исходная битовая последовательность дополняется так, чтобы ее длина в битах плюс 64 нацело делилась на 512. Затем к ней приписывается 64-битовое значение ее первоначальной длины. Полученная таким образом новая последовательность обрабатывается блоками по 512 бит с помощью специальной итерационной процедуры. В результате на выходе МD4 получается так называемая “выжимка” исходной последовательности, имеющая длину 128 бит. Алгоритм хэширования MD5 похож на MD4 и по способу дополнения исходной битовой последовательности, и по методу ее обработки, и по размеру получаемой «выжимки» (те же 128 бит). Однако каждый 512 битовый блок подвергается не трем, как в MD4, а четырем циклам преобразований.

Для борьбы с «Троянами» в операционной системе Windows можно воспользоваться программой eSafe Protect компании Aladdin Knowledge System [10]. Функционально eSafe Protect делится на три компонента - антивирус, персональный брандмауэр и модуль защиты компьютерных ресурсов. Антивирус избавляет компьютер от вредоносных программ. Персональный брандмауэр контролирует весь входящий и исходящий трафик по протоколу TCP/IP. Для защиты ресурсов компьютера, на котором установлен программный продукт eSafe Protect, создается специальная изолированная область - так называемая «песочница». Все автоматически загружаемые из Internet Java-аплеты и компоненты ActiveX сначала помещаются в «песочницу», где они находятся под наблюдением eSafe Protect. Если попавшая в «песочницу» программа попытается выполнить какое-либо недозволенное действие, то оно будет немедленно блокировано. В течение заданного интервала времени (от 1 до 30 дней) каждое приложение проходит «карантинную» проверку в «песочнице».

Для защиты операционной системы от имитаторов необходимо, чтобы в ней выполнялось два условия, которые являются необходимыми:

- системный процесс, который при входе пользователя в систему получает от него соответствующее регистрационное имя и пароль, должен иметь свой собственный рабочий стол, недоступный другим процессам;

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

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

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

1) во время ввода пароля переключение раскладок клавиатуры не разрешается;

2) конфигурировать цепочку программных модулей, участвующих в работе с паролем пользователя, может только системный администратор;

3) доступ к файлам этим модулей имеет исключительно системный администратор.

Соблюдать данные правила в локализованных для Украины версиях ОС принципиально невозможно. Дело в том, что средства создания учетных пользовательских записей на русском языке являются неотъемлемой частью таких систем. Только в англоязычных версиях систем Windows NT и UNIX предусмотрены возможности, позволяющие поддерживать уровень безопасности, при котором соблюдаются все три перечисленные условия.

2.1.3 Атака раскрытия шифров

SSL зависит от нескольких криптографических технологий. Шифрование с открытым ключом RSA используется для пересылки ключей сессии и аутентификации клиента/сервера. В качестве шифра сессии применяются различные криптографические алгоритмы. Если осуществлена успешная атака на эти алгоритмы, SSL не может уже считаться безопасным. Атаки против определенных коммуникационных сессий могут производиться путем записи сессии, и затем, потратив большое количество компьютерного времени, предпринимается попытка подобрать ключ сессии или ключ RSA. В случае успеха открывается возможность прочесть переданную информацию. Этот подход легче, чем попытка вскрытия криптографии всех возможных сообщений. Заметим, что SSL пытается сделать цену таких атак выше, чем выгоды от успешной атаки, таким образом, делая ее пустой тратой времени и денег.

2.1.4 Ошибка в программном продукте

SSL как таковой, теоретически, может обеспечить практически полную защиту любого Интернет соединения. Но, любая вещь в этом мире не существует в пустоте. Это означает, что для успешного функционирования SSL, кроме него самого, необходимы также и чисто программные средства, претворяющие технологию SSL в жизнь. Программы, так или иначе использующие SSL протокол, как ни странно, является порой самым уязвимым местом этой технологии. Именно из-за ошибок в этих программах, возможна почти полная потеря, всех, достигнутых после использования SSL щитов и заслонов [6]. К таким программным инструментам, прежде всего, относятся активно используемые нами Интернет-браузеры.

Одним из самых показательных критериев уровня защиты, является размер используемых ключей. Чем больше этот размер, тем соответственно надежнее защита. Браузеры в основном используют три размера: 40, 56 и 128 бит, соответственно. Причем, 40-а битный вариант ключа недостаточно надежен. Таким образом, предпочтительнее использовать именно 128-ми битные ключи. Применительно к Internet Explorer от Microsoft, это означает загрузку дополнительного пакета (security pack). В настоящее время браузеры всегда снабжаются исключительно 128-ми битной защитой. Для того чтобы установить, какой именно размер ключа используется в вашем браузере, в Netscape Navigator вам достаточно открыть подменю "Options/Security Preferences", а в Internet Explorer, подменю "Help/About".

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

2.1.5 Организация атаки в Outlook

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

Именно реализация SSL при общении компьютера с почтовым сервером и содержит уязвимость. Если почтовый клиент часто (например, каждые пять минут), обращается к серверу за новыми письмами, он отправляет туда одни и те же данные: зашифрованное имя пользователя, пароль и т.д. Хакеру достаточно один раз перехватить эти данные в зашифрованном виде, а затем начать направлять предполагаемые варианты пароля на сервер.

Скорее всего, угадать пароль с первого раза не выйдет, и сервер выдаст сообщение об ошибке, также зашифрованное с помощью SSL. Сравнивая сообщения об ошибках, можно достаточно быстро восстановить пароль [6].

При практической реализации взлома использовали программу Outlook Express, которая обращалась к почтовому серверу по протоколу IMAP каждые пять минут. Кроме взлома почтовых ящиков, описанный метод ни на что не годится. Перехватывать обмен данными между почтовым сервером и клиентом достаточно непросто, так что вряд ли эта уязвимость в SSL будет эксплуатироваться широко. Тем не менее, в некоторых случаях полезно помнить о потенциальной опасности взлома. Схема данной атаки показана на рисунке 2.2.



Рисунок 2.2 - Алгоритм атаки на Outlook Express.

2.1.6 Атака отклика

Атака отклика достаточно проста. Злоумышленник записывает коммуникационную сессию между клиентом и сервером. Позднее, он устанавливает соединение с сервером и воспроизводит записанные сообщения клиента. SSL отбивает эту атаку, с помощью специального кода "nonce" (идентификатор соединения), который является уникальным.

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

Злоумышленник с большими ресурсами может записать большое число сессий между клиентом и сервером и попытаться подобрать “правильную” сессию, основываясь на посланном сервером коде nonce, посылает в сообщении SERVER-HELLO. Однако коды nonce SSL имеют, по крайней мере, длину 128 бит, таким образом, злоумышленник будет вынужден записать примерно 264 кодов nonce, при этом он получит вероятность угадывания лишь 50%. Это число достаточно велико, чтобы сделать такого рода атаки бессмысленными (см. Рисунок 2.3).



Рисунок 2.3 - Алгоритм атаки отклика

2.1.7 Атака «посредника»

Атака «посредника» (man-in-the-middle) предполагает участие в коммуникационной сессии трех субъектов: клиента, сервера и посредника-злоумышленника, находящегося между ними. Такое положение позволяет злоумышленнику перехватывать все сообщения, следующие в обоих направлениях, и при желании подменять их.

«Посредник» ввыдает себя сервером для клиента и клиентом для сервера. Промоделируем данную атаку. Для реализации имеет следующие входные данные:

- клиент, сервер и злоумышленник находятся в одной сети;

- имеются программы-вредители (Snifer, Nmap (Win), WinNuke, Smurf);

- обмен ключами ведется по сети;

Этапы выполнения атаки (рисунок 2.4):

- прослушиваем весь трафик, идущий по сети (пользуемся Sniffer), чтобы перехватить секреты и handshake;

- устанавливаем IP-адреса машин, участвующих в SSL-диалоге;

- определяем тип ОС (пользуемся Nmap);

Дальше можно по-разному продолжить атаку: либо вывести из строя клиентскую машину и выдавать себя за клиента-участника SSL-диалога; либо просто посылать свои SSL-блоки, выдавая их клиентскими. - меняем свой Mac-адрес и IP-адрес(10.168.1.1).

Рисунок 2.4 - Атака «посредника»

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

2.1.7.1 Настройка Apache на использование клиентских сертификатов

Помимо SSL Web-сервера существует более защищенный метод аутентификации пользователей: клиентские SSL сертификаты, или «личные» сертификаты для каждого пользователя. Следовательно, использование сертификатов более безопасный метод, чем стандартные парольные решения, потому что злоумышленнику в случае с сертификатом понадобится получить обе части для аутентификации - приватный ключ, согласованный с пользовательским сертификатом и парольную фразу. Более того, в отличие от стандартного пароля, парольная фраза сертификата не передается по сети, а используется только на локальной машине для расшифровки приватного ключа. Применение сертификата даст возможность избежать атаку «человек посередине». Но существуют современное программное обеспечение, которое компрометирует сертификаты (Приложение В).

Осуществить этот метод аутентификации не слишком сложно. Администратору потребуется выполнить всего несколько простых шагов, в отличие от более популярного метода Базовой Аутентификации (Basic Authentication).

Для настройки Apache на поддержку аутентификации клиентов по сертификатам X.509v3, нам понадобиться выполнить четыре шага:

1) задействуем аутентификацию клиентов

Добавим следующие директивы в httpd.conf:

SSLVerifyClient require

SSLVerifyDepth 1;

2) установим сертификат СА в директорию Apache:

install -m 644 -o root -g sys ca.crt /usr/local/apache2/conf/ssl.crt/;

3) присвоим значение директиве SSLCACertificateFile (в httpd.conf), равное пути СА сертификата, который мы только что установили:

SSLCACertificateFile /usr/local/apache2/conf/ssl.crt/ca.crt;

4) теперь перезагрузим Apache:

/usr/local/apache2/bin/apachectl stop

/usr/local/apache2/bin/apachectl startssl.

Теперь доступ к Web-серверу через SSL будет разрешаться только тем браузерам, у которых установлен клиентский сертификат, подписанный нашим местным СА. Набрав URL сайта в браузере. После установки SSL соединения MS Internet Explorer попросит нас выбрать клиентский сертификат, который мы бы хотели использовать.

2.1.7.2 Создание клиентских сертификатов

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

Действия, которые необходимо выполнить для создания клиентского сертификата:

1) создаем пользовательскую пару приватный/общедоступный ключ вместе с запросом на сертификат. openssl req;

2) пользователь посылает запрос на сертификат (request.pem) в местный СА для подписи;

3) задача местного СА - проверить правильно ли пользователь заполнил поля в запросе на сертификат;

4) после верификации запрос на сертификат (request.pem) следует скопировать в директорию $SSLDIR/requests на местном хосте СА, при помощи переносного устройства, например USB флэшки;

5) местный СА должен подписать сертификат следующим образом. Эти команды нужно выполнить на хосте СА:

openssl ca \

-config $SSLDIR/openssl.cnf \

-policy policy_anything \

-extensions ssl_client \

-out $SSLDIR/requests/signed.pem \

-infiles $SSLDIR/requests/request.pem;

6) местный СА пришлет пользователю подписанный сертификат (signed.pem);

7) после получения подписанного сертификата пользователю необходимо сохранить приватный ключ вместе с сертификатом в формате PKCS#12;

8) только что созданный файл client.p12 следует защитить парольной фразой, трудной для подбора. Все остальные файлы (включаю незашифрованный приватный ключ, подписанный сертификат и запрос на сертификат) следует удалить, используя утилиту wipe:

wipe client.key signed.pem request.pem;

9) клиентский сертификат, вместе с приватным ключом должен быть установлен в Web-браузер пользователя.

Теперь сертификат можно найти в "Personal" (Личной) вкладке при просмотре сертификата (в меню in MS Internet Explorer -> вкладка "Content" (Содержание)-> "Certificates" (см. Рисунок 2.5).

Данный раздел можно использовать для лабораторных работ по курсу «Защиты информации в компьютерных сетях», при прохождении темы «протокол SSL».

Рисунок 2.5 - Пример клиентского сертификата

2.1.8 Пример атака на IDS

Используя различные программные средства, злоумышленники извлекают из передаваемых данных конфиденциальную информацию. Для выявления вторжений протокол SSL является единственным существенным препятствием. В большинстве систем SSL для сбора данных о сетевой деятельности используются средства анализа пакетов. Если передаваемые данные зашифрованы, то их анализ и проверку на "благонадежность" выполнить уже невозможно. Все IDS, работа которых основана на анализе сетевых пакетов, "не замечают" атаки на базе SSL.

Чтобы проиллюстрировать "возможности" IDS по выявлению атак, основанных на использовании протокола SSL, рассмотрим пример такой атаки на узел под управлением Windows, на котором установлен также Web-сервер IIS 4.0. В рамках примера рассматривается следующая сетевая конфигурация:

- сервер IIS прослушивает порты 80 и 443 узла 192.168.7.203;

- система выявления вторжений Snort запущена на узле webspy, прослушивающем тот же cетевой сегмент, в котором находится и узел 192.168.7.203;

- злоумышленник # 1 располагается на узле 10.0.0.1;

- злоумышленник #2 располагается на узле 10.0.0.2.

Против узла 192.168.7.203 было инициировано четыре атаки: две атаки МDАС RDS с узла 10.0.0.1 и две атаки Unicode cmd.exe с узла 10.0.0.2. Надо сказать, что один из хакеров в отличие от второго не пользовался SSL - протоколом. Если просмотреть все записи журнала сервера IIS узла 192.168.7.203 после хакерских атак, можно увидеть, что все Get- запросы были зарегистрированы. Но при этом в журналах системы Snort, запущенной на системе webspy, содержится только две записи (сохранились только те запросы, которые осуществлялись без использования SSL). В итоге, две атаки через безопасный протокол остались вне поля зрения IDS (рисунок 2.6).

Рисунок 2.6 - Атака на IDS

2.1.9 Туннелирование атак посредством протокола SSL

Для реализации НТТР-атак с использованием протокола SSL можно без проблем воспользоваться броузером. Для этого достаточно указать в адресе URL префикс https, а не http. Далее браузер сам позаботится о согласовании параметров SSL-сеанса и шифровании данных. Однако, если для реализации атаки взломщику нужно воспользоваться сценарием или утилитой, в которых отсутствует встроенная поддержка протокола SSL, придется прибегнуть к SSL-туннелированию. Этот метод подразумевает использование специальной программы, которая прослушивает порт 80 и при поступлении на него стандартных НТТР-запросов передает их через зашифрованное SSL- соединение указанному узлу. В рамках такой схемы передаваемые данные будут автоматически шифроваться и передаваться целевой системе. Построить SSL-туннель на базе пакета ОрепSSL совсем несложно, особенно в системе Unix, в которой используется демон inetd. Рассмотрим пример, когда злоумышленник находится на узле 10.0.0.1, а целевой Web -сервер установлен на узле 192.168.7.203 и прослушивает порт 443. Предположим, что злоумышленник хочет запустить на Web-сервере такую программу поиска ошибок, как Whisker. Для реализации задуманного плана злоумышленник создает SSL-туннель на другой системе, 10.0.0.2. При этом в файл /etc/inetd.conf на узле 10.0.0.2 он добавляет следующую запись: www. stream tcp nowait root /usr/sbin/tcpd /tmp/sslconnect.sh. Подобное изменение конфигурации приведёт к тому, что демон inetd будет передавать сценарию /tmp/sslconnect.sh весь TCP-траффик, приходящий на порт 80. В файле /tmp/sslconnect.sh содержится примерно такой код: #/bin/sh openssl s_client -no_tls1 -quiet -connect 192.168.7.203:443 2 /dev/null. Поскольку сценарий /tmp/sslconnect.sh запускается демоном inetd, все данные, подающие на ТСР-порт 80, воспринимаются утилитой openssl как данные, поступающие из стандартного входного потока. IР-адрес 192.168.7.203 целевого сервера жестко задан в самом сценарии. Один такой SSL-туннель одновременно можно использовать для взаимодействия только с одной системой. Параметры -no_tls1 -quiet предназначены для подавления вывода на экран заголовков SSL и обхода предупреждений SSL-аутентификации, генерируемых при использовании неподписанных сертификатов узлов. Все возвращаемые утилитой opensll данные отсылаются обратно через входящее ТСР-соединение демона inetd, поскольку сценарий передает все данные в стандартный выходной поток. Теперь в качестве целевого сервера утилиты Whisker взломщик может задать узел 10.0.0,2 и порт 80, а не узел 192.168.7.203. При этом шифрование и передача данных на узел 192.168.7.203, а также передача ответов по адресу 10.0.0.1 будут обеспечиваться SSL-туннелем. Более удачный и надежный SSL-туннель можно организовать с использованием утилиты stunnel (ее исполняемую версию для системы Windows, разработанную на базе библиотек OpenSSL, можно найти по адресу [8])

2.1.10 Схема высокоуровневой атаки

Выделяя минимальные аспекты SSL, нужно понимать атаки на высоком уровне. SSL протокол начинается с handshaking этапа, в течении которого договариваются о версии протокола, алгоритмы шифрования и сжатия, выполняется аутентификация, используется механизм «открытых ключей». Общие секреты, которые включают симметричные ключи и IV для каждого соединения, могут затем использоваться для симметрично-ключевого шифрования и аутентификации сообщения. Стандарт SSL включает симметрично-ключевое шифрование, используя при этом либо блочные, либо поточные шифры. Большинство реализации используют блочные шифры. Длина блоков в разных алгоритмах имеет разное значение, например DES использует 64 битовые блоки.

Предположим, что S- ключ, Х - блок, - сообщение, которое шифруется при помощи SSL, при этом получаем некоторое IV, которое обозначим , вычислим следующим образом:

C_i = F_sk(P_i C_{i =1}) (2.1)

Результирующий зашифрованный текст представляется как: С,…, , если получатель уже знает С, тогда он не должен быть передан. Чтобы декодировать, получатель вычисляет for i=1 to l следующим образом:

 = F_sk⁼¹ (Ci) C_i=1 (2.2)

На практике для безопасности выбирается новый IV для каждого сообщения, которое закодировано.

Предположим, что злоумышленник, который может установить открытый текст атаки, как-то хочет проверить величину любого блока открытого текста. Из выше сказанного злоумышленник, который наблюдал зашифрованный текст …, хочет определить, что блок независимого открытого текста Pj равняется некоторой строке P^* . Отметим, что злоумышленник знает IV, который будет использован при кодировании следующего сообщения. Рассмотрим теперь, что происходит, если злоумышленник заставляет отправителя кодировать сообщение , которое имеет начальный блок равный: . Первый блок зашифрованного текста вычисляется как:

(2.3)

Покажем также, что . Из этого следует, что если , следовательно: . На этом этапе злоумышленник должен проверить догадку для значения каждого блока открытого текста . На практике, выполняя вышеуказанную атаку некоторое время, при этом злоумышленник знает, что - одна из двух возможных величин, то через некоторое время он может определить фактическое значение . Аналогично, если нападающий знает, что - это одно из N возможных значений, тогда, повторяя атаку в среднем N/2 времени, злоумышленник может определить фактическое значение . Кроме уже нарушенного понятия безопасности, проделанное подразумевает, что данная атака может быть использована для определения величины короткого пароля.

Требования атаки. В случаи попытки восстановить пароль пользователя или PIN, кратко выделим требования к вышеописанной атаки , чтобы добиться успеха:

- злоумышленник должен узнать, какой открытого текста j будет содержать желаемую информацию (злоумышленник знает формат передачи HTTPS);

- злоумышленник должен знать . Тем не менее, пока зашифрованный текст следует по среде Internet, это осуществить не сложно;

- злоумышленник должен знать IV, который используется для следующего сообщения. Эту информацию злоумышленник должен извлечь из последнего блока зашифрованного текста предшествующего сообщения;

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

Реализация данной атаки возможна, если злоумышленник сможет убедить получателя использовать полученный встроенный блок (plug-in), как правильный. Чтобы быть уверенным, что получатель убежден в целостности сообщения, можно установить свое программное обеспечение, типа “Snifer”. Т.к Snifer не наблюдается в «Меню процессов» и в «Меню подключений», это делает наш метод более адекватным при применении данной атаки. Данные Web-странички (HTML - формат), в которыхх находится информация об версии SSL, могут отображаться с помощью browser. Некоторые данные передаются, как изображения (image-files). Чтобы использовать злоумышленником своего программного обеспечения, его нужно загрузить на атакуемой машине. В результате внедрения своего программного продукта, злоумышленник сможет наблюдать за нажатием клавиш на атакуемой машине (см. Рисунок 2.7).



2

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Рисунок 2.7 - Алгоритм высокоуровневой атаки.

2.1.11 Атака основанная на реализации RSA

Рассмотрим атаку, которая основана на реализации RSA в протоколах SSL/TLS. Эти протоколы включают PKCS (v.1.5) для кодирования RSA -секретной величины, которая является единственной, секретной величиной, использованной для получения всех конкретных сеансовых ключей. Следовательно, злоумышленник, при восстановлении premaster-секрета, сможет декодировать весь захваченный сеанс SSL/TLS. Включение номера версии PKCS в открытом тексте, но при использовании SSL/ TLS создается канал, который позволяет интерпретировать шифрование RSA. Злоумышленник получит возможность подписывать сообщения от имени сервера. На практике, в результате тестов, было доказано, что 2/3 выбранных протоколов SSL/TLS оказались уязвимыми. В данной дипломной работе будет рассмотрен метод атаки на PKCS (v.1.5), который называется атака Bleichenbacher's. Введем понятие “оракула плохой версии” (BVO).

2.1.11.1 Планирование и распространение атаки Bleichenbacher

Эта атака позволяет нам вычислять величину x = y^d mod N для любого данного целого значения у, где d - это неизвестная величина, N - модуль RSA. Эта атака основана на том, что злоумышленник для каждого зашифрованного текста С сообщает соответствующий открытый текст RSA P = C^d mod N . BVO, введенный в предыдущей части, может быть использован с полной уверенностью. Используя эту атаку для SSL/TLS, мы можем реализовать эту атаку для раскрытия premaster-секрет в течении произвольного захваченного сеанса или подделывания атрибутов сервера. В данной работе мы сосредоточим свое внимание на раскрытии premaster-секрет .

Основная идея в применении Bleichenbacher-атаки, с некоторыми изменениями, заключается в специфических свойствах S-PKCS и BVO.

Покажем как преобразовуется Bleichenbacher исходный алгоритм RSA для BVO с целью увеличения эффективности. PKCS соответствие открытого текста удовлетворяет следующую систему неравенств:

, (2.4)

где E=2B, F=3B-1, B=256^k-2. Границы E, F широко применены в целом алгоритме инверсии RSA. Если SSL/TLS протоколы имеют дело только с S-PKCS соответствиями открытого текста, то BVO улучшается. Следовательно, можно записать границы как:

, (2.5)

где значение получено включением минимума заполнения, значение вычисляется фиксированной позицией нулевого разделителя в открытом тексте P:

E' = 2B + 1 *256 ^k-3 + 1 *256 ^k-4 + ... + 1 *256 ⁴⁹ = 2B + 256 ⁴⁹ (256 ^k-5 - 1 )/255 and F' = 2B + 255*(256 ^k-3 + 256 ^k-4 + ... +256 ⁴⁹ ) + 0 + 255*(256 ⁴⁷ + 256 ⁴⁶ + ... + 256 ⁰ ) =3B - 255*256 ⁴⁸ - 1 .

Значения и подставляют в исходный алгоритм для увеличения эффективности атаки.

При этом злоумышленник должен знать ожидаемую величину номера версии, которая проверяется BVO. Следовательно, при атаке на зашифрованный текст С₀, BVO(C₀) = 0, чтобы узнать premaster-секрет, злоумышленник точно знает два байта P_0,k-47 и P_0,k-46 S-PKCS - соответствия открытого текста P₀= C₀ ^d mod N, он также знает, что P_0,k-48= 0. Эти значения используются при вычислении границ интервала <a,b>.

2.1.12 Атаки на протокол TLS методом понижения версии

Так как TLS содержит существенные улучшения по сравнению с SSL версии 2.0, атакующие могут попытаться создавать TLS-совместимых клиентов и серверов, чтобы вернуться к версии 2.0. Эта атака может произойти, если два TLS-совместимых партнера используют диалог в SSL 2.0 [5,7].

Хотя решение, использующее неслучайное заполнение сообщения блока PKCS #1 типа 2, не является надежным, оно предоставляет безопасный путь для серверов версии 3.0, чтобы заметить такую атаку. Это решение не безопасно по отношению злоумышленников, которые могут попытаться подсунуть ключ и осуществить подмену сообщения ENCRYPTED-KEY-DATA, содержащего тот же ключ (но с нормальным заполнителем) до момента истечения порога ожидания, заданного приложением. Партнеры, озабоченные атаками этого типа, никогда не должны использовать 40-битовые ключи шифрования. Вариация заполнителя младших 8 байт PKCS не увеличивает безопасности, так как это просто эквивалентно увеличению размера входного блока на 8 байт.

2.1.12.1 Избегание атак понижения версии посредником (man-in-the-middle) на протокол TLS

Когда клиенты TLS возвращаются к режиму совместимости с версией 2.0, они должны использовать специальное форматирование блоков PKCS #1. Это сделано так, что TLS-серверы будут отклонять сессии версии 2.0 с совместимыми TLS-клиентами.

Когда клиенты TLS работают в режиме совместимости с версией 2.0, они устанавливают правые случайные 8 байт заполнителя PKCS (исключая завершающий нулевой заполнитель) для RSA-шифрования поля ENCRYPTED-KEY-DATA CLIENT-MASTER-KEY, равными 0x03 (остальные байты заполнителя содержат произвольные случайные значения). После дешифрования поля ENCRYPTED-KEY-DATA, серверы, которые получают блоки, заполненные по такой схеме, продолжают свою работу обычным образом.

2.2 Моделирование Dos-атаки на протокол SSL

В общем случае, в распределенной ВС каждый субъект системы должен иметь возможность подключиться к любому объекту РВС и получить в соответствии со своими правами удаленный доступ к его ресурсам. Обычно в вычислительных сетях возможность предоставления удаленного доступа реализуется следующим образом: на объекте РВС в сетевой ОС запускаются на выполнение ряд программ-серверов (например, SSL-сервер, FTP-сервер и т.п.), предоставляющих удаленный доступ к ресурсам данного объекта. Данные программы-серверы входят в состав телекоммуникационных служб предоставления удаленного доступа. Задача сервера состоит в том, чтобы, находясь в памяти операционной системы объекта РВС, постоянно ожидать получения запроса на подключение от удаленного объекта. В случае получения подобного запроса SSL-сервер должен по возможности передать на запросивший объект ответ, в котором либо разрешить подключение, либо нет. По аналогичной схеме происходит создание виртуального канала связи, по которому обычно взаимодействуют объекты РВС. При использовании SSL-сервера, непосредственно ядро сетевой ОС обрабатывает приходящие запросы на создание виртуального канала (ВК) и передает их в соответствии с идентификатором запроса (443 порт) прикладному процессу, которым является SSL-сервер.

Очевидно, что сетевая операционная система способна иметь только ограниченное число открытых виртуальных соединений и отвечать лишь на ограниченное число запросов. Эти ограничения зависят от различных параметров системы в целом, основными из которых являются быстродействие ЭВМ, объем оперативной памяти и пропускная способность канала связи (чем она выше, тем больше число возможных запросов в единицу времени).

Основная проблема состоит в том, что при отсутствии статической ключевой информации в РВС идентификация запроса возможна только по адресу его отправителя. Если в распределенной ВС не предусмотрено средств аутентификации адреса отправителя, то есть инфраструктура РВС позволяет с одного объекта системы передавать на другой атакуемый объект бесконечное число анонимных SSL-запросов на подключение от имени других объектов, то в этом случае будет иметь успех типовая удаленная атака "Отказ в обслуживании". Результат применения этой удаленной атаки - нарушение на атакованном объекте работоспособности соответствующей службы предоставления удаленного доступа, то есть невозможность получения удаленного доступа с других объектов РВС - отказ в обслуживании.

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

И последней, третьей разновидностью атаки "Отказ в обслуживании" является передача на атакуемый объект не корректного, специально подобранного SSL-запроса. В этом случае при наличии ошибок в удаленной системе возможно зацикливание процедуры обработки запроса, переполнение буфера с последующим зависанием системы ("Ping Death"). Данный тип атаки мы использовали при написании программного продукта (Приложение А). Суть данной атаки заключается в том, что мы посылаем на указанный нами хост специально сформированный SSL - запрос. При чем атакуемая машина выступает в роли сервера, а машина злоумышленника - в роли клиента. Перед использованием данной программы нужно воспользоваться утилитой X-Spider, которая позволит увидеть открытые порты на атакуемой машине. Затем программа начинает забрасывать указанную машину на найденный открытый порт большим количеством SSL-запросов. Сервер не успевает обработать такое количество запросов и, как результат, SSL-служба на атакуемой машине перестает работать, результаты атаки приведены в Приложении Б. Данная атака ориентирована на Unix/Linux системы, поэтому для работы данной программы в среде Windows, её следует компилировать при помощи утилиты Cygwin.

Алгоритм данной атаки приведен на рисунке 2.8.

2

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Рисунке 2.8 - Алгоритм Dos - атаки

3. БЕЗОПАСНОСТЬ ЖИЗНИ И ДЕЯТЕЛЬНОСТИ ЧЕЛОВЕКА

3.1 Анализ условий труда

Дипломная работа выполнялся в помещении научно - исследовательской лаборатории (НИЛ). При разработке применялись ПЭВМ. В дальнейшем при разработке вопросов БЖД будем использовать источники и нормативные документы, регулирующие вопросы безопасности охраны труда при эксплуатации ПЭВМ [19, 22, 26]. НИЛ расположено на 2 этаже здания, выполненного из железобетонных конструкций.

Размеры НИЛ составляют 7 x 6 x 3.5 м, что составляет площадь 42 м².

Количество работающих - 6 человек (5 операторов ПЭВМ; 1 программист). Помещение НИЛ, исходя из норм на отдельные рабочие места, соответствует требованиям [22] - на одного работающего приходится 7 м² площади и 24,5 м³ объема при норме 6 м² и 20 м³ соответственно. В НИЛ размещены 6 ПЭВМ и 1 принтер.

В НИЛ образована система «Человек - Машина - Среда» («Ч-М-С»), элементами которой являются:

а) 6 элементов «человек» - люди, работающие в НИЛ (из них: 5 операторов ПЭВМ и 1 программист);

б) 6 элементов «машина» - ПЭВМ с периферийными устройствами;

в) «среда» - производственная среда в помещении НИЛ. Каждый элемент «человек» можно условно разделить на следующие функциональные части:

Ч1 - это человек-оператор (программист), управляющий машиной;

Ч2 - это человек, рассматриваемый с точки зрения непосредственного влияния на окружающую среду за счет тепло и влаговыделения, потребления кислорода и др.;

Ч3 - это человек, рассматриваемый с точки зрения его психофизиологического состояния под влиянием факторов, воздействующих на него в производственном процессе.

ПТ1 - предмет труда (контроль программного продукта);

ПТ2 - предмет труда (проектирование программного продукта);

М1 - выполняет основную техническую функцию (программный продукт);

М2 - функции аварийной защиты (изоляция, предохранители);

М3 - управление окружающей средой (тепло, шум, электромагнитное излучение);

А - влияние внешних факторов на «Ч-М-С» (влияние природной среды на производственную среду);